返回总目录：00 总览与导读（MOC）　|　上一章：01 导言 — 为什么2026年我们都在谈论 Vibe Coding　|　下一章：03 第二部分 — 2026 主流 AI 编程兵器谱

要用好 Vibe Coding，先得把脑子里的旧地图换掉。这一部分做三件事：回顾我们是如何一步步走到"自主代理"时代的，理解一种叫"上下文工程"的新基本功，以及直面一个所有人都绕不开的残酷规律——"70% 定律"。

1. 从"搜索复制"到"自主代理"：十年技术编年史

理解今天，最好的方式是看清这十年我们到底经历了什么。编程的"基本操作单位"在这十年里被改写了四次，每一次改写，人机协作的重心都向 AI 移动了一格。

timeline
    title 编程协作范式的十年迁移
    2015-2021 搜索复制时代 : 单位 = 代码片段 : 报错→复制→搜索→改名→祈祷
    2021-2022 副驾驶时代 : 单位 = Tab 补全 : Copilot 与早期 Codex
    2022-2024 对话调试时代 : 单位 = 一段对话 : ChatGPT 爆发，"最火的语言是英语"
    2025-2026 智能体时代 : 单位 = 一个任务 : Cursor / Windsurf / MCP / Claude Code 终端自主 Agent

2015–2021：搜索复制时代

这是大多数人最熟悉的"经典"开发方式。它的核心循环是一条几乎所有程序员都体会过的链路：程序报错 → 复制错误信息 → 丢进 Google 或 Stack Overflow → 找到一个看起来差不多的答案 → 改改变量名贴回去 → 祈祷它能跑。

在这个时代，知识是离散的、碎片化的，散落在无数论坛帖子里。开发者的核心能力之一，就是"会搜"——知道用什么关键词，能在一堆答案里分辨哪个靠谱。代码的基本单位是片段（snippet），工作方式是"拼接"。

2021–2022：副驾驶时代

2021 年前后，GitHub Copilot 与 OpenAI 早期的 Codex 模型登场，第一次把"AI 写代码"带到了主流开发者的编辑器里。它的形态是副驾驶（Copilot）：你在写，它在你身边轻声提示下一行可能是什么，你按一下 Tab 就接受。

基本单位从"片段"变成了"Tab 键补全"。这是一次微小但深刻的转变——AI 第一次进入了编写动作的内部，而不只是事后查询的对象。

安全隐患的雏形

也正是在这个时代，研究者第一次系统地发现：AI 倾向于推荐不安全的代码。它会自信地补全出带有注入漏洞、硬编码密钥、缺乏边界检查的片段，而开发者往往因为"它看起来很顺手"就直接接受。这个隐患不会随着模型变强而消失，反而会随着我们越来越信任 AI 而被放大——这是贯穿本书的一条安全暗线。

2022–2024：对话调试时代

2022 年底 ChatGPT 的爆发，把人机协作推向了"对话"。你不再是接受补全，而是用自然语言描述需求、贴上报错、来回追问，让 AI 给出整段解释和整块代码。

这个时代留下了一个标志性的数据：Stack Overflow 的访问流量出现断崖式下跌，一度同比下降约 14%。 当你可以直接问一个永远耐心、永远在线、还能针对你的具体代码回答的对话伙伴时，翻论坛找答案的动力就大大减弱了。一句流行的调侃精准地概括了这个阶段："现在最火的编程语言，是英语。"

2025–2026：智能体与终端爆发时代

最近这一两年，协作的基本单位再次跃迁——从"一段对话"变成了"一个任务"。你不再需要把任务拆成一问一答，而是直接把一个完整目标交给 AI，让它自己规划、自己执行、自己验证。

这一阶段的关键里程碑密集涌现：Cursor、Windsurf（搭载 Cascade 架构） 这样的 AI 原生 IDE 让 AI 能读懂整个项目；MCP（模型上下文协议，Model Context Protocol） 的问世，给了 AI 一个标准化的"插口"去连接外部工具与数据；最终在 2026 年，发展为 Claude Code 这样的终端自主 Agent——它直接住在你的命令行里，能读写本地文件、运行测试、根据结果自我修复，真正具备了"库级（repo-level）"的执行力。

至此，编程从"人写、AI 补"，演进到了"人指挥、AI 执行"。这就是 Vibe Coding 得以成立的技术地基。

2. 上下文工程（Context Engineering）与意图表达

如果说上一节讲的是"AI 能做什么"，这一节讲的是"你该怎么跟它说"。在智能体时代，决定产出质量的，已经不是你的打字速度，而是你给 AI 的上下文（context）有多准、多全。围绕这件事的功夫，被称为上下文工程。它是 Vibe Coding 时代真正的新基本功。

摆脱"盲目碰撞"：转向规范驱动

很多人用 AI 的方式是"盲目碰撞"——想到哪说到哪，AI 给个结果不对就再含糊地说"不对，再改改"，来回拉扯，越改越乱。这种方式做小玩具尚可，做稍微复杂的东西必然失控。

成熟的做法是规范驱动开发（Spec-Driven Development）：在让 AI 动手之前，先用清晰的自然语言把"要做什么、输入输出是什么、有哪些约束、什么算成功"讲明白。你不需要会写代码，但你需要会写一种"需求伪代码"——一种结构清晰、没有歧义、机器能听懂的需求描述。这本身就是一种可以刻意练习的能力，也是非技术读者最值得投资的技能。

把模糊想法翻译成"需求伪代码"

与其说"做一个待办事项 App"，不如说：

"做一个网页待办清单。用户能新增、勾选完成、删除条目。已完成的条目划掉并移到列表底部。数据存在浏览器本地，刷新不丢失。界面极简，只有一个输入框和一个列表。"

后者把 AI 的发挥空间收敛到了正确的轨道上——这就是意图表达的力量。

全库理解：为什么 AI IDE 优于普通对话框

为什么 Cursor、Windsurf 这类工具，比直接在网页对话框里贴代码强得多？核心原因只有一个：全库理解（Repo-level Understanding）。

一个真实的项目从来不是一个孤立的文件。它由几十上百个文件构成，彼此之间有引用、有依赖、有约定俗成的命名和结构。当你在网页对话框里只贴一个文件给 AI 时，它就像一个只看到剧本某一页的演员，根本不知道整部戏在讲什么。而 AI 原生 IDE 能让模型"看见"整个项目的文件结构和依赖关系，于是它给出的修改才能与项目的其余部分严丝合缝。

flowchart LR
    A[普通对话框] -->|只看到单个文件| B[盲人摸象<br/>改动易冲突]
    C[AI 原生 IDE] -->|索引整个代码库| D[全局视野<br/>改动相互咬合]
    style B fill:#ffe5e5,stroke:#d33
    style D fill:#e5ffe9,stroke:#3a3

规则文件：给 AI 注入"世界观"

最后一块拼图，是规则文件。像 .cursorrules、.claudecode 这样的配置文件，作用是给你的 AI 注入一套全局的"世界观"和代码规范——比如"这个项目统一用 TypeScript""所有接口必须写注释""不要使用某个已废弃的库""回复用中文"。

它的价值在于一次声明、处处生效：你不必在每次对话里重复你的偏好，AI 会自动带着这套规则去工作。这相当于你作为"导演"，提前写好了整个剧组都要遵守的创作守则。规则文件写得好不好，直接决定了 AI 是你得力的搭档，还是一个反复犯同样错误的麻烦制造者。

3. 硬核清醒：必须正视的"认知偏差"与"70% 定律"

前面两节讲的都是 Vibe Coding 的力量。这一节要泼一盆必要的冷水——因为不理解它的边界，你就会成为它的受害者。

生产力悖论：感觉变快，实际变慢

2025 年，一项名为 METR 的研究做了一件很少有人认真做的事：用严格的随机对照实验，去测量 AI 到底有没有让开发者变快。结果出人意料。

在处理他们熟悉的、复杂的真实项目时，那些被分配使用 AI 工具的资深开发者，实际完成速度反而慢了约 19%。 但更耐人寻味的是主观感受：这些开发者普遍"觉得"自己快了大约 20%。

flowchart TB
    subgraph 感觉["开发者的主观感受"]
        A["✨ 感觉快了 +20%"]
    end
    subgraph 现实["随机对照实验的客观测量"]
        B["🐢 实际慢了 -19%"]
    end
    A -.->|背离约 40 个百分点| B
    style A fill:#fff4cc,stroke:#cc9900
    style B fill:#ffe5e5,stroke:#cc0000

为什么会有这么大的背离？因为 AI 提供了极佳的正反馈：它几秒钟就吐出一大段看起来很专业的代码，让你产生"进展神速"的多巴胺快感。但真实的工作量，藏在之后——你要读懂它、验证它、发现它埋的坑、再把它纠正回来。这部分隐形成本，主观上感受不到，客观上却实实在在地拖慢了你。

这条研究的真正含义

METR 的结论不是"AI 没用"，而是"盲目地用 AI 会害了你"。它揭示了 Vibe Coding 时代最危险的陷阱：你越是依赖那种"感觉很快"的爽感，越可能在不知不觉中变慢、变差。 对抗它的唯一办法，是保持清醒——用客观标准（测试是否通过、需求是否真正满足）而不是主观爽感来衡量进展。

"70% 定律"：那道卡住所有人的墙

如果说整本书有一个最重要的概念，那就是"70% 定律"（The 70% Problem）。

它说的是：AI 能极其轻松地、在几秒到几分钟内，帮你搞定一个应用 70% 的部分——应用脚手架、样板代码（boilerplate）、基础界面、表面化的测试。这部分工作过去要花一个开发者几天，现在几乎免费。这是 Vibe Coding 最令人兴奋的地方。

但剩下的 30%，是另一回事。它包括：

  • 边缘情况（edge cases）：用户输入了你没想到的东西、网络突然断了、数据是空的……
  • 核心安全：支付回调的签名验证、数据库的权限隔离、防止越权和注入。
  • 系统架构完整性：当功能变多、用户变多时，系统是否还撑得住、改得动。
  • 真正的商用部署：从"在我电脑上能跑"到"在真实环境里稳定服务成千上万人"。
pie showData
    title 一个应用的工作量构成
    "AI 丝滑完成的 70%（脚手架 / 样板 / 表面测试）" : 70
    "人类必须攻坚的 30%（边缘 / 安全 / 架构 / 部署）" : 30

这剩下的 30%，依然死死地卡在人类的工程能力上。它不是"再问 AI 几次"就能解决的，而是需要真正的理解、判断和经验。

这就是为什么"光靠 Vibe 做不出好产品"。一个只会享受 70% 爽感的人，会做出大量"看起来能用、实际一碰就碎"的半成品；而真正能交付产品的人，是那些懂得接住 AI 的 70%、再亲手啃下 30% 的人。

整本书接下来的所有案例，都会用同一个固定结构来呈现这件事：【70% Vibe】告诉你 AI 能丝滑做掉什么，【30% Engineering】告诉你人类必须在哪里、用什么方式守住底线。 请带着这条主线，进入后面的实战。

本章要点回顾

  • 编程协作的基本单位十年四变：代码片段 → Tab 补全 → 一段对话 → 一个任务，每一次都让重心向 AI 移动一格。
  • "AI 倾向于推荐不安全代码"的隐患从副驾驶时代就已埋下，并随信任加深而放大。
  • 上下文工程是新基本功：规范驱动（写好"需求伪代码"）、全库理解（AI IDE 的核心优势）、规则文件（一次声明、处处生效）。
  • METR 研究揭示生产力悖论：盲目用 AI 实际慢约 19%，主观却感觉快约 20%——警惕"爽感"取代"客观标准"。
  • 70% 定律是全书主线：AI 丝滑完成 70%，人类必须攻坚决定成败的 30%（边缘 / 安全 / 架构 / 部署）。

👉 继续阅读：03 第二部分 — 2026 主流 AI 编程兵器谱