模型改文档最贵的错不是写错，是悄悄删掉一句"必须"

为什么模型改完的文档看起来更干净了，风险反而更大？因为被删掉的往往不是废话，而是那句"必须"。

大多数文档评审把注意力放在写错的句子上。对模型起草的页面来说，代价更高的失败通常是消失的句子：一条"不得"、一条弃用通知、一条在重写过程中悄悄不见的前置条件。下面这套闸门把"删除约束"变成一次显式、签名的动作，模型可以继续写连接性文字，而每一条离开页面的限制仍由人负责。

失败模式是丢失，不是编造

模型接到"改进这个页面"的请求，会把它读成写作任务，而写作任务奖励简洁。约束句恰恰是页面里最不简洁的部分，因为好页面会在概述、步骤、故障排查里重复它的警告。一次带"缩短"指令的改写，就会把这些重复压成单次提及，而从上到下读 diff 的评审者看到的是一张更干净的页面，而不是一张更弱的页面。

查来源抓不住这个问题。一个确认"草稿里每条断言都有出处"的检查器，在草稿比被替换页面断言更少时会欣然通过，因为它只朝前看。你需要反方向：从旧页面出发，枚举它承载的约束，拒绝让任何一条消失，除非有具名的人说它该消失。这个检查是机械的、便宜的，且与草稿出自哪个模型无关。

按句子类型分权，而不是按章节

章节级归属好描述、难执行，因为一次重写会跨越章节边界，而有意思的句子是散落的。句子分类是可执行的，因为情态动词和指纹是脚本真能看见的东西。一个实际后果是：起草提示词应当写明模型可以碰什么。"重写引言并扩展示例；逐字复制每一句含 must、never 或 deprecated 的句子"，这样的提示词人后来真能审计，因为输出可以对着输入检查。

用标记词表抽取约束句

脚本只用 Python 标准库，这在你希望它能在任何产出草稿的地方运行时很重要。它把页面切成句子，保留匹配情态标记正则的那些，再把旧集合与草稿集合比对。一条约束在归一化句子原样存活时算"存在"，存在接近匹配时算"改写"，草稿里没有足够相似的东西时算"缺失"。

相似度阈值是唯一可调的数值，0.75 是刻意放松的默认值：它把一条被改写的约束归为"改写"而非"缺失"，让人看到新旧句子并排，而不是一次不透明的删除。

删除说明就是人的签名

一条"缺失"或"改写"的约束不自动等于错误，因为有时限制确实过时了。关键在于这个决定必须可归因。每个被接受的变更都有一条以原句指纹为键的记录，包含负责人、原因和日期。

两个细节让它持久而非走过场。第一，键由句子文本派生，所以一条说明无法漂移到另一条约束上；句子被编辑，指纹就变，说明变成"过期"，评审包会把它暴露出来而不是默默忽略。第二，只要有账户缺失，闸门就以非零码退出，CI 任务可以用评审者看到的同一个信号来卡发布。

接进起草循环

先用 git show HEAD:docs/retries.md 把已发布页面冻结到 before 目录；用点名受保护句子、禁止改动它们的提示词起草新页面；把草稿存为 after 并跑闸门；读评审包而不是读整页，该留的恢复，该删的写一条带负责人和原因的说明；重跑到未归零为止，再正常评审行文；最后把说明文件与页面一起提交，让推理随文本一起发布。

起草这一步受益于宽松的免费额度，因为调提示词时你会反复重生成草稿。把整个循环放在同一环境里，比在付费运行时和笔记本之间来回搬文件省事。

先测闸门，再信闸门

一个永远通过的闸门比没有闸门更糟，所以要拿有已知答案的夹具验证它。如果第 2 个用例通过了，说明你的标记词表太窄；如果第 5 个用例毫无反应，过期说明会累积，并悄悄预批准未来的删除，而这正是这套闸门要防的失败。

局限与谁该跳过

这套闸门检查的是存在性，不是真理性：一条逐字复制进草稿、但已与代码矛盾的约束照样通过，只有人把页面和实现对照才能抓到。Markdown 上的句子切分是近似的，表格、嵌套列表和代码块都会让朴素切分器出错，标记词表也会对 required、should 这类词的日常用法产生误报。指纹只在归一化规则固定时稳定，改正则会让现有说明失效，应当在一个提交里连同重新生成的说明一起做。

如果你的文档完全由代码生成、从不手工编辑，跳过它，因为没有先前的人类约束集可保护。如果团队无法承诺为每次删除写一行原因，也跳过，因为人人都随手编辑的允许清单会变成橡皮图章。它最适合的场景是：少数页面承载真实的运维风险，而模型被期望持续重写它们。

先从最重要的两个夹具，也就是用例 2 和用例 3 开始，用在你手上最危险的那一个页面上。如果闸门在那里触发，你就找到了一次本会发出去的删除。