AI 编程时代，真正容易被淘汰的，可能不是老程序员，而是“只会写代码“的人

MulaLi_

664人浏览 · 2026-09-04 14:09:58

MulaLi_ · 2026-09-04 14:09:58 发布

这句话可能有点扎心：AI 编程时代，真正危险的可能不是年龄大，而是你的核心能力只有"把需求写成代码"。

以前这句话可能不成立，因为"把需求变成代码"本身就是一件很有门槛的事情。产品说增加一个订单退款功能，程序员要自己看需求、找代码、设计接口、写 Controller、写 Service、写 SQL、处理异常、跑测试、改 Bug，这里面大量工作本质上都依赖程序员亲手完成。所以写代码快，本身就是生产力。

但 Claude Code、Codex 这一代 Coding Agent 出来以后，这件事情正在发生非常明显的变化。现在一个需求下来，我越来越多时候是自己负责理解需求，把任务交给 Agent，让它搜索代码、修改、跑测试、自己修一轮，最后由我来验收。于是我最近越来越强烈地感觉到："会写代码"当然仍然重要，但它可能正在从程序员最核心的能力，慢慢变成一项基础能力。真正开始拉开差距的，是另外一些东西。

以前稀缺的是"怎么写"，以后可能稀缺的是"写什么"

举个非常简单的例子。需求是"用户提交订单以后增加一个状态"。以前一个新人可能先想:字段怎么加,枚举怎么写,SQL 怎么改,前端怎么显示。而一个做了很多年项目的人第一反应可能是:这个状态是谁维护的?能不能回退?旧订单怎么办?第三方系统认不认识这个值?有没有报表依赖?有没有定时任务判断这个状态?历史数据怎么处理?上线顺序是什么?

以前两个人的差距最后会体现在代码里。但 Agent 出来以后很有意思——"怎么写"这一部分,枚举、Mapper、DTO、Service、SQL,AI 几秒钟就能写出来。于是两个人真正的差距开始更直接地暴露出来:你知不知道这个需求真正意味着什么。AI 可以快速解决 How,但工程师越来越需要解决 What 和 Why。

只会 CRUD，确实会越来越危险

以前网上经常有人调侃 CRUD Boy，但实际上过去 CRUD 也能产生大量真实价值，因为接口总得有人写，表总得有人建，字段总得有人加，页面总得有人调,一个业务系统里可能 70% 的开发工作都长这样。但现在这部分恰恰是 Coding Agent 最擅长的。你告诉 Codex 根据现有代码风格增加一个查询接口，它自己就能找类似 Controller、找 Service、找 Mapper、补 DTO、写 SQL、跑测试。

这时候如果一个程序员的全部优势就是"我写这种接口特别快"，那确实需要认真想一下未来这个优势还有多大——因为你不是在和另一个程序员比手速，你开始在和一个不会累、不会嫌重复、搜索代码极快、可以不停工作、而且越来越便宜的 Agent 比。这个比赛很难赢。

"会写代码"和"会做软件"一直都不是一回事

这个区别以前其实就存在,只是 AI 把它放大了。有的人很会写代码,一个需求来了两小时写完,但你问他为什么这么设计,不知道;会影响哪些老功能,不知道;上线出问题怎么回滚,不知道;这张表两亿数据怎么办,不知道;为什么这里以前的人写得这么奇怪,"不知道,反正我重构掉了"。

这种人在没有 AI 的时代,也许还能靠编码效率获得不错的生产力。但到了 Agent 时代,编码速度突然不稀缺了,于是那些以前被"手速"掩盖的问题,就全暴露出来了。

AI 越会写，程序员越不能只会写

我现在越来越觉得,未来程序员的能力结构可能会发生变化。以前可能是编码能力占大头,加上 Debug、设计、沟通;以后也许慢慢变成需求理解、任务拆解、架构判断、Context 管理、Agent 调度、Code Review、测试设计、风险控制、最终验收这些能力占主导。代码当然还是要看得懂,甚至必须懂得更深,但"亲手敲出来"这件事情的重要性可能会下降。

这和当年从汇编走向高级语言有点类似——不是说汇编没用了,而是大部分人没必要再亲自管理每一个寄存器。同样,未来可能也不是每个程序员都必须亲自写完每一个 DTO、Mapper、Controller。

老程序员反而有一个很大的转型机会

我前面写过一篇《AI 编程时代，老程序员反而有一个年轻人没有的优势》，后来我又想了一下，这个优势真正应该怎么利用。我觉得不是"我有经验，所以 AI 替代不了我"，这种想法其实也挺危险。真正应该变成:把过去十几年积累的工程经验,变成控制 Agent 的能力。

比如以前你脑子里知道这个目录不要随便改,这个接口必须兼容,这段代码看着丑但是不能动,这个 SQL 在线上绝对不能这么执行,这个模块没有测试修改必须保守,这个客户的数据特别脏,这个服务出现问题必须能回滚。以前这些经验指导的是"你自己怎么写代码"，以后这些经验可能指导的是"Agent 能做什么,以及不能做什么"。这其实是一个非常大的角色变化。

Agent 开发不是"Prompt 写得好"就够了

现在网上很多 Agent 教程特别容易给人一种感觉:学会 Prompt 就会 AI 编程了。我自己用久了以后越来越觉得完全不是这样。Prompt 当然重要,但一个真实项目真正影响结果的,经常是你给了什么 Context,有没有告诉它边界,任务拆得合不合理,修改范围明不明确,有没有验收标准,有没有 Review,哪些操作允许自动,哪些必须人工确认。

比如同样是"帮我优化这个模块"，和写成"解决当前 Bug，只允许修改与当前问题直接相关的代码，不要进行结构性重构，保持现有接口兼容，修改完成后说明根因、修改文件、影响范围、回归风险、测试结果"，看起来都是 Prompt，但真正产生价值的其实是你知道哪些约束值得写进去。这就是工程经验。

还有一个我现在特别不推荐的东西：刚用 Agent 就全自动

现在很多 Coding Agent 都支持 Full Auto、Auto Accept、YOLO、Bypass Permissions 这种模式，特别诱人——理想状态是需求扔进去、去喝咖啡、回来全部完成。但我越来越觉得，全自动应该是你熟悉 Agent 以后得到的结果，而不是使用 Agent 的起点，尤其是老项目。你甚至还不知道它会怎么搜索、怎么修改、什么情况下重构、什么时候删文件、什么时候执行 Shell、什么时候改配置，就先把所有权限放开——这和现实里新同事第一天上班就给 root 差不多。

我更喜欢逐步放权。刚开始是 Agent 请求操作、我来确认，慢慢会发现 git status、git diff、npm test、npm run build 这些每天要跑几十遍，风险也很低，那就把低风险、高频的操作自动化;但删除、权限修改、未知脚本执行、高风险系统命令，继续保留 Human Review。这也是我觉得比较合理的 Agent Coding——不是把人删掉，而是把人从低价值操作里删掉。

一个 Agent 用熟以后，你很快会遇到下一个问题

就是一个 Agent 不够了。比如一个稍微复杂一点的需求，可以拆成 Agent A 分析代码、Agent B 实现功能、Agent C Review、Agent D 测试和修复。这个时候生产力会再次提高，但一个新的问题又来了:谁在 Running?谁已经 Finished?谁在等 Approval?谁异常了?哪个 Agent 刚才需要我?哪个已经十分钟没动了?你会发现，AI 越来越能干以后，人开始变成调度员。

这也是我为什么后来自己做了一个 Agent TUI Manager

我自己现在工作里会同时跑 Claude Code、Codex，用久以后最烦的已经不是"Agent 会不会写代码"，而是 Terminal 太多、状态分散、Approval 分散、异常不好发现、离开电脑以后 Agent 容易卡住。所以后来给自己写了一个 Agent TUI Manager。

GitHub：https://github.com/MulaLee4851/AgentTuiManager

它不是另外一个 Coding Agent，而是用来管理我现在已经在使用的 Claude Code、Codex、Pi 这些原生 TUI Agent。现在可以在一个地方看到 Frontend 在 Running、Backend 在 Waiting、Review 已经 Finished、Test 出了 Error，Approval 也可以集中处理，还有安全规则、异常恢复、钉钉远程值班。

我自己反而很坚持它不能"太全自动"，这可能有点反商业直觉——很多产品恨不得宣传"一键全自动，完全无人值守"。但我自己每天真的拿 Agent 写工作代码以后，反而越来越不喜欢"一键全自动"这个卖点，我更想要的是该自动的自动，该找我的时候一定找我。因为真正做过几年项目的人应该都知道，最危险的 Bug 往往不是程序直接报错，而是程序正常运行、结果也看起来正常，但业务逻辑错了。这种东西 Agent 自己很难替你兜底。

TUI 也是我现在比较喜欢的一种 Agent 形态。我自己现在还是偏 Claude Code / Codex 这种 CLI / TUI，不是因为 Terminal 比 GUI 高级，而是因为透明——它读了什么、执行了什么、改了什么、跑了什么命令，你基本都能看到。Agent TUI Manager 做的事情也是尽量在原生 TUI 上增加管理能力，而不是再包装一个完全黑盒的"输入需求、等待、Done"。我觉得特别是老程序员刚进入 Agent Coding，这种透明度非常重要——先知道 Agent 在干什么，再谈自动化。

而且我不希望 Manager 把原来的工具链锁死。Claude Code / Codex 原本都有自己的 Session，所以 Agent TUI Manager 没重新创造一套自己的私有 Session，以后不用 Manager 了，codex resume <session-id> 或者 claude --resume <session-id>，原来的会话还能继续。这个也是我自己做开发工具比较在意的一点:Manager 可以消失,但我的工作流和数据不能跟着消失。

所以我现在越来越觉得，未来程序员可能会分成两类

不是"会 AI 的"和"不会 AI 的"，这种分法太简单。更可能是:第一类让 AI 帮自己写代码,第二类设计一套系统,让多个 Agent 稳定地产出正确代码。第一类已经能获得很大的效率提升，但第二类可能才是真正开始改变软件开发方式的人。因为这时候程序员关注的已经不是"这一行怎么写"，而是任务怎么拆、谁来做、谁来 Review、什么能自动、哪里必须人工、失败怎么恢复、最终怎么验收。