阶段 4 · 流程闭环与试点

单点用 AI 容易，难的是把"需求→代码→测试→上线"串成 AI 能端到端跑、且可中断续传的流水线。

用 OpenSpec（规范管理 WHAT/WHY）+ Superpowers（执行 HOW）串成六阶段闭环，配合 SDD（spec/plan/tasks 三产物）把"发现需求偏差"的成本从改代码左移到改 Markdown。关键：tasks 清单让 Claude 中途退出后仍可断点续传，子代理分工让探索/实现/审查各司其职。

🧰 本阶段速查（做什么 · 产出什么 · 用什么）

🎯 做什么：OpenSpec + Superpowers 串六阶段闭环 + AI 自动化测试 + 防偷改护栏
📦 产出与汇报：周报（试点数据）+ 测试资产交接（录制转生成规范沉淀成 Skill）
🔧 工具/Demo：OpenSpec（规范管理）+ Superpowers（执行）/ autotest（GitLab，python main.py 即跑）
📖 测试方法论：《AI 自动化测试：方法论与实践》
👥 角色手册：开发 + 测试手册（闭环主力 + 质量把关）
📋 验收与交接：试点验收清单（结项打分）+ 开发↔测试交接（防偷改测试）

1. 为什么：单点用 AI 易，闭环难

新手先看这里：本章只看 §2 SDD 三产物（spec/plan/tasks）+ §3 六阶段工作流就够了。子代理分工（§4）、防偷改测试（§5）、案例（§6）是进阶，后续再看。OpenSpec+Superpowers 不用一上来全懂——先理解"规范驱动纠错左移"这个核心思想即可。

每个人都能让 AI 写一段代码，但串成端到端流水线会撞上三堵墙：①AI 初始分析不准（理解偏了）；②上下文断（会话中断，前面全丢）；③需求偏差晚发现（改完代码才发现理解错，返工贵）。闭环流程就是拆这三堵墙。

1.1 试点设计：选谁、多大、跑多久算成功

闭环不是上来就全员跑，先选对试点团队、定清成功标准：

维度	怎么定
选谁	意愿强的团队 + 业务典型的项目；别选最忙的（没空配合）、别选最边缘的（结果没说服力）
多大	1-2 个团队（每组 3-8 人）+ 1-2 个真实需求，跑 4-8 周
成功标准	① AI 代码占比达标（如 ≥60%）；② 产出提升（同比）；③ 质量不降（Bug 率不升）；④ 团队愿意继续用
失败止损	4-8 周无明显改善就复盘（见阶段 1 §4.3 失败预案），不硬推

试点的目的不是「证明能行」，而是「拿数据说话」——成功有数据推广、失败有原因可查，试点本身就是阶段 1「可止损」的落地。

2. SDD 规范驱动：把纠错左移

SDD（Spec-Driven Development）把开发拆成三层产物：

spec.md WHAT：可测试的行为规格（WHEN/THEN 格式）。
plan.md HOW：含完整代码的实施指南（每步前后对比、精确文件路径）。
tasks.md DO：可追踪的 checkbox 任务清单。

核心价值是"左移"：把"发现需求理解偏差"从改代码（昂贵）左移到改 Markdown（便宜一个数量级）。AI 初始理解往往不准，但改 spec 比改代码快得多。tasks 清单还带来断点续传——Claude 中途退出后，重进项目指定 change 目录，看 tasks 的 [ ]→[x] 就知道做到哪了。

2.1 OpenSpec 操作速查

SDD 用 OpenSpec 落地。三个核心概念先分清：

概念	性质	位置
Spec（规格）	稳定、跨变更共享	`openspec/specs/`
Change（变更）	一次性、做完归档	`openspec/changes/<name>/`
Archive（归档）	变更完成后存档	`openspec/changes/archive/`

四条命令覆盖全流程：

/opsx:explore   # 探索需求、调查代码库
/opsx:propose   # 生成 proposal.md / design.md / specs/ / tasks.md
/opsx:apply     # 按 tasks 执行（或交给 Superpowers）
/opsx:archive   # 验证通过后归档变更

每次对话 OpenSpec 会自动读 openspec/specs/ 下所有 spec.md 并应用到生成代码——所以 specs/ 要精简（只放稳定的全局规范），一次性变更放 changes/。

tasks 状态机（断点续传的关键）：[ ] 待办 → [in_progress] 进行 → [x] 完成 → [deleted] / [blocked]。TBCFlow 的恢复判定正是扫 tasks 的 [x] 标记判断从哪续。

3. 六阶段工作流（OpenSpec + Superpowers）

团队工作流编排 OpenSpec（规范）+ Superpowers（执行）+ 代码图谱（定位）。

注：下面的 Stage 1-6 是 OpenSpec 工作流的内部阶段，不是教程的 6 个实施阶段（stage1-6）——同名但不同概念。

Stage 1 需求探索    → superpowers:brainstorming      （用户可纠正方向）
Stage 2 规范生成    → openspec-propose               （产 proposal/design/tasks/spec）
Stage 3 计划拆分    → superpowers:writing-plans      （+ 代码图谱 impact/locate）
Stage 4 TDD+审查    → subagent-driven-development    （RED→GREEN→REFACTOR）
Stage 5 验证        → verification-before-completion （+ detect_changes）
Stage 6 归档        → openspec-archive

每阶段只读当前 Stage 文件（渐进式披露）。探索阶段主动找死代码和 bug——"跳过探索直接动手 = 重写 bug"。

跳过了阶段 3（无代码图谱）怎么办：上面「+ 代码图谱 impact/locate/detect_changes」是有图谱时的增强，不是闭环的硬前提。小团队跳过 stage3 时用替代：impact（改前评估影响）→ 改前 grep + 人脑梳理上下游；locate（定位文件）→ grep / 项目结构；detect_changes（提交前验证）→ git diff + 人审 + 测试。能力降级（靠人补），但闭环仍能跑——等代码量大到人脑兜不住，再回来建图谱（阶段 3）。

这套工作流的 skill 落地：TBCFlow（tbc-skills GitLab 仓库，时代光华自研编排型 skill）把上面 6 阶段串成一条命令——自己不实现任何逻辑，只编排 OpenSpec + Superpowers，还带「断点续传」（中断后查文件状态自动恢复到正确阶段）和「规则覆盖」（rules/ 改写底层 skill 的默认出口）。想看完整的多阶段 skill，直接 clone 仓库读 SKILL.md + stages/。

工具演进：随能力做减法。OpenSpec + Superpowers 不必一直一起用，随你驾驭 AI 的能力提升逐步精简：
• 入门期：OpenSpec + Superpowers 结合——前者把需求拆成规范（防 AI 跑偏），后者按规范执行，新手靠框架兜底；
• 熟练期：只用 Superpowers——你已能把需求讲清（规范思维内化），只剩执行交框架；
• 精通期：直接用 Claude Code 裸交互——精准下达指令、自己掌控流程，不再依赖框架。
但注意：这是个人能力的演进。团队协作、规范沉淀、新人上手场景下，框架仍有价值——它让能力可复制、流程可复现，不止约束个人。所以「精通后裸用」是个人上限，不是团队标准。

4. 子代理分工：各司其职

不同子代理扮演不同角色，避免"一个代理又探索又写又审"的混乱：

Explore 代理：只搜索、只读，不修改。
实现代理：按 plan 的精确指令修改代码。
规格审查代理：对照 spec.md 逐条验证。
质量审查代理：检查风格、安全、命名冲突。

5. 防 AI 偷改测试：三层防护

AI 为让测试"全绿"会偷偷改测试迎合错误逻辑。防护三层，第 2 层是关键：

// .claude/settings.json —— 权限层 deny 掉测试文件写入
{
  "permissions": {
    "deny": ["Write(test/**)", "Edit(test/**)", "Write(**/*.test.ts)", "Edit(**/*.spec.ts)"]
  }
}

第 1 层提示词：CLAUDE.md 写明"严禁修改测试文件"。
第 2 层权限（关键）：settings.json 的 deny 硬性拦截。
第 3 层 Git 兜底：先提交测试，完成后 git diff 检查。

TDD 防幻觉铁律：不要让 Claude 同时写代码和测试——它会写出"验证错误逻辑"的测试，全绿但全错。正确做法：测试先行、独立验证。

6. 真实案例：从单点修复到大规模迁移

案例 A：apaas-design form 编辑器数据丢失修复（TBCFlow 全流程，变更 fix-form-editor-expression-data-loss）。低代码平台 apaas-design 的 form 表达式映射导致编辑面板原始数据丢失——用户一句话 /tbcflow 修复一下form表单… → 2 个 Explore 子代理调查 → 用户两次纠正方向（①根因在 form.vue 的 dataContext 初始化而非 baseSetting.vue；②方案漏 25+ 插件）→ 提 3 方案 → 最终 Vue2 provide/inject：

方案演进：v1（prop 开关 2 文件，覆盖不全）→ v2（prop 开关 25+ 文件，改动大）→ v3（provide/inject 2 文件，自动覆盖 ✅）
最终只改 2 个文件约 10 行（editorPanel.vue provide +5 行 + form.vue inject +4 行改 2 行），覆盖全部 25+ 插件，全程约 24 分钟（探索 10 + 规范 6 + 计划 2 + 实现 5 + 归档 1）。

案例 B：国际化配置 Nacos 化（基础应用组秦延国，OpenSpec+Superpowers，变更 i18n-nacos-config，2026-03-31 完成）。把 i18n 语言配置从硬编码静态文件迁移到 Nacos 动态配置——产出 proposal/design/tasks/spec.md（4 Requirement / 8 Scenario，WHEN/THEN），技术决策与回滚方案记录在 design.md，全程 spec-driven（改 spec 不改代码）。

案例 C：app-rtr 个人中心前后端分离重构（大规模迁移）。易培组（孙坤 / 刘迎康团队）用 TBCFlow + tasks 断点续传，把 app-rtr（用户门户 / 个人中心，GitLab 仓库）从前后端耦合重构为分离架构：12 个 Controller / 211 个 API / 约 15000 行（估算）/ 110 个任务全部完成。关键是 tasks 清单支撑跨周断点续传——中途退出重进，看 [x] 标记接着干。

案例 D：前端 AI 陪练对话生成（前端复杂集成）。前端组（韩炎军，tbc-lcp 仓库 AiPeilian/AgentDrawer 模块，分支 aiPeilian_hyj）用 AI 生成对话交互模块，8 人日（5 开发 + 3 修复），含 React×Vue SDK Monkey Patch、SSE 拦截器等复杂集成——证明 AI 不只能写 CRUD，前端复杂场景也能落地，关键在「给足上下文 + 分步验证」。

启示：案例 A 的方案演进最能体现价值——AI 前两版是机械式的（漏/笨），是用户对业务的理解（provide/inject 透传）找到了最优解。用户引导是核心，AI 是执行者。案例 B 的"决策记录+风险权衡"结构可作重大技术决策模板。案例 C/D 证明闭环能撑住大规模迁移和前端复杂集成，不只是小修小补。

7. 测试侧闭环：AI 自动化测试

§6 两个案例是开发侧闭环（需求→代码）。测试侧也有一个成熟的 AI 闭环：录制 → AI 转换 → 人审 → 数据驱动执行。两者互补——开发闭环产出功能代码，测试闭环产出测试资产，合起来才是端到端。

核心定位：AI 只生成不执行——AI 在第二段（编码期）把 Playwright 录制脚本转成标准测试类，运行期是确定性的数据驱动框架（零 AI）。这个边界规避了 LLM 幻觉导致的"虚假通过"（把失败说成通过）。最值得复用的方法论是"规范即 Prompt"：把测试类编写规范沉淀成一个 Claude Code Skill（8 条硬规范 + 3 套模板），AI 在规范框框里稳定产出。

与 §5 的呼应：§5 讲"防 AI 偷改测试"（保护测试不被 AI 改坏）；本节讲"用 AI 生成测试"（让 AI 帮你写测试）。这是测试与 AI 关系的两个面——前者防风险，后者要提效，缺一不可。

📖 完整方法论（四段式详解、规范即 Prompt 的 8 规范 3 模板、元数据驱动编辑器、动态数据 + 软断言、录制转换 7 大避坑、已实现 vs 规划的诚实边界）见《AI 自动化测试：方法论与实践》。

8. 角色视角 + 常见坑 + 清单

Leader

推动试点团队先用闭环流程跑通 1-2 个真实需求，拿案例做示范。

开发者

掌握 SDD + 六阶段工作流；试点时坚持"探索→规范→计划→TDD→验证"，别跳步。

在 brainstorming 阶段把需求讲清（AI 初始分析常不准，PM 的业务理解是关键输入）。

坑：①跳过探索直接编码（=重写 bug）；②一个会话干完所有事（上下文污染，应子代理分工）；③信任 AI 不验证（尤其测试）。

📋 阶段4 落地清单

试点团队已用 OpenSpec+Superpowers 跑通 1-2 个真实需求，有案例
SDD 三产物（spec/plan/tasks）成为标准，纠错左移到 Markdown
子代理分工明确（探索/实现/规格审查/质量审查）
防偷改测试三层到位（提示词 + 权限 deny + git diff）
tasks 清单支持断点续传（Claude 中断后可续）
测试侧闭环已纳入：AI 生成测试资产 + 框架确定性执行（见专题）