一次 37 页设备点检标准文档的踩坑复盘
这次经历可以说是波澜起伏。
事情看起来并不复杂：我手里有一份 37 页的点检标准 PDF，还有一份公司产品数据 Word。我需要按照公司数据替换 PDF 中的品牌、Logo 和少量固定参数，最后得到一份可以继续编辑的 Word 文档。
我原本以为，这正是 AI 擅长的工作。结果为了这份文档，我前后尝试了好几种方法，几乎耗尽两个 Plus 账号的周额度，得到的却一度全是排版混乱、无法交付的文件。
直到最后我才明白：问题不是 AI 完全做不了，而是我一开始就把任务拆错了。
第一次尝试：把所有东西交给 AI
最开始，我过于相信 AI 的能力。
我直接把模板 PDF 和公司数据 Word 发给 AI，让它完成以下工作：
- 读取公司 Word 中的产品数据；
- 理解 37 页 PDF 的内容和排版；
- 按照 PDF 重新制作一份可编辑的 Word；
- 替换其中的品牌、Logo 和参数；
- 保留原来的图片、标注、分页、页眉页脚和整体格式。
现在回头看，这实际上不是一个任务，而是四个相互影响的任务：
- 从 PDF 中识别文字；
- 根据视觉结果反推 Word 结构；
- 重新搭建 37 页复杂排版；
- 在重建后的文档中进行数据替换。
PDF 保存的是最终呈现效果，而 Word 保存的是段落、分页、浮动图片、文本框、锚点、页眉页脚等可编辑结构。想从 PDF 的“结果”完整反推出 Word 的“结构”，本来就很困难。
AI 当时采取的路线，大致是先通过视觉理解或 OCR 读取每一页，再尝试用 Word 元素重建排版。文字基本能够识别出来，但版式很快失控：
- 原本对齐的符号没有对齐；
- 粗体和普通字体混在一起；
- 图片遮挡文字；
- 图片、箭头和标注框发生错位；
- 页面上出现莫名其妙的空白框；
- 删除一个空白框时，与它关联的图片也会一起消失；
- 原 PDF 的分页关系无法稳定复现。
最终得到的虽然是“可编辑 Word”，但离“可以正常维护和交付”还有很远。
失败稿中的判定符号和文字间距，与右侧原稿存在明显差异。
这些空白框并不是正常段落，删除时还可能连带删除上方图片。
图片、文字和浮动对象之间的关系没有处理好，导致正文被遮挡。
第二次尝试：增加更多限制条件
第一次失败后，我以为是提示词写得不够详细，于是第二次加入了更多要求：
- 必须按照原 PDF 的分页；
- 必须保留字体、粗体和段落间距；
- 图片位置不能变化；
- 页眉、页脚和页码必须与原稿一致；
- 每一页都要单独调整，不能全局缩放；
- 最终必须逐页渲染检查。
这些限制当然有用，但效果仍然不理想。
原因也很简单：我只是给原来的错误路线增加了更多约束，却没有改变路线本身。AI 仍然需要先识别 PDF，再重新搭建整份 Word。37 页内容越多，文字、图片、文本框和分页之间的误差就越容易累积。
结果是，我又花了大量时间和 token，最后仍然只能放弃。
这让我第一次意识到：提示词写得更长，并不能解决工具路线选错的问题。
第三次尝试：OfficeCLI 能不能解决问题？
我开始怀疑，AI 处理 Word 如此麻烦，是不是因为缺少专门工具。
于是我在 LINUX DO 上搜索相关方案，发现不少人在推荐 OfficeCLI。
OfficeCLI 是一个面向 AI Agent 的 Office 文档工具，可以读取、编辑和自动化处理 Word、Excel、PowerPoint，还能把 Office 文件渲染成 HTML 或图片，方便 AI 执行“修改—查看—再修改”的流程。它以单个可执行文件提供，不依赖本机安装 Microsoft Office。
从功能介绍来看，它确实很适合批量替换、模板填充、结构化读取和文档自动化。我当时以为，这可能就是缺失的那块拼图。
但实际尝试后，效果仍然有限。
OfficeCLI 可以提高 AI 操作 Office 文件的能力，却不能自动消除“从复杂 PDF 反推可编辑 Word 结构”这一步的难度。我的瓶颈并不是不会调用 Word，而是手里没有一份排版可靠的可编辑底稿。
换句话说：工具可以帮助 AI 编辑 Word，但不能保证 AI 凭空重建出来的 Word 与原 PDF 完全一致。
到这一步，我几乎用完了两个 Plus 账号的周额度，眼前却还是一份排版混乱的 Word。
第四次尝试：不再强求 Word，改用 Typst
冷静下来后，我换了一个思路：
既然复杂 Word 是 AI 不喜欢处理的东西，能不能换成 AI 更擅长的纯文本格式？
除了 Markdown，我还发现了 Typst。Typst 不是 TXT，而是一套基于标记语言的排版系统。它的源文件是纯文本，扩展名通常是 .typ，通过编译器生成 PDF。它既有类似 Markdown 的简洁语法，也能通过代码控制页面、字体、表格和复杂排版。
这类格式对 AI 更友好，因为：
- 内容和格式都能直接写成文本；
- 不需要操作大量不可见的 Word 对象；
- 修改某个参数时，可以准确定位到代码；
- 编译后能快速查看 PDF 效果；
- 不容易出现“移动第三页的一张图片，第二十六页突然乱掉”的情况。
这一次我还做对了一件非常重要的事：先把公司数据 Word 整理成一份 Markdown 数据替换规范。
原来的公司 Word 更像一张数据表，内容分散，AI 每次都要重新读取和判断。整理成 Markdown 后，规则变得非常清楚：
- 哪些通用名称需要替换；
- 哪些具体型号必须保留；
- 哪些固定参数有公司依据；
- 哪些数值不能猜；
- 图片中的文字是否需要处理。
这样一来，后续每次尝试都不必重新理解那份复杂 Word，只需要读取一份简明的替换规范。
把“需要替换、必须保留、固定参数”拆开以后，后续任务不再需要反复读取复杂的数据表。
Typst 的效率确实高了很多，AI 修改纯文本也更加稳定。但是最后的效果只是有所提升，仍然没有完全达到要求。
原因是：虽然输出工具换成了 Typst，但最前面的信息来源仍然是 PDF。只要版式重建仍然依赖 AI 对 PDF 的视觉理解，识别偏差就会被带到最终结果中。另外，Typst 更适合生成 PDF，并不能直接满足后续人员继续在 Word 中大量补充实例的需求。
Typst 版本的结构明显稳定了，但图片被简化成占位区域，细节和原 PDF 仍有差距。
真正的转折：先把 PDF 转成 Word，再让 AI 做小修改
折腾到这里，我终于问了自己一个很朴素的问题：
如果没有 AI，我第一时间会怎么做？
答案其实非常直接：先找一个可靠的 PDF 转 Word 工具。
我之前迟迟没有走这条路，一方面是过于依赖 AI，另一方面也是想看看 AI 到底能做到什么程度。结果绕了一大圈，最后还是回到了最传统、也最有效的方法。
我尝试了两个 PDF 转 Word 网站：
转换结果出奇地好。原 PDF 中的大部分分页、文字、图片和排版都被保留下来，而且得到的是真正可编辑的 Word，而不是 37 张整页截图。
这一步解决了整个项目中最困难的问题：如何得到一份排版可靠的可编辑底稿。
之后，AI 不再需要重新制作 37 页 Word，只需要在已有底稿上做最小范围修改：
- 替换页眉 Logo；
- 把 14 处通用名称
Variax改成JSG； - 把 37 处独立使用的通用
VG改成JSG； - 核对五项固定参数；
- 保留所有没有明确映射的具体型号；
- 保留照片像素中的文字；
- 不碰其他文字、图片、分页和版式。
最终，实际文字替换只有 51 处，外加 1 个 Logo。五项固定参数在可编辑底稿中已经与公司资料一致，因此只做了核对，没有为了“看起来修改过”而重复改动。
更重要的是，具体型号没有被误改。像 VG25、VG50、VG50T、VG75、VG15H、VG20H、VG100、VG20M 等内容，因为没有公司提供的型号映射，全部按原样保留。
这一次，AI 做的终于是它擅长的事情：在结构可靠的文档中，按照清晰规则进行小范围文本替换和检查。
转换后的底稿已经保留了原来的图片、标注、分页和主要版式，AI 不再需要从零重建整页。
| 原 PDF | 最终 Word 导出效果 |
|---|---|
 |
 |
最终版本只替换了品牌文字和 Logo，正文、图片和原有布局基本保持不变。
我最后得到的正确流程
如果以后再遇到类似任务，我会直接采用下面的流程：
- 先明确最终交付格式。 如果后续还要大量编辑，就必须保留 Word，而不能只追求一份看起来相似的 PDF。
- 先寻找可靠的格式转换工具。 用专门工具完成 PDF 到 Word 的结构转换，不让 AI 从零重建 37 页排版。
- 把数据规则单独整理出来。 将复杂的公司 Word 数据表整理成简洁的 Markdown 规范。
- 明确替换边界。 写清楚什么必须改、什么必须保留、什么不能猜。
- 先做 3～5 页样稿。 样稿通过后再处理全文，不要一开始就生成全部 37 页。
- 只让 AI 做最小修改。 能替换一个词，就不要重写整段；能替换一张 Logo，就不要重建整个页眉。
- 最后逐页验证。 检查页数、分页、图片、字体、粗体、页眉页脚、文字重叠和可编辑性。
这套流程看起来没有一开始那么“智能”，但它更快、更稳，也更容易检查。
这次经历给我的几个教训
1. 做之前，先花时间选择方法
我现在越来越认同一个原则：在真正开始执行之前，至少拿出三分之一的时间理解问题、比较工具和设计流程。
一开始多花半小时选择正确路线，可能会节省后面几天的返工。
2. 不要把所有工作都交给一个工具
PDF 转 Word 工具擅长保留版式，AI 擅长理解规则、替换文字和检查差异，Microsoft Word 擅长最终编辑与导出，Typst 擅长用纯文本生成稳定 PDF。
工具没有绝对的强弱，关键是让每个工具负责自己最擅长的环节。
3. 学会把复杂问题拆成简单问题
原任务是“读取公司数据、理解 PDF、重建 Word、替换内容并验证”。拆开以后就变成了：
- 用转换工具得到可编辑底稿；
- 用 Markdown 保存替换规则；
- 用 AI 执行有限替换；
- 用 Word 导出 PDF；
- 逐页检查结果。
每一步都更简单，也更容易发现错误。
4. 坚持最小试错原则
我最大的浪费，是每次都直接处理完整的 37 页。
更合理的做法应该是：先做 3～5 页，重点选择包含标题、表格、图片、标注和复杂分页的页面。如果这几页都无法通过，就立即更换路线，而不是等完整文档生成后再发现方向错误。
5. AI 不是万能替代品，而是流程中的一个环节
这次经历并不能简单归结为“AI 不会处理 Word”。更准确的说法是：当任务要求从复杂 PDF 反推 Word 结构，并同时保证 37 页排版完全一致时，仅靠 AI 的视觉理解和 OCR 很难稳定完成。
但当我提供了一份可靠的可编辑底稿，并把任务缩小到 51 处文字和 1 个 Logo 时，AI 的效率和准确度就明显提高了。
真正重要的，不是有没有使用 AI，而是有没有把 AI 放在正确的位置上。
写在最后
这次折腾最大的收获，并不是得到了一份 Word 文档，而是重新理解了“自动化”这件事。
最好的方案不一定是最先进、最复杂、最像魔法的方案。很多时候，真正高效的流程，反而是先用成熟工具解决最确定的问题，再让 AI 处理需要理解和判断的部分。
先找对方法，再开始执行；先做最小样稿，再处理完整任务；先把问题拆简单，再谈自动化。
这大概就是我烧掉大量时间和 token 后，换来的最有价值的经验。