第 31 节 · Evaluation / Gate：没有闸门等于没有系统¶
闸门防的不是错字，是那种「看起来对、但没有来源」的话。这一节讲分级审稿与独立验证。
一、第一道门，装在走查之前¶
先说一件难看的事：这条门我立了规矩，但到今天也没跑出过一次真实分数。
总经理 agent 的走查协议里，装着一道比走查更早的门。当产品经理 agent 交来一份需求文档，总经理 agent 先不自己看，而是派出去一个独立的验证者——它在另一个上下文里，只看两样东西：这份文档，和文档自己承诺的验收标准。作者怎么想出来的、中间改了几稿、为什么这么写，一律不看。
判据是四个维度，各打 0.0–1.0：
- 方向是否一致
- 验收标准能不能测
- 有没有偷偷加需求
- 写出来能不能执行
三档处置：
| 总分 | 处置 |
|---|---|
| ≥ 0.8 | 放行，写走查记录，继续往下派 |
| 0.5 – 0.8 | 打回，附上具体缺口，重做 |
| < 0.5，或打回满 2 轮 | 上报，交给人裁定 |
为什么要把"打分的人"和"走查的人"拆开？因为一个人只要看过稿子是怎么生出来的，就很难再看结果本身。他会记得那句写得费劲的句子，会记得自己昨天为什么选了这条路。看着过程的人打不出公正的分，不是因为他偏心，是因为他已经知道了答案。
图 A-31-1（待出）：两道闸门在链条上的位置 —— 需求文档先过"独立验证门"，一路做成稿件，发布之前再过"分级审稿门"
同一份协议里还有一条反向约束，同样重要：只报影响正确性、方向、范围的缺口；报风格偏好的，直接驳回。 理由是——你要求一个评审者去找问题，他一定会找到，哪怕没有。这条约束是用来掐掉"为找而找"的。
现在说那句难看的话。这套四维打分、三档阈值的门，它的形态是规则，不是日志。到今天为止，主白板上的走查记录一共 16 份（同一白板归档案里的 10 份，是这 16 份中一部分的副本，不另计），我在里面翻不到一个真实的四维分数。所以这一节不能写成"这道门一直在跑、拦下过几份"——它是一条立好的规矩，不是一段跑出来的记录。这一节里凡是"跑过"的部分，我一条一条都给了数字；凡是没有数字的，就只能是规矩。
二、第二道门：把问题分成四级¶
需求文档过了第一道门，一路做成稿子，才轮到第二道。第二道门不判"好不好"，它做的是把问题分级。
审稿 agent 拿到的分级标准，全品类共用一套——小说、技术长文、短视频脚本，判的都不是"这是什么文体"，而是"这个问题会不会害人"：
| 等级 | 定义 | 动作 |
|---|---|---|
| P0 | 事实错误、设定矛盾、承诺不符、平台红线、代码或数据错误 | 阻断发布，必须修 |
| P1 | 关键缺失（概念第一次出现时没有解释）、密度不达标、开头前 200 字没有钩子、格式违规 | 修完才能发 |
| P2 | 类比不统一、开头可以更强、次要平台版本缺失、位置不理想 | 建议修，紧急时可发 |
| P3 | 风格偏好、新方向建议、措辞润色 | 记到下一轮 |
分完级，才轮到判定。这张矩阵是死的，不看心情：
| 情况 | 判定 | 动作 |
|---|---|---|
| P0 ≥ 1 | No-Go | 阻断，退回上游修改 |
| P1 ≥ 3 | No-Go | 阻断，退回上游修改 |
| P1 = 1–2 | Conditional Go | 先自动修掉 P1，再往下走 |
| 只有 P2 / P3 | Go | 放行，P2/P3 记入复盘 |
还有一条上限：回退最多 2 轮。第 3 轮仍然不过，不许再改，上报给人裁定。
分级的作用不是排序，是让"要不要放行"这个决定有据可依。一个只分"合格 / 不合格"的闸门，最后一定会退化成"差不多就行"——因为没有中间地带，任何一点小毛病都只能靠拍脑袋决定放不放。
同一条 P0，在不同文体里的长相完全不一样。所以矩阵判的是"会不会害人"，不是"这是什么文体"：
| 文体 | 会被判 P0 的 | 会被判 P1 的 | 只记 P2 的 |
|---|---|---|---|
| 技术长文 | 代码示例跑不通 | 概念第一次出现时没有解释 | 类比可以更统一 |
| 短内容笔记 | 数据造假 | 超出字数上限、没有收藏引导 | 封面可以更强 |
| 长文（另一平台版） | 核心数据写错 | 没有分段、结尾没有判断句 | 插图可以更有意思 |
注意三栏的分界：P0 是"发出去会出事"，P1 是"发出去会掉价"，P2 是"发出去也没事，只是不够好"。 一条闸门如果分不清这三件事，它要么把什么都拦住，要么什么都拦不住。
这里要诚实交代一句：矩阵里那条"P1 ≥ 3 单独触发 No-Go"，是写死的规则，没有实例。到今天为止，两张被打回的稿子，真正按下 No-Go 的都是那条 P0 ≥ 1。规则先立在那儿，等着它有一天被用上，或者被证明没必要——这两种结果都算数。
三、真实战绩：两篇稿，四次判定¶
到这一节写为止，按现在这套 P0–P3 分级、记录在案的，完整跑完的稿子只有两篇，一共判定了四次。
第一篇，一篇技术长文。 第一轮：P0 = 1 / P1 = 2 / P2 = 4 / P3 = 7 → No-Go。
那条 P0 是什么？我把两家公司的一次架构动作，写成了"同一个九月"。事实是：一家在 8 月动手，一家在 9 月动手，两件事隔了快一个月。
它被抓出来的方式，比它本身更值钱。审稿者没有相信我的正文，而是去翻原始技术报告，一页一页往回核，把那条时间断言连同它的证据一起拽了下来。加重的地方还有一层：那家公司的发布日期，本来就躺在稿子元数据块里的"未证实清单"中——清单上写着"未提具体日期"，正文却把它当成事实用了。
图 A-31-2（待出）：一次 P0 的抓出路径 —— 正文断言 → 回核一手报告 → 连证据一起打回
改完第二轮：P0 = 0 / P1 = 0 → Go。剩下的两条 P2 是措辞级的，当场内联修掉，没有再审。
第二篇，本书的序章。 第一轮：P0 = 1 / P1 = 5 / P2 = 6 / P3 = 7 → No-Go。那条 P0 是同一个数在稿子里出现了两个版本，其中一个已经是废数——它不会让读者觉得奇怪，它会让读者记住一个错的数。
第二轮：P0 = 0 / P1 = 0 → Go。新增 1 条 P2，但那一条是"交付完整性"（两份新落盘的证据件还没进版本库），不在正文里，不改变判定；其余是 11 条 P3，全部记到下一轮。
图 A-31-3（待出）：两篇稿、四次判定的严重度计数对照（P0/P1 从 ½ 与 ⅕ 归零）
两篇稿，四次判定，两次 No-Go。这个通过率很难看。
但它恰好是闸门工作过的证据。审稿的价值不在于它说了什么好话，而在于它把哪一条拽了下来。 第一条被拽下来的，往往不是"写错了"，而是"写得太顺了"——顺到没有人去问它那句话的来源在哪。
四、防漂移：先把稿子冻住，再开始审¶
第一轮审那篇序章的时候，出了个岔子。
审稿是要花掉一段时间的，而这段时间里，稿子在动。等审稿记录写完，回头去对行号，对不上——两份文件在那几分钟里被反复改了好几轮，正文、元数据、另一个平台版本，全在改。审稿记录按行号指认某一句话，可稿子一动，那个行号就不再指着同一句话了。
于是有了一条规矩：审稿前先冻结。逐份登记三样东西——行数、内容摘要值、最后修改时间；审稿记录里所有的行号，都按这个冻结基准算。谁在基准之后又动了稿子，就按清单逐条对账，避免"改一处、漂一处"。
第一轮冻结时，两份稿分别是 316 行和 358 行。第二轮复审时，冻结令已经生效：整个审稿窗口内，两版零改动，复审记录开头第一件事就是核对摘要值——对上了，判定"未漂移"，才开始审。
不冻住基准，审稿就变成打地鼠：你改一处，我审一处，谁也不知道最后发出去的是哪一版。审一份会自己动的稿子，像在水还在流的时候量水位。 冻结基准这一步，是审稿里唯一一件对读者完全不可见、却决定这次审稿算不算数的事。
五、闸门自己也会失效¶
上面两座闸门管的是稿子。但闸门这东西，自己也会坏。
早会每天要定不超过 3 件当天必办的事（Top3）。9 月 1 日定下的 Top3，到 9 月 10 日，三项全部没有闭环。整整 9 天，没有一次对账。
这件事的定性，我记下的原话是：这是结构性治理缺陷，不是偶发。"偶发"可以怪运气，"结构性"只能怪设计——设计里根本没有那道对账的门。
同一天立的规，三条：
- 每条 Top3 必须带 owner + 可验收的完成信号。 完成信号必须是能查证的客观事实——文件、链接、数字、提交记录。禁止"推进中""已安排"这类说法；没有完成信号的条目，不许进 Top3。
- 次日开会第一件事，逐项对账。 先报上一次每条的"已闭环 / 未闭环"，对完账再进常规汇报，对账结果写进当天记录。
- 未闭环必须说明原因并升级。 卡在哪一步、谁负责、已经拖了几天；超出原定信号 1 天即升级，不得静默顺延——要顺延，必须显式记档。
注意这三条的形状：第一条是"入口闸"，第三条是"出口闸"，第二条是"每天验一次水位"。一套闸门该有的东西，在这三条里齐了。
闸门失效的表现，通常不是"拦不住"，而是"根本没人来开"。 一个只写在纸上的对账制度，和一座从不打卡的闸门是同一种东西——它站在那里，让所有人以为有人在看着。
六、为什么一个 AI System 需要 Evaluation / Gate¶
把这一节挂回那条链上：
模型 → 小模型 → 模型池 → 路由 → 上下文 → 知识 / 记忆 → agent → Harness / 状态 → Evaluation / Gate → 闭环 / 反馈 → AI System
前面每一个零件都在回答同一个问题：怎么把活干成。 Harness 回答"跑一半崩了怎么办"，路由回答"这活派给谁"，上下文回答"开口之前要读多久"。
Evaluation / Gate 回答的是另一半，而且是一个更不受欢迎的问题：怎么让错的活干不成。
它是这条链上第一个会"往回说话"的零件。前面所有零件都在把东西往前推，只有它把东西往回推；而且它往回推的理由，不许是"我觉得不好"。得是能复述的判据：四个维度的分数、四级严重度、一张判定矩阵、两轮上限。没有这几样，闸门就不再是闸门，只是个人口味。
这就是为什么"闸门防的不是错字"。错字谁都能防。真正要防的是那种读起来通顺、逻辑自洽、语气笃定，但你追不到来源的话——它不会让稿子变难看，它会让稿子带着一个错的结论，被发到所有人眼前。
一个没有闸门的 AI System，不是系统，是一条只会往前冲的传送带——它跑得越快，把错的东西送得越远。
数据与出处¶
- 总经理 agent 走查协议：走查前的独立验证门（独立上下文、只看文档与验收标准、四维 0.0–1.0 打分、三档阈值、只报影响正确性/方向/范围的缺口）
- 审稿 agent 分级标准：P0–P3 定义与判定矩阵（P0≥1 或 P1≥3 → No-Go；P1 1–2 → Conditional Go；回退上限 2 轮，第 3 轮上报）
- 两篇稿（一篇技术长文、一篇本书序章）的完整审稿记录各两轮（含两次 P0 打回；其一：两家公司的架构动作被写成同一个月，经原始技术报告逐页回核抓出）
- 冻结基准登记表（行数 + 内容摘要值 + 最后修改时间；含一次审稿窗口内的漂移事件——稿子在审稿期间被反复改动）
- Top3 决议闭环节的立规记录（9 天未闭环、定性为结构性治理缺陷、次日对账起生效）
- 走查记录存量清点：主白板上 16 份走查记录文件（同一白板归档案中的 10 份为其中一部分的副本，不另计）