从 Vibe Coding 到 Agentic Engineering：AI 编程工作流的 2026 进化图谱
去年这个时候，你打开 ChatGPT 或者 Claude，让它帮你写一个函数，然后复制粘贴到编辑器里，这事已经算「AI 辅助编程」了。到了 2026 年，事情已经完全变了。
现在的日常是：你打开终端，启动一个 Coding Agent，跟它说「把这个系统的用户认证模块重构一下」，然后 Agent 自己去读代码、写计划、拆任务、创建分支、写测试、实现功能、跑 CI，最后把 PR 递到你面前。你只需要 review 一下，决定合并还是打回去。
这不是科幻。这是 Karpathy、Addy Osmani、Simon Willison 这批人正在系统化推广的 Agentic Engineering。
但问题也随之而来：当你不再亲手写每一行代码，而是管理一群能写代码的 Agent 时，你需要一套全新的工作方法。怎么安排任务？怎么保证质量？怎么避免 Agent 把代码库搞成灾难现场？
日本工程师 Sakasegawa 最近发表了一篇非常全面的综述《A Survey of Development Workflows in the Coding Agent Era》，把 2026 年 AI 编程工作流的「江湖格局」梳理得很清楚。本文基于这篇综述，加上我自己的实践经验，画一张这个新世界的导航图。
从 Vibe Coding 到 Agentic Engineering：一年间的范式跃迁#
2025 年 2 月，Karpathy 提出了 Vibe Coding 这个概念。当时的含义很简单：你不再亲手写代码，而是让 AI Coding Agent 凭「感觉」去写，你只负责描述需求。
这个提法在当时很有争议。批评者认为这是放弃了对代码质量的把控，支持者则认为这是解放生产力的必经之路。
一年后的 2026 年 2 月，Karpathy 把这个概念升级为 Agentic Engineering。定义也清晰了很多：你 99% 的时间花在编排和监督 Agent 上，而不是直接写代码。
与此同时，Addy Osmani 对这个方法论做了大量系统化工作。他观察到，成功的 AI 辅助开发者把 70% 的时间花在问题定义和验证策略上，只有 30% 用于执行。这跟传统开发中「80% 写代码、20% 思考」的分配完全颠倒了过来。但最终完成的总时间大幅缩短。
他还提出了「工厂模型」的思维转变：从「手工打磨每一件产品」转变为「运营一条自动化装配线」。你的角色从工匠变成了工厂经理。
Simon Willison 则从实践层面总结了几个核心模式：Red/Green TDD（测试驱动）、Writing Code is Cheap Now（代码现在很便宜）、First Run the Tests（先跑测试再说）、Linear Walkthroughs（线性遍历）、Hoard Things You Know How to Do（囤积你会做的事）。这些模式共同构成了一套可操作的 Agent 协作方法论。
理解这个演进很重要，因为它决定了后面的所有选择。你不再问「怎么让 AI 写出更好的代码」，而是问「怎么设计一个流程，让 AI 在其中持续产出高质量代码」。
四大项目工作流：选对框架比选对模型更重要#
当你接受了 Agentic Engineering 的理念，下一个问题就是：具体怎么跑一个项目？
Sakasegawa 的综述中梳理了四种主流工作流。它们各有适用场景，而且可以组合使用。
1. 头脑风暴 → 计划 → 执行（Harper Reed 风格）#
这是最经典、也最有影响力的 Coding Agent 工作流原型，由 Harper Reed 提出，Simon Willison 推广。
流程分三步：
第一步，头脑风暴。 用一个对话型 LLM，跟它说「一次只问我一个问题」，通过反复对答深挖想法，最终产出一份 spec.md。
第二步，做计划。 把 spec.md 喂给一个推理模型，让它拆成小步骤，产出 prompt_plan.md 和 todo.md。
第三步，执行。 按顺序把生成的 prompt 喂给 Coding Agent（当时主要是 Claude Code），逐个实现。
这个流程最适合个人做绿野项目（从零开始的新项目），不适合团队协作。Harper Reed 自己也承认这一点。但它的意义在于确立了一个原则：不要一上来就让 AI 写代码，先把规格搞清楚。 这个原则影响了后面所有工作流的设计。
2. SDD / AI-DLC：规格驱动的开发#
这是 2025 到 2026 年间传播最快的工作流。作为 Vibe Coding 的反面，它把规格文档（spec）放在真理源头的位置。目前已经有 30 多个竞争框架，Thoughtworks 技术雷达把它评为「评估中」。
SDD 的核心思想是：需求 → 设计 → 任务 → 实现。人在规格层面做决策，AI 在实现层面写代码。
AWS 把这个理念扩展到了团队和组织规模，形成了 AI-DLC（AI 驱动的开发生命周期），包含三个阶段：
- 启动期：规划阶段，包含「Mob Elaboration」（4 小时的同步会议，把业务意图转化为详细需求）
- 建设期：开发阶段，Adaptive Workflow 会根据任务复杂度自动从 9 种阶段菜单中选择合适的流程
- 运营期：持续运维
工具生态方面，几个值得关注的项目：
| 工具 | Stars | 特点 |
|---|---|---|
| GitHub Spec Kit | 76,627 | 事实标准，支持 22+ Agent |
| BMAD-METHOD | 40,579 | 多 Agent 方法，12+ 领域专家角色 |
| OpenSpec | 30,399 | 迭代式规格管理，轻量，擅长棕地项目 |
| GSD | 29,635 | 元提示（meta-prompting），Claude Code 中心化 |
SDD 适合中大型团队的功能开发。它的一个关键好处是：用阶段门审查替代了实现过程中的微观审批，解决了审批疲劳问题。
但它也有自己的问题。规格文档可能跟实际代码产生偏差（「淹没在 Markdown 的海洋里」），对小 bug 修复来说太重了，而且有回到「重规格 + 大爆炸发布」这种老旧反模式的风险。
3. RPI：研究 → 计划 → 实现#
这是 Cloudflare 工程主管 Boris Tane 在 9 个月的 Claude Code 使用中系统化出来的流程，跟 Block 公司的 RPI 方法论和 HumanLayer 的框架高度趋同。
它的核心是「理解优先」。在动手写代码之前，先用 Agent 对现有代码库做深度研究，理解上下文，然后制定详细的变更计划，最后才进入实现阶段。
这个流程特别适合对大型现有代码库做修改的场景。它避免了 Agent 在不理解全局的情况下盲目修改，导致连锁破坏。
4. Superpowers：全自动化流水线#
这是一个把 SDD 和 TDD 融为一体的 7 阶段流水线，通过强制方法论来约束 Agent 的行为：
- 头脑风暴：交互式拉需求，用户批准后才进入下一步
- Git Worktrees：自动创建隔离的开发分支，检查测试基线
- 计划：把批准的设计拆成微任务（每个 2 到 5 分钟），精确指定文件路径、代码规格和验证标准
- 执行：每个任务派一个独立子 Agent，带两阶段审查
- TDD：严格强制执行 RED → GREEN → REFACTOR 循环
- 代码审查：按严重程度对变更进行分类
- 分支完成：验证测试套件，提交 PR
本质上，Superpowers 是一套护栏，防止 Agent 不经思考就一头扎进代码里乱改。如果你想要全流程自动化且愿意接受方法论约束，它是很好的选择。
怎么选？#
| 维度 | Harper Reed | SDD/AI-DLC | RPI | Superpowers |
|---|---|---|---|---|
| 核心优势 | 详细的规格生成 | 规格驱动实现 | 理解优先，原子化拆分 | 方法论强制执行 |
| 验证手段 | 人工审查 | 测试 + 规格符合性 | 注释循环 | TDD + 代码审查 |
| 目标规模 | 绿野项目 | 通用 | 中大型（存量代码） | 通用 |
| 工具依赖 | 低 | 高（需要框架） | 中（文件约定） | 高（需要插件） |
| 团队 | 单人 | 团队 | 团队 | 单人到团队 |
粗略指南：绿野个人项目选 Harper Reed，需要规格管理的团队选 SDD，大型存量代码修改选 RPI，想全流程自动化的选 Superpowers。
落地的三项关键技术#
选好工作流之后，下一个问题是：怎么在实际编码会话中保持质量？Sakasegawa 总结了三个核心技法。
上下文工程（Context Engineering）#
这可能是在 Agent 输出质量上最重要的单一因素。比选什么模型更重要，比怎么措辞 prompt 更重要。
核心原则是「喂什么」和「不喂什么」决定了 Agent 的表现：
- 上下文打包：把任务需要的所有东西塞进上下文，包括文件、规格、约束、现有代码风格。Addy Osmani 的建议是「写代码之前先做脑力倾倒」
- 渐进式披露：在
CLAUDE.md或AGENTS.md里只放 100 token 的摘要，Skill 和规则文件按需动态加载 - 文件系统作为外部记忆：把研究结果和中间产物保存成文件，上下文里只保留轻量路径引用
- 用 todo 列表管理注意力：创建并持续更新
todo.md，在长会话末尾重新注入目标，对抗 Agent「忘了自己要干什么」的问题 - 保留失败状态：不要把错误痕迹清掉。让 Agent 看到之前的失败，避免重复同样的错误
Agentic TDD#
传统的 TDD 是人写测试、人写代码、人重构。Agentic TDD 变成了：人定义业务规则，Agent 生成 TDD 计划，然后严格走 RED → GREEN → REFACTOR 循环。
关键变化是测试变成了 prompt。测试的形式让你能精确地向 AI 传达你期望的行为。
业界共识是，这是保证 Agent 生成代码质量最可靠的方式。工具方面，tdd-guard（1,811 stars）作为 Claude Code 的 hook 运行，阻止 Agent 跳过测试步骤。
多 Agent 分工#
一旦 TDD 保证了单任务的质量，多任务并行就成了自然延伸。
Anthropic 的「用 Claude 构建 C 编译器」实验展示了 16 个并行 Agent 协作编写 10 万行 C 编译器的可能性。设计、实现、审查可以并行推进。每个 Agent 运行在独立的上下文窗口中，避免了上下文污染。
典型的 Agent 团队配置是：Orchestrator（指挥，不写代码）、前端/后端/测试（领域专家）、Reviewer/Security（质量检查）。
各工具对多 Agent 的实现方式不同。Claude Code 采用子 Agent 委托模式，每个子 Agent 独立上下文，稳定可靠。OpenAI Codex 可以并行 spawn 子 Agent，支持通过 CSV 批量分发任务，每个 Agent 隔离在独立的 worktree 中。Cursor 支持最多 8 个 Agent 并行，强项是 IDE 内的可视化管理。
需要警惕的是：当所有 Agent 聚焦同一处修改时，可能互相覆盖对方的成果。
总结#
2026 年的 AI 编程已经不再是「让 AI 帮你写几行代码」那么简单了。它变成了一个三层设计问题：
- 项目工作流层：选择 SDD、RPI 还是 Superpowers，决定项目怎么跑
- 实现技法层：上下文工程、Agentic TDD、多 Agent 分工，决定编码质量
- 基础设施层：AGENTS.md、Skills、Hooks、编排器，提供支撑
真正重要的是三件事：用确定性的方式闭合反馈循环、在结构化节点插入人工审查、保持会话短小精悍。
我们正在从「程序员」变成「AI Agent 的管理者」。这个转型可能比从汇编到高级语言的跳跃更加深远。
参考来源：Sakasegawa, “A Survey of Development Workflows in the Coding Agent Era” (2026), nyosegawa.com. 本文基于原文进行了中文原创重写，补充了实践视角的分析和解读。