古法编程与 Vibe Coding：两条曲线背后的工程真相

一张图把当代程序员分成了两拨人。
上面那条曲线叫「古法编程」，下面那条叫「Vibe Coder」。
它们看起来都在讲"成长"，但只有一条真的在讲成长——另一条讲的是信心的涨落。
这篇文章要做的，是把这张图拆到骨头里，然后回答一个真问题：在 AI 已经把写代码的成本打到接近于零的时代，一个软件工程师的能力到底应该怎么积累？

本文收获：

一句话结论：AI 只压缩了"实现"的成本，没有降低"理解与承担"的成本。所以被压缩的是写代码的时间，没被压缩的是形成判断力的过程——这就是为什么古法那条曲线在 AI 时代反而更值钱。

引言：一张被疯传的图，和它没说完的话

这张图你一定见过，或者至少见过它的变体。

[如下案例图片来源声明：视频号 AIGeeks ]

上半部分，标题是「古法编程」。纵轴标注为知识 / 技能，横轴是时间。曲线是一条标准的 S 形：初期缓慢爬升，中段陡峭上升，后期趋于平缓，形成一段长长的高原。曲线上标了十个节点，从最左下角的「1. 编程基础」开始，依次是 HTML / CSS、JavaScript、数据结构、算法、后端开发、数据库、系统设计、DevOps 与部署，最后落在右上角的「10. 理解代码」。

下半部分，标题是「Vibe Coder」。纵轴标注为信心（≠ 技能）——括号里那四个字是这张图的灵魂，也是它的全部笑点所在。横轴同样是时间。曲线在极短的时间内几乎垂直拉起到顶端，然后在上方维持一个漫长的平台期，最后毫无预兆地、像悬崖一样直接摔到谷底。曲线上标了十一个节点：安装 Cursor、问 AI、Ctrl C / Ctrl V、跑起来了！、部署到生产环境、我基本算是高级工程师了、我什么都能做！——这是登上平台期的七步。然后剩下的四步是这样的：生产版本出事了、为什么会这样？、调试 AI 生成的代码、为什么改了 47 个文件？！

笑完之后，很多人会把它当成一个"AI 翻车现场"的段子转发出去。但作为一个在软件工程里待过足够久、又在过去两年里亲手把 AI 塞进研发流程每一个环节的人，我想说：这张图的信息量远不止一个段子。它精准地指出了 AI 时代工程师能力建设中最核心的一个陷阱，而且它给出的诊断是准确的、量化的、可验证的。

可惜它只给了诊断，没给处方。

这篇文章要做三件事：

1. 把两条曲线逐点拆开，解释每一个节点背后真正的知识结构，解释为什么古法编程那条曲线必然长成 S 形，而 Vibe Coder 那条曲线必然长成"上凸 + 断崖"。
2. 把断崖的成因讲透。不是"AI 不靠谱"这种废话，而是从复杂度守恒、上下文窗口、隐性契约、可观测性缺失、归因错误这五个角度，说清楚"生产版本出事了"是必然事件而不是运气不好。
3. 给出一条真正可行的第三条曲线。它既不是苦修十年的古法，也不是裸奔的 Vibe，而是一条把 AI 当杠杆、同时把工程纪律保留下来、斜率可控、没有断崖的路径。

如果你只想看结论，可以直接跳到第七章的纪律清单；但如果你真的想理解为什么，请从第一章开始——因为这张图最容易被误读的地方，恰恰是它的坐标轴。

第一章 逐点解剖：两条曲线到底在说什么

1.1 古法编程：一条教科书级的 S 形学习曲线

先看上面那条。

它的形状非常标准：起步阶段斜率小，中间段斜率大，末端斜率趋近于零。这不是艺术家随手画的，这是几乎所有人类技能习得的共同形状——从学游泳到学小提琴，从下围棋到学微积分，都是这个形状。

为什么会是 S 形？原因藏在每个节点的前置依赖里。

看那十个节点的顺序：编程基础 → HTML / CSS → JavaScript → 数据结构 → 算法 → 后端开发 → 数据库 → 系统设计 → DevOps 与部署 → 理解代码。

这个顺序不是按"重要性"排的，也不是按"年限"排的，而是按依赖关系排的。每一层都建立在下面所有层之上：

• 没有编程基础（变量、条件、循环、函数、作用域），你没法写 HTML 里的任何一行脚本逻辑，甚至没法理解"字符串拼接"为什么会报错。
• 没有 HTML / CSS 提供的文档结构和盒模型直觉，你无法建立"页面是一棵树"的空间认知，后面所有前端调试都无从下手。
• 没有 JavaScript 提供的异步模型（事件循环、Promise、async / await），你不可能理解"为什么这个值在这一行还是 undefined"。
• 没有数据结构（数组、链表、栈、队列、哈希表、树、图），你在写业务代码时会一遍遍地用 O(n²) 的嵌套循环去解决问题，并且在数据量上来之后完全不知道发生了什么。
• 没有算法（复杂度分析、递归、分治、动态规划），你写不出一个能跑的排序，更看不懂框架源码里的任何一段核心逻辑。
• 没有后端开发（HTTP、REST、鉴权、中间件、并发模型），你无法理解"前端拿不到数据"到底是前端的问题还是服务端的问题。
• 没有数据库（范式、索引、事务、隔离级别、慢查询），你会写出那种"开发环境 100 条数据跑得飞快、生产环境 100 万条数据直接超时"的接口。
• 没有系统设计（分层、缓存、消息队列、幂等、限流、一致性取舍），你的系统一旦并发上升就会像纸牌屋一样塌掉。
• 没有 DevOps 与部署（构建、镜像、CI/CD、灰度、回滚、监控），你根本不知道"我本地是好的"这句话在生产环境里值几分钱。
• 而理解代码这个词被放在金字塔顶端，意思是：到这里，你终于能在一分钟内读完一个陌生仓库的核心文件，并且对"它为什么这么设计"产生判断。这不是一项技能，这是前面九层全部长在脑内之后，涌现出来的能力。

这是一个依赖链，不是一个清单。 这就是古法编程必须慢的第一个原因：你不能跳级。你可以跳过某本书的某一章，但你没办法在缺少数据结构认知的情况下真正掌握算法，也没办法在缺少异步模型认知的情况下写出可靠的后端服务。

但依赖链只解释了"为什么有台阶"，还没解释"为什么是 S 形而不是直线"。

S 形中间那段陡峭，来自复利效应：当节点 1 到 5 的基础能力都具备之后，学习 6 到 8 的速度会突然变快。因为你不再需要为每一行代码去查语法，你的大脑有了"空闲的带宽"去理解真正的概念——为什么要有索引、为什么要有缓存、为什么要做幂等。前面五层花掉的时间，买到的不是五个知识点，而是后面所有知识点的学习效率。

S 形末端那段平缓，来自收益递减：节点 9 到 10 之后，剩下的空间不是"更多知识"，而是"更深的判断力"，而判断力只能靠真实项目里的失败来磨，不能靠读书。所以曲线必然变平——不是你学不动了，而是这条曲线的纵轴度量的是"知识 / 技能"，而真正的高阶能力（判断、取舍、品味）在这根轴上几乎测不出来。这是这张图的一个隐藏缺陷，我们放到第九章再回来说。

1.2 Vibe Coder：一条被误读为 S 形的钟形断崖

现在看下面那条。

很多人第一眼看到它，会觉得"这不也是 S 形吗？只是快得多"。这是最危险的误读。

仔细看它的纵轴：信心（≠ 技能）。

四个字把这条曲线的性质彻底改变了。上面那条曲线测量的是你会什么；下面这条曲线测量的是你觉得自己会什么。这两件事在古法编程里大体是对齐的（因为你每一步都要自己把代码跑通，能力增长会被现实不断校准），但在 Vibe Coding 里，它们是两条完全不同的曲线，而图里画出来的只是那条虚高的信心线。

所以下面那条曲线的正确解读是：

• 第一段近乎垂直的上升，不是技能在涨，是信心在涨。而信心为什么涨得这么猛？因为 AI 给了你一种前所未有的东西：一个几乎即时、几乎从不拒绝、几乎总是自信的回答。
• 中间的漫长平台期，标注着「我基本算是高级工程师了」和「我什么都能做！」，这不是能力高原，这是幻觉高原。因为在这段时间里，你确实做出了很多东西——一个小工具、一个仪表盘、一个内部系统，它们都跑起来了，都部署上去了。所有可见的证据都在告诉你：我行。
• 然后断崖。断崖的触发点写得很清楚：「生产版本出事了」。注意，出事的原因不是"你变笨了"，而是现实的复杂度终于超过了 AI 那层薄薄的抽象所能覆盖的范围。
• 最后三个节点构成了一条向下的自我诊断链：「为什么会这样？」——你在找原因，但你手里的信息不足以定位原因；「调试 AI 生成的代码」——你试图进入调试，但你发现自己不拥有被调试对象的完整心智模型；「为什么改了 47 个文件？！」——这是整张图最精彩的一笔，它描述的是一个极度具体的、每一个 Vibe Coder 最终都会遇到的画面。

这十一个节点，如果换成更学术的语言，讲的是这样一个过程：

一个人用极低的成本获得了"产出"，把"产出"误认为"能力"，用"产出"喂养了"信心"，然后在一次没有任何预备知识可以支撑的复杂故障面前，同时失去了产出、能力和信心。

这是一个完整的、逻辑自洽的悲剧结构。而且它是可预测的——这才是这张图真正让人后背发凉的地方。它不是一张"某些倒霉蛋会遇到的意外"的图，它是一张"绝大多数走这条路的人都会遇到的、有明确触发条件的、几乎不可能绕开的"的图。

1.3 坐标轴才是这张图真正的信息量

现在把两条曲线叠在一起看，你会发现那张图最大的幽默感来自一个细节：

上面那条曲线的纵轴是"知识 / 技能"，下面那条曲线的纵轴是"信心（≠ 技能）"。

画图的人其实已经告诉你答案了——这两条曲线根本不在同一个坐标系里。它们不可比，也不该被拿来问"哪条更好"。

但只要你把下面那条曲线的真实纵轴替换成"技能"，会发生什么？它的形状会变成什么样？

答案是：它会变成一条几乎贴着地面的直线，只在极少数地方有微小的起伏。

因为 Vibe Coder 在节点 1 到 7 做的事情——安装 Cursor、问 AI、Ctrl C / Ctrl V、把东西跑起来、部署上去——这里面几乎没有任何一项会沉淀为可迁移的技能。

• 安装 Cursor 是配置，不是技能。
• 问 AI 是提问，提问能力算技能，但它和"写软件"不是同一类技能。
• Ctrl C / Ctrl V 是复制粘贴——它甚至不能被称作一项技能，它是技能的替代品。
• 「跑起来了」是一个状态，不是能力。一个东西能跑，可能是因为它确实对，也可能只是因为你还没踩到让它崩的那条路径。
• 「部署到生产环境」在今天的工具链下确实需要一点操作知识，但它考的是"会不会点按钮"，不是"懂不懂系统"。

所以当断崖到来时，问题不是"我技能下降了"，而是——

我从来就没有积累起能应对这个问题的技能，而我花了几个月以为自己有。

这就是这张图的全部悲剧：它暴露的不是 AI 的不可靠，它暴露的是"能力形成机制"被短路的后果。

（这里要补一句公道话：Vibe Coding 不是一无是处，恰恰相反，它在特定场景下是非常强力的工具。它的问题不在于"用 AI 写代码"这件事本身，而在于很多人把它的产出当成了能力的证明，并且跳过了所有会让能力真实增长的环节。这一点我们会在第六章详细展开。）

第二章 古法编程为什么必须那么慢

2.1 十级台阶，每一级真正在训练什么

前面我们讲了依赖链，但依赖链只说明了"顺序"，没有说明"内容"。这一节我们把十级台阶逐级拆开，看每一级真正在训练的能力是什么。这一步很重要，因为很多人（尤其是 Vibe Coder）会以为这些台阶是"知识的堆叠"，是可以被 AI 替代的。它们不是知识，它们是认知结构。

第 1 级：编程基础。

表面内容：变量、类型、条件、循环、函数、数组、字符串、作用域、错误处理。

真正训练的东西：精确性。

这是所有台阶里最被低估的一级。写代码这件事的核心特征不是"表达想法"，而是"把你的想法翻译成一台不会猜你心思的机器能执行的精确指令"。少一个分号、把 == 写成 =、把索引从 0 开始还是 1 开始搞错，结果就是错——不是"差点对"，是"错"。这一级训练的是一个心理习惯：在把东西交给机器之前，先自己在脑子里跑一遍。 这个习惯，是所有后续调试能力的地基。一个没有这个习惯的人，在 AI 时代会表现出一种典型症状：他看不出 AI 给的代码有问题，因为他从没被机器用"报错"这件事反复抽打过，他没有那种"这里不对劲"的直觉。

第 2 级：HTML / CSS。

表面内容：标签语义、盒模型、flex / grid、层叠与优先级、响应式。

真正训练的东西：结构与表现分离的思维方式，以及"状态可视化"的能力。

CSS 看起来是最"不编程"的一级，但它训练了一个非常关键的心智模型：一棵树 + 一组规则 + 优先级决定的最终结果。这个模型在后面的很多地方会复用——DOM 是一棵树，对象继承链是一棵树，组件树是一棵树，依赖关系是一张图。而 CSS 的层叠优先级（specificity）更是提前教了你一件工程上极其重要的事：当多个规则同时生效时，"谁赢"不是由直觉决定的，是由一套明确的优先级规则决定的。 你后来在数据库里遇到的索引选择、在系统设计里遇到的缓存层级，本质上都是同一类问题。

第 3 级：JavaScript。

表面内容：原型、闭包、this、事件循环、Promise、async / await、模块化。

真正训练的东西：异步与状态的思维。

这是很多人的第一道真正意义上的分水岭。同步代码的思维是"从上到下，一行接一行"，而真实世界里的一切——网络请求、文件 IO、用户交互、定时任务——都是异步的。异步带来的东西叫状态：一个值在你读到它的那一刻，可能已经变了。this 指向谁取决于谁调的，闭包捕获的是变量而不是值，事件循环把任务分成宏任务和微任务……

这一级训练的能力是：在脑子里同时维护多个时间线上发生的事情。 这个能力，在后来处理并发、处理分布式系统、处理"为什么这个订单被扣了两次款"的时候，是同一套肌肉。跳过这一级的人，在 AI 时代会遇到一种特征性困惑：AI 给他的代码"看起来完全合理"，但就是有时候对、有时候不对——因为他没有能力去想象"两个请求同时到达"这条路径。

第 4 级：数据结构。

表面内容：数组、链表、栈、队列、哈希表、堆、树、图，以及它们各自的增删改查复杂度。

真正训练的东西：对"代价"的敏感。

数据结构这一级最大的价值不是"我知道什么是红黑树"，而是在做任何一次数据组织决策的时候，脑子里会浮现出代价。用数组按下标查找是 O(1)，但中间插入是 O(n)；用哈希表查找平均 O(1)，但失去了顺序；用链表插入是 O(1)，但查找是 O(n)。当你有了这种敏感，你写业务代码的方式会彻底改变——你会本能地问：这个数据有多少条？会被怎么读？会被怎么改？热路径是哪条？

没有这一级的人写出的代码有一个共同特征：它在小数据量下完美，在大数据量下灾难。 而这正是很多 AI 生成的代码的典型画像——因为 AI 是在"让代码跑通"的目标下生成代码的，它优先保证正确性，而不是复杂度。

第 5 级：算法。

表面内容：复杂度分析、递归、排序、二分、分治、贪心、动态规划、图算法。

真正训练的东西：分解问题的能力，以及"证明"的意识。

算法这一级经常被诟病为"面试八股"，但它的训练效果是真实的：它教你把一个模糊的问题形式化——定义输入、定义输出、定义约束、定义边界情况——然后在这个形式化基础上找解。更重要的是，它培养了"举反例"的本能：一个方案听起来对，但它在什么情况下会错？这种本能，正是后来做代码评审、做故障复盘、做架构取舍时最值钱的东西。

第 6 级：后端开发。

表面内容：HTTP、REST、路由、鉴权、中间件、并发模型、错误码设计、限流。

真正训练的东西：边界意识与契约思维。

前端和后端之间有一条线，这条线叫接口。接口的本质是契约：我承诺给你什么、我要求你提供什么、出错时我会怎么告诉你。后端开发这一级训练的就是这种契约思维——你要开始为一个你看不见的调用方写代码，那个调用方可能是三个月后的同事，可能是另一个团队，可能是一个写死在前端里的缓存逻辑。

这里还埋了一个后面会反复出现的概念：幂等性。一个"重试安全"的接口和一个"重试会重复扣款"的接口，在代码上可能只差几行，但在生产环境里的风险差了几个数量级。理解幂等，需要你先理解"网络会失败、客户端会重试"这个现实，而这个理解只有在你真的被坑过一次之后才会变成直觉。

第 7 级：数据库。

表面内容：范式、SQL、索引、B+ 树、事务、隔离级别、锁、慢查询优化。

真正训练的东西：持久性与一致性的世界观。

数据库是软件工程里最反直觉的一层，因为它是唯一一层你必须假设"东西是永久存在的"。内存里的东西可以随时丢，进程可以随时被杀，但落库的数据必须永远对。这一层会教给你一堆非常难学但极其关键的概念：事务的 ACID、并发下的隔离级别、脏读 / 不可重复读 / 幻读、索引的代价、连接的昂贵。

跳过这一级的人，会持续地写出那种"结构上就错了"的系统——比如把本该落库的状态放在内存里、比如在多实例部署时用一个进程内的锁去"防止重复"、比如在不看执行计划的情况下给每个字段都加索引。

第 8 级：系统设计。

表面内容：分层架构、缓存策略、消息队列、幂等、限流熔断、一致性取舍、CAP、并发模型。

真正训练的东西：取舍（trade-off）的思维方式。

这是整条曲线上最重要的一个台阶，因为从这一级开始，不存在"正确答案"了。前面七级里，一个问题通常有一个更优解；而从系统设计开始，每一个决策都是在不同维度上的取舍：一致性换可用性、延迟换成本、耦合换开发速度、复杂度换灵活性。工程师的成熟度，很大程度上就体现在"他能同时看清一个决策的几个副作用"。

第 9 级：DevOps 与部署。

表面内容：构建、制品、容器、CI/CD、灰度、回滚、监控、告警、日志。

真正训练的东西："代码写完不等于交付"的认知。

这一级训练的是责任感的时间延伸——你写的东西要进入一个你无法直接触碰的环境，在那里 24 小时运行，被成千上万个你没有见过的请求路径冲击。这一层会给你一套极其实用的生存工具：能回滚的发布、能观测的指标、能定位问题的日志。而这些工具，恰恰是第五章里 Vibe Coder 最缺的那张安全网。

第 10 级：理解代码。

这一级不是一个知识模块，它是前面九级的涌现结果。当你真的走完前九级，你会获得一种很难描述但可以观察的能力：

• 打开一个陌生的仓库，你能在十分钟内画出它的主要数据流；
• 读到一个函数名，你能猜到它的副作用；
• 看到一个报错，你不会慌，你会按"最近改了什么 → 哪一层负责 → 怎么验证"的顺序排查；
• 看到一段奇怪的代码，你会想到"这是为了解决某个历史问题打的补丁"，而不是"写这代码的人真蠢"。

这种能力，在图里被放在曲线的最高点，恰如其分。因为它确实是最高的东西。而且它有一个残酷的性质：它只能由前九级里的大量真实失败沉淀而成，没有任何捷径。

2.2 为什么必须"顺着"爬——不是规矩，是物理

现在回答一个关键问题：为什么不能跳？为什么不能"哪里不会补哪里"，用 AI 来填掉所有中间层？

答案藏在认知负荷理论里。人的工作记忆容量有限，大约只能同时处理四到七个信息块。当你在解决一个真实工程问题时，你的工作记忆需要装下：问题本身、当前的上下文、你尝试过的方案、以及关于所用技术的知识。如果底层知识（语法、数据结构、异步模型）还没有自动化，它们就会占满工作记忆，让你没有余量去做真正的思考。

这就是为什么一个刚学会语法的人写不出好架构：不是他笨，是他的工作记忆全被"这个 API 怎么调"占满了。也是为什么古法编程必须一级一级来：每一级的作用就是把它下面那些东西变成"不用想就会"的本能，从而腾出带宽给上一级。

AI 在这个过程中扮演了一个微妙但危险的角色。

一方面，AI 确实大幅降低了"查 API"的成本。以前你需要记住 Array.prototype.reduce 的参数顺序，现在你只要描述意图，AI 就给你写出来。这部分成本是实打实地省下来了，这是真实收益。

但另一方面，如果 AI 连"底层知识的自动化"这件事也一并替你做了，你就失去了把工作记忆腾出来的机会。你会呈现出一种很特殊的状态：你什么都能做出来，但你脑子里没有任何东西是"不用想就会"的。 于是当遇到一个 AI 也搞不定的问题（通常是复杂、隐晦、跨模块、需要全局上下文的问题）时，你的工作记忆瞬间被压垮——因为所有底层的东西，你都需要现查。

这就是断崖在认知层面的解释：断崖不是能力突然消失，而是你的能力一直在租用，现在租期到了。

2.3 慢的回报：心智模型的复利

古法编程的"慢"，回报在哪里？

回报在于：你拥有的是心智模型（mental model），而不是操作手册。

这个区别极其关键。操作手册是"遇到 A 就做 B"，它有效但脆弱——一旦环境变了，手册就失效了。心智模型是"我知道这个系统的内部结构是怎样的，所以我能推断出它在没见过的场景下会怎么表现"。

一个例子：

操作手册型的人遇到"接口超时"这个问题时，会做的事是——搜索"接口超时怎么解决"、试五个方案、其中三个有效、但不知道为什么有效、下次换个场景又不行。

心智模型型的人遇到同一个问题时，脑子里会自动跑出这条链：请求从浏览器发出 → DNS → 连接 → 网关 → 应用 → 数据库 → 返回。然后他会问：超时是从哪一段开始计时的？是连接超时还是读超时？上一次出现是在什么时候？有没有对应的变更？最后他会去看那条链上每个环节的耗时指标——而这个指标，是因为他的模型里存在"这一段"，他才想到要去看的。

AI 可以给你操作手册，但它没法给你一个能自己生成操作手册的脑子。

这就是古法编程那条曲线的真正形状：前期的慢，是在攒"生成操作手册的能力"；中期陡峭，是因为这个能力开始自我加速；后期的平缓，是因为剩下的部分需要真实世界的复杂性来喂养，而这个供给是有限的。

第三章 Vibe Coder 曲线为什么先飞起来

3.1 三个正反馈回路

如果 Vibe Coding 一点用没有，它不会在两年内席卷整个行业。它飞起来是有真实原因的，而且原因很硬。

第一个回路：反馈延迟从小时级降到秒级。

传统开发里，一个功能从"想做"到"看到它在屏幕上动"，中间要经过：设计数据结构 → 写接口 → 写前端 → 联调 → 处理 CORS → 处理环境变量 → 终于跑起来。这条路径上每一个环节都可能卡住你半天。而在 Vibe Coding 里，你描述意图，AI 生成，你点运行，看到了。反馈延迟被压缩到秒级，而反馈延迟是学习曲线斜率的最强决定因素之一——这一点在古法编程里本来是通过"多写小 demo"来模拟的。

第二个回路：摩擦消失带来的"能动性"暴涨。

传统开发里，大量的精力消耗在"非核心摩擦"上：找不到正确的库、版本冲突、配置文件格式不对、文档过时。这些摩擦不产生任何学习收益，纯粹是消耗。AI 极其擅长消除这类摩擦——它对 API 的记忆远好于人类，它能一次生成完整可运行的骨架，它能帮你把报错信息翻译成人话。

摩擦消失的直接结果是：一个人可以持续保持"在做东西"的状态，而不是"在卡住"的状态。 人在"在做东西"的状态下，主观能动性、情绪、信心都是上扬的。这就是那条近乎垂直的上升段。

第三个回路：产出可见的时间点被大幅提前。

传统路径下，一个人从零开始到做出一个"能拿给别人看的东西"，可能需要几个月。而 Vibe Coding 下，第一天就能做出一个能用的工具，第一周就能部署一个内部系统。外部可见的产出会转化为正反馈，而正反馈会驱动更多的尝试，更多的尝试又会带来更多的产出。这是一个标准的正反馈循环。

三个回路叠加的结果，就是那条曲线的垂直段。这个过程是真实的，收益是真实的，不应该被嘲笑。 任何一个否认 Vibe Coding 生产力的人，只要亲手用它做过一个从前需要两周、现在只需要两小时的东西，就会明白这一点。

3.2 "能跑"很廉价，"能上生产"极其昂贵

那么问题出在哪里？

问题出在：上面三个回路全都服务于一个目标——让东西"能跑"。而"能跑"和"能上生产"之间的距离，比绝大多数人想象的要大得多。

把人做个类比。让一个东西"能跑"，难度大约相当于搭一个样板间：找一块地、立起墙、刷上漆、摆上家具、拍一张漂亮的照片。做到这一步，需要的是执行力、审美、以及对工具的熟练度。

让一个东西"能上生产"，难度大约相当于盖一栋能住人五十年的楼：地基要能承重、结构要抗风抗震、水电要能检修、消防要合规、每一层的承重墙不能随便敲掉、二十年后别人来装修时能看懂图纸。

这两个任务看起来是同一件事的不同完成度，实际上是两种不同的工作。

具体差在哪里？我们把"能跑"和"能上生产"的差异列成一张表：

这张表就是断崖的物理成因。 你站在"能跑"这一边，用"能跑"这一整套心智去评估自己的水平，得出"我基本算是高级工程师了"的结论；而生产环境测试你的，是右边那一整列。

而右边那一列的每一项，恰好都对应古法编程曲线上的某一段：并发对应第 3 级和第 6 级，数据量对应第 4 级和第 7 级，故障与幂等对应第 6 级，观测与回滚对应第 9 级，安全与权限对应第 6 级和第 8 级，成本对应第 8 级。

你看，那张图的两条曲线在这里第一次交会了：Vibe Coder 的信心断崖，正好落在古法编程的第 6 到第 9 级上。

这不是巧合。这是任何一个真实系统都会提出的要求，它不管你用什么方式写代码，它只测试你有没有这些能力。AI 帮你跳过了这些台阶的学习过程，但生产环境不会因此跳过对这些能力的检验。

第四章 断崖解剖：为什么"生产版本出事了"是必然事件

本章是全文最重要的一章。我们要回答一个问题：为什么断崖一定会来？ 不是"可能会来"，是"一定会来"。

我会给出七个原因。这七个原因不是并列的七条，而是层层递进的：前三个解释了为什么 AI 生成的代码在复杂度上升时会失效，中间两个解释了为什么你无法定位问题，最后两个解释了为什么你会陷入"越改越乱"的死循环。

4.1 原因一：复杂度守恒定律

先讲一条被反复验证的规律，通常被称为复杂度守恒定律（Tesler's Law）：

每个应用都有其内在的、不可约简的复杂度。这份复杂度不会消失，它只会在"开发者"和"使用者"之间转移；或者更准确地说，它只会在"编码阶段"和"运行阶段"、"显式"和"隐式"之间转移。

AI 的能力在于：它能把复杂度从你眼前搬走。 你说"给我一个带用户登录和权限控制的系统"，它给你生成一堆代码。你看到的只有"它能用"。复杂度消失了——从你的视野里消失了。

但它没有从系统里消失。

它去了哪里？它藏进了这些地方：

• 藏进实现细节：AI 选择了某个 ORM、某个鉴权方案、某种会话存储，这些选择带着它们自己的约束和陷阱，而你并不知道；
• 藏进隐式假设：AI 假设了请求是串行的、数据量是小的、时间是单调递增的、字符编码是 UTF-8 的。这些假设在正常情况下不会暴露；
• 藏进未覆盖的路径：所有那些你没有描述过、AI 也没有主动处理的边界情况；
• 藏进耦合：为了让你快速看到效果，AI 往往选择最短路径把两个模块连起来，而这种连线方式通常不具备可扩展性。

所以 Vibe Coder 感受到的"轻松"，本质上是复杂度被暂时存放进了系统本身。 那些复杂度并没有消失，它们只是在等待一个足够复杂的场景来同时引爆。

这就解释了为什么断崖来得这么突然：它不是渐进式的恶化，它是累积到阈值之后的集中释放。 前面的每一个"跑起来了"，都在往一个看不见的容器里存一点复杂度；存量上升的时候，你任何感受都没有；直到某一天，一个新的需求或者一次流量上涨，把容器撑破。

4.2 原因二：上下文窗口是第一生产力，也是第一瓶颈

第二个原因和 AI 的工作方式直接相关。

今天的 AI 编程工具，本质上是在一个有限的上下文窗口里工作的。它能"看到"的东西包括：你当前打开的文件、它自己检索到的相关文件、以及对话历史。但它看不到的东西更多：那些它没有检索到的文件、那些约定俗成但没有写进代码的团队规范、那些散落在文档和聊天记录里的历史决策、以及最重要的——系统的运行状态。

这造成了一个非常具体的失效模式：

单向依赖可以，交叉依赖不行。

如果系统是严格的树状结构，模块之间只有单向调用，那么 AI 完全可以逐文件地处理——它处理任何一个文件时，需要的信息都在这一个文件及其直接依赖里。这就是为什么 Vibe Coding 在小项目、独立工具、单页面应用、原型上表现极好。

但真实的业务系统几乎从来不是树，而是网。订单模块要知道用户模块的状态，用户模块要知道权限模块的状态，权限模块又依赖组织架构，组织架构又和被删除的历史数据有关系……当 AI 在这样一个网络里做修改时，它必须同时理解很多个节点之间的关系，而其中任何一个节点没有被检索到，它给出的修改就是局部正确、全局错误的。

而且这里有一个更隐蔽的问题：AI 不会告诉你它缺了上下文。

它不会说"我没有看到 order 表的历史迁移脚本，所以我不确定这个字段是否可空"。它会基于已有的信息给出一个看起来很自信、语法完全正确、逻辑也自洽的方案——但基于了一个错误的假设。

这就是断崖前那一刻的典型体验：「为什么会这样？」因为代码看起来完全没问题。语法对的，逻辑通的，AI 也说这样写就行，测试环境也跑得过——但你缺的那一块上下文，才是真正的答案。

4.3 原因三：隐性契约的无声崩塌

第三个原因是契约问题，它比前两个更阴险，因为它不报错。

软件系统里有两类契约：

显式契约：函数签名、接口文档、类型定义、数据库 schema。这类契约是写下来的，AI 能读到，工具能检查，出错了会报错。

隐性契约：那些所有人都知道、但没有写在任何地方的约定。比如：

• 这个字段在业务上永远不为空，虽然数据库允许它为空；
• 这个接口只会被一个调用方以固定频率调用，所以不需要防重；
• 这个时间字段存的是本地时间，不是 UTC；
• 这个状态值只会从 A 变到 B，永远不会从 B 回到 A；
• 这个服务部署在单个实例上，所以进程内缓存是有效的；
• 这个 ID 是单调递增的，所以可以用它做排序。

隐性契约是 AI 的最大盲区。 它读不到，也没人会告诉它。而当 AI 在你的系统上做修改时，它有很高的概率会无意中破坏某一条隐性契约——通常是在它"优化"代码的时候：把两个循环合并成一个、把异步改成同步、把进程内缓存改成模块级单例、给一个字段加个默认值。

这类破坏的可怕之处在于：它不会立刻报错。 代码会跑，测试会过，甚至可能上线一两天都没事。直到某个特定条件被触发——某个用户的某个操作、某个时刻的数据状态——系统才会以一个你完全无法解释的方式出问题。

这就是"生产版本出事了"最常见的真相：不是新写的代码有 bug，而是新的改动打破了一条从来没有人写下来过的旧约定。

4.4 原因四：你没有调试所需的心智模型

现在讲断崖之后的第一个节点：「调试 AI 生成的代码」。

调试的本质是什么？

调试的本质是"用现实证据修正脑内的模型"。

这个过程是这样的：你有一个关于系统如何工作的模型 → 系统表现出了不符合模型的行为 → 你设计一个实验去获得信息 → 这个信息告诉你模型哪里错了 → 你修正模型 → 再次预测 → 再次验证 → 直到模型与现实一致，此时你也就找到了 bug。

这个过程的每一步都需要模型。没有模型，你无法提出假设；没有假设，你无法设计实验；无法设计实验，你就只能无目的地乱试。

而 Vibe Coder 面临的正是一个没有模型的状态：

• 代码不是他写的，所以他不知道作者的意图；
• 代码是 AI 生成的，所以它没有"作者的意图"这种东西——它是概率上最像正确答案的文本，而不是某个思维过程的产物；
• 他从未参与过这个系统的设计决策，所以他不知道哪些选择是刻意的，哪些是偶然的；
• 他没有见过这个系统在故障下的表现，所以他不知道哪里的信号可信。

结果就是：他手里有全世界最强大的代码生成工具，但他不知道要问什么问题。

这就是「调试 AI 生成的代码」这个节点最痛的地方。它不是"AI 生成的代码更难调"，而是"面对 AI 生成的代码，你失去了调试所需的全部前提"。

而且更糟的是：当你调不动的时候，你的第一反应是再问一次 AI。

4.5 原因五：为什么改了 47 个文件

最后那个节点——「为什么改了 47 个文件？！」——值得单独用一节来讲，因为它是整个断崖的终局形态，也是最能体现"AI 编程范式"缺陷的一笔。

它是怎么发生的？路径通常是这样的：

1. 出问题了。你（或者 AI）开始调查。
2. AI 说："我觉得问题可能出在 A 模块，我帮你改一下。" 于是文件 1 被改了。
3. 还是不对。AI 说："那可能是 B 的问题。" 文件 2、3、4 被改了。
4. 还是不对。这次 AI 做了一件看起来更聪明的事：它说"这可能是多个地方的问题，我帮你全面检查一下。" 于是文件 5 到 20 被改了。
5. 依然不对。你开始怀疑是配置、是环境、是版本。文件 21 到 30 被改了。
6. 你已经忘了最初的问题是什么。你只想让它"恢复原状"。
7. 你打开 diff，看到 47 个文件被改动，其中 30 个是你完全不知道为什么被改的。而且其中有一半改的是对的，一半是错的，剩下几个是无所谓的——但你分不出来哪个是哪个。

这个过程的根本问题有两个：

第一，AI 在调试时是"猜测驱动"，而不是"假设驱动"。

人类工程师调试时会做一件关键的事：先提出一个可以被证伪的假设。"我认为是缓存没清" —— 这个假设可以被验证：清掉缓存看问题是否消失。而 AI 的默认行为更接近"广度搜索"：它基于文本相似度，找出所有"看起来可能相关"的地方，然后都改一改。这在直觉上合理，在工程上是灾难——因为你不再是在做科学，你是在做赌博，而且每一次赌博都改变了整个系统的状态，让下一次判断变得更难。

第二，改动一旦蔓延，可回滚性就消失了。

当你只改了一个文件时，出问题你可以 git checkout 回来。当你改了 47 个文件、跨越了 6 个模块、其中还夹杂着为了测试而临时加的日志和为了绕过某个报错而写的 hardcode 时，你失去了"回到已知良好状态"的能力。

这是现代软件工程里最核心的一条安全边界：永远保留一个可以回去的地方。 而 Vibe 式调试恰恰在系统性地破坏它——因为它追求的是"让它好起来"，而不是"最小化改动量"。

记住一句话：在软件工程里，改动量本身就是一种风险。47 个文件的 diff 不是"修好了"，是"什么都可能发生"。

4.6 原因六：可观测性的黑洞

第六个原因关乎"信息"。

人类工程师调试复杂系统，靠的不只是代码，更是系统运行时反馈的信息：日志、指标、链路追踪、告警、火焰图。这些信号的共同点是：它们是专门为"发现问题"而设计的。

而 Vibe Coder 生成的系统，通常有一个特征：它在出问题的时候什么也不说。

因为 AI 在生成代码时，目标函数是"让功能工作"，而不是"让问题可被发现"。所以你会看到：

• 错误被 try / catch 吞掉了，catch 块里只有一句 console.log(err) 或者干脆是空的；
• 没有任何结构化的日志，只有零散的 print；
• 没有指标，所以你无法知道"这个接口的 P99 是多少"；
• 没有链路，所以你不知道一个慢请求到底慢在哪一段；
• 没有告警，所以你是从用户嘴里知道系统挂了的。

这就形成了一个致命的组合：没有可观测性 + 没有心智模型 = 完全无法定位问题。

这时候你剩下的唯一手段是"读代码"。而读 AI 生成的、你没有参与设计的、有几万行的代码，去找一个你连症状都无法准确描述的 bug——这就是第四条原因和第六条原因叠加后的绝境。

4.7 原因七：归因错误——最根本的那一个

最后这一条不是技术原因，是心理原因，但它可能是整张图里最根本的那个原因。

它解释了为什么纵轴标注的是"信心"而不是"技能"。

人类在评估自己的能力时，会使用一种叫做结果归因的机制：我做到了某件事，所以我有某方面的能力。这个机制在没有 AI 的世界里是相当可靠的，因为"我做到了"这件事，通常意味着"我具备了这个能力"。

但它有一个致命的前提：结果和能力之间必须有因果链。

在 Vibe Coding 里，这条因果链断了。你确实做出了一个系统，但你做出来它的方式是：描述需求 → 接受 AI 的输出 → 观察它运行 → 接受结果。这个链条里，你的贡献是"提出需求"和"判断结果"，AI 的贡献是"实现"。 而你把整个结果，都归因给了自己。

这不是愚蠢，这是人类认知的正常运作方式。我们天生倾向于把成功归因于内部因素（能力），把失败归因于外部因素（环境）。而在 Vibe Coding 里，这种倾向被 AI 放大了十倍——因为 AI 太擅长把"实现"这一步做得看起来很轻松了，轻松到你会以为它本来就很轻松。

于是信心曲线和技能曲线发生了历史上最大规模的一次脱钩。

而在古法编程里，这种脱钩是难以发生的，因为每一个结果都对应着你亲手写下的每一行代码、亲手解决的每一个报错。报错是这个世界给你的最诚实的反馈：它不会说"你很有潜力"，它只说"第 23 行第 8 列有个分号写错了"。 成千上万次这样的反馈，会让你的自我评估和真实能力保持校准。

所以那张图上下两条曲线的真正差异，不在于"哪条路更快"，而在于：

上面那条曲线有一个持续的、诚实的校正机制；下面那条曲线没有。

这就是断崖的最后一个原因，也是最根本的原因：不是你能力不够，而是从来没有人（包括 AI）告诉你，你的能力在哪里。

第五章 两条曲线的完整对照

前面四章讲完了机制，现在我们把它收敛成可以直接用的判断工具。

5.1 逐维度对照表

5.2 一个关键观察：两条曲线在"复杂度"上交会

把两条曲线叠起来，你会看到一个非常漂亮的结论：

Vibe Coder 信心曲线开始下降的位置，正好对应古法编程曲线的第 6 到第 9 级。

• 崩溃点"生产版本出事了" —— 对应第 8 级系统设计（并发、幂等、一致性、限流）
• 崩后"为什么会这样？" —— 对应第 7 级数据库和第 9 级 DevOps（无指标、无日志、无链路）
• "调试 AI 生成的代码" —— 对应第 4、5 级数据结构与算法（缺乏复杂度直觉，无法判断哪里成本异常）
• "为什么改了 47 个文件？！" —— 对应第 6 级后端开发（契约意识缺失，改动无边界）

这不是巧合。 生产环境对工程师提出的能力要求是一个常量，它不关心你是用 AI 还是用手写。你用什么方式抵达它，只影响你抵达的速度，不影响它考核的内容。

所以那句流行的话——"AI 让每个人都能编程"——需要精确化：

AI 让每个人都能"产出"程序，但没有让每个人都能"承担"程序。

产出是创造的动作，承担是运维、扩展、修复、演进的责任。AI 把前者的成本打到了接近于零，后者的成本一分钱都没有降，因为后者考验的是理解，而理解是无法被生成的。

5.3 一个反直觉的推论：AI 让"古法"更值钱了

许多人以为 AI 会稀释传统工程能力的价值。结论恰好相反，可以这样推导：

1. 写代码的成本大幅下降 → 世界上生成的代码总量大幅上升；
2. 代码总量上升 → 需要被人理解、维护、审计、修复的代码总量大幅上升；
3. 同时，具备"理解、维护、审计、修复"能力的人没有变多（因为这些能力恰恰是 Vibe 路径跳过的）；
4. 于是 → 能读懂复杂系统并对其负责的人，供需缺口扩大，相对价值上升。

这个推论在现实中的表现已经很明显了：能"写"代码的人越来越多，能"接手一个没人讲得清楚的 AI 生成系统并把它救回来"的人越来越稀缺。而后者，恰恰是古法编程那条曲线终点站上的人。

第六章 Vibe Coding 行不行？分场景判断

现在我们必须给 Vibe Coding 一个公平的评价。前四章讲了它的问题，但它不是一个骗局——它是一个适用范围明确、威力巨大、但被严重误用的工具。

6.1 高适配场景（放心 Vibe）

6.2 低适配场景（必须古法护航）

判断标准可以浓缩成一句话：

**如果出错的代价是"重跑一次"，就放心 Vibe；
如果出错的代价是"钱、数据、信任、时间无法找回"，就必须有工程护航。**

6.3 一个更实用的判断公式

在实际工作中，可以用一个简单的四问法快速判断某个任务该走哪条路：

1. 这个产出会活多久？ 活一天 → Vibe。活一年 → 工程。
2. 出错时谁承担代价？ 只有我 → Vibe。有别人 → 工程。
3. 我能验证它吗？ 能（有测试 / 有对照 / 结果肉眼可判）→ Vibe。不能 → 工程。
4. 三个月后我要改它，还能读得懂吗？ 读得懂 → Vibe。读不懂 → 工程。

四问里只要有两问以上指向"工程"，就不应该裸奔。

6.4 真正的分野：不是"用不用 AI"，而是"验不验证"

这里必须澄清一个常见的误读。很多人把这张图理解成"AI 编程 vs 手写编程"的对立。不是。

真实的差异不在生产方式，而在验证方式。

• 古法编程的人用 AI，是"我让 AI 写这段样板代码，然后我读懂它、我改它、我为它负责"。这是AI 增强的工程师。
• Vibe Coder 用 AI，是"AI 写，我复制，它能跑，我上线"。区别在于验证环节被整体删除了。

所以正确的分界线应该画在这里：

AI 生成的代码，你理解了多少？你能为它负责到什么程度？

• 每一行都理解 → 可以上生产；
• 关键路径理解 → 需要测试和灰度兜底；
• 完全不懂 → 只能是一次性脚本。

这就是 AI 时代最重要的一条纪律：你交付的不是代码，是你对代码的理解。

第七章 第三条曲线：把断崖修成缓坡

前三章讲了病，这一章讲药。

目标是构造一条第三条曲线：保留 Vibe Coding 的速度优势，同时消除断崖。它的形状不是 S 形（太慢），也不是钟形（会崩），而是一条斜率中等、持续上升、没有断崖的曲线。

下面这套纪律，是我在真实项目里反复验证过、并且每一条都能对应到第四章某个失败原因的。它们不是理论，是可以今天就执行的清单。

7.1 十二条纪律（按重要度排序）

纪律 1：每个改动都必须能回到起点。

在开始任何一次 AI 辅助的修改之前，确保当前状态是干净的、已提交的。改完先看 git diff --stat，如果改动文件数超过你预期的两倍，停下来重新思考，而不是继续。

对应失败原因五（改动蔓延）。这是最重要的一条，因为它保护的是你的退路。

纪律 2：一次只让 AI 改一个维度。

不要说"帮我把这个功能加上，顺便优化一下性能，顺便重构一下这个模块"。每次只给 AI 一个目标、一个边界。改完验证，提交，再进入下一个。

对应失败原因五。AI 在多目标下会做大量"顺手"的改动，而每一个顺手改动都可能破坏一条隐性契约。

纪律 3：先读后改，读不懂不改。

AI 给出的每一段代码，在合入之前你必须能回答三个问题：这段代码的目的是什么？它在什么条件下会失败？它和周围代码的边界在哪？如果三个问题中有一个答不上来，这段代码就不能进主干。

对应失败原因四（缺乏心智模型）。读，就是建模的过程。

纪律 4：让 AI 先解释，再动手。

在让 AI 修改某个模块之前，先让它"通读并解释这个模块的数据流、关键状态、以及它认为的约束"。这一步会暴露它没有看到什么——当它解释中发现你熟悉的重要细节缺席时，你就知道它的上下文是残缺的。

对应失败原因二（上下文窗口）。这是成本最低的上下文探测手段。

纪律 5：把隐性契约写下来。

每当你发现一条"大家都知道但没写下来"的约定，立刻做三件事之一：写进类型定义、写进测试、写进代码注释（并标注原因）。这不是为了 AI，这是为了你自己三个月后还能活。

对应失败原因三（隐性契约崩塌）。这是性价比最高的一条长期投资。

纪律 6：为 AI 的输出准备验证器。

在让 AI 生成之前，先想清楚你打算怎么确认它是对的。可以是单元测试、可以是一个可以对照的旧实现、可以是手工验证的步骤清单。没有验证方式的生成，等于没有生成。

对应失败原因七（归因错误）。验证器是校准信心与能力的唯一工具。

纪律 7：测试先写或同步写，绝不留到"以后补"。

AI 让"写测试"的成本同步降低了——你完全可以让 AI 为它自己生成的代码写测试。但要注意：AI 写的测试可能和你一样瞎。 所以测试必须至少包含两类：(a) 你手工构造的边界用例；(b) 每个曾经出过的线上 bug 的复现用例。第二类是最有价值的测试，因为它是用真实世界的失败换来的。

对应失败原因一（复杂度守恒）和原因六（可观测性）。

纪律 8：任何东西上生产之前，先让它可回滚。

上线不是"发布"，上线是"以可以被撤销的方式发布"。灰度、开关、双写、版本化，选一个。"能不能回滚"这个问题的答案如果是"要手动改回来"，那就不算可回滚。

对应失败原因一。回滚能力是把"断崖"降级为"小坑"的关键装置。

纪律 9：日志、指标、告警，从第一天就加。

不需要复杂的 APM，但至少要有：结构化的错误日志（带 request id）、关键路径的耗时与错误率指标、以及一条在错误率异常时能叫醒你的告警。

对应失败原因六（可观测性黑洞）。没有信号，调试就是玄学。

纪律 10：把 AI 当"资深同事"，不当"编译器"。

问它的方式要从"帮我写 X"改成"我想做 X，请分析几种做法的取舍，指出各自的适用条件与风险"。让它输出决策依据，而不是输出答案。 前者可以被你验证，后者只能被你信仰。

对应失败原因七。这是从"使用 AI"到"与 AI 协作"的分界线。

纪律 11：定期做一次"从零复述"。

每隔一段时间，强迫自己不看代码，把系统的核心链路口头或书面复述一遍：数据从哪来、经过哪几层、存到哪、什么条件下会失败。复述不出来的部分，就是你的能力缺口，也就是下一个断崖的位置。

对应失败原因四。这是最有效的自我校准手段。

纪律 12：读代码的量，要跟写代码的量同步增长。

AI 让你"写"的量暴涨了，但如果"读"的量没有跟上，你的模型就会越来越薄。具体做法：每次让 AI 改动之后，花同样的时间读一遍它改动的上下文（不只是改动的那几行），理解它为什么在这里改而不是别处改。

对应全部七条失败原因。这是最根本的一条纪律。

7.2 三个安全网

上面十二条可以归入三个层次的安全网。这三层网叠起来，断崖就变成了缓坡：

第一层：可回退（Git + 小步提交 + 可回滚发布）

它解决的是"出事了怎么办"。核心思想是降低单次错误的爆炸半径。只要"回到已知良好状态"这个动作是秒级的，任何事故都只是麻烦，不是灾难。

第二层：可验证（测试 + 类型 + 契约测试 + 灰度观察）

它解决的是"怎么知道它是对的"。核心思想是用机器来替代人肉校验，把"我觉得没问题"变成"证据显示没问题"。

第三层：可观测（日志 + 指标 + 链路 + 告警）

它解决的是"出事了怎么知道是哪里"。核心思想是让系统在出问题时主动告诉你，而不是等你从用户的抱怨里推断。

这三层网的逻辑关系是：

• 有了可观测，你才能知道出事了；
• 有了可验证，你才能提前拦住大部分问题；
• 有了可回退，你才能在拦不住的时候安全撤退。

三者缺一，断崖就还在。三者齐备，Vibe Coding 的速度优势就可以被安全地吃下来——这也是第三条曲线的全部秘密：它不是更慢的 Vibe，它是"带安全网的 Vibe"。

7.3 一张"AI 辅助开发"的最小工作流

把上面的纪律落成一个可执行的循环，大概是这样：

1. 定义边界
   - 这次要改什么？明确到文件/函数级
   - 明确不改什么

2. 让 AI 解释现状
   - "读一下这几个文件，说明数据流、关键状态、你看到的约束"
   - 观察它遗漏了什么 → 补上下文

3. 让 AI 给方案，不给代码
   - "列出 2-3 种做法，各自的代价与风险"

4. 你来选，说出理由
   - 这是"能力"发生的地方，不能外包

5. 让 AI 实现最小改动
   - 明确要求：只改必要的地方

6. 你读懂它
   - 逐行确认：目的、失败条件、边界
   - 问"这里如果 X 会怎样"

7. 写/补验证
   - 边界用例 + 回归用例

8. 小步提交
   - 走到这一步，改动必须已经能回退

9. 有观测地发布
   - 灰度 / 开关 / 盯指标

10. 从零复述一次
    - 不看代码讲清这条链路 → 讲不清就是还有缺口

注意这个流程里，AI 参与了 2、3、5 三步，而 1、4、6、7、10 步全部由人主导。 这个比例不是随意的——它对应着"哪些环节是能力形成的必经之路"。

第 4 步和第 6 步是最不能外包的两步。 前者是取舍，后者是理解。这两件事恰恰是古法编程曲线从头到尾在训练的东西。

所以第三条曲线的本质可以说得非常清楚：

**用 AI 压缩"实现"的成本，用纪律保留"理解"和"取舍"的环节。
被压缩的是写代码的时间，没被压缩的是形成判断力的过程。**

第八章 给三类人的行动清单

8.1 如果你是新手（正在起步）

不要相信"有了 AI 就不用学基础"这句话。 这句话对已经会编程的人成立（他们的基础已经自动化了，AI 只是加速器）；对新手不成立，因为新手连"AI 生成的代码好不好"都判断不了。

你的行动清单：

1. 保留手写代码的比例。 建议至少 30% 的练习由自己从零写，不看 AI。不是为了情怀，是因为手写是获得"报错反馈"的唯一途径，而报错反馈是校准能力的唯一机制。
2. 优先补三样东西：数据结构与算法（获得复杂度直觉）、异步模型（获得并发直觉）、数据库与事务（获得一致性直觉）。这三样是 AI 最难替你补的，也是生产环境最先拷问你的。
3. 用 AI 做老师和审查者，而不是代笔者。 "解释这段代码"、"我这样写有什么问题"、"这个报错的根本原因是什么"——这些用法会让你成长；"帮我写个 X"——这个用法会让你停滞。
4. 刻意练习调试。 遇到 bug 时，先自己定位 30 分钟，再问 AI。哪怕最后是 AI 帮你找到的，你也要追问："你是怎么判断出是这里的？" 把它的推理过程变成你的方法。
5. 接一个"必须长期维护"的真实项目。 任何代码写完之后不再改动的项目，都无法训练你。真正训练你的，是三个月后不得不回来改自己写的东西，然后被自己当年的设计坑到。

8.2 如果你已工作几年（有基础，正在被 AI 冲击）

你的处境其实最好——你已经有心智模型了，AI 对你是纯增量。

1. 把 AI 用在你最不擅长的地方：写样板代码、写测试、写文档、做代码翻译、做不熟悉语言的实现。这是"补短板"式用法，收益最大。
2. 不要把 AI 用在你的核心判断上。 架构选型、方案取舍、风险评估——这些是你相对 AI 的核心优势，不要外包。
3. 建立你自己的"验证器体系"：什么情况下你信 AI、什么情况下你必须亲自查、什么情况下必须写测试。这个体系是你在 AI 时代的核心竞争力。
4. 注意一个隐蔽的风险：长期使用 AI 会让你手写能力退化。这不是危言耸听——就像长期用导航会削弱方向感。建议定期做"无 AI 时段"练习，尤其是写核心逻辑和做调试的时候。
5. 把 AI 当作放大器而不是替身来定位自己：同样一个 AI，在一个有十年经验的人手里，产出质量可能是新手的十倍。杠杆的大小取决于支点在哪里，而支点就是你的专业能力。

8.3 如果你是团队负责人 / 管理者

这是最需要行动的群体，因为组织层面的错误会有放大效应。

1. 不要用"代码行数""功能交付速度"衡量 AI 时代的工程师。 这些指标在 AI 时代会瞬间失真，并且会奖励最危险的行为模式（快速产出、不验证、不留观测）。
2. 把审查资源从"写"移到"读"。 既然生成成本降了，评审就成了真正的瓶颈。要建立"AI 生成代码的评审规范"：必须能说明意图、必须有验证、必须能回滚。
3. 强制要求可观测性与可回滚性。 这两件事不能靠工程师自觉，因为它们在短期内是纯成本。要在流程和门禁里卡死。
4. 为"理解"留出时间预算。 如果团队的任务排期假设"AI 生成即完成"，那么理解环节会被系统性挤压，技术债会以指数速度积累。建议在排期里显式加入"读懂与验证"的时间，通常是生成时间的一到三倍。
5. 建立事故复盘文化，并且把复盘产出转成测试。 每一个线上事故都应该变成一条自动化的回归用例。这是把"古法编程的诚实反馈机制"批量复制进团队的唯一办法。
6. 重新设计招聘与晋升标准。 如果面试仍然考"能不能写出某个算法"，那筛选的是古法编程者；如果只考"能不能快速做出一个东西"，那筛选的是 Vibe Coder。真正需要的是第三类：能用 AI 快速产出，同时能对复杂系统负责的人。考核方式应该变成：给你一个陌生的、有历史包袱的代码库，给你两小时，看你能不能定位一个问题并给出安全的修复方案。

第九章 更高一层：什么变了，什么没变

到这里，我们已经有了一张完整的图：两条原始曲线、一个断崖的七重成因、一套十二条纪律、一份三类人的清单。最后一章，我们把视角拉高。

9.1 变了的：写代码的成本

过去两年真正被改变的东西，可以说得非常简洁："把意图翻译成可执行代码"这件事的成本，被压到了接近于零。

这个变化的量级，可以类比历史上几次类似的跃迁：

• 汇编 → 高级语言：把"与机器对话"的成本降了一个量级；
• 手写内存管理 → 垃圾回收：把"资源安全"的成本降了一个量级；
• 物理机 → 云：把"获得算力"的成本降了两三个量级；
• 手写代码 → AI 生成：把"把想法变成代码"的成本降了一到两个量级。

注意每一次跃迁的共同点：被降低的是"实现"的成本，被提升的是"抽象层次"。 而每一次跃迁之后，业界都会出现两个群体：一个是被新抽象解放出来、去做更高层次工作的人；另一个是把新抽象当成全部、在抽象泄露时无法应对的人。

"抽象泄露"这个概念值得记住。 任何抽象都会在某些情况下失效，此时底层的复杂度会突然涌上来。AI 生成代码是一个特别高、特别厚的抽象——所以在它的抽象泄露时，涌上来的复杂度也就特别大。这就是为什么"生产版本出事了"这个节点会来得如此猛烈：因为你站在一个特别高的地方，摔下来就更疼。

9.2 没变的：四个恒久命题

AI 没有改变下面任何一件事，而这四件事恰好构成了软件工程的全部难点。

第一，复杂度守恒。

无论用什么工具，系统必须处理的所有边界情况、所有并发路径、所有失败模式，总量是不变的。你可以把这部分复杂度藏起来，但你无法让它消失。AI 让你少写代码，但没有让你少处理复杂度。

第二，理解是不可替代的。

一个系统能被安全修改的前提，是有人理解它。AI 本身不理解你的系统——它是在统计意义上生成最可能的文本。所以"有人理解"这个前提，在任何 AI 时代都不会被取消，只会变得更稀缺。

第三，所有系统都在持续熵增。

代码会腐化，不是因为它坏了，而是因为世界在变：需求在变、数据在变、依赖在变、人在变。每一次变更都在原有结构上叠加，如果没有持续的整理，结构会自然走向混乱。AI 生成代码的速度越快，熵增的速度也越快——因为"往上叠加"比"整理结构"容易得多，而 AI 恰好极度擅长前者，非常不擅长后者。

第四，软件最终是关于人的。

代码是给人读的，接口是给人用的，系统是给人维护的。所有让"机器更容易生成"的努力，如果让"人更难理解"了，那就是在借未来的债。 47 个文件的 diff 之所以可怕，不是因为它技术上错了，而是因为它破坏了人对系统的可理解性。

9.3 一个关于终局的猜想

这两条曲线最终会怎样收场？

我的判断是：它们会收敛，但收敛点不在中间，而在古法那条曲线的延长线上。

理由：

1. AI 的能力会继续提升，上下文窗口会扩大，长程一致性会改善。这会抬高 Vibe 曲线的断崖位置——断崖不会消失，但会来得更晚。
2. 但断崖不会消失，因为它的成因（复杂度守恒、隐性契约、可理解性）不是 AI 能力问题，是工程问题的结构性质。AI 再强，也无法替你理解你自己业务里的隐性约定。
3. 同时，工具会把大量"古法编程"中的机械环节自动化——你不再需要手写 CRUD，不再需要记 API，不再需要查语法。古法曲线的启动段会被大幅抬高，也就是说，新人起步会快很多。
4. 于是最终的形状会是：一条起点更高、但形状依然是 S 的曲线，终点依然是"理解代码"（或者说"理解系统"）。 而 Vibe 那条曲线，会从"孤立的钟形"变成"这条 S 曲线的下半段被抬高的部分"，中间那道断崖，会被纪律和工具补成缓坡。

换一句话说：

**AI 没有改变工程师成长的形状，它只改变了成长的速度和起点高度。
而形状是由工程问题的性质决定的，不是由工具决定的。**

9.4 关于那张图，最后一句公道话

我想为 Vibe Coder 说一句公道话，也是为这张图做一个注脚。

图里把 Vibe Coder 画成了一个笑话，但我不认为走这条路的人是可笑的人。恰恰相反，他们身上有一种非常珍贵的东西：在没有任何准备的情况下，直接开始做东西的勇气。

古法编程那条曲线最大的问题不是慢，而是它让很多人在走到第 3 级之前就放弃了。而 Vibe Coding 那条曲线最大的贡献，是它让这些人没有放弃——他们真的做出了东西，真的 deploy 了，真的把一个想法变成了可以在浏览器里打开的东西。这件事本身是了不起的。

问题从来不是"你用了 AI"，问题是"你以为到达了终点，其实你只到达了一个新的起点，而你把这个起点当成了终点"。

所以这张图最好的用法不是拿去嘲笑 Vibe Coder，而是贴在自己的显示器旁边当校准器：当你的信心曲线开始垂直上升的时候，问自己一个问题——

我的技能曲线，跟着动了吗？

结语：信心必须长在能力上

回到那张图最本质的那个细节：下面那条曲线的纵轴，括号里写着"≠ 技能"。

这四个字是整张图的题眼，也是这篇文章的题眼。

信心不是坏东西。 没有信心，一个人走不过古法编程那条曲线漫长而痛苦的前半段。事实上，几乎所有真正的工程师都在某个阶段经历过那条曲线最平缓、最令人绝望的部分——那时候你写的每一个东西看起来都很幼稚，你读到的每一篇文章都在讲你不懂的东西，你看不出自己的进步，你甚至开始怀疑自己是不是不适合做这一行。

让人熬过那一段的，恰恰是信心。

但信心有一个前提：它必须是能力的影子，而不是能力的替身。

当信心是能力的影子时，它会随着能力的增长而增长，它会让你敢于挑战更难的问题，它会成为你继续投入的理由。而当信心是能力的替身时——当它来自于 AI 那些流畅的回答、来自于屏幕上那个能跑的 demo、来自于"我什么都能做"的幻觉时——它就不再是动力，它是一颗定时炸弹，因为它的存在本身，妨碍了你去积累它本该依托的那种能力。

这就是为什么古法编程那条曲线永远不会崩：因为它每一寸的上升，都是被报错、被测试、被真实用户一寸一寸验证过的。

这就是为什么 Vibe Coder 那条曲线必然崩：因为它每一寸的上升，都没有被任何东西验证过。

所以，如果你今天正在写代码，无论你是不是在用 AI，请记住三句话：

第一句：让机器写代码是可以的，让机器替你思考是不可以的。

第二句：你交付的不是代码，是你对代码的理解。

第三句：信心要长在能力上。能力没到的地方，信心到了，那不是自信，那是债。

AI 让"写代码"这件事变得空前便宜，也让"理解代码"这件事变得空前昂贵。而这两者之间的差额，就是下一个十年里，工程师之间的全部差距。

本文基于一张流传甚广的对比图（「古法编程」S 形技能曲线 vs 「Vibe Coder」信心曲线）展开分析。图片本身的十个节点与十一个节点，构成了这篇文章的全部出发点；而对每个节点背后机制的拆解，来自软件工程中若干条早已被反复验证的规律——复杂度守恒、抽象泄露、隐性契约、可观测性、以及能力与信心的校准关系。

愿每一条信心曲线下面，都垫着一条真实的技能曲线。