AI 写完又审、一周还在修 P1：评审死循环怎么收敛
用 AI 从零写一个不熟悉领域的工具，再让模型反复评审，很容易陷入「审出问题—修—再审出新问题」的死循环。这篇文章分析循环停不下来的几个真实原因（缺少验收标准、同模型自审盲区、底层设计错误、评审粒度太大），并给出一套可操作的收敛流程：给意见分级、把意见变成可复现用例、交叉审查、限定改动范围、设置停止条件。
在不熟悉的领域里靠 AI 从零写出一个能用的工具，本身是可行的；真正让人卡住的通常是下一阶段：代码写完了，开一个干净的会话让模型去评审，把评审意见贴回开发会话去改，改完再评审。来回一周，P1 级别的问题还在冒，而评审结论落在自己的知识盲区里，既判断不了真假，也决定不了该不该改。
这类循环的难受之处不在于模型不够强，而在于流程缺了「裁决」这一环。评审输出只是意见，不是事实；没有判断标准，意见就会源源不断地产生。下面把原因拆开，再给一套能真正收尾的做法。
循环停不下来的几个原因
没有验收标准，找茬可以无限进行
只要任务被定义成「找出问题」，模型就一定会找出问题——这是任务定义决定的，不是模型水平问题。真实工程里的「够用」是靠需求边界和验收标准划出来的，而「再 review 一遍」没有这条线。有开发者反馈，双模型互审三四天仍然无法收敛，最后改出来的版本还不如回退。
同模型自审，盲区重合
写和审用同一个模型、同一套偏好，设计层面的问题往往两边都看不见，反而容易在风格、极端边界条件上反复来回。换个家族的模型能覆盖不同盲区，但对同一份代码的判断标准也更不一致，容易各说各话。
底层设计错了，修的是症状
如果每一轮评审都围绕同一类问题（比如某个连接握手时序、状态机分支），大概率是抽象层或状态划分本身有问题。此时每次修复都是打补丁，补丁又引出新补丁，P1 永远清不完。
评审粒度太大
把整个工程丢进一个会话，改动范围不可控，「修 A 坏 B」几乎必然发生。把模块拆小、限定只改当前模块，进度会明显好于一次性处理整包代码。
你无法裁决
这是根本原因。评审给的是「可能有问题」，而你需要的是「这个问题在我的使用场景下是否成立」。缺这一层判断，就只能全盘接受，于是永远收不了尾。
让循环收敛的具体步骤
第一步：给每条评审意见分级
不要按模型给的优先级直接排队，先自己过一遍分类：
| 类型 | 判断方法 | 处理 |
|---|---|---|
| 可复现的功能缺陷 | 能写出稳定复现的步骤或用例 | 进入修复队列 |
| 理论边界（极端时序、异常组合） | 说不出复现路径，只能「理论上可能」 | 记录，暂不修 |
| 风格与「更优雅的实现」 | 不影响行为 | 忽略 |
| 完全看不懂的 | 让模型解释「为什么这是问题」并给出最小复现 | 解释不清的直接丢弃 |
规则只有一条：进修复队列的必须有可复现用例，或明确的用户可见影响。 其余一律不进。
第二步：把「模型说」换成「跑得出来」
评审意见是自然语言，测试是可执行断言。把每条要修的问题先写成一条会失败的用例，再让模型针对这条用例改代码：
# 先让问题可复现，再谈修复
pytest tests/test_handshake.py::test_retry_after_reset -x
这一步能过滤掉大量并不存在的问题，也让「改没改好」有客观答案。
第三步：给评审方加约束
评审提示里写清楚输出格式，能显著减少无效意见：
- 每条问题必须包含：最小复现步骤、影响范围、不修的后果；
- 不允许给出「重构整个模块」这类无法验证的建议；
- 明确要求区分「确定是缺陷」和「仅是风格偏好」；
- 明确禁止为了让测试通过而修改测试用例本身。
第四步：拆模块，限定改动范围
一次只提供一个目录或一个模块，并显式声明允许修改的文件列表。改动范围越小，验证成本越低，回滚越容易。
第五步：用工程手段固化流程
- 每完成一个小任务就提交一次。 保留可回退的节点，是这类探索性开发里最划算的保险。
- 把「开新会话评审 → 汇总 → 回填修改」自动化。 让主流程调用一个干净上下文的子任务做评审，由主流程先过滤一轮再决定是否修改，可以免去手工复制粘贴。
- 设置停止条件。 例如：连续两轮评审没有新增「可复现」问题即视为收敛；或 P1 清零、P2 全部登记后收工。
如果这套评审—修复循环需要长时间挂着跑，把它放到一台长期在线的机器上是可选项之一（比如按月租用的远程 Mac），可以避免本地休眠、网络中断把长任务打断；任务本身不需要长时间在线的话，本地跑完全够用。
第六步：给自己补最小必要的领域知识
不需要学到能亲手写，只需要学到能判断。有效的方式是让模型先给「这个领域常见的几种架构以及各自取舍」，你选定方向后再让它落地，而不是直接要代码。能回答「这个 P1 在我的使用场景里会不会发生」就够了。
几个常见分歧的取舍
让 AI 自己写测试（TDD 路线）：好处是把模糊评审变成可执行断言，收敛速度明显提升；风险是模型可能为了让用例通过而去改断言。折中做法是测试用例的断言语义由你确认，模型只负责补实现。
同族模型互审 vs 跨厂商互审：跨厂商适合放在设计评审阶段，用来暴露思路盲区；实现细节层面的审查，一个模型加一套测试通常比两个模型吵架更有效。
P2、P3 要不要一起修：绝大多数情况下先让程序跑起来，等真实使用中出问题再回头改。追求「零问题」没有终点，过度优化本身也是一种成本。
什么时候该考虑重写
同时满足下面几条时，继续打补丁的成本通常已经高于重写：
- 同一类问题反复出现三次以上；
- 每次修复都会引入新的问题；
- 你已经说不清模块之间的调用关系和数据流向。
重写时先把「这个工具要解决的具体场景」写清楚，定好接口和状态机，再让模型填实现——先设计后编码，比先编码后评审省事得多。
小结
- 评审意见先分级，只处理可复现或有明确影响的问题；
- 把问题变成测试用例，用执行结果代替模型判断；
- 评审提示里要求最小复现、影响范围，禁止改测试；
- 拆小改动范围，每个小步都提交，保留回退能力；
- 设定停止条件，接受「当前版本够用」；
- 补到能判断的程度，而不是补到能亲手实现。
最后提醒一句：模型名称、上下文长度与具体能力变化很快，实际使用时以厂商官方最新说明为准；上面讨论的是流程，而不是某个具体版本的表现。
