AI 编程代理进团队，别把审查权也交出去

Simon Willison 引了 Jon Udell 一段话。材料不长，但打中 AI 编程代理最容易被忽略的地方：流程到底谁说了算。

Udell 不喜欢“human in the loop”。这个说法听起来温和，实际默认机器在主流程里跑，人类只是被塞进去兜底。他建议反过来：这是我们的 loop，代理只是被邀请进团队。

这不是术语洁癖。AI 代理一旦能写代码、改文件、开 PR，风险就不只在代码质量。更麻烦的是，它可能制造一个人类看不懂、审不动、也不好拒绝的大 PR。效率从这里开始变味。

Udell 改的不是词，是主导权

Udell 的原话强调一点：agent-assisted process 不该是黑箱，不该是“输入 prompt，输出 feature”。开发流程本来就有人类的协作、审查、合并、维护。代理加入后，也要服从这套秩序。

两种说法的差别很小，后果很大。

“名不正，则言不顺。”放在这里并不玄。名字背后是权力关系。叫 human in the loop，机器像流程，人像插件；叫 agent in our loop，至少提醒团队：流程主语不能丢。

受影响的人很具体。

开发者会先感到快。样板代码、边角任务、初稿实现都能省时间。技术负责人会看到吞吐量上升。代码审查者最先付账：一坨变更压过来，意图不清，边界不清，测试意图也不清。

不可审查的 PR，表面是提交粒度问题，底层是工程治理问题。

真正危险是团队让出节奏

我不反对 AI 编程代理。反对也没意义。它已经进入开发现场，而且确实能压掉一部分低价值劳动。

我不太买账的是另一种乐观叙事：代理越强，团队越轻松。只说对了一半。

代码开发不是把功能堆出来。它还包括命名、边界、依赖、回滚路径、测试意图、历史包袱和团队共识。很多东西不写在代码里，却决定代码能不能维护。

一个代理生成的大 PR，如果没人能在合理时间读懂，就不是贡献，而是债务。今天合并，明天付息。

对正在用 AI coding agents 的开发者，动作要更具体：不要把代理当“自动完成功能”的黑箱。让它拆任务、写变更说明、补测试、解释关键选择。PR 过大，就退回去重拆，而不是硬着头皮审。

对技术负责人和代码审查负责人，规则要写到流程里：

• PR 必须可审查，不能只看功能跑通；
• 变更必须可拆，不能把重构、修 bug、新功能混在一起；
• 关键路径要有人类 owner，不能让代理承担模糊责任；
• 合并前要有回滚路径，尤其是接口、权限、数据迁移相关改动；
• 审查者有权拒绝“看不懂但似乎能跑”的提交。

现实约束也要承认。小团队赶进度时，很容易放宽这些规则。短期看，速度确实上去了。问题是软件债不会消失，只会换个地方记账：依赖里、测试缺口里、没人敢动的模块里。

铁路、电力、报业、互联网平台都经历过类似阶段：先释放效率，再补治理。类比不完全一样，但人性很像。技术一旦带来增长幻觉，组织就会倾向于先合并、先上线、先庆祝，责任边界以后再说。

软件行业的麻烦在于，“以后”常常变成没人敢碰。

接下来盯住两个变量

这条引述本身不是行业新闻，也不是某个标准术语发布。它的价值在于给 AI 编程代理划了一条线：代理可以进团队，但不能重写团队的责任结构。

接下来最该观察的不是模型又会不会多写几行代码，而是两个变量。

一个是 PR 粒度。代理生成的变更，能不能被拆成正常审查单元。能拆，才有协作；不能拆，就是把黑箱包装成生产力。

另一个是审查权。审查者能不能拒绝不可解释、不可回滚、不可定位责任的提交。如果不能拒绝，所谓 human in the loop 就只剩姿势。人还在环里，但权力已经出环了。

这也是 Udell 那句话最有用的地方。它没有反 AI 写代码。它反对的是开发团队在兴奋中把审查权、节奏权和责任边界一起交出去。

代理可以很强。流程必须更硬。