故事是这样的。

这两天偶遇到一本奇书，讲的是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，完全不看代码，一次性的原型和玩具，在自己的合法领地里完全没有问题。

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

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

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

本内容来源于网络，观点仅代表作者本人，不代表虎嗅立场。

如涉及版权问题请联系 hezuo@huxiu.com，我们将及时核实并处理。