PDF 转 Word 到底做了什么：从一份真实的步骤日志看

把 PDF 转成可编辑文档，通常被描述成一个动作。它不是。本站一次真实的运行包含八个记录在案的步骤，其中两个是流程自己恢复过来的失败。这份日志值得读，因为它同时解释了价格和失败行为。

一次成功任务的步骤日志

inspect_document              pypdf-docx-editable     884 ms
  extract_document_content     pypdf-docx-editable     644 ms
  render_document_page         pypdf-docx-editable     482 ms  error: unsupported_renderer
  convert_to_editable_document compact_spacing         424 ms  error: strategy_requires_optimization
  convert_to_editable_document (retry)                1357 ms
  validate_editable_document                           4289 ms
  optimize_document_candidate  compact_spacing        1040 ms
  validate_editable_document (after optimise)          3875 ms

这些行里有两行是错误，而任务依然成功了。这就是设计：某一步的错误是循环要用的信息，不是对这份文档的判决。

为什么要渲染自己的输出

最要紧的一步是 validate_editable_document，它也是最慢的——这次运行花了 4.3 秒。它做的事是：把它刚产出的 DOCX 渲染回一张图，再拿这张图和源页面比。文字覆盖率、缺失的数字、表格结构、合并单元格、边线、超出页面的文字。

这就是"转换跑过了"和"转换产出了能用的东西"之间的区别。写完文件就停的流程，根本不知道文件对不对；只读 DOCX XML 的检查器可以确认段落存在，而渲染出来的页面上文字已经丢了一半。渲染回来，才是发现这件事的方式。

第三步那个 unsupported_renderer 错误是同一件事的诚实版本：试用的渲染器做不了这件事，所以流程直说，而不是跳过校验、假装输出被检查过。

修复循环

校验发现问题时，流程不会立刻失败。它会优化候选——这次运行用的是紧凑间距策略，用来容纳溢出的内容——然后再校验一次。日志里的两次转换是同一份文档用两种策略各转一次，而第一次尝试在第二次开始之前就被优化门明确否决了。

这就是为什么在本站，成功的任务要 35 到 70 秒，而失败的只要 12 到 32 秒。失败中断了循环；成功把它跑到底，其中至少包含一次完整的重新渲染和比对。为慢路径付费正是关键：快路径产出的，是那些看起来没问题、却少了一列的文档。

失败在这里是什么意思

本站记录在案的转换中，7 次失败、9 次成功。7 次失败全部带同一个错误码 agent_execution_failed，意思是循环用尽了修复尝试，而不是撞上了计费或网络问题。每一次都没有发布文件，预占的积分都被释放。

在你决定要不要重试时，这个区别很重要。这里的失败是关于这份文档的陈述——这份扫描件在可用的尝试次数内没能通过转换——而不是关于服务挂了。同一个文件再传一次，通常会以同样的方式失败。换一份更清楚的扫描件，或者用数字版 PDF 替代拍出来的照片，结果才会不同。

成功的那些还警告了什么

本站每一次成功的转换都带着 layout_approximate 警告，这不是在为一个缺陷找借口。把固定版式的页面转成可流动的文档，意味着字体和间距不可能和原件一致——原件本来就没有可重排的结构可以保留。一页图片可以做到完全一致，但那样什么都改不了，也就失去了意义。

搞清楚你需要的是哪一种，就是决策的大部分。如果文档必须长得一模一样，你要的是 PDF，不是 Word 文件。如果它必须可编辑，近似版式就是代价，而真正有用的问题变成：文字、数字和表格有没有活下来——这恰好就是校验那一步在量的东西。