夜雨聆风
用Claude Code写完38份文档之后,我花了一周和现实对齐
上一篇我写了3天38份文档那篇不会写代码的产品经理，3天用Claude Code写了38份文档
今天这篇，是那个故事的续集。
结论先行：38份文档写出来只用了3天，但让这些文档和真实系统对齐，花了整整一周——而且最终还是靠手动。
在那一周里，我经历了：
· 让AI自动截了189张系统截图
· 发现系统和PRD有100项差异
· 操作手册从第1版改到了第6版
· 写了25个Playwright自动化脚本
· 最后领悟了一个让人沮丧的道理
一、信心满满：以为一键搞定
前情提要：我用Claude Code 3天产出了完整的PRD和18份操作手册（10份角色手册+8份模块手册），一个B端教育系统项目。
下一步很自然——给操作手册加上真实的系统截图，变成可以交付的培训材料。
我的计划是：
1. 用AI自动化工具截取测试系统的每个页面
2. 自动把截图插入到操作手册对应位置
3. 导出成Word/PPT交付
听起来很简单对吧？一个自动化流程，几个小时应该能搞定。
我甚至在提示词里提前预警了：
“有个问题——测试系统不一定完全按照需求文档或操作手册研发的，这个要注意到。”
然而，”注意到”和”做好准备”之间，隔着一条巨大的鸿沟。
二、第一次打脸：内置工具全军覆没
我先尝试用Claude Code内置的browse工具——理论上可以直接在对话里操作浏览器截图。
结果：在Windows上，每次新的Bash调用会重启浏览器服务，localStorage丢失，登录token直接失效。等于每截一张图就要重新登录一次。
这条路走不通。
于是被迫转向Plan B：Playwright Python脚本。手动写脚本控制无头浏览器，批量截图。
Playwright脚本技术上不难（AI帮我写的，我不会写代码），但每个模块都需要处理一堆细节：
· 页面缩放75%才能让所有列字段显示完整
· 需要自动关闭右下角的通知弹窗
· 多角色模块需要切换账号（清除localStorage→重新登录）
· 防止误操作（删除/停用等按钮用dialog.dismiss()拦截确认弹窗）
· Ant Design的下拉框需要force=True才能点击
最终写了25个Python截图脚本，其中巡检任务管理最复杂——有7个脚本变体，因为需要5个角色切换、从创建计划到反馈整改的完整链路都要截图。
189张截图，终于全部拿到了。
三、第二次打脸：100项差异
截图拿到了，开始和操作手册对比。
这一对比——崩了。
100项差异。8个模块无一幸免。
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
P0里最刺眼的几个：
· 某个管理页签在系统中未显示——手册详细描述了一个功能入口，系统压根没做
· 巡检任务缺少”任务类型”字段——PRD里有，手册里有，系统里没有
· 数据趋势图功能缺失——手册写了趋势折线图的交互逻辑，系统DOM中找不到任何”趋势”相关元素
· 某个审批流程步骤不同——手册描述6步流程，系统实际只有4步，步骤名称和内容完全不同
差异最集中的两个重灾区：异常预警模块（22项）和在线质量评测模块（22项），并列第一。教研管理模块（18项）第三。
看到这些数据的那一刻，我的心情就一个词：绝望。
这意味着，我之前3天写的那些精心打磨的操作手册，有将近一半的内容需要根据系统实况重新调整。
四、痛苦循环：操作手册的六层演进
接下来是一场漫长的拉锯战。操作手册从第1版一路改到第6版：
第1层：源手册（理想状态）
纯基于PRD编写的操作手册，18份，干净漂亮。假设：研发会按PRD做。
第2层：用户升级后的完整手册
用户试用测试系统后提出了升级意见，把意见同步到手册。还处于理想状态——”这是如果研发不偷工减料升级后的操作手册应该有的样子”。
第3层：标差异+加截图+精简
让Claude Code将测试系统和手册对比后，发现大量差异，每处差异标注了⚠️，同时插入189张自动截图。这一层是最痛苦的——每读一页手册都在发现”又不对了”。
第4层：按差异决策更新
我逐条对100项差异做了决策，四种处理方式：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
然后AI按决策更新手册，删除差异标注。
第5层：V3.0风格优化成品
按”B端教育系统操作手册标准”优化结构和描述风格。补充目录、操作路径导航、角色权限表。8份独立版+1份合并完整版（246KB，189张截图）。
第6层：飞书检查修正后的最终版
在飞书文档中人工逐页检查后，又发现了一些系统和需求不完全一致的问题。更改后又手动重新截了一批图。
最终产出：培训PPT（82MB）+ 完整版Word手册（44MB）。
从第1层到第6层，核心逻辑就一句话：每多看一次真实系统，就会发现手册又需要改一次。
五、两个AI互相卷
中间还有一段插曲。
巡检任务管理是最复杂的模块（7个角色、12种任务状态、反馈整改流程）。我先让Claude Code生成这个模块的带截图手册，结果缺少很多截图。
于是我把同一个任务交给了OpenAI Codex，原话是：
“Claude Code生成这个模块任务就是缺少很多截图，你能做到它做不到的吗？”
Codex确实”卷”了一波——自己看着流程从源头发起计划，填写数据流转到各个环节，在每个环节操作前截图。
后来的项目中，我同时开着CC和Codex的多个会话窗口，并行执行不同模块的任务。甚至需要一个共享进度文件来协调——
“如果非常巧合遇到多个工具同时更改执行进度和执行计划文件时，要想办法处理或等一等”
一个不会写代码的PM，同时指挥两个AI工具的多个会话并行干活——听起来很赛博朋克，实际上很痛苦。
六、最终还是手动
整个过程最讽刺的部分是什么？
第6层手册的名称已经说明了一切：”在飞书检查修正且重新截图后的最终版”。
即使有了189张自动截图、25个Playwright脚本、100项差异清单的AI辅助，最终交付物还是需要：
· 人在飞书文档里一张张检查截图是否正确
· 人手动重新截了一批图替换不准确的
· 人逐页确认格式和内容
AI把一个月的手动工作压缩到了一周，但那一周里密度最大的工作，仍然是人做的判断和决策。
七、AI自动化是放大器
经历了这一周后，我想明白了一件事。
AI自动化不是万能药，它是放大器——放大效率，也放大混乱。
当上下游每个环节都按标准来的时候，AI就是效率核弹：3天38份文档14,000+行，一点问题没有。
但只要有一个环节的交付质量不达标（比如研发没完全按PRD实现），AI的自动化链条就会在那个环节断裂，下游再强的自动化都是白搭。
我甚至推导出了一个公式：
AI自动化效率 = AI能力 × min(1, 上游交付质量)
当上游交付质量为1（完全按PRD实现），AI满血输出。当上游交付质量打了折扣，AI效率被同比腰斩——而且新增了”差异发现→决策→多文档同步→一致性校验”的巨大人工成本。
100项差异就是证据：48项需要改手册和PRD，15项是系统BUG，剩下的37项需要逐条判断”改不改”。
如果研发完全按PRD实现，这100项差异为零，操作手册可能只需要2层演进而非6层。
八、给想用AI自动化的人3条建议
1. 先验证上游再自动化下游
在启动任何AI自动化流程之前，先确认上游输入的质量。我的教训是：先写了完美的操作手册，才发现系统和PRD不一致。如果我先做差异核查，再写手册，能省掉至少3层版本演进。
2. 预留”手动兜底”的时间
不要在排期里假设AI自动化100%成功。我的189张截图拿到了，但100项差异的决策和修正全靠人工。给”检查-判断-修正”环节预留至少和”AI执行”一样多的时间。
3. 记录每一步决策，而不只是记录结果
100项差异清单 + 每条的决策记录（以系统为准/忽略/BUG/截图问题），这些记录让后续的手册更新有据可查。如果只保留最终手册而丢掉决策过程，下次遇到类似问题就得重新判断一遍。
写完这篇文章的时候我在想，上一篇3天38份文档那篇可能让人觉得”AI无所不能”。
今天这篇想告诉你的是：AI的强大是真的，AI的局限也是真的——而这个局限往往不在AI本身，在你上游的交付质量。
3天写38份文档是爽文，但把文档和真实系统对齐的一周，才是真实的工作日常。
AI时代最珍贵的不是能用AI写文档的能力——是在AI的输出和现实之间架起桥梁的判断力。
这是「精分边缘的猫」的第3篇文章。
B端产品经理 / 15年 / 不会写代码 / 用AI做了不少事也踩了不少坑。
如果你也在用AI工具做实际工作，关注我，后面还有更多真实记录。