一、为什么要换一家来审

同源的模型审自己写的代码，通常只做两件事：确认结构没错、把措辞改顺。这是训练目标决定的——它更擅长"让输出看起来合理"，而不是"证明输出有缺陷"。

所以做独立评审时，一个有效的做法是：换一个厂商的模型当评审员，并且明确告诉它——你和作者不是一家。

二、四条硬约束，缺一条就失效

输出契约的价值在于可自动化：结论是一行固定格式，机器才能据此卡住合并流程。没有这一行，评审再认真也只是聊天记录。

三、契约的三个细节

• 标记只能出现一次，且必须在最后一行。否则脚本解析时会被正文里的重复标记干扰。
• 用裸词，不加反引号、不加粗、不加方括号。格式噪声会让解析失败。
• 先写评审，再写结论。顺序反了，模型会先定调再找理由。

四、一条发现该怎么写

要求评审结果必须包含四要素，缺一不算有效发现：

1. 文件与行号——能定位。
2. 严重程度——区分阻断与建议。
3. 具体缺陷——说清错在哪，不是"建议优化"。
4. 根因修复方案——不是绕过症状。

如果确实没有问题，就让它明说"没有发现问题"。这一条很重要：不允许为了显得认真而硬凑意见，否则评审会退化成噪声。

五、这类做法能用到哪

• 代码合并前：作为人工评审前的一道自动闸门。
• 合同/方案审阅：同样可以设"独立评审 + 固定结论行"，让 AI 只输出"可签 / 需修改"。
• 自己写的东西：换一个模型当读者，比让同一个模型自查有效得多。