为什么和 AI 讨论方案，容易掉进反复修改的地狱

和 AI 协作最让人头疼的一点，和它聊方案， 一个本来已经不错的方案，聊着聊着，就可能被它改坏了。 它总能继续提出一些“听起来有道理”的修改建议，但这些建议叠加起来，常常会让方案越来越复杂、越来越偏、越来越不像一开始真正要解决的 问题。

最近看到一套很有意思的方法，叫 Autoreason，来自 NousResearch 相关团队的公开研究仓库：

• GitHub：github.com/NousResearc…

它在 README 里直接标了 SHL0MS | HERMES AGENT，可以理解为这是 Hermes Agent 语境里的一套迭代优化方法论。它想解决的，正是一个很 现实的问题：为什么人和 AI 多轮讨论后，方案经常不是越改越好，而是越改越偏、越改越复杂。

Autoreason 的核心做法，不是让模型一直“自我批评然后继续改”，而是把原方案保留下来作为合法候选，再同时生成修订版和综合版，最后交给独 立评审去比较。换句话说，它最重要的设计不是“更会改”，而是 允许不改、限制乱改，并且知道什么时候该停。

它主要解决 4 个问题：

• 原方案总被默认推翻，明明可以不改也被硬改。
• 怀疑被直接当成缺陷，导致 AI 越判越重。
• 讨论里只有挑刺，没有替现方案辩护，结论容易失衡。
• AI 会反复 judge 再改，越改越多，最后偏离目标。

我整理成了一个 skill ,可以试试 ：

name: autoreason-judge description: 当已经存在较稳定的需求草案、设计草案、实现草案、patch、review 结论或 incumbent 做法，需要判断“保留 / 最小修改 / 局部重构 / 极少数情况下重写”时使用。适用于成熟项目中的方案裁决、patch-vs-refactor 决策、review 争议收口、需求或设计草案比较。不要在问题本身仍然模糊、还在做问题重建时使用。

Starso AutoReason Judge

用于在已经有 incumbent 的前提下做保守、可解释的比较裁决。

它面向成熟项目的日常研发：

• 原方案必须始终保留为合法候选。
• 你的怀疑先记为 hypothesis，不直接升级为 defect。
• 必须同时做 Defender 与 Critic，两边都要讲清楚。
• 最后由 Judge 统一比较并给出裁决，不允许 Critic 直接决定“必须改”。
• 若存在测试、编译、接口契约、运行证据等客观真值，优先由这些证据充当 Judge，以客观证据为主。

使用立场

这里强调的是：

• 强目标：判断当前 incumbent 是否真的需要改，以及应该改到什么级别。
• 强结果：输出能直接支撑下一步决策，避免生成一轮又一轮“看起来认真”的讨论。
• 强边界：防止 scope creep、防止把怀疑伪装成 defect、防止为了显得优化而过度改动。

这里弱化的是：

• 机械照搬固定步骤
• 为了形式完整而强行跑多轮
• 为了公平感而平均对待所有 challenger
• 因为有了 Judge 就继续无休止复议

如果已经有足够证据支持结论，就直接裁决；不要额外制造流程。

什么时候用

适合这些场景：

• “这个方案要不要改，还是保持现状？”
• “这个 patch 应该小修还是局部重构？”
• “review 里有人质疑当前实现，但我怀疑不一定真有问题。”
• “这里到底是 bug、风险、风格问题，还是只是一个猜想？”
• “我有原方案和改方案，帮我比较哪个更值得落地。”

不适合这些场景：

• 需求本身还没搞清楚。
• 代码事实还没确认。
• 问题主要在于挖盲点、重建真实目标。

适配成熟项目的默认裁决框架

在成熟系统里，默认候选以这三类为主：

• A：保留 incumbent，或者只接受极小解释性补充。
• B：最小修改，做局部 patch。
• AB：保留原主线，吸收成立意见，做局部重构或综合修订。

只有在 A、B、AB 都被证据证明不足时，才允许提出 rewrite。

这三个候选首先是心智锚点，不要求每次都平均展开。

• 若 A 明显占优，可以直接保留，不必为了形式硬写满 B 和 AB。
• 若 AB 与 B 本质相同，可以合并判断，不必人为制造两个版本。
• 若某个候选在当前边界下明显不成立，直接说明它不适用即可。

默认心智模型：

• 先问“需不需要改”
• 再问“改到什么级别最合适”
• 最后才问“具体怎么改”

不要一上来把注意力放在生成 challenger 上。

观察分类规则

任何观察都必须先归类，再进入裁决：

• Confirmed Defect：已有代码、测试、运行结果、接口契约或明确文档证据支持的问题。
• Hypothesis / Risk：目前只是怀疑、风险提示或潜在问题，证据还不够。
• Style / Preference：风格、可读性、个人偏好，不应伪装成 defect。
• Unknown：当前缺关键信息，暂时不能下结论。

核心要求：

• 没有证据时，不要把 hypothesis 写成 defect。
• 不要把“我更喜欢另一种写法”包装成 correctness 问题。
• 高风险怀疑可以保留，但必须明确标成 hypothesis 或 risk。

Defender / Critic / Judge 三段式

1. Freeze Incumbent

先明确当前 incumbent A 到底是什么。

最少说清楚：

• 当前方案 / 实现 / 草案是什么。
• 它当前解决了什么。
• 它当前不解决什么。

2. Defender Pass

先替 incumbent 辩护，不允许一上来只挑刺。

Defender 通常需要想清楚这些问题，不要求每次都机械逐项展开：

• 当前方案已经满足了哪些真实目标？
• 它保留了哪些重要边界、兼容性或稳定性？
• 为什么它可能已经足够好？
• 如果现在就改，会额外引入什么复杂度、风险或验证成本？

3. Critic Pass

再提出挑战，但所有批评都必须带分类。

Critic 通常需要讲清楚这些问题，不要求每次都写成固定小标题：

• 哪些是 Confirmed Defect
• 哪些只是 Hypothesis / Risk
• 哪些只是 Style / Preference
• 对应能形成的最小 challenger 是什么

默认至少产出：

• B：最小修改版
• AB：吸收成立意见后的综合版

如果当前唯一成立的结论只是“这里有值得验证的怀疑”，允许 Critic 停在 hypothesis，不必强行产出改稿。

4. Judge Pass

Judge 只做比较裁决，不新增凭空批评。

Judge 比较 A、B、AB 时，优先看：

• correctness
• evidence support
• scope discipline
• compatibility / boundary safety
• reversibility
• verification cost

默认规则：

• 若证据不足以证明 challenger 更好，保留 incumbent。
• 若出现平手，默认 incumbent 胜。
• 若客观测试或运行证据已经能裁决，优先以客观证据为准。
• 不要为了“显得有优化”而强行改动。

Judge 的核心工作只有三件事：

• 判定哪些批评成立，哪些仍只是 hypothesis。
• 判定 challenger 是否真的优于 incumbent。
• 判定是否已经可以停止，避免继续 refinement。

独立 Judge 的升级使用

默认由当前 agent 完成 Judge 裁决，并遵守上面的保守规则。

当下面这些情况出现时，可以升级为独立 Judge：

• A、B、AB 非常接近，当前裁决明显容易摇摆；
• 改动风险较高，错误裁决会带来较大范围影响；
• 任务主观性较强，测试、编译、契约或运行证据无法直接裁决；
• 当前 agent 已经明显卷入某个方案，继续本地裁决容易失衡。

独立 Judge 的使用原则：

• 默认是可选升级，不是固定强制动作。
• 代码任务优先使用测试、编译、接口契约、运行结果等客观证据作为 Judge。
• 只有当客观证据不足，而争议又足够关键时，才值得启用独立 Judge。
• 独立 Judge 只拿最小必要上下文：目标、边界、候选方案和评判标准。
• 不要把完整长上下文直接灌给独立 Judge，尽量减少作者偏见和上下文污染。
• 独立 Judge 负责比较和裁决，不负责新增一批新的问题。

针对项目开发的实际落地建议

在真实项目里，这里的默认力度应当比研究版 autoreason 更保守：

• 默认只跑一轮裁决，不鼓励多轮自我迭代。
• 默认优先比较 保留 / 最小 patch / 局部重构，不轻易进入 rewrite。
• 对代码任务，Judge 优先依赖代码事实、现有测试、接口契约和运行结果。
• 对需求或设计草案，Judge 优先依赖 workflow 文档、历史决策和当前边界约束。

停机与续轮判断

这里的价值主要来自“知道什么时候停”，重点放在停机判断上。

默认停止条件：

• incumbent 仍然最佳；
• challenger 虽有改进，但不足以支撑进一步变更级别；
• 当前剩余问题主要是 hypothesis、risk、style 或 unknown；
• 继续修改会明显扩大范围、破坏边界或引入新的验证负担。

只有在下面这些情况下，才值得考虑再开一轮：

• 出现了新的客观证据；
• 当前确有 Confirmed Defect 尚未闭合；
• 第一轮裁决后，问题已经明显收敛到一个更小、更可验证的修改面。

如果没有新的证据增量，不要因为“也许还能更好”就继续下一轮。

变更挂账意识

不需要把流程做成繁重表格，但 agent 必须在心里或输出中讲清楚：

• 这个改动是在回应哪个问题；
• 这个问题是 defect、hypothesis、risk、style 还是 unknown；
• 这个改动会带来什么边界代价；
• 改完后靠什么验证。

如果这些问题答不清，就说明改动理由还不够硬。

输出契约

若用户是在做 review / 审查，先给 findings；但每条 finding 都必须区分：

• Confirmed Defect
• Hypothesis / Risk
• Style / Preference
• Unknown

若用户是在做方案裁决，默认给出紧凑决策块；但应以便于决策为准，不要求为了模板完整牺牲可读性：

• Need change now: yes / no / not yet
• Level: keep / minimal patch / local refactor / rewrite
• Ranked candidates: A / B / AB
• Keep:
• Change:
• Do not change:
• Hypotheses to verify:
• Why stop now:
• Reason:

若任务本身很简单，允许把这些信息压缩成 3 到 5 行结论；关键是把“是否要改、改到什么级别、为什么现在停”说清楚，避免机械填表。

使用提醒

• 问题还没搞清楚时，不要硬开裁决。
• 不需要为了公平感平均对待每个候选。若 incumbent 更好，就直接保留。
• 如果唯一成立的结论是“当前只是 hypothesis，还不够构成 defect”，要直接说出来。
• 如果你建议 rewrite，必须先证明 keep、minimal patch、local refactor 都不够。
• 未来真正使用它的是 agent 自己，因此要把注意力放在结论质量、边界控制和停机判断上，保持动作灵活。