“AI 要取代程序员了"这句话已经被说了三年多，热度不减，但也越说越空。它更像一句情绪表达，而不是一个可以拿来做决策依据的判断。与其纠结这个非黑即白的问题，不如换个更具体的问法：在后端、企业级开发这个具体场景里，AI 已经实际改变了什么，还没有改变什么，正在改变什么。这篇笔记只谈这个。
一、AI 工具现阶段能做到什么程度#
抛开演示视频里的效果，回到日常企业级后端开发的真实场景，当前主流 AI 编程工具大致能稳定做到：
- 重复性、模式化的代码生成：CRUD 接口、DTO/VO 转换、简单的单元测试骨架、样板化的配置代码，这类"照葫芦画瓢"的工作，AI 完成得又快又稳。
- 局部调试与报错定位：给一段报错信息和上下文，AI 能相当准确地缩小排查范围，尤其是常见框架（Spring、常见 ORM、消息队列客户端）里的典型坑。
- 代码解释与知识检索：读一段陌生代码、理解一个不熟悉的库的用法，AI 比过去翻文档、搜论坛效率高得多。
但同样明显的是它做不好的部分：
- 跨系统的架构判断：一个改动会不会影响到下游服务、要不要拆表、这个字段该不该加索引——这类需要结合业务历史和线上真实数据分布做的判断，AI 目前给出的建议往往是"教科书正确、场景不一定对”。
- 长期维护性的取舍：AI 倾向于给出"能跑通"的方案，但对"三年后谁来维护这段代码"这类隐性成本几乎没有感知。
- 对模糊需求的澄清：真实需求经常是模糊、矛盾、随时间变化的，AI 目前仍然依赖人把问题讲清楚，而"把问题讲清楚"这件事本身往往就是后端开发里最耗时间的部分。
简单说：AI 把"写代码"这个动作的门槛和成本都在降低，但"决定写什么代码、为什么这么写"这件事，目前基本没有被替代。
二、对岗位结构的具体冲击#
如果只停留在"AI 好不好用"层面，讨论价值有限。更值得关注的是，这种能力边界正在往岗位结构上传导，而且已经能观察到一些具体迹象。
2.1 初级、重复性工作量被压缩#
过去一个团队里，相当一部分初级工程师的日常工作就是写这些模式化的 CRUD 和样板代码。这部分工作量被 AI 分担之后，直接的结果不是"初级岗位消失"，而是同样规模的团队，对初级岗位的需求量在下降——因为这部分工作的边际人力成本变低了。这对应届生和初级岗位求职者是最直接、最现实的冲击，比"AI 会不会取代程序员"这种笼统说法要具体得多。
2.2 招聘标准的重心在转移#
企业在招聘描述里，“熟练使用某语言/框架"这类描述权重在下降，“系统设计能力"“对复杂业务的架构判断"“代码评审（code review）能力"这类描述权重在上升。原因不难理解：当"写代码"的执行成本被摊薄，团队愿意为"能不能做对判断、能不能把关质量"这件事付更高的溢价。这不是岗位数量的简单增减，而是同一个岗位标题下，考察的能力集合变了。
2.3 Code Review 的负担在变化#
AI 生成代码的效率提升，带来一个不太被讨论的副作用：产出代码的速度超过了人工审查代码的速度。一个团队里，如果每个人都用 AI 加速了写代码的环节，但 code review 仍然依赖人工逐行把关，review 环节就会成为新的瓶颈，甚至因为审查疲劳而降低把关质量。这意味着"代码评审能力"和"如何设计更高效的审查流程”，正在变成比过去更重要、也更稀缺的能力，而不是简单地被 AI 分担。
三、需要警惕的两种偏差#
讨论这个话题时，容易滑向两种同样站不住脚的极端：
一种是过度乐观的替代叙事——把 AI 现阶段在演示场景里的表现，直接外推到"复杂企业系统的全流程自动化”，忽略了真实系统里大量的历史包袱、隐性约束和跨团队协调成本，这些恰恰是 AI 目前最弱的部分。
另一种是过度防御的否认态度——用"AI 现在还写不出真正复杂的系统"来回避"日常工作里大量可自动化的部分已经被自动化"这个已经发生的事实。这种态度短期内让人心安，但对判断自己该往哪个方向投入精力没有任何帮助。
比较务实的态度是：把 AI 现阶段的能力边界当成一个正在变动、但当下可以观察和验证的事实，而不是一个用来支持某种情绪结论的素材。
四、结语：往哪些能力上迁移#
对个体开发者而言，真正值得思考的问题从来不是"要不要用 AI”，这件事基本没有选择空间——不用的成本正在变得越来越高。值得思考的是：当"写代码"本身的门槛持续下降，自己的价值应该建立在哪些 AI 目前顶替不了的部分上。从目前能观察到的迹象看，至少包括这几类能力：对业务和系统历史的深度理解、跨系统的架构判断力、以及在信息不全、需求模糊时做出取舍的判断力。这些能力的稀缺性，恰恰是在 AI 把"执行成本"拉低之后，才被更清楚地显现出来的。
通过邮件回复