审查或改写他人技术文档时：按严重度分级…

在审查、改写他人技术文本、撰写文档审查报告，或任何文档交付前做最终检查时，用一套分级、发现格式与交付清单来保证内容不变、缺陷可追溯。

适用场景

解决思路

1. 先阅读全文，绝不只看摘要；编辑即诊断，每处修改都要指出它修复的具体缺陷，能用最小改动修好就用最小改动。
2. 按严重度映射分级：BLOCKER 为硬规则违规（禁用破折号、changelog 段落、正文中出现交付历史）以及引文无法支撑或无来源的断言；WARNING 为禁用句式、结构缺陷（问句标题、结论被埋、段落可任意重排）以及仅松散支撑的断言；OBS 为歧义、缺少打磨、细心作者多半能自己发现的问题。
3. 改写他人文本时，最高要求是内容完全不变；按顺序操作：读原文并标出所有禁用句式与用词违规；写出改写版本并朗读；问三个控制问题——哪句仍像语言模型写的、改写是否增删了事实/数字/日期/名称/来源/断言、改写是否以新的修辞形式重现了已删除的模式；把改写段落当作原文重新扫描；修复控制问题暴露的问题，增加和丢失都算错误。
4. 绝不为了把句子写完而添加事实：去问作者，或换一个更简单的句子；若某句两次尝试后仍生硬，就围绕其主旨重写整段。
5. 只改连续正文：代码块、frontmatter、表格数据、链接目标保持原样。
6. 改写保持文档原有语言：荷兰语文档仍返回荷兰语，结构规则与真实性规则照常适用，英语特有的词汇检查替换为该语言自己的清单（若有）。
7. 作者可联系时，diff 就是提案：覆盖其文本前先展示改写；在仓库中无人值守时，提交即提案，审查做同样的工作。
8. 当原文没有可恢复的断言（铺垫、注释、释义句）时，正确做法是删除并留下标记缺口 `**[input wanted: <该句应做出的断言>]**`（核心技能 `**[source wanted: ...]**` 的断言级同类）；满是标记缺口的改写对无断言原文而言是预期结果，不是失败。
9. 不要仅凭禁用句式清单就下判断：每种模式在优秀的人类写作中也会出现，只有当同一段落中多个迹象同时出现时才标记。
10. 以下情况不要标记：打磨过的语法与一致格式；仅一次重复的句首（只有重复毫无增益时才修）；为强调用的单个短句（只有一连串碎片才是问题）；一般性的正式用词（清单只点名特定词）；事实性对比（如“流水线设置标签，开发者不设置”是陈述而非对偶）；读者真会权衡的严肃替代方案；限定范围的修饰语（范围、假设、安全或法律说明保留，只去掉堆叠）；迁移文档或发布说明中对先前情况的引用（那里变更本身就是主题）；引文中的词（绝不在引用、标题或讨论该词的示例内部改写）；有解释作用的比喻（只去掉其装饰）；刻意为之的笨拙（清晰的碎片或不对称句子不因可被润色就算缺陷）。
11. 审查报告：第一行给结论，发现按最严重优先排序；在使用该分级词汇的报告中定义严重度（BLOCKER 无法继续、WARNING 可能返工但不阻塞、OBS 值得注意）；每条发现包含一句缺陷陈述、位置（`file:line`、章节、任务 ID）、建议修复、置信度；给出具名的空情况（“FINDINGS: none”）。
12. 文档断言与代码矛盾时，缺陷在文档，报告时附上冲突来源；顺带发现的不相关 bug 不算你的发现；复审只列仍未解决的问题；承认做得好的部分。
13. 交付前逐项检查：与同目录既有文档风格匹配，若存在 `README.md` 索引则加入；无 em dash、en dash 或 ` -- `，无 changelog 段落或“last updated”字段，正文无 ticket key、阶段或 SHA；无禁用句式（至少检查摘要与结尾段落）；标题命名内容（不用问句、不用“What X means”、标题不在首句重复）；文档、章节、段落层面结论先行；流程每句一个动作且有执行者；文档提出或决定之处，每个非平凡选择都记录理由与严肃替代方案，且成本与收益都写入；事实与提案可区分，估算有标注，未知明确标为未知；每个带数字的断言都追溯到文档中具名的来源；通过实际点击检查引用：章节号、相对链接、文件名确实存在；术语一致并在首次使用时定义，一个概念一个术语；朗读至少摘要，无碎片成排、无三句同头；对开头与摘要做去名测试：删掉产品名后陌生人仍能看出文本在讲什么；冷读且整读：对从未见过产生它的对话或反馈轮次的人读来自然，全篇一个声音，无拼接痕迹，无解释文档为何这样写的句子；改写时：没有增删任何事实、数字、日期或来源。

适用边界 · 注意事项

• 不用于代码审查（只审查其中的文字部分）。
• 不要用审查环节重新争论已定决策、扩大范围，或把文档改成自己的偏好风格。