层级 3: 标准工作流
复杂度: 中-高 | 产物: 持久化会话文件 | 状态: 完全会话管理
层级 3 工作流提供完整规划并支持持久化会话管理。专为需要可追溯性、验证和结构化执行的多模块变更而设计。
概述
包含的工作流
| 工作流 | 用途 | 阶段数 | 产物位置 |
|---|---|---|---|
plan | 复杂功能开发 | 5 阶段 | .workflow/active/{session}/ |
tdd-plan | 测试驱动开发 | 6 阶段 | .workflow/active/{session}/ |
test-fix-gen | 测试修复 生成 | 5 阶段 | .workflow/active/WFS-test-{session}/ |
共同特性
| 属性 | 值 |
|---|---|
| 复杂度 | 中-高 |
| 产物 | 持久化文件 (.workflow/active/{session}/) |
| 状态 | 完全会话管理 |
| 验证 | 内置验证步骤 |
| 执行 | /workflow:execute |
| 适用场景 | 多模块、可追溯任务 |
工作流 1: plan -> verify -> execute
5 阶段完整规划工作流
命令
/workflow:plan "实现 OAuth2 认证系统"
/workflow:plan-verify # 验证计划(推荐)
/workflow:execute
/workflow:review # (可选) 代码审查
流程图
流程阶段
阶段 1: 会话发现
/workflow:session:start --auto "实现 OAuth2 认证系统"
- 创建或发现工作流会话
- 返回:
sessionId
阶段 2: 上下文收集
/workflow:tools:context-gather
- 分析代码库结构
- 识别技术栈和模式
- 返回:
context-package.json+conflict_risk
阶段 3: 冲突解决(条件触发)
# 仅当 conflict_risk >= medium 时
/workflow:tools:conflict-resolution
- 检测潜在冲突
- 解决依赖问题
- 确保清晰的执行路径
阶段 4: 任务生成
/workflow:tools:task-generate-agent
- 生 成结构化任务
- 创建依赖图
- 返回:
IMPL_PLAN.md+IMPL-*.json+TODO_LIST.md
产物
位置: .workflow/active/{WFS-session}/
.workflow/active/WFS-oauth2-auth-2025-02-03/
├── workflow-session.json # 会话元数据
├── IMPL_PLAN.md # 实现计划
├── TODO_LIST.md # 进度跟踪
├── .task/
│ ├── IMPL-001.json # 主任务
│ ├── IMPL-002.json
│ └── ...
└── .process/
├── context-package.json # 项目上下文
├── conflict-resolution.json # 冲突分析
└── planning-notes.md
适用场景
- 多模块变更
- 代码重构
- 需要依赖分析
工作流 2: tdd-plan -> execute -> tdd-verify
6 阶段测试驱动开发工作流
命令
/workflow:tdd-plan "使用 TDD 实现用户注册"
/workflow:execute # 遵循 Red-Green-Refactor
/workflow:tdd-verify # 验证 TDD 合规性
流程图
流程阶段
阶段 1: 会话发现
/workflow:session:start --type tdd --auto "TDD: 用户注册"
TDD 结构化格式:
TDD: [功能名称]
GOAL: [目标]
SCOPE: [包含/排除的范围]
CONTEXT: [背景]
TEST_FOCUS: [测试场景]
阶段 2: 上下文收集
/workflow:tools:context-gather
阶段 3: 测试覆盖率分析
/workflow:tools:test-context-gather
- 检测测试框架
- 分析现有测试覆盖率
- 识别覆盖率缺口
阶段 4: 冲突解决(条件触发)
# 仅当 conflict_risk >= medium 时
/workflow:tools:conflict-resolution
阶段 5: TDD 任务生成
/workflow:tools:task-generate-tdd
- 生成包含内置 Red-Green-Refactor 循环的 IMPL 任务
meta.tdd_workflow: trueflow_control.implementation_approach包含 3 个步骤(red/green/refactor)
阶段 6: TDD 结构验证
- 验证 TDD 结构合规性
TDD 任务结构
{
"id": "IMPL-001",
"title": "实现用户注册",
"meta": {
"tdd_workflow": true
},
"flow_control": {
"implementation_approach": [
{
"step": 1,
"title": "Red: 编写失败的测试",
"description": "编写一个失败的测试"
},
{
"step": 2,
"title": "Green: 使测试通过",
"description": "实现最小代码使测试通过",
"test_fix_cycle": {
"max_iterations": 3,
"pass_threshold": 0.95
}
},
{
"step": 3,
"title": "Refactor: 改进代码",
"description": "在保持测试通过的同时重构"
}
]
}
}
铁律
没有失败的测试,就没有生产代码
执行方法:
- 阶段 5:
implementation_approach包含测试优先步骤(Red -> Green -> Refactor) - Green 阶段: 包含 test-fix-cycle 配置(最多 3 次迭代)
- 自动回滚: 达到最大迭代次数且测试未通过时触发
顺序为何重要:
- 后写的测试会立即通过 -> 证明不了什么
- 测试优先强制在实现前发现边界情况
- 后写测试验证的是已构建的内容,而非所需内容
适用场景
- 测试驱动开发
- 高质量功能需求
- 关键系统组件
工作流 3: test-fix-gen -> test-cycle-execute
5 阶段测试修复生成工作流
命令
# 会话模式
/workflow:test-fix-gen WFS-user-auth-v2
/workflow:test-cycle-execute
# 提示词模式
/workflow:test-fix-gen "测试认证 API"
/workflow:test-cycle-execute