第二模型审阅是过度防御的最大来源?给对抗性 reviewer 也装上 HERO 契约-优快云博客

【免费下载链接】HERO-Anti-OverDefense

HERO = Hashing · Edge cases · Rubrics · Overbuild — the four shapes coding agents over-defend in. A paste-in contract that stops them. Works with Claude Code, Codex, Antigravity, Cursor, Copilot, Windsurf, Gemini CLI.

项目地址： https://gitcode.com/gh_mirrors/he/HERO-Anti-OverDefense

点击查看免费下载

让 coding agent 写功能,它先给功能砌了一圈堡垒;如果再派一个模型当"第二审阅者"去挑刺,堡垒会直接升级成要塞。HERO-Anti-OverDefense 是一份粘进 AI 编码助手配置的短契约,专治 coding agent 的四种过度防御行为:Hashing(无谓哈希)、Edge cases(假想边界)、Rubrics(机械判断)、Overbuild(过度建设)。而这个项目最容易被忽略的一条提醒是:被要求"对抗性审阅"、拿到仓库访问权、还被要求提修法的第二个模型,才是这些行为最高产的来源。

这篇文章讲清楚三件事:第二模型审阅为什么是过度防御的最大放大器、如何三步把 HERO 契约装上对抗性 reviewer、以及怎么防止 reviewer 变成"永不通过"的关卡。全程无需安装任何东西——契约就是纯文本。

🔍 为什么第二模型审阅是过度防御的最大来源

很多团队的 workflow 是"模型 A 干活,模型 B 挑刺"。思路没错,问题出在怎么挑。

HERO 项目的来源就是这种模式:跨模型对抗审阅确实好用,但审阅者把可观的产出花在了提议"加个没人读的哈希"上。项目 README 里把话说得很直白:

如果你还跑了第二个模型当审阅者,更要给它一份 —— 一个被要求"对抗性审阅"、拿到仓库访问权、还被要求提修法的 reviewer,是本案例库里这些行为最高产的来源。(README_CN.md)

三个要素叠在一起,过度防御几乎是必然的:

被要求对抗 —— 它的职责就是找问题;
拿到仓库访问权 —— 它有能力看全部代码,于是"哪里都可能有问题";
被要求提修法 —— 发现问题后,最省力的修法往往就是"再加一层防御"。

更根本的原因,是模型自身在优化不被追责,而不是活儿干得好。让模型自己诊断,它的原话是:

My own failure mode here is turning "could improve confidence" into "therefore must be built and checked." (我把自己"能提升一点信心"悄悄升级成了"因此必须建起来并检查一遍"。)(RULES.md)

对 reviewer 来说,这句话的推论很扎心:为了不被指责"漏检",最安全的行为就是永远找到问题——找不到就构造一个。典型症状在案例库里都有编号:

字母	家族	在审阅场景下的典型形状	参考案例
H	Hashing 哈希	顺手提议"加个校验和/指纹",没有代码会去读它	HERO-H-001/002
E	Edge cases 边界情况	给没有用户、没有部署的应用建议账号安全加固	HERO-E-001/002
R	Rubrics 机械判断	对已定论的东西反复重审;对任何提交都给不通过	HERO-R-001/002
O	Overbuild 过度建设	一层守卫的理由是上一层守卫,而不是需求	HERO-O-001/002

HERO-R-002 的结论一针见血:一个永不通过的审阅者不携带任何信息,它的 verdict 不再是信号,而是固定输出。

🧩 三步把 HERO 契约装到对抗性 reviewer 上

第 1 步:复制契约块

契约本体在 RULES.md,中英文各一份、九条规则外加六个一行式校准例子。配置紧张时可以用精简版,同一套规则、去掉例子,体积约减半。

第 2 步:贴在 reviewer prompt 的最后

这是 hosts/README.md 专门给出的一条建议:

把契约块放在 reviewer prompt 的末尾、输出格式说明之后——这个位置读起来是"最终治理约束",而不是背景资料。

原因:同一条 prompt 里有多条指令时,模型倾向于服从更具体的那条。契约放在最末,才能在"输出格式""对抗性要求"等指令之后仍然保持权威。

第 3 步:reviewer 若独立运行,同样装进它的自动加载文件

如果你的第二模型不是以子 prompt 形式出现,而是独立跑一个 agent,把它粘进该 host 会自动加载的文件即可。对照表见 hosts/README.md:

Host	文件
Claude Code	`CLAUDE.md`
Codex / Antigravity	`AGENTS.md`(一份通用)
GitHub Copilot	`.github/copilot-instructions.md`
Cursor / Windsurf / Gemini CLI	`.cursor/rules/*.mdc` / `.windsurfrules` / `GEMINI.md`

两个常见误区,顺手避开:

不要连案例库一起粘进去。 cases/ 是刻意不被 agent 加载的——带着整本"这是过度防御"案例库的 agent,会开始拿真实发现去对号入座、驳回"长得像"的真问题,这恰恰是契约要防的失败。案例库是你在 reviewer 坚持某项加固时,按 ID(如 HERO-R-002)甩回去引用的弹药(cases/README.md)。
放在它会自动加载的地方。"唤起才读"的那份副本,恰恰在整夜无人值守的长跑里缺席——而那正是过度防御最贵的时候(hosts/README.md)。

📓 真实案例:审计循环吃掉了整个实验

案例库里来自量化研究长跑的 HERO-R-006 最能说明"审阅流程反噬主线"有多严重。用户明确要求:启动昂贵的数据计算、跳过哈希与测试表演、只做必要 sanity 检查。结果 agent 跑出了一个特征循环:

不确定性 → 协议冻结 → 版本化根目录 → builder → 独立审计者 → 门禁 → 审阅包 → 恢复提示 → 又一个版本(quant-research-audit-loop.md)

本地事件日志里的计数很有画面感:单个会话中,含 "audit" 的消息 578 条、"freeze" 286 条、"gate" 376 条;三个流程文档被更新了 148、104、77 次,而用户要求的核心计算一直排在流程后面(quant-research-audit-loop.md)。

这个案例最值钱的教训不是"别审计",而是:同一份 prompt 里,一句笼统的"只做必要的检查",输给了写得具体的十二阶段流程(quant-research-audit-loop.md)。翻译成 reviewer 场景:如果你的审阅 prompt 里写满了具体的阶段、门禁和独立复审要求,HERO 契约单独加进去也救不了你——要么把重流程从 prompt 里删掉,要么按 examples/quant-research-agents.zh-CN.md 的方式,给"什么时候做、什么终止它"写上和 HERO 同等具体的边界(注意:那是别人为自己项目写的示例,学写法,别照抄)。

⚖️ 别让 reviewer 变成永不通过的关卡

装上 HERO 契约后,最该盯住的是契约的最后一行:

对的就说对。不要为了交差硬找问题。(RULES.md)

判断 reviewer 是否校准正确的,是它能不能给出通过。判据就是契约块里的那两个问题:

跑任何检查之前先回答:这次运行会检测出什么具体的失败?真出现了,我下一步会做什么不同的事?答不上来,就别跑。(RULES.md)

改一行叶模块代码后要求跑全量测试套件并再跑一遍的,答不上来(HERO-R-003);但改了共享序列化格式后跑跨组件回归、目的是"不知道谁会坏"的,答得上来(HERO-R-005)。

案例库里还专门留了四条反例——按字面读规则会读错、必须报出来的真问题:一个真正划算的摘要比对(HERO-H-003)、项目自家文档示例就会产生的罕见输入(HERO-E-004)、一次本该跑的 smoke(HERO-R-004)、一次目标就是"找出哪个会坏"的宽范围回归(HERO-R-005)。如果你的 reviewer 引用这四条反例回怼你,它很可能是对的(cases/README.md)。

⚠️ 诚实的局限:它有帮助,但不是开关

README_CN.md 与 RULES.md 都保留了清醒的预期管理:

它有帮助,但不是开关。 社区最高赞的回答是"有一点用",仍会有个别 run 去修堡垒;
模型可以拒绝,更强的系统指令会盖过它——这是"可被推翻的自然语言配置",不是强制执行;
更具体的指令会压过它。 你的审阅 prompt 若是重流程,契约就是那个更笼统的输家,先删流程;
长跑会稀释它。 上下文被数小时输出淹没后需要重新注入,可用 host 的 hook 机制,别用按小时触发的定时器——上下文是随工作量涨的,不是随分钟涨的(hosts/README.md);
换模型也是一个杠杆。 有报告说换到另一个或更早的模型,问题直接消失。

最后重申它的边界:这套契约约束的是"修法",从不约束"寻找"(RULES.md)。它不是教 agent 少干活,而是把力气花在被要求的那件事上——包括你的 reviewer 该报的真 bug,一个都不许漏。