AI for Coding：如何构建基于 SDD 的多人协作流水线？

大家好，我是 Jie。

故事要从 2023 年说起。那时Github Copilot 刚火，正好公司来了一个紧急需求：打通人事系统与财务报销流程------当时公司每天出差的人数不下 20 人，最折磨人的是一个出差单要在两个系统里分别提交，领导也得审批两次，流程非常繁琐，大家怨气都很大。

原本这种活儿，对着文档手搓实体类怎么也得半天。我当时就想，既然这工具宣传得这么神，我是不是直接把接口文档"喂"给它就行？结果我把文档一复制，它还真就在几分钟内把 Java 实体类和接口工具类全生成了。

紧接着写业务逻辑，那是我第一次真正体验到什么叫"无限回车"------真的是 CV 大法 + Enter 的节奏，整个核心模块大概只花了一个小时。当然，实话实说，当时生成的代码虽然快，但也没少埋坑，后面因为 JSON 解析和其他逻辑 Bug，我也修修补补搞了半天。但即便如此，这种开发方式的冲击力依然巨大。

这种震撼驱使我在随后的两年里（2024-2025），把 Cursor、Claude Code、v0、Trae、Antigravity 这些主流工具试了个遍，也带着同事一起用，全公司基本都进入了 Vibe Coding（氛围编程） 的状态，吃饭的话题从吐槽公司也变成了Cursor真牛逼，这不是以后ai躺着干活了。

但到了 2025 年底，情况变了。当我们开始着手构建一个更复杂的可视化开发平台时，我发现单纯靠"直觉"和"补全"不够用了。首先是业务层面的教训，这个平台之前已经失败过两次了，老板这次下了死命令：必须彻底吃透需求，先输出详尽的文档，严禁上来就盲目写代码。其次是其他项目暴露的问题：团队里每个人的提示词（Prompt）习惯不同，对需求的把控能力也参差不齐，这就导致上下文经常对不齐，生成的代码风格割裂严重。再加上 AI 的幻觉防不胜防，项目的维护成本直线上升。

于是，我开始研究 Spec-Kit，尝试结合 Cursor 落地 SDD（规范驱动开发）。从单兵作战爽快的"无限回车"，到团队协作严谨的"规范驱动"，今天我想和大家实实在在地聊聊这一路走来的踩坑经验和方法论。

一、为什么 Vibe Coding 在团队中失效了？

在单兵作战时，Context（上下文）在你脑子里，也在 AI 的短期记忆里。但在多人协作开发复杂系统（如我们正在做的可视化平台）时，Vibe Coding 面临着严重的"熵增危机"。

1.1 上下文漂移 (Context Drift)

这是团队协作的头号杀手。

现象：我告诉 AI "使用 React Hooks 风格"，同事告诉 AI "追求极致渲染性能"。
结果：同一个组件库里，代码风格精神分裂。
本质：AI 是基于概率的。没有统一的"系统提示词（System Prompt）"作为锚点，概率分布就会随着人的主观意志漂移。

1.2 幻觉的传播 (Hallucination Propagation)

一个人产生的 AI 幻觉（例如引用了一个不存在的内部库方法），如果是手写代码，Code Review 很容易发现。但如果是 AI 生成的几百行代码，Reviewer 往往会因为"看着像那么回事"而漏过。一旦这行代码合入主干，它就成为了"真理"，随后的 AI 会基于这个错误继续通过 RAG 产生更多的错误代码。

二、破局之道：SDD (规范驱动开发)

为了解决上述问题，我们在 2025 年底引入了 SDD-Enterprise (企业级规范驱动开发)。其核心理念是：文档（Spec）不仅是需求，更是团队协作的唯一"握手协议"。

在传统的开发模式下，我们习惯靠开会、靠口头沟通来对齐认知。但在 AI 介入的开发模式下，这些隐性知识必须被显性化、文本化、结构化。道理很简单：AI 听不懂我们会议室里的录音，也猜不透我们脑子里的潜台词，它只读得懂结构清晰的 Markdown。

这一次，面对这个已经失败过两次的"可视化平台"，我们没有急着写一行代码。我们按下了暂停键，足足花了一个月的时间进行深度的需求分析和顶层设计。

在这一个月里，我们把 Gemini 3 和 Grok 变成了我们的"产品顾问"和"架构参谋"。利用它们强大的推理能力，我们对市面上的竞品进行了地毯式的分析，对比优劣，博采众长。

最终，我们将这一个月的思考沉淀为一套完整的文档体系。下面这幅图，就是我们当时总结出的一个成功的商业化产品所必须具备的文档全景图：

核心原则

Single Source of Truth (唯一事实来源)：Spec 文档是最高准则。如果代码和 Spec 不一致，改代码；如果 Spec 不合理，改 Spec 并在团队内同步。
Context Engineering (上下文工程) ：我们开始维护项目的 .cursorrules，确保所有人的 AI 助手"大脑构造"是一致的。
Atomic Verification (原子化验证)：AI 写的每一段代码，必须附带 AI 写的测试用例。

三、角色重塑：AI 时代的组织架构

AI 不会取代人，但会重新分配人的认知负荷。在落地可视化开发平台的过程中，我们重新定义了团队角色。

3.1 老板：从"许愿池"到"战略守门员"

以前老板的角色更像是"许愿"，今天说"要个大屏"，明天说"加个按钮"。但在经历了两次项目失败后，他现在的职责非常明确：管住"随意变更"的手，守住业务价值的门。他不再干涉具体的 UI 细节，而是参与到前期的 Spec 评审中，确保我们花一个月梳理出来的业务流程图真正符合商业逻辑。一旦文档定稿，他也必须尊重规范，不再随意进行"一句话需求"的干扰。让老板参与好处就是老板懂客户，更能站在市场的角度考虑问题。

3.2 产品经理：逻辑边界的定义者

纯文字需求是 AI 产生幻觉的温床，所以我们强制要求 PM 必须转型。一是"图纸化"：必须提供 Mermaid 流程图或原型，用可视化手段纠正 AI 的逻辑偏差。二是"标准前置"：验收标准（User Stories）必须在开发前就死磕出来。因为这些标准后面会直接喂给 AI 生成自动化测试代码，标准如果不准，跑出来的代码绝对是歪的。

3.3 架构师（我）：上下文工程师 (Context Engineer)

我现在的核心工作不再是盯着具体的业务代码，而是维护项目的"数字宪法"。首先是定义宪法：确保所有人用的 AI 遵守同一套技术规范和代码风格，防止"上下文漂移"。其次是"熔断机制"：在开发写代码前，我会强制审查 AI 生成的"实施计划（Plan）"。如果 AI 拆解的任务逻辑有漏洞，在这里直接驳回，绝不允许带着隐患开工。

3.4 开发人员：领航员与审查者

我们的目标是100%代码给AI去写，大家的身份从"写手"变成了"领航员"，80% 的时间都在 Review AI 的产出。我们现在严格执行 TDD（测试驱动开发）：先让 AI 根据 Spec 写出测试用例（此时是红灯），再让 AI 写业务代码把测试跑通（变绿灯）。只有测试全绿，任务才算真正交付。说白了，以前是自己写代码自己测，现在是让 AI 写代码，我们来制定考试题。

四、实战流水线：我们是如何做可视化平台的？

为了驾驭这个复杂的项目，我们建立了一套标准化的 SDD（规范驱动开发）工业级流水线。

这套工具链的组合非常有讲究，模拟了一个完整的研发团队配置：

Gemini 3 Pro (大脑) ：负责顶层设计与逻辑推理，它充当 CTO + 产品总监。
Spec-Kit (律法) ：负责将模糊意图转化为可执行的规范，它充当 项目经理 + 质量把控。
v0 (门面) ：负责 UI/UX 的具象化生成，它充当 UI 设计师。
Cursor (手脚) ：负责最终的代码落地与测试，它充当 资深全栈工程师。

在 SDD 模式下，第一步绝对不是写代码，而是"谋定后动"。我们将整个开发过程重构为：立法 -> 具象 -> 规划 -> 执行。

4.1 团队协作协议 (The Team Protocol)

请死记这个循环。这是我们团队从"口头扯皮"进化到"文档驱动"的关键。

步骤	命令 (Spec-Kit)	主责角色	协作动作 (Handshake)
0. 初始化	`specify init`	架构师	确立基础设施，全员拉取最新配置。
1. 立宪	`/speckit.constitution`	架构师	全员同步：制定不可违背的代码规范（如：禁止 Any，逻辑与 UI 分离）。
2. 需求	`/speckit.specify`	PM + Dev	需求评审：PM 提供 v0 图和 Gemini 生成的 User Story，Dev 转化为 Spec 文档。
3. 计划	`/speckit.plan`	Tech Lead	计划审查 (关键) ：在写代码前，Lead 必须审查 AI 生成的技术方案。Plan 不通过，禁止开工。
4. 任务	`/speckit.tasks`	Dev	任务拆解：AI 自动将 Plan 拆解为原子任务列表。
5. 执行	`/speckit.implement`	Dev	闭环执行：Dev 在独立分支执行，Cursor 自动生成代码并跑通测试。
6. 验收	`PR Review`	Reviewer	一致性检查：Reviewer 对比 Spec 和代码，而非纠结语法细节。

4.2 步骤一：借脑与具象 (PM + Gemini 3 + v0)

在协作开始前，必须消除"语言歧义"。

PM 针对需求，先用 v0.dev 生成 UI 原型。一张图胜过千言万语，这直接消除了开发和产品之间 50% 的误解。Gemini 3 推理：利用推理能力最强的 Gemini 3 Pro 扮演 CTO，生成 Spec-Kit 的初始指令。

复制这段 Prompt 给 Gemini 3：

Prompt (发给 Gemini 3):

你是一个十年经验的 CTO。我们需要开发 [项目名称] 的 [功能模块]。附件是需求文档和 v0 生成的原型图。

请按照 GitHub Spec-Kit 模式，为团队生成协作指令：

/speckit.specify: 描述功能边界，引用附件中的 UI 结构。

/speckit.plan: 制定技术实施计划，明确与现有架构的兼容性。

4.3 步骤二：立宪与分支 (架构师 + Git)

打开 Cursor Composer (Agent 模式)，输入 Gemini 3 生成的第一条指令。

这一步相当于为 AI 立法。很多团队用 AI 写代码容易"跑偏"，一会儿用 TypeScript 一会儿用 JS，就是因为没有"宪法"。

复制代码

/speckit.constitution

(在此处粘贴 Gemini 3 生成的宪法内容，例如：
1. All UI components must be purely functional and styled via Tailwind.
2. Business logic must be isolated in `packages/kernel` with 100% test coverage.
...)

4.4 步骤三：计划审查 (The Handshake)

这是多人协作中最关键的一步。

在传统开发中，Lead 往往在代码写完后才发现方向错了。在 SDD 中，我们在 Plan 阶段就拦截风险。

1. 生成计划 ：张三输入 /speckit.plan，AI 根据需求生成技术方案（如：使用 React DnD 库）。

2. 人工审查：

架构师介入：张三把 Plan 发给架构师（或在 PR 中提交 Plan 文档）。
驳回："架构师发现 React DnD 与当前 Leafer 引擎冲突，建议改为手动计算坐标。"
修正：张三使用 /speckit.clarify 修正 AI 的认知，重新生成 Plan。

3. 锁定 ：Plan 通过后，才允许进入下一步。这一步省去了 80% 的返工时间。

4.5 步骤四：原子执行与合并 (Dev + Cursor)

任务拆解 ：输入 /speckit.tasks。Cursor 生成 tasks.md。
自动化执行 ：输入 /speckit.implement。

Cursor 会自动读取 tasks.md，按顺序编写代码，因为大家都遵守同一套 Constitution，张三生成的代码和李四生成的代码，风格就像同一个人写的，极大地降低了 Merge Conflict（合并冲突）的概率。
提交 PR：

提交时，PR 中不仅包含代码，还包含自动生成的 spec.md 和 plan.md。

Reviewer 的工作变得很简单："AI 是否忠实执行了我们批准的 Plan？"

4.6 循环迭代 (The Loop)

当核心引擎开发完成后，如果李四要并行开发"属性面板"功能：

李四切分支 feat/properties-panel。
李四重复：v0 出图 -> Gemini 出 Plan -> 架构师审查 Plan -> Cursor 执行。
由于双方都基于同一套 Spec 规范，最后的合并就像搭积木一样顺畅。

五、写在最后

从 2023 年那个让我惊叹"CV 大法"的下午，到今天我们在一个复杂的项目落地SDD开发，我最大的感触是：

AI 编程的尽头，不是更快的打字速度，而是更清晰的逻辑表达。

Vibe Coding 依然很爽，写个脚本、做个 Demo 绰绰有余，能够让我们的创意快速实现，但是要让AI听话目前最好的办法就是文档驱动+人工审核。

AI 不会取代程序员，是让我们能够站在架构师的角度去设计一个功能，纵观全局，协调人和AI，那么就限制开始学习SDD开发吧。

希望我的这段"踩坑"与"填坑"的经历，能给正在探索 AI 协作的你们一点启发。别急着让 Cursor 狂奔，先停下来，把 Spec 写好。