面试官问:AI 都能写这么多代码了,公司为什么还要你?

面试官问：AI 都能写这么多代码了，公司为什么还要你？

这个问题，可能正在成为程序员面试里的新常见题。

以前面试前端，可能会问你 Promise 怎么实现、React Fiber 是什么、浏览器渲染流程怎么样。

现在不一样了。

面试官很可能直接问：

“现在 Claude、Codex 这些 AI 已经可以写大量代码了，你觉得公司为什么还需要你？”

甚至会问得更直接：

“如果给一个实习生，再配一个 Claude Code，你觉得还需要你吗？”

表面上是在问 AI，实际上是在问另外一件事：

当写代码本身越来越容易，一个程序员还能提供什么价值？

有些答案，现在已经不太够用了

比如：

“AI 写的代码还是不够可靠，所以需要程序员。”

这个答案放在前几年或许还能成立。

但现在，越来越多常见的开发任务，AI 已经能够完成得相当不错。CRUD、表单、接口、工具函数，甚至一些完整的小型功能，都可以直接交给 AI。

如果还停留在“AI 写代码不如我”这个层面，很容易把自己带进一个尴尬的问题：

如果 AI 已经能完成你大部分工作，那你的核心竞争力到底是什么？

还有一种回答：

“AI 不懂业务。”

这句话也不能说完全错，但已经不够有说服力。

因为只要需求描述足够完整，AI 确实可以理解相当多的业务规则，并根据需求生成代码。

再比如：

“总得有人 Review AI 的代码。”

这同样成立，但如果把自己的价值定义成“AI 代码检查员”，显然也不是一个特别有竞争力的答案。

真正重要的地方，可能在代码之外。

第一层：AI 负责实现，人负责判断

我越来越认同一个简单的区别：

AI 更擅长回答“怎么做”，而开发者需要不断判断“应该做什么”。

举一个很普通的例子。

假设产品提出一个需求：

用户下单成功以后，页面显示一个 15 分钟倒计时。

这对 AI 来说并不难。

让 AI 生成一个倒计时组件，可能几分钟就能完成。

但真正开发这个功能的时候，你还会遇到很多问题：

倒计时究竟应该按照客户端时间计算，还是以服务器时间为准？

用户把手机时间手动调整了，会不会影响倒计时？

倒计时结束以后，是自动刷新订单状态，还是弹出提示？

如果用户同时打开两个页面，两个页面的倒计时如何保持一致？

活动开始以后，如果突然有几十万用户同时进入页面，会不会产生大量请求？

这些问题，并不是“把代码写出来”就结束了。

甚至有些问题，如果一开始没有考虑，等上线以后才发现，代价可能已经很高。

所以开发者真正的价值，并不只是把代码写出来。

而是知道：

哪些东西需要做，哪些东西没必要做，哪些边界条件必须提前考虑。

AI 可以帮你完成一个任务，但它未必知道你还遗漏了什么。

第二层：AI 可以生成代码，但系统不是代码堆起来的

再往上一层，就是架构。

让 AI 写一个注册接口，现在已经不是什么特别困难的事情。

但如果让你负责整个用户系统，问题马上就复杂起来了。

比如：

注册和登录是不是应该拆开？

用户数据未来会不会增长到千万级甚至更大？

数据库应该怎么设计？

Session 应该使用 JWT，还是 Redis？

以后要不要接微信、Google 等第三方登录？

权限体系现在应该做到什么程度？

哪些东西需要考虑未来扩展，哪些东西现在保持简单反而更合理？

这些问题没有一个统一答案。

AI 可以把各种方案列给你：

A 方案有什么优点，B 方案有什么缺点，C 方案适合什么场景。

甚至可以把三套方案全部写出来。

但最后选择哪一个，需要结合公司的业务规模、团队技术能力、现有系统、开发周期和维护成本。

技术方案从来不只是技术问题。

同一个架构，放在大公司可能合理，放在一个十几个人的创业团队里可能就是过度设计。

所以 AI 越擅长写代码，开发者反而越需要具备系统视角。

因为现在最大的问题可能已经不是：

“这段代码怎么写？”

而是：

“我们到底应该选择哪条路？”

而且 AI 生成代码越快，一个错误的架构决定，可能也会越快变成一大堆代码和技术债。

第三层：真正出了问题，还是得有人负责

这一点听起来有点现实，但可能恰恰是最重要的。

假设一个功能上线以后，凌晨三点突然报警。

这时候需要有人判断：

影响了多少用户？

是继续观察，还是立即回滚？

是前端问题、后端问题，还是数据库或者第三方服务出了故障？

临时修复应该怎么做？

修复以后如何确认没有引入新的问题？

第二天还要不要做复盘？

AI 可以帮你分析日志。

可以帮你看堆栈。

可以帮你搜索类似错误。

甚至可以直接生成修复代码。

但最后依然需要有人做决定。

要不要回滚，是人的决定。

哪个问题优先处理，是人的决定。

这个风险能不能接受，也是人的决定。

出了事故以后，也不会有人半夜三点把 AI 叫起来承担责任。

所以公司真正需要的，可能并不是一个单纯“能写代码的人”。

而是一个能够对结果负责的人。

一个真实案例，比说一堆“AI 不行”更有用

如果面试的时候真的遇到这个问题，我反而建议不要一直讲大道理。

直接讲一个具体案例。

比如：

“有一次我让 AI 帮我做一个数据导出功能。功能本身测试完全正常，几千条数据导出来也没问题。后来我检查代码的时候发现，它把所有数据一次性加载到了内存里。”

“测试环境的数据量比较小，所以一直没有暴露问题。但如果到了生产环境，数据量变成十万甚至百万级，这种实现方式就可能直接把服务拖垮。”

“所以问题并不是 AI 不会写代码，而是它不知道真实生产环境的数据规模和运行条件。”

这个例子真正说明的是：

代码能运行，不代表方案就是正确的。

而这可能就是 AI 编程时代，程序员需要继续保留的能力。

所以，AI 时代程序员到底应该提升什么？

我觉得可以把这个问题换一下。

不要一直问：

“AI 会不会把程序员替代？”

不如问：

“当写代码越来越便宜之后，什么能力反而会越来越贵？”

至少有几个方向值得关注。

第一，系统设计。

AI 让代码生产速度越来越快，但系统一旦设计错了，产生技术债的速度也会更快。

第二，业务理解。

知道需求怎么实现是一回事，知道产品为什么要这么做，是另一回事。

第三，沟通和协作。

真实项目从来不是一个人坐在电脑前把代码写完。

产品、设计、前端、后端、测试、运维，很多问题最终都需要人与人之间协调。

第四，线上解决问题的能力。

程序真正上线以后，才是考验的开始。

出了问题以后，谁能够快速定位、判断优先级、推动解决，并且避免下一次再次发生？

这也是为什么我并不认为 AI 编程意味着程序员“不需要写代码了”。

恰恰相反。

未来优秀的程序员可能依然需要很强的编码能力。

只是这个能力的用途正在变化。

以前是：

我自己把代码写出来。

以后越来越可能变成：

我知道代码应该怎么写，也知道 AI 写出来的东西到底对不对。

AI 把“写代码”这件事情变得越来越便宜。

而真正昂贵的，可能会变成：

做正确的判断，并且为结果负责。

所以，如果下一次面试官问你：

“AI 都能写这么多代码了，公司为什么还需要你？”

也许真正值得回答的，并不是：

“因为 AI 还不够强。”

而是：

“因为写代码只是软件开发的一部分。”

这版我特意保留了你要求的几个原文核心案例：倒计时、用户系统架构、凌晨线上事故、10 万条数据导出/OOM；但把案例里的具体表达、论证顺序和结论重新组织了。这样会比单纯把“完美地”改成“很好地”更像独立文章。