前言
为什么写这本书，以及它是写给谁的
一个笨拙的开始#
如果你在 2023 年初路过我的电脑屏幕，你大概会看到一个荒诞的场景：
我在 ChatGPT 的对话框里写代码，然后复制到编辑器，运行，报错，把错误信息粘贴回去，等它改，再复制，再运行，再报错……
这不是什么高级工作流，本质上和以前在 CSDN 上搜帖子、在 StackOverflow 上翻问答没什么区别——只不过这次"回答问题的人"是一个聊天窗口。
但就是从那个时候起，我已经隐隐感觉到：这东西会改变一切。
我的 AI 编程进化史#
我算是第一批"吃螃蟹"的人。
在 ChatGPT 爆火之前，我就已经在用 GitHub Copilot 了——那个时候它还只有简陋的 Tab 补全。后来国产的 CodeGeeX 出来，免费、中文理解好，我成了它的早期用户。再后来 GPT-4 出来，为了体验"最强模型"，我到处找中转站、镜像站，就为了能把代码丢进去跑一跑。
这个阶段很原始，但也很关键。因为它埋下了一颗种子：我要跟上 AI 的发展。
直到 Cursor 出现，这种"古法编程"才真正终结。
第一次觉醒：同样的模型，天差地别的体验#
Cursor 刚公测的时候我就冲了进去。说实话，第一次用的时候我有点慌：只会写代码的程序员，未来是不是要被淘汰了？
现在看来，这个担心不是没有道理——随着模型能力的持续进化，那些"只会写代码"的程序员确实面临着被替代的风险。
之后我也体验了很多类似的 AI IDE：Windsurf（Codeium 出品）、Trae（字节跳动的免费 IDE），还有 GitHub Copilot 的 Agent 模式和 Cursor 的 Composer。
2025 年 11 月，Google 发布了 Antigravity——一个 agent-first 的 IDE。
但真正让我"进化"的，是 Kiro。
这是我第一次接触到 SpecDriven（规格驱动开发） 的概念。同样的 Claude 3.7 Sonnet，在 GitHub Copilot 里我只能写写页面、改改样式；但在 Kiro 里，我只需要审审文档，剩下的交给 AI，然后自己点点测试、说说 bug、叫 AI 修就行。
同样的模型能力，在不同的工具里，体验竟然是天壤之别。
第二次觉醒：研究 Claude Code 架构#
真正的技术飞跃，来自我对 Claude Code 架构的拆解。
Claude Code 是 Anthropic 在 2025 年推出的官方命令行工具，它不是简单的"聊天补全"，而是一个真正意义上的 Agentic Coding（代理式编码） 系统——Single-Threaded Master Loop、上下文管理、工具原语集成……这些设计理念让我大开眼界。
我花了一个国庆假期，把它的架构翻了个底朝天。这之后，无论是 Gemini CLI（Google 的同类产品）、BrowserUse、Playwright 的浏览器自动化，还是 OpenCode 的高度定制化（100k+ GitHub stars 的开源项目），我都上手得极快。
因为理解原理，比追逐工具更重要。
第三次觉醒：当 AI 成了我的"虚拟员工"#
现在的我，连 Spec 都嫌慢。
文档我顶多简单审审，剩下的——需求分析、架构设计、编码实现、测试验收、部署上线——全都交给 AI 干。
MultiAgent 火了之后，软件工程的全流程我都用 AI 去接管了。我变成了一个"可恶的资本家"，手下是一群 24 小时不休息的"虚拟员工"。
一个有趣的类比在一些公司里，技术组长的工作其实和现在的我很像——他不用自己写代码，只需要分配任务、Review 产出、做决策。
Agent Swarm / Team 本质上就是把这套协作模式，迁移到了 AI 身上。
为什么写这本书？#
一个让我反思的 HackWeek#
大一的时候，我加了学校的互联网社团。那里有一些老登过于传统——这里的"传统"是贬义，意味着思维固化、抵触变化。
他们觉得用 AI 写东西"不合适"，觉得 AI 生成的文档"没灵魂"。
在社团唯一一次 HackWeek（黑客马拉松）里，评委老登批评我的产品文档"AI 味太浓"。他们的潜台词是：你不能太依赖 AI。
那次我几乎没用 AI Coding——因为我想锻炼自己的"纯手工"能力。我当时有个执念：我自己得先会，才能在保证质量的前提下用 AI 提效。
HackWeek 之后我反思了很久：我是不是应该与 AI"保持距离"？
但想来想去，我得出一个结论：
他们不是比我"更有经验"，他们只是比我"更难改变"。
能够适应变化，才是 AI 时代最核心的能力。
一次让我确信的合作#
后来，我和一位在字节的学长合作做一个 Live2D ChatBot 项目。
那个项目我用 Claude 3.7 Sonnet 几乎全程 Vibe 撑起来的——AI 生成的代码量可能占了 90%。
学长很惊讶于我的效率——对于一个新手来说，这确实有点不可思议。
他是一位客户端开发，虽然半年没写前端代码了，但经验摆在那。而我当时只是个大一下学期的新生。
那一刻我深深体会到：AI 加持下的效率，可以让一个新手达到让资深工程师吃惊的程度。
一个让我决定出书的声音#
VibeCoding 火了之后，我听到越来越多的抱怨：
"AI 怎么这么笨，我说东它往西！"
"Token 成本太高了，根本用不起！"
"请给我完整代码！我要你改这个你改那个干嘛！我*****"
我意识到：不是 AI 笨，是很多人用错了方式。
网上也有教程，但要么太浅（教你装个 Copilot 就完了），要么太散（今天看篇博客，明天看个视频），要么太虚（讲一堆概念，落地的时候发现用不上）。
缺的，是一个系统、全面、从入门到进阶的完整路径。
后来我跳槽了，新公司非常重视 VibeCoding。Mentor 跟我说："年后分享一下你的 VibeCoding 经验吧。"
就是这句话，让我下定决心：写一本书。
这本书是写给谁的？#
如果你符合以下任意一条，这本书就是为你准备的：
- 已经在用 AI 辅助编程，但总感觉"不对劲" —— 为什么别人说 AI 很强，我用起来就是个高级自动补全？
- 经常听到 AI "很笨/很贵/改错代码"的抱怨，想知道"正确打开方式" —— 这本书会告诉你，问题往往不在 AI，而在你的用法
- 想从 Copilot 补全，进阶到 Agent Swarm 全流程接管 —— 从单点效率到端到端交付的完整路径
- 不满足于网上零散的教程，想要系统学习 —— 五个 Part，从认知到实战到架构，层层递进
不太适合谁如果你是完全的编程小白（一行代码都没写过），这本书可能会让你有些吃力。建议先有一点编程基础，再来探索 AI 加持下的进阶玩法。
这本书讲了什么？#
全书分为五个 Part，循序渐进：
| Part | 主题 | 你会学到 |
|---|---|---|
| Part 1 | 破局：编程范式的第三次跨越 | 从 Copilot 补全到 Vibe Coding 的认知升级，各类工具（Cursor / Windsurf / Trae / Claude Code / Gemini CLI / Kiro / OpenCode / Antigravity）的生态位与选型 |
| Part 2 | 暗礁：真实场景的痛点与防线 | 黑盒调试、自我拟合陷阱、可追溯性灾难——以及如何建立企业级防御体系 |
| Part 3 | 实战上半：项目起盘与核心链路落地 | 从需求收敛、架构设计到后端底座与前端主干，先把项目主干搭起来 |
| Part 4 | 实战下半：自动化增强与联调交付 | CLI、MCP、Playwright、跨端宿主与联调发布闭环，给项目装上更完整的执行能力 |
| Part 5 | 终局：治理、Swarm 与生产系统升级 | 成本治理、多 Agent 编排、共享记忆、反脆弱设计与架构师升级 |
完整的大纲与阅读路径，可以直接看 《全书大纲》。
怎么读这本书？#
如果你完全没接触过 Vibe Coding#
建议从 Part 1 开始，按顺序阅读。它会帮你完成"思想冷启动"，理解为什么 AI 编程正在经历范式转移。
如果你已经在用 Cursor/Claude Code，但总觉得差点意思#
你可能觉得"我都在用了，第一章不用看了吧"——但说实话，用不等于会用。
Part 1 里有很多工具对比和选型建议，值得花时间扫一遍。看完之后，再去 Part 2 看看那些“坑”有没有踩过。
如果你已经是"资深 Vibe 玩家"#
Part 4 和 Part 5 可能更对胃口——MCP 协议、Playwright 自动化、Agent Swarm 编排，这些是当前最前沿的玩法。
一个特殊的声明#
这本书有一个"不寻常"的特点：它高度依赖 AI 协作编写。
我不擅长写书——但我擅长"驾驭 AI"。我能做的，是把我的想法、经验、观点清晰地表达出来，然后让 AI 帮我组织成书的形式。
这不是偷懒，而是一种方法论示范：
人做发散性工作（提出想法、判断对错、做出决策），AI 承担执行（组织语言、优化结构、润色表达）。
这本书是怎么写出来的？#
举个例子——这篇前言的诞生过程：
- 我提出需求："帮我写前言，我会渐进式引导你，对我提问。"
- AI 提问：问我"为什么写这本书""目标读者是谁"等核心问题。
- 我回答：用口语化的方式讲我的经历、动机、观察到的痛点。
- AI 起草：根据我的回答，组织成正式的前言结构。
- 我审核：指出哪里不对——"这段是你编的""这个工具我没用过""这里的第二人称有问题"。
- AI 修正：根据我的反馈调整内容。
- 我补充规范：把发现的问题（比如"不要编造作者经历""避免第二人称"）写进
AGENTS.md，让后续写作不再犯同样的错。
这个循环会一直持续——每次发现问题，就更新规范；每次有新的想法，就让 AI 帮我扩展。
AGENTS.md 就是这本书的"系统提示词"——它记录了我的写作风格、技术偏好、禁忌事项。AI 每次帮我写内容时，都会先读这份规范。
我不觉得我写的文字会比 AI 更好——承认工具的边界，才能更好地驾驭它。
正因为如此，你可能会在书中看到一些"个人痕迹"：比如我对 Tauri、Next.js 的偏好，或者某些还没来得及更新的过时工具链。这是"活文档"的常态——我和 AI 会持续校验、修正、演进。
关于术语：Vibe Coding vs Agentic Coding#
坦白说，Vibe Coding 这个词已经有点 Out 了。
2025 年 2 月，Andrej Karpathy 在 X 上发了一条推，正式提出了"Vibe Coding"这个概念——"我完全沉浸在氛围中，拥抱指数级增长，甚至忘记代码的存在"。但到了 2026 年，Agentic Coding（代理式编码） 成了更前沿的概念：AI 不只是帮你写代码，而是自主地规划、执行、纠错。
那为什么这本书的标题还是用"Vibe Coding"？
因为这个词更火、更大众、更容易理解。但实际上，这本书的内容已经很大程度上往 Agentic Coding 靠了——从 MCP 到 Agent Swarm，都是代理式思维的体现。
你可以把这本书理解为：用 Vibe Coding 的名字，讲 Agentic Coding 的内容。
最后#
AI 不会取代程序员。
但会用 AI 的程序员，会取代不会用 AI 的程序员。
希望这本书能帮助读者成为"会用的那一拨人"。
让我们开始吧。
梦辰 (TatsukiMeng) 2026 年 3 月