【AI Native开发-16】把 SDD 变成团队的 AI Native 研发系统

摘要

这是系列的收官篇。前面 15 篇讲的是一个人怎么用 SDD + AI 把软件做对。但一个人用得好，不等于一个团队用得起来。个人方法靠自觉，团队系统靠机制——这一篇讲怎么把散落的好习惯，固化成团队共享、可执行、可审计的研发系统。

核心论点：

团队规模化的本质，是把”靠人记得”变成”机制强制”。 个人靠每次记得”要写非目标""要核对副作用”；团队靠模板、CI 检查、强制审批，让不这么做就走不下去。
追踪链（REQ → TEST → 代码 → Verify）是系统的脊梁。 它把需求、计划、实现、测试、验证串成一条可审计的链，CI 可以自动检查它的完整性，而不是靠开会对齐。
系统必须能自我进化。 线上失败回写 Spec 和回归集、评审检查表随踩坑更新、pitfalls 沉淀给所有 AI 会话——系统越用越严密，而不是越用越僵化。
角色变了，但人的判断力更值钱了。 AI Native 研发的终点不是”不需要人”，而是人的判断被沉淀、复用、放大。

本篇给出团队落地的统一资产、CI 校验机制、测试集治理、风险分级审批、多 Agent 并行隔离、角色分工，以及四步引入路线，最后收束整个系列。

从个人习惯到团队系统：差在哪

一个人用 SDD，你可以记得：写 Spec 要带非目标、Plan 要写不碰清单、测试要断言副作用、失败要归因回写。因为上下文都在你脑子里。

团队里这一切会失效：

新人不知道项目的 Spec 长什么样、放哪里；
有人赶进度跳过 Plan 直接让 AI 改代码；
不同人写的 Spec 详略不一，AI 执行质量天差地别；
失败的教训留在个人脑子里，别人（和 AI）还在踩同一个坑；
多个 AI / 多个人并行改代码，互相覆盖、冲突不断。

差别就一句话：个人靠自觉，团队靠机制。 团队系统要做的，是把前 15 篇里”应该怎么做”的每一条，变成”不这么做就无法往下走”的硬约束或默认提供的基础设施。

第一块：统一资产，让正确做法成为最省事的做法

把所有产物标准化、模板化、纳入版本管理。AI 和人都从模板出发，而不是每次从零写。

团队共享资产库（Git 管理）：

/specs/
  article-delete.spec.md          # Spec 统一模板（第 04 篇十项结构）
  _template/spec.template.md
/plans/
  article-delete.plan.md          # Plan 统一模板（第 06 篇）
  _template/plan.template.md
/spikes/
  keystatic-delete-path.spike.md  # Spike 记录（第 05 篇）
/tests/
  text-cases/                     # 文本用例（第 10 篇，REQ→TEST 矩阵）
  automation/                     # 自动化代码（第 11 篇）
/verify/
  article-delete.verify.md        # Verify 报告（第 14 篇）
/docs/
  ARCHITECTURE.md                 # 架构说明
  pitfalls.md                     # 踩坑笔记（AI 每次必读）
  decisions/                      # 架构决策记录
  glossary.md                     # 业务术语表
/agents/
  AGENTS.md 或 CLAUDE.md          # AI 工作守则：命令、规范、禁区

关键原则：

模板即规范。Spec 模板里固定有”非目标""需求编号""验收标准”等节，不填就不完整——人不需要记得”要写非目标”，模板会替他记得；
AI 守则显式化。AGENTS.md 写清：测试命令、代码规范、禁止修改的路径、“失败先分类不许改测试压绿”等纪律，让每个 AI 会话开工前就加载；
所有资产进 Git。Spec、Plan、用例、Verify 报告都版本化，可追溯、可评审、可 diff。

第二块：CI 强制追踪完整性，让缺口藏不住

第 14 篇的需求追踪矩阵，在团队里不该靠人手工核对，而应由 CI 自动校验。这是把”靠开会对齐”变成”机器强制”的核心。

CI 校验项（不通过则阻断合入）：

1. 追踪链完整性
   - 每个 Spec 的 REQ 编号，都有至少一个 TEST 文本用例
   - 每个 TEST，都有自动化用例或显式的"仅人工验证"标注
   - Verify 报告里，每条 REQ 都有证据链接
   → 断链即失败：REQ 无 TEST、TEST 无代码、Verify 无证据

2. 变更范围控制（第 09 篇）
   - 实际 diff 文件 ⊆ Plan 声明的授权文件
   - 受保护路径（auth、核心加载器、package.json）改动需人工审批标记
   - 扫描：console.log / debugger / 幻觉 import / 调试残留

3. 质量门槛
   - 类型检查、lint、构建必须通过（静态站构建是独立必过项）
   - 测试全绿，且无"未解释的 skip"
   - flaky 用例不允许带 retry 混在主集（第 12 篇）

4. 模板完整性
   - Spec 包含非目标、验收标准等必填节
   - Plan 包含"不碰清单""回滚方案"
   - Verify 报告包含"未验证项""已知限制"

追踪链校验尤其重要。它让”这条需求有没有被测""这个测试对应哪个需求”不再是口头问题，而是 PR 上一个明确的红叉或绿勾。缺口在合入前就被机器拦住，而不是上线后被用户发现。

第三块：测试集治理与质量分层

团队的测试会不断增长，需要分类治理（第 13 篇的团队化）：

冒烟集（smoke）    个位数核心路径，每次部署自动跑
黄金集（golden）   关键业务 + P0 权限/资金/不可逆，每次合入跑
回归集（regression）全量，发布前跑；每个线上 bug 修复后补入新用例
flaky 隔离区       疑似 flaky 登记治理，显式 skip 留痕，禁止 retry 掩盖

治理规则：

线上缺陷必须转成回归用例（第 15 篇），且这条用例要进 CI 自动跑——这是测试集自我织密的机制；
flaky 有负责人和期限：登记、定位、修复或显式 skip，不允许无限期挂着；
定期审计测试有效性：抽查关键用例做空实现测试（第 11 篇），清掉陪跑测试——一个空实现也绿的测试是负资产；
度量用于团队自检，不用于个人考核（第 02 篇原则）：Gate 拒绝率、缺口发现阶段分布、逃逸缺陷数等，一旦和个人绩效挂钩，就会被优化成漂亮数字而失去意义。

第四块：风险分级与强制审批

不是所有变更都走同样重的流程。按第 09 篇的风险分级，团队设定差异化审批：

P0（权限/认证、不可逆操作、资金、数据迁移、核心共享模块）
  → 强制人工逐行评审 + 人工确认合入 + 完整 Verify 报告
  → AI 不得自动合入

P1（新业务功能、业务逻辑修改、状态流转）
  → 人审范围一致性 + 高风险逻辑 + 异常路径测试覆盖
  → Verify 矩阵闭合可合入

P2（文案、样式、文档、类型补充）
  → CI 全绿 + Diff 范围核对，可快速放行

风险由”改动中最危险的部分”决定，不由改动大小决定。这个分级写进 CI：动了 P0 路径却没有人工审批标记，自动阻断。

第五块：多 Agent / 多人并行的隔离

团队会让多个 AI 并行做不同任务（甚至多 Agent 同时开发），这带来冲突风险。隔离规则：

工作区隔离：
- 每个任务独立分支 / 独立工作区，不共享未提交改动
- Agent 只在自己的分支和授权文件范围内操作

文件所有权声明：
- 每个任务在 Plan 里声明"本任务拥有哪些文件"
- 两个任务声明了同一文件 → 串行或显式协调，不允许并行硬闯
- 核心共享文件（auth、loader、类型定义）默认无人可独占，改动走 P0 审批

Spec 冲突解决：
- 两个任务的 Spec 出现规则冲突（如对同一状态的不同处理）
  → 停下来由人裁决，回 Spec 层统一，不允许各自实现导致行为分裂

上下文一致性：
- 所有 Agent 读同一份 AGENTS.md / pitfalls.md / glossary
- 避免"每个 Agent 按自己的理解各写一套"

并行的前提是边界清晰。没有文件所有权和工作区隔离，多 Agent 并行只会把冲突和越界放大。

第六块：线上反馈闭环，让系统自我进化

团队系统和个人流程最大的不同：它要能随时间变强。闭环机制：

用户问题 / 线上缺陷
   ↓
归因（第 15 篇决策树：Spec / Plan / 实现 / 测试 / 环境）
   ↓
止血修复（Implement）
   ↓
回写四处：
  ① Spec 补/改规则（根因在需求）
  ② 回归集补用例（根因在漏测）→ 进 CI 永久守护
  ③ pitfalls.md / 评审检查表（根因在认知盲区）→ 所有 AI 下次必读
  ④ CI 规则（根因在机制漏洞）→ 机器自动拦截同类
   ↓
系统比事故发生前更严密

这是整个体系的飞轮：每一次失败都不只是被修复，而是转化成系统里一条新的防线。 线上出一次越权，CI 就多一条权限路径检查、回归集多一条用例、pitfalls 多一条笔记、Spec 权限规则更具体——同类错误第二次几乎不可能再溜过去。

团队角色的变化

AI Native 研发系统里，角色不是消失，而是重心转移：

产品 / 需求：
  从"写需求文档"转向"定义意图、规则、边界、验收"
  核心产出：可测的 Spec、明确的非目标、风险优先级

开发：
  从"逐行写代码"转向"审查方案、控制架构、裁决高风险变更"
  核心动作：Plan 评审、Diff 范围控制、P0 审批、失败归因裁决
  三件不可委托：判断测试是否充分、失败归因、发布决策（第 00 篇）

测试：
  从"执行用例"转向"设计测试体系、维护质量门槛、治理测试资产"
  核心产出：REQ→TEST 矩阵、分层测试集、flaky 治理、Verify 把关

AI：
  分析代码库、生成 Spec/Plan 初稿、实现代码、生成用例、
  执行测试、基于证据调试、汇总报告
  —— 所有"生成与执行"，但不做"最终判断"

人不再是主要的代码产出者，而是意图的定义者、边界的设定者、风险的裁决者、结果的负责者。AI 放大的是执行力，人保值的是判断力。

落地路线：四步引入，不要一步到位

团队不要试图一次性铺开全部。按第 02 篇”从 Verify 起步”的思路，分四步，每步都能独立见效：

第一步：先建证据能力（Verify 切入，改造成本最低、见效最快）
  - 统一测试命令和报告格式
  - 建立需求追踪矩阵（哪怕先手工）
  - 引入冒烟集
  → 让团队先有"什么算验证过"的共识。没有证据能力，闸门会退化成签字。

第二步：固化 Spec 和 Plan 模板
  - 提供 Spec / Plan 模板，必填节齐全
  - 建立 AGENTS.md / pitfalls.md
  - 推行 Plan 评审（Gate 2）
  → 让"做什么/怎么做"先书面化、可评审。

第三步：CI 强制化
  - 追踪链完整性校验
  - 变更范围控制、受保护路径审批
  - 质量门槛、flaky 治理
  → 把靠自觉的纪律变成机器强制。

第四步：闭环与规模化
  - 线上失败回写机制
  - 多 Agent 并行隔离
  - 测试集分层治理、度量自检
  → 系统开始自我进化，支撑更大规模。

刻意从 Verify 而非 Spec 起步的原因（第 02 篇已论证）：团队最先缺的往往不是”写 Spec 的意愿”，而是”判断对错的证据能力”。没有能自动证明行为的测试和追踪，Spec 写得再好，闸门也只能靠人签字，签着签着就成了橡皮图章。先让团队能”看见真相”，再逐步把上游管起来。

团队化反模式

反模式一：一步到位的流程革命。 第一天就要求所有人写完整 Spec + Plan + Verify + 全套 CI，团队不堪重负、集体绕过。对策：四步渐进，每步见效。

反模式二：度量挂钩个人绩效。 Gate 拒绝率、缺陷数一旦考核个人，就会被优化成假数字，质量判断崩塌。对策：度量只用于团队自检和流程改进。

反模式三：只建模板不建机制。 发一堆模板文档，但没有 CI 校验、没有强制评审，模板形同虚设。对策：关键纪律必须机器强制，不能只靠文档号召。

反模式四：系统僵化不进化。 模板、检查表、CI 规则定完就不改，踩了新坑也不更新。对策：失败回写是固定动作，系统随事故进化。

反模式五：把人完全排除在判断外。 追求”全自动合入""AI 自己发布”，在高风险场景失控。对策：P0 变更和发布决策永远有人，自动化的是执行和检查，不是裁决。

系列总结：回到最开始的那个问题

第 00 篇我们问：AI 能写代码了，新的核心问题是什么？答案是——不再是”怎么写”，而是”怎么描述意图、怎么约束边界、怎么证明它写对了”。

17 篇走完，这套方法可以收成一句话：

写清楚（Spec） → 规划好（Plan/Spike） → 小步做（Implement）
            → 有证据地验收（测试/Verify） → 把经验沉淀下来（回写/系统化）

认知篇（00–02）：AI Native 不是让 AI 写代码更快，而是重组”人定义意图、AI 执行、人用证据验收”的分工；生成提速会让审查队列堆积，所以核心命题是让审查成本不随生成量线性增长；SDD 的四道闸门就是答案。
方法篇（03–07）：上下文工程让 AI 理解现状，Spec 让 AI 理解要做什么，Spike 清掉技术未知，Plan 声明影响面，评审在最便宜的阶段拦住错误。
实现篇（08–09）：小步、红线、每步 Diff、冲突暂停；代码评审的主角从”代码优不优雅”变成”变更是否忠于契约”。
测试篇（10–13）：从 REQ 推导文本用例，把用例代码化成有效断言（测行为不测实现、空实现自检），失败先证据后分类、禁猜测修复，分层执行并诚实报告。
验证篇（14–15）：Verify 把视角从”测试绿”抬升到”每条需求有证据”，失败要归因到真正的源头层并回写，而不是就地修绿。
系统篇（16）：把个人习惯变成团队机制——模板、CI 追踪、分级审批、并行隔离、反馈飞轮。

贯穿始终的几条信念：

AI 越强，流程越重要——因为错误实现的速度也变快了；
契约在人，执行在 AI，证据在测试，裁决永远在人；
最贵的不是写代码，是判断”哪些改动该存在""失败该在哪一层修”；
每一次失败都应让系统更严密，而不是简单清零。

AI Native 研发的终点，不是”完全不需要人”，而是——让人的判断力被沉淀进 Spec、模板、CI 和知识库，被每一个 AI 会话复用，被整个团队放大。 人从重复的执行里解放出来，专注在只有人能做的事上：定义什么是对的，并为结果负责。

系列到此完整。但这套方法不是读完就会的，它是在一次次”写 Spec → 被 AI 误解 → 补规则 → 测试拦住 → 归因回写”的循环里长出来的。挑一个你手上真实的小功能，从第一步”把它写成一份带非目标的 Spec”开始，让它跑完整套四道闸门——你会比读完这 17 篇理解得更深。

.Sam

摘要