我只点 merge：Agent 全自动迭代半个月后，我把这套关了
那半个月，我对那个项目做的唯一一件事，就是点 merge。
早上起来，GitHub 上躺着三四个 PR，都是它自己开的 worktree、自己写完、自己评审过、自己把说明写得整整齐齐。我扫一眼标题，觉得”看着没问题”，点 merge。绿了。下一个。
直到某天我想加个小功能，打开代码时愣了一下。代码能跑，但东一块西一块，一堆功能我不知道是干嘛的，也想不起来自己什么时候点头同意过。它没崩，只是长成了一个我不认识的东西。
我当时是怎么想的
这工具最早是同事的一个命令行小产品，我接手后起了个念头：能不能让它自己长大。
我给 Agent 定了产品基调和底线，又丢给它一串同类工具。它每天去 GitHub 看这些项目更新了什么，发现值得跟进的功能，就自己创 epic、拆 story、开评审。评审通过后，它再开 worktree、写代码、提 PR。
我留给自己的角色只有一个：merge。
那阵子我还挺得意。人退到最后一道关，机器跑完整个闭环，这不就是大家说的那个梦吗？
每一步都合理，产品还是会跑偏
半个月后我才看明白，我交出去的不只是写代码的活，还有决定产品往哪长的权力。
它每天都能”发现”新功能。竞品加了什么，它想跟一个；某个 issue 被提了，它也能找到做它的理由。每一个单独看都合理，合在一起却没有主心骨。因为那个应该决定”值不值得做”的人，把选择缩成了合并页面上的一个按钮。
Replit 在 2025 年出过一个更极端的事故：用户明确要求冻结改动，Agent 仍然执行了数据库操作，删掉了生产数据。那是权限和生产隔离失控，和我的产品跑偏不是一类后果，但它们有同一个薄弱点：Agent 获得了一项超出验证边界的决定权。
真正让人松懈的是，它每一步看起来都对。语法对、格式对、PR 说明写得比我还工整，你很难从某个 diff 里指出”方向错了”。《Trust Doesn’t Live in Code Review》里说，当 Agent 写代码的速度超过人认真阅读的速度，review 很容易退化成盖章。章还在盖，“我知道自己在发布什么”的感觉也还在，实际的控制权却已经丢了。
自动化之前，先分清两类判断
我现在会把判断分成两类。
一类是有边界、能核对的执行判断：代码是否通过测试，有没有违反项目约定，是否满足写好的验收标准。Agent 可以在这个范围里自己实现、自己验证，我只看异常和最终结果。
另一类是产品判断：这个功能值不值得存在，会不会把产品带向另一个方向，为它付出的复杂度是否划算。Agent 可以提供材料和方案，最后授权必须留在人手里，因为这类问题没有一条测试跑完就能给出答案。
我以前把这两类判断一起交了出去，只在最后看代码能不能合。等功能已经做完、PR 已经写好，再让人否掉它，心理成本反而更高。于是”都做到这一步了”会替产品做决定。
代码当然还要审，但代码审查回答不了一个更早的问题：这段代码是否值得出现。
现在我怎么做
那套全自动，我关了。
每个功能开始前，我先写清楚三件事：为什么做，明确不做什么，做到哪儿算结束。Agent 在这个框里拆任务和写代码；涉及产品方向的变化，停下来等我确认。写完以后，我再按验收标准走一遍，不拿它自评时那句”我检查过了”当证据。
速度比只点 merge 慢，但产品重新变回了我认识的样子。我仍然依赖 Agent，只是不再让一张看起来工整的 PR 替我做产品选择。
真正的关口不在 merge 按钮，在功能进入 backlog 的那一刻。
