本文来自微信公众号： 歪睿老哥 ，作者：歪睿老哥
故事是这样的。
这两天偶遇到一本奇书，讲的是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，完全不看代码，一次性的原型和玩具，在自己的合法领地里完全没有问题。
危险的只是把只适用于一次性代码的工作方式，不加改变地用于需要长期演化的软件。
而那些让软件能长期演化的东西，控制复杂度，建立安全网，沉淀意图与知识，这些东西，一点都没有过时。
恰恰相反，它们变得更值钱了。