Vibe Coding 工程化实践

本文只介绍思想，尽量避免涉及具体工具的选型与使用

先说本质

Vibe Coding 不是"用 AI 写代码"，而是人与 AI 的工程协作。

角色分工要清楚：人负责意图、约束、取舍、验收；AI 负责实现、草案、局部重构、体力活。不能模糊边界，最常见的翻车方式就是把本该人负责的架构决策也扔给了 AI。

要承认一个事实：AI 可以给架构方案，但没法为你的隐含权衡负责。它不知道哪些是红线，哪些是"现在不做"，哪些是"宁可慢也不能错"。

所以 Vibe Coding 不适合所有场景。强安全、强合规、强审计的系统不适合；极端性能敏感、没有回旋余地的核心链路不适合；需求高度不确定、短期内无法形成验收标准的项目也不适合。这些场景下 AI 只能做局部辅助，不能当主力。

为什么可维护性变得更重要了

传统工程里，可维护性主要是给人服务的。在 Vibe Coding 场景下，它同样是给 AI 服务的------甚至更重要。

原因很简单：AI 没有你脑子里的隐含上下文。

这带来一个根本变化：代码不只要能跑，还必须能被快速理解、修改、验证。

很多 Vibe Coding 翻车案例，本质不是 AI 写错了代码，而是约束是隐式的、设计是模糊的、验收是事后的、边界是靠默契维持的。AI 对这些东西一概没有感知能力。

一个工程闭环

与其把 Vibe Coding 总结成几条原则，不如把它看成一个闭环：

约束显式化
设计先行
小步实现
验证与门禁
上线反馈与回滚
沉淀为项目记忆，进入下一轮

下面四个部分，是这个闭环里最容易被忽略、也最关键的环节。

一、规范先行

动手写代码之前，先把这些定下来：

命名怎么约定
目录和模块怎么组织
错误怎么表达、怎么传播
日志、指标、敏感信息的边界在哪
哪些依赖方向是禁止的

这些规范不只给人看，更是给 AI 的操作约束。没有约束，AI 就会自由发挥，你会得到风格、结构、假设都不一致的代码。

有个容易忽略的判断标准：好的规范应该尽量可被自动校验。如果只能靠人记、靠人提醒，在 AI 参与的情况下，偏离只是时间问题。

这一步应该产出：命名与目录规则、错误处理约定、日志与安全边界、分层与依赖方向说明、不可违反的红线清单。

二、设计驱动

很多人用 Vibe Coding 是想跳过设计直接出结果。这恰恰是最容易翻车的地方。

典型翻车路径：

模糊想法 → 直接让 AI 写 → 发现不对 → 反复改 → 局部合理但整体失控

应该这么做：

模糊想法 → 让 AI 先出设计 → 人过一遍 → 明确取舍 → 再写代码

设计不用多正式，但几个维度要想清楚：架构上模块怎么划、层次怎么组织；接口上输入输出是什么、契约怎么定；数据上存什么、存哪、一致性怎么保证；流程上状态怎么流转、关键路径是什么；异常上失败了怎么办、降级策略是什么。

有个重要补充：设计里要显式写出假设、不确定性和非目标。否则 AI 会自动帮你"补全世界"。建议明确写出：assumptions（基于什么前提）、open questions（什么还没确认）、non-goals（当前明确不做什么）、risks（性能、一致性、安全、并发风险）。

这一步应该产出：一页设计说明、接口契约定义、状态流转或时序说明、风险与非目标清单。

三、测试保障

以前人写代码，逻辑在自己脑子里，测试是验证工具。现在 AI 写代码，逻辑在 AI 那边，测试成了你唯一能确认"它理解对了"的手段。

所以在 Vibe Coding 场景下，测试的重要性不降反升。既然代码都让 AI 写了，测试这步就不能省。最好是测试驱动，至少也要测试先行。测试代码必须人工审查。

有个坑：AI 倾向于写"能通过的测试"而不是"能发现问题的测试"。审测试的时候关注点不是跑没跑过，而是边界值有没有覆盖、空值和异常路径存不存在、并发和资源耗尽有没有考虑、验证的是不变量还是实现细节。

还要明确一点：安全性、性能、资源使用这些问题，往往靠单元测试兜不住。它们必须进工程门禁，不能留在"以后再说"。

这一步应该产出：验收用例与反用例、边界条件清单、回归测试集、性能和安全的最低保障线。

四、细粒度拆分

原则很简单：拆得细，但边界要干净。

理想状态是每个模块都能独立替换、重构，不需要靠"提前设计未来"来维持扩展性。

以前细粒度拆分意味着更高的维护成本。现在情况反过来了：拆得细，AI 修改时更准；耦合在一起，AI 一改就牵一发动全身。

例子：

java 复制代码

// 耦合写法
double total = quantity * price * 0.9;

// 恰好够用的抽象
double total = calculateDiscount(quantity * price);

// 过度设计（策略模式）
DiscountStrategy strategy = DiscountStrategyFactory.create(type);
double total = strategy.apply(quantity * price);

目标不是设计模式齐全，而是变化隔离：变化频繁的放边缘，稳定规则放核心，高层不依赖具体实现。

要防一手：AI 很容易为了"显得专业"而过度设计。必须通过明确的约束提前制止。

这一步应该产出：模块边界说明、依赖方向图、变化隔离点、禁止耦合列表。

上下文管理：从对话记忆到项目记忆

AI 的上下文是有限的。即便支持长上下文，注意力漂移和成本问题依然存在。

解决方案不是"聊更久"，而是沉淀稳定的项目记忆。

实践上：关键文件要自描述（职责、边界、依赖）；会话开始时主动提供关键上下文；控制单次会话的范围；把关键信息固化成项目记忆。

项目记忆应该包含：项目概览与架构说明、不可违背的约束与红线、常见范式与模板、历史决策与踩坑记录。

有个硬性要求：规范或架构变更时，必须同步更新项目记忆。

成熟度矩阵

当然，并不是说所有规模的项目都得遵循以上所有的要求，这里就不同场景下应该遵循哪些原则给出我的建议：

原则	个人脚本	小团队 (1-3人)	中型团队 (4-15人)	大型团队
		个人/团队行为	个人/团队行为	个人/团队行为
命名与目录规范	建议	必须 / 必须	必须+门禁 / 必须+门禁	自动校验 / 自动校验
红线清单	---	建议 / 必须	必须 / 必须+门禁	必须+门禁 / 必须+门禁
设计先行	建议	必须 / 必须	必须+评审 / 必须+评审	必须+评审+存档 / 必须+评审+存档
接口契约定义	---	建议 / 必须	必须 / 必须+版本管理	必须+版本管理 / 必须+版本管理
测试覆盖	关键路径	关键路径+边界 / 关键路径+边界	分层测试 / 分层测试+门禁	分层+门禁+基准 / 分层+门禁+基准
安全/性能门禁	---	--- / 建议	建议 / 必须	必须 / 必须+审计
模块边界说明	---	建议 / 必须	必须 / 必须	必须+依赖方向强约束 / 必须+依赖方向强约束
项目记忆维护	---	建议 / 建议	建议 / 必须+制度化	必须+制度化 / 必须+制度化+审计
AI协作流程本身的规范	---	--- / ---	--- / 建议	建议 / 必须+审计

说明：

"---" 表示该场景下通常不需要
"建议" 表示有了更好，没有也能接受
"必须" 表示不做会埋坑
"+门禁" 表示需要自动化校验拦截
"+审计" 表示需要可追溯
"个人行为" 指团队里只有个别人用 Vibe Coding
"团队行为" 指 Vibe Coding 是团队的标准实践

小结

Vibe Coding 不是把模糊想法交给 AI 去猜，而是通过工程化手段让协作成本可控。

核心不在于 AI 写了多少代码，而在于：约束是否显式、设计是否先行、验证是否可靠、边界是否清晰、反馈是否形成闭环。

最终目的就一个：让代码对人和 AI 都好理解、好修改、好验证。

Vibe Coding 能放大工程能力，也会放大工程缺陷。