Dev Workflow — 结构化开发流程

强制 Design → Plan → TDD Implement → 两阶段 Review → Verify 的结构化开发流程，支持多角色子 agent 协作和模型成本优化。

触发判断

显式触发

用户输入 KAIFA##（可带描述文本）→ 无条件进入开发模式。

自然语言触发

匹配以下模式时自动进入：

• 开发 + SKILL/APP/应用/系统/模块/功能/工具
• 实现 + 功能描述
• 写 + 模块/系统/服务
• 重构 + 代码/模块
• 新建 + 项目/模块

不触发

• "修复一个小bug"、"改一下配置"、"帮我查一下"、"解释这段代码"
• 单文件修改、查询类请求
• 纯咨询/讨论类问题

不确定时

发确认卡：

🤔 这个需求是否需要走开发模式（Plan→Implement→Review）？

核心流程（强制，不可跳过）

PHASE 0: ASSESS             → 评估复杂度 + 决定团队 + 分配模型
PHASE 1: DESIGN DISCUSSION  → 苏格拉底式需求精炼 + 方案选项讨论
PHASE 2: PLAN               → 产出设计方案文档
     ⛔ APPROVAL            → 用户一次性审批，通过才继续
PHASE 3: IMPLEMENT (TDD)    → spawn Developer 子 agent（RED→GREEN→REFACTOR）
PHASE 4: REVIEW (两阶段)    → Stage 1: 规格合规 → Stage 2: 代码质量
PHASE 5: VERIFY             → 验证闭环：回归测试 + 关键路径验证
     ⛔ BLOCKER?            → 有 BLOCKER 标记给用户决策
PHASE 6: REPORT             → 汇总结果，归档

流程变体速查

PHASE 0: ASSESS（评估）

由 PM（主 agent）完成，输出简短评估卡：

📊 复杂度评估
- 级别: 简单 / 中等 / 复杂
- 理由: (一句话)
- 团队: PM → Developer → Reviewer  |  PM → Architect → Developer → Reviewer
- 模型分配:
  · Architect: pro (如果需要)
  · Developer: flash
  · Reviewer: pro / flash

复杂度判断标准

模型分配规则

原则：

• flash：确定性执行（已知输入 + 明确方案 → 写代码），省钱
• pro：深度推理（多维度权衡、对照分析、风险评估）
• Reviewer 在简单场景可用 flash（快速扫一眼），中等及以上必须用 pro

PHASE 1: DESIGN DISCUSSION（需求精炼）

🆕 新增阶段。参照 Superpowers 的 brainstorming 理念，在写 Plan 前确保需求理解正确。

由 PM（主 agent）完成。ASSESS 后、PLAN 前，对用户需求进行苏格拉底式精炼。

执行方式

1. 需求澄清 — 用户需求中不明确的地方逐一确认：

   • 功能边界：做什么 / 不做什么？
   • 使用场景：谁来用？什么时候用？怎么用？
   • 非功能需求：性能、安全、兼容性？

2. 方案讨论 — 技术方案至少给出 2 个选项供用户选择：

   • 每个选项包含：方案简述 + 优缺点 + 适用场景
   • 给出推荐选项及理由
   • 记录用户的方案选择

3. 设计决策记录 — 产出简要决策记录：

   💡 设计决策
   - 确认项 1: ...
   - 确认项 2: ...
   - 方案选择: 选项A（理由: ...）
   

快速模式例外

快速模式可跳过此阶段，PM 自行推断需求，但必须在 Plan 中标注"快速模式，需求未经精炼确认"。

PHASE 2: PLAN（方案设计）

基于 DESIGN DISCUSSION 的结论，由 PM（主 agent）完成，输出到 plans/YYYY-MM-DD-\x3Cslug>-plan.md。

输出内容

参照 references/plan-template.md，必须包含：

1. 需求分析（目标 + 使用场景 + 设计决策回顾）
2. 架构设计（模块划分、数据流、技术选型）
3. API/接口定义（输入输出、边界条件）
4. 数据模型（核心实体和关系）
5. 任务拆解（2-5 分钟粒度的子任务清单，可供 Developer 逐项执行）
6. 测试策略（单元测试覆盖哪些场景、集成测试覆盖哪些路径）
7. 边界情况 & 风险
8. 模型分配方案

Slug 安全规则

从用户需求中提取 slug（功能名缩写），仅允许 [a-z0-9-]+，长度 ≤ 50。不能提取时 fallback 为 unnamed-task。

输出方式

1. 将完整 Plan 写入 plans/YYYY-MM-DD-\x3Cslug>-plan.md（slug 必须经过规范化）
2. 在对话中输出结构化的 Plan 摘要
3. 末尾带审批提示

⛔ APPROVAL GATE（审批闸门）

Plan 输出后，必须等待用户审批。提示格式：

⛔ APPROVAL REQUIRED
完整 Plan: plans/YYYY-MM-DD-\x3Cslug>-plan.md
请确认：
  ✅ Approved → 进入 Implement
  ✏️ Modify  → 需要调整…
  ❌ Reject  → 回到 Phase 2 重新 Plan

规则：

• 用户明确说 "Approved"/"OK"/"通过"/"开始实现" → 进入 Implement
• 用户说修改意见 → 更新 Plan 后再次审批
• 用户 Reject → 回到 Phase 2 重新 Plan
• 未审批通过，绝不进入 Implement

PHASE 3: IMPLEMENT — TDD 强制

🆕 新增 TDD 强制约束。参照 Superpowers 的 test-driven-development skill。

审批通过后，spawn Developer 子 agent 执行。强制 RED → GREEN → REFACTOR 循环。

TDD 强制规则

Developer 子 agent 必须按以下顺序执行，不可跳过：

🔴 RED    → 先写测试（且看它失败）
🟢 GREEN  → 再写最小实现代码
🔵 REFACTOR → 重构优化（保持测试通过）

违背此规则的代码视为无效，必须重新执行。

Developer 子 agent 参数

runtime: subagent
context: isolated
model: deepseek-v4-flash  # 默认，复杂场景可在 Assess 阶段覆盖
label: "developer-\x3Cslug>"
task: |
  你是 Developer，基于以下 Plan 实现代码。必须严格遵守 TDD 流程。
  
  ## TDD 强制规则（不可跳过）
  1. 🔴 先写测试代码，运行确认测试失败
  2. 🟢 写最小实现代码使测试通过
  3. 🔵 重构优化代码，保持测试通过
  4. 每完成一个子任务 → 运行全套测试确保不回归
  
  ## Plan
  [Plan 文档内容]
  
  要求：
  1. 按 Plan 中的子任务清单逐项执行（2-5分钟粒度）
  2. 严格按 Plan 中的架构和接口定义实现
  3. 覆盖 Plan 中测试策略列出的所有场景
  4. 处理 Plan 中列出的所有边界情况
  5. 不引入 Plan 之外的依赖
  6. 代码风格清晰，关键逻辑加注释
  7. 完成后列出所有修改/新建的文件清单
  8. 如有已知限制，明确列出

输出要求

Developer 完成后应输出：

• 修改/新建的文件清单
• 每个子任务的 TDD 执行摘要（RED → GREEN → REFACTOR）
• 测试运行结果（通过/失败数量）
• 关键实现说明
• 已知限制（如有）

失败处理

• Developer 子 agent 出错 → PM 检查错误原因，修复后重新 spawn（最多重试 2 次）
• 2 次重试后仍失败 → 标记给用户，附带已尝试的方案和错误信息
• 重试时使用相同的 Plan（不修改方案，除非用户要求）

PHASE 4: REVIEW（两阶段审查）

🆕 拆分为两阶段审查。Stage 1：规格合规 → Stage 2：代码质量。

Implement 完成后，spawn Reviewer 子 agent 审查。

Stage 1: 规格合规审查

对照 Plan 检查实现是否偏离设计：

• 接口签名是否与 Plan 一致？
• 数据模型是否符合 Plan 定义？
• 功能边界是否匹配 Plan 范围？
• 是否引入 Plan 之外的依赖或功能？
• 边界情况是否都已处理？

Stage 2: 代码质量审查

对照 checklist 检查代码质量：

• 命名规范、代码风格
• 错误处理是否完善
• 是否有明显性能问题
• 安全风险（注入、越权等）
• 可读性和可维护性

Reviewer 子 agent 参数

runtime: subagent
context: isolated
model: deepseek-v4-pro  # 默认，简单场景可用 flash
label: "reviewer-\x3Cslug>"
task: |
  你是 Reviewer，对照 Plan 审查实现代码。请分两阶段执行：
  
  ## Plan
  [Plan 文档内容]
  
  ## 实现
  [Developer 输出的文件清单 + 代码]
  
  ### Stage 1: 规格合规审查
  逐项对照 Plan 检查实现是否偏离设计。
  
  ### Stage 2: 代码质量审查
  使用 references/review-checklist.md 中的检查清单逐项审查。
  
  对每个问题标注严重程度：🔴 BLOCKER / 🟡 MAJOR / 🟢 MINOR
  标注问题属于 Stage 1 还是 Stage 2。

Review 输出

写入 plans/YYYY-MM-DD-\x3Cslug>-review.md，格式参照 references/review-checklist.md。

输出需包含：

• Stage 1 审查结果（规格合规检查项及结论）
• Stage 2 审查结果（代码质量检查项及结论）
• 问题清单（分类 + 严重程度 + 修复建议）

PHASE 5: VERIFY（验证闭环）

🆕 新增验证闭环。Review 通过后、Report 前，验证所有问题已修复且系统正常工作。

验证步骤

1. 回归测试 — 运行全套测试，确保全部通过
2. Review 问题复检 — 逐项检查 Review 中标记的问题是否已修复
3. 关键路径验证 — 手动验证（或通过脚本验证）核心功能路径
4. 边界情况复测 — 确认 Plan 中识别的边界情况已覆盖

验证结果

🔍 验证结果
- 测试: ✅ X passed / 0 failed
- Review 问题: ✅ 已修复 N 项 / 0 项待处理
- 关键路径: ✅ 已验证
- 边界情况: ✅ 已覆盖

结论: ✅ 通过 / ❌ 不通过 → 回到 PHASE 3 修复

不通过则回到 PHASE 3 修复，通过后进入 PHASE 6。

⛔ BLOCKER 处理

Review 或 Verify 完成后：

循环计数器

每次 Review 发现 BLOCKER 后进入修复循环，PM 需跟踪循环次数：

• 第 1-2 次：正常处理，给用户 A/B/C 选项
• 第 3 次及以上：强制标记用户，提示"已修复 N 次仍存在 BLOCKER，建议重新评估方案"

用户决策选项（有 BLOCKER 时）

🔴 Review 发现 BLOCKER 级别问题，无法继续。
完整 Report: plans/YYYY-MM-DD-\x3Cslug>-review.md
修复循环: 第 N 次

请决策：
  A) 回到 Implement → 修复问题
  B) 回到 Plan → 重新设计
  C) 接受风险 → 继续进入 Report（记录已知问题）

PHASE 6: REPORT（汇总报告）

汇总全部产出，给出最终报告：

📋 开发报告 — \x3C功能名称>

| 阶段 | 状态 | 产出 |
|------|------|------|
| Design | ✅ | 决策记录 |
| Plan | ✅ | plans/\x3Cslug>-plan.md |
| Implement (TDD) | ✅ | (文件清单) |
| Review (两阶段) | ✅/⚠️/❌ | plans/\x3Cslug>-review.md |
| Verify | ✅ | 验证结果 |

遗留问题: (Review 中的 MINOR/MAJOR 项)
后续建议: (如有)

流程变体

详见 references/workflow-variants.md。

快速模式

用户说"快速开发"/"简单开发"：

• 跳过 Design Discussion
• Plan 精简（跳过架构设计章节，任务拆解可放宽至 5-10 分钟粒度）
• TDD 可简化（测试覆盖核心路径即可）
• Review 仅 Stage 2，用 flash
• VERIFY 精简（仅运行测试，跳过手动验证）

严格模式

用户说"严格模式"/"核心功能"：

• 完整 Design Discussion + 启用 Architect 子 agent
• Architect 产出 Plan 方案，PM 审批后传递给 Developer
• TDD 严格要求覆盖所有边界情况
• 两阶段 Review 用 pro
• VERIFY 完整执行（含关键路径手动验证）

仅审查

用户说"审查这段代码"/"review this"：

• 跳过 Assess~Implement
• 直接进入两阶段 Review（无 Plan 对照时，Stage 1 仅检查代码是否自洽）

重构模式

用户说"重构"：

• Design Discussion 聚焦现状分析 + 目标架构讨论
• Plan 阶段聚焦重构方案（现状分析 + 目标架构 + 迁移步骤 + 兼容性考虑 + 回归测试策略）
• TDD 要求先确保现有测试通过，再修改

Git 工作流集成（可选）

🆕 可选的 Git 管理能力。当项目在 Git 仓库中时可用。

非强制，PM 根据项目情况决定是否启用：

• 开发前 — 自动创建 feature 分支：feature/\x3Cslug>
• 开发中 — 使用 git worktree 隔离并行开发（参考 Superpowers 的 using-git-worktrees）
• 完成后 — 合并到主分支或创建 PR
• 不在 Git 仓库中的项目跳过此步骤

自我进化

🆕 元能力。KAIFA## 可根据使用经验自我改进。

• 每次完成开发后，PM 反思流程中是否有可改进之处
• 发现 SKILL.md 或 references 中的流程缺陷 → 生成补丁建议
• 用户确认后更新 SKILL.md
• 不自动修改流程文件（需要用户审批）

归档规范

plans/
├── YYYY-MM-DD-\x3Cslug>-plan.md     # Plan 文档
├── YYYY-MM-DD-\x3Cslug>-review.md   # Review Report
└── ...

• slug: 功能名缩写，仅允许小写字母、数字和连字符 [a-z0-9-]+，长度 ≤ 50，如 user-login, payment-refactor
• slug 不能包含路径分隔符（/、..），提取时自动过滤
• 无法提取功能名时 fallback 为 unnamed-task
• 如果 slug 同一天重复（罕见），追加数字后缀

子 Agent 执行期间的中断处理

• 用户在 Implement 或 Review 期间发送新消息 → PM 等待子 agent 完成后统一响应
• 用户明确要求中断（"停止"/"取消"） → PM kill 子 agent，记录当前状态，等待用户下一步指令
• 子 agent 超时无响应 → 标记用户，询问是否重试或调整

约束与原则

1. 审批闸门不可绕过 — Plan 未审批通过，绝不进入 Implement
2. Plan 优先于代码 — 先想清楚再写
3. TDD 不可跳过 — RED → GREEN → REFACTOR 是铁的纪律
4. Review 两阶段 — 规格合规 + 代码质量，缺一不可
5. 验证才闭环 — 修完必须验证，不通过回到修复
6. Review 对照 Plan — 不只审查代码，还要检查是否偏离设计
7. 成本意识 — 能用 flash 的不用 pro，Reviewer 质量不妥协
8. 追溯归档 — 每次开发都有 Plan + Review 记录
9. 不确定时反问 — 不要假装确定触发条件
10. 自我进化 — 每次完成后反思，持续改进流程