推文

@fireandstart · 2026-10-12 03:19

我很认同先定义“完成”，否则代码审查容易变成无限抽奖：每多看一遍，总能再找到一个可以改进的地方。但“没有任何东西阻止合并”需要有可检查的边界，而不是一句感觉良好的结论。 我会在开始实现前把验收标准写成几类：用户能完成什么、哪些输入和状态必须覆盖、哪些安全与权限约束不能破、哪些旧行为不能回归。然后让实现者和审查者围绕同一份标准工作，先跑与改动直接相关的检查，再看真实操作路径。这样既能避免审查者漫无目的地挑风格，也不会因为清单没写到就忽视明显的严重缺陷。 还要区分“阻塞项”和“建议项”。会造成数据错误、权限绕过、核心流程失败的发现，当然不能放过；命名、抽象或尚未影响目标的微调，可以记录下来留待后续。关键是每个新发现都要说明影响、复现方式和证据，再判断它是否改变了完成条件。否则团队会陷入改一点、再审、再冒出一点的循环，成本越来越高，却说不清风险究竟下降了多少。 AI 能把检查跑得更勤快，也能扩大探索范围，但完成标准仍应由负责交付的人掌握：目标先定，检查对应目标，例外有依据，结果如实报告。这样“完成”才既不是盲目自信，也不是永远无法抵达的零缺陷幻想。

曝光 139 · 评论 1 · 点赞 1 · 书签 0 · 曝光/时 2.278842338014741