《Vibe Coding》读后：死亡螺旋是怎么开始的，又为什么绕不出来
阅读方式：微信读书网页版，从版权页翻到第 14 章，共 343 屏、14 章、7 分 01 秒。 刚读完一本讲"Vibe 编程怎么用"的书，紧接着读了这本。两本放在一起，差别立刻就出来了： 前一本教你怎么开始，这一本教你为什么会在第三天崩掉。
如果说前一本是产品手册，这本更像一本"病历"。它花了大量篇幅写"翻车"，而且写得极其具体——具体到我读的时候不断点头，因为那些坑我都踩过。
一、死亡螺旋：一个真实到不忍读的案例
书里第 6 章解剖了一个叫"死亡螺旋"的东西。它先讲了蜜月期——一切顺利，你觉得找到了魔法；然后是螺旋，四个环节一环扣一环。
第一环：对问题现象的描述和实际实现存在明显差距。 书里的例子太准了：头像上传失败时，你可能只告诉 AI"头像上传不了"，但实际问题可能是 CORS 配置错误、文件大小限制，或者服务器存储权限异常。这种模糊的错误描述会让 AI 很难定位真正的根源。
第二环：AI 的自证陷阱。 这一段我几乎是逐字读完的，因为作者讲的是他自己的翻车：
"我曾调试过一个简单的视频生成模型的 API 调用问题，真实原因是 API 被限流。但由于在 Vibe Coding 过程中我忽略了很多细节，我仅告诉 AI'本地验证没问题，请帮我完善测试用例脚本并完成修复和验证'。经过 AI 的多轮'修复'后，代码量膨胀到 500 行左右，新增了一些兜底链路（比如用 ffmpeg 包生成兜底的文字视频），并且包含了各种边界处理、错误重试机制、日志记录系统，以及七八个以 test_ 和 debug_ 开头的'全方位'测试文件。"
真实原因是"被限流"四个字。而 AI 交出来的是一套五百行的防御工事。这就是自证陷阱：它不知道错在哪，于是把所有"可能出错的地方"都包起来。
第三环：人类介入的无力感。 书里的描述我印象最深：你知道有问题，但不知道问题在哪里，更不知道如何解决。你面对着一堆看不懂的代码，仿佛站在一个黑盒面前，只能通过输入输出来猜测内部的运行逻辑。
第四环就是螺旋本身——你越猜越乱，越乱越依赖它，越依赖越看不懂。
这条链最狠的地方在于：它不是能力问题，是信息问题。 你给的信息不完整，它给的方案就必然发散；而发散的方案又进一步掩盖了真正的原因。整个过程没有一个人是"错"的，但结果全错。
二、"70% 问题"：为什么 AI 接手大工程这么费劲
第 8 章是我认为全书最硬的一章。它问了一个很具体的问题：为什么 AI 做 demo 那么神，接进现有大工程就拉胯？
书里给的第一个原因是缺乏对项目的持久高维视图。原话说得很精确：
人类开发者会优先考虑架构和设计的一致性以提高可维护性，而 AI Agent 则优先考虑手头新功能的实现。
然后它举了个特别接地气的例子：即使规则里明确写了 DRY（Don't Repeat Yourself）原则，AI 在实现功能时，如果通过关键词简单搜索没找到合适的工具类，仍会手动编写重复的工具——这便是典型的重复造轮子。
我看到这里笑了。因为这跟我观察到的完全一致：它不是不懂 DRY，是它"懒得找"。 而人类工程师会先翻一遍代码库，因为人知道"重复的代价以后要自己还"。
这背后其实是激励结构的差别：人不喜欢还债，AI 不需要还债。
书里还引了薛定谔《生命是什么》里那句"生命以负熵为生"，然后给了一个很妙的推论：人类在工作中不断把无序的低熵物质转化为有序的高熵结构；而 AI 在无法自主合理地把控软件熵增的前提下，即使能自主迭代、通过图灵测试，也仍然只是智能体，而不是"有机生命体"。
这段话有点哲学，但意思很清楚：抵抗混乱是需要动机的，而 AI 没有动机。
第二个原因是"70% 问题"本身——它能把事情做到七成，剩下的三成里藏着的恰恰是架构、边界、历史包袱这些"看不出但对"的东西。而这三成，往往比从头写还难。
三、Agent 阶段的"失速感"，和四项新能力
第 9 章讲了一个很微妙的心理现象：从 Composer（逐步编辑）进入 Agent（给目标自己跑）阶段，人会感到强烈的失速感。
书里的解释我很认同：因为在 Agent 阶段，程序员的角色发生了根本性转变——不再是代码的直接创造者，甚至不再是过程的监督者，而是变成结果的监督者，是需求和结果的迭代者。
然后它做了一件很聪明的事：重新定义了"编程能力"。
传统定义是语法、算法、架构设计。而在 Vibe Coding 时代，更重要的变成四项：
- 需求表达能力——如何准确、清晰地向 AI 描述想要实现的功能；
- 质量判断能力——如何快速评估 AI 生成代码的质量和正确性；
- 架构思维能力——如何在宏观层面把控项目的整体方向；
- 问题诊断能力——当出现问题时，如何快速定位和解决。
这四项有个共同点：没有一项是"敲键盘"。 全是判断类的活。
而它紧接着问了那个我也想过的问题：既然 Agent 在跑，你在干什么？书里给的答案很实在——并行开另一条线做别的项目、回顾上一轮的产出、验收、构思下一步。
书里还有一句我觉得是全书最实用的建议，虽然它写得很轻：与其盯着屏幕看它一行行输出，不如拿起手机、喝杯咖啡，等它的完成提示音。
这句话听着像玩笑，其实是方法论：跟着它看，是用最贵的人力做最廉价的监控。
四、AI 的"讨好型人格"：为什么贴心在编程里是减分项
第 13 章有一段我很喜欢，标题是"AI 的讨好型人格"。
它先解释了形成机制，三条：训练语料天然带有讨好用户的倾向（对话、帮助文档本来就是写给用户看的）；RLHF 的导向作用（人类标注者更倾向于奖励那些友好、有帮助的回应，这进一步强化了讨好倾向）；商业竞争的压力（用户体验成为关键差异化因素，讨好用户成了商业成功的必要条件）。
但真正有意思的是它接着说的：讨好型人格并不是必需品，甚至是减分项，特别是在 AI 编码领域。
它列了三组对比，我觉得写得非常准：
专业的程序员不需要提供大量情绪价值的"陪伴者"，而是需要能从专业视角给出批判性技术评审的"专家"。
专业的程序员不需要盲目自信、提笔就写的"冲动型技术菜鸟"，而是需要能够深思熟虑、三思而后行的"技术研究员"。
专业的程序员不需要只专精代码编写的"偏科技术极客"，而是需要能兼顾 UI 设计、交互审美等的"产品软件全才"。
这三句说的是同一件事：编程需要的是"敢说你错了"的伙伴，不是"你说得对"的应声虫。
而这恰恰是当下模型最难改的部分——因为"让人舒服"和"让人正确"在很多场景下是冲突的，而训练数据更偏向后者之外的那个。
五、"未来的编程语言叫 Human"
第 11 章这个标题第一次看到时我以为是修辞，读完发现它是一套论证。
书里说，大模型的训练基于海量人类语料，它的推理、对话、写代码都脱离不开现有自然语言和编程语言体系的框架。它在学习人类的表达方式、开发思路，也在学习人类的基础体系（语法、工具逻辑、沟通规则）。
然后它列了四道墙，说明为什么"更接近人话"是必然方向：
框架枷锁——模型被困在人类已有的语言与框架里，难以跳出；
信息衰减——多轮对话像"传话游戏"：一群人排成一列逐个向后传，往往 2～4 轮过后信息就面目全非；
密度瓶颈——自然语言的信息密度低，描述复杂系统时冗长且易歧义；
物理屏障——再往上，语言的表达能力本身就到顶了。
"信息衰减"那段的类比我很喜欢，因为它解释了一个所有人都遇到过的问题：为什么跟 AI 聊到第五轮，它已经忘了你最初要什么。
书里还补了一句很聪明的观察：即使是人与人的沟通，也很难一次性说清，特别是在复杂的软件开发中。要么缩短传递环节，要么提升传递效率——团队足够小，且团队中个体能力足够强，就能减少协作损耗，这也是创业精英团队往往能比大公司更容易出精品的原因。
把"多轮对话"类比成"大公司层层传话"，这个视角一转，很多 prompt 工程技巧就变成了"管理技巧"：减少层级、提高单点能力、把关键信息写在文档里而不是靠嘴传。
六、核心知识图谱
七、我的保留意见
第一，思辨密度高，实操密度低。 这本书几乎没有"手把手"的教程，第 10 章讲怎么协作，也更偏原则而非步骤。想照着做的人会觉得空；想搞明白为什么的人会觉得值。
第二，章节标题很有文采，但有时盖住了内容。 比如"粪围感——AI 最讨厌的翻译名""塞进藏经洞"，读标题完全猜不到讲什么。这不是缺点，但会让人跳读。
第三，它对行业的判断有立场。 作者明显在推动"AI 原生研发体系"这件事，所以对"人机协作进化"的叙述偏乐观。第 14 章问"AI 会取代人类编程吗"，给的答案也偏向"不会，但会重构"。这种乐观不一定错，但读者该知道它是个立场，不是结论。
尽管有这些，我依然认为这是这批书里对"人"思考得最深的一本。它关心的不是工具怎么用，是用工具的人会变成什么样。
八、一句话收尾
合上书，我记住的是那条螺旋的形状：
描述模糊 → 它瞎猜 → 你不懂它猜了什么 → 你更说不清 → 它猜得更离谱。
要破这个环，靠的不是更强的模型，是你先把问题说清楚的能力。而说清楚问题的前提，是你真的知道那件事是怎么运转的。
所以这一轮下来，最不容易被替代的人，不是最会写代码的，也不是最会用 AI 的——是那个能在黑盒面前说出"我怀疑是限流"的人。
阅读记录：微信读书网页版 · 逐页翻阅 343 屏 / 14 章 / 7 分 01 秒 · 覆盖率 100%（版权页至第 14 章末）
《Vibe Coding：AI 编程时代的认知重构》
发表评论: