从“治理”到“交付”的七步链条

1. /constitution
   奠定“怎么做事”的元规则（治理原则、质量标准、决策准则、角色职责、提交/评审规范）。
2. /specify
   产出“要做什么”——结构化需求：业务目标、用户故事、验收标准、边界、非功能需求。
3. /clarify
   在计划前，对规格中含糊、缺失、冲突、风险点做问答/补全，降低推测。
4. /plan
   将清晰规格转化为宏观技术实施蓝图：架构设计、组件划分、接口策略、技术选型、数据模型、风险缓解。
5. /tasks
   把计划拆分为可执行、可估时、可追踪的最小工作单元（任务/子任务），附带依赖关系与验收条件。
6. /analyze
   做交叉工件一致性、覆盖率与差距分析：需求是否被计划覆盖？计划是否都映射到任务？有没有遗漏/冗余/冲突？
7. /implement
   按任务执行，实现、提交、测试、集成，产出可验证的增量价值，并回写状态。

1. /constitution

目的：
建立团队共同遵循的“操作系统”。若缺少此层，后续所有环节会因标准不一而反复争议。

典型内容：

• 价值与原则：如“最小可行、可测试、可追溯、自动化优先”。
• 质量门槛：代码覆盖率、静态检查、性能门线、设计评审必经节点。
• 角色职责：产品、架构、开发、测试、DevOps、合规。
• 决策模型：何时需要架构委员会、何种变更需 RFC。
• 工件规范：需求模板、计划文档结构、任务命名规则、提交信息格式（Conventional Commits 等）。
• 安全/合规指引。

触发时机：

• 项目初始或重大方向转折。
• 大规模新成员加入前。
• 质量/协作混乱暴露时的治理补课。

产出：

• 固化为 CONSTITUTION.md 或 governance 文档集。
• 可供其余命令读取的元数据（例如：优先级枚举、风险等级定义）。

影响下游：

• /specify 的字段格式受其约束。
• /plan 采用的设计评审标准来自这里。
• /tasks 结构与命名规则、Definition of Done (DoD) 来源此处。
• /analyze 的验证规则与指标库参考此处。
• /implement 的提交/合并准则、代码审查政策也在这里规定。

2. /specify

目的：
描述“正确的产品要达到什么”，而避免过早落入“怎么实现”。

结构化输入（示例字段）：

• 业务背景与目标（Problem Statement / OKR 对齐）。
• 用户画像与场景。
• 用户故事与验收标准（Given-When-Then）。
• 约束：合规、性能、可用性、可扩展性、国际化等非功能需求。
• 边界 & 反例（不做什么）。
• 利益相关方及优先级。
• 依赖外部系统清单。

适用场景：

• 新功能/模块。
• 存量功能重构。
• 技术性史诗（如“统一日志平台”）也可通过“内部用户故事”表达价值。

输出工件：

• 标准化规格文档（可 JSON/YAML 结构化）。
• 需求—目标—验收矩阵（为后续可追溯性打基础）。

下游依赖：

• /clarify 将遍历其字段找出不完整与冲突点。
• /plan 会将每条用户故事映射到架构/模块设计。

失败信号：

• 混杂解决方案语言（“使用 Redis 做…”）。
• 验收条件不可测试。
• 大量“待定 TBD”。

3. /clarify

目的：
在设计前消除歧义与认知偏差，避免“带猜测”进入 /plan 导致返工。

工作方式：

• 解析 /specify 输出，生成“疑问列表”：模糊术语、未量化指标、冲突需求、缺失边界。
• 与需求方（或领域专家）进行交互式问答（可能循环多轮）。
• 记录决策与补充说明（形成“澄清日志”）。

典型澄清类型：

• 模糊指标 → 转化为量化：例如“高性能”→“P95 响应 < 300ms”。
• 冲突：Story A 说“匿名可用”，Story B 要求“强制登录”。
• 依赖外部系统 SLA 未说明。
• 安全责任归属不清。

输出：

• 更新后的规格（版本升级）。
• 澄清决策追踪表（Question → Answer → 影响范围）。

下游影响：

• /plan 的风险假设减少。
• /tasks 的估时会更可靠。

最佳实践：

• 不要跳过：任何跳过 /clarify 的“抢时间”做法，常在 /implement 时付更高代价。
• 记录结构化变更（diff log）。

4. /plan

目的：
确立“怎样实现”——在不写具体业务代码前，形成可评审、可拆解的技术蓝图。

输入前提：

• /clarify 已关闭主要知识缺口。
• 治理规范 (/constitution) 明确质量门槛。

核心内容：

• 架构视图：上下文图、容器图、组件交互（C4 Model 等）。
• 数据模型：ER 图 / 事件模型 / 领域聚合。
• 接口契约：REST/gRPC/事件 schema。
• 流程：时序图（认证流程、补偿事务等）。
• 技术选型：含取舍分析（ADR）。
• 横切关注点：日志、追踪、鉴权、缓存、弹性、容灾。
• 风险列表与缓解策略（含试验计划或 Spike 任务）。
• 估算：Story → 组件 → 工作量分布。

输出：

• 计划文档（结构化：plan.yaml + ADR/ diagrams）。
• Story → 组件映射表。

下游：

• /tasks 以计划中的组件、接口、风险项为主线展开。
• /analyze 用它核对 coverage。

质量校验点：

• 是否每个用户故事都映射到至少一个设计组件？
• 是否有不可验证的“黑箱”描述？
• 是否对高风险未知（性能、并发、第三方依赖）定义了探索或 POC 任务？

5. /tasks

目的：
将“计划蓝图”落地为可执行的最小单元，支持进度跟踪、并行开发、自动化流水线触发。

任务拆解原则：

• 原子性：单任务单责任（实现一个 API、写一类测试、完成一个数据迁移脚本）。
• 可测试定义：任务完成有明确可验证输出。
• 可估时：通常 0.5～2 人日粒度（视团队节奏）。
• 可追溯：任务引用 Plan 节点与 Spec 用户故事 ID。

结构字段（示例）：

• id / title
• type（feature / refactor / test / ops / spike / doc）
• story_refs / plan_refs
• dependency_ids
• acceptance_criteria
• risk_level / priority
• estimate (e.g. story points 或 hours)
• owner (可空，后续分配)

自动生成逻辑：

• Story → 组件 → 任务树。
• Horizontal tasks（日志、监控、权限）由 /plan 横切策略派生。
• 风险缓解任务（Spike）显式列出（并标记“阻塞后续”）。

下游影响：

• /analyze 会检查：是否所有 Plan 元素都有对应任务？是否存在孤立任务？
• /implement 直接消费。

最佳实践：

• 初稿生成后需团队评审（开发+测试+DevOps）。
• 标记“合并任务”或“拆分建议”以调整粒度。

6. /analyze

目的：
在实施前（和实施过程中定期）验证工件间的一致性、覆盖率、质量偏差，形成“结构化健康报告”。

检查维度示例：

1. 覆盖率
   • 用户故事总数 vs 被映射到的 Plan 组件占比。
   • Plan 组件 vs 具备任务的比例。
   • 任务 vs 是否都回溯到某个故事或设计（孤儿任务）。
2. 一致性
   • 同一非功能需求是否在 Plan 与任务层面保持一致阈值（例如性能指标差异）。
   • 术语字典（Glossary）引用是否统一。
3. 完整性
   • 高风险区域是否有对应 Spike / 试验任务。
   • 安全、日志、监控、文档任务是否遗漏。
4. 冗余/冲突
   • 多个任务实现同一接口。
   • 互斥配置策略。
5. 衡量指标
   • 预计工作量 vs 可用资源平衡曲线。
   • 关键路径分析（依赖链长度）。

输出：

• 分析报告（coverage.json / risk_report.md）。
• 建议动作：补充、合并、重估、重排优先级。

触发时机：

• /tasks 初稿后。
• 实施中每个迭代开始/结束。
• 需求发生变更后（差量分析）。

影响：

• 可能回退（反馈）到 /specify（补需求）、/plan（调整架构）、/tasks（增删改）。

7. /implement

目的：
执行并交付可验证增量，使“任务→代码→测试→部署→验证→状态回写”自动化闭环。

典型流程：

1. 拉取待办（遵守依赖拓扑）。
2. 生成或提示分支命名（feature/{task-id}）。
3. 代码/测试/文档同步产出。
4. 静态检查 + 单测 + 安全扫描。
5. 构建 & 部署到预设环境（CI/CD）。
6. 验收脚本/自动化测试对照 acceptance_criteria。
7. 更新任务状态（done / blocked / needs-review）。
8. 汇总增量指标（覆盖率、变更行数、复杂度）。

与上游的反馈：

• 若验收失败：回溯 /tasks 是否需拆分或补充测试任务。
• 若任务实现遇到架构缺口：反馈 /plan。
• 若发现需求漏项：反馈 /clarify 或 /specify。

扩展：

• 可与基线质量阈值（来自 /constitution）自动比对。
• 通过标签/度量驱动发布准入（release gating）。

指令之间的“依赖图”

/constitution → 约束格式 & 质量标准
/specify ←（受治理）
↓ (发现模糊)
/clarify ↺ （循环直到歧义降至阈值）
↓（规格已稳定）
/plan
↓
/tasks
↔（循环改进，经由） /analyze
/analyze 可能回溯：/tasks、/plan、/specify
↓（一致性满足门槛）
/implement
↺（实施过程中的发现继续触发 clarifications/plan/tasks/analyze）

可视为一个分层“收敛—展开—收敛—执行”波浪模型：
静态规则 → 需求收敛 → 技术蓝图收敛 → 任务展开 → 一致性再收敛 → 执行增量。

典型协作角色映射

• 产品经理 / 领域专家：主导 /specify，参与 /clarify。
• 架构师 / 资深工程师：主导 /plan，评审 /tasks，参与 /analyze。
• 开发工程师：细化 /tasks，执行 /implement。
• 测试 / QA：提供验收标准、参与 /clarify、驱动 /analyze，验证 /implement。
• DevOps / 平台工程：在 /plan 提供部署/可观测性策略，在 /tasks 中创建流水线/监控任务。
• 安全 / 合规：在 /constitution & /plan & /analyze 节点设置检查点。

质量度量与仪表盘建议（辅助 /analyze 与 /implement）

变更管理策略

场景：需求变更或新发现

1. 变更请求评估：是否破坏现有 /constitution 原则？
2. 若新增/修改需求：更新 /specify → /clarify 快速补质疑 → 局部 /plan 重编 → /tasks 增量生成。
3. /analyze 差量模式：只检查受影响图节点。
4. /implement 增量合并，标记版本号。

常见反模式与改进建议

示例（简化演示）

1. /constitution 输出：

   • code_review: mandatory
   • test_coverage_min: 80%
   • performance_p95_ms: 300

2. /specify（用户故事示例）
   Story S1: 作为注册用户，我希望在 3 秒内看到个性化首页。验收：P95 < 3000ms，含最近订单列表。

3. /clarify 发现：

   • “最近订单”到底范围？答：最近 30 天内已支付订单。
   • 性能与 /constitution 性能准线（300ms vs 3000ms）冲突 → 统一：页面总加载 < 3s，关键 API P95 < 300ms。

4. /plan：

   • 组件：Auth Service, Order Service Aggregator, Personalization Engine。
   • 缓存策略：User Profile 缓存 5 min。
   • 风险：个性化引擎冷启动延时（Spike T-SP1）。

5. /tasks：

   • T1 构建 Order Aggregation API (refs S1, C-OrderService)
   • T2 实现缓存中间层 (refs S1, C-CacheLayer)
   • T3 Spike：个性化引擎延迟测试 (refs Risk R1)
   • T4 编写性能基准测试 (refs NFR P95)

6. /analyze 报告：

   • Coverage: 100% (S1 → T1,T2,T3,T4)。
   • 缺失：日志与监控任务 → 建议新增 T5 (Observability Setup)。

7. /implement：

   • 完成 T3 验证冷启动 800ms → /plan 更新：引入预热机制，新增任务 T6 Pre-warm Job。

总结要点

• /constitution 是“规范根”，不直接产出业务价值，却决定整体工程质量天花板。
• /specify 与 /clarify 形成需求精准度闭环。
• /plan 将“为什么”桥接到“怎么做”，必须透明、评审、版本化。
• /tasks 是执行与跟踪的最小颗粒载体，维系端到端可追溯。
• /analyze 是质量与一致性的“体检仪”，应多次运行，而非礼节性一次。
• /implement 不只是“写代码”，而是“实现+验证+反馈”的循环。
• 反馈通道是体系生命力关键：任何下游发现都能有序回流上游，不导致混乱。