05-vibe-coding-向agentic-engineering演进

文章目录

• [为什么需要演进：Karpathy自己都说"Vibe Coding已死"](#为什么需要演进：Karpathy自己都说"Vibe Coding已死")
• [第一步跃迁：从Vibe Coding到Agentic Engineering](#第一步跃迁：从Vibe Coding到Agentic Engineering)
• 第二步跃迁：从Agentic到SDD规范驱动开发
• 第三步跃迁：从单Agent到多智能体协作
• [贯穿三次跃迁的主线：Harness Engineering](#贯穿三次跃迁的主线：Harness Engineering)
• 演进路线图与能力成熟度模型
• [收尾：Vibe Coding的真正遗产](#收尾：Vibe Coding的真正遗产)

为什么需要演进：Karpathy自己都说"Vibe Coding已死"

Vibe Coding在2025年初引爆了整个开发者社区，Andrej Karpathy那条"I just vibe code"的推文让无数人涌入这条新路径。半年之后，社区的热度开始降温，真实项目中的问题集中爆发。代码质量不可控、前后逻辑矛盾、缺乏全局架构视角、团队协作困难------这四大崩塌点在上一篇（第4篇）中已做过系统拆解，它们并非个别现象，而是Vibe Coding固有局限性的必然结果。

逐个审视这四大崩塌点，能看清问题的深层结构。代码质量不可控的根源在于，Vibe Coding依赖对话上下文生成代码，模型每次生成的风格、结构、命名规范都可能不同，缺乏一致性保障机制。前后逻辑矛盾的根源在于，对话式开发没有全局设计文档，功能A和功能B可能由不同对话分别生成，接口定义、数据格式、错误处理方式互相冲突。缺乏全局视角的根源在于，Vibe Coding以"功能点"为单位推进，每次对话聚焦一个具体需求，缺少架构层面的整体规划，代码库逐渐膨胀为"功能堆砌"而非"系统设计"。难以协作的根源在于，Vibe Coding高度依赖个人与模型的对话历史，团队成员无法复现你的对话上下文，也就无法理解和延续你的代码思路。

Karpathy本人在2025年中后期的公开表态中承认了这一点。他不再频繁提及Vibe Coding，转而讨论"Harness Engineering"（脚手架工程化）的概念------不再强调"凭感觉写代码"，而是强调"围绕模型搭建工程化环境"。这并非是对Vibe Coding的全盘否定，而是范式演化的自然路径。Vibe Coding解决的核心问题是"从0到1"------让一个想法快速变成可运行的代码，验证可行性。当项目进入"从1到100"的阶段，需要维护性、可测试性、团队协作时，纯凭感觉的工作方式就力不从心了。Karpathy的态度转变传递了一个清晰信号：工具在进化，使用工具的方式也必须进化。

理解这场演进，需要建立一个三次范式跃迁的总框架。第一次跃迁是从Vibe Coding到Agentic Engineering（智能体工程化），核心变化是从"人写每一行代码"到"Agent自主规划并执行"。人类不再逐行敲代码，而是定义目标、审核计划、验收结果。第二次跃迁是从Agentic Engineering到SDD（Spec-Driven Development，规范驱动开发），核心变化是从"Agent凭理解做事"到"规范先行，代码履约"。Agent不再依赖对需求的自由理解，而是严格按照规范文档执行。第三次跃迁是从单Agent到多智能体协作，核心变化是从"一个Agent包打天下"到"Agent团队分工协同"。多个专业化Agent各自负责擅长领域，通过协调机制完成复杂项目。贯穿三次跃迁的主线是Harness Engineering------围绕模型搭建的工程化脚手架，决定了模型能力在真实项目中能发挥到什么程度。

人类角色在这三次跃迁中经历了根本性转变。Vibe Coding时代，人是"打字员"------在编辑器里逐字敲击，AI做辅助补全，人的精力消耗在语法细节和实现逻辑上。Agentic Engineering时代，人是"需求定义者"------描述要什么、审核Agent的计划、验收最终结果，人的精力转移到需求清晰度和验收标准上。SDD和多智能体时代，人是"Agent驾驭者"------定义规范、设计工作流、协调多个Agent的产出，人的精力投入到系统架构和工程治理上。每一次跃迁，人离代码更远一步，离产品和架构更近一步。这个趋势不是让人变得不重要，而是让人的价值从"执行"转移到"决策"。

三次跃迁不是简单的工具升级。从Cursor到Claude Code，从Spec Kit到Kiro，工具确实在迭代，但真正变化的是人机协作关系的根本重构。Vibe Coding中人机关系是"人主导、机辅助"------人写代码，机器补全。Agentic Engineering中变成"机执行、人审核"------机器写代码，人审核关键节点。SDD中演化为"规范约束、双方协作"------人定义规范，机器按规范执行，双方在规范框架内协作。多智能体协作中则升维为"人监理、Agent团队自治"------人设计工作流和监督产出，Agent团队自主分工和执行。理解这条主线，才能在工具快速迭代的浪潮中找到稳定的方向，而不是被每一个新工具牵着走。

第一步跃迁：从Vibe Coding到Agentic Engineering

Vibe Coding的本质是"人机对话式编程"------你描述需求，模型生成代码，你感觉不对就再描述一次。这个循环的效率在简单项目中极高，但在复杂项目中会陷入"改了东墙塌西墙"的泥潭。问题的症结在于，对话式开发把人变成了整个循环的串行瓶颈：每一次代码修改都需要人发起对话、人审核结果、人决定下一步。Agentic Engineering的突破口在于引入了Agent（智能体）这一全新角色，让机器能自主完成内部循环。

什么是Agent？Agent是一个能自主规划、执行、验证的AI系统。它不是简单的"你问我答"的Chatbot（聊天机器人），而是一个具备目标导向能力的执行体。Chatbot在收到问题时生成一段文本或代码就结束交互，Agent在收到目标后会自主拆解任务、选择工具、执行操作、观察结果、判断成败，并在必要时修正策略。两者的核心差异可以用一张对比表说清楚。

维度	Chatbot	Agent
行为模式	被动响应，问一句答一句	主动推进，拿到目标后自主执行
能力边界	只能生成文本/代码片段	能调用工具、读写文件、执行命令
主动性	等待用户指令	自主拆解任务、选择工具、判断结果
记忆能力	依赖上下文窗口，会话结束即丢失	可持久化记忆、跨会话保留状态
比喻	一个百科全书式的顾问	一个能干活的全栈工程师

Agent的工作循环可以概括为四个阶段：感知（Perceive）→推理（Reason）→行动（Act）→反馈（Feedback）。感知阶段，Agent接收用户的目标描述和当前环境信息------项目文件结构、已有代码、配置文件、错误日志。推理阶段，Agent分析目标、拆解任务、选择策略------决定先做什么后做什么、用哪些工具、预期什么结果。行动阶段，Agent调用工具执行具体操作------创建文件、修改代码、运行测试、查询数据库。反馈阶段，Agent观察执行结果，判断是否达成目标，决定是继续下一步还是回退修正。这个循环不是执行一次就结束，而是持续运转直到目标完成。

将这个循环具体化，就形成了Plan-Act-Observe-Reflect（计划-行动-观察-反思）工作模型。以开发一个登录功能为例，完整的循环过程如下：

1. Plan：要完成登录功能，需要做这些事------
   创建用户表、实现注册接口、实现登录接口、
   添加JWT令牌生成、编写单元测试

2. Act：先创建数据库用户表，包含id、username、
   password_hash、created_at字段

3. Observe：创建成功。但检查后发现少了一个
   email字段，注册时需要验证邮箱唯一性

4. Reflect：需要修改表结构，加上email字段，
   并添加唯一索引防止重复注册

5. 回到Plan：表结构修正完毕，继续下一步------
   实现注册接口，接收username、email、password

这个循环的关键在于Reflect（反思）环节。没有反思的Agent只是"执行机器"，遇到偏差不会自我修正，必须依赖人工发现问题和重新指示。有反思能力的Agent能够在执行过程中发现"创建成功但字段不全"这类隐性问题，主动调整计划，无需人工介入即可继续推进。这是Agentic Engineering区别于Vibe Coding的核心------不是生成完代码就结束，而是持续验证、持续修正，形成一个自闭合的执行回路。

任务分解是Agent规划阶段的核心能力，遵循MECE原则（Mutually Exclusive, Collectively Exhaustive，相互独立、完全穷尽）。"相互独立"要求子任务之间不重叠，避免重复劳动和职责混乱。"完全穷尽"要求子任务合在一起覆盖全部需求，避免功能遗漏。以一个博客系统为例，正确的拆解应该是五个互不重叠且覆盖完整的子任务：文章管理（增删改查、富文本编辑）、用户认证（注册登录、权限控制）、评论系统（评论发表、嵌套回复、审核机制）、标签分类（标签管理、文章关联、按标签筛选）、数据备份（定时备份、恢复机制）。每个子任务可以独立开发和测试，合在一起构成完整的博客系统。错误的拆解------比如把"文章管理"和"标签分类"合并为"内容管理"------会导致边界模糊、职责混乱，两个功能耦合在一起难以独立修改。

Agentic Engineering的标志性工作习惯是"先让AI制定计划，你确认后再执行"。在Claude Code中，这对应Plan Mode（计划模式）；在Cursor中，对应Composer的Plan功能。这个习惯看似简单，却能大幅减少返工。原因在于：计划阶段成本极低（只是文本生成），修改计划的成本远低于修改代码。在计划阶段发现一个架构问题，改几行文字即可；在代码阶段发现同样的问题，可能需要重构数百行代码。更深层的原因是，计划是显性化的------计划文档可以被审核、被讨论、被版本管理，而对话式开发中的"计划"隐藏在对话流中，无法追溯和审查。

从"vibing"到"engineering"的思维转变，核心是从依赖模型直觉转向主动构建工程化环境。Vibe Coding时，开发者把模型当作一个聪明的黑盒，输入描述、输出代码，好坏全凭模型当时的"手感"。Agentic Engineering时，开发者开始关心一系列工程问题：Agent能访问哪些文件、不能访问哪些？能调用哪些工具、不能调用哪些？有没有测试反馈机制让Agent知道代码是否正确？错误如何被捕获和修正？Agent的执行过程是否有日志可追溯？这种思维转变的本质，是从"使用工具"升级为"设计工具的使用方式"------不再只是提问者，而是工作流的设计者。

一个实际的对比例子能说明差异。用Vibe Coding方式开发一个API接口，典型流程是：描述需求→生成代码→手动测试→发现问题→再描述→再生成，循环往复。每轮循环中，人都是必须参与的节点------跑测试是人、发现问题是人、重新描述是人。用Agentic Engineering方式，流程变成：让Agent先制定计划→审核计划合理性→Agent自主执行（写代码、跑测试、修Bug、再跑测试，直到通过）→人工审核最终结果。前者的瓶颈在于人成为整个循环的串行节点，Agent的能力被人的响应速度限制。后者的优势在于Agent自主完成内部循环，人只在计划审核和最终验收两个关键节点介入，中间环节完全并行化。

从团队层面看，Agentic Engineering还带来了一个隐性收益：知识沉淀。Vibe Coding时代，团队的AI使用经验散落在每个人的对话历史中，无法共享和传承。Agentic Engineering时代，Plan Mode产出的计划文档本身就是知识资产------新成员可以通过阅读历史计划文档理解项目的设计决策和实现思路。一个成熟的Agentic Engineering团队，其计划文档库就是最好的项目文档，比事后补写的文档更准确、更及时，因为它是在开发过程中自然产生的，而非为了文档而文档。

第二步跃迁：从Agentic到SDD规范驱动开发

Agentic Engineering解决了"Agent能自主执行"的问题，但带来了一个新问题：Agent的执行结果不稳定。同一个需求，今天Agent生成的代码结构合理，明天可能就风格迥异。团队协作时，开发者A让Agent生成的代码和开发者B让Agent生成的代码风格不统一，接口定义冲突，命名约定不一致。这个问题的根源在于------缺少规范约束。Agent有能力执行，但缺乏统一标准来约束执行的方向和方式。

SDD（Spec-Driven Development，规范驱动开发）的核心思想用一句话概括："先写规范，再写代码；规范是合同，代码是履约。"在SDD中，规范文档不是事后补写的文档，而是开发的前置条件。没有规范，不写代码。规范定义了"做什么""怎么做""做到什么程度"三个层面的问题，Agent的职责是严格按照规范执行，而非自由发挥。这种"合同-履约"关系的建立，让Agent的输出从"每次不同"变为"符合约定"。

SDD的三份核心文档构成一个完整的规范体系，每份文档回答一个明确问题。

第一份是PRD（Product Requirements Document，产品需求文档），回答"做什么"。PRD采用用户故事格式描述功能需求，每个功能附带验收标准。用户故事的经典格式是"作为一个角色，我想要功能，以便价值"------这种格式强制开发者思考需求的受众和价值，避免"为了做功能而做功能"。验收标准采用Given/When/Then格式，确保需求可验证。以博客系统的标签筛选功能为例，完整的验收标准如下：

功能：按标签筛选文章

Given：系统中有20篇文章，其中5篇标记了"Python"标签
When：用户点击"Python"标签
Then：页面只显示这5篇标记了"Python"的文章
And：页面顶部显示当前筛选条件"标签：Python"
And：文章按发布时间倒序排列

Given/When/Then格式的价值在于可测试性。每一条验收标准都可以直接转化为自动化测试用例：Given对应测试前置条件（准备20篇文章数据，5篇标记Python），When对应测试操作（模拟点击Python标签），Then对应断言（验证返回结果只有5篇、按时间倒序）。当Agent生成的代码能通过所有验收标准对应的测试，就说明代码"履约"了。这种从需求到测试的直线路径，是SDD相比传统开发的核心优势------需求、测试、代码三者绑定，不存在"需求文档和代码对不上"的问题。

第二份是SPEC（Technical Specification，技术规范文档），回答"怎么做"。SPEC包含五个部分：系统架构（整体架构图、模块划分、数据流向、部署拓扑）、技术选型（框架、数据库、中间件及选型理由------为什么选PostgreSQL而非MySQL、为什么选Redis做缓存）、数据模型（表结构、字段定义、索引设计、外键关系图）、API接口（路由定义、请求/响应格式、状态码规范、错误处理策略）、目录结构（项目文件组织规范、模块边界定义）。SPEC的详细程度应该达到"另一个开发者拿到这份文档，不看源码就能理解系统设计"的水平。对Agent而言，SPEC是执行的蓝图------有了SPEC，Agent不需要猜测数据库该用什么字段类型、API该返回什么格式，直接按规范执行即可。

第三份是质量规范文档，回答"做到什么程度"。质量规范涵盖三个维度：编码规范（命名约定、代码风格、注释要求，通常对应ESLint、Prettier、Ruff等工具的配置文件，Agent必须遵守）、测试规范（单元测试覆盖率要求、集成测试范围、测试命名规范、Mock数据策略）、安全规范（输入验证规则、SQL注入防护方案、XSS防护方案、敏感数据加密存储要求、API鉴权策略）。质量规范的本质是把团队的隐性约定变成显性规则，让Agent有据可依。没有质量规范的团队，每个开发者让Agent生成的代码都带有个人风格烙印；有了质量规范，所有Agent产出都符合统一标准。

SDD生态在2025年快速发展，代表性框架各有侧重。GitHub Spec Kit是GitHub推出的规范驱动开发工具包，提供从PRD到代码的完整工作流，与GitHub Copilot深度集成，支持规范的版本管理和团队协作。OpenSpec是一个开源的规范驱动开发框架，强调规范的版本管理、变更追踪和团队评审流程，适合对规范严谨度要求高的团队。Superpowers专注于将规范转化为可执行的Agent指令，在规范和Agent执行之间搭建桥梁。Amazon Kiro编辑器是AWS在2025年推出的以SDD为核心的IDE，内置了规范编写、任务拆解、Agent执行的完整流程，把SDD工作流产品化（以上信息基于2026年5月核对，具体功能请以各项目官网为准）。

SDD与Vibe Coding之间存在清晰的决策边界。判断该用哪种方式，核心看三个因素：项目复杂度、受众规模、维护周期。原型验证、个人自用脚本、一次性数据处理任务------这些场景用Vibe Coding效率最高，写规范的时间可能比写代码还长，属于过度工程化。生产环境项目、团队协作项目、需要长期维护的项目------这些场景必须用SDD，因为没有规范约束的Agent生成代码会在维护阶段变成灾难：三个月后没人记得为什么这段代码这样写，新加入的团队成员无法理解代码结构，修改一个功能引发连锁Bug。

用AI辅助生成PRD是一个实用的工作模式。与其从空白文档开始手写PRD，不如让AI先出初稿，人工再修改完善。一个经过验证的Prompt范式如下：

我想做一个「博客系统」。请先不要写代码。
请你先完成三件事：
1. 用小白能看懂的话整理PRD，包括核心功能、
   目标用户、使用场景
2. 拆成3-5个开发阶段，每个阶段有明确的交付物
3. 告诉我第一版最小可用功能（MVP）应该包含什么

输出格式要求：
- PRD部分用用户故事格式
- 每个功能附Given/When/Then验收标准
- 开发阶段按依赖关系排序

AI生成PRD初稿后，人工审核的重点是：功能优先级是否合理（MVP是否真的最小可用）、验收标准是否可测试（Given/When/Then是否具体到能写测试用例）、开发阶段拆分是否符合技术依赖关系（用户认证是否在文章管理之前、数据备份是否在最后）。这个"AI出初稿、人工做决策"的模式，正是Agentic Engineering和SDD结合的典型工作方式------AI负责生成和结构化，人负责判断和决策。

AI输出示例（节选）：

=== PRD ===
核心功能：文章发布与管理、标签分类、评论系统
目标用户：技术博主，需要发布带代码块的技术文章
使用场景：个人技术博客、团队知识库

用户故事：
作为博主，我想要用Markdown写文章并实时预览，
以便在发布前确认排版效果

验收标准：
Given：博主在编辑器中输入Markdown格式文本
When：博主切换到预览模式
Then：预览区显示渲染后的HTML
And：代码块有语法高亮
And：预览实时更新，延迟不超过200ms

=== 开发阶段 ===
阶段1（MVP）：文章CRUD + Markdown渲染
阶段2：用户认证 + 权限控制
阶段3：标签系统 + 按标签筛选
阶段4：评论系统 + 嵌套回复
阶段5：数据备份 + 部署优化

=== MVP建议 ===
第一版只做阶段1，确保核心写作流程可用

从Agentic Engineering到SDD的跃迁，本质是从"信任Agent的理解能力"到"用规范约束Agent的执行边界"。Agent的理解能力会随模型迭代而提升，但规范的价值不会因此消失------规范不仅是给Agent的约束，更是团队协作的契约、项目维护的基石、质量保障的底线。一个没有规范的Agent团队，就像一支没有施工图纸的建筑队，每个人都在盖房子，但盖出来的东西拼不到一起。

第三步跃迁：从单Agent到多智能体协作

单Agent在中小型项目中表现出色，但当项目复杂度超过一定阈值，单Agent的局限性开始显现。一个Agent同时负责架构设计、编码实现、测试编写、代码审查，认知负荷过重，容易顾此失彼------在写代码时忘记架构约束，在写测试时偏离需求原始定义。更关键的是，单Agent只能串行工作------写完代码才能测试，测完才能修Bug，修完才能进入下一个功能。这种串行模式在大型项目中成为效率瓶颈：一个包含50个API端点的项目，单Agent逐个实现、逐个测试，耗时线性增长。

多智能体协作（Multi-Agent Collaboration）是解决这一问题的方向。核心思路是让多个专业化的Agent分工协作，每个Agent专注一个领域，通过协调机制完成整体目标。就像人类团队中，架构师负责设计、开发工程师负责编码、测试工程师负责质量保障、运维工程师负责部署------每个角色专业化，通过协作流程整合产出。

三种主流协作模式各有适用场景。

第一种是Leader-Worker（领导者-执行者）模式。一个Leader Agent负责理解整体需求、拆解任务、分配工作，多个Worker Agent各自执行分配到的子任务。Leader还负责整合各Worker的产出、处理冲突、确保一致性------如果Worker A和Worker B的接口定义不兼容，Leader负责协调修正。Qoder是这一模式的典型代表平台，其架构中Leader Agent扮演项目经理角色，负责需求分析和任务调度；Worker Agent扮演开发者角色，各自专注一个模块的实现。这种模式适合需求明确、任务可清晰拆分的项目。文字流程如下：

[用户需求]
    │
    ▼
[Leader Agent：分析需求，拆解任务]
    │
    ├──► [Worker A：实现用户模块]
    ├──► [Worker B：实现文章模块]
    └──► [Worker C：实现评论模块]
           │
           ▼
    [Leader Agent：整合产出，检查一致性]
           │
           ▼
    [最终代码交付]

第二种是Pipeline（管道式）模式。多个Agent按固定顺序接力处理，每个Agent接收上一个Agent的输出作为输入，处理后传递给下一个。典型流程是：需求分析Agent→架构设计Agent→编码Agent→测试Agent→部署Agent。每个Agent专注于自己的环节，像工厂流水线一样高效。需求分析Agent的产出（PRD）直接作为架构设计Agent的输入，架构设计Agent的产出（SPEC）直接作为编码Agent的输入，环环相扣。这种模式适合流程标准化程度高、各环节边界清晰的项目。文字流程如下：

[需求分析Agent]──►[架构设计Agent]──►[编码Agent]
                                          │
[部署Agent]◄──[测试Agent]◄────────────────┘

第三种是Peer-to-Peer（对等协作）模式。多个Agent地位平等，各自独立完成工作后互相审查。一个Agent写代码，另一个Agent做Code Review；一个Agent写测试，另一个Agent验证测试覆盖率是否达标、测试逻辑是否有效。这种模式适合质量要求高、需要交叉验证的项目，模拟的是人类团队中同事互相Review的工作方式。与Leader-Worker模式不同，P2P模式中没有中央调度者，Agent之间通过协商机制达成一致。文字流程如下：

[编码Agent A]◄──审查──►[审查Agent B]
       │                        │
       └────互相反馈────────────┘
                 │
                 ▼
         [高质量代码产出]

三种模式的选择取决于项目特征。需求明确且可拆分的选Leader-Worker，流程标准化的选Pipeline，质量要求极高的选P2P。实际项目中也可以混合使用------比如在Leader-Worker框架内，Worker之间采用P2P模式互相审查，兼顾效率和 质量。

多智能体协作的真正价值在于"并行"。在单Agent模式下，编码、测试、审查是串行的，总耗时等于三者之和。在多智能体模式下，编码Agent写完模块A后，测试Agent可以立即开始测试模块A，同时编码Agent继续写模块B，审查Agent审查已完成的模块。总耗时接近最长单环节的耗时，而非所有环节之和。这种并行能力在大型项目中带来的效率提升是数量级的------50个API端点的项目，如果5个Worker Agent并行实现，理论耗时缩短为单Agent的五分之一。

但并行也带来了新的复杂度------协调成本。多个Agent同时操作同一个代码库时，文件冲突、接口不兼容、依赖顺序错误等问题会频繁出现。Leader-Worker模式通过中央调度缓解了部分冲突，但Leader本身成为了潜在的瓶颈------如果Leader的任务拆解不合理，所有Worker的执行都会受影响。Pipeline模式避免了并行冲突（因为是严格串行接力），但牺牲了并行优势。P2P模式最大化了并行度，但协调成本最高。模式选择本质上是在并行效率和协调成本之间寻找平衡点，没有万能解，只有适合具体项目特征的选择。

需要指出的是，多智能体协作在2026年仍处于探索阶段。Leader-Worker模式在Qoder等平台上有实际应用，Pipeline模式在CI/CD流程中有成熟实践，但Peer-to-Peer模式的自治协调机制仍面临挑战------Agent之间的沟通成本（多一轮通信意味着多一轮延迟）、冲突解决机制（两个Agent对同一接口有不同理解时谁说了算）、一致性保障（如何确保所有Agent遵循同一套规范）都需要进一步验证（以上判断基于2026年5月观察，具体进展请以各平台官方文档为准）。

贯穿三次跃迁的主线：Harness Engineering

三次跃迁看似各自独立，实则共享一条主线------Harness Engineering（脚手架工程化）。Harness指的是围绕模型搭建的工程化脚手架，它不是模型本身，而是让模型能力在真实项目中稳定发挥的基础设施。打个比方，模型是一台高性能发动机，Harness是整车的底盘、传动系统、悬挂系统、方向盘------发动机再强，没有这些配套，车也跑不起来、跑不稳、跑不安全。

Harness的本质可以用一个公式概括：模型能力决定下限，项目上下文+工具权限+规则文件+工作流决定上限。同一个模型（比如Claude Sonnet 4），在裸环境（直接对话、无文件访问、无工具调用）下可能只能完成简单任务------生成一段代码片段、回答一个问题。但在完善的Harness环境中------有项目规则文件定义编码规范、有LSP提供代码语义理解、有MCP连接数据库和测试框架、有Subagents实现任务委派------同一个模型能胜任复杂项目开发。差异不在模型，在脚手架。

这正好回扣第3篇提出的七层Harness框架。从底层到顶层，七层结构各有职责：

第一层是CLAUDE.md（或等效的项目规则文件），定义项目的全局规则------技术栈选择、编码规范、禁止事项、架构约束。这是Agent理解项目上下文的入口，相当于新员工入职时拿到的项目手册。第二层是Hooks（钩子），在Agent执行特定操作前后触发自定义逻辑，比如提交代码前自动运行lint检查、创建文件后自动添加版权头。第三层是Skills（技能），将常用操作封装为可复用的Agent能力，比如"创建REST API端点"可以封装为一个Skill，包含路由定义、控制器编写、测试生成的标准流程。第四层是Plugins（插件），扩展Agent的外部能力，比如数据库操作插件、云服务调用插件、消息通知插件。第五层是LSP（Language Server Protocol，语言服务器协议），让Agent理解代码的语义结构------函数定义、类型关系、引用追踪------而非把代码当作纯文本字符串处理。第六层是MCP（Model Context Protocol，模型上下文协议），标准化的工具接入协议，让Agent能连接外部系统和数据源------数据库、API、文件系统、测试框架。第七层是Subagents（子智能体），将复杂任务委派给专门的子Agent处理，实现关注点分离------主Agent负责协调，子Agent各自专注一个子任务。

七层框架与三次跃迁的对应关系清晰可见。第一次跃迁（到Agentic Engineering）主要依赖第五层LSP和第六层MCP------让Agent能理解代码语义、调用外部工具，从"只能生成文本"升级为"能操作代码和环境"。第二次跃迁（到SDD）主要依赖第一层CLAUDE.md和第三层Skills------用规则文件约束Agent行为边界，用技能封装规范化的开发流程，让Agent的执行从"自由发挥"变为"按规范操作"。第三次跃迁（到多智能体协作）主要依赖第七层Subagents和第二层Hooks------用子智能体实现任务分工，用钩子实现Agent间的协调和一致性检查。

Harness Engineer是一个由此催生的新角色定义。Harness Engineer不是写业务代码的人，而是"驾驭Agent的人"。其核心职责包括四个方面：设计项目上下文结构（哪些文件Agent需要访问、哪些需要排除、上下文窗口中应该保留什么信息）、配置工具权限（Agent能执行哪些命令、不能执行哪些------比如允许运行测试但不允许删除数据库）、编写规则文件（编码规范、架构约束、禁止操作清单------这些规则同时约束人类和Agent）、设计工作流（任务如何拆解、Agent如何协作、人工审核节点在哪个环节）。Harness Engineer的产出不是代码，而是让Agent能稳定产出高质量代码的工程环境。

搭建一个有效的Harness不是一次性工程，而是持续迭代的过程。初始阶段，团队可能只配置了一个简单的CLAUDE.md文件，定义基本的技术栈和编码规范。随着项目推进，会发现Agent在某些操作上反复出错------比如总是忘记添加错误处理、总是用错测试框架的断言方法。这些反复出错的地方就是Harness需要加强的点：把"添加错误处理"写入规则文件，把"使用正确的断言方法"封装为Skill。Harness的成熟度与项目复杂度同步增长，不存在一步到位的完美配置，只有不断发现问题、加强约束、固化流程的迭代循环。衡量Harness质量的指标很直接：Agent在不需要人工干预的情况下，能自主完成多大比例的任务。这个比例越高，Harness越成熟。

从依赖模型直觉到主动构建工程化环境，这是Harness Engineering的核心转变。Vibe Coding时代，开发者关心的是"怎么向模型描述需求"------Prompt写得好不好、描述够不够清晰。Harness Engineering时代，开发者关心的是"怎么搭建一个让Agent稳定工作的环境"------规则文件是否完整、工具权限是否合理、工作流是否高效。前者的焦点在提示词，后者的焦点在系统工程。这个转变意味着，AI开发能力的竞争已经从"谁更会写Prompt"升级为"谁更会搭建Harness"------Prompt是战术层面的技巧，Harness是战略层面的能力。

演进路线图与能力成熟度模型

将四次演进放入一个统一的能力成熟度模型中，可以更清晰地定位个人和团队所处的阶段，以及下一步的演进方向。能力成熟度模型的价值不在于给团队"打分"，而在于提供一张地图------告诉你现在在哪、下一步去哪、需要补什么能力。判断团队所处阶段有一个简单的自测方法：回顾最近一次开发任务，如果你花了大量时间在"描述需求"和"手动测试"上，还停留在Vibe Coding阶段；如果已经开始让Agent先出计划、自己审核计划后再放行，进入了Agentic Engineering阶段；如果开发前会先写PRD和SPEC、代码必须通过验收标准测试，达到了SDD阶段；如果多个Agent在同时编码、测试、审查，则进入了多智能体协作阶段。

四阶段能力成熟度模型从低到高依次为：Vibe Coding、Agentic Engineering、SDD、多智能体协作。每个阶段有明确的标志、适合的项目规模、对应的人类角色和典型工具栈。

阶段	标志	项目规模	人类角色	典型工具
Vibe Coding	凭感觉迭代，对话式生成	原型/个人项目	需求描述者	Cursor、Claude Code
Agentic Engineering	Agent自主规划执行	中型项目	计划审核者	Claude Code+Plan Mode
SDD	规范先行，代码履约	生产项目	规范定义者	Spec Kit、Kiro
多智能体协作	Agent团队分工协同	复杂企业项目	项目总监	Qoder、多Agent平台

（以上工具信息基于2026年5月核对，具体功能与定位请以各产品官网为准。）

2026年的现实定位需要客观看待。多数开发者在第二和第三阶段之间------已经从纯Vibe Coding过渡到使用Agent的Plan Mode，开始有意识地审核Agent的计划，但尚未建立完整的SDD规范体系。具体表现为：知道让Agent先出计划再执行，但计划审核流于表面；偶尔写一些需求文档，但没有形成PRD、SPEC、质量规范的三件套体系；CLAUDE.md等规则文件存在但内容简略，不足以约束Agent行为。第四阶段（多智能体协作）仍处于早期探索，Leader-Worker模式有初步实践，P2P模式的自治协调尚不成熟。这意味着，对大多数开发者和团队而言，当前最有价值的投入方向是巩固第二阶段能力、向第三阶段SDD演进------这是投入产出比最高的跃迁路径。

个人演进路径的建议分三步。第一步，在现有项目中引入Plan Mode习惯，每次开发前让Agent先出计划、人工审核后再执行，建立"计划先行"的肌肉记忆。这个习惯的养成不需要额外工具，只需要改变工作流程------从"直接让Agent写代码"变为"先让Agent出计划"。第二步，选择一个中等复杂度的项目，尝试编写完整的PRD和SPEC，体验规范驱动开发的流程，感受规范对Agent输出稳定性的提升。用同一个需求分别做对比实验------不写规范让Agent生成一次，写了规范再让Agent生成一次，对比两次输出的质量和一致性。第三步，在团队中推广CLAUDE.md等规则文件，建立团队级的Agent使用规范，为多智能体协作做铺垫。团队规范的核心是统一所有人的Agent使用方式，避免"每个人都在用Agent，但方式各不相同"的混乱状态。

团队演进路径需要额外考虑协作因素。团队引入SDD时，规范的编写和维护本身需要投入------PRD谁写、SPEC谁审、质量规范谁来制定，都需要明确的责任分工。建议从核心模块开始试点，验证流程可行后再推广到整个项目。多智能体协作在团队场景中需要额外解决Agent产出的一致性问题------多个Agent生成的代码风格是否统一、接口是否兼容、命名是否一致，这些都需要规范层面提前约束。团队演进的节奏应该比个人更保守，每一步都需要小范围验证后再扩大范围。

收尾：Vibe Coding的真正遗产

Vibe Coding作为一个"阶段"可能正在落幕，但其核心遗产在Agentic Engineering和SDD中依然延续。回看第1篇总结的四大原则------"关注点从代码转向产品""拥抱指数增长""信任但验证""迭代而非完美"------这些原则在工程化时代不仅没有过时，反而因为执行方式的纪律化而更具操作性。原则是方向，工具和方法是手段，方向不会因为手段升级而改变。

"关注点从代码转向产品"在SDD中体现为PRD先行------开发者在写代码之前先想清楚产品要什么、用户是谁、价值在哪。规范驱动开发天然要求产品思维前置，因为PRD是代码的前置条件。"拥抱指数增长"在多智能体协作中体现为并行执行------多个Agent同时工作带来的效率提升是指数级的，而非线性的。"信任但验证"在Agentic Engineering中体现为Plan-Act-Observe-Reflect循环------信任Agent的执行能力让它自主推进，但通过反思环节验证每一步结果，发现偏差立即修正。"迭代而非完美"贯穿所有阶段------从MVP到完整产品的演进本身就是迭代的体现，区别只在于Vibe Coding的迭代是随机试探的，SDD的迭代是规范驱动的、有方向的。

四大原则的执行方式确实发生了变化，这种变化是纪律化的升级。Vibe Coding时，"信任但验证"靠的是人工逐行检查代码------成本高、覆盖低、容易遗漏。SDD时，"信任但验证"靠的是验收标准自动化测试------Given/When/Then直接转化为测试用例，每次代码变更自动运行全量测试，更系统、更可靠。Vibe Coding时，"迭代而非完美"靠的是频繁对话修改------每次发现问题就重新对话，迭代方向不可预测。Agentic Engineering时，"迭代而非完美"靠的是Agent自主修复循环------Agent发现问题、修正代码、重新测试，循环自动进行，更高效、更持续。原则没变，工具和方法变了，执行精度提升了。

回望整个系列五篇文章，构成了一条完整的认知链路。第1篇回答"Vibe Coding是什么"------追溯起源、定义本质、提炼四大原则。第2篇回答"怎么做"------拆解工作流程、实践方法、Prompt技巧。第3篇回答"用什么做"------梳理工具生态、模型选择、七层Harness框架。第4篇回答"什么时候用、什么时候不该用"------界定适用场景、边界条件、四大崩塌点。第5篇（本文）回答"接下来去哪里"------规划三次跃迁的演进方向、能力成熟度模型、个人与团队的演进路径。五篇文章从"是什么"出发，经过"怎么做""用什么做""何时用"，最终到达"向何处去"，形成了一个完整的认知闭环。

五篇文章合在一起，完整回答了"Vibe Coding是什么"这个起点问题，并延伸到了"Vibe Coding向何处去"这个终点问题。Vibe Coding不是终点，而是AI辅助编程长河中的一个起点。从Vibe Coding到Agentic Engineering，从SDD到多智能体协作，从提示词工程到Harness Engineering------演化的方向始终一致：让人更专注于思考和决策，让Agent更专注于执行和验证。理解这条演进路径，才能在工具快速迭代的技术浪潮中找到属于自己的坐标系。工具会变，模型会升级，但"人负责思考、机器负责执行"这条分工原则，是穿越所有技术周期的稳定锚点。