Vibe编程：探索AI时代编程新范式：真话都写在最后一章

2026-11-04silcano

微信读书《Vibe编程：探索AI时代编程新范式》· 张斌（Captain）著 · 2025 年 6 月 · 七章
逐页翻阅 333 屏 · 7 章 · 2026-11-04
说明：这本书的自序落款是 2025 年 6 月，书里的案例大量来自作者自己的项目和身边团队（《王者荣耀》《天工》都在其中），所以它比一般"AI 编程"书更接近一线工程现场，也更接近一线的那点私心。我抽了七处逐页核对：前言、打孔卡时代一节、王者荣耀案例与开源社区数据、需求文档截图、轻量级工程化一节、Git 安装与 Vercel 部署、专业开发者视角的局限。以下判断只在抽样范围内成立。

先给结论：这本书最诚实的一章是第七章，题目就叫"局限与挑战"。那一章里它说，AI 编程工具"倾向于生成看起来很'专业'的代码"，像"用大炮打蚊子"；说它的本质是"基于已有代码的模式识别和重组"，"就像一个博学的图书管理员能够快速找到相关资料，但无法进行原创性的科学研究"。这些话又准又不留情。

而更要紧的一句在第五章："缺乏工程化支撑的 Vibe 编程，其优势只能体现在短期或小规模的项目中。"

我的判断是：这本书的真话，全排在后半本；而前四章，一直在讲这件事有多好。我不是说前面四章是假的。我是说，一本书的限定条件如果只能放在结尾才敢说，那前面那些例子，读者就会当成普遍情况来用。而这正是这类书最危险的地方。

一、它想说的那句话，其实是对的

书的第一章立论，核心是从"命令式"到"意图式"。这个提法不新，但它把差别讲清楚了：命令式编程里，你说的是"怎么做"——先取这个，再判断那个，循环到条件不成立；意图式编程里，你说的是"要什么"——我要一个能按标签筛选、支持导出、加载不超过两秒的列表页。

这个转变的真实含义，不是"以后不用学编程了"，而是把"翻译"这一段外包出去。过去一个人要写程序，得先在脑子里把需求翻译成数据结构、控制流、接口调用，再敲成代码；现在这一段交给模型，人只需要把需求说清楚，再判断产出对不对。

这里有个关键区别，很多书没讲清，这本讲清了：外包出去的是"翻译"，不是"判断"。翻译可以外包，判断不能。因为判断的前提是知道什么算对——而"什么算对"这件事，只有你自己能定义。你如果不知道一个列表页该多快、该支持什么筛选、导出成什么格式，模型给你的东西你连验收标准都没有。

第 3 章把工具分成三层：大模型问答、IDE 插件、端到端 Agent。这个阶梯也是对的，而且有个隐含的判据——越往下，人对过程的控制越少，对结果的验收要求越高。问答阶段你还能一句句看，插件阶段你只能看 diff，Agent 阶段你只能看最终能不能跑。所以能力越强的工具，越需要你先有验收标准。这个推论书里没明说，但它是三层划分真正的用处。

二、全书最值钱的，是替专业开发者说的那几段

第 7 章 7.1.2 讲专业开发者视角，这四页是我最想推荐的部分。它没有顺着"AI 提效"的话往下说，而是把三类风险摊开了：

AI 编程工具往往倾向于生成看起来很"专业"的代码，使用复杂的设计模式和架构，即使在简单的场景下也是如此。这就像"用大炮打蚊子"，虽然显示了技术实力，但增加了不必要的复杂性。对于需要长期维护的项目来说，简洁和直接往往比复杂和"炫技"更有价值。

对专业开发者来说，当前的 AI 编程工具本质上是基于已有代码的模式识别和重组，它们能够非常优秀地解决已知问题，但在面对全新的技术挑战时却可能束手无策。这种局限性在前沿技术领域或小众应用场景表现得尤为明显。就像一个博学的图书管理员能够快速找到相关资料，但无法进行原创性的科学研究。

"用大炮打蚊子"这个比喻很准，而且它指出的是一种系统性的偏差，不是偶发的失误。模型为什么爱堆设计模式？因为它的训练语料里，"专业代码"的样子就是分层、抽象、接口、工厂——它学到的是"专业感"的表征，不是"必要性"的判断。所以它会在只需要一个函数的场景里给你三个类和一个接口。

这个偏差的代价，不在写的时候，在改的时候。你接手一份三层抽象、四个接口、两个工厂的代码，想改一个字段的取值范围，得先搞清楚它是从哪一层流下来的。AI 生成代码省下的那两小时，会在三个月后的某次改动里连本带利还回去。

"图书管理员"那个比喻也值得记下来。它把 AI 的能力边界说得比"幻觉"两个字精确得多：检索和重组是它的强项，原创是它的弱项。而工程实践里，"已知问题的已知解法"占八成，"没有现成答案的新问题"占两成——AI 在那八成里表现惊人，在那两成里会一本正经地给你一个看似合理的错误方案。问题在于，你往往是在踩了坑之后，才知道自己碰到的是那两成。

这本书敢写这两段，说明作者不是纯粹的布道者。他知道自己卖的是什么，也知道它不值什么。

三、但它自己的案例，我得打个问号

第 4 章讲大型企业的实践，举了《王者荣耀》的例子。我按原书抄下来：

以《王者荣耀》新赛季迭代为例，团队在 IDE 输入"生成具有炫酷特效的战斗技能代码"后，天工即刻产出完整技能脚本、UI 交互逻辑及粒子特效配置，令版本迭代效率提升约 50%，玩家首周留存率提升 8.3%。这一深度集成不仅验证了 Vibe 编程思维在大型复杂项目中的卓越效能，也助力腾讯游戏在激烈竞争中始终保持领先。

这段话我读了三遍，越读越觉得有问题。三个问题，从小到大。

第一个，产出物不对。"完整技能脚本、UI 交互逻辑及粒子特效配置"，这是三样东西，分属三个工位：策划写技能逻辑，客户端写交互，美术做特效资产。一句"生成具有炫酷特效的战斗技能代码"，可能产出技能逻辑的骨架，绝不可能同时给出可用的 UI 交互逻辑和粒子特效配置——因为后者不是代码，是资产。把三样产出压在一句话上，说明这句话不是对工程流程的描述，是对效果的概括。

第二个，因果跨了级。"版本迭代效率提升约 50%"是研发侧指标，"玩家首周留存率提升 8.3%"是产品侧指标。两者之间隔着上线质量、版本内容吸引力、同期运营活动、竞品动态。把留存提升记在一次代码生成上，等于把整条链的功劳记在最后一环。这类归因在日常汇报里很常见，写进书里就成了"证据"。

第三个，也是我最在意的：没有对照。没有样本量，没有对照期，没有说明同期还改了什么。8.3% 这个数字精确到小数点后一位，却没有任何可复核的口径。一个精确到小数点的数字，配一个没有口径的因果，这是"叙事性数据"的标准长相——它看起来像结论，其实是修辞。

更值得玩味的是，就在同一页的下一节，作者自己引了一份很硬的材料：

2024 年发布的一份研究报告"Generative AI for Pull Request Descriptions: Adoption, Impact, and Developer Interventions"分析了 18,256 个使用 Copilot 自动生成提交描述的情况，发现：
· Copilot for PRs（即自动生成提交描述功能）的使用正在快速增长；
· 采用 AI 描述的 PR 审查时间较短，合并率更高；
· 开发者往往会再手动完善自动生成的内容。

18,256 个样本，三条发现，最后一条是关键：开发者往往会再手动完善自动生成的内容。

这句话和前面那个"即刻产出完整技能脚本"的案例，是互相矛盾的。一个说"生成完还得人改"，一个说"一句话即刻产出完整"。同一本书，相隔几页。前者是从 18,256 个真实 PR 里统计出来的行为，后者是一个没有出处的单点案例。我更信前者，因为它的口径清楚、样本够大、结论还不好听。

这个矛盾其实指向全书最该讨论、却讨论得最少的那个问题：AI 生成之后，人还得改多少？如果答案是"改得不少"，那"效率提升 50%"就要重新算——因为人改的时间也是时间。如果答案是"改得很少"，那 18,256 个 PR 里的开发者为什么不放心？

要回答这个问题，其实不需要大厂案例，只需要一个很小的对照实验，成本大概一个下午：同一个需求，让 AI 生成两版；第一版直接提交，第二版你自己过一遍再提交；然后记录两次"提交到合并"之间你动了多少行、花了多少分钟。

按我的判断，这个实验的结果不会太好看：AI 一次生成的代码，行数通常是对的，但能被直接接受的行占比不会高，剩下的改动集中在三类——边界条件、错误处理、以及"这个函数它假设了一定会成功"。这三类恰好都是"不看运行结果就发现不了"的东西，所以它们不会被你在读代码时抓到，只会等到测试或者上线才冒出来。

这个结论对"效率提升 50%"意味着什么？意味着真正的账要这么算：生成省下的时间，要减去你读、你改、你验的时间，还要减去"你没读出来、后来才发现"的返工时间。前两项通常还能算平，第三项才是决定性的——因为它不会出现在当天的工时里，只会出现在三个月后的故障单上。

四、它做对的一件事：把约束写在需求里

第 6 章实战，作者给了自己的需求文档截图。这份文档的写法，我认为是全书的操作示范，值得单独拎出来：

## 3. 约束
### 技术栈约束
- 前端框架：使用 HTML5 + CSS3 + JavaScript，主要使用 Canvas 或 WebGL 实现粒子渲染。
- 交互库：可选 GSAP、three.js 或 pixi.js 实现更丰富的动画控制。
- 框架要求：优先原生实现，如需框架，建议使用 React。

这三行值钱在哪？值钱在它把"选择权"收窄了，但没收死。"主要使用 Canvas 或 WebGL"是硬约束，"可选 GSAP、three.js 或 pixi.js"是软约束，"优先原生，如需框架建议 React"是有条件的偏好。三级约束摆在一起，模型就知道哪些不能碰、哪些可以挑、哪些看情况。

大部分人写需求给 AI，写的是"做一个炫酷的粒子背景墙"。这句话里没有一个约束，模型只能用默认值——默认值往往是它训练语料里最常见的那个方案，通常也是最重、最复杂的那个（还记得"大炮打蚊子"吗）。

约束不是限制 AI，是替 AI 排除它不该做的选择。你把技术栈定死，它就不会在框架选型上浪费一次幻觉；你把"优先原生"写上，它就不会默认给你装三个包。这一条经验，比书里任何一个提示词模板都实用，而且它跟具体模型无关，换哪家都能用。

顺带说一句：这份需求文档是 Markdown 原文截图，里面的 ** 粗体标记还留着。这说明它是真的从项目里截的，没做过排版美化——这种"没洗过"的截图，比精心排版的示意图可信得多。

五、篇幅错位：一本讲范式的书，用整节教你装 Git

第 5 章讲工程化，5.4.2 节之后有几个小节在讲版本控制。我翻到的那一页，内容是 Git 的安装步骤，原文抄下来：

在 Windows 操作系统中，安装步骤如下。
(1) 下载安装程序：访问 Git 官方网站并下载最新的 Git for Windows 安装程序。
(2) 运行安装程序：双击下载的 .exe 文件以启动 Git 安装向导。
(3) 遵循向导指示完成安装：对于大多数用户，默认选项是合理的，除非有特定原因需要更改。
(4) 验证安装：安装完成后，打开命令提示符……输入 git --version 命令并按回车键，验证 Git 是否已成功安装。

我不怀疑这段的正确性，它写得很对。我想问的是另一件事：这本书的副标题是"探索 AI 时代编程新范式"。一本讲范式的书，为什么要把"双击 exe 下一步"写进正文？

答案不难猜：它想让零基础读者也能跟着做。这是个善意的选择，但代价很实在——333 屏里，用来教"双击安装"的篇幅，本可以用来讨论"AI 生成的三百行代码，你怎么在二十分钟内判断能不能用"。前者到处都能查到，后者只有这种一线作者才写得出。

这个错位在书里不是孤例。第 6 章实战，从项目脚手架一路写到部署上线，中间有大量手把手的命令。333 屏是个硬约束：多一页讲装 Git，就少一页讲别的。而这本书真正稀缺的内容——那些只有一线工程师才写得出的判断——恰好被挤在每章末尾的几百字里。部署那段倒是让我眼前一亮：

bash ./packages/server/build.sh
vercel build --prod
vercel deploy --prebuilt --prod --archive=tgz

这三条命令是真的。尤其 --prebuilt 加 --archive=tgz 这个组合，是为了绕开 Vercel 上传文件数量的限制——这种细节，只有真被卡过的人才会写。同类的书里，部署一节通常停在"点击 Deploy 按钮"，因为作者只走过那条路。这本书走的是命令行那条，说明它至少真的部署过一个带服务端的项目。

但截图里也留了痕迹：命令回显里的项目名和团队名，是作者自己仓库的名字，不是 your-project 这种占位符。这不算大错，可它会让照抄的读者在第一步就撞上"找不到这个团队"。教学样本的第一条规矩是换掉所有真实标识——这条规矩，实操书十本里有八本会忘。

六、那句"远超本书内容范围"

第 5 章 5.4.2 开头有一句话，我读的时候停了一下：

虽然工程化对于保障软件质量与长期稳定性有其不可或缺的价值，但完整的工程化体系本身是一个庞大而复杂的课题，远超本书的内容范围。因此，本节将提供一套基础、轻量级且易于实践落地的工程化设计方案，读者可以将其理解为满足"必要质量保障"的最小集合，以最低成本获得有效的质量与维护性保障。

这句"远超本书的内容范围"是诚实的，但它也是全书的转折点——作者在这里承认了一件事：Vibe 编程要真正落地，需要的东西，这本书讲不完。

问题是，他接下来给的"最小集合"，一点都不小。版本控制、代码审查体系、测试、持续集成，四样齐上。这四样，恰好就是传统软件工程里最费工的那四样。换句话说，"轻量级工程化"并没有真的变轻，它只是把传统那套压缩了一下，然后换了个名字。

我认为这里应该更狠一点。真正的问题不是"Vibe 编程需不需要工程化"——显然需要；真正的问题是：在 AI 生成占了大头的项目里，工程化的重心该往哪挪？

我的判断是往"验收"挪，而不是往"流程"挪。传统工程化重心在过程：先设计、再评审、再编码、再测试。这套流程的前提是"代码是人一行行写的，写的过程里人一直在想"。AI 生成打破了这个前提——代码是瞬间出现的，写的过程里没人想过。所以流程里那些"在写的时候顺便做"的质量动作（命名时想清楚语义、抽函数时想清边界、写注释时想清意图），全部失效了。

补这个缺口，只有一条路：把评审提到前所未有的位置，而且要评得比过去更细。过去评审看的是"你写得对不对"，现在评审看的是"这段代码是谁写的、为什么这么写、它依赖的东西真的存在吗"。多出来的这一问，是 AI 时代评审和过去评审的全部区别。这本书讲了代码审查，但没讲这一问。

下面是这本书的结构图谱，四列分别是它的立论、它硬的地方、可疑之处、它的短板：

图文对照：一张图看完这本书

七、它的短板

老实写，五条。

一、真话全排在后半本。"缺乏工程化支撑的 Vibe 编程，其优势只能体现在短期或小规模的项目中"，这句在第五章；"局限与挑战"整章在第七章。而第 1 到第 4 章一直在讲这件事多快、多普惠、多有前景。一本书如果把限定条件写在结尾，绝大多数读者读不到那一步——他们会带着"什么都能做"的印象合上书，然后在第一个真实项目上撞墙。正确的排法，是第一章就把这句摆出来，然后全书去论证"那怎么把短期做成长期"。

二、"轻量级"名不副实。版本控制、代码审查、测试、持续集成，四件套一条不少。这套东西对专业团队是常识，对这本书真正想说服的那批人（产品经理、设计师、独立开发者、"全民开发"里的普通人）是四座山。说它"轻量"，只是相对"完整工程化"而言轻；相对读者的实际能力，它一点都不轻。书里没有给"我现在只会做静态页，这四样从哪一样开始"的路径。

三、案例只有成功的那一面。第 4 章分了四类：独立开发者、创业公司、大型企业、开源社区。四类全讲的是"做成了"。没有一个是"用了 Vibe 编程，最后项目黄了"的复盘。而这类复盘才是读者最需要的——因为失败的方式是可复用的，成功的故事往往只是运气好。一本讲新范式的书，如果连一个失败案例都没有，那它对风险的描述就只能停在概念层（"存在安全隐患""可能难以维护"），停不到操作层（"哪一步没做，会在第几个月炸"）。

四、关键数据不可复核。前面那个 8.3%，加上"效率提升约 50%"，两个数字都没有口径、没有样本、没有对照。而同一页引用的 18,256 个 PR 的研究，口径清楚得多。一本书里同时存在这两种材料，说明作者知道好数据长什么样，只是自己的案例拿不出好数据。拿不出可以不说，说了就要能复核——这是技术写作的底线。

五、历史章节写得像资料汇编。第 2 章讲编程方式演变，从打孔卡讲到低代码。史料是对的：那一页讲专用穿孔机，"每条指令需拨动开关 8 次并通过指示灯确认。这种方式不仅耗时耗力，也极难维护，本质上代码成了硬件电路的映射"——这句写得挺好。但紧接着的图 2-6，图注老老实实写着"图片源自维基百科"。一本讲"新范式"的书，用维基百科的图讲历史，问题不在版权，在深度：它说明这一章是从二手材料整理的，不是从一手经验写的。这一段读起来像背景铺垫，不像论证。

也得说它的好话。它对"三类工具"的划分（问答、IDE 插件、端到端 Agent）是目前同类书里比较清楚的一种；它对专业开发者那四页的判断（大炮打蚊子、图书管理员）是真的懂行；它把约束写进需求文档的做法，是能直接抄走用的；它讲部署时给出的命令行细节，说明作者真跑过。这本书的可信度是不均匀的——凡是它自己干过的事，写得又准又细；凡是它想论证"这件事很伟大"的地方，就开始借数字和案例。

八、一句话

如果只带走一句，带走这个：想法现在免费了，交付没有。

这本书真正改变的东西，是"从想法到能跑的东西"这一段的前半程。过去你要先学三个月语法，才能把脑子里的东西变成一个能点的页面；现在你可以在一小时内看到它，哪怕它很粗糙、很脆弱、很快就得重写。这个变化是真的，而且它值钱——因为它把"我该不该做这个"的判断，从事前挪到了事后。试错成本降下来，值得试的想法就变多了。

但它没改变后半程。"能跑"到"能交给别人用"，中间隔着的东西，这本书在第 5 章用四座山概括了：版本控制、审查、测试、集成。这四样一样没少，一样不能省。

所以"人人都是开发者"这句话，得改一个字：人人都是原型开发者。做原型，门槛确实降到了零；做产品，门槛一点没降，只是从"会不会写"挪到了"会不会验"。而"会不会验"这件事，比"会不会写"更难教——因为写有语法可查，验只有判据可依，而判据得你自己定。

作者其实知道这一点。他先在第 5 章末尾写了那句限定，又在第 7 章用整章篇幅讲"局限与挑战"，把安全、隐私、原创性、成本、产品定位一条条摊开。只是这一章排在最后，而大多数读者，翻不到那里。

阅读记录：《Vibe编程：探索AI时代编程新范式》· 张斌（Captain）著 · 2025 年 6 月 · 微信读书逐页翻阅 333 屏 · 七章 · 抽读 7 处逐页核对 · 笔记写于 2026-11-04