Files
myclaude/README-zh.md
ben chen 18042ae72e Update Chinese README and requirements-pilot command to align with latest workflow
- Updated Chinese README to match English version terminology
- Changed from spec-workflow to requirements-pilot throughout documentation
- Updated quality thresholds from 95% to 90% for consistency
- Replaced Sub-Agent terminology with Requirements-Driven workflow
- Updated agent names from spec-* to requirements-* pattern
- Improved requirements-pilot command structure with clearer phase separation
- Added mandatory user approval gate before implementation phase

🤖 Generated with [Claude Code](https://claude.ai/code)

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-04 14:23:25 +08:00

14 KiB
Raw Blame History

Claude Code 多智能体工作流系统

License: MIT Claude Code

将开发流程从手动命令链升级为自动化专家团队95%质量保证。

🚀 从手工作坊到自动化工厂

传统方式: 手动命令链,需要持续监督

/ask → /code → /test → /review → /optimize
# 1-2小时手动操作上下文污染质量不确定

现在: 一键自动化专家工作流

/requirements-pilot "实现JWT用户认证系统"
# 30分钟自动执行90%质量门控,零人工干预

🎯 核心价值主张

本仓库提供了一个Claude Code元框架,实现:

  • 🤖 多智能体协调: 专业AI团队并行工作
  • 质量门控自动化: 95%阈值自动优化循环
  • 🔄 工作流自动化: 从需求到生产就绪代码
  • 📊 上下文隔离: 每个智能体保持专注专业性,无污染

📋 两种主要使用模式

1. 🏭 Requirements-Driven 工作流(自动化专家团队)

架构: 需求导向工作流与质量门控

requirements-generate → requirements-code → requirements-review → (≥90%?) → requirements-testing
         ↑                                              ↓ (<90%)
         ←←←←←← 自动优化循环 ←←←←←←

使用方法:

# 一条命令完成完整开发工作流
/requirements-pilot "构建用户管理系统支持RBAC权限控制"

# 高级多阶段工作流
先使用 requirements-generate然后 requirements-code再用 requirements-review
如果评分 ≥90% 则使用 requirements-testing

质量评分体系 (总分100%):

  • 功能性 (40%)
  • 集成性 (25%)
  • 代码质量 (20%)
  • 性能 (15%)

2. 🎛️ 自定义命令(手动编排)

架构: 针对性专业技能的独立斜杠命令

/ask     # 技术咨询和架构指导
/spec    # 交互式需求 → 设计 → 任务工作流  
/code    # 功能实现,带约束条件
/debug   # 使用UltraThink方法论的系统化问题分析
/test    # 全面测试策略
/review  # 多维度代码验证
/optimize # 性能优化协调

渐进式示例:

# 逐步开发,手动控制每个环节
/ask "帮我理解微服务架构需求"
/spec "生成API网关规格说明" 
/code "实现带限流功能的网关"
/test "创建负载测试套件"
/review "验证安全性和性能"

🚀 快速开始

1. 配置设置

克隆或复制配置结构:

# 你的项目目录
├── commands/          # 12个专业斜杠命令
├── agents/           # 7个专家智能体配置  
└── CLAUDE.md         # 项目特定指导原则

2. 基本使用

完整功能开发:

/requirements-pilot "实现OAuth2认证支持刷新令牌"

手动开发流程:

/ask "可扩展微服务的设计原则"
/spec "OAuth2服务规格说明"
/code "实现OAuth2遵循安全最佳实践"

3. 预期输出

自动化工作流结果:

  • 需求确认90+质量评分
  • 实现就绪技术规格
  • 生产就绪代码,遵循最佳实践
  • 全面测试套件 (单元 + 集成 + 功能测试)
  • 90%+ 质量验证评分

🏗️ 架构概览

核心组件

Commands 目录 (/commands/)

  • 规格说明: /spec - 交互式需求 → 设计 → 任务
  • 咨询服务: /ask - 架构指导(不修改代码)
  • 实现工具: /code - 带约束的功能开发
  • 质量保证: /test, /review, /debug
  • 优化工具: /optimize, /refactor
  • 运维工具: /deploy-check, /cicd

Agents 目录 (/agents/)

  • requirements-generate: 为代码生成优化的技术规格生成
  • requirements-code: 最小架构开销的直接实现智能体
  • requirements-review: 专注功能性和可维护性的实用代码审查
  • requirements-testing: 专注功能验证的实用测试智能体
  • bugfix: 分析和修复软件缺陷的错误解决专家
  • bugfix-verify: 客观评估的修复验证专家
  • code: 直接实现的开发协调器
  • debug: UltraThink系统化问题分析
  • optimize: 性能优化协调

多智能体协调系统

4个核心专家:

  1. 需求生成专家 - 实现就绪的技术规格
  2. 代码实现专家 - 直接、实用的代码实现
  3. 质量审查专家 - 实用质量审查与评分
  4. 测试协调专家 - 功能验证和测试

关键特性:

  • 独立上下文: 专家间无上下文污染
  • 质量门控: 90%阈值自动进展判断
  • 迭代改进: 自动优化循环
  • 可追溯性: 完整规格 → 代码 → 测试追溯链

📚 工作流示例

企业用户认证系统

输入:

/requirements-pilot "企业JWT认证系统支持RBAC500并发用户集成现有LDAP"

自动化执行过程:

  1. 需求确认 (质量: 92/100) - 交互式澄清

    • 功能清晰度、技术特定性、实现完整性
    • 决策: ≥90%,进入实现阶段
  2. 第1轮 (质量: 83/100) - 基础实现

    • 问题: 错误处理不完整,集成问题
    • 决策: <90%,重新开始并改进
  3. 第2轮 (质量: 93/100) - 生产就绪

    • 决策: ≥90%,进入功能测试

最终交付物:

  • 质量评估的需求确认
  • 实现就绪技术规格
  • 带RBAC的实用JWT实现
  • 带正确错误处理的LDAP集成
  • 专注关键路径的功能测试套件

API网关开发

输入:

/ask "高性能API网关的设计考虑"
# (交互式咨询阶段)

/spec "微服务API网关支持限流和熔断器"
# (规格生成阶段)

/code "基于规格说明实现网关"
# (实现阶段)

结果:

  • 性能模式的架构咨询
  • 带负载均衡策略的详细规格
  • 带监控的生产就绪实现

🔧 高级使用模式

自定义工作流组合

# 调试 → 修复 → 验证工作流
先使用 debug 分析 [性能问题]
然后用 code 实现修复,
再用 spec-validation 确保质量

# 完整开发 + 优化流水线  
先使用 spec-generation 处理 [功能]
然后 spec-executor 进行实现,
再用 spec-validation 进行质量检查,
如果评分 ≥95% 则使用 spec-testing
最后用 optimize 确保生产就绪

质量驱动开发

# 迭代质量改进
先使用 spec-validation 评估 [现有代码]
如果评分 <95% 则用 code 基于反馈改进,
重复直到达到质量阈值

🎯 效益与影响

维度 手动命令 Requirements-Driven工作流
复杂度 手动触发每个步骤 一键启动完整流水线
质量 主观评估 90%客观评分
上下文 污染,需要/clear 隔离,无污染
专业性 AI角色切换 专注的专家
错误处理 手动发现/修复 自动优化
时间投入 1-2小时手动工作 30分钟自动化

🔮 关键创新

1. 专家深度 > 通才广度

每个智能体在独立上下文中专注各自领域专业知识,避免角色切换导致的质量下降。

2. 智能质量门控

90%客观评分,自动决策工作流进展或优化循环。

3. 完全自动化

一条命令触发端到端开发工作流,最少人工干预。

4. 持续改进

质量反馈驱动自动规格优化,创建智能改进循环。

🛠️ 配置说明

设置Sub-Agents

  1. 创建智能体配置: 将智能体文件复制到Claude Code配置中
  2. 配置命令: 设置工作流触发命令
  3. 自定义质量门控: 根据需要调整评分阈值

工作流定制

# 带特定质量要求的自定义工作流
先使用 spec-generation 处理 [严格安全要求]
然后 spec-executor 处理 [性能约束]
再用 spec-validation 设置 [90%最低阈值]
继续优化直到达到阈值

📖 命令参考

Requirements 工作流

  • /requirements-pilot - 完整的需求驱动开发工作流
  • 交互式需求确认 → 技术规格 → 实现 → 测试

开发命令

  • /ask - 架构咨询(不修改代码)
  • /code - 带约束的功能实现
  • /debug - 系统化问题分析
  • /test - 全面测试策略
  • /review - 多维度代码验证

优化命令

  • /optimize - 性能优化协调
  • /refactor - 带质量门控的代码重构
  • /deploy-check - 部署就绪验证

🤝 贡献

这是一个Claude Code配置框架。欢迎贡献

  1. 新智能体配置: 特定领域的专业专家
  2. 工作流模式: 新的自动化序列
  3. 质量指标: 增强的评分维度
  4. 命令扩展: 额外的开发阶段覆盖

📄 许可证

MIT许可证 - 详见LICENSE文件。

🙋 支持

  • 文档: 查看/commands//agents/获取详细规格
  • 问题: 使用GitHub issues报告bug和功能请求
  • 讨论: 分享工作流模式和定制化方案

🎉 开始使用

准备好转换你的开发工作流了吗?从这里开始:

/requirements-pilot "在这里描述你的第一个功能"

看着你的一行请求变成完整、经过测试、生产就绪的实现90%质量保证。

记住: 专业软件来自专业流程。需求驱动工作流为您提供一个永不疲倦、始终专业的虚拟开发团队。

让专业的AI做专业的事 - 开发从此变得优雅而高效。


🌟 实战案例

用户管理系统开发

需求: 构建企业内部用户管理系统500人规模RBAC权限控制集成OA系统

传统方式 (1-2小时):

1. /ask 用户认证需求 → 手动澄清需求
2. /code 实现认证逻辑 → 手动编写代码  
3. /test 生成测试用例 → 手动测试
4. /review 代码审查 → 手动修复问题
5. /optimize 性能优化 → 手动优化

Requirements-Driven方式 (30分钟自动):

/requirements-pilot "企业用户管理系统500人规模RBAC权限OA系统集成"

自动化执行结果:

  • 📋 完整规格文档: 需求分析、架构设计、实现计划
  • 💻 生产级代码: JWT最佳实践、完善异常处理、性能优化
  • 🧪 全面测试覆盖: 单元测试、集成测试、安全测试
  • 质量保证: 97/100评分所有维度均达标

微服务API网关

场景: 高并发微服务架构需要API网关进行流量管理

Step 1 - 需求理解:

/ask "设计高性能微服务API网关需要考虑哪些方面"

AI会深入询问

  • 预期QPS和并发量
  • 路由策略和负载均衡
  • 限流和熔断机制
  • 监控和日志需求

Step 2 - 规格生成:

/spec "基于讨论生成API网关完整规格"

生成内容:

  • requirements.md - 明确的用户故事和验收标准
  • design.md - 考虑高并发的架构设计
  • tasks.md - 详细的开发任务分解

Step 3 - 自动实现:

# 基于规格的自动化实现
先使用 spec-executor 基于规格实现代码,
然后用 spec-validation 验证质量,
如果评分 ≥95% 则用 spec-testing 生成测试

💡 最佳实践

1. 需求澄清优先

不要急于/spec先用/ask充分交流

# 错误做法:直接开始
/spec "用户管理系统"

# 正确做法:先理解需求  
/ask "企业用户管理系统需要考虑哪些方面?"
# 经过3-5轮对话澄清需求后
/spec "基于讨论,生成企业用户管理系统规格"

2. 渐进式复杂度

从简单功能开始,逐步增加复杂性:

# 第一阶段:基础功能
/requirements-pilot "用户注册登录基础功能"

# 第二阶段:权限管理
/requirements-pilot "在现有基础上添加RBAC权限系统"

# 第三阶段:系统集成
/requirements-pilot "集成LDAP和SSO单点登录"

3. 质量优先策略

利用质量门控确保每个阶段的代码质量:

# 设置更高质量要求
先使用 spec-generation 生成规格,
然后 spec-executor 实现,
再用 spec-validation 验证,
如果评分 <98% 则继续优化,
达标后用 spec-testing 和 optimize

🔍 深度解析:为什么这样更有效?

传统问题分析

上下文污染: 单一AI在不同角色间切换质量逐步下降

AI扮演产品经理 → 架构师 → 开发者 → 测试工程师 → 优化专家
随着对话长度增加AI的专业度和准确性下降

手动管理开销: 每个环节都需要人工判断和干预

是否需求已完整? → 设计是否合理? → 代码是否正确? → 测试是否充分?
每个决策点都可能中断,需要重新组织思路

Requirements-Driven解决方案

专业化隔离: 每个专家在独立上下文中工作

规格专家(独立) + 实现专家(独立) + 质量专家(独立) + 测试专家(独立)
专业深度最大化,角色混淆最小化

自动化决策: 基于客观指标的自动流程控制

质量评分 ≥90% → 自动进入下一阶段
质量评分 <90% → 自动返回优化,无需人工判断

🚀 开始你的AI工厂

从手工作坊升级到自动化工厂,只需要:

  1. 配置一次: 设置Requirements-Driven智能体和自定义命令
  2. 使用一生: 每个项目都能享受专业AI团队服务
  3. 持续改进: 工作流模式不断优化,开发效率持续提升

记住: 在AI时代Requirements-Driven工作流让你拥有了一个永不疲倦、始终专业的虚拟开发团队。

让专业的AI做专业的事开发从此变得优雅而高效。