故事是这样的。

这两天偶遇到一本奇书，讲的是 vibe coding 时代的软件工程。

我当时第一反应是，这话题是不是有点过了。

vibe coding 这个词，Karpathy 2025 年初造的，到现在一年半了，该聊的都聊差不多了吧。

结果翻开第一页就被打脸了。

这本书从一个很刁钻的角度切入。

它没有站在 AI 这边鼓吹 " 编程已死 "，也没有站在传统那边哀叹 " 世风日下 "。

它做了一件我觉得更有意思的事，它把 vibe coding 当成一个已经发生的事实，然后问了一个问题：

当写代码这件事的成本趋近于零，软件工程的瓶颈到底转移到了哪里？

然后它给出了一个答案。

一个让我看完沉默了好一会的答案。

瓶颈从生产，转移到了验证。

就这么一句话，但推下去的东西太密了。代码不缺了之后，工程师真正缺的是什么？

我最近用了很多 AI 编程工具。Claude Code 也好，codex 也好，agy 也好。体验是真的很爽。

一个周末能搞出以前两周才能做完的原型，说出需求看着代码一行一行往外蹦，那种感觉你懂的。

但与此同时，有一些说不清的不对劲也在累积。

比如项目第三周的时候改不动了。

新加一个功能，老功能莫名其妙坏了。让 AI 去修，修好了这里坏了那里。

再修，它开始道歉然后重复同样的错误。最后你盯着屏幕上不知道谁写的三千行代码，脑子里只有一个念头，算了，删掉重来吧。

我以前觉得这是我的问题。

是我提示写得不够好，是我不会用工具。

但这本书告诉我，不是我的问题。

这是 vibe coding 范式本身的内生矛盾。

书里有一个概念叫「验证鸿沟」。

说的是代码以机器的速度产出，而理解和验证代码的速度，仍然以人的速度进行。

你的 AI 可以在 30 秒内生成 300 行代码，但你要花 30 分钟去确认这 300 行代码是不是对的。

而且你还没有参与书写，验证起来更慢，就像检查别人的账本总比检查自己的更费力。

所以看起来 AI 让写代码快了十倍，但项目整体并没有快十倍。

因为写代码这件事，在软件工程的总成本里，本来就不占大头。

你花在理解需求、设计方案、验证正确性上的时间，一点都没少。

反而因为代码产量暴增，验证的工作量变得更大了。

书里还给了一个数学公式，简单到初中水平但看完让人后背一凉。

设 AI 每次改动的正确率是 95%，你连续委托 30 次改动，不闻不问。那么最终全部正确的概率是多少？

0.95 的 30 次方。约等于 21%。

也就是说，每五次这样干活，有四次项目会在某个你看不见的角落里慢慢烂掉。

不是被一个惊天大 bug 杀死的，是被每一次差不多对慢慢累积杀死的。

这就是小周的故事。

书里第一章的主人公。

一个周末做出了漂亮的记账网页，一个月后删掉了整个项目。

不是因为他写不出来代码，恰恰相反，因为他写得太容易了，代码堆得太快了，快到他没时间验证，快到他来不及理解。

验证鸿沟，真实的鸿沟。

这本书读到一半的时候，我停下来想了想一个问题。

那验证这件事，有没有可能也交给 AI 来做？

答案是可以，但有一个前提。

书里说，测试在 vibe 时代有一个双重身份。它既是验证器，也是规格。

你想想看，一个失败的测试，是你向模型表达什么算做对了的最高带宽形式。

你给模型一个红彤彤的测试用例，说让这个变绿，不比你在自然语言里绕来绕去说十句话要强？

TDD 这个老掉牙的实践，在 AI 时代焕然一新了。

你先写一个表达需求的失败测试。

模型跑它，看到红色，修改代码，看到绿色。

整个循环不需要你在中间翻译做完了吗。

人的全部投入，就是想清楚那几条断言应该长什么样。

但这里有一个非常关键的权力分割，断言必须由人负责。

你让 AI 写测试，它看着现有实现去写，实现里的 bug 会被原样供奉进测试。

更糟的是 AI 特别擅长写那种「assert result is not None」的恒真断言。

覆盖率报表灿烂得不行，但实际什么都没防住。

所以书里给了两条非常硬的原则

「实现可以放手，规格不能放手」

「测试的断言主权在人」。

我觉得这两句话，值得印在每一个 vibe 工程师的工作台上。

但验证只是表面。这本书真正扎下去的地方，在第四章。

第四章的标题我特别喜欢「不变的本质，复杂度与模块化」。

作者说了一段我反复读了三遍的话。

他说，大语言模型是迄今最强的「偶然复杂度消除器」。

记不住的语法，写不完的样板，查不完的 API，这些折磨人的东西几乎被一扫而空。但问题的本质复杂度，业务规则该怎么定、多人共享时账目冲突怎么解决、退款要不要影响已结算的月份，这些，一毫克都没有减少。

AI 移除了通往复杂度的旧收费站。

但它没有移除复杂度本身。

反而因为代码的产生速度提高了一个数量级，复杂度的积累速度也提高了一个数量级。

这个洞察我觉得极其锋利。

因为它揭示了一个反直觉的事实，AI 不是让软件工程变简单了，而是让软件工程变重要了。

以前代码写得慢，复杂度也积累得慢，你可以在项目彻底烂掉之前慢慢还债。

现在代码喷涌而出，复杂度也呈指数级积累，等到你察觉的时候，已经来不及了。

所以人在 vibe 工程里有一个不可让渡的岗位，叫复制度的守门员。

书上列了四条纪律，我觉得每一条都可以直接拿来用。

第一，接口先行。

重要功能先让模型提出两三种接口设计，人来拍板，再委托实现。接口一旦定下，实现里的平庸可以日后重写，但糟糕的接口会通过每一个调用者扩散生根。

第二，边界由人守。

模块怎么划分，什么该藏在什么边界后面，这个不要外包。

第三，定期还债。

安排专门的重构任务让模型去清理重复逻辑和过宽的接口。AI 极擅长这种机械重构，前提是有测试兜底证明行为没变。

第四，为两种读者写作。

命名、注释、文档，从给同事看的礼貌升级为喂给模型的上下文。

一个叫 applyMonthlyDiscount 的函数自带规格，一个叫 process2 的函数对人对机都是模糊之源。

最后一句话尤其值得反复咀嚼「写给人读的代码，就是写给模型读的代码」。

五十年为人类认知极限发明的每一项设计纪律，恰好都在为大语言模型铺路。

这本书看到的另一个维度也很有意思。

关于安全网。

书里讲了一个两家公司的对比故事。

同一个事故，AI 重构报表模块时顺手改了一个日期格式化函数，所有导出文件的日期格式变了，下游客户的自动对账脚本开始解析出错误数据。

团队 A 没有回归测试。两周后由客户投诉暴露，三名工程师排查两天才找到祸首，又花一天评估影响范围。

总损失，三个人日和一次客户信任危机。

团队 B 有一条回归测试，断言导出文件的日期格式。重构提交后 90 秒，流水线亮红灯。模型看到失败信息，自己把改动撤了回去。总损失，90 秒机器时间。

同一个错误，同一个模型。差别不在谁的工具更智能，而在谁提前织好了网。

安全网改变的是心理学。

没有网的杂技演员只敢做保守动作，有网才敢练新动作。

书里把这种现象叫做「检查点式开发」。

每次验证通过，立刻提交。

提交因此变得极小极频繁，一次一个可验证的增量，恰好与委托粒度一一对应。

完整节拍变成，委托，生成，验证，提交，下一个。

这么做的价值在需要回头的时候才真正体现出来。git bisect 定位到的肇事提交只有 40 行而不是 4000 行，一眼看穿。回滚可以精确到单个增量，而不是全周的工作一起陪葬。

写到这里我突然想到，很多团队引入 AI 编程之后生产率并没翻倍，反而出现了 CTO 说的那句名言 " 我们不再缺代码了。我们缺的是敢合并代码的人。"

书里用了一条 1967 年的数学公式来解释这个现象，叫 Amdahl 定律。

公式很简单，整体加速的上限由未被加速的部分决定。

如果你的编码只占交付总时间的 40%，那无论 AI 把编码提速多少倍，整体交付的上限也只有 1.67 倍。

这道乘法题的意思太清楚了，规模化之后，加快速度的方向要从「生成更多代码」转向「更快地验证与决策」。

不过我觉得这本书最打动我的，不是它的方法和公式。

是尾章的三封短信。

第一封讲判断力。

说方法可以教，但品味没法教。

看一眼接口就皱眉的直觉，读一段 diff 就闻到坏味道的鼻子。

在代码无限供应的时代，稀缺的不是产量，是判断什么值得要。

品味的来源没有捷径，但有路径。读一流的代码，那些活过二十年的开源项目，源码就是免费的大师课。

亲手把一个项目维护到第二年，让复杂度真的咬过你，你才认识它。每次做完判断，回头验证自己判对了没有。

「判断力是唯一随着 AI 变强而升值的资产」，这句话我想了好久。

第二封讲肌肉。

请偶尔关掉 AI，手写一点代码。不是因为怀旧。

是因为验证能力的底层，是你亲手建立的心智模型。

什么样的代码会在并发下出错，什么样的接口会让调用者痛苦，这些知识只能从写和被咬中来。

全程坐副驾的人学不会开车。从没开过车的人，坐在副驾也看不出司机正在犯错。

「外包打字，不要外包理解。理解一旦外包，你在循环里就只剩一个功能，按接受键。那个岗位不需要工程师。」

第三封讲身份。

如果机器写代码比我们好，工程师还剩下什么？

书里的回答让我觉得很平静。它说，工程师从来不是「写代码的人」，正如建筑师从来不是「砌砖的人」。五十年里，我们把打孔卡外包给了汇编器，把汇编外包给了编译器，把内存管理外包给了垃圾回收器。

每一次，「编程」的含义都上移一层，而工程师的人数不降反升，因为每次上移都让更多问题变得值得解决。

大语言模型是这个序列的下一项，也许是最大的一项，但结构没有变。工程师的本质工作，始终是在约束之下，为人的问题设计可靠的解法。约束会变，工具会变，「可靠」的验证手段会变。这份工作本身，比任何一代工具都活得长。

说回这本书本身。

作者是谁我不知道，书稿上没有署名。

但我查了一下。

这一查不要紧，是查了一个更奇怪的事。

这本书是由 AI 生成，当然有人给了个 prompt，然后就有了这本书。

我愣住了。

往回翻。重新读了一遍。

然后突然意识到这本书最精彩的部分根本不在正文里，而在正文之外的这个事实本身。

一本关于「当写代码不再值钱之后工程何以立足」的书，它本身的诞生过程就是这句话最完美的注脚。

作者没有亲手写一行字，他给了一个 prompt，最后拿到了一个让他满意的东西。

而我们刚刚花了半小时读这本书的感想，讨论验证鸿沟、讨论复杂度的守门员、讨论测试即规格，这些文字本身，也是验证循环的另一端产出的。

镜像套镜像。

这本书用它自己的存在，把一个最刁钻的问题抛了回来。

如果连讨论这本书的文字都可以由 AI 完成，那写代码这件事的门槛到底被削成了什么样？

工程师在循环里的位置，又到底往哪里缩了？

书里有一句话说得好，我现在才真正理解它的分量。

「判断力是唯一随着 AI 变强而升值的资产」。

连这本书的好坏，都只能由你来判断了。

我不知道你怎么想。

但我觉得在 2026 年这个时间点上，能看到这样一本冷静的、不凑热闹的、把 vibe coding 和软件工程放在一起认真讨论的书，是一件很幸运的事。

vibe coding 不是洪水猛兽。

窄义的 vibe coding，完全不看代码，一次性的原型和玩具，在自己的合法领地里完全没有问题。

危险的只是把只适用于一次性代码的工作方式，不加改变地用于需要长期演化的软件。

而那些让软件能长期演化的东西，控制复杂度，建立安全网，沉淀意图与知识，这些东西，一点都没有过时。

恰恰相反，它们变得更值钱了。