同一份文档让AI写两遍，差异最大的地方才是人该看的地方

把模型起草的文档从头到尾逐行审一遍，是默认做法，也是最浪费人的做法。一页文档里大部分行只是格式习惯，不承担风险；真正决定读者会不会搞崩生产环境的，只有少数几行。与其让一个人均匀地怀疑每一句话，不如把同一个生成任务跑两遍，在块级别做差分，让差异告诉你人的注意力该落在哪。

这套方法搭起来便宜，跑起来无聊。它不需要一套断言分类法，不需要政策文档，也不需要审核人先给句子分类再读。它只产出一个东西：一份账本，记录哪些起草块在两次运行间保持稳定，哪些发生了摇摆，哪些是凭空造出来的。

为什么差异是一个有用的归属信号

单次生成只给你文本，不给你任何关于模型对哪部分有把握的信息。每一句话都以同样的权威感抵达，审核人只能把怀疑预算平摊到整页。这个预算是错配的——一句讲标题层级的话和一句讲重试语义的话，不该享受同等程度的审视。

跑两遍能浮出单遍给不了的信号。逐字节存活的块是模型的稳定习惯，通常是措辞、结构和格式。两次之间发生变化的块，是模型没有可靠答案的地方，也正是这页文档真正悬而未决的地方。第二遍不是用来平均的投票，而是一根探针。

这把常规操作顺序倒了过来。不是让人先分类再阅读，而是机械地测量稳定性，再把不稳定的材料路由给人。审核人的判断力花在能改变结果的地方。

测量之前先定义单位

句子级差分产生噪声，因为从句顺序和标点会因为不携带信息的原因抖动。标题级差分又太粗，一个稳定章节里只要有一句不稳定，就会消失在及格线里。挂在最近标题下的段落块是实用的单位：小到能指派给一个负责人，大到一次重写能登记为单次变更。

要明确这是分诊，不是验证。一个自信的错误块可以在两次运行间完美稳定，一个平凡正确的块也可能因为模型换了措辞而摇摆。差异告诉你先看哪里，它从不告诉你什么是真的。

脚本把每一遍按标题切块，用 difflib 跨两遍对齐，把每一对分类为 STABLE、WOBBLE 或 UNSTABLE。它写出 JSON 记录供审阅，加上 --gate 参数时，一旦出现不稳定块就在 CI 里以非零码退出。调用时把两份保存的输出喂进去，JSON 放在消费它的那个 PR 旁边。

报告长这样。下面这些值来自一个合成的双遍夹具，用来跑通分类器的每个分支；它们演示输出格式，不是对任何模型的测量。

• STABLE 1.000 Authentication
• STABLE 1.000 Error codes
• WOBBLE 0.884 Rate limits
• UNSTABLE 0.412 Migration order
• UNSTABLE 0.000 Deprecated flags
• {"STABLE": 14, "WOBBLE": 5, "UNSTABLE": 2}

六步工作流

1. 冻结生成输入。提示词、源快照、工具版本、任何检索语料，全部进一个摘要。两遍必须消费同一个摘要，否则你测到的是输入漂移，不是模型不确定性。
2. 两遍在同一环境里跑。不同的运行时版本、区域设置或依赖时钟的上下文，会注入与模型无关的差异，而且会落进你的 UNSTABLE 桶。
3. 切块并对齐。跑上面的账本脚本，把 JSON 和草稿分支一起提交。半年后的审核人没有这份记录，就无法重建某个块为什么被升级处理。
4. 在自己的页面上校准阈值。默认的 0.97 和 0.80 是起点，不是验证过的常数。调到 STABLE 对应的是你不细读也会接受的文字为止。
5. 把每一类路由给不同的负责人。STABLE 块作为起草文字进入草稿 PR。WOBBLE 块交给章节负责人，两个版本并排展示。UNSTABLE 块由人重写，而不是再生成第三遍。
6. 对不稳定数量设门禁，而不是对总差异设门禁。不稳定数量缓慢上升，通常意味着源事实正在页面底下漂移，这首先是文档问题，其次才是审核问题。

两遍意味着生成调用翻倍，这是这套流程最主要的现实反对意见。MonkeyCode 的免费模型访问消除了第二遍的边际成本，它的免费服务器选项让两遍能在同一个环境里跑，环境漂移就不会被记成模型差异。披露：本文是作为 MonkeyCode 产品推广的一部分准备的。那两条可用性事实由运营方提供；这里不应被读作关于配额、硬件、模型身份或持久性的任何主张，依赖之前请核实当前条款。

采用前应当接受的局限

稳定不等于正确，而一旦账本开始输出绿色行，这两件事很容易混淆。一个写着重试是幂等的块，无论真假，在两遍里都会读起来一模一样。对必须被拥有而非被测量的事实，保留一套单独的机制，因为差异对准确性没有意见。

对齐逻辑刻意简单，因此脆弱。某一遍重命名了标题或重排了整个章节，会产生零分行，看起来像不稳定，实际是结构性分歧。比较前先归一化空白和代码围栏，把同一标题下反复出现的零分当作检查提示词而非输出的信号。

即使生成免费，开销也是真实的。得有人冻结输入、存两份输出、跑账本、读 JSON，而在一个两段的页面上，这些开销超过价值。这套流程在长参考页上才划算——那里一个错误块就带来运维成本。

谁不该用这套方法

如果团队里唯一的审核人本来就会在发布前读完每一页的每一行，那这里什么也得不到，因为路由这一步重复了他们已经在做的事。以捕获的命令输出和日志为主的页面，几乎没有起草文字可分类，账本会报出一个舒服的全 STABLE 结果，而它毫无意义。

受监管或合同类内容，无论稳定性如何，每一条断言都应保留一位署名的人类作者，因为这里的问题是问责，不是模型一致性。最后，如果你无法固定生成输入，就完全跳过这套方法，直到你能固定为止，因为无法归因的差异比不测量更糟。

产物本身就是论据，所以把 variance.json 附在草稿 PR 上，让记录下来的分数向接下来审阅的人解释路由。如果你想不花第二遍生成的钱就端到端复现这套双遍账本，免费模型访问和免费服务器选项，足够在你自己的某页真实文档上试一遍。