01 引言：软件工程范式的五十年之变

<blockquote><p>&quot;Same person. Different era. The difference is the tooling.&quot;<br>人未变，时代已改。拉开差距的，全在工具。</p><p>——Garry Tan, Y Combinator 总裁 &amp; CEO, 2026 年</p></blockquote><p>卷首语用五个人的故事画出了一幅图景：Karpathy 半年没写代码，Amodei 预言 90% 代码将由 AI 完成，Garry Tan 的产出翻了 810 倍，Boris Cherny 不再写代码只审查代码，antirez 放下了亲手雕琢每一行的执念。这些信号指向同一个结论——软件工程正在经历自 1968 年这门学科诞生以来最深刻的一次范式转换。</p><p>本章建立理解这场变革所需的概念坐标。它是怎么一步步走到今天的？新旧范式之间真正的断裂在哪里？全书贯穿的那根主线——&quot;用结构化知识驾驭非结构化 AI 能力&quot;——是怎么来的？</p><span id="more"></span><h2 id="1-1-软件工程简史-一个假设的五十年"><a href="#1-1-软件工程简史-一个假设的五十年" class="headerlink" title="1.1 软件工程简史: 一个假设的五十年"></a>1.1 软件工程简史: 一个假设的五十年</h2><p>1968 年 NATO 软件工程会议上，&quot;软件危机&quot;被正式命名——项目失败、成本超支、交付延期——催生了&quot;软件工程&quot;这门学科。解决方案是用工程化流程约束创造力：阶段分解、评审关口、文档驱动。</p><p>此后半个多世纪，方法论不断演化。一个核心假设从未被挑战。</p><p><strong>瀑布模型</strong>（Winston Royce, 1970）将开发划分为需求分析、设计、实现、测试、维护的严格线性阶段。Royce 本人的论文远比后来的教条版本微妙——他实际上提倡迭代（&quot;do it twice&quot;）——但瀑布作为一种管理模式被广泛采纳。它的核心前提是：需求可以在编码之前被完整地理解。</p><p><strong>敏捷运动</strong>（Agile Manifesto, 2001）拆掉了瀑布的刚性阶段门。&quot;个体和互动高于流程和工具，可工作的软件高于详尽的文档。&quot;敏捷承认了需求会变，但保留了最底层的假设——<strong>写代码的人依然是写代码的人</strong>。所有的 Scrum 站会、Sprint 计划、用户故事，都建立在一个未经审视的前提之上：软件是由人类工程师一行一行写出来的。</p><p><strong>DevOps</strong> 打破的是开发与运维之间的墙。CI&#x2F;CD、基础设施即代码、容器化——这些运动将运维带入了工程视野。但它们同样没有触及那个核心信条。DevOps 优化的是&quot;写完之后怎么办&quot;，而不是&quot;谁来写&quot;。</p><p>最后这个假设——<strong>代码由人亲自编写</strong>——在 2023 年第一次动摇了。不是因为新的管理方法或流程改进，而是因为大语言模型。它能理解自然语言指令，自主探索代码库，执行完整的功能开发。它不是更聪明的自动补全。它在转移编程行为的主体。</p><img src="/2026/06/22/software-engineering-fifty-years-paradigm-shift/image-20260523093209852.png" class=""><h2 id="1-2-AI-Coding-Agent-的四层演进"><a href="#1-2-AI-Coding-Agent-的四层演进" class="headerlink" title="1.2 AI Coding Agent 的四层演进"></a>1.2 AI Coding Agent 的四层演进</h2><p>如果将 AI Agent 的能力演进放到时间轴上，可以看到四个清晰的阶段。每个阶段都在重新定义&quot;编程&quot;这个行为的含义——不只是效率的提升，而是<strong>人类和机器在编程活动中各自的角色</strong>发生了质变。</p><table><thead><tr><th>层次</th><th>时间</th><th>交互范式</th><th>人类角色</th><th>AI 角色</th><th>代表作</th></tr></thead><tbody><tr><td>L1: 补全</td><td>2022-</td><td>人写代码，AI 预测下一行</td><td>作者</td><td>自动补全</td><td>GitHub Copilot</td></tr><tr><td>L2: 对话</td><td>2023-</td><td>人问问题，AI 回答</td><td>学习者</td><td>知识库</td><td>ChatGPT, Claude</td></tr><tr><td>L3: 任务</td><td>2025-</td><td>人下指令，AI 完成功能</td><td>指挥者</td><td>实现者</td><td>Claude Code, Cursor</td></tr><tr><td>L4: 自主流程</td><td>2026-</td><td>人定义目标，AI 管理全流程</td><td>审查者</td><td>工程经理</td><td>autoresearch, Ralph Loop</td></tr><tr><td><strong>L1 补全</strong>：GitHub Copilot 在 2022 年 6 月正式发布，程序员第一次体验到了&quot;AI 帮你写下一行&quot;。但它本质上是智能化的自动补全——AI 预测，人类决策。</td><td></td><td></td><td></td><td></td><td></td></tr></tbody></table><p><strong>L2 对话</strong>：ChatGPT 改变了交互范式。程序员学会了&quot;提问&quot;——替代了查文档、搜 Stack Overflow。但代码仍然是程序员亲手写的。AI 是搜索引擎的替代品，不是代码的作者。</p><p><strong>L3 任务</strong>：Claude Code 于 2025 年 2 月发布，同时 Cursor、Codex CLI、OpenCode 等工具将体验升级为&quot;AI 帮你实现一个功能&quot;。Agent 开始具备自主理解代码库、定位修改位置、执行多文件变更的能力。人类从&quot;写代码的人&quot;向&quot;分配任务的人&quot;滑动。</p><p><strong>L4 自主流程</strong>：进入 2026 年，Agent 不再只是执行任务，而是开始<strong>管理流程</strong>——从理解需求到设计方案、实现代码、编写测试、创建 PR，一次会话走完整条链路。这正是卷首语中 Boris Cherny 描述的工作状态：他不再写代码，只审查代码。</p><p>从 L1 到 L4，变的不是 AI 能力的量，而是<strong>编程行为中主体的位置</strong>。L1 中人类是唯一主体。L4 中 AI 变成主动参与者，人类变成监督者和质量守门人。</p><img src="/2026/06/22/software-engineering-fifty-years-paradigm-shift/image-20260523093742002.png" class=""><h2 id="1-3-Vibe-Coding-解放还是陷阱？"><a href="#1-3-Vibe-Coding-解放还是陷阱？" class="headerlink" title="1.3 Vibe Coding: 解放还是陷阱？"></a>1.3 Vibe Coding: 解放还是陷阱？</h2><p>AI 让编程门槛降到了历史最低点。任何人——不管会不会写代码——都可以用一句话让 AI 生成一个能跑的应用。Andrej Karpathy 给这种现象取了一个生动的名字：<strong>Vibe Coding（氛围编程）</strong>。</p><p>这是解放，毫无疑问。但它也是一个精心包装的陷阱。</p><p>Vibe Coding 的典型模式：对 AI 说&quot;给我做一个 todo app&quot;→ AI 十几秒生成一整套代码 → &quot;加一个暗黑模式&quot;→ &quot;加一个拖拽排序&quot;。你甚至不需要知道 useState 是什么。你只要&quot;vibe&quot;就可以了。</p><p>陷阱在于：<strong>它拉高下限的同时，模糊了上限的存在。</strong> 当你不需要理解自己的代码如何工作，当你的应用在&quot;看起来能运行&quot;和&quot;真正能在生产环境运行&quot;之间存在巨大的鸿沟——Vibe Coding 的产物往往是一团不可测试、不可重构、不可理解的代码浆糊。</p><p>这就是 Karpathy 为什么特意区分了两个概念：<strong>Vibe Coding 与 Agentic Engineering（智能体工程）</strong>。前者的关键词是&quot;放手&quot;——把需求丢给 AI，接受它吐出的一切。后者的关键词是&quot;掌控&quot;——把 AI 视为极其强大但带有随机性和盲区的工具，通过结构化方法引导、约束、验证它的产出。</p><p>作为卷首语中详细展开过的论证，这里不再重复，但需要强调它的推论：<strong>AI 不会救你，它会放大你。</strong> 你给它清晰的架构，它还你整洁的代码；你给它模糊的意图，它还你一团浆糊。一个人用 AI 后的产出上限，是由他在没有 AI 时的工程素养决定的。Redis 创造者 antirez 用一周时间完成 DS4 项目——但他审查了 AI 生成的每一行代码。</p><p>这就是为什么，在 AI 让编码门槛降到历史最低点的时刻，工程化的价值反而达到了历史最高点。</p><h2 id="1-4-核心主张-从-Prompt-Driven-到-Skill-Driven"><a href="#1-4-核心主张-从-Prompt-Driven-到-Skill-Driven" class="headerlink" title="1.4 核心主张: 从 Prompt-Driven 到 Skill-Driven"></a>1.4 核心主张: 从 Prompt-Driven 到 Skill-Driven</h2><p>这就引出了全书最核心的概念转折。</p><p>过去两年间，一个洞见在不同的人和实践中反复出现、逐步收敛。它不是某个人独自发明的，而是社区在实践中达成的共识：<strong>Prompt 是临时的，Skill 是持久的。</strong></p><p>当你对 AI 说&quot;帮我做代码审查&quot;，你能得到什么？一个审查结果。它的质量取决于你当时的表达、AI 当时的理解、对话上下文的完整度。改天再做一次，结果可能完全不同。Prompt 消失在对话历史里——不可复用、不可迭代、不可积累。</p><p>而一个 Skill——比如 &#x2F;review-it——是一个结构化指令文件，定义了什么算好的审查、审查哪些维度、遇到每种问题怎么处理。它可以在不同项目、不同时间、对不同的代码重复使用。每次使用都是一次验证机会，如果出现偏差，你可以改进 Skill 本身，让下一次更好。Skill 留在你的工具链里——可复用、可迭代、可积累。</p><p>&quot;对话一次&quot;和&quot;建立一个系统&quot;之间的区别，就是一位 AI 时代的合格工程师和一位&quot;vibe coder&quot;之间的区别。</p><p>也正是在这个意义上，四个层次构成了一个递进：<strong>Prompt Engineering</strong> 让 AI 理解意图（一次性对话）→ <strong>Skill Engineering</strong> 让能力可复用（持久化方法论）→ <strong>Agent Orchestration</strong> 让多个 Agent 协同（编排调度）→ <strong>Harness Engineering</strong> 让整个系统安全可控（运行环境与权限）。每一层建立在前一层基础上。Skill Engineering 处于&quot;从临时到持久&quot;的转折点上——它不是让 AI 变得更聪明，而是让使用 AI 的人变得更体系化。</p><p>这引出了全书的核心理念：</p><p><strong>在 AI 时代，软件工程的核心竞争力不再是&quot;你能写多快的代码&quot;，而是&quot;你能不能构建一套让 AI 高质量产出的方法和系统。&quot;</strong></p><p>这套系统应具备五个特征：<strong>可复用、可验证、可迭代、可组合、不依赖特定模型。</strong></p><p>围绕这些原则，一个全新的方法论生态已经生长出来。以下方法论将在本书第一部分逐一展开：</p><table><thead><tr><th>方法论</th><th>核心思想</th><th>关键贡献者</th><th>详章</th></tr></thead><tbody><tr><td>Matt Skills 系统</td><td>将工程经验沉淀为可复用的能力单元</td><td>Matt Pocock</td><td>第2章</td></tr><tr><td>Spec-Driven Development</td><td>规格文档作为人类与 AI 之间的&quot;合约&quot;</td><td>OpenSpec &#x2F; GitHub Spec-Kit</td><td>第3章</td></tr><tr><td>Ralph Loop</td><td>AI 在循环中自我改进，直到满足验收标准</td><td>Frank Bria</td><td>第4章</td></tr><tr><td>gstack</td><td>23 个专家角色构建虚拟工程团队</td><td>Garry Tan</td><td>第5章</td></tr><tr><td>superpowers</td><td>159K+ Stars 的 AI 编程 Skills 方法论库</td><td>obra &#x2F; jnMetaCode</td><td>第6章</td></tr><tr><td>autoresearch</td><td>多 Agent 轮转交叉审核，端到端全自动闭环</td><td>smallnest</td><td>第7章</td></tr><tr><td>Goal Workflow</td><td>目标驱动的四步研发闭环</td><td>smallnest</td><td>第8章</td></tr><tr><td>这些方法论看似各不相同，但它们共享同一个底层逻辑——也是贯穿全书的那根线：<strong>用结构化知识驾驭非结构化 AI 能力。</strong></td><td></td><td></td><td></td></tr></tbody></table><h2 id="1-5-本章小结"><a href="#1-5-本章小结" class="headerlink" title="1.5 本章小结"></a>1.5 本章小结</h2><p>我们正站在软件工程史上一个罕见的转折点上。上一次这种量级的改变，要追溯到 1968 年——当这门学科本身被命名时。</p><p>这次转折有三个核心特征：</p><p>第一，<strong>编程行为的主体正在转移</strong>。五十年来的第一次，不是人类在敲键盘。人类从&quot;作者&quot;变成了&quot;指挥者&quot;，再变成&quot;审查者&quot;。</p><p>第二，<strong>速度和质量之间出现了新的张力</strong>。AI 让写代码极快，但验证代码的速度远远跟不上。Vibe Coding 是解放，也是陷阱。工程化不是减速带，而是让你高速行驶时不翻车的底盘。</p><p>第三，<strong>方法论的价值超过了工具本身</strong>。工具每天都在变。但&quot;用结构化知识驾驭非结构化 AI 能力&quot;的原则不会变。Skills 系统、Spec-Driven Development、闭环工作流——这些不是某个具体工具的说明书，而是在任何 AI 工具上都能成立的工程原则。</p><p>从下一章开始，我们将逐一展开这些方法论。但在进入细节之前，请记住本章最核心的那个判断：</p><p><strong>AI 不会救你，它会放大你。在 AI 时代，你的工程素养不是变得不重要了，而是第一次变得如此重要。</strong></p>