当AI会写代码后，程序员真正值钱的是什么？

上周我试着用新出的多代理工具处理一个老项目重构。原本预计要写三四天代码，结果Agent帮我把框架搭得七七八八。可当我 review 的时候，才发现真正花时间的地方，不是让它“写函数”，而是反复跟它说清楚：这个模块的边界在哪？异常情况怎么处理？业务上不能接受什么副作用？

那一刻我突然明白，Agent 时代真正值钱的，从来不是“写代码”这件事本身。

现象其实已经很明显了。过去两年，Cursor、Claude Code、GitHub Copilot Workspace，还有最近 Sakana Fugu 这种“一个 API 背后自动编排专家团队”的东西，越来越强。开发者社区里很多人开始说同样的话：我现在每天手写的代码越来越少，更多时间花在想清楚要什么、拆成什么样子、然后盯着 Agent 的输出挑刺。

这不是危言耸听，而是真实的生产力曲线在变。

问题在于，当 Agent 能比较可靠地完成“写函数 + 写测试 + 简单重构”这些中低复杂度任务后，单纯的实现能力就不再是稀缺资源了。以前一个程序员值钱，是因为他能把需求翻译成可运行的代码。现在这条翻译通道被 AI 大幅缩短了。真正卡住项目进度的，往往是上游：问题定义模糊、任务边界不清、验收标准缺失。

原因也很直接。模型上下文越来越长，工具调用越来越稳，多代理编排也开始成熟（Sakana Fugu 就是典型例子，它不追求自己全能，而是学会了“雇人”）。这意味着低层实现正在被自动化，像当年编译器把汇编解放出来一样。只是这次解放得更快、更彻底。

影响已经开始显现。那些还在每天炫耀“99% 代码是 AI 写的”的人，短期内可能交付得很快，但长期看，极大概率在堆技术债务。代码能跑，但没人真正理解边界、没人做过严格的边缘 case 审核、没人对系统级一致性负责。等出问题的时候，修起来比从头写还麻烦。

而另一批人，已经在悄然转型。他们花更多时间做三件事：

第一，定义问题。把模糊的需求拆成清晰、可验证、可度量的目标。Agent 再聪明，也不会替你想清楚“这个功能上线后，客服的工单量会下降多少”这种业务问题。

第二，拆解任务。把大目标切成 Agent 能可靠执行的子任务，并设计好它们之间的协作方式。好的拆解像搭积木，坏的拆解像一团乱麻。

第三，审核与驾驶。不是简单看一眼“代码能跑”，而是建立自己的 checklist：安全、性能、业务逻辑、长期可维护性。必要时把 Agent 拉回来迭代，甚至在关键路径上人工接管。

这三件事加起来，其实就是“指挥多个 Agent 完成有价值的工作”。我把它叫“驾驶能力”。

我见过两种极端。一种人把 Agent 当高级自动补全，用完就扔，问题永远出在“输入质量”。另一种人则像老飞行员一样，对自己的 Agent 编排流程、审核清单、回滚机制了如指掌。后者交付的东西，明显更稳，也更敢用在重要场景里。

这不是说“写代码”不重要了。底层实现能力依然是底盘。但在 Agent 时代，它正在从“核心竞争力”变成“基础素养”。就像现在没人因为会手动管理内存就觉得自己很牛了——那是必须会的，但不是区分人的地方。

真正值钱的是那层“人类判断 + 系统思维 + Agent 编排”的复合能力。它很难被完全自动化，因为它本质上需要对业务、风险、长期演进的理解，而这些理解目前还高度依赖人的经验和责任感。

我个人的判断是：未来三到五年，最吃香的程序员，不是写得最快的那批，而是最会让 AI 把正确的事做正确的那批。他们定义问题更准、拆任务更清晰、审核更狠、编排更优雅。他们不是在跟 AI 抢活干，而是在做 AI 做不了、也不该做的事。

这其实挺公平的。AI 把大量机械劳动拿走了，剩下的就是真正需要人类智慧和责任的地方。

所以下次当你打开编辑器的时候，不妨先问自己三个问题：

这个需求，我真的想清楚了吗？ 我准备让 Agent 负责哪些部分，又在哪些地方必须我自己把关？ 如果 Agent 今天就把这件事做完了，我明天要怎么 review 它、怎么长期维护它？

把这三个问题想透了，你就已经在练习 Agent 时代最值钱的能力了。

剩下的，就交给越来越强的 Agent 去执行吧。