用同一模型写实现计划、再交给另一个模型评审，往往能挑出一堆问题；把意见回给原模型，它又全部认同。这到底是评审有效，还是模型只会顺着说？文章梳理这种现象背后的信息折损、边界缺失和评审无限扩展问题，给出冷启动评审、问题分级、收敛条件与任务拆分的具体做法，并说明同模型自审与换模型评审各自适用的场景。
让模型 A 写一份实现计划，再交给模型 B 评审，B 挑出一堆问题；把 B 的意见原样丢回给 A，A 表示「说得都对，我改」。这个循环跑上几轮，计划越来越长，问题却始终不见减少。于是很自然会产生疑问：让同一个模型自己写、自己审，到底有没有意义？是不是非得换成另一个模型才靠谱？
先给结论：有意义，但它解决的不是同一个问题
两种做法并不互斥，它们覆盖的是不同的失败模式。
- 同模型自审：成本低、上下文连续，能发现遗漏、前后不一致、与需求脱节的地方。但生成时用过的假设会被带进评审，盲区是共享的。
- 换模型评审：相当于换一套训练分布和偏好，容易看到「另一个方向」的错。但它是「换一种方式出错」，并不等于「不出错」，也可能给出看起来专业、实际不该采纳的建议。
真正决定评审质量的，往往不是换不换模型，而是：评审方有没有拿到干净的上下文、评审范围有没有边界、输出有没有被分级、循环有没有终止条件。
为什么评审会越做越长、越改越乱
常见的几种成因，基本都能在原帖的现象里对上：
- 信息折损：计划本身是对需求的压缩，评审时上下文进一步丢失，评审方看到「这里没写清楚」就会当成缺陷，于是每轮都能挑出新的问题。
- 缺少边界：没有写「不做什么」和验收标准，评审自然从「这个功能怎么实现」扩展到「整体架构应该怎样」，一个小功能的计划最后变成完整架构设计。
- 评审 prompt 没有约束：不要求分级、不限制条数，模型倾向于把所有能想到的点都列出来。
- 意见被全盘吸收：每条建议都改，计划膨胀，下一轮又产生新的评审面，形成正反馈。
- 上下文超限：长会话里早期的决策和约束被挤出窗口，模型开始基于残缺记忆评审。
可操作的改进方案
1. 按阶段分层，而不是全流程用同一种评审
| 阶段 | 建议做法 |
|---|---|
| 需求与架构 | 强模型起草 + 人工确认边界与验收标准 |
| 计划拆解 | 模型自审 + 一次独立评审，重点看遗漏与依赖顺序 |
| 代码实现 | 模型自审 + 足够测试用例，评审聚焦可验证的缺陷 |
架构阶段值得投入最强的模型和最多的人工时间；到了实现阶段，测试比评审更可靠。
2. 让评审「冷启动」
评审失效最常见的原因不是模型不行，而是评审方看到了生成过程，被同样的思路带着走。可以这样做：
- 新开一个会话或子任务，只提供：需求、计划正文、验收标准、约束条件，不提供历史讨论和生成过程。
- 需要交叉验证时，再开一个独立评审，比较两份报告的交集——交集部分通常才是真问题。
- 让评审方先用自己的话复述目标和非目标，再开始挑问题，能显著减少凭空臆测。
3. 把边界写进计划本身
一份能被稳定评审的计划，至少包含：
- 目标：这次要交付什么可观察的行为
- 非目标：明确不做哪些事，防止评审扩展范围
- 改动范围：允许动哪些模块、接口、配置
- 验收标准：怎么判断做完了
- 约束：性能、兼容性、不允许引入的依赖
4. 给评审输出定级并限制数量
在评审指令里直接写死格式，比事后筛选更省事：
你是独立评审者，只阅读下面的计划，不要假设作者的历史讨论。
请只输出会导致返工或线上故障的阻断性问题，最多 5 条。
每条格式：
- 级别：blocker / should / nit
- 问题：一句话
- 不修的后果：具体到什么场景会出什么错
- 最小修复建议：不超过两句话
不要提出范围扩展类建议，不要重写计划。
拿到报告后按级别处理：blocker 必修，should 视成本决定，nit 记下来但不改。
5. 设定收敛条件
无限循环几乎都源于没有停止规则。可以定几条硬规则：
- 连续两轮评审没有新增 blocker，即视为收敛，进入实现。
- 同一处被反复提出但无法给出「不修的后果」的意见，直接丢弃。
- 每轮记录问题数量与级别，如果问题数只增不减，说明问题出在边界定义，而不是计划质量。
- 计划篇幅在两轮内明显膨胀时，回退到上一版而不是继续叠加。
6. 拆分任务，控制单个会话的上下文
把计划拆成互相独立、可单独验证的任务，一个任务一个会话，避免长会话里上下文被稀释。计划文件保持精简，把细节放到任务级说明里，而不是堆在一份大文档中。如果评审循环需要长时间连续运行，本地机器休眠、网络抖动都可能中断会话，可以考虑放到长期在线的远程 Mac 上执行，让评审在独立会话里稳定跑完——这只是环境层面的一种省心做法，不改变前面这些流程要求。
同模型自审和换模型评审，怎么选
- 只有资源跑一个模型：同模型自审仍然值得做，但必须冷启动、改角色、限定输出，否则只是在重复自己的假设。
- 对正确性要求高、且你能判断意见真伪：用不同模型交叉评审，取交集，收益最大。
- 对领域不熟、无法判断意见真伪：慎用互评。模型很擅长「找出可以挑的地方」，不擅长判断「值不值得修」。此时更稳的做法是固定检查清单 + 补齐测试，而不是无限评审。
- 后期分支多、改动面大的项目：互评成本会快速上升，尽早收敛到「测试 + 人工抽查」。
注意事项
- 评审意见不等于缺陷。每条意见都应能回答：不修会出什么故障、谁受影响、能否用测试覆盖。答不上来的一律降级。
- 模型认同你的修改建议，不代表建议正确，只代表它在顺着对话走。判断标准要放在外部：验收标准、测试结果、可复现的失败场景。
- 计划膨胀是比遗漏更常见的损失来源。范围一旦扩大，评审成本和实现风险同步上升。
- 不同模型之间的差异是视角差异，不是正确性保证。把它当成「多一个审稿人」，而不是「多一个裁判」。
小结
同一个模型写计划、自己评审，有意义，但它的价值在于低成本的自我检查，不能替代独立视角。想真正提升质量，重点应放在四件事上：给计划划边界、让评审冷启动、给意见分级限量、给循环设终止条件。做到这四点，同模型自审和换模型评审都能用；做不到，换再多模型也只是把同一个循环重跑一遍。