SOLO 四阶段工作流
从产品需求到TDD实现的完整自动化工作流程
🎯 工作流概述
SOLO 工作模式采用四阶段流水线式开发方法，每个阶段都有专门的AI代理负责，确保交付物的质量和完整性。
📋 阶段详解
🎨 PRODUCT - 需求分析阶段
目标: 将业务需求转化为清晰的产品需求文档
核心交付物:
- 📄 PRD.md - 产品需求文档
- 👥 用户故事和验收标准
- 🎯 功能优先级排序
- 🔍 非功能性需求定义
质量标准:
- ✅ 需求可测试且量化
- ✅ 用户价值明确
- ✅ 技术可行性评估
- ✅ 风险识别完整
代理角色: product-manager
🏗️ ARCHITECT - 架构设计阶段
目标: 基于PRD设计技术架构和实现方案
核心交付物:
- 📐 PROJECT_PLAN.md - 项目计划
- 🔌 API接口设计 (OpenAPI 3.0)
- 🗄️ 数据库设计 (ER图+DDL)
- 🏛️ 系统架构图
- 📝 DECISIONS.md - 技术决策记录
质量标准:
- ✅ 架构满足非功能性需求
- ✅ API设计符合RESTful规范
- ✅ 数据库设计规范化
- ✅ 技术选型合理有据
代理角色: architect
⚙️ ENGINEER - TDD实现阶段
目标: 严格按照TDD循环实现所有功能
核心交付物:
- 🔴 失败的测试用例 (RED)
- 🟢 最小化实现代码 (GREEN)
- 🔄 重构优化代码 (REFACTOR)
- 📊 80%+ 测试覆盖率
- 🚀 可部署的应用程序
质量标准:
- ✅ 严格遵循RED-GREEN-REFACTOR循环
- ✅ 单元测试覆盖率 ≥ 80%
- ✅ 集成测试验证API契约
- ✅ 代码符合团队规范
代理角色: engineer
🔍 QA - 质量保证阶段
目标: 全面验证系统质量和用户体验
核心交付物:
- 🧪 E2E测试用例和报告
- 📈 性能测试报告
- 🔒 安全测试报告
- 📚 API文档和使用指南
- ✅ 验收测试报告
质量标准:
- ✅ 所有用户故事验收通过
- ✅ 性能指标满足要求
- ✅ 安全漏洞修复完成
- ✅ 文档完整准确
代理角色: qa-engineer
🔄 阶段切换机制
智能状态检测
bash
# 系统自动检测当前阶段和完成状态
/solo "用户管理系统" # 自动检测已完成的工作，继续未完成部分手动阶段切换
bash
# 检查切换条件
/solo__switch architect --dry-run
# 强制切换（需谨慎使用）
/solo__switch engineer --force
# 带风险评估的切换
/solo__switch qa --assess-risk中断恢复机制
bash
# 智能恢复工作
/solo__resume deep # 深度分析后恢复
/solo__resume quick # 快速恢复当前上下文
/solo__resume verify # 验证环境一致性📊 工作流监控
实时状态查看
bash
# 简要状态
/solo__status brief
# 详细分析
/solo__status detailed
# 可视化仪表板
/solo__status dashboard
# 角色视图
/solo__status role:dev # 开发者视角
/solo__status role:pm # 产品经理视角
/solo__status role:qa # QA工程师视角质量指标监控
- 开发效率: 平均开发周期 5.2天
- 质量水平: 代码质量评分 4.7/5.0
- 缺陷率: 生产环境bug率 < 1%
- 测试覆盖: 单元测试覆盖率 ≥ 80%
🎯 最佳实践
1. 阶段完整性原则
- 确保每个阶段的交付物完整
- 不跳过任何质量检查点
- 保持文档与代码同步
2. 增量迭代原则
- 优先实现核心功能
- 逐步增加复杂特性
- 持续集成和部署
3. 团队协作原则
- 代理工作透明可见
- 决策过程有记录
- 知识共享和传承
🚀 快速开始
第一次使用
bash
# 1. 初始化项目
/solo "你的项目描述"
# 2. 查看状态
/solo__status brief
# 3. 继续工作
/solo # 继续当前阶段的工作恢复已有项目
bash
# 1. 检测项目状态
/solo__status detailed
# 2. 智能恢复
/solo__resume deep
# 3. 继续开发
/solo📖 相关资源
核心文档
实践案例
工具集成
💡 提示: SOLO工作流的核心是自动化和质量保证。每个阶段都有明确的输入、处理和输出，确保从需求到代码的完整追溯性。