🚀 SOLO 开发指南

Appearance

SOLO 工作模式概述 ​

SOLO（System-Organized Large-scale Operation）工作模式是基于 PRODUCT → ARCHITECT → ENGINEER → QA 四阶段流水线的系统化产品开发框架，专为现代软件工程设计。

💡 “SOLO”的含义：AI时代的独奏者 ​

“SOLO”一词具有双重含义：

  1. 字面缩写: System-Organized Large-scale Operation，即“系统化组织的大规模操作”，强调其流程的标准化和可扩展性。
  2. 哲学延伸: “独奏”。在AI时代，我们希望每一位开发者都能像一位独奏家 (Soloist)。虽然名为“独奏”，但独奏家并非孤军奋战，其背后有整个“交响乐团”（即由AI子代理和自动化工具链构成）的强大支持。

这种模式旨在极大地赋能个体开发者，使其在AI的辅助下，能够独立、高效地完成从需求分析到高质量交付的完整闭环，奏出华美的“代码乐章”。

🎯 核心理念 ​

四阶段协作模式 ​

  • PRODUCT: 产品需求分析和PRD编写
  • ARCHITECT: 技术架构设计和项目规划
  • ENGINEER: TDD代码实现和重构
  • QA: 测试设计和质量保证

与API-First的完美融合 ​

SOLO模式不是替代现有的API-First开发流程，而是在其基础上提供更完整的上游流程：

🚀 主要优势 ​

1. 完整的开发闭环 ​

  • 需求到交付: 从产品需求到API发布的完整流程
  • 角色明确: 专业化分工，提高效率
  • 标准化: 统一的文档结构和工作流程

2. 与现有工具无缝集成 ​

  • OpenAPI Generator: 在架构设计阶段集成
  • 测试框架: 与现有TDD实践完美配合
  • CI/CD: 自然融入现有部署流程

3. 可追溯的开发过程 ​

  • 上下文记录: 完整的决策和实现过程
  • 质量门控: 每个阶段的明确验收标准
  • 文档同步: PRD、架构设计与代码实现保持一致

📂 文件组织结构 ​

SOLO模式采用 .solo/ 目录统一管理所有工作产物：

project-root/
└── .solo/                      # SOLO工作模式专用目录
    ├── docs/                   # 核心文档
    │   ├── PRD.md             # 产品需求文档
    │   ├── PROJECT_PLAN.md    # 项目实施计划
    │   └── DECISIONS.md       # 技术决策记录
    ├── contexts/              # 开发上下文
    │   └── CONTEXT_TASK*.md   # 任务上下文记录
    ├── reports/               # 各类报告
    │   ├── tests/             # 测试报告
    │   └── quality/           # 质量报告
    └── .solo-metadata.json   # 项目元数据

🎭 子代理介绍 ​

Product Manager (产品经理) ​

  • 职责: 需求收集、分析和PRD编写
  • 输出: .solo/docs/PRD.md
  • 触发: 当需要产品需求分析时自动调用

Architect (技术架构师) ​

  • 职责: 技术架构设计和项目规划
  • 输出: .solo/docs/PROJECT_PLAN.md, .solo/docs/DECISIONS.md
  • 触发: PRD完成后，需要技术设计时调用

Engineer (软件工程师) ​

  • 职责: TDD代码实现和重构
  • 输出: .solo/contexts/CONTEXT_*.md
  • 触发: 项目计划完成后，开始编码实现时调用

QA Engineer (质量保证工程师) ​

  • 职责: 测试设计和质量保证
  • 输出: .solo/reports/tests/TEST_*.md
  • 触发: 功能实现完成后，需要质量检查时调用

🔧 快速开始 ​

1. 安装配置 ​

SOLO模式作为Claude Code的扩展，通过自定义命令和子代理实现：

bash
# 使用SOLO主命令启动项目
/solo 创建一个用户管理API

# 查看项目状态
/solo__status

# 手动切换工作模式
/solo__switch architect

2. 与现有项目集成 ​

对于已有的API-First项目，SOLO可以：

  • 无侵入集成: 不影响现有代码结构
  • 渐进式采用: 可以只在特定阶段使用SOLO
  • 工具兼容: 与OpenAPI Generator、测试框架等无缝配合

3. 团队协作 ​

  • 角色清晰: 每个子代理对应明确的团队角色
  • 文档同步: 统一的文档结构便于团队协作
  • 版本控制: 核心文档可纳入Git管理

🌟 使用场景 ​

适合SOLO的项目 ​

  • ✅ 新启动的API项目
  • ✅ 需要系统化管理的复杂项目
  • ✅ 团队协作密集的项目
  • ✅ 质量要求高的企业级项目

可选使用SOLO的场景 ​

  • ⚠️ 快速原型项目（可简化使用）
  • ⚠️ 维护性项目（可部分使用）
  • ⚠️ 个人项目（可根据需要选择阶段）

📈 预期收益 ​

通过采用SOLO工作模式，团队可以期待：

  • 开发效率提升 30%: 标准化流程减少沟通成本
  • 代码质量提升: TDD+QA双重保障
  • 文档一致性: 统一的文档结构和维护流程
  • 团队协作改善: 明确的角色分工和工作流程
  • 项目可维护性增强: 完整的上下文记录和决策历史

🔗 相关链接 ​

SOLO工作模式让API-First开发更加系统化、标准化和高效化。

SOLO Development Guide

Copyright © 2024 Team