大家好，我是小富。

《十万个why》系列持续更新中

这两年 AI 写代码的能力肉眼可见在进步。

GitHub Copilot 补全代码越来越准，Cursor、Claude Code 这些 AI IDE 已经能直接根据一段需求描述生成整个功能模块，甚至自己跑通测试。我自己日常开发也在重度使用，写 CRUD 接口、工具类、单元测试，它确实比我快。

于是一个问题就出来了：大模型写代码越来越强，程序员是不是快被取代了？

我的判断是 10 年内不会，这不是盲目乐观，下面说说我的理由。

写代码从来不是程序员最难的工作

外行看程序员觉得这个职业就是写代码，大模型能写代码了，所以程序员要完蛋了。

但做过几年项目的人都知道，写代码在整个开发周期里占的时间可能连三分之一都不到。一个需求从提出到上线，程序员大部分时间在干别的。

跟产品扯需求，他说的"简单加个功能"背后可能藏着三张表的结构变动和两个跨服务调用，你得能听出他没说出来的隐含约束。

看懂现有系统，这个接口为什么绕了一圈去查了另一个服务的缓存？这个 if 分支看着多余为什么不能删？上下文全在前任的脑子里和四年前的 commit message 里。

定方案做取舍，用消息队列还是直接同步调用？加字段还是加表？这个决策涉及的是业务增长预期、团队维护能力和系统当前瓶颈的综合判断。

这些事情大模型一件都干不了，它没有你的业务上下文，不了解你的系统历史包袱，更不可能帮你判断产品经理这次的需求合不合理。

历史早就给过答案

每一轮技术革命都有人说某个职业要消失。

Excel 出来的时候，有人觉得会计要失业了。结果会计反而更多了，因为 Excel 让做报表的成本大幅降低，公司开始做更多的数据分析，产生了更多的会计岗位。

ATM 机在美国普及的时候，所有人都觉得银行柜员要被裁光。实际上美国银行柜员的数量从 1970 年到 2010 年一直在涨。ATM 降低了开设分行的成本，银行反而开了更多网点，需要更多柜员去处理 ATM 搞不定的复杂业务。这个数据来自 MIT 经济学家 James Bessen 的研究，不是我编的。

这背后有一个反直觉的经济学规律：当工具让某项工作的成本降低时，市场对这项工作的需求往往会大幅增加，最终需求的增长超过效率的提升。

软件开发也是一样。大模型让写代码变便宜了，企业不会裁掉程序员省钱，它们会用同样的成本去做更多的项目、更多的功能、更多的自动化。全世界还有大量的行业没有被充分软件化，医疗、农业、制造、政务、教育……需求远没有到顶。

生成代码 ≠ 生成正确的代码

你让 AI 写一个用户注册接口，它写得很快，代码也像模像样。但你把它放到一个已经跑了三年的系统里，问题就来了：

你系统的用户名唯一性校验不是靠数据库唯一索引，而是走的 Redis 分布式锁，因为历史原因两个服务共享同一张用户表。AI 不知道这个。

注册成功之后要发一条消息给积分服务，但这个积分服务最近在灰度迁移，消息格式变了。AI 不知道这个。

公司安全规范要求所有用户数据写入接口加审计日志切面，不能在业务代码里手写。AI 也不知道这个。

这些东西不在任何公开文档里，散落在同事的脑子里、团队 Wiki 里、以及 Git 历史的某次 commit message 里。

大模型能生成一段"语法正确的代码"，但它生成不了一段"在你这个系统里正确的代码"。这两者之间的差距，短期内看不到弥合的趋势。

"几乎正确"比"明显错误"更危险

AI 写的代码有一个很坑的特点：大部分时候看起来是对的。

如果它写的代码一看就有毛病，那没关系，你一眼能发现。但它写的代码看起来非常合理、逻辑通顺，偏偏在某个边界条件上有一个极其隐蔽的 Bug，这种情况才真正危险。

比如我之前让 AI 生成并发扣库存的逻辑，它用了数据库乐观锁，version 字段比对，更新失败就重试。代码结构、命名规范、异常处理全都很到位，甚至还加了重试次数限制。

但它把重试时的 SELECT 放在了事务外面。高并发下，重试读到的 version 可能已经被其他事务改了两轮了，导致永远更新不成功，最终全部走到重试上限返回系统繁忙。

这种 Bug 在 Code Review 时非常容易漏掉，因为代码看起来太对了。你需要一个对事务隔离级别和并发模型有深入理解的人才能一眼看出来。

所以大模型越能写代码，越需要有经验的人来审代码。它不是在取代程序员，它是在拉高对程序员能力的要求。

线上出了问题，AI 帮不了你

代码写完上线只是开始，线上环境的复杂度远超开发环境。

凌晨三点监控告警 CPU 飙到 100%，你查日志发现是某个定时任务触发了全表扫描。看了下这个定时任务上周刚改过逻辑。SSH 上去排查，发现是配置中心推了一个错误的 cron 表达式，把每天执行一次变成了每分钟一次。

整个排查链条涉及监控系统、日志平台、配置中心、数据库慢查询、业务逻辑、运维操作记录，信息散落在五六个系统里。你需要一个人能串起这些上下文，凭经验快速缩小范围，定位到根因。

这个过程你没法丢给 AI，它没权限登你的生产服务器，看不到你的监控大盘，也理解不了你的部署拓扑。更关键的是，线上排障需要的不是"生成代码"的能力，而是从一堆碎片信息里拼出全貌的分析判断力。

角色在变，但人不会少

我自己的工作方式这两年变化不小：

以前写工具类从零开始敲，现在让 AI 先出一版，我在上面改。写单元测试以前觉得烦，现在 AI 生成测试用例，我只管检查覆盖率和边界条件。以前大量时间花在模板代码上，现在这部分基本全交出去，精力更多花在系统设计和 Code Review 上。

程序员正在从"代码的编写者"变成"代码的决策者和审核者"。你需要判断该写什么、怎么写、写出来的东西对不对。AI 是一个越来越强的执行工具，但指挥权还是在人手上。

跟自动化测试出来时的情况很像，测试工程师没有消失，只是从手动点点点变成了写自动化脚本、设计测试策略。活变了，人没少。

说在最后

大模型写代码越来越强是事实，但它强的是"写"这个动作本身。而程序员的核心价值从来不只是写代码，是理解业务、做技术决策、控制系统复杂度、保障线上稳定。

这些能力目前的大模型连边都沾不上。

与其焦虑 AI 会不会取代自己，不如想想怎么用好这个工具，从低价值的重复编码中解放出来，把时间花在真正需要人做判断的地方。工具越强，会用工具的人越值钱。