摘要：AI 编程真正颠覆的，不是代码，而是整个软件工程。从「Talk is cheap, show me the code」到「Code is cheap, show me the spec」的转变。从代码仓库、工具链、组织结构、流程机制，都从面向人类到面向 Agent 的转变。工程的复杂性没有消失只是在转移，人类的注意力不会过剩，也只是在转移。古法编程会永远存在。语义、唯一真源、执行约束和验证闭环真正拧成一个系统才重要而不是天天热炒新概念。

这几个月，如果你一直泡在 AI 编程的语境里，会有一种非常强烈的感受：新概念冒出来的速度，远远快过大多数人建立稳定认知的速度。

前两年大家在谈 Prompt Engineering，后来开始谈 Vibe Coding、Context Engineering、Spec-Driven Development，再到今年，Harness、Eval、Agent Loop、Intent Engineering 几乎铺天盖地。表面看起来，这是工具和术语的快速迭代；但如果你退一步看，就会发现这件事的本质根本不只是“多了几个新词”，而是几十年来默认成立的软件工程前提，正在被一点一点掀翻。

过去的软件工程，默认主语是人。人读代码，人写代码，人操作终端，人点发布按钮，人看监控，人做回滚，人串联需求、设计、实现、测试、运维这些环节。AI 再强，也只是一个局部辅助工具，帮你补全几行代码，或者生成一点模板内容。

但现在已经不是这个阶段了。

AI 编程真正恐怖、也真正迷人的地方在于：它正在把软件工程从“人亲自执行每一个环节”，改造成“人只保留少量关键注意力，而把越来越多执行环节交给 Agent”。

这不是效率优化，而是范式迁移。

一、真正被改写的，不是编码速度，而是软件工程的主语

很多人第一次感受到 AI 编程的冲击，来自于速度。

以前一个人写几天的代码，现在一个下午就能出来；以前要多人协作才能做出来的原型，现在一个人带几个 Agent 就能搞定；UI、脚本、环境配置、单测、文档、接口定义，几乎都能被 AI 快速拉起来。

但速度只是最表层的现象。

更深的一层变化是：软件工程的“默认执行者”变了。

斯坦福 CS146S《The Modern Software Developer》里有个非常重要的判断：软件开发正在从“从头编写代码”，转向“计划、AI 生成、修改并重复”的迭代工作流；开发者的角色，也在从写代码的人，转向管理 AI Agent 的人。这个判断之所以重要，不是因为它新鲜，而是因为它把很多人已经隐约感受到的现实，说透了。参考： 

• • Stanford CS146S / The Modern Software Developer^[1]

我越来越强烈地觉得，今天的软件工程已经可以被理解为一个新的循环系统：不是以前那种每个环节都由人直接介入的流水线，而是一个由 LLM 驱动、由多个子 Agent 执行、由人类做少量高杠杆决策的 Agentic Loop。

过去我们讲的是 human in the loop。软件工程的每个环节都是人来参与，不同的环节需要不同的人来协作，比如产品经理提出需求、架构师设计、程序员开发、QA 来测试、SRE来部署发布运维，每个环节都是不同的人来担任不同的角色，在一次完整迭代或者版本发布的生命周期中，和Agent Loop 类似，但是每个节点都是 human in the loop。现在越来越多的真实场景，变成了：human in the loop 仍然存在，但只存在于最关键的地方。

这意味着什么？

意味着人不再是每一步的执行者，而更像这个系统的设计者、裁判者、约束制定者、最终兜底者。

人类真正稀缺的，不再是手写代码的体力，而是：

1. 1. 定义问题的能力
2. 2. 做 trade-off 的能力
3. 3. 识别偏航的能力
4. 4. 设计约束和闭环的能力
5. 5. 在复杂系统中分配有限注意力的能力

如果说传统软件工程的主语是“程序员写代码”，那么 AI 编程时代的软件工程主语，正在变成“程序员设计一个让 Agent 持续正确干活的系统”。

二、代码的重要性在下降，但工程的重要性在上升

很多人会把这轮变化理解为“以后代码不重要了”。这个说法如果不展开，很容易被误解；但如果展开来看，它其实触到了一个很深的事实：

代码并没有消失，但代码作为唯一核心资产的地位，正在下降。

为什么？

因为在 Agent 时代，代码越来越像一种中间产物，而不是最终真源。

GitHub 近年的公开方向已经非常明确：从 code is the source of truth，逐步走向 spec 作为共享真源，让 Agent 围绕 spec 去生成、修改、测试和校验。斯坦福课程里也有一个很刺眼但非常准确的表达：Spec is the new source code。生成出来的代码，只是意图的“有损投影”。参考： 

• • Spec-driven development with AI^[2]
• • Stanford CS146S / The Modern Software Developer^[1]

这件事如果再往前推一步，结论会更加激进：

在很多场景下，真正要长期维护的，不再是某一版具体代码，而是下面这些东西：

1. 1. 语义是否清晰
2. 2. 规范是否明确
3. 3. 真源是否唯一
4. 4. 上下文是否干净
5. 5. 工具链是否可稳定调用
6. 6. 约束是否足够强
7. 7. 验证闭环是否完整

一旦这些东西稳了，代码本身就变得越来越“可再生”。反过来，如果这些东西不稳，哪怕你暂时生成了一份看起来很漂亮的代码，它也大概率只是一份更快腐烂的中间产物。

程序员以前最自豪的话：「Talk is cheap, show me the code」，现在变成了 「Code is cheap, show me the spec」。

所以真正没有被削弱的，不是工程，而是恰恰相反：工程在 AI 时代变得更硬了。

工程的本质，仍然是通过系统性的方法，去消除风险、不确定性，进而提升确定性。而 LLM 恰恰是一个天然带着不确定性、漂移、幻觉、上下文腐烂的系统。这就决定了：模型越强，越不能靠“感觉”；模型越强，越需要工程。所以才有了这么多的概念，从 Prompt Engineering，到 Context Engineering，再到今年的 Harness Engineering。工程的复杂性不会消失，只会转移。

三、AI 时代最核心的新基础设施，不是 Prompt，而是语义、真源、约束和闭环

如果今天一定要我给这轮范式变化抓几个核心词，我会选这四个：

1. 1. 语义
2. 2. 唯一真源
3. 3. Harness / 执行约束
4. 4. Eval / 测试 / 质量门禁

1. 语义：解决“它懂不懂”

过去一个团队语义不清，很多时候只是沟通成本高一点。你说错了，资深同事大概率能靠经验把你的意思补回来；文档有点乱，大家也能靠隐性知识凑合往前走。代码和文档不一致，这是家常便饭，甚至有些团队文档都没有、注释也乱，都没关系，组里的老人自然知道是怎么回事，出了问题只要老人在都能稍微心安。

AI 不行。

AI 遇到模糊语义，最常见的问题不是不会做，而是理解错了还做得特别快。

一个词定义不清，它就可能把两个职责揉在一起。一个边界没划清，它就可能按自己的统计经验补出另一个系统。你以为它在实现你的意图，实际上它只是在实现它“猜出来的那个意思”。

所以语义在 AI 时代不再只是“写得优雅一点”的问题，而是系统是否会偏航的问题。

2. 唯一真源：解决“它听谁的”

人类工程师能忍受多版本真相并存。PRD 一套、README 一套、注释一套、接口文档一套、口口相传的经验再来一套，很多团队照样活着。

AI 也能“活着”，但它会把这些冲突信息揉成一个平均值，然后高效率地产出一个 能跑、也自洽，但不是你真正要的东西。

所以唯一真源真正解决的，不是“世界上只能有一份文档”，而是：

每一个关键判断，都必须有一个清晰的主参考源。

产品行为听谁的？模块边界听谁的？接口定义听谁的？测试预期听谁的？

这些不明确，AI 就只能猜。而一旦进入“猜”的阶段，所谓高效率，很多时候只是高效率地跑偏。这时候，AI 不是代码加速器，而是错误放大器。

3. Harness：解决“它怎么不跑偏”

今天很多人谈 Harness，会让一线工程师觉得虚，不是因为这个词没价值，而是因为太多人只谈概念，不谈约束。

真正的 Harness 不是“给 AI 更多自由”，而是“给 AI 更可靠的轨道”。

OpenAI 今年这篇 Harness Engineering，把这个方向系统化地摆到了台前，本来就在强调：Agent 不是丢进上下文里自己发挥，而是要被放进一个可执行、可验证、可迭代、可回收的工程回路中。Anthropic 对 long-running agents、context engineering、eval-driven development 的几篇文章，也都在指向同一件事：关键不是模型会不会说，而是整个系统会不会失控。参考： 

• • Harness engineering: leveraging Codex in an agent-first world^[3]
• • Effective context engineering for AI agents^[4]
• • Demystifying evals for AI agents^[5]

如果一句话说 Harness 到底在干什么，我更愿意这么定义：

Harness 不是材料包，而是一套工作约束。

它要回答的不是“AI 能看什么”，而是：

1. 1. 先看什么，后看什么
2. 2. 哪个来源权重更高
3. 3. 哪些操作允许做，哪些不能碰
4. 4. 做完必须过哪些检查
5. 5. 不满足什么条件就不能继续
6. 6. 一旦偏航怎么拉回来
7. 7. 到什么程度必须停下来交还给人

4. Eval：解决“它到底做对了没有”

语义清晰，不代表结果就一定正确。真源明确，不代表执行过程就一定不变形。Harness 完整，也不代表最终产出一定满足预期。

所以最后一定还得补上 Eval、Tests、Quality Gates。

前面那三件事解决的是：它知不知道该怎么做。而 Eval 解决的是：它最后到底做对了没有。

如果没有这一层，Agentic Loop 就只是一个自我感觉良好的自动化系统；如果有了这一层，它才可能真正进入工程生产。

上面这四点，恰恰是新的软件工程中最不确定性、最复杂的部分，代码不重要了，随之而来是新的复杂性和不确定性，并不容易解决。所以，模型的差距在变小，而这语义、真源、Harness、Eval 决定了模型的上限。

四、仓库、工具链、组织架构、流程机制，都会从“面向人”转向“面向 Agent”

这是我最想强调，也最容易被低估的一点。

很多人谈 AI 编程，还是在“代码生成工具升级”这个层面理解它。但如果你真的在工程现场里持续使用 Agent，就会越来越发现：被改写的不是某个写代码步骤，而是整个软件工程环境。

1. 仓库会变

过去我们设计代码仓库，默认优先级是人类可读性、人类导航体验、人类理解成本。 甚至代码规范、Code Review 都是基于可读性来考虑的，而最好的可读性某些时候是团队的代码一致性。现在这个优先级正在变化：仓库首先要让 Agent 能高效定位上下文、加载约束、理解项目结构、找到唯一真源。

这也是为什么越来越多项目开始重视 CLAUDE.md、AGENTS.md、规则目录、spec 目录、渐进式披露的规范组织方式。

仓库不再只是人类工程师的阅读介质，也正在变成 Agent 的操作界面。

2. 工具链会变

传统工具链大量围绕 GUI 和人类交互设计。但 Agent 真正需要的是：稳定的 CLI、结构化输出、明确权限、可组合调用、可嵌入工作流的能力。现在，还要考虑这些工具的经济性，毕竟 Token 越来越贵了，成本也会成为工具链设计的重要变量。

所以可观测系统、项目管理系统、测试系统、发布系统、日志系统、存储系统、数据库工具，都会越来越需要被 Agent 化、CLI 化、MCP 化、结构化。

不是“把原来的人类界面搬成命令行”就完了，关键是要让这些系统能够成为 Agent 的五官、四肢和执行器。

LLM 本身只是一个大脑。如果没有这些外部系统，它什么都看不见，也什么都做不了。

这对这些工具链，也是很大的挑战，使用对象不同了，可能工具链的设计逻辑就不同了，不只是套个CLI 的壳，做个 MCP 就完事了。工具链输出对 Agent 的可读性、经济性、安全性，都是挑战。

3. 组织架构会变

过去前端、后端、测试、算法、产品、运维之间的边界，本质上建立在“实现工作需要不同专业角色分别动手”这件事上，越是大厂，分工越明确，职责越清晰。

一旦执行层开始被 Agent 大规模吞掉，这些角色边界就一定会重新被压缩、重排、模糊化。任何人借助 AI 好像都能成为六边形全栈，设计师有 Pencil、Google Stitch、Claude Design，程序员有 Coding Agent，执行型测试更不需要了，Computer Use 、Browser Use 几乎都是 Coding Agent 的标配。一部分 SRE 操作会被吞掉，做个 Sre Agent，连接各种系统，跑在 OpenClaw 或者 Hermes Agent 里，从拨测、问题发现、定位、修复、验证，一条龙全给干完了。 发现和解决一个问题，还给你自动生成一个 Skill，以后都按这样的 SOP 来，还要啥复盘呢。

但这不意味着“人人都能干一切”，而是意味着：

1. 1. 原来很多靠岗位边界维持的分工，会失去一部分存在基础
2. 2. 真正有价值的边界，会越来越建立在系统理解、架构权衡、业务判断和质量责任上
3. 3. 很多开发者会从“功能实现者”转向“系统工程师”或“Agent 管理者”

产品经理不会因为 AI 就天然获得工程落地能力；但纯粹建立在“我会写这类代码”上的职业壁垒，也一定会被冲击。

4. 流程机制会变

从需求、设计、开发、测试、上线，到观测、回滚、复盘，整个链路都会越来越像一个持续运行的 Agentic Loop。

以前每个环节都是人工介入；以后越来越多环节会变成：

1. 1. 人定义目标
2. 2. Agent 拆解任务
3. 3. Agent 调用工具
4. 4. Agent 执行实现
5. 5. Agent 自测与回归
6. 6. Agent 读取观测结果
7. 7. 人在关键节点判断是否继续、回滚、灰度放量、扩缩容

一旦这个循环稳定下来，软件工程的“流程”这个词，本身都会被重新定义。

五、人不会消失，但人会被迫迁移到更高杠杆的位置

这轮变化里，最容易引发焦虑的问题往往是：以后还有程序员吗？

我的答案并不极端。

我不认为程序员会消失。但我也不认为“程序员的主要作用还是写代码”这件事还能长期成立。

更准确地说，程序员这个角色会发生两层分化。

第一层：大量开发者会成为 Agent 使用者、系统工程师、约束设计者

他们的核心价值不再是“能手写多少代码”，而是：

1. 1. 能不能把需求说清楚
2. 2. 能不能把领域语义说清楚
3. 3. 能不能建立清晰真源
4. 4. 能不能设计出可靠的反馈闭环，去验证 AI 做的对不对
5. 5. 能不能在多 Agent 环境里做正确裁决，做出正确的 Trade-Off，而不是让 AI 瞎做决定

这也是为什么我越来越觉得，“需求规划师”这个说法并不准确。因为这不是简单的需求抽象，而是更底层的工程系统设计。还是那句话，复杂性不会消失，只是转移了。

第二层：古法编程永远存在，但不会是主流

这是我非常坚持的一个判断。

AI 编程会越来越强，但古法编程不会消失。尤其是在那些需要极强精细控制、极深 trade-off、极高性能极限、极强稳定性要求、底层系统与新型基础设施场景里，人类手工精雕细琢的代码仍然会长期存在。并且，肯定还会有人坚持自己写代码，就像工业制造已经这么发达的时候，还会有人坚持做手工，享受 Hand-Made 的充实感。

写一个中间件、设计一个新的数据结构、定义一套新运行时、构造一门新语言，这些事情背后真正关键的，不只是“能不能把代码敲出来”，而是为什么这样设计、解决什么问题、做了哪些取舍。

这部分，至少在相当长一段时间里，仍然会高度依赖人。

所以未来不是“AI 编程取代古法编程”，而更可能是：

AI 编程和古法编程长期并存。

前者吞掉大量确定性执行工作，后者保留那些极强控制、极深创造性、极重权衡的部分。会有人继续坚持这种方式，像手艺人一样保留程序员最初的工匠精神。

以后程序员到底叫什么呢？不是「需求规划师」，我觉得更合理的是「系统工程师」，可以不是那么懂代码语法，但是什么都得懂一些。不分什么前端、后端、测试、运维了。

六、好代码的标准会变，甚至连编程语言和交互方式都可能变

这可能是最激进、但也最值得认真想的一层。

如果软件工程真的正在从面向人类执行，迁移到面向 Agent 执行，那么很多我们过去默认成立的“好代码标准”，都要重新被拷问。

过去我们强调：

1. 1. 人类可读
2. 2. 人类易维护
3. 3. 命名优雅
4. 4. 抽象克制
5. 5. 分层清晰

这些当然不会瞬间失效。但未来还会新增另一套标准：

1. 1. Agent 是否容易理解
2. 2. Agent 是否容易定位边界
3. 3. Agent 是否容易获得正确上下文
4. 4. Agent 是否容易调用正确工具
5. 5. Agent 是否容易在约束下稳定修改

当这套标准越来越重要时，仓库形态会变，规范组织方式会变，工具协议会变，甚至连编程语言都可能开始变化。

现在所有的工具，包括代码工具链和代码本身，几乎都是面向人类设计的。但未来很可能有越来越多东西，是首先面向 Agent 设计的。

过去，程序员->代码（编程语言）->计算机，现在是 系统工程师->自然语言->Coding Agent->代码->计算机，其实链路是更复杂了，而大家都知道，语言的魅力和多样性是非常广的，不同的上下文，其实含义差别巨大甚至完全相反。自然语言->Coding Agent 就是新的范式中引入的不确定性环节。

我有一个预测：未来的某些编程语言，也许仍然跑在 Runtime 或 VM 上，但它们的表达方式，可能会越来越偏向 Agent 理解，而未必天然适合人类阅读。会有适合 Agent 而非人类的编程语言出现吗？

如果真走到那一步，变化就不只是软件工程范式变了，甚至可能连计算机科学的一部分基础假设、人机交互方式、终端设备形态，都会受到牵引。

这未必会在明天发生。但它已经不再只是科幻层面的猜想。

七、为什么很多团队会被 AI 反噬：因为它放大的首先不是能力，而是混乱

我越来越相信，AI 进场之后，首先被放大的不是能力，而是混乱。 人类还没尝到 AI Coding 的苦头吧，我每年都追踪全球互联网故障 case，今年我预测 AI 的锅会很多，是不是再也不会有开发背锅、程序员祭天的事了^_^。任何新事物都是从质疑、接受、大规模爆发、运营、治理的过程，AI Coding 也不会例外。

项目语义不清，AI 会更快做错。真源不唯一，AI 会更快跑偏。约束不完整，AI 会更快扩散技术债。验证闭环薄弱，AI 会更快把错误写进系统。

所以 AI 编程的最大风险，不是“写得慢”，而是 错误放大器。

这也是为什么我对很多运动式全面拥抱 AI 的公司，天然保持警惕。烧 Token 没用。如果一个团队没有准备好语义治理、真源治理、工具链治理、约束治理和验证闭环，只是把模型接进来、把产能拉满，那么它得到的很可能不是生产力奇迹，而是更快的混乱扩散。

现实里，这种反噬往往长这样：

1. 过度设计，规整但不精良

AI 很容易给你拉出一个“看起来非常完整”的方案，但它未必优雅，未必克制，未必真的适合当前阶段。

它会套大量参数、抽象和配置，把一个本来不复杂的问题做成一个维护噩梦。 给你兼容一大堆不会存在的可能性，过度封装、过度兼容、过度设计，我遇到过很多了，以至于我不得不边让 AI 写代码，边让 AI 重构的经历。它写出来的东西，很多时候不是精良，而只是规整。 AI 写代码会永远自洽。你提醒的时候，态度永远很好。

我到现在仍然认为：最优美的代码，永远是富有创造力、想象力的人类写出来的。

2. 写得太快，所以更容易烂

过去一个人一天写不了太多代码，错误扩散速度天然有限。 我记得刚入行的 20 年前，有人告诉我平均每人每天不会超过 10 行代码。现在 Agent 一口气可以拉出很大一坨实现，设计问题、分层问题、语义问题、技术债问题，都会被同步放大。

于是你会发现，AI 写得越快，越要更早、更频繁地 review、重构、拉回设计方向。很多问题不一定是 bug，而是如果现在不改，后面只会越改越乱。

人类程序员的产能有限，但是 AI 写的屎山，会让你欲哭无泪，两眼一抹黑，因为你看不懂 AI 写的代码了，写的太快、堆得太多、复杂性太大。

3. AI 真的会摸鱼、会丢代码、会甩锅

这听起来像段子，但它恰恰是工程现实。这都是我遇到过的真实体验。

LLM 天生就有幻觉、漂移、上下文污染、跨会话不稳定这些问题。多个 Agent 交替执行时，代码可能丢失；任务看似完成，实际没有产出；上一轮引入的问题，下一轮会被它用一种特别像职场甩锅的口吻推开。

当这些问题出现在真正的工程现场里，它们的危害一点都不抽象。

你不盯着，它就可能给你挖坑。你不验证，它就可能把错误一路写到后面。你无限信任，它就会教育你什么叫不确定性。

所以 AI 编程绝不只是“让模型帮我写代码”，而是一套系统性工程：要给 Agent 配马鞍、缰绳、甚至嚼子；要持续给它约束、反馈和回收机制；不是一锤子买卖，也不存在无限信任。

八、未来真正稀缺的，不是会不会用模型，而是能不能把概念变成系统

今天再回头看这轮 AI 编程浪潮，我越来越不相信那些最表层的判断了。

真正的分水岭，不是你会不会写 Prompt。也不是你会不会喊 Harness。甚至不只是你用的是哪个模型。

真正的分水岭是：

你能不能把语义、真源、上下文、执行约束和验证闭环，真正拧成一个系统。

只有做到这一步，AI 才不再只是一个“很会写”的东西。它才开始变成一个“能在工程现场里真正干活”的东西。

模型当然重要，但大部分常规编码任务上，模型差距已经不是唯一决定因素。但模型更像发动机。对很多人来说，2.0T 涡轮增压和 3.0T v6，感受不到太大差别。

真正决定你能不能跑得快、跑得稳、跑得不偏的，是另外几样东西：

1. 1. 语义是路
2. 2. 真源是地图
3. 3. Harness 是轨道
4. 4. Eval 是护栏

没有这些，模型越强，很多时候只是更快地把你带到错误的地方。

所以如果一定要用一句话总结我对这轮变化的判断，那就是：

AI 编程带来的，不是“程序员写代码更快了”，而是“软件工程正在从以人类执行为中心，转向以 Agent 执行为中心；人类则退到更少、更关键、也更高杠杆的位置上”。人的注意力不会过剩，只会转移，就像有了 AI 之后，人并没有觉得更闲而是更忙了

这背后被重写的，不只是编码方式，而是仓库、工具链、组织架构、流程机制、质量体系，乃至“什么叫好代码”“什么叫程序员”“什么叫软件工程”本身。

几十年的软件工程范式，确实正在被彻底改写。

而这，可能才刚刚开始。

引用链接

[1]Stanford CS146S / The Modern Software Developer: https://themodernsoftware.dev[2]Spec-driven development with AI: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/[3]Harness engineering: leveraging Codex in an agent-first world: https://openai.com/index/harness-engineering/[4]Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents[5]Demystifying evals for AI agents: https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents