Vibe Coding 工作流全景图（2025-2026）

引言

Vibe Coding 自 2025 年 2 月由 Andrej Karpathy 命名以来，已经从一种实验性工作方式演变为专业开发者的主流实践。然而，"描述想要什么，AI 生成代码"这种表面简单的工作模式，掩盖了背后丰富的实践智慧与教训。

本文综合了来自 Supabase、0xminds、VibeCoding.app、Graphite.dev、DEV Community、Google Cloud 等多个来源的实践总结，梳理出 vibe coding 工作流的最佳实践、社区共识与常见陷阱。

一、两种工作形态：Vibe Coding 与 Agentic Engineering

社区逐渐形成了一个重要共识：vibe coding 和 agentic engineering 是两种不同场景的工具，而不是同一工具的两种叫法。

维度 Vibe Coding Agentic Engineering
起点 一个想法或提示 规范文档（Spec）
流程 即兴提示，快速生成 PEV 循环：Plan → Execute → Verify
人类角色 提示者，bug 修复者 架构师，审查者，决策者
QA 方式 "看起来能用" 测试、审查、评估
最佳场景 原型、MVP、探索性项目 生产系统、长期维护代码库
技术债务 快速积累 从第一天起管理
上下文 仅当前提示窗口 工程化上下文栈（AGENTS.md、CLAUDE.md）

Karpathy 本人在一周年回顾中也承认，专业开发者的默认工作流已经演变为"agentic engineering"——不再是"忘记代码的存在"，而是"作为架构师orchestrate AI 代理"。这一区分已经是社区的广泛共识。

二、核心工作流模式

2.1 规范驱动开发（Spec-Driven Development）

这是几乎所有高效 vibe coder 都会强调的第一步。

在打开任何 AI 工具之前，先写一份规范文档。 规范不需要复杂，但需要包含：

  • 核心用户流程：用户实际上做什么？
  • 数据模型：应用存储什么信息，关系是什么？
  • 页面和导航：有哪些页面，用户如何流转？
  • 设计约束：颜色、字体、布局偏好
  • 技术要求：认证方式、数据库选择、部署目标

规范成为每个提示的来源事实（source of truth）。当你 reference 具体的规范段落而不是每次即兴发挥时，AI 获得的指令更清晰，输出也更可预测。

实践建议：在项目根目录创建 SPEC.md，并在每次新会话开始时将其内容提供给 AI。

2.2 PEV 循环

Mistral AI 的实践指南提出了一个通用框架：Plan → Execute → Verify。

  • Plan：为目标和约束定义明确的计划——不是整个项目，而是下一步。用"先规划"替代"直接实现"，这会迫使模型先推理、暴露边缘情况、提出可审查的方法。
  • Execute：让 AI 生成代码或文档。
  • Verify：审查差异。运行测试。给出具体的、可操作的反馈。

这与 TestDevLab 提出的"TDD 循环"高度一致：在让 AI 写实现代码之前，先写（或让 AI 写）测试。测试定义了"完成"的样子，也定义了验证机制。

2.3 三层提示结构

多个来源（Supabase、0xminds、SitePoint）都独立提炼出了相同的三层提示结构：

层级 内容 示例
Context（上下文） 技术栈、现有代码结构、命名规范 "项目使用 Next.js + Supabase，API 路由在 /api"
Constraints（约束） AI 必须不做什么 "不要引入新依赖，不修改 auth 模块，只用 TypeScript strict mode"
Acceptance Criteria（验收标准） "完成"的定义（可测试的结果） "用户提交表单后，数据写入 users 表，返回 201 状态码"

跳过任何一层都会导致幻觉和范围蔓延（scope creep）进入输出。

2.4 小步迭代，而非一步到位

社区对"一个巨大提示生成整个应用"的做法有明确的共识：不要这样做。

AI 在一定复杂度以内表现良好，超过临界点后开始做出你未要求的权衡——功能被简化，页面被合并，输出偏离你的意图。每次提示越长，对每个单独部分的控制就越弱。

正确的做法是：

1. 生成基础 UI → 验证
2. 添加 API 连接 → 验证
3. 添加样式 → 验证
4. 添加认证 → 验证

每个步骤给 AI 提供精确的上下文。"脚手架优先，实现次之"——先让架构和接口稳定下来，再逐个功能构建。

2.5 多模型策略

Zoer.ai 提出的一个高级模式：不要用单一模型处理整个工作流。

角色 推荐模型类型 任务
架构师 高上下文推理模型 系统设计、数据建模、API 契约定义
实现者 快速代码专用模型 写函数、组件、样板代码
审查者 与实现者不同的模型 安全审查、逻辑审计、边缘情况识别

这类似于没有哪个严肃的工程团队会让同一个人写代码、审查自己的代码并发布。多模型策略为 AI 辅助开发引入了"同行评审"机制。

三、社区共识：什么有效，什么无效

3.1 广泛认可的有效实践

1. 使用 Plan Mode

几乎所有主流工具（Claude Code、Cursor、Codex CLI、Gemini CLI）都有 Plan Mode。在实现之前让 AI 先读代码库、规划步骤、提出方法，可以避免 AI 在中途做出架构决策或创建不必要的文件。

2. 提交在每个工作变更之后，不是每个变更之后

"每次工作变更后提交"意味着当某次 AI 生成破坏了代码时，你可以精确地回滚到上一个正确的状态。Graphite.dev 的数据显示，这是专业 vibe coder 最一致的实践之一。

3. 不要接受你无法解释的代码

这是"vibe coding"和"vibe engineering"之间的分界线。对于要维护的项目：如果不能向同事解释一个函数，就不要 ship 它。AI 生成的代码看起来很专业，但这不代表它可以无条件接受。

4. 在会话之间保持上下文

AI 在长对话中会丢失上下文。每 5-10 个提示后，Summarize 当前状态：构建了什么、还剩什么、当前问题是什么。这相当于重置 AI 的注意力。

5. 尽早配置 linting 和类型检查

TypeScript strict mode、ESLint、Prettier 这样的防护栏会自动捕获 AI 错误。0xminds 的测试显示，这些配置让 AI 表现"显著更好"——因为约束会过滤掉低级的语法错误和类型不匹配。

3.2 广泛认可的致命错误

1. 不审查生成的代码

AI 生成的代码看起来干净、格式化一致、命名专业。但这只是表面看起来不错——边缘情况、网络失败、并发问题、意外数据都会让它失败。更糟糕的是：安全漏洞经常隐藏在专业外观的代码下。社区报告的安全问题包括：硬编码密钥、缺少输入验证、SQL 注入漏洞、过度宽松的数据库策略。

2. 跳过版本控制

AI 生成代码很快。开发者接受变更也很快。没有版本控制，就没有办法回到上一个正常工作的状态。一次糟糕的 AI 建议可能修改了十二个文件，没有 git 你将无法恢复。

3. 范围蔓延（Scope Creep）

"And also add…" 是一个危险的短语。每个提示都应该保持专注。额外功能应该是额外的提示，而不是扩展当前的提示。

4. 在验证之前构建过多

"AI 让构建如此之快，以至于你可以在没人想要的产品上浪费好几天。" 这是 VibeCoding.app 列出的最大错误。AI 加速了生产，但也加速了浪费。在构建之前先验证想法。

5. 用 vibe coding 处理安全关键代码

Auth、权限、支付、用户数据——这些领域的 AI 代码经常出现"看起来能工作但不安全"的问题。Reddit 线程中有一个具体案例：AI 生成的基于角色的访问层，有一个回退路径默认变成"allow"。

四、多代理工作流

4.1 什么时候需要多代理

当任务足够复杂时——多个功能同时开发、依赖关系管理、长期执行周期——单一的反馈循环不够用了。你需要从"反馈提供者"转变为"编排者"。

Appxlab 的实践给出了一个实用上限：本地并行 AI 代理的实用上限是 3-5 个并发会话。超过这个数字，review 瓶颈会抵消并行带来的生产力收益。

4.2 Git Worktree 是关键基础设施

多代理并行工作流的关键是不可或缺的工具：没有它，多个代理同时写入同一工作目录会产生文件级冲突。一个代理的输出会被另一个代理覆盖。

每个并行代理应该在独立的 worktree 中工作，每个 worktree 拥有不重叠的文件集。

4.3 任务分解是最重要的技能

任务分解决定了多代理工作流的成败。分解正确，冲突在发生前就被预防；分解错误，任何合并工具都无法解决。

每个任务应该满足：独立可测试、文件所有权清晰、接口契约明确。

4.4 终止条件必须提前定义

社区实践中总结的终止条件：

  • 代理在同一个错误上停滞 3+ 次迭代无进展 → 中止，进一步分解任务
  • 代理触及其工作范围之外的文件 → 立即中止
  • 代理输出连续 2+ 轮测试失败 → 中止，将失败的测试用例加入提示，重新启动

五、提示模式库

5.1 五个黄金规则（VibeCoding.app）

  1. 上下文为王（@文件）：不要"修复登录中的 bug"，而是 "@auth.ts @login-form.tsx 修复用户会话在刷新后未持久化的问题"
  2. 描述 Why 和 What，不只描述 How：告诉 AI 目标，它可能会找到比你更好的方法
  3. 使用 Chain of Thought：复杂任务先让 AI 分析依赖，再提出计划，最后执行第一步
  4. Role Hack：告诉 AI 它是谁——"作为对性能痴迷的高级 React 工程师，重构这个组件"
  5. 小步迭代：不要一个提示做所有事情

5.2 高价值提示模板（VibeCodeMeta）

架构规划提示：

I'm building [description]. Stack is [stack].
Give me a file structure, key data models, and the 3 most important architectural decisions I need to make before writing any code.
Be opinionated — tell me what you'd do, not what I could do.

完整上下文生成器：

Here's what this function needs to do: [description]
It's called by: [list callers]
It should handle these edge cases: [list them]
Match the style of the rest of this codebase.

重构请求：

Refactor this code to [specific goal].
Keep the external API identical — nothing that calls this should need to change.
Explain what you changed and why.

PR 审查者：

Review this diff. Flag:
- Bugs or logic errors
- Security issues
- Performance concerns
- Style inconsistencies
Be direct. If it's fine, say it's fine.

部署检查清单：

I'm about to deploy [describe what changed].
Give me a pre-deploy checklist specific to these changes.
What could break? What should I verify first? What's the rollback plan?

5.3 五种核心提示模式（SitePoint）

模式 用途 核心思想
Context Priming 在任何代码请求之前建立项目上下文 提供技术栈、约定、约束，减少 AI 对训练数据默认值的依赖
Constraint Injection 明确说明 AI 必须不做什么 禁用库、禁止的类型构造、性能预算、反模式
Incremental Scaffolding 将大任务分解为序列化的微步骤 强制模型先提交决策（类型、接口），再逐层添加错误处理
Example-Driven Specification 提供参考代码段让 AI 匹配风格 "按照这个代码的风格写新组件"
Role and Review Framing 为输出设定质量标准和审查要求 "你是安全专家。审查 [criteria list]。修订后再呈现。"

六、工具与工作流的配合

6.1 工具选择矩阵

任务 推荐工具 原因
架构规划 高上下文模型（Claude Extended） 需要深度理解现有代码库
快速原型 Bolt.new、Lovable 浏览器内即时预览
精细多文件编辑 Cursor、Windsurf 图形界面 + 完整 IDE 功能
自主长任务 Claude Code、Codex CLI 终端代理模式，支持多代理
快速 UI 组件 v0 React + Tailwind 专用
代码审查 多模型交叉审查 不同模型发现不同的盲点

6.2 上下文管理文件

所有主流工具现在都有持久上下文的机制：

  • CLAUDE.md（Claude Code）
  • GEMINI.md（Gemini CLI）
  • AGENTS.md（OpenCode）
  • .cursorrules（Cursor）

这些文件是最重要的项目文件——比 README 更重要，因为它决定了 AI 是否理解你的项目，或者对你的项目产生幻觉。

文件应包含：架构决策、命名约定、禁止的模式、编码标准、工作流约定（分支策略、提交规范）。

七、行业转折：从 Vibe Coding 到 Agentic Engineering

7.1 发生了什么

2025 年是"vibe coding 派对年"——快速、令人兴奋、有点混乱。2026 年则是"宿醉回归清醒"的年份。

GitHub 和 Thoughtworks 都指出，原始提示不足以支撑严肃系统。可靠开发需要：上下文工程、规范、结构化工作流，以及可审计的工作记录。

7.2 Agentic Engineering 的定义

这不是一个花哨的重新命名。它标志着一个认真的行业转变：

  • Agentic：承认 99% 的工作中，你不是直接写代码，而是在orchestrate 代理
  • Engineering：强调这是一门需要专业知识、结构、和科学的学科——不是老虎机，而是可以精炼和掌握的技能

Agentic 软件工程不是"更多 AI 编码"。它是从"AI 作为草稿助手"到"AI 作为工程工作流参与者"的转变。工作单元不再是提示本身，而是循环：规范 → 上下文检索 → 实现 → 测试生成 → 审查 → 评估 → PR → 部署检查 → 运行时修复。

7.3 社区的最终共识

关于 vibe coding 的最终共识已经在多个来源中形成一致：

Vibe coding 的价值：快速启动、实验、快速原型

Agentic engineering 的价值：生产系统、长期维护、需要可靠性的环境

二者不是竞争关系，而是不同档位的齿轮。根据任务选择正确的模式——用 vibe coding 探索，用 agentic engineering 生产。

最有力的总结来自 Product Builder：

"停止做那个给 AI 提示的人，开始做那个专业地 directing AI 代理的工程师。"

8. SDLC 工具与规范驱动开发

Vibe Coding 工作流与正式软件开发生命周期（SDLC）的交汇点，是当前生态中增长最快的领域之一。多个工具专门将"规范先行"（spec-first）工作流注入 AI 代理环境，让团队在保持 vibe coding 效率的同时，获得工程级的可预测性与可审计性。

8.1 OpenSpec

概述：OpenSpec 是一个结构化的规范写作框架，47K GitHub stars，旨在将 AI 时代的协作流程标准化。核心思想是：规范（Spec）是产品经理、工程师和 AI 代理之间的唯一真实来源（Single Source of Truth）。

与 Vibe Coding 工作流的结合：

  • 将 PEV 循环的 "Plan" 阶段从松散的提示转化为结构化规范文档
  • 规范文件作为上下文输入传递给 AI 代理，减少上下文漂移
  • 支持多轮审查与版本化，规范迭代可追溯

工具链集成：OpenSpec 官方支持 Claude MCP（Model Context Protocol），可直接在 Claude Desktop/Claude Code 中调用规范模板、审查清单、验收条件生成器。

适用场景：需要跨角色协作（PM+工程师+AI）的团队，或需要将 AI 生成结果与产品规格对齐的中型项目。

8.2 Spec Kit（by GitHub）

概述：GitHub 官方出品的规范工具包，100K+ stars，提供一套结构化模板，用于在 GitHub 项目中编写规范、接受标准（Acceptance Criteria）和验收测试。强调"规范即代码"——将规范内容嵌入 Pull Request 描述、Issue 模板和 README。

与 Vibe Coding 工作流的结合：

  • 每个 feature 分支关联一个规范 Issue，AI 代理在实现时参照该 Issue 的验收条件
  • 自动生成"完成标准检查清单"，AI 代理可自检
  • 与 GitHub Copilot 深度集成：Copilot Workspace 可直接读取规范 Issue 并生成实现

适用场景：已在 GitHub 上运作的团队，希望将规范工作流嵌入现有 CI/CD pipeline，而不引入额外工具链。

8.3 Tessl

概述：Tessl 是一个新兴的 MCP（Model Context Protocol）原生工具，专注于 formal spec-driven 开发。区别于传统规范工具，Tessl 将规范定义为结构化 JSON/ YAML，可被 AI 代理直接解析和验证。

核心特性：

  • 结构化规范格式：强制要求包含前置条件、后置条件、边界条件，避免模糊描述
  • MCP 原生集成：作为 MCP server 运行，任何支持 MCP 的 AI 代理均可调用
  • 规范执行引擎：AI 实现可自动对照规范进行自我验证

与 Vibe Coding 工作流的结合：将"三层提示"中的 Acceptance Criteria 层正式化为 Tessl 规范格式，AI 代理在实现后自动对照规范检查，而非依赖人工审查。

适用场景：对代码正确性要求高、需要形式化验证的领域（如金融、医疗、基础设施），或需要多个 AI 代理协同且必须对齐同一规范的项目。

8.4 Kiro

概述：Kiro 是一个 IDE-first 的规范工具，以 EARS notation（Enhanced Artifact Reduction Specification）为核心，为 AI 时代的规范写作提供了一套严格语法。其 IDE 插件可在编写规范时实时验证语法正确性，并自动生成对应的测试用例骨架。

EARS Notation 简介：

When [触发条件], then [系统响应]
Where [条件], the [系统行为] shall [响应]

这种结构化语法强制规范编写者明确：谁触发、什么条件、系统如何响应——解决了 Vibe Coding 中常见的"提示模糊导致输出模糊"问题。

与 Vibe Coding 工作流的结合：

  • Kiro 的 IDE 插件在 AI 生成代码时自动标注"规范覆盖缺口"，即 AI 实现未覆盖的规范条目
  • 内置 prompt 优化器：将模糊的自然语言提示转化为符合 EARS 格式的结构化规范

适用场景：需要严格规范编写的团队，或希望训练 AI 代理学会"先写规范再实现"的开发者。

8.5 工具选择矩阵

工具 规范格式 MCP 支持 IDE 集成 团队协作 适用阶段
OpenSpec Markdown 模板 ✅ 官方支持 基础（CLI 为主） 强（多角色） Plan + Review
Spec Kit GitHub Issue/PR ✅（Copilot 集成） 强（GitHub IDE） 强（权限模型） 全流程
Tessl JSON/YAML ✅（MCP 原生） 弱 中 Verify + Deploy
Kiro EARS Notation 计划中 强（IDE-first） 弱（单人为主） Plan + Verify

8.6 社区共识：SDLC 工具的价值

在 Vibe Coding 与 Agentic Engineering 的讨论中，规范驱动工具的价值已形成明确共识：

支持规范化的人群论点：

  • 规范文档解决"AI 输出不一致"问题——约定大于默契
  • 结构化规范让 AI 代理的输出可预期、可验证
  • 规范先行减少返工，提升 AI 代理的执行效率

质疑的声音：

  • 过重的规范流程与"vibe"理念相悖——快速探索不应被文档拖累
  • 小型项目（独立开发者、hackathon）引入规范工具反而降低效率
  • 规范质量依赖人工编写，AI 辅助规范生成尚未成熟

社区的实际选择：多数团队采用"双轨制——探索阶段用 vibe coding快速验证，验证成功后用规范工具补充工程级文档，再进入 agentic engineering 生产流程"。工具选择取决于项目阶段和团队规模。

参考来源