AI Coding 不缺产能了，缺的是交付约束
前两天看到 Boris Cherny 的访谈，我第一反应不是“程序员要没了”。
Boris 是 Claude Code 的 creator/head。他说自己 2026 年没怎么手写代码了，日常更多是在手机上让 Claude Code 开 PR，自己看 diff、做判断。早一点的公开报道里，他也提过一天能 ship 20 多个 PR，而且代码都是 Claude 写的。
这个故事很容易被讲成焦虑文。
什么“程序员最后的倒计时”，什么“2027 年软件开发自动化”。这种讲法我不太喜欢。它把一个真实的工程变化，压扁成了职业恐吓。
我更关心另一个问题：
如果一个工程师一天能让 Agent 开 10 个、20 个甚至更多 PR，团队的工程流程接不接得住？
代码产能上来了，Review 跟不上怎么办？测试证据不够怎么办？权限边界没设好怎么办？几十个 PR 看起来都能跑，但没人敢合，怎么办？
这才是 AI Coding 接下来真正会撞上的墙。
写代码正在变便宜
过去我们讨论 AI Coding，经常还停在“它会不会写代码”。
这个问题还重要，但已经不是唯一重点了。
OpenAI 最近把 Codex 往开发工作台方向推，PR review、多文件、多终端、SSH devbox、浏览器、plugins、automation、memory 都在往里塞。GitHub 也已经支持把 Dependabot alert 分配给 Copilot、Claude、Codex 这类 coding agent，让它们分析漏洞并开 draft PR。
这些变化放在一起看，方向很清楚：Agent 不只是补全一段函数了。它开始进入 issue、PR、安全告警、review comment、devbox、浏览器这些工程流程。
也就是说，它的手变长了。
手长是好事。很多重复劳动确实可以丢给它，比如依赖升级、lint 修复、测试补齐、文档同步、简单 bugfix。以前这些活你不想做，但又不得不做。现在 Agent 可以自己在那吭哧吭哧开 PR。
问题是，代码变便宜以后，工程系统里的其他东西会变贵。
以前慢的是写代码。以后慢的可能是这些：
| 环节 | 新问题 |
|---|---|
| 需求 | Agent 接到一句模糊需求，也会硬着头皮开工 |
| 权限 | 它能读文件、改代码、跑命令、拿 token、开 PR |
| 验证 | 它说“已验证”，但可能只跑了一个最顺手的命令 |
| Review | PR 数量上来之后，人类 review 会先被打爆 |
| 合并 | 低风险和高风险 PR 混在一起，最后没人敢点 merge |
这不是模型聪不聪明的问题。
这是交付系统的问题。
不要把 Agent 当聊天框，要当 PR 生产线
我现在越来越不愿意把 AI Coding 工具叫“助手”。
助手这个词太温柔了。你会默认它只是站在旁边帮你补两句代码，最多给点建议。
但现在的 Agent 已经不是这样。它能自己读 repo，自己改文件，自己跑测试，自己回 review comment，自己开 PR。你给它一点空间，它就会把一个任务往前推。
这更像一条 PR 生产线。
生产线的问题，从来不是“机器能不能动”。机器当然能动。真正的问题是：原料进来有没有规格，机器能碰哪些区域，产物怎么检查，不合格怎么返工，什么时候能入库。
把这个类比放回 AI Coding，就是一套交付约束。
我觉得至少要有五类。
第一类：需求约束。
没有验收标准，不让 Agent 开工。
这句话听着很重，但实际非常朴素。不要给 Agent 丢一句“优化一下登录体验”，然后期待它自己理解你脑子里的产品判断。
最低限度，任务里要写清楚四件事：
要改什么
不改什么
完成后怎么验证
失败了怎么回滚
比如你要修 token 过期后的白屏，可以这样写：
任务：修复登录 token 过期后访问 /dashboard 白屏
改动范围：
- 可以改前端 auth guard
- 可以改登录跳转逻辑
- 不改 token 生成逻辑
- 不改用户表结构
验收标准：
- token 过期时跳转登录页
- 登录成功后回到原页面
- URL 保留 redirect 参数
验证方式：
- 跑 auth E2E
- 手动访问 /dashboard，模拟过期 token
- 提供测试输出和跳转截图
回滚方式：
- 单独 PR
- 不混入其他 auth 重构
这东西不高级。
但它能把 Agent 从“自由发挥”拉回“按合同干活”。需求越模糊，Agent 越容易补一个自己理解的目标。它补得还挺像样，最麻烦。
第二类：权限约束。
Agent 真正危险的地方，不是写错一行代码。
是它拿着权限执行动作。
一个只能读文件的 Agent，最多给你胡说八道。一个能改代码、跑 shell、拿 GitHub token、连 devbox 的 Agent，已经在工程系统里有真实行动能力了。
所以权限不能默认全开。
我现在更倾向于按层级给：
| 层级 | 能做什么 |
|---|---|
| L0 只读 | 看代码、读日志、写 plan |
| L1 局部可写 | 只改指定目录或指定文件 |
| L2 可跑验证 | 跑 test、lint、build、类型检查 |
| L3 可开 PR | 只能开 draft PR，不能 merge |
| L4 需人工确认 | 数据库迁移、依赖大版本升级、发布、权限配置 |
| L5 禁止 | 生产 destroy、真实支付、删除备份、绕过审计 |
很多团队最开始用 Agent 时，会直接给一个很大的权限包，因为这样“省事”。
省事是真的。
出事也是真的。
前段时间不少 AI coding agent 的安全讨论，核心都不是“模型被说服写了烂代码”，而是凭据、token、workflow 权限这些东西被拿来做了不该做的事。攻击者不一定要让模型变笨，只要让 Agent 在有权限的环境里执行错误动作就够了。
这块不要赌模型自觉。
权限边界要靠系统收住。
第三类：验证约束。
“已验证”这三个字，我现在看到会自动打折。
不是因为 Agent 一定撒谎。它可能真的跑了命令。问题是它跑的命令不一定覆盖你的验收标准。
它修了一个 API bug，跑了 npm test，绿了。听起来没问题。但真正该验的是“旧 token 过期后前端跳转是否正确”。单测绿了，不代表这个行为过了。
所以验证不能只看一句话，要看证据。
不同任务要留不同证据：
| 任务类型 | 证据 |
|---|---|
| API | 请求内容、状态码、响应结构、关键字段 |
| UI | 截图、交互步骤、Playwright trace |
| 数据库 | 迁移前后 schema、样本数据、回滚测试 |
| 权限 | 操作前角色、操作后权限、拒绝路径 |
| 性能 | 命令、数据规模、耗时、对比基线 |
证据不一定复杂。
一个 curl 输出、一张截图、一段 Playwright trace、一次 CI 链接，都比“我检查过了”可靠。
我的判断是：Agent 生成代码越快，验证证据越要硬。否则你会得到一堆看起来都能跑的 PR，每个都差一点证明。
差一点证明，最后就是没人敢合。
第四类：Review 约束。
写代码的 Agent，不能自己判自己通过。
这个道理在人类工程里很普通：不要自己 review 自己的 PR。到了 Agent 这里，很多人反而会偷懒。
一个 Agent 写完代码，再让它总结“我做得怎么样”，它大概率会把自己的意图解释得很顺。问题是工程事故经常不是意图错，是边界错、遗漏错、假设错。
我更愿意拆成两层：
Agent A：负责实现
Agent B：负责验证和 review
人类：只看高风险点、业务边界和最终 diff
这样人类不是从头到尾逐行看所有 PR。那不现实。一天 20 个 PR，谁都扛不住。
人类应该看更少但更关键的东西：
- 这次改动有没有越过任务边界？
- 测试证据够不够？
- 业务逻辑有没有被顺手改掉？
- 数据、权限、发布有没有风险？
- 这个 PR 是不是混进了无关重构？
Agent 之间可以先互相筛一轮。人最后看风险，不看流水账。
这不是完全自动化。
这是把人的注意力从“盯着它写代码”挪到“判断它能不能进主干”。
第五类：合并约束。
AI Coding 真跑起来之后，最先爆掉的可能不是代码质量，而是 PR 队列。
这个体验我自己很熟。你让 Agent 并发做几个任务，它很快就能开出一排分支。每个 PR 都不大，每个看起来都有道理。然后你一天过去了，发现真正耗时间的是决定先看哪个、哪个能合、哪个要退回去。
所以 PR 不能无限开。
要按风险分级。
低风险：
- 文档同步
- lint 修复
- 小范围测试补齐
- 单依赖 patch 升级
中风险：
- 普通 bugfix
- 小功能
- 单模块重构
高风险：
- 数据库迁移
- 权限逻辑
- 支付/订单/计费
- 发布链路
- 大范围依赖升级
低风险可以批量 review。中风险每批控制数量，比如 3 到 5 个。高风险单独走，别混。
还有一个很实际的规则：review 队列超过上限，就停止派新任务。
这听起来扫兴，但很必要。否则 Agent 一直开 PR，人一直看不过来，最后团队会进入一种很尴尬的状态：代码产能很高，交付吞吐很低。
表面上很先进。
实际上只是把堵点从开发挪到了 review。
工程师不是没事干了，是工作位置变了
我不太认同“程序员不写代码就没价值”这个说法。
写代码当然重要。但如果 AI Coding 继续往前走，工程师每天的工作比例确实会变。
以前你可能 70% 时间在写实现，30% 时间在读需求、跑测试、review。
以后可能反过来：
- 把需求写成 Agent 能执行的任务
- 给任务设边界
- 配权限
- 看验证证据
- review diff
- 处理失败 PR
- 把有效流程沉淀成 Skill、script、CI 规则
这不是更轻松。
很多时候更累。因为你从写代码的人，变成了对代码进入系统负责的人。
以前 bug 是你写出来的，你知道自己哪里心虚。现在 PR 是 Agent 写的，你要在更短时间里判断它有没有埋坑。这个压力不小。
所以我觉得“AI Coding 不缺产能了”不是一句乐观判断。
它只是说明瓶颈换地方了。
代码会越来越容易生成。真正难的是把这些代码约束进一个可验证、可回滚、可审计的交付系统里。
下一阶段拼的不是谁的 Agent 更像天才。
拼的是谁能让这个天才别乱碰生产。
参考资料：