Vibe Coding（氛围编程）从 Andrej Karpathy 提出概念到如今席卷开发圈，只用了不到一年时间。很多人对它的印象停留在「跟 AI 聊天就能写出代码」，但真正落地过项目的人都明白：vibe coding 不是一种单一的开发方式，而是一个连续谱。
不同的项目阶段、团队成熟度、风险容忍度，对应着完全不同的人机协作模式。粗暴地用「纯 AI 写代码」或「人工逐行审查」二元对立来讨论，既不科学也不实用。
本文从两个核心维度拆解 Vibe Coding 的完整方法论，帮你找到适合自己项目的协作节奏。
一、第一个维度：输入把控的四个层级——从「说个大概」到「精确制导」
对 AI 的输入控制到什么程度，决定了 AI 的发挥空间，也决定了最终结果的可控性。这个维度背后有一套完整的理论支撑——Spec-Driven Development（规格驱动开发，SDD）。SDD 的核心思想是：规格是唯一可信源，代码只是规格的执行产物。在 AI 编程时代，输入的清晰度直接决定了输出的质量。
我们把输入把控程度由低到高分为四级：
层级对比表
| 把控层级 | 输入内容 | AI 发挥空间 | 适用场景 | 典型指令 |
|---|---|---|---|---|
| L1 灵感级 模糊需求 | 只给大致方向和功能描述，细节完全由 AI 脑补 | 极大 | 原型验证、周末项目、创意探索 | “帮我做一个待办清单应用，好看一点” |
| L2 需求级 完整需求 | 明确功能点、用户故事、验收标准，但不限制实现方式 | 中等 | 中小功能、业务逻辑不复杂的模块 | “实现用户注册登录，支持手机号+验证码，注册成功后跳转首页” |
| L3 框架级 需求+技术框架 | 完整需求 + 技术选型、架构分层、接口定义，具体实现由 AI 完成 | 较小 | 生产级功能、需要融入现有系统的模块 | “基于 Spring Boot + MySQL 实现用户模块，Controller/Service/Repository 三层架构，接口遵循 RESTful 规范” |
| L4 精确级 需求+详细方案 | 完整需求 + 详细技术设计 + 数据结构 + 算法思路 + 异常处理策略 | 极小 | 核心业务链路、高风险模块、性能敏感代码 | “按以下接口文档实现支付回调：请求字段定义见附录，签名校验算法为 HMAC-SHA256，异常分三类处理……” |
为什么不是越精确越好？
- L1 速度最快，但返工率最高。AI 生成的东西大概率不是你想要的，需要多轮修正。它的价值在于「快速看到一个东西」，用来验证想法是否值得继续投入。
- L4 质量最稳，但前期成本最高。你需要花大量时间写详细规格，某种程度上相当于把「写代码的时间」换成了「写文档的时间」。它的价值在于确定性——你知道 AI 不会跑偏。
- L2、L3 是大多数项目的甜蜜点。既保留了 AI 的创造力和效率优势，又把核心风险控制住了。
SDD 视角下的洞见：当 AI 写代码的边际成本趋近于零时，「明确表达想要什么」就成了最稀缺的能力。规格越清晰，AI 的价值释放越充分；规格越模糊，AI 越容易生成「看起来正确但其实不对」的代码。
二、第二个维度：输出审查的三种模式——白盒、灰盒、黑盒
第二个维度是：AI 输出代码后，你看到什么程度才放行？这对应着三种不同的「代码透明度」策略。
三种审查模式详解
1. 黑盒开发（Black-Box）
- 核心逻辑：不看代码，只看结果。测试通过就上线。
- 审查方式：完全依赖自动化测试、功能验收、接口联调。
- 优势：速度极快，人力投入最少，真正实现「忘记代码的存在」。
- 风险：隐藏的技术债、安全漏洞、性能问题会持续累积，某天集中爆发。
- 适用场景：内部工具、原型项目、一次性脚本、低价值页面。
2. 灰盒开发（Gray-Box）
- 核心逻辑：不纠结每一行代码，但要管住架构和边界。
- 审查方式：重点看模块划分是否合理、接口定义是否一致、依赖引入是否可控、数据结构是否符合设计。具体的函数内部实现不深究。
- 优势：在效率和质量之间取得平衡，既利用 AI 的编码速度，又防止架构腐烂。
- 风险：局部逻辑可能有瑕疵，但不影响整体走向。
- 适用场景：大多数业务功能、非核心模块、已有成熟架构的系统迭代。
3. 白盒开发（White-Box）
- 核心逻辑：逐行审查，对每一行代码负责。
- 审查方式：完整阅读 diff，检查逻辑正确性、边界处理、异常捕获、代码规范、安全隐患、性能隐患。
- 优势：质量最高，技术债最少，出问题概率最低。
- 风险：耗时，某种程度上失去了 AI 提效的意义。
- 适用场景：核心交易链路、支付/鉴权等安全敏感模块、底层基础设施、开源公共组件。
三种模式的审查重点对比
| 审查维度 | 黑盒模式 | 灰盒模式 | 白盒模式 |
|---|---|---|---|
| 功能正确性 | ✅ 测试验证 | ✅ 测试验证 | ✅ 测试验证 |
| 架构合理性 | ❌ 不关注 | ✅ 重点关注 | ✅ 关注 |
| 接口契约 | ❌ 不直接看 | ✅ 重点关注 | ✅ 关注 |
| 代码逻辑细节 | ❌ 不看 | ❌ 不深究 | ✅ 逐行检查 |
| 边界与异常处理 | ❌ 靠测试覆盖 | ⚠️ 抽查关键路径 | ✅ 全面检查 |
| 安全漏洞 | ❌ 靠黑盒扫描 | ⚠️ 检查依赖与入口 | ✅ 人工审计 |
| 代码风格与规范 | ❌ 不关注 | ❌ 不关注 | ✅ 严格要求 |
三、二维矩阵：9 种 Vibe Coding 模式全景
把两个维度交叉，我们就能得到一张完整的 Vibe Coding 方法论地图：
| 输入把控 → 审查模式 ↓ |
L1 灵感级 （模糊需求） |
L2 需求级 （完整需求） |
L3 框架级 （需求+框架） |
L4 精确级 （需求+方案） |
|---|---|---|---|---|
| 黑盒模式 | 纯野生 Vibe （原型/玩具） |
测试驱动黑盒 （内部工具） |
契约化黑盒 （外围系统） |
— |
| 灰盒模式 | — | 标准 Vibe （通用业务） |
主流工程化 Vibe （生产级开发） |
精密协作 （核心模块） |
| 白盒模式 | — | 辅助编码 （提效工具） |
架构师+AI （复杂系统） |
规格驱动开发 SDD （高可靠场景） |
标记「—」的组合在实践中很少出现，因为投入产出比不合理。比如用 L4 的精确输入却只做黑盒审查，或者用 L1 的模糊输入却做白盒审查，都是本末倒置。
几个典型组合的解读
1. 纯野生 Vibe（L1 + 黑盒）
这是大众认知里最经典的「氛围编程」——说个大概想法，AI 哗哗生成代码，跑起来没问题就直接用。适合做个人项目、快速验证想法，但绝对不能上生产。
2. 主流工程化 Vibe（L3 + 灰盒）
这是目前团队协作中性价比最高的模式：人负责定需求、定架构、定接口，AI 负责填充具体实现；写完后人只审查架构边界是否符合预期，内部细节交给测试兜底。大多数生产级 AI 辅助开发都落在这个象限。
3. 规格驱动开发 SDD（L4 + 白盒）
这是最严谨的模式：先写出结构化的完整规格，AI 按规格生成代码和测试，最后人工逐行复核。质量最高、确定性最强，但速度也最慢。适合金融、支付、医疗等高可靠要求的场景。
四、Vibe Coding 的生命线：测试驱动的迭代收敛
无论你选择哪种模式，有一件事是共通的——没有好的测试体系，Vibe Coding 就是在裸奔。
为什么测试如此关键？
Vibe Coding 的典型工作流是一个循环：
这个循环能够成立的前提，是测试足够可靠。如果测试覆盖不全，AI 每一轮修改都可能引入新的 bug，你永远不知道哪次改完就偷偷埋了雷。
传统开发中，代码是人写的，写的人心里有数；Vibe Coding 中，代码是 AI 改的，每一轮改动你都无法完全预判影响范围。测试就是你的安全网。
测试覆盖率的迭代演进
好的 Vibe Coding 项目，测试覆盖率是随着迭代逐步上升的，而不是一开始就追求 100%。
具体策略：
- 第一轮先写 Happy Path 测试：保证主流程能跑通，AI 至少把核心功能做对了。
- 每发现一个 bug，就补一个测试：不要修完就完事，把这个场景固化成测试用例，防止 AI 下次改代码又改回来。
- 每次重构前，先加测试：如果你要让 AI 重构某个模块，先确保重构前有足够的测试保护。
- AI 自己写测试：不要自己手写所有测试——让 AI 同步生成测试代码，你只审查测试用例是否合理。这是 SDD 的标准实践：规格 → 测试 → 实现。
问题收敛曲线
一个健康的 Vibe Coding 项目，bug 数量应该呈现收敛趋势：
- 初期：bug 快速出现又快速修复，因为 AI 生成的第一版代码问题很多，但修得也快。
- 中期：新增 bug 逐渐减少，主要是边界场景和异常处理的问题。
- 后期：bug 趋于稳定，每次修改引入新问题的概率被测试网兜住。
如果发现 bug 越改越多、永远收敛不了，通常说明两个问题：要么输入需求太模糊（L1 级别却想做生产级），要么测试覆盖太差（黑盒模式却没有足够测试兜底）。
五、实践建议：怎么选适合你的模式？
1. 按项目阶段选择
| 项目阶段 | 推荐模式 | 理由 |
|---|---|---|
| 0-1 原型验证 | L1 + 黑盒 | 速度优先，快速验证想法是否可行 |
| MVP 开发 | L2 + 灰盒 | 开始注重质量，但仍要保持迭代速度 |
| 正式上线 | L3 + 灰盒 | 架构定型，用测试和边界审查保障质量 |
| 稳定运营 | L3/L4 + 灰盒/白盒 | 核心模块逐步白盒化，非核心保持灰盒 |
2. 按模块风险等级选择
- 高风险模块（支付、登录、权限）：L3/L4 + 白盒，宁可慢一点也要稳。
- 中风险模块（普通业务逻辑）：L3 + 灰盒，效率质量平衡。
- 低风险模块（后台配置、展示页面）：L2 + 黑盒/灰盒，怎么快怎么来。
3. 团队落地的三个建议
第一，不要一步到位。
先从低风险模块试点 L2+灰盒模式，跑通流程、积累经验后再逐步推广。不要上来就全团队推行纯黑盒开发，大概率会翻车。
第二，建立统一的规格模板。
哪怕是 L2 级别，也应该有标准的需求描述模板：功能描述、输入输出、异常场景、验收标准。模板越统一，AI 输出越稳定，团队协作成本越低。这就是 SDD 的最小实践版本。
第三，把 CI/CD 管道建扎实。
自动化测试、代码规范检查、安全扫描、依赖检查……这些基础设施越完善，你就越敢放开让 AI 写代码。黑盒模式不是不管代码质量，而是把质量检查下沉到了自动化工具里。
六、结语
Vibe Coding 不是「让 AI 替你写代码」这么简单。它本质上是人机分工的重新定义——人往上游走，负责意图、架构、判断和验收；AI 往下游走，负责实现、编码、调试和重复劳动。
两个维度的划分，本质上是在回答两个问题：
- 输入端：你愿意花多少成本把意图说清楚？
- 输出端：你愿意花多少成本为代码质量负责？
没有绝对正确的答案，只有适合当前场景的选择。但无论怎么选，请记住一件事：测试是 Vibe Coding 的底线。迭代可以快，风格可以野，但安全网必须织牢。
毕竟，氛围可以轻松，交付不能儿戏。