Vibe Coding：AI 编程时代的认知重构

如果像看其他杂书一样看完书评再来确定值不值的去看，那我就错过了。 很多书友觉得这本书说的太空，没有实操，但正如作者说的，如果是看“术”的，不会去看书，书的时效性太差，网上的文章视频才是真正的打开方式，vibe coding用一日千里来说都不过分，我作为每天的重度用户，深有同感，我正是带着想探究vibe coding的代际迭代的底层逻辑的想法在找书的。阅读本书的过程颇有点之前读《浪潮之巅》《芯片战争》等科技史书之感，对于才几年的一个概念，却已像历经沧桑 作者作为这项技术的参与者，使用者，其中的感悟自然是要比我这种只是使用的人更多的多，带着这种想法翻了这书，以前面说到的这项技术的发展速度，这书也是得趁热翻，凉了效果可能就打折了，外面可能已经换了天地 在书中很多点都会与内容产生共鸣，比如由此产生的产业人才结构的变化等 读着读着，就会开小差，比如现在与ai协同写代码，就像自己刚成为一名小组长时候带着小伙伴写，为了不至于失控，至少我是把框架整好，然后就看各自发挥，如果时间不允许就只能从结果上去看是否符合预期了。再后来，就要管理一个研发团队，这时候拆分的就不是某个需求的任务了，而是整个技术线，这不正是多agent方式吗。以后考验ai协同能力，对人的要求就拔升到leader层面了。类似的小差其实蛮多，想了蛮多 一直看书都不写书评，但还是希望对这个概念感兴趣的书友们，不要错过一本还行的书，可以翻翻

说实话，这本书不行。 为啥这样说呢，我看你这本书就是想要了解vibe coding的原理和实践的，要学习vibe coding的。 但是整本书下来不断的讲原理和理论还有方法，连一个具体实践案例都没有。 vibe coding作为一个新生事物，还在不断的发展过程中，你说你进行很系统的理论研究并作为指导，这是一件不太现实的问题。 但是这本书就想做这件事，因此书中反复讲理论，做论证，做预测，和传统的编程逻辑对比。而且同样的内容反复出现，并做了vibe coding的影响，对社会，个人充满了人文关怀等等。 但最重要的，教会你的读者使用vibe coding这个最重要的事情，你没有做到，甚至做的很差，一个具体案例和实践没有。 所以我评价本书是本末倒置的典型。

《Vibe Coding》并非一本教你如何写代码的“术”书，而是一本教你如何“不写代码”的“道”书。作者以其在阿里云通义灵码的实战经验，精准预言了AI编程时代的核心悖论：代码越写越少，但工程思维必须越来越深。 书中指出，当AI能秒级生成代码时，程序员的核心竞争力已从“编码能力”转向“代码品位”与“技术责任感”。真正的Vibe Coding不是随意“瞎聊”，而是在严谨的Spec（规范）与随性的Vibe（氛围）之间找到平衡，让AI成为你大脑的“外挂”，而非简单的“打字员”。这本书最大的启发在于：AI时代，最稀缺的不是会写代码的人，而是能驾驭AI、定义架构的“系统设计师”。

代码设计或优化原则： 1. 确保代码的可维护性和可扩展性。 2. 避免代码重复。 3. 保持简单和直接。 4. 拒绝过度设计。 模型的上下文窗口大小包括输入和输出，要使模型正常地使用，需要为输出预留token数量。 精确表达需求的能力，无论是对人还是对AI，都是开发者的核心技能，只是在 Vibe Coding 时代更加重要和关键。从提示词工程到上下文工程，与模型的协作沟通能力，直接决定了我们能否适应AI时代的软件工程研发。 Context engineering is the delicate art and science of filling the context window with just the right information for the next step. --Andrej Karpathy AI本质上是基于上下文理解生成高概率token序列的工具，而操作它的人类才是应该对AI生成质量负主要责任的主体。 AI 的真正价值不在于模仿人类，而在于凭借自身的超人类特质，成为人类的高效协作伙伴。 Vibe Coding 核心是 Coding 的能力和 Vibe 的心态。 经验丰富的工程师往往推崇奥卡姆剃刀原则：如无必要，勿增实体。 AI Coding 时不要玩手机！！！并不是劳逸结合不好，而是我们要保持在线的状态。 TDD（测试驱动开发）：先写测试，再写实现代码，遵循"红→绿→重构"循环。 PDCA 工作流：持续改进循环模型——Plan（计划）→ Do（执行）→ Check（检查）→ Act（处理）。 BMad 工作流：基于多 AI Agent 角色（产品经理、架构师、开发者等）协作完成软件开发的框架。 ANP 协议：AI Agent 间通信协作的网络协议，用于 Agent 发现、信息交换和任务协调。 A2A 协议：Google 提出的 Agent 间互操作协议，让不同厂商的 Agent 能无缝协作。 flake8：Python 代码风格与逻辑错误检查工具（整合 PyFlakes + pycodestyle + McCabe）。 mypy：Python 静态类型检查工具，通过类型注解在运行前发现类型错误。 bandit：Python 安全漏洞静态分析工具，扫描危险函数、硬编码密码等安全问题。 pytest：Python 最流行的测试框架，语法简洁，插件生态丰富。 投机解码：用小模型快速生成候选 token，大模型并行验证，加速 LLM 推理。 search-replace：AI 编程中只输出"搜索-替换"指令来修改代码，减少 token 消耗、降低出错率。

总体评价“空洞”，不具备相应的价值核心，跟记流水账一样，我从两个方面说下感受。 一是实践。这本书没有任何实践例子，甚至连作者自身使用vibe coding时具体案例也没有，阅读起来就跟观众在台下看演员自顾自摆动作，很难有什么联系。虽说作者反复强调本书没有例子，可对于软件工程来说，很多技术本就基于某些概念组合而成，同样vibe coding也同样能以一个实际项目去作为概念论证才对，操作步骤中的问题与思考才是具有价值的部分。 二是理论。理论属于网上普遍流传的一套，对于有过技术落地到实际业务中的人都能轻松感受，而作者也只是泛泛而谈，没有提炼出自身的观点去做出核心表达，也可能是作者本人就在这波漩涡之中难以抽离思维去理解。同样ai属于新事物，对于未知不敢去描述是人之常情，但读到后面全都是凑字数的猜想，都不与实际生活的能源、领域、基础设施等一同去考虑，在知识面上显得狭隘。 整本书属于，有技术落地经验或者实际vibe coding过的人不用看，书中内容在日常刷论坛和项目过程中都能体会；好奇ai技术的小白看了也等于没看，整体概念缺少实际支点忘的很快，不如直接跟着网上教学视频实操印象更深。

AI的发展正在改变程序员的编程方式，在面对Vibe Coding时代，程序员的核心能力不再是单纯的代码编写，更加侧重于一下三点： 1.需求拆解能力：将模糊的商业想法转化为清晰、AI可执行的"产品需求提示词"（PRP） 。 2.产品审美与系统思维：具备理解用户需求与业务场景的能力，而非仅关注技术实现细节 。 3.结果校验能力：能够快速评估AI生成方案的优劣，关注需求本质而非固定实现路径

AI对编程领域的影响是革命性的，不单单是工作方法的改变、工作效率的提升，更是对编程的认知产生颠覆性的变化。Vibe Coding 概念上不复杂，关注这方面的人主要还是希望更好的用好工具。本书的写作角度是蛮高级的，但要有耐心阅读下去并不容易。

从最开始的机器语言，到汇编语言，到高级语言C语言，到JAVA、Python编程语言，其发展都是越来越符合人的使用习惯，直到现在Vibe Coding，仅凭自然语言描述需求就能生成代码。这一路非常符合人的使用的发展过程。 Vibe Coding依托人工智能，大幅降低了编程门槛，让编程不再是专业人士的专属技能，极大提升了开发效率。但与此同时，我更加坚信：AI只是高效的编程工具，唯有知其所以然，深耕计算机底层知识、建立核心编程思维，才能真正掌握编程能力。 很多人借助Vibe Coding完成编程任务，却完全不懂代码底层逻辑、运行原理和漏洞成因，只会机械套用AI代码。这种没有底层认知的编程方式，只能应对简单固定的场景。一旦遇到程序报错、场景适配异常、复杂逻辑优化等问题，使用者便会束手无策。我们要主动钻研底层知识、锤炼编程思维，用扎实的技术功底驾驭AI工具，而非被动依赖工具。 技术工具不断迭代，但计算机底层逻辑与核心思维永恒不变。Vibe Coding重构了编程形式，却没有改变“知其所以然”的技术本质。未来，唯有深耕底层、拒绝浅层依赖、以思维驾驭工具，才能在AI编程时代实现真正的技术成长，站稳技术根基。

这是一本抽象的书，所谓抽象就是脱离具体情境，萃取出事物核心共性特征的过程。脱离情境就让很多人产生抗拒了，因为没有具体案例学习理论是很违背认知规律的，首先认知负荷太大，无法将理论和已有经验联系起来，无法形成组块，工作记忆容量很快耗尽，人就迷糊了，进而放弃阅读。比如你的背景知识中没有软件工程的概念，那么读到瀑布模型，读到敏捷开发，读到测试驱动开发（TDD） 就会云里雾里。在再如你没有过实际使用 AI 编程工具的经验，你也很难感受到作者所说的 vibe coding 中的真正痛点：如何让 AI 在一个真实的项目中发挥作用，而不是从 0 到 1 单轮对话做出一个看似牛逼的玩具。作者真正在意的是如何让 AI 完成从 1 到100 在真实项目中的落地。所以很多通过书名找书想要快速入门 VibeCoding 的读者可能有点失望了！ 但为什么作者要把这本书写得这么抽象呢？其实从面向对象的角度来看，抽象的目的就是用更通用的接口去适配更广泛的场景。作者将讲 VibeCoding 的方法论，因为这些方法论是从各种 VibeCoding 工具、案例、经验、技巧抽象而来的，可以应用于 VibeCoding 的各种场景。因为 VibeCoding 甚至于在更大范畴 Harnees Engineering 中时效性作为一个关键变量让我们不得不通过抽象来应对这种从过眼云烟般转瞬即逝的时间轴上抓取值得沉淀下来的精髓。 那么 VibeCoding 到底是什么？氛围编程？个人的一句话总结就是：用嘴编程！当然打字也算。 学习 VibeCoding 需要具备哪些能力？会说话就行，这是入门门槛，别以为这很简单，其实会说话也是一门技术活，如何让你说的话 AI 听得懂，还能遵照执行，而且还要刚好满足你的需求。这就不是技术了，而是艺术！ 说话的技术首先体现在你要懂你说的话的意思，其次你还要知道你说的话 AI 能不能听得懂？所以其实这是一个双向奔赴的过程。这个过程中一方面大模型越来越聪明，越来越懂你，另一方面作为人类的你也要不断学习，才能说出高质量的话。 作为人类应该学什么？作者建议是全栈工程师，前端、后端、数据库、运维、测试、产品、营销、UI 等等 本书中作者偶有的金句引用，博古通今，很有文化底蕴。 部分段落 AI 味较浓。 关于 Vibecoding 的未来，不确定性的本质是不可预测的，所以看看就好，但如果无法压抑对确定性的偏好，一定要做点什么，心理才会舒服的话遵照执行也无妨！ 一句话推荐：本书适合有 Vibe coding 经验的读者作为沉淀方法论的读物！

用 Claude Code 已经有一段时间了，"vibe coding" 这个词也反复听到，但一直没弄清楚它具体指什么。于是找来这本书，想系统地了解一下。读完之后，真正留在脑子里的倒不是 vibe coding 的定义本身，而是作者引出的两个问题：设计模式还有没有存在的必要，以及工程师这个职业还能走多远。 ➡️设计模式，是为人脑的局限而生的 作者对软件工程的理解很深——不只停留在编码层面，而是看到了编程的本质：用软件工程的方式解决现实问题。书中有个观点让我印象很深：软件工程领域沉淀下来的设计模式，本质上是人类自身局限性的产物。人脑能处理的复杂度有限，"上下文窗口"也非常小，设计模式正是为了弥补这些短板才被发明出来的。 这就引出一个值得琢磨的问题：如果未来的软件都由模型来理解、由模型来维护，这些专为人类量身定制的设计模式，还有必要遵循吗？我觉得这里确实要打一个问号。 ➡️上下文工程，解决的是模型的"暂时性缺陷" 作者在书的结尾提出一个判断：99% 的程序员会失业。对此我深有同感。 我最近在做一个 agent 项目，核心就是上下文工程。但如果追问一句——上下文工程到底在解决什么问题？答案其实是模型自身的缺陷：目前上下文最高只有 1M 的限制。这个限制主要来自两个方面：一是 1M 上下文背后对应的 KV cache 高达几十到几百 GB；二是上下文过长之后，模型很难从海量信息中准确定位真正需要的内容。 假如有一天模型的上下文达到 500M，上下文工程几乎就不再被需要了——团队的全部信息可以一次性交给大模型，只有实时数据才需要通过外部接口获取。换句话说，今天我们精心构建的这一整套东西，解决的可能只是一个过渡期的问题。 ➡️当限制被突破，高级工程师还剩下什么 按我目前的理解，高级工程师的核心价值在于架构决策、技术选型和方案设计。我平时工作中，这些事情往往需要和模型反复对话才能敲定；有时模型坚持错误的方向，还得由我来拍板。但仔细想想，很多时候并不是模型没有能力理解，而只是它的上下文有限，缺乏足够的环境信息。 Claude Code 和 Cursor 的出现，已经能够顶替初级工程师了。等到上下文的限制被突破、模型能力进一步进化，高级工程师大概率也会被顶替。作者说 99% 的程序员会失业，读之前我可能会觉得夸张，读完再对照自己每天的工作，反而觉得这个判断并不遥远。