「后编码时代」续篇。
前面的 4 篇讲清楚了决策怎么记、怎么传。这篇回答一个被跳过的问题：记下来的决策怎么变成可执行的东西，执行完怎么验证？以及最重要的——出了偏差怎么办？

---

Vibe Coding 很爽，但只解决了一个人的问题

一个人用 Cursor 或 Claude Code 写代码，确实起飞。你说需求，AI 写代码，你 review，改改就行。效率可以是以前的 3-5 倍。

但这个效率提升停在了一个边界上：你的工位。

张三用 Claude Code 写了模块 A，李四用 Cursor 写了模块 B——谁保证 A 和 B 的设计是一致的？谁记得上周为什么选了方案 C？AI 不知道隔壁工位在做什么。

Vibe Coding 解决了"写代码"的速度问题。但团队协作的瓶颈从来不是写代码的速度——前面几篇已经说清楚了：瓶颈是做决策和传决策。

所以什么是"团队 Vibe Coding"？

一个人 Vibe Coding：你对 AI 说需求，AI 写代码，你说改哪，AI 改了。

团队 Vibe Coding：一群人先聊清楚要什么，写成一份 AI 能直接跑的 spec，然后让 AI 执行，人 review 结果，发现 gap 就关。

核心区别不是"谁来写代码"——反正都是 AI 写。核心区别是 spec 怎么来，出了 gap 怎么处理。

个人 vibe coding 的 spec 在一个人的脑子里，边做边改，gap 只有自己知道。团队 vibe coding 的 spec 是集体讨论的产出——它不是需求文档，不是 PRD，是团队和 AI 之间的契约。而 gap 是这个契约和现实之间的距离。

一个具体的场景

5 人团队要给后台加一个操作审计日志。

第一步：集体讨论 spec。

不是开会念 PRD。是所有人围着同一个问题，把"要做什么"聊到 AI 可执行的程度。产品经理说清楚哪些操作需要审计（登录、数据导出、权限变更），后端说清楚存储方案和查询性能要求，前端说清楚审计日志的筛选和展示逻辑。AI 在旁边听着，实时把讨论结果结构化——不是会后补会议纪要，是讨论过程中 spec 就在成形。

这个环节看起来像需求评审，但有一个根本区别：产出不是给人看的文档，是给 AI 执行的指令。 所以它必须精确——模糊的 spec 无法被验证，也产生不了有意义的 gap。

第二步：AI 根据 spec 生成代码。

因为 spec 是精确的、可验证的，AI 的执行有了明确的目标。不是"加一个审计日志"这种模糊指令，而是"记录以下 3 类操作，每条记录包含操作人、时间、操作类型、影响范围，存入 audit_logs 表，保留 90 天，提供按操作人和时间范围的查询接口"。

第三步：工程师 review + 自动化测试。

AI 生成的代码到了 review 环节。但 review 的重心变了——传统 review 是看"这行代码对不对"，现在重点是"这和 spec 一样不一样"。

自动化测试在这里扮演关键角色：如果 spec 足够精确，测试用例可以直接从 spec 中生成。测试通过 = spec 被满足。测试失败 = 存在 gap。测试是自动化的 gap 检测器，不依赖人的主观判断。

第四步：处理 gap。

Gap 出现了。三种可能：

• 代码的问题。 AI 没按 spec 写，比如漏掉了权限变更的记录——改一下就行。最常见的。
• 结构的问题。 AI 写了，但发现 spec 和现有架构冲突——比如审计日志写入了主库导致性能问题，需要调整为异步写入。
• Spec 的问题。 AI 完全按照 spec 写了，但做出来发现不对——比如 spec 没考虑批量操作的场景，一次导出 1000 条记录应该记一条日志还是 1000 条。是 spec 本身有盲区。

第三种情况最值得注意。Spec 是团队的共识，但不是圣旨。做出来发现不对，说明共识有盲区。这时候不是偷偷改了继续做，而是回到团队：spec 哪里有问题，怎么改，改完重新确认。Spec 的修改本身就是一个新的决策事件，被记录、被追溯。

第五步：验收。 测试通过，gap 关闭，交付。

Gap 是什么？

整个流程里反复出现一个东西：spec 描述的状态和实际产出之间的差距——gap。

需求变更、bug、review 反馈——在传统流程里它们走不同的处理路径。但在这个闭环里，它们是同一件事：spec 和现实之间的 gap。AI 没按 spec 来，是执行层的 gap。Spec 本身有盲区，是定义层的 gap。架构和 spec 冲突，是结构层的 gap。

不会出现"代码没错但不是我要的"这种含糊的情况——你要的东西在 spec 里。如果 spec 没写清楚，gap 指向 spec；如果 spec 写清楚了但代码没做到，gap 指向代码。

这个观察来自 GDD（Gap-Driven Development）方法论的探索。GDD 的核心洞察很简单：如果能持续地检测和关闭 gap，系统的质量会持续提升。 在个人开发场景下有用但有限。在团队场景下变得非常有价值——因为团队的 gap 不只是"AI 写错了"，还包括"团队没对齐"“spec 有盲区”“架构有冲突”。每一个 gap 都是一个信号。

反复出现的 gap 变成规范

同一个类型的 gap 出现一次，是个 bug。出现三次，是一个缺失的规范。

比如：团队连续三次发现 AI 生成的代码缺少错误处理。第一次补了，第二次又漏了，第三次还是漏。这说明问题不在 AI——是规范里没有明确"所有外部调用必须做错误处理"。

这时候要做的事很简单：写下来。

写在哪里？就是团队已经在用的地方：

• CLAUDE.md / .cursorrules —— agent 可读的约束
• Code review checklist —— review 时检查的项目
• ESLint / Prettier 规则 —— 能自动化的就自动化
• ADR（架构决策记录） —— 架构层面的约定

这不是什么新实践。团队一直在做这些事——code review 里的 comment、onboarding 时告诉新人的"我们团队的规矩"、README 里写的"注意事项"。区别只是：现在这些规范的来源从"老人的经验"变成了"反复出现的 gap"。

更重要的是，这些规范是 AI 可读的。写进 CLAUDE.md 的规则，AI 下一轮执行时就会遵守。团队的经验不再是只存在于人脑子里的隐性知识，而是变成了 agent 可执行的显式约束。

不是在发明新流程。是在已有的实践中加了一个闭环：发现 gap → 关闭 gap → 如果反复出现就沉淀为规范 → 规范减少未来的 gap。

现实的闭环

集体讨论 → 产出可验证的 Spec
    ↓
AI 根据 Spec 生成代码
    ↓
Review + 自动化测试 → 检测 Gap
    ↓
Gap 在代码 → 补丁 / 重构
Gap 在 Spec → 集体修改 Spec（记录为决策事件）
反复出现的 Gap → 沉淀为团队规范
    ↓
验收

每走一圈，团队积累两样东西：

1. 更精确的 spec——知道什么程度的精确度是够用的
2. 更完善的规范——从 gap 中沉淀出来的团队约定

这两样东西让下一轮更快、gap 更少。

谁先跑起来？

说实话：不是所有团队都能立刻用这个流程。

很多团队说自己在敏捷，实际上在做微瀑布——需求 → 开发 → 测试 → 上线，只是周期从三个月缩短到了两周。本质没变，节奏快了。这种团队很难适应"发现 spec 有问题就改"的节奏，因为他们的前提是"需求文档签了字就不能动"。

能先跑起来的团队有几个特征：

综合能力强。 团队里有人能做需求判断、有人能做架构决策、有人能抓质量。分工清晰，不缺角色。不需要全栈，但每个环节都有人能负责。

文化开放。 愿意改流程，愿意试新东西。改 spec 不等于打谁的脸，review 不是走形式。心理安全感够，"这个 spec 有问题"可以被公开说出来。

真正在实践敏捷宣言。 “响应变化高于遵循计划”——发现 spec 有问题就改，不把前期决策当圣旨。“个体和互动高于流程和工具”——集体讨论 spec 的质量高于按模板填文档。

好消息是：不需要改整个公司的软工体系。从一个团队开始就行。大公司里总有那么一两个团队是创新导向的、流程灵活的。让他们先跑，效果出来了，其他团队自然复制。

不需要一步到位。哪怕只做一件事——把集体讨论的产出写成 AI 可执行的 spec，而不是给人看的文档——闭环就已经开始了。剩下的，gap 会告诉你。

---