编者按：
当“AI 正在接管编程”成为技术圈最热门、也最容易被情绪化传播的话题之一时，真正值得追问的，或许并不是“程序员会不会消失”，而是：当代码生成越来越廉价之后，软件工程中真正稀缺、也真正不可替代的能力，究竟会转移到哪里。这篇文章并不回避 AI 对初级开发岗位带来的真实冲击，也不满足于重复“程序员不会被替代”的安慰性判断。作者试图回答的是一个更具体、也更现实的问题：在 AI 已经深度介入编码流程之后，工程师的核心价值是否正在从“写代码”转向“定义问题、设计验证机制、控制风险并完成系统交付”。
前一阵看到一条新闻，Claude Code 的创建者 Boris Cherny 在一档播客里说“编程被解决了”。这句话被国内不少自媒体反复引用，标题取得很重——“程序员的时代结束了”、“AI 替你写代码的时代来了”。
如果你真去翻那期原始播客，会发现节目的标题写得相当克制：「Head of Claude Code: What happens after coding is solved」——重点不在“被解决”，而在“之后”。Boris 在节目里坦白自己自去年 11 月起一行代码都没手写过，每天提交几十个改动都靠 Claude Code，但他紧接着补了一句：所有合并请求仍然要先过 Claude 自动审一遍，再过一道人工审核这一关。主持人 Lenny 在节目里替他总结了这件事——以前的瓶颈是写，现在是审。
这个细节在传播过程中被删掉了。但被删掉的不是无关紧要的修饰，恰恰是整件事最有信息量的部分：编程没有被消灭，它的瓶颈从一处转移到了另一处。问题是——转移到哪了？转移之后，做软件工程的人到底要做什么？
这些也是这篇文章想回答的问题。我首先会承认 AI 在替代论上确实命中的那一部分，然后再解释为什么“程序员要失业了”是夸大其词，最后尝试给出一个具体的判断：工程师的工作正在从一种活变成另一种活，那个新的活叫什么、怎么练。
先说真的那部分。
斯坦福数字经济实验室在 2025 年中期发布的一组数据显示，22 到 25 岁的软件开发者就业率，自 2022 年底高峰起已经下降了将近两成。这是一条相当陡的曲线。同期更多的数据也在印证——全球初级开发岗位过去一年缩水两到三成，英国科技行业的应届岗位 2024 年缩减了近一半，2026 年第一季度全球科技公司裁员里，明确归因到“AI 替代”的占比从去年不到一成跳到了五分之一。
数字背后是岗位品类层面的塌陷。我不需要列举太多类型，几个例子就够了：纯切图的前端、写增删改查的初级后端、套模板做后台管理系统的工程师、刚毕业还在练手的新人。这些岗位的共同点是任务清晰、变种不多、出错容易看出来——也就是说，是 AI 现在最擅长接管的那一类。
如果你的工作是五年前那种入门级任务的当代版本，那 Boris 那句话对你来说就是真的。这一段没什么好安慰的，我也不打算用“AI 创造了更多新岗位”这种空话来搪塞。新岗位会有，但不一定落到你头上、不一定按你期待的速度落下来。
让我举三个反例。
第一个反例，AI 编程最热情的鼓吹者之一、前 OpenAI 的 Andrej Karpathy。他在 2025 年初创造了一个词 vibe coding，大致意思是“完全把代码托付给模型，连改动都不看一眼“。但同年十月他自己开源了一个叫 Nanochat 的项目（一个迷你版的 ChatGPT 完整训练管线），他在仓库的讨论区里很坦白地写道：这个东西基本上是手写的，我也尝试过让 Claude 和 Codex 帮忙，但它们做得不够好，反而帮倒忙——大概是因为这个仓库离它们见过的数据分布太远了。vibe coding 这个词的发明者，自己做严肃技术项目时回到了手写。原因不是模型不强，是模型没见过这种东西。
第二个反例更有意思，来自 Anthropic 官方。他们在一篇讨论“长任务智能体框架“的工程博客里，公开承认了 Claude 的一个失败模式：我们观察到的最严重的失败模式之一，是 Claude 倾向于把一个功能标记为完成、但实际上没有经过真正的测试。模型厂家自己说出这种话的分量很重——你要他们承认这件事，跟让一家车厂承认自己刹车在某些工况下会失灵差不多。
第三个反例是数据。已经有相当多学术研究在跟踪 AI 写的测试到底靠不靠谱，结论很不乐观。AI 生成的测试普遍偏向“正常路径“——也就是只检查代码在最理想输入下不出错，不会去构造边界值和坏输入。一个被广泛引用的实验中，AI 生成的测试在变异测试（一种衡量测试到底能抓多少 bug 的方法）下的得分只有四成左右，而专业工程师的水平通常在七成以上。另一个实验里，AI 生成的测试准确率只有 6.3%——也就是每一百条测试里只有六条是真正在检查代码该检查的事，其他都在做无效断言。
这三个反例放在一起，指向同一个结论：AI 不是不能写代码，是不能可靠地验证自己写的代码。它能造，但它没法判断造的对不对。
那 AI 能不能搞定一个项目，分界线到底在哪？
很多人——也包括我自己最初的直觉——会把“AI 能不能搞定”对应到“项目复杂度”。小项目能全包，大项目就不行。但这个分法经不起推敲。Anthropic 自己用 Claude Code 来写 Claude Code，Cursor 团队用 Cursor 来写 Cursor，这些都不是小项目，是几十万行的产品代码。复杂度不是真分水岭。
更准的分法，我觉得是可验证性。具体说就是：一段代码写出来之后，确认它做对了的成本有多低？
如果验证成本低——比如写一个小工具函数，跑一下输入输出就知道——AI 可以全包，验证可以彻底自动化，错了立刻能发现。
如果验证成本高——比如改一段并发逻辑，错了可能要在生产环境跑几天才显现；改一段支付链路，错了直接是钱的损失；改一段老代码，错了破坏的是十年前某个人在某种特殊场景下做的兼容；重构一个跨服务的接口，错了影响的是其他团队的代码——这种代码 AI 不是不能写，是它写完之后你没法快速判断对不对，怀疑的代价远大于实现的代价。
这条线划清楚之后，很多事就好理解了。Simon Willison 给过一条非常硬的判断：“我不会把任何我无法向另一个人解释清楚的代码合并到我的仓库。”翻译成工程语言就是：你能不能验证代码——以你自己作为标尺——是合并的前提。Redis 作者 antirez 也说过类似的话，他用了一个更工程化的比喻——人是用来帮代码跳出局部最优解和错误的。这个“跳出”，靠的不是写代码的能力，是判断代码偏离没偏离需求的能力。两个人说的其实是一回事。
讲一个具体的故事。这是我自己最近一段时间的项目。
我用 Claude Code 加规范驱动开发的工作流，跑通了一个九个包的中型代码仓库（一个 AI 设计工程智能体）。其中有一个版本号叫 Sprint 3.3 的任务，是把现有的元素检查器从“只读”升级为“所见即所得 CSS 编辑面”——用户在预览界面里点中元素，直接拖滑块改 padding、改圆角、改阴影，改完一键让 AI 把变化写回源码。
这个 Sprint 又拆成 13 个子任务，前 12 个是实现，第 13 个是收官——跑手工测试和端到端自动化测试。AI 把前 12 个任务做完，每一个都有自动化测试覆盖，每一个都标了“通过“。流程顺得让我开始相信这个 Sprint 一定能合入主线。
但第 13 个任务，也就是真正的需求级验证，一上手就翻车了。
翻出来的不是一个坑，是三个。第一，发布到包仓库上的客户端插件版本是上一个 Sprint 锁的旧版本，新加的“修改样式”消息处理函数根本没打进去，真实用户场景下改属性界面纹丝不动。第二，端到端自动化测试默认进入了非选中模式，鼠标点击元素被吞掉，所谓“选中”的事件压根没触发过，前面跑通的那些“通过”全是假象。第三，跨测试套件复用同一个测试夹具时状态没清干净，五个核心场景的预览容器加载到的是错的项目地址，等了 15 秒还是错的——但每一个测试用例自己都标“绿”。外加四五处体验上的小问题：输入框焦点抢占、应用按钮点完后预览闪一下、撤销快捷键在某种边界条件下会越界。每一个单独看都不致命，叠在一起，这个 Sprint 我没法上线。最后我做了一个不太好做的决定——把整个 Sprint 从主版本里撤出，界面入口隐藏，底层代码全保留留作以后重启用。十二个任务的工作，被一个收官手测全盘掀翻。
我反复看这件事的成因，最后只能归到一句话——这句话其实就写在我自己项目的规范文件里：
测试和验证清单必须从需求出发推导，禁止“读代码反过来写测试”。读代码写出来的是“代码复读机”，只验证“代码按我写的方式运行”，不会发现“代码是否满足用户需求”。
AI 写的实现“通过”了 AI 写的测试，这没什么意外的。意外的是我之前居然真的相信了那个绿色的勾。前 12 个任务的“通过”，全部是 AI 在代码层面对自己代码的自我证明，不是从需求层面对代码的真正验证。这次翻车不是 AI 的能力问题，是我把“验证”这件事整个让 AI 接管了——而验证恰恰是它最弱的那一环。
写到这里要停一下，承认一个我故意还没展开的事。
如果上面那一段数据是对的——AI 真的在快速接管入门级的工作——那五到十年经验的工程师从哪里来？没有今天的入门级新人，就没有五年后的中级、十年后的资深。一个职业的“育苗床”如果被抽掉，这个职业会怎么演化？是只剩有经验的人和一群 AI、再没有新人？是新人的入口从“写代码起步”变成“第一天就直接做需求拆解和验证机制”？是中级和资深这一档的成长曲线整个变形？
这个问题我不打算在这篇文章里展开，它需要的不是一段而是一篇文章，而且更适合让人力资源研究者、教育工作者、招聘经理来回答，不该是一个一线工程师下结论。但我提它，是想说：当我们这些已经在职的工程师讨论“如何用 AI”时，其实是在一艘自己脚下正在下沉一层的甲板上讨论。这个事不能装看不见。
编者按：如果你对这一话题有自己的观察、经验或观点，欢迎联系本文编辑（微信 caifangfang_wechat【请注明来意】），一起讨论。
回到主线。
把上面这些放在一起，能画出一个我自己用了几年才明确下来的判断：在 AI 编程的时代，工程师的核心工作正在从“写代码”转向“系统性地把高成本验证的任务转化为低成本验证的任务”。
前者交给 AI，后者是人不可替代的部分。
这话听起来抽象，落到日常工作里其实非常具体。
写一个测试不再只是为了“抓 bug”——AI 写测试比你快，但它写的测试只覆盖正常路径——你的测试要从“用户怎么用、会踩哪些边界、错了怎么恢复”出发。写一个类型定义、一个接口契约不再只是“做文档”——它是给 AI 划定可以工作的边界，让它越界的时候你能立刻发现。写日志、写监控、写告警、写灰度、写回滚——这些过去被认为是“运维相关”的工作，今天变成核心工程能力。因为 AI 写的代码上线之后，你不再能像过去那样“读懂每一行所以放心”，你只能靠这些机制在它出错时第一时间知道。
代码评审也在变。过去你审的是“这段代码写得对不对、漂亮不漂亮”。今天 AI 一天可以提交几十个变更，你按这种速度审根本审不完——审不完不是程序员的问题，是审的方法已经不对了。新的审法是审验证机制本身：这个变更有没有对应的需求级测试、有没有可观测性兜底、有没有能在三十秒内回滚的开关。审一段代码可能要十分钟，审“这段代码周围的安全网齐不齐”可能只要一分钟。
Anthropic 自己的工程博客把这个判断写得很直白——模型再强，给它一个高层提示让它自己跑，它做不出生产级产品。让它能跑稳的，是套在模型外面那一圈他们叫 harness（直译大概是“挽具”，可以理解为给 AI 套上的工作骨架）的东西。换句话说，能不能交付高质量产品，不取决于模型能力，取决于框架设计能力。这不就是把“工程师的活”重新定义成“建框架而不是写代码”吗？
GitHub 2024 年开源的 Spec Kit、亚马逊 2025 年发布的 Kiro，都在沿着这条路推——把规范当成可执行的、第一类的工件，先写规范再写代码。规范驱动开发这个词在国内圈里也开始火起来。这不是孤立的产品发布，是一个行业方向。
回到本篇文章的目标读者——已经在用 AI 写代码、但还没把“怎么用 AI”系统化的 5 到 10 年经验的工程师。如果上面这套判断是对的，这一阵子你应该开始准备几件具体的事。
学会写“需求驱动”的测试，而不是让 AI 看着实现给你反推一份。具体做法是：拿到任务后先闭眼把“用户怎么用、会踩哪些边界、出错怎么恢复”列一遍，列完再让 AI 写代码、再把这份清单变成测试。这个动作 AI 替不了你。
把过去你认为是“运维或基础设施团队管”的那些事——可观测性、灰度、回滚——纳入你日常代码工作的一部分。这是你新的安全网，AI 写得越快越多，这张网就要越密。
重新校准你的代码评审节奏。不要再花时间审风格、审命名——这些 AI 已经能管。把时间花在审“这段变更周围的验证机制是否齐全”上。
主动找一些 AI 不擅长的活儿——业务边界模糊的需求拆解、跨团队接口的对齐、老代码的判断式重构、灰色地带的产品决策——把这些当成你的核心战场，把可以让 AI 跑的部分坚决让出去。
最后说回 Boris 那句话。“编程被解决了”听起来像一个时代的终结。但如果你听完整期播客就会发现，他自己的工作并没有变得轻松——他从写代码的人变成了同时操控五个智能体、每天审一堆合并请求、不停做架构决策和验证机制设计的人。他失去的是“亲手敲代码”这件事带来的心流和踏实感，得到的是更高的杠杆和更模糊的责任边界。
这不是一个程序员失业的故事，是一个程序员的工作内容被重新定义的故事。重新定义之后，你这 5 到 10 年攒下来的东西——对系统的整体感、对边界条件的直觉、对什么会出错的嗅觉、对人和需求的理解——其中相当大一部分非但没有贬值，反而比过去任何时候都更值钱。前提是你愿意把“会写代码”这块勋章先放下。
关于文中未展开的那个问题——如果 AI 持续吞噬初级岗位，未来五到十年后的资深工程师从哪里来？中高级工程师的培养链条将如何延续？如果你对这一话题有自己的观察、经验或观点，欢迎联系本文编辑（微信 caifangfang_wechat【请注明来意】），一起讨论。
Lenny Rachitsky.「Head of Claude Code: What happens after coding is solved（Boris Cherny 访谈）」. Lenny's Podcast, 2026 年 2 月. https://www.lennysnewsletter.com/p/head-of-claude-code-what-happens
Andrej Karpathy.「Introducing nanochat: The best ChatGPT that \$100 can buy」. GitHub Discussions, 2025 年 10 月. https://github.com/karpathy/nanochat/discussions/1
Anthropic.「Effective harnesses for long-running agents」. Anthropic Engineering Blog, 2025 年. https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
Simon Willison.「Not all AI-assisted programming is vibe coding (but vibe coding rocks)」. simonwillison.net, 2025 年 3 月. https://simonwillison.net/2025/Mar/19/vibe-coding/
Salvatore Sanfilippo (antirez).「Coding with LLMs in the summer of 2025 (an update)」. antirez.com, 2025 年. https://antirez.com/news/154
GitHub.「Spec Kit: Toolkit for Spec-Driven Development」. github.com, 2024 年 9 月起. https://github.com/github/spec-kit
经 Stack Overflow Blog 引用的斯坦福数字经济实验室数据.「AI vs Gen Z」. Stack Overflow Blog, 2025 年 12 月. https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/
一项关于 AI 生成单元测试有效性的实证研究. arXiv:2406.18181, 2024 年. https://arxiv.org/html/2406.18181v1
smile-design 项目源码与规范、记忆三件套. https://github.com/smilezyl2023/smile-design
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。