用历史反馈驱动 Claude 三轮文档审查

把文档交给 Claude 看一遍，和建立一套文档审查流程，是两回事。一位做客户软件项目的 PM，把历史评审意见整理成清单，再让三个不继承对话的 agent 连续检查。按作者的记录，人工评审收到的意见从约 10 条降到了 2-3 条，包含细小问题。

值得拆解的不是「多问几遍」，而是这套流程如何确定依据、追查遗漏，以及把最终修改权留在人手里。它适合借鉴到需求、设计和估算文档，但效果也有明确前提。

先确定检查依据，Claude 才知道什么算错

作者的做法来自一位同时负责多个项目的资深 PM：把需求、规格、设计文档和实施指南放在 Google Drive，让 Claude 交叉检查矛盾、缺失的关联和不一致的用词。

作者随后规定，新文档必须对照已经批准的上游文档。比如审详细设计时，依据是已批准的需求和基本设计；术语、名称发生冲突，上游文档优先。

这个顺序很关键。模型擅长找两段文字的差异，但差异不一定是错误。先指定哪份文档有决定权，它才有判断方向。

另一份依据来自过去的人工评审。作者去掉只适用于单次项目的意见，把能复用的问题分成两级：

• 「critical」覆盖会改变结论、范围、总成本，或让读者误解前提的问题。
• 「normal」覆盖不改变结论的措辞和细节缺失。

清单相当具体。比较对象是否符合委托方约定？有没有混入目标层级之外的产品？跨边界的处理和费用是否标明包含或排除？范围图是否与正文一致？成本是否包含测试、评审、PM 和基础设施搭建？

这些并非凭空设计的提示词。作者曾因比较对象和范围写偏而收到批评，才把对应检查放在前面。

审查清单的价值，在于把真实踩过的坑变成下一次必须回答的问题。

三轮审查，后两轮专门检查前一轮漏了什么

三轮都使用不继承先前对话的新 agent，但会显式接收前轮意见：

1. 第一轮通读全文，逐项检查清单。
2. 第二轮接收第一轮意见，只查遗漏和误判。
3. 第三轮接收前两轮意见，继续查遗漏和误判。

所谓「新 agent」，这里指新会话没有沿用旧对话，并不代表更换模型，也不代表完全独立判断。后两轮仍然看得到之前的结论。

即使某轮没有发现问题，剩余轮次也照常执行。如果没有逐项报告结果，或没有确认读过全文，该轮就要重做。

作者报告，第一轮通常发现约 20 个问题，第二、三轮各发现 5-10 个，最终每份文档大约修复 30-40 个问题。这与开头的 10 条降到 2-3 条是两组不同口径：前者是 AI 审查过程中处理的问题，后者是人工评审收到的意见，不能直接混算。

Claude 全程只提意见，不编辑文档。每条意见标成「fix」「needs judgment」或「skip」，由作者决定改什么。这样至少保留了一道检查：模型指出的矛盾，可能只是它没有理解业务前提。

能机械查出的错误，交给脚本更合适

内容修完，作者才做一次措辞检查。Python 脚本负责找禁用词、项目术语和句尾不一致，还覆盖日语动词的变形；AI 负责判断命中的条目，并补查词表没有收录的随意表达。

这里的分工值得借鉴：脚本保证已知规则得到执行，模型处理需要上下文的判断。日语词尾检查则有语言前提，不能直接照搬到中文文档。

规则也没有全部塞进 Claude skill。作者把流程和清单的权威版本放在 Obsidian，skill 只描述如何执行，每次运行再加载规则；发生冲突时，以 Obsidian 为准。这些通用规则中不写客户名和项目专有名称。

下面这段目录展示了如何把内容审查、措辞检查和共享规则分开维护：

document-writing/
├ 00_entry-point.md
├ tool-constraints/
│ └ google-docs-constraints-and-rules.md
├ create/
│ ├ skill_create-procedure.md
│ └ create-checklist.md
├ review/
│ ├ content-review/
│ │ ├ skill_content-review-procedure.md
│ │ └ content-review-checklist.md
│ ├ wording-check/
│ │ ├ skill_wording-check-procedure.md
│ │ ├ wording-check-checklist.md
│ │ └ wording-check-script.py
│ └ responding-to-feedback/
│   └ skill_feedback-procedure.md
└ shared-rules/
  ├ banned-words-glossary.md
  ├ editing-rules.md
  └ formatting-rules.md

重点看 content-review-checklist.md 和 wording-check-script.py：判断标准与机械检查分别维护，便于独立更新。完整流程是写作、内容审查、应用修改、措辞检查，最后处理人工评审反馈。

我的判断

我赞成这套方法把「依据」放在模型前面。相比一句「帮我检查文档」，上游文档加历史清单能明确检查对象，也能让人工复核更容易。

但三轮是否最划算，目前只能算作者的经验之谈。原文没有给出样本量、模型版本、耗时、费用，也没有比较两轮、三轮或一次完整审查的差别。人工意见从约 10 条降到 2-3 条是有用的个人观察，还不足以证明普遍效果。

后两轮读取前轮意见，有利于减少重复，也可能沿着已有判断继续走。「确认读过全文」只是执行要求，不能充当模型确实完整理解文档的证据。

还有一个清楚的能力边界：清单要求指出哪里缺图，作者却坦言，系统仍不善于判断解释是否难懂、加图是否更清晰。规则里写了要求，不等于模型稳定做得到。作者考虑把这类增值工作交给另一个 agent，目前还只是设想。

能拿来做什么

• 下次写前端详细设计或全栈接口方案时，把已批准的需求和基本设计一起提供，并明确冲突时以谁为准，避免模型自行选择依据。
• 从过去的评审意见中整理一份短清单，先覆盖范围、职责、数据流和成本前提，再补措辞细节，每条都应能对应真实问题。
• 对复杂文档试行三轮审查，记录每轮新增且被采纳的问题及耗时，用自己的结果判断是否需要保留全部轮次。
• 用 Python 或 Node 脚本检查禁用词和术语一致性，让 AI 判断命中项是否成立；应用修改后，继续保留人工评审。