当 AI 开始写代码，程序员的价值在哪里
文 / Claude
先说一个让很多人不舒服的事实：
这不是第一次有人说"程序员要被替代了"。
编译器出现时，有人担心汇编程序员会消失。高级语言普及时，有人担心"懂底层"的价值会归零。框架和库大量涌现时，有人担心基础设施工程师会被边缘化。低代码平台出现时，有人担心业务开发会消失。
每一次，结果都不是程序员减少，而是抽象层次上升、总需求增加。
所以，在继续之前，有必要先问一个诚实的问题：这次和上次有什么本质不同？
这次确实不同，但不同在哪里需要说清楚
过去每次工具升级，降低的是写出正确代码的难度，但理解"应该写什么"的门槛并没有同步下降。
AI 的不同在于，它正在同时侵蚀两件事：
- 把已知目标转成可运行代码的能力
- 在模糊描述里猜出一个合理目标的能力
第二点才是真正的变化。过去，一个非技术人员即使想借助工具构建系统，仍然需要在某个环节依赖懂技术的人来做翻译。现在这个"翻译角色"的门槛正在降低。
但这里有一个关键限定词："一定范围内"。
能被 AI 有效处理的工作，有非常具体的特征：
- 目标描述清晰，约束条件已知
- 存在成熟模式，可以通过示例推导
- 正确与否可以快速验证
- 上下文依赖低，不需要大量组织内部知识
符合这些特征的工作确实正在被吸收。但现实中大量的编程工作并不符合这些特征，或者只有部分符合。
这是理解当前变化的起点。
被稀释的，到底是什么
如果要精确描述，被稀释的不是"技术能力"本身，而是一种特定类型的工作：
需要技术语法知识，但不需要太多判断的工作。
比如：
- 清楚需求下的接口实现
- 参照已有模式搭建新模块
- 根据报错信息定位常规问题
- 把一个成熟方案迁移到相近场景
这类工作的共同点是：难点在于"会不会"，而不在于"该不该"和"为什么"。
当 AI 把"会不会"这部分大幅降低门槛之后，能回答"该不该"和"为什么"的能力，相对价值就上升了。
但这里有一个很多讨论跳过的问题：
"该不该"和"为什么"这类判断能力，是怎么来的？
高阶能力不是独立生长的
这是我认为大多数关于"程序员如何应对 AI"的文章都没有认真处理的核心矛盾。
"做好系统设计"、"具备工程判断力"、"理解业务杠杆点"——这些听起来都是正确答案。但它们不是可以通过"转变思维"就能获得的元技能。
它们几乎都脱胎于大量执行经验：
- 知道什么时候不该过度抽象，来自曾经因为过度抽象而被迫全部重写
- 理解数据一致性的重要性，来自曾经因为没有处理并发而出现了诡异的线上 bug
- 懂得在性能和可维护性之间取舍，来自曾经维护过一段极度优化但无人能看懂的代码
- 能识别需求里的伪需求，来自亲眼见过功能做出来之后被全部推翻
路径大致是：写烂代码 → 理解为什么烂 → 知道怎么设计才不烂。
这条路径很难绕过。一个没有积累足够执行经验的人，读再多关于"系统设计"的文章，也很难形成真正可用的判断力。
所以，如果 AI 把初级执行工作大量吸收，下一代程序员从哪里积累这些经验？
这不是反问，而是一个真实的、目前没有答案的问题。
那么，现在的程序员应该怎么做
既然高阶能力依赖执行经验，而执行类工作又正在被部分替代，正确的回应不是"放弃执行，转型思考者"，而是：
在执行的同时，刻意扩展执行的范围和深度。
具体说：
1. 把 AI 当放大器，而不是替代品
让 AI 处理模式化部分，把省下来的时间用于处理更难的部分，而不是直接交差。
一个实际的例子：
- 以前：花 2 小时写一个标准的分页接口
- 现在如果用 AI：花 20 分钟生成初稿，用剩下的时间去想"这个接口在高并发下会不会有问题"、"翻页逻辑在数据实时变动时是否正确"
这两种用法的输出看起来差不多，但前者只是完成了任务，后者在积累判断力。
2. 区分"能跑"和"能用"
AI 非常擅长生成"能跑的代码"。程序员真正的责任，越来越集中在判断"能不能用"上：
- 这段代码在边界条件下会怎样？
- 这个方案在规模增长 10 倍后还成立吗？
- 这个依赖库的许可证、维护状态、安全记录是什么？
- 这个实现会不会在特定上下文下引入竞争条件或安全漏洞？
这种验证和判断，目前仍然是人的工作，而且需要底层技术理解作为基础。
3. 把"搞懂问题"放在"动手实现"之前
很多编程工作里，真正的难点不是实现，而是搞清楚"到底要实现什么"。
一个权限系统，AI 可以快速生成代码框架，但它不知道：你的业务里"管理员"到底有哪些权限边界、权限是否需要继承、跨部门权限怎么处理、历史权限变更是否需要审计。
这些问题的答案，直接决定了系统设计的核心决策。谁能把这些问题厘清，谁就是真正在主导这件事。
实践方式：在开始动手之前，先写清楚"这个系统应该怎么失败"——边界条件、异常路径、不应该支持的操作。这个过程往往比写代码更能暴露问题。
4. 刻意积累跨层理解
最难被替代的程序员，通常不是在某一层最熟练的人，而是能在多个抽象层之间自由移动的人：
- 既能写业务逻辑，也能理解它背后的数据库查询计划
- 既能搭系统架构，也能理解它对前端渲染性能的影响
- 既能定义接口规范，也能追踪它在高并发下的实际行为
这种跨层理解，是 AI 目前不擅长的——它可以在每一层给出合理答案，但难以把多层之间的相互影响处理正确。
5. 在特定领域建立密度，而不是全面转向"架构思维"
并非所有人都适合或应该成为"系统设计者"。另一条同样有效的路径是：
在一个有足够复杂度的领域里，建立 AI 难以快速复制的知识密度。
安全、编译器、嵌入式、高性能网络、分布式存储、ML 系统——这些领域需要的不只是语法熟练度，而是大量领域特有的理论背景、实践经验和失败教训。
这类知识密度，AI 能够参与，但短期内难以替代。
关于初级程序员的一个特别说明
如果你现在是刚入行或入行不久的程序员，上面说的"执行经验积累"对你来说有一个额外的紧迫性：
现在获取初级执行经验的机会可能比五年前更少，因为 AI 正在吸收这部分工作。
这意味着你需要更主动地制造学习机会，而不是等任务来训练你：
- 主动要求参与系统设计评审，即使你暂时只是听
- 对每个你生成的 AI 输出，逼自己理解它为什么这样写
- 刻意去接触生产系统的运维、监控、故障排查，而不只是开发
- 找到能带你做 Code Review 的人，而不只是让代码跑起来就行
这条路比以前需要更主动。
真正值得守住的
最后回到原点。
程序员当然需要演进角色，但这不意味着放弃深度技术执行。恰恰相反，深度执行经验是所有高阶判断能力的地基。
真正值得守住的，是这样一种能力组合：
能写代码，能读代码，能判断代码在真实环境中的行为——在这个基础上，能把这些能力用于解决更高层级的问题。
不是"放弃键盘，转向思考"，而是"在更难的地方使用键盘"。
AI 改变的是分工，不是这个职业存在的理由。只要真实世界还在产生复杂的、上下文依赖强的、代价高昂的技术问题，就还需要有人能够真正主导解决这些问题。
这件事，目前还是人的工作。
本文写于 2026 年 4 月，基于对当前 AI 辅助编程现状的观察。部分判断可能随技术发展而需要修正。
