夜雨聆风两天前，老板甩给我一份v1.0的开发手册，561段文字、116张截图，让我根据系统现状更新一版。我心里咯噔一下——这要是搁以前，光对着截图改文字就得一周。
但这次我决定让AI上。Claude Code打开，几个sub agent调起来，Playwright脚本跑起来。两天后，一份v2.1版的新手册躺在文件夹里，章节重排、截图重采、文字逐字校验。
听起来很爽对吧？
但我那两天累得不行，比我自己写还累。
复盘的时候我才意识到一件事——这两天我根本没"写"过一个字的文档。我90%的时间都在干一件事：防止AI骗我。
第一次被骗：AI给我交了一份"完美"的章节大纲
任务一开始，我让AI先把原文档的结构提出来，作为更新基准。
AI很快交差，列出了7个章节的目录。我扫了一眼，正要点头继续往下走，鼠标停了一下——
目录里有一项叫"XX广场"。
不对啊。这是开发手册，是给开发者看的，"XX广场"是用户那边的功能，开发手册里不应该有这个东西。
我把脚本停下来，让AI重新逐段分析文档结构。结果发现一件离谱的事：原文档的目录页和正文，根本是两套内容——目录页是用户手册的目录被错放进来了，正文才是开发手册的真实内容。
AI第一遍提取的时候，把这两套东西当成一套来理解了。如果我没多看那一眼，整份新文档就会按错误的章节框架往下写，写完再发现，整个推倒。
那一刻我心里咯噔一下。不是因为AI错了——AI错很正常。
是因为AI错得太丝滑了。它没有报错、没有警告、没有犹豫，它非常自信地交了一份看起来完全正确的大纲给我。
AI最可怕的从来不是它做不到，是它"做到"了一个看起来完全对的版本。
第二次被骗：ALL CHECKS PASSED，但Word打不开
吸取教训，从那以后我每个阶段都加了验证脚本。
写到一半，我让AI生成新的docx文件，跑验证脚本——
ALL CHECKS PASSED ✓
13项检查全过。结构完整、字数对得上、图片数量正确。我心想行了，自己点开文档预览一下——Word直接报错，打不开。
我整个人傻在椅子上。
我把报错信息甩给AI让它排查。两个小时后AI才给我交代清楚：它之前用了一个Python库去改XML，那个库在序列化的时候动了OOXML格式的细节——自闭合标签从709个变成619个，少了90个。XML本身合法，验证脚本看不出问题，但Word对格式要求极其严格，微小的差异就直接拒绝打开。
验证脚本说全过，文档其实是废的。
那一刻我盯着"ALL CHECKS PASSED"那行绿字，特别想笑。
AI不仅会骗我，连我让它写的验证脚本，都能被它骗过去。
第三次被骗：4张截图，每张单看都对，放回去全错
最离谱的一次，是给文档替换截图的时候。
我让AI根据章节内容，把17张新截图映射回原文档的116张图位置上。AI很快做完了，每张截图我点开看，每一张单独看都没问题——是合理的系统截图，清晰、完整、内容相关。
我差点直接收工。
复盘的时候我无意中在文档里翻，翻到第6章"多智能体协作"那一段，截图显示的是一个功能分类页面——但章节内容讲的是对话界面。
不对啊。
继续翻，又发现一处：第5章某个工具栏的截图，应该显示"清除上下文"按钮，AI给的截图里那个按钮根本不在画面里——是另一个工具栏。
继续翻。又一处。又一处。最后查出来4张图全错。
每张图单独看都"是张合理的截图"。它们的错，只有放回上下文里才能发现。
那天晚上我对着屏幕坐了很久。我突然明白一件事：AI验证AI的输出，有一个根本盲区。
单点合理性 ≠ 全局一致性。AI看每一张图都觉得"这张合理"，但只有人能感知到"这张图和这一段文字之间，对不上"。
复盘那天我才发现，我的角色变了
项目交付的晚上，我翻了一遍这两天的工作日志。
我以为自己是去"写文档"的。但日志记录下来的事情是这样：
- 第一步：拆任务，定阶段（勘察 → 采集 → 写作 → Review → 修复）
- 第二步：发现AI混淆了用户手册和开发手册的目录，叫停重梳理
- 第三步：设计验证脚本，让另一个AI审第一个AI写的章节
- 第四步：发现ALL CHECKS PASSED但Word打不开，回退重做
- 第五步：4张图片映射错误，建立截图-章节对照表，逐张人工核对
- 第六步：审核agent扫出45个问题，分级处理
- 第七步：版本快照，建立回退点
真正"在写内容"的时间，不到10%。剩下90%我在干嘛？拆任务、设验证、审输出、做回退、定标准。
这些活有一个统一的名字——这是项目经理的活。
我以前是"写文档的人"，那两天我变成了"管AI写文档的人"。而后者，比前者累得多，但也值钱得多。
写给同样在用AI干活的PM和技术管理者
这两天踩的坑，沉淀下来三件事，我觉得对你们也有用。
1. Phase化拆解，不要一句话提需求。 我那两天没让AI"帮我更新这份手册"，而是让它：勘察现状 → 列变更清单 → 按章节并行写 → 审核agent全量Review → 修复 → 截图对照 → 二次Review。每个阶段都有可验收的产出物：变更清单、章节稿、Review报告、截图对照表。这不是技术问题，这是PM的基本功——只是这次的下属是AI。
2. 永远准备"AI审AI"的双层结构。 单个AI的输出永远不能直接信。我那两天的真实结构是：写作agent写 → 审核agent审 → 验证脚本兜底 → 我做最终决策。类比一下：代码要code review，AI的产出也要review，而且做review的最好是另一个AI——因为速度匹配，人来不及看。但兜底那一关，必须是人。
3. 永远建立回退点，不要一路狂奔。 我那两天保存了v1.0、v2.0、v2.0_final、v2.1四个版本。每翻一次车，就退回最近的版本。不建版本，就是在赌博——而AI输出的不确定性，比你想象的高得多。
最后
那116张截图，最后变成了一份用户拿到手就能用的手册。两天交付，老板很满意。但我学到的最值钱的事，跟这份手册本身没关系。
以前我以为AI会让工作变少。那两天之后我知道——
AI让"做工作"变少了，但让"管工作"变多了。
而"管工作"，恰好是PM和技术管理者最不可替代的核心技能。
这不是替代，这是杠杆。
觉得有用就点个赞和在看，想第一时间看到更新可以星标⭐混沌解码器。 我们下篇见。
/ 混沌解码器 / 读懂AI，用好AI
