第1章: 引言 —— 软件工程范式的五十年之变

卷首语用五个人的故事画出了一幅图景：Karpathy 半年没写代码，Amodei 预言 90% 代码将由 AI 完成，Garry Tan 的产出翻了 810 倍，Boris Cherny 不再写代码只审查代码，antirez 放下了亲手雕琢每一行的执念。这些信号指向同一个结论——软件工程正在经历自 1968 年这门学科诞生以来最深刻的一次范式转换。

本章建立理解这场变革所需的概念坐标。它是怎么一步步走到今天的？新旧范式之间真正的断裂在哪里？全书贯穿的那根主线——"用结构化知识驾驭非结构化 AI 能力"——是怎么来的？

1.1 软件工程简史：一个假设的五十年

1968 年 NATO 软件工程会议上，"软件危机"被正式命名——项目失败、成本超支、交付延期——催生了"软件工程"这门学科。解决方案是用工程化流程约束创造力：阶段分解、评审关口、文档驱动。

此后半个多世纪，方法论不断演化。一个核心假设从未被挑战。

瀑布模型（Winston Royce, 1970）将开发划分为需求分析、设计、实现、测试、维护的严格线性阶段。Royce 本人的论文远比后来的教条版本微妙——他实际上提倡迭代（"do it twice"）——但瀑布作为一种管理模式被广泛采纳。它的核心前提是：需求可以在编码之前被完整地理解。

敏捷运动（Agile Manifesto, 2001）拆掉了瀑布的刚性阶段门。"个体和互动高于流程和工具，可工作的软件高于详尽的文档。"敏捷承认了需求会变，但保留了最底层的假设——写代码的人依然是写代码的人。所有的 Scrum 站会、Sprint 计划、用户故事，都建立在一个未经审视的前提之上：软件是由人类工程师一行一行写出来的。

DevOps 打破的是开发与运维之间的墙。CI/CD、基础设施即代码、容器化——这些运动将运维带入了工程视野。但它们同样没有触及那个核心信条。DevOps 优化的是"写完之后怎么办"，而不是"谁来写"。

最后这个假设——代码由人亲自编写——在 2023 年第一次动摇了。不是因为新的管理方法或流程改进，而是因为大语言模型。它能理解自然语言指令，自主探索代码库，执行完整的功能开发。它不是更聪明的自动补全。它在转移编程行为的主体。

1.2 AI Coding Agent 的四层演进

如果将 AI Agent 的能力演进放到时间轴上，可以看到四个清晰的阶段。每个阶段都在重新定义"编程"这个行为的含义——不只是效率的提升，而是人类和机器在编程活动中各自的角色发生了质变。

L1 补全：GitHub Copilot 在 2022 年 6 月正式发布，程序员第一次体验到了"AI 帮你写下一行"。但它本质上是智能化的自动补全——AI 预测，人类决策。

L2 对话：ChatGPT 改变了交互范式。程序员学会了"提问"——替代了查文档、搜 Stack Overflow。但代码仍然是程序员亲手写的。AI 是搜索引擎的替代品，不是代码的作者。

L3 任务：Claude Code 于 2025 年 2 月发布，同时 Cursor、Codex CLI、OpenCode 等工具将体验升级为"AI 帮你实现一个功能"。Agent 开始具备自主理解代码库、定位修改位置、执行多文件变更的能力。人类从"写代码的人"向"分配任务的人"滑动。

L4 自主流程：进入 2026 年，Agent 不再只是执行任务，而是开始管理流程——从理解需求到设计方案、实现代码、编写测试、创建 PR，一次会话走完整条链路。这正是卷首语中 Boris Cherny 描述的工作状态：他不再写代码，只审查代码。

从 L1 到 L4，变的不是 AI 能力的量，而是编程行为中主体的位置。L1 中人类是唯一主体。L4 中 AI 变成主动参与者，人类变成监督者和质量守门人。

1.3 Vibe Coding：解放还是陷阱？

AI 让编程门槛降到了历史最低点。任何人——不管会不会写代码——都可以用一句话让 AI 生成一个能跑的应用。Andrej Karpathy 给这种现象取了一个生动的名字：Vibe Coding（氛围编程）。

这是解放，毫无疑问。但它也是一个精心包装的陷阱。

Vibe Coding 的典型模式：对 AI 说"给我做一个 todo app"→ AI 十几秒生成一整套代码 → "加一个暗黑模式"→ "加一个拖拽排序"。你甚至不需要知道 useState 是什么。你只要"vibe"就可以了。

陷阱在于：它拉高下限的同时，模糊了上限的存在。 当你不需要理解自己的代码如何工作，当你的应用在"看起来能运行"和"真正能在生产环境运行"之间存在巨大的鸿沟——Vibe Coding 的产物往往是一团不可测试、不可重构、不可理解的代码浆糊。

这就是 Karpathy 为什么特意区分了两个概念：Vibe Coding 与 Agentic Engineering（智能体工程）。前者的关键词是"放手"——把需求丢给 AI，接受它吐出的一切。后者的关键词是"掌控"——把 AI 视为极其强大但带有随机性和盲区的工具，通过结构化方法引导、约束、验证它的产出。

作为卷首语中详细展开过的论证，这里不再重复，但需要强调它的推论：AI 不会救你，它会放大你。 你给它清晰的架构，它还你整洁的代码；你给它模糊的意图，它还你一团浆糊。一个人用 AI 后的产出上限，是由他在没有 AI 时的工程素养决定的。Redis 创造者 antirez 用一周时间完成 DS4 项目——但他审查了 AI 生成的每一行代码。

这就是为什么，在 AI 让编码门槛降到历史最低点的时刻，工程化的价值反而达到了历史最高点。

1.4 核心主张：从 Prompt-Driven 到 Skill-Driven

这就引出了全书最核心的概念转折。

过去两年间，一个洞见在不同的人和实践中反复出现、逐步收敛。它不是某个人独自发明的，而是社区在实践中达成的共识：Prompt 是临时的，Skill 是持久的。

当你对 AI 说"帮我做代码审查"，你能得到什么？一个审查结果。它的质量取决于你当时的表达、AI 当时的理解、对话上下文的完整度。改天再做一次，结果可能完全不同。Prompt 消失在对话历史里——不可复用、不可迭代、不可积累。

而一个 Skill——比如 /review-it——是一个结构化指令文件，定义了什么算好的审查、审查哪些维度、遇到每种问题怎么处理。它可以在不同项目、不同时间、对不同的代码重复使用。每次使用都是一次验证机会，如果出现偏差，你可以改进 Skill 本身，让下一次更好。Skill 留在你的工具链里——可复用、可迭代、可积累。

"对话一次"和"建立一个系统"之间的区别，就是一位 AI 时代的合格工程师和一位"vibe coder"之间的区别。

也正是在这个意义上，四个层次构成了一个递进：Prompt Engineering 让 AI 理解意图（一次性对话）→ Skill Engineering 让能力可复用（持久化方法论）→ Agent Orchestration 让多个 Agent 协同（编排调度）→ Harness Engineering 让整个系统安全可控（运行环境与权限）。每一层建立在前一层基础上。Skill Engineering 处于"从临时到持久"的转折点上——它不是让 AI 变得更聪明，而是让使用 AI 的人变得更体系化。

这引出了全书的核心理念：

在 AI 时代，软件工程的核心竞争力不再是"你能写多快的代码"，而是"你能不能构建一套让 AI 高质量产出的方法和系统。"

这套系统应具备五个特征：可复用、可验证、可迭代、可组合、不依赖特定模型。

围绕这些原则，一个全新的方法论生态已经生长出来。以下方法论将在本书第一部分逐一展开：

这些方法论看似各不相同，但它们共享同一个底层逻辑——也是贯穿全书的那根线：用结构化知识驾驭非结构化 AI 能力。

1.5 本章小结

我们正站在软件工程史上一个罕见的转折点上。上一次这种量级的改变，要追溯到 1968 年——当这门学科本身被命名时。

这次转折有三个核心特征：

第一，编程行为的主体正在转移。五十年来的第一次，不是人类在敲键盘。人类从"作者"变成了"指挥者"，再变成"审查者"。

第二，速度和质量之间出现了新的张力。AI 让写代码极快，但验证代码的速度远远跟不上。Vibe Coding 是解放，也是陷阱。工程化不是减速带，而是让你高速行驶时不翻车的底盘。

第三，方法论的价值超过了工具本身。工具每天都在变。但"用结构化知识驾驭非结构化 AI 能力"的原则不会变。Skills 系统、Spec-Driven Development、闭环工作流——这些不是某个具体工具的说明书，而是在任何 AI 工具上都能成立的工程原则。

从下一章开始，我们将逐一展开这些方法论。但在进入细节之前，请记住本章最核心的那个判断：

AI 不会救你，它会放大你。在 AI 时代，你的工程素养不是变得不重要了，而是第一次变得如此重要。