Vibe Coding 二维方法论：从「凭感觉写代码」到工程化交付

本文首发于我的个人技术站点 mbse.ltd，原文链接：Vibe Coding 二维方法论：从「凭感觉写代码」到工程化交付。站点内还有 AI 编程、MBSE 工程化的系列深度文章，欢迎前往交流。

Vibe Coding（氛围编程）从概念火遍开发圈到真正落地实践，只用了不到一年时间。很多人对它的印象停留在「跟 AI 聊聊天就能写出代码」，但真正在项目里跑过一轮的人都明白：vibe coding 从来不是一种单一的开发方式，而是一个连续谱。

不同的项目阶段、团队成熟度、风险容忍度，对应着完全不同的人机协作模式。粗暴地用「纯 AI 写代码」或「人工逐行审查」二元对立来讨论，既不科学也不实用。

本文从两个核心维度拆解 Vibe Coding 的完整方法论，帮你找到适合自己项目的协作节奏。这也是我在站点系列文章里提到的——从 Vibe Coding 走向 Agentic 工作流的核心基础。

一、第一个维度：输入把控的四个层级——从「说个大概」到「精确制导」

对 AI 的输入控制到什么程度，决定了 AI 的发挥空间，也决定了最终结果的可控性。这个维度背后有一套完整的理论支撑——Spec-Driven Development（规格驱动开发，SDD）。SDD 的核心思想是：规格是唯一可信源，代码只是规格的执行产物。在 AI 编程时代，输入的清晰度直接决定了输出的质量。

我们把输入把控程度由低到高分为四级：

层级对比表

把控层级	输入内容	AI 发挥空间	适用场景	典型指令
L1 灵感级模糊需求	只给大致方向和功能描述，细节完全由 AI 脑补	极大	原型验证、周末项目、创意探索	"帮我做一个待办清单应用，好看一点"
L2 需求级完整需求	明确功能点、用户故事、验收标准，但不限制实现方式	中等	中小功能、业务逻辑不复杂的模块	"实现用户注册登录，支持手机号+验证码，注册成功后跳转首页"
L3 框架级需求+技术框架	完整需求 + 技术选型、架构分层、接口定义，具体实现由 AI 完成	较小	生产级功能、需要融入现有系统的模块	"基于 Spring Boot + MySQL 实现用户模块，Controller/Service/Repository 三层架构，接口遵循 RESTful 规范"
L4 精确级需求+详细方案	完整需求 + 详细技术设计 + 数据结构 + 算法思路 + 异常处理策略	极小	核心业务链路、高风险模块、性能敏感代码	"按以下接口文档实现支付回调：请求字段定义见附录，签名校验算法为 HMAC-SHA256，异常分三类处理……"

为什么不是越精确越好？

很多人会直觉地认为「L4 肯定最好」，但实际上每个层级都有其代价：

L1 速度最快，但返工率最高。AI 生成的东西大概率不是你想要的，需要多轮修正。它的价值在于「快速看到一个东西」，用来验证想法是否值得继续投入。
L4 质量最稳，但前期成本最高。你需要花大量时间写详细规格，某种程度上相当于把「写代码的时间」换成了「写文档的时间」。它的价值在于确定性——你知道 AI 不会跑偏。
L2、L3 是大多数项目的甜蜜点。既保留了 AI 的创造力和效率优势，又把核心风险控制住了。

SDD 视角下的洞见：当 AI 写代码的边际成本趋近于零时，「明确表达想要什么」就成了最稀缺的能力。规格越清晰，AI 的价值释放越充分；规格越模糊，AI 越容易生成「看起来正确但其实不对」的代码。

二、第二个维度：输出审查的三种模式——白盒、灰盒、黑盒

第二个维度是：AI 输出代码后，你看到什么程度才放行？这对应着三种不同的「代码透明度」策略。

三种审查模式详解

1. 黑盒开发（Black-Box）

核心逻辑：不看代码，只看结果。测试通过就上线。
审查方式：完全依赖自动化测试、功能验收、接口联调。
优势：速度极快，人力投入最少，真正实现「忘记代码的存在」。
风险：隐藏的技术债、安全漏洞、性能问题会持续累积，某天集中爆发。
适用场景：内部工具、原型项目、一次性脚本、低价值页面。

2. 灰盒开发（Gray-Box）

核心逻辑：不纠结每一行代码，但要管住架构和边界。
审查方式：重点看模块划分是否合理、接口定义是否一致、依赖引入是否可控、数据结构是否符合设计。具体的函数内部实现不深究。
优势：在效率和质量之间取得平衡，既利用 AI 的编码速度，又防止架构腐烂。
风险：局部逻辑可能有瑕疵，但不影响整体走向。
适用场景：大多数业务功能、非核心模块、已有成熟架构的系统迭代。

3. 白盒开发（White-Box）

核心逻辑：逐行审查，对每一行代码负责。
审查方式：完整阅读 diff，检查逻辑正确性、边界处理、异常捕获、代码规范、安全隐患、性能隐患。
优势：质量最高，技术债最少，出问题概率最低。
风险：耗时，某种程度上失去了 AI 提效的意义。
适用场景：核心交易链路、支付/鉴权等安全敏感模块、底层基础设施、开源公共组件。

三种模式的审查重点对比

审查维度	黑盒模式	灰盒模式	白盒模式
功能正确性	✅ 测试验证	✅ 测试验证	✅ 测试验证
架构合理性	❌ 不关注	✅ 重点关注	✅ 关注
接口契约	❌ 不直接看	✅ 重点关注	✅ 关注
代码逻辑细节	❌ 不看	❌ 不深究	✅ 逐行检查
边界与异常处理	❌ 靠测试覆盖	⚠️ 抽查关键路径	✅ 全面检查
安全漏洞	❌ 靠黑盒扫描	⚠️ 检查依赖与入口	✅ 人工审计
代码风格与规范	❌ 不关注	❌ 不关注	✅ 严格要求

三、二维矩阵：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 生成/修改代码 → 运行自动化测试 → 通过？
                          ↑                    ↓
                          └──── 反馈问题 ────── 否
                                         
是 → 提交/上线

这个循环能够成立的前提，是测试足够可靠。如果测试覆盖不全，AI 每一轮修改都可能引入新的 bug，你永远不知道哪次改完就偷偷埋了雷。

传统开发中，代码是人写的，写的人心里有数；Vibe Coding 中，代码是 AI 改的，每一轮改动你都无法完全预判影响范围。测试就是你的安全网。

测试覆盖率的迭代演进

好的 Vibe Coding 项目，测试覆盖率是随着迭代逐步上升的，而不是一开始就追求 100%。

迭代 1 · 原型阶段：只覆盖核心路径（Happy Path），保证主流程能跑通
迭代 2 · 功能完善：覆盖主要分支 + 异常场景
迭代 3 · 稳定运行：补充边界值 + 回归测试
迭代 4 · 生产级：全量覆盖 + 性能测试

具体落地策略：

第一轮先写 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 的底线。迭代可以快，风格可以野，但安全网必须织牢。

毕竟，氛围可以轻松，交付不能儿戏。

以上就是我这段时间实践 Vibe Coding 沉淀的完整方法论。这套框架还在持续迭代，后续我会在 mbse.ltd 更新从 Vibe Coding 演进到 Agentic 工作流的完整路径，以及更多 MBSE + AI 工程化的落地实操案例。

欢迎访问我的个人站点查看更多内容：https://mbse.ltd