这组数据提醒我：AI code review 的瓶颈，未必是“看得不够多”，而可能是没有定义何时停止。50 多轮里，约 59% 的问题首轮就已可见；如果后续… · @fireandstart · TwKit

@fireandstart

这组数据提醒我：AI code review 的瓶颈，未必是“看得不够多”，而可能是没有定义何时停止。50 多轮里，约 59% 的问题首轮就已可见；如果后续每轮只是把旧问题拆得更细，修复又不断引入新问题，继续循环就会把审查变成没有终点的劳动。 我很认同把第三轮设成重新审视方案的节点：若同类问题反复出现，应该暂停局部打补丁，回到设计、边界和实现路径，而不是让 agent 继续追逐新发现。之后只看 diff，也是在限制审查范围，避免旧问题不断回流。 按风险分配人工审核同样关键。低风险改动可以减少打扰；高风险变更必须让人承担明确责任，agent 的“通过”不能替代人的判断。尤其谁指挥 agent 写了 PR，谁就需要参与审查，这让自动化和责任链保持一致。 把计划、实现、审查交给不同角色能减少单一视角，但角色拆分本身并不能解决循环。真正可操作的工作流还应预先设定轮数上限、风险门槛、升级条件和停止后的复盘动作。超过上限时，系统应给出“需要重新设计”或“交由人工决策”，而不是默默开启下一轮。

曝光 125 · 评论 3 · 点赞 3 · 书签 0