mirror of
https://github.com/cexll/myclaude.git
synced 2026-02-14 03:31:58 +08:00
Add comprehensive documentation and multi-agent workflow system
- Add English and Chinese README.md with complete project documentation - Add agents/ directory with 7 specialized sub-agent configurations - Add spec-execution.md and spec-workflow.md commands - Add .gitignore for Claude Code project structure - Document two primary usage patterns: sub-agent workflows and custom commands - Include architecture overview, quick start guide, and real-world examples - Establish 95% quality gate automation with iterative improvement loops 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
ben chen
466
README-zh.md
Normal file
466
README-zh.md
Normal file
@@ -0,0 +1,466 @@
|
||||
# Claude Code 多智能体工作流系统
|
||||
|
||||
[](https://opensource.org/licenses/MIT)
|
||||
[](https://claude.ai/code)
|
||||
|
||||
> 将开发流程从手动命令链升级为自动化专家团队，95%质量保证。
|
||||
|
||||
## 🚀 从手工作坊到自动化工厂
|
||||
|
||||
**传统方式**: 手动命令链，需要持续监督
|
||||
```bash
|
||||
/ask → /code → /test → /review → /optimize
|
||||
# 1-2小时手动操作，上下文污染，质量不确定
|
||||
```
|
||||
|
||||
**现在**: 一键自动化专家工作流
|
||||
```bash
|
||||
/spec-workflow "实现JWT用户认证系统"
|
||||
# 30分钟自动执行，95%质量门控，零人工干预
|
||||
```
|
||||
|
||||
## 🎯 核心价值主张
|
||||
|
||||
本仓库提供了一个**Claude Code元框架**，实现：
|
||||
|
||||
- **🤖 多智能体协调**: 专业AI团队并行工作
|
||||
- **⚡ 质量门控自动化**: 95%阈值自动优化循环
|
||||
- **🔄 工作流自动化**: 从需求到生产就绪代码
|
||||
- **📊 上下文隔离**: 每个智能体保持专注专业性，无污染
|
||||
|
||||
## 📋 两种主要使用模式
|
||||
|
||||
### 1. 🏭 Sub-Agent 工作流（自动化专家团队）
|
||||
|
||||
**架构**: 并行专家协调与质量门控
|
||||
```
|
||||
spec-generation → spec-executor → spec-validation → (≥95%?) → spec-testing
|
||||
↑ ↓ (<95%)
|
||||
←←←←←← 自动优化循环，直到质量达标 ←←←←←←
|
||||
```
|
||||
|
||||
**使用方法**:
|
||||
```bash
|
||||
# 一条命令完成完整开发工作流
|
||||
/spec-workflow "构建用户管理系统，支持RBAC权限控制"
|
||||
|
||||
# 高级多阶段工作流
|
||||
先使用 spec-generation，然后 spec-executor，再用 spec-validation，
|
||||
如果评分 ≥95% 则使用 spec-testing，最后用 optimize 优化
|
||||
```
|
||||
|
||||
**质量评分体系** (总分100%):
|
||||
- 需求符合度 (30%)
|
||||
- 代码质量 (25%)
|
||||
- 安全性 (20%)
|
||||
- 性能 (15%)
|
||||
- 测试覆盖 (10%)
|
||||
|
||||
### 2. 🎛️ 自定义命令（手动编排）
|
||||
|
||||
**架构**: 针对性专业技能的独立斜杠命令
|
||||
```bash
|
||||
/ask # 技术咨询和架构指导
|
||||
/spec # 交互式需求 → 设计 → 任务工作流
|
||||
/code # 功能实现，带约束条件
|
||||
/debug # 使用UltraThink方法论的系统化问题分析
|
||||
/test # 全面测试策略
|
||||
/review # 多维度代码验证
|
||||
/optimize # 性能优化协调
|
||||
```
|
||||
|
||||
**渐进式示例**:
|
||||
```bash
|
||||
# 逐步开发，手动控制每个环节
|
||||
/ask "帮我理解微服务架构需求"
|
||||
/spec "生成API网关规格说明"
|
||||
/code "实现带限流功能的网关"
|
||||
/test "创建负载测试套件"
|
||||
/review "验证安全性和性能"
|
||||
```
|
||||
|
||||
## 🚀 快速开始
|
||||
|
||||
### 1. 配置设置
|
||||
|
||||
克隆或复制配置结构:
|
||||
```bash
|
||||
# 你的项目目录
|
||||
├── commands/ # 12个专业斜杠命令
|
||||
├── agents/ # 7个专家智能体配置
|
||||
└── CLAUDE.md # 项目特定指导原则
|
||||
```
|
||||
|
||||
### 2. 基本使用
|
||||
|
||||
**完整功能开发**:
|
||||
```bash
|
||||
/spec-workflow "实现OAuth2认证，支持刷新令牌"
|
||||
```
|
||||
|
||||
**手动开发流程**:
|
||||
```bash
|
||||
/ask "可扩展微服务的设计原则"
|
||||
/spec "OAuth2服务规格说明"
|
||||
/code "实现OAuth2，遵循安全最佳实践"
|
||||
```
|
||||
|
||||
### 3. 预期输出
|
||||
|
||||
**自动化工作流结果**:
|
||||
- ✅ 完整规格说明 (requirements.md, design.md, tasks.md)
|
||||
- ✅ 生产就绪代码，遵循安全最佳实践
|
||||
- ✅ 全面测试套件 (单元 + 集成 + 安全测试)
|
||||
- ✅ 95%+ 质量验证评分
|
||||
|
||||
## 🏗️ 架构概览
|
||||
|
||||
### 核心组件
|
||||
|
||||
#### **Commands 目录** (`/commands/`)
|
||||
- **规格说明**: `/spec` - 交互式需求 → 设计 → 任务
|
||||
- **咨询服务**: `/ask` - 架构指导（不修改代码）
|
||||
- **实现工具**: `/code` - 带约束的功能开发
|
||||
- **质量保证**: `/test`, `/review`, `/debug`
|
||||
- **优化工具**: `/optimize`, `/refactor`
|
||||
- **运维工具**: `/deploy-check`, `/cicd`
|
||||
|
||||
#### **Agents 目录** (`/agents/`)
|
||||
- **spec-generation**: 自动化规格说明工作流
|
||||
- **spec-executor**: 带进度跟踪的实现协调器
|
||||
- **spec-validation**: 多维度质量评分 (0-100%)
|
||||
- **spec-testing**: 全面测试策略协调
|
||||
- **code**: 直接实现的开发协调器
|
||||
- **debug**: UltraThink系统化问题分析
|
||||
- **optimize**: 性能优化协调
|
||||
|
||||
### 多智能体协调系统
|
||||
|
||||
**4个核心专家**:
|
||||
1. **规格生成专家** - 需求、设计、实现规划
|
||||
2. **实现执行专家** - 带任务跟踪的代码开发
|
||||
3. **质量验证专家** - 多维度评分与可执行反馈
|
||||
4. **测试协调专家** - 全面测试策略与执行
|
||||
|
||||
**关键特性**:
|
||||
- **独立上下文**: 专家间无上下文污染
|
||||
- **质量门控**: 95%阈值自动进展判断
|
||||
- **迭代改进**: 自动优化循环
|
||||
- **可追溯性**: 完整规格 → 代码 → 测试追溯链
|
||||
|
||||
## 📚 工作流示例
|
||||
|
||||
### 企业用户认证系统
|
||||
|
||||
**输入**:
|
||||
```bash
|
||||
/spec-workflow "企业JWT认证系统，支持RBAC，500并发用户，集成现有LDAP"
|
||||
```
|
||||
|
||||
**自动化执行过程**:
|
||||
1. **第1轮** (质量: 83/100) - 基础实现
|
||||
- 问题: JWT密钥硬编码，缺少密码复杂度验证
|
||||
- **决策**: <95%，重新开始并改进
|
||||
|
||||
2. **第2轮** (质量: 91/100) - 安全改进
|
||||
- 问题: 异常处理不完善，性能未优化
|
||||
- **决策**: <95%，继续优化
|
||||
|
||||
3. **第3轮** (质量: 97/100) - 生产就绪
|
||||
- **决策**: ≥95%，进入全面测试阶段
|
||||
|
||||
**最终交付物**:
|
||||
- 完整EARS格式需求文档
|
||||
- 安全加固的JWT实现
|
||||
- 带角色层级的RBAC
|
||||
- 带错误处理的LDAP集成
|
||||
- 全面测试套件（单元 + 集成 + 安全）
|
||||
|
||||
### API网关开发
|
||||
|
||||
**输入**:
|
||||
```bash
|
||||
/ask "高性能API网关的设计考虑"
|
||||
# (交互式咨询阶段)
|
||||
|
||||
/spec "微服务API网关，支持限流和熔断器"
|
||||
# (规格生成阶段)
|
||||
|
||||
/code "基于规格说明实现网关"
|
||||
# (实现阶段)
|
||||
```
|
||||
|
||||
**结果**:
|
||||
- 性能模式的架构咨询
|
||||
- 带负载均衡策略的详细规格
|
||||
- 带监控的生产就绪实现
|
||||
|
||||
## 🔧 高级使用模式
|
||||
|
||||
### 自定义工作流组合
|
||||
|
||||
```bash
|
||||
# 调试 → 修复 → 验证工作流
|
||||
先使用 debug 分析 [性能问题]，
|
||||
然后用 code 实现修复，
|
||||
再用 spec-validation 确保质量
|
||||
|
||||
# 完整开发 + 优化流水线
|
||||
先使用 spec-generation 处理 [功能]，
|
||||
然后 spec-executor 进行实现，
|
||||
再用 spec-validation 进行质量检查，
|
||||
如果评分 ≥95% 则使用 spec-testing，
|
||||
最后用 optimize 确保生产就绪
|
||||
```
|
||||
|
||||
### 质量驱动开发
|
||||
|
||||
```bash
|
||||
# 迭代质量改进
|
||||
先使用 spec-validation 评估 [现有代码]，
|
||||
如果评分 <95% 则用 code 基于反馈改进，
|
||||
重复直到达到质量阈值
|
||||
```
|
||||
|
||||
## 🎯 效益与影响
|
||||
|
||||
| 维度 | 传统Slash命令 | Sub-Agent自动工作流 |
|
||||
|------|-------------|------------------|
|
||||
| **复杂度** | 手动触发每个步骤 | 一键启动完整流水线 |
|
||||
| **质量** | 主观评估 | 95%客观评分 |
|
||||
| **上下文** | 污染，需要/clear | 隔离，无污染 |
|
||||
| **专业性** | AI角色切换 | 专注的专家 |
|
||||
| **错误处理** | 手动发现/修复 | 自动优化 |
|
||||
| **时间投入** | 1-2小时手动工作 | 30分钟自动化 |
|
||||
|
||||
## 🔮 关键创新
|
||||
|
||||
### 1. **专家深度 > 通才广度**
|
||||
每个智能体在独立上下文中专注各自领域专业知识，避免角色切换导致的质量下降。
|
||||
|
||||
### 2. **智能质量门控**
|
||||
95%客观评分，自动决策工作流进展或优化循环。
|
||||
|
||||
### 3. **完全自动化**
|
||||
一条命令触发端到端开发工作流，最少人工干预。
|
||||
|
||||
### 4. **持续改进**
|
||||
质量反馈驱动自动规格优化，创建智能改进循环。
|
||||
|
||||
## 🛠️ 配置说明
|
||||
|
||||
### 设置Sub-Agents
|
||||
|
||||
1. **创建智能体配置**: 将智能体文件复制到Claude Code配置中
|
||||
2. **配置命令**: 设置工作流触发命令
|
||||
3. **自定义质量门控**: 根据需要调整评分阈值
|
||||
|
||||
### 工作流定制
|
||||
|
||||
```bash
|
||||
# 带特定质量要求的自定义工作流
|
||||
先使用 spec-generation 处理 [严格安全要求]，
|
||||
然后 spec-executor 处理 [性能约束]，
|
||||
再用 spec-validation 设置 [90%最低阈值]，
|
||||
继续优化直到达到阈值
|
||||
```
|
||||
|
||||
## 📖 命令参考
|
||||
|
||||
### 规格说明工作流
|
||||
- `/spec` - 交互式需求 → 设计 → 任务
|
||||
- `/spec-workflow` - 自动化端到端规格 + 实现
|
||||
|
||||
### 开发命令
|
||||
- `/ask` - 架构咨询（不修改代码）
|
||||
- `/code` - 带约束的功能实现
|
||||
- `/debug` - 系统化问题分析
|
||||
- `/test` - 全面测试策略
|
||||
- `/review` - 多维度代码验证
|
||||
|
||||
### 优化命令
|
||||
- `/optimize` - 性能优化协调
|
||||
- `/refactor` - 带质量门控的代码重构
|
||||
- `/deploy-check` - 部署就绪验证
|
||||
|
||||
## 🤝 贡献
|
||||
|
||||
这是一个Claude Code配置框架。欢迎贡献：
|
||||
|
||||
1. **新智能体配置**: 特定领域的专业专家
|
||||
2. **工作流模式**: 新的自动化序列
|
||||
3. **质量指标**: 增强的评分维度
|
||||
4. **命令扩展**: 额外的开发阶段覆盖
|
||||
|
||||
## 📄 许可证
|
||||
|
||||
MIT许可证 - 详见[LICENSE](LICENSE)文件。
|
||||
|
||||
## 🙋 支持
|
||||
|
||||
- **文档**: 查看`/commands/`和`/agents/`获取详细规格
|
||||
- **问题**: 使用GitHub issues报告bug和功能请求
|
||||
- **讨论**: 分享工作流模式和定制化方案
|
||||
|
||||
---
|
||||
|
||||
## 🎉 开始使用
|
||||
|
||||
准备好转换你的开发工作流了吗？从这里开始：
|
||||
|
||||
```bash
|
||||
/spec-workflow "在这里描述你的第一个功能"
|
||||
```
|
||||
|
||||
看着你的一行请求变成完整、经过测试、生产就绪的实现，95%质量保证。
|
||||
|
||||
**记住**: 好的软件来自好的流程，好的流程来自专业的团队。Sub-agents让你拥有一个永不疲倦、始终专业的虚拟开发团队。
|
||||
|
||||
*让专业的AI做专业的事 - 开发从此变得优雅而高效。*
|
||||
|
||||
---
|
||||
|
||||
## 🌟 实战案例
|
||||
|
||||
### 用户管理系统开发
|
||||
|
||||
**需求**: 构建企业内部用户管理系统，500人规模，RBAC权限控制，集成OA系统
|
||||
|
||||
**传统方式** (1-2小时):
|
||||
```bash
|
||||
1. /ask 用户认证需求 → 手动澄清需求
|
||||
2. /code 实现认证逻辑 → 手动编写代码
|
||||
3. /test 生成测试用例 → 手动测试
|
||||
4. /review 代码审查 → 手动修复问题
|
||||
5. /optimize 性能优化 → 手动优化
|
||||
```
|
||||
|
||||
**Sub-Agents方式** (30分钟自动):
|
||||
```bash
|
||||
/spec-workflow "企业用户管理系统，500人规模，RBAC权限，OA系统集成"
|
||||
```
|
||||
|
||||
**自动化执行结果**:
|
||||
- 📋 **完整规格文档**: 需求分析、架构设计、实现计划
|
||||
- 💻 **生产级代码**: JWT最佳实践、完善异常处理、性能优化
|
||||
- 🧪 **全面测试覆盖**: 单元测试、集成测试、安全测试
|
||||
- ✅ **质量保证**: 97/100评分，所有维度均达标
|
||||
|
||||
### 微服务API网关
|
||||
|
||||
**场景**: 高并发微服务架构，需要API网关进行流量管理
|
||||
|
||||
**Step 1 - 需求理解**:
|
||||
```bash
|
||||
/ask "设计高性能微服务API网关，需要考虑哪些方面？"
|
||||
```
|
||||
|
||||
AI会深入询问：
|
||||
- 预期QPS和并发量
|
||||
- 路由策略和负载均衡
|
||||
- 限流和熔断机制
|
||||
- 监控和日志需求
|
||||
|
||||
**Step 2 - 规格生成**:
|
||||
```bash
|
||||
/spec "基于讨论，生成API网关完整规格"
|
||||
```
|
||||
|
||||
生成内容：
|
||||
- **requirements.md** - 明确的用户故事和验收标准
|
||||
- **design.md** - 考虑高并发的架构设计
|
||||
- **tasks.md** - 详细的开发任务分解
|
||||
|
||||
**Step 3 - 自动实现**:
|
||||
```bash
|
||||
# 基于规格的自动化实现
|
||||
先使用 spec-executor 基于规格实现代码，
|
||||
然后用 spec-validation 验证质量，
|
||||
如果评分 ≥95% 则用 spec-testing 生成测试
|
||||
```
|
||||
|
||||
## 💡 最佳实践
|
||||
|
||||
### 1. 需求澄清优先
|
||||
|
||||
**不要急于/spec，先用/ask充分交流**
|
||||
|
||||
```bash
|
||||
# 错误做法：直接开始
|
||||
/spec "用户管理系统"
|
||||
|
||||
# 正确做法：先理解需求
|
||||
/ask "企业用户管理系统需要考虑哪些方面？"
|
||||
# 经过3-5轮对话澄清需求后
|
||||
/spec "基于讨论，生成企业用户管理系统规格"
|
||||
```
|
||||
|
||||
### 2. 渐进式复杂度
|
||||
|
||||
从简单功能开始，逐步增加复杂性：
|
||||
|
||||
```bash
|
||||
# 第一阶段：基础功能
|
||||
/spec-workflow "用户注册登录基础功能"
|
||||
|
||||
# 第二阶段：权限管理
|
||||
/spec-workflow "在现有基础上添加RBAC权限系统"
|
||||
|
||||
# 第三阶段：系统集成
|
||||
/spec-workflow "集成LDAP和SSO单点登录"
|
||||
```
|
||||
|
||||
### 3. 质量优先策略
|
||||
|
||||
利用质量门控确保每个阶段的代码质量：
|
||||
|
||||
```bash
|
||||
# 设置更高质量要求
|
||||
先使用 spec-generation 生成规格，
|
||||
然后 spec-executor 实现，
|
||||
再用 spec-validation 验证，
|
||||
如果评分 <98% 则继续优化，
|
||||
达标后用 spec-testing 和 optimize
|
||||
```
|
||||
|
||||
## 🔍 深度解析：为什么这样更有效？
|
||||
|
||||
### 传统问题分析
|
||||
|
||||
**上下文污染**: 单一AI在不同角色间切换，质量逐步下降
|
||||
```
|
||||
AI扮演产品经理 → 架构师 → 开发者 → 测试工程师 → 优化专家
|
||||
随着对话长度增加，AI的专业度和准确性下降
|
||||
```
|
||||
|
||||
**手动管理开销**: 每个环节都需要人工判断和干预
|
||||
```
|
||||
是否需求已完整？ → 设计是否合理？ → 代码是否正确？ → 测试是否充分？
|
||||
每个决策点都可能中断，需要重新组织思路
|
||||
```
|
||||
|
||||
### Sub-Agents解决方案
|
||||
|
||||
**专业化隔离**: 每个专家在独立上下文中工作
|
||||
```
|
||||
规格专家(独立) + 实现专家(独立) + 质量专家(独立) + 测试专家(独立)
|
||||
专业深度最大化，角色混淆最小化
|
||||
```
|
||||
|
||||
**自动化决策**: 基于客观指标的自动流程控制
|
||||
```
|
||||
质量评分 ≥95% → 自动进入下一阶段
|
||||
质量评分 <95% → 自动返回优化，无需人工判断
|
||||
```
|
||||
|
||||
## 🚀 开始你的AI工厂
|
||||
|
||||
从手工作坊升级到自动化工厂，只需要：
|
||||
|
||||
1. **配置一次**: 设置Sub-Agents和自定义命令
|
||||
2. **使用一生**: 每个项目都能享受专业AI团队服务
|
||||
3. **持续改进**: 工作流模式不断优化，开发效率持续提升
|
||||
|
||||
**记住**: 在AI时代，Sub-Agents让你拥有了一个永不疲倦、始终专业的虚拟开发团队。
|
||||
|
||||
*让专业的AI做专业的事，开发从此变得优雅而高效。*
|
||||
Reference in New Issue
Block a user