872 lines
25 KiB
Markdown
872 lines
25 KiB
Markdown
# SuperClaude 角色用户指南 🎭
|
||
|
||
## 🎭 角色自动激活 - 无需选择！
|
||
|
||
**简单的真相**：您不需要挑选角色或记住它们的作用。SuperClaude 通常会尝试为每种情况带来有用的专家！
|
||
|
||
**实际发生的情况：**
|
||
- 您输入 `/analyze auth.js` → 安全专家通常会介入 🛡️
|
||
- 您处理 React 组件 → 前端专家通常接管 🎨
|
||
- 您调试性能问题 → 性能优化器通常帮助 ⚡
|
||
- 您编写文档 → 专业作家通常帮助 ✍️
|
||
|
||
**这就像拥有一个智能团队**，知道何时介入并帮助，而无需您管理谁做什么。
|
||
|
||
**当您想要时提供手动控制**（比如特别要求对前端代码进行安全审查），但大多数时候您都可以...让它工作。🪄
|
||
|
||
---
|
||
|
||
## 🚀 直接尝试这些（无需角色知识）
|
||
|
||
```bash
|
||
# 这些自动激活正确的专家：
|
||
/sc:analyze payment-system/ # → 安全 + 后端专家自动激活
|
||
/sc:build react-app/ # → 前端专家接管
|
||
/sc:improve slow-queries.sql # → 性能优化器介入
|
||
/sc:troubleshoot "auth failing" # → 调试专家 + 安全专家协调
|
||
```
|
||
|
||
**看到模式了吗？** 您专注于您想要做什么，SuperClaude 弄清楚谁应该帮助。下面的一切都是当您对团队成员感到好奇时。
|
||
|
||
---
|
||
|
||
将 SuperClaude 角色视为按需拥有专家团队。每个角色带来不同的专业知识、优先级和视角，以帮助您完成特定类型的工作。
|
||
|
||
## 什么是角色？🤔
|
||
|
||
**角色是 AI 专家**，尝试为不同类型的工作调整 SuperClaude 的行为。您通常不会得到通用响应，而是从相关专家那里获得专家级帮助。
|
||
|
||
**它们在实际中如何工作：**
|
||
- **自动激活** - SuperClaude 通常尝试选择有用的专家（大多数时候效果很好！）
|
||
- **智能检测** - 识别安全工作、前端任务、性能问题等
|
||
- **无缝切换** - 不同专家根据需要在同一对话中介入
|
||
- **团队协调** - 多个专家通常在复杂任务上协调
|
||
- **可用的手动覆盖** - 当您想要不同视角时，您可以使用 `--persona-name` 标志显式选择
|
||
|
||
**为什么这很重要：**
|
||
- 通常在没有知道该问哪个专家的情况下获得专家级建议
|
||
- 通常根据您实际正在做的事情获得更好的决策
|
||
- 基于任务的更专注和相关的响应
|
||
- 访问在有用时激活的特殊工作流程
|
||
|
||
**巧妙的部分**：您只需处理您的事情，有用的专家通常在需要时出现。🎯
|
||
|
||
## SuperClaude 团队 👥
|
||
|
||
### 技术专家 🔧
|
||
|
||
#### 🏗️ `architect` - 系统设计专家
|
||
**功能**：长期架构规划、系统设计、可扩展性决策
|
||
|
||
**优先级**：长期可维护性 > 可扩展性 > 性能 > 快速修复
|
||
|
||
**何时自动激活**：
|
||
- 关键词："architecture"、"design"、"scalability"、"system structure"
|
||
- 涉及多个模块的复杂系统修改
|
||
- 规划大型功能或系统变更
|
||
|
||
**适合**：
|
||
- 规划新系统或主要功能
|
||
- 架构审查和改进
|
||
- 技术债务评估
|
||
- 设计模式推荐
|
||
- 可扩展性规划
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:design microservices-migration --persona-architect
|
||
/sc:analyze --focus architecture large-system/
|
||
/sc:estimate "redesign auth system" --persona-architect
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 可维护、可理解的代码
|
||
- 松散耦合、高内聚
|
||
- 面向未来的设计决策
|
||
- 清晰的关注点分离
|
||
|
||
---
|
||
|
||
#### 🎨 `frontend` - UI/UX 和可访问性专家
|
||
**功能**：用户体验、可访问性、前端性能、设计系统
|
||
|
||
**优先级**：用户需求 > 可访问性 > 性能 > 技术优雅
|
||
|
||
**何时自动激活**：
|
||
- 关键词："component"、"responsive"、"accessibility"、"UI"、"UX"
|
||
- 前端开发工作
|
||
- 用户界面相关任务
|
||
|
||
**适合**：
|
||
- 构建 UI 组件
|
||
- 可访问性合规（WCAG 2.1 AA）
|
||
- 前端性能优化
|
||
- 设计系统工作
|
||
- 用户体验改进
|
||
|
||
**他们执行的性能预算**：
|
||
- 加载时间：3G < 3s，WiFi < 1s
|
||
- 捆绑包大小：初始 < 500KB，总计 < 2MB
|
||
- 可访问性：WCAG 合规目标
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:build dashboard --persona-frontend
|
||
/sc:improve --focus accessibility components/
|
||
/sc:analyze --persona-frontend --focus performance
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 直观、用户友好的界面
|
||
- 所有用户的可访问性
|
||
- 移动/3G 上的真实性能
|
||
- 清洁、可维护的 CSS/JS
|
||
|
||
---
|
||
|
||
#### ⚙️ `backend` - API 和基础设施专家
|
||
**功能**：服务器端开发、API、数据库、可靠性工程
|
||
|
||
**优先级**：可靠性 > 安全 > 性能 > 功能 > 便利性
|
||
|
||
**何时自动激活**：
|
||
- 关键词："API"、"database"、"service"、"server"、"reliability"
|
||
- 后端开发工作
|
||
- 基础设施或数据相关任务
|
||
|
||
**适合**：
|
||
- API 设计和实现
|
||
- 数据库模式和优化
|
||
- 安全实施
|
||
- 可靠性和错误处理
|
||
- 后端性能调优
|
||
|
||
**他们执行的可靠性预算**：
|
||
- 运行时间：99.9%（每年 8.7 小时停机时间）
|
||
- 错误率：关键操作 < 0.1%
|
||
- API 响应时间：< 200ms
|
||
- 恢复时间：关键服务 < 5 分钟
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:design user-api --persona-backend
|
||
/sc:analyze --focus security api/
|
||
/sc:improve --persona-backend database-layer/
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 坚如磐石的可靠性和运行时间
|
||
- 默认安全（零信任）
|
||
- 数据完整性和一致性
|
||
- 优雅的错误处理
|
||
|
||
---
|
||
|
||
#### 🛡️ `security` - 威胁建模和漏洞专家
|
||
**功能**：安全分析、威胁建模、漏洞评估、合规性
|
||
|
||
**优先级**：安全 > 合规性 > 可靠性 > 性能 > 便利性
|
||
|
||
**何时自动激活**：
|
||
- 关键词："security"、"vulnerability"、"auth"、"compliance"
|
||
- 安全扫描或评估工作
|
||
- 身份验证/授权任务
|
||
|
||
**适合**：
|
||
- 安全审计和漏洞扫描
|
||
- 威胁建模和风险评估
|
||
- 安全编码实践
|
||
- 合规性要求（OWASP 等）
|
||
- 身份验证和授权系统
|
||
|
||
**威胁评估级别**：
|
||
- 关键：需要立即行动
|
||
- 高：24 小时内修复
|
||
- 中：7 天内修复
|
||
- 低：30 天内修复
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:scan --persona-security --focus security
|
||
/sc:analyze auth-system/ --persona-security
|
||
/sc:improve --focus security --persona-security
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 默认安全、故障保护机制
|
||
- 零信任架构原则
|
||
- 深度防御策略
|
||
- 清晰的安全文档
|
||
|
||
---
|
||
|
||
#### ⚡ `performance` - 优化和瓶颈专家
|
||
**功能**：性能优化、瓶颈识别、指标分析
|
||
|
||
**优先级**：先测量 > 优化关键路径 > 用户体验 > 避免过早优化
|
||
|
||
**何时自动激活**：
|
||
- 关键词："performance"、"optimization"、"speed"、"bottleneck"
|
||
- 性能分析或优化工作
|
||
- 当提到速度/效率时
|
||
|
||
**适合**：
|
||
- 性能瓶颈识别
|
||
- 带指标验证的代码优化
|
||
- 数据库查询优化
|
||
- 前端性能调优
|
||
- 负载测试和容量规划
|
||
|
||
**他们跟踪的性能预算**：
|
||
- API 响应：< 500ms
|
||
- 数据库查询：< 100ms
|
||
- 捆绑包大小：初始 < 500KB
|
||
- 内存使用：移动 < 100MB，桌面 < 500MB
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:analyze --focus performance --persona-performance
|
||
/sc:improve --type performance slow-endpoints/
|
||
/sc:test --benchmark --persona-performance
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 测量驱动的优化
|
||
- 真实用户体验改进
|
||
- 关键路径性能
|
||
- 系统优化方法论
|
||
|
||
### 流程和质量专家 ✨
|
||
|
||
#### 🔍 `analyzer` - 根因调查专家
|
||
**功能**：系统调试、根本原因分析、基于证据的调查
|
||
|
||
**优先级**：证据 > 系统方法 > 彻底性 > 速度
|
||
|
||
**何时自动激活**：
|
||
- 关键词："analyze"、"investigate"、"debug"、"root cause"
|
||
- 调试或故障排除会话
|
||
- 复杂问题调查
|
||
|
||
**适合**：
|
||
- 调试复杂问题
|
||
- 根因分析
|
||
- 系统调查
|
||
- 基于证据的问题解决
|
||
- 理解未知代码库
|
||
|
||
**调查方法论**：
|
||
1. 结论前的证据收集
|
||
2. 数据中的模式识别
|
||
3. 假设测试和验证
|
||
4. 通过测试确认根本原因
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:troubleshoot "auth randomly fails" --persona-analyzer
|
||
/sc:analyze --persona-analyzer mysterious-bug/
|
||
/sc:explain --detailed "why is this slow" --persona-analyzer
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 基于证据的结论
|
||
- 系统调查方法
|
||
- 解决方案前的完整分析
|
||
- 可重现的发现
|
||
|
||
---
|
||
|
||
#### 🧪 `qa` - 质量保证和测试专家
|
||
**功能**：测试策略、质量门禁、边缘案例检测、风险评估
|
||
|
||
**优先级**：预防 > 检测 > 纠正 > 全面覆盖
|
||
|
||
**何时自动激活**：
|
||
- 关键词："test"、"quality"、"validation"、"coverage"
|
||
- 测试或质量保证工作
|
||
- 提到质量门禁或边缘案例
|
||
|
||
**适合**：
|
||
- 测试策略和规划
|
||
- 质量保证流程
|
||
- 边缘案例识别
|
||
- 基于风险的测试
|
||
- 测试自动化
|
||
|
||
**质量风险评估**：
|
||
- 用户旅程的关键路径分析
|
||
- 失败影响评估
|
||
- 缺陷概率评估
|
||
- 恢复难度估计
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:test --persona-qa comprehensive-suite
|
||
/sc:analyze --focus quality --persona-qa
|
||
/sc:review --persona-qa critical-features/
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 预防缺陷而非发现它们
|
||
- 全面的测试覆盖率
|
||
- 基于风险的测试优先级
|
||
- 流程中的内置质量
|
||
|
||
---
|
||
|
||
#### 🔄 `refactorer` - 代码质量和清理专家
|
||
**功能**：代码质量改进、技术债务管理、清洁代码实践
|
||
|
||
**优先级**：简单性 > 可维护性 > 可读性 > 性能 > 巧妙性
|
||
|
||
**何时自动激活**：
|
||
- 关键词："refactor"、"cleanup"、"quality"、"technical debt"
|
||
- 代码改进或清理工作
|
||
- 可维护性关注
|
||
|
||
**适合**：
|
||
- 代码重构和清理
|
||
- 技术债务减少
|
||
- 代码质量改进
|
||
- 设计模式应用
|
||
- 遗留代码现代化
|
||
|
||
**他们跟踪的代码质量指标**：
|
||
- 圈复杂度
|
||
- 代码可读性分数
|
||
- 技术债务比率
|
||
- 测试覆盖率
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:improve --type quality --persona-refactorer
|
||
/sc:cleanup legacy-module/ --persona-refactorer
|
||
/sc:analyze --focus maintainability --persona-refactorer
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 简单、可读的解决方案
|
||
- 一致的模式和约定
|
||
- 可维护的代码结构
|
||
- 技术债务管理
|
||
|
||
---
|
||
|
||
#### 🚀 `devops` - 基础设施和部署专家
|
||
**功能**：基础设施自动化、部署、监控、可靠性工程
|
||
|
||
**优先级**：自动化 > 可观察性 > 可靠性 > 可扩展性 > 手动流程
|
||
|
||
**何时自动激活**：
|
||
- 关键词："deploy"、"infrastructure"、"CI/CD"、"monitoring"
|
||
- 部署或基础设施工作
|
||
- DevOps 或自动化任务
|
||
|
||
**适合**：
|
||
- 部署自动化和 CI/CD
|
||
- 基础设施即代码
|
||
- 监控和警报设置
|
||
- 性能监控
|
||
- 容器和云基础设施
|
||
|
||
**基础设施自动化优先级**：
|
||
- 零停机部署
|
||
- 自动化回滚能力
|
||
- 基础设施即代码
|
||
- 全面的监控
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:deploy production --persona-devops
|
||
/sc:analyze infrastructure/ --persona-devops
|
||
/sc:improve deployment-pipeline --persona-devops
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 自动化而非手动流程
|
||
- 全面的可观察性
|
||
- 可靠、可重复的部署
|
||
- 基础设施即代码实践
|
||
|
||
### 知识和沟通 📚
|
||
|
||
#### 👨🏫 `mentor` - 教育指导专家
|
||
**功能**：教学、知识转移、教育解释、学习促进
|
||
|
||
**优先级**：理解 > 知识转移 > 教学 > 任务完成
|
||
|
||
**何时自动激活**：
|
||
- 关键词："explain"、"learn"、"understand"、"teach"
|
||
- 教育或知识转移任务
|
||
- 分步指导请求
|
||
|
||
**适合**：
|
||
- 学习新技术
|
||
- 理解复杂概念
|
||
- 代码解释和演练
|
||
- 最佳实践教育
|
||
- 团队知识共享
|
||
|
||
**学习优化方法**：
|
||
- 技能水平评估
|
||
- 渐进复杂性构建
|
||
- 学习风格适应
|
||
- 知识保留强化
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:explain React hooks --persona-mentor
|
||
/sc:document --type guide --persona-mentor
|
||
/sc:analyze complex-algorithm.js --persona-mentor
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 清晰、易懂的解释
|
||
- 完整的概念理解
|
||
- 引人入胜的学习体验
|
||
- 实用技能发展
|
||
|
||
---
|
||
|
||
#### ✍️ `scribe` - 专业文档专家
|
||
**功能**：专业写作、文档、本地化、文化沟通
|
||
|
||
**优先级**：清晰性 > 受众需求 > 文化敏感性 > 完整性 > 简洁性
|
||
|
||
**何时自动激活**：
|
||
- 关键词："document"、"write"、"guide"、"README"
|
||
- 文档或写作任务
|
||
- 专业沟通需求
|
||
|
||
**适合**：
|
||
- 技术文档
|
||
- 用户指南和教程
|
||
- README 文件和 wiki
|
||
- API 文档
|
||
- 专业沟通
|
||
|
||
**语言支持**：英语（默认）、西班牙语、法语、德语、日语、中文、葡萄牙语、意大利语、俄语、韩语
|
||
|
||
**内容类型**：技术文档、用户指南、API 文档、提交消息、PR 描述
|
||
|
||
**示例工作流程**：
|
||
```bash
|
||
/sc:document api/ --persona-scribe
|
||
/sc:git commit --persona-scribe
|
||
/sc:explain --persona-scribe=es complex-feature
|
||
```
|
||
|
||
**他们优先考虑什么**：
|
||
- 清晰、专业的沟通
|
||
- 适合受众的语言
|
||
- 文化敏感性和适应
|
||
- 高写作标准
|
||
|
||
## 每个角色何时闪耀 ⭐
|
||
|
||
### 开发阶段映射
|
||
|
||
**规划和设计阶段**：
|
||
- 🏗️ `architect` - 系统设计和架构规划
|
||
- 🎨 `frontend` - UI/UX 设计和用户体验
|
||
- ✍️ `scribe` - 需求文档和规范
|
||
|
||
**实施阶段**：
|
||
- 🎨 `frontend` - UI 组件开发
|
||
- ⚙️ `backend` - API 和服务实施
|
||
- 🛡️ `security` - 安全实施和强化
|
||
|
||
**测试和质量阶段**：
|
||
- 🧪 `qa` - 测试策略和质量保证
|
||
- ⚡ `performance` - 性能测试和优化
|
||
- 🔍 `analyzer` - 错误调查和根本原因分析
|
||
|
||
**维护和改进阶段**：
|
||
- 🔄 `refactorer` - 代码清理和重构
|
||
- ⚡ `performance` - 性能优化
|
||
- 👨🏫 `mentor` - 知识转移和文档
|
||
|
||
**部署和运营阶段**：
|
||
- 🚀 `devops` - 部署自动化和基础设施
|
||
- 🛡️ `security` - 安全监控和合规性
|
||
- ✍️ `scribe` - 运营文档和运行手册
|
||
|
||
### 问题类型映射
|
||
|
||
**"我的代码很慢"** → ⚡ `performance`
|
||
**"某些东西坏了，我不知道为什么"** → 🔍 `analyzer`
|
||
**"需要设计新系统"** → 🏗️ `architect`
|
||
**"UI 看起来很糟糕"** → 🎨 `frontend`
|
||
**"这安全吗？"** → 🛡️ `security`
|
||
**"代码很乱"** → 🔄 `refactorer`
|
||
**"需要更好的测试"** → 🧪 `qa`
|
||
**"部署不断失败"** → 🚀 `devops`
|
||
**"我不理解这个"** → 👨🏫 `mentor`
|
||
**"需要文档"** → ✍️ `scribe`
|
||
|
||
## 角色组合 🤝
|
||
|
||
角色通常自动协同工作。以下是常见的协作模式：
|
||
|
||
### 设计和实施
|
||
```bash
|
||
/sc:design user-dashboard
|
||
# 自动激活：🏗️ architect（系统设计）+ 🎨 frontend（UI 设计）
|
||
```
|
||
|
||
### 安全审查
|
||
```bash
|
||
/sc:analyze --focus security api/
|
||
# 自动激活：🛡️ security（主要）+ ⚙️ backend（API 专业知识）
|
||
```
|
||
|
||
### 性能优化
|
||
```bash
|
||
/sc:improve --focus performance slow-app/
|
||
# 自动激活：⚡ performance（主要）+ 🎨 frontend（如果 UI）或 ⚙️ backend（如果 API）
|
||
```
|
||
|
||
### 质量改进
|
||
```bash
|
||
/sc:improve --focus quality legacy-code/
|
||
# 自动激活：🔄 refactorer（主要）+ 🧪 qa（测试）+ 🏗️ architect（设计）
|
||
```
|
||
|
||
### 文档和学习
|
||
```bash
|
||
/sc:document complex-feature --type guide
|
||
# 自动激活：✍️ scribe（写作）+ 👨🏫 mentor（教育方法）
|
||
```
|
||
|
||
## 实用示例 💡
|
||
|
||
### 之前/之后：通用 vs 角色特定
|
||
|
||
**之前**（通用）：
|
||
```bash
|
||
/sc:analyze auth.js
|
||
# → 基本分析、通用建议
|
||
```
|
||
|
||
**之后**（安全角色）：
|
||
```bash
|
||
/sc:analyze auth.js --persona-security
|
||
# → 安全聚焦分析
|
||
# → 威胁建模视角
|
||
# → OWASP 合规检查
|
||
# → 漏洞模式检测
|
||
```
|
||
|
||
### 实际中的自动激活
|
||
|
||
**前端工作检测**：
|
||
```bash
|
||
/sc:build react-components/
|
||
# 自动激活：🎨 frontend
|
||
# → UI 聚焦的构建优化
|
||
# → 可访问性检查
|
||
# → 性能预算
|
||
# → 捆绑包大小分析
|
||
```
|
||
|
||
**复杂调试**：
|
||
```bash
|
||
/sc:troubleshoot "payment processing randomly fails"
|
||
# 自动激活：🔍 analyzer
|
||
# → 系统调查方法
|
||
# → 证据收集方法论
|
||
# → 模式分析
|
||
# → 根本原因识别
|
||
```
|
||
|
||
### 手动覆盖示例
|
||
|
||
**强制安全视角**：
|
||
```bash
|
||
/sc:analyze react-app/ --persona-security
|
||
# 即使是前端代码，也从安全视角分析
|
||
# → XSS 漏洞检查
|
||
# → 身份验证流程分析
|
||
# → 数据暴露风险
|
||
```
|
||
|
||
**在小更改上获得架构建议**：
|
||
```bash
|
||
/sc:improve small-utility.js --persona-architect
|
||
# 将架构思维应用于小代码
|
||
# → 设计模式机会
|
||
# → 未来可扩展性
|
||
# → 耦合分析
|
||
```
|
||
|
||
## 高级使用 🚀
|
||
|
||
### 手动角色控制
|
||
|
||
**何时覆盖自动激活**：
|
||
- 您想要对同一问题有不同的视角
|
||
- 自动激活为您的特定需求选择了错误的角色
|
||
- 您正在学习并想看不同专家如何处理问题
|
||
|
||
**如何覆盖**：
|
||
```bash
|
||
# 显式角色选择
|
||
/sc:analyze frontend-code/ --persona-security # 前端的安全视图
|
||
/sc:improve backend-api/ --persona-performance # 后端的性能视图
|
||
|
||
# 多个角色标志（最后一个获胜）
|
||
/sc:analyze --persona-frontend --persona-security # 使用安全角色
|
||
```
|
||
|
||
### 角色特定标志和设置
|
||
|
||
**安全角色 + 验证**：
|
||
```bash
|
||
/sc:analyze --persona-security --focus security --validate
|
||
# → 最大安全聚焦和验证
|
||
```
|
||
|
||
**性能角色 + 基准测试**：
|
||
```bash
|
||
/sc:test --persona-performance --benchmark --focus performance
|
||
# → 带指标的性能聚焦测试
|
||
```
|
||
|
||
**导师角色 + 详细解释**：
|
||
```bash
|
||
/sc:explain complex-concept --persona-mentor --verbose
|
||
# → 教育解释与完整细节
|
||
```
|
||
|
||
### 跨域专业知识
|
||
|
||
**当您需要多个视角时**：
|
||
```bash
|
||
# 不同角色的顺序分析
|
||
/sc:analyze --persona-security api/auth.js
|
||
/sc:analyze --persona-performance api/auth.js
|
||
/sc:analyze --persona-refactorer api/auth.js
|
||
|
||
# 或让 SuperClaude 自动协调
|
||
/sc:analyze --focus quality api/auth.js
|
||
# 自动协调：安全 + 性能 + 重构器洞察
|
||
```
|
||
|
||
## 按角色的常见工作流程 💼
|
||
|
||
### 🏗️ 架构师工作流程
|
||
```bash
|
||
# 系统设计
|
||
/sc:design microservices-architecture --persona-architect
|
||
/sc:estimate "migrate monolith to microservices" --persona-architect
|
||
|
||
# 架构审查
|
||
/sc:analyze --focus architecture --persona-architect large-system/
|
||
/sc:review --persona-architect critical-components/
|
||
```
|
||
|
||
### 🎨 前端工作流程
|
||
```bash
|
||
# 组件开发
|
||
/sc:build dashboard-components/ --persona-frontend
|
||
/sc:improve --focus accessibility --persona-frontend ui/
|
||
|
||
# 性能优化
|
||
/sc:analyze --focus performance --persona-frontend bundle/
|
||
/sc:test --persona-frontend --focus performance
|
||
```
|
||
|
||
### ⚙️ 后端工作流程
|
||
```bash
|
||
# API 开发
|
||
/sc:design rest-api --persona-backend
|
||
/sc:build api-endpoints/ --persona-backend
|
||
|
||
# 可靠性改进
|
||
/sc:improve --focus reliability --persona-backend services/
|
||
/sc:analyze --persona-backend --focus security api/
|
||
```
|
||
|
||
### 🛡️ 安全工作流程
|
||
```bash
|
||
# 安全评估
|
||
/sc:scan --persona-security --focus security entire-app/
|
||
/sc:analyze --persona-security auth-flow/
|
||
|
||
# 漏洞修复
|
||
/sc:improve --focus security --persona-security vulnerable-code/
|
||
/sc:review --persona-security --focus security critical-paths/
|
||
```
|
||
|
||
### 🔍 分析器工作流程
|
||
```bash
|
||
# 错误调查
|
||
/sc:troubleshoot "intermittent failures" --persona-analyzer
|
||
/sc:analyze --persona-analyzer --focus debugging problem-area/
|
||
|
||
# 系统理解
|
||
/sc:explain --persona-analyzer complex-system/
|
||
/sc:load --persona-analyzer unfamiliar-codebase/
|
||
```
|
||
|
||
## 快速参考 📋
|
||
|
||
### 角色备忘单
|
||
|
||
| 角色 | 最适合 | 自动激活于 | 手动标志 |
|
||
|---------|----------|-------------------|-------------|
|
||
| 🏗️ architect | 系统设计、架构 | "architecture"、"design"、"scalability" | `--persona-architect` |
|
||
| 🎨 frontend | UI/UX、可访问性 | "component"、"responsive"、"UI" | `--persona-frontend` |
|
||
| ⚙️ backend | API、数据库、可靠性 | "API"、"database"、"service" | `--persona-backend` |
|
||
| 🛡️ security | 安全、合规性 | "security"、"vulnerability"、"auth" | `--persona-security` |
|
||
| ⚡ performance | 优化、速度 | "performance"、"optimization"、"slow" | `--persona-performance` |
|
||
| 🔍 analyzer | 调试、调查 | "analyze"、"debug"、"investigate" | `--persona-analyzer` |
|
||
| 🧪 qa | 测试、质量 | "test"、"quality"、"validation" | `--persona-qa` |
|
||
| 🔄 refactorer | 代码清理、重构 | "refactor"、"cleanup"、"quality" | `--persona-refactorer` |
|
||
| 🚀 devops | 部署、基础设施 | "deploy"、"infrastructure"、"CI/CD" | `--persona-devops` |
|
||
| 👨🏫 mentor | 学习、解释 | "explain"、"learn"、"understand" | `--persona-mentor` |
|
||
| ✍️ scribe | 文档、写作 | "document"、"write"、"guide" | `--persona-scribe` |
|
||
|
||
### 最有用的组合
|
||
|
||
**安全聚焦开发**：
|
||
```bash
|
||
--persona-security --focus security --validate
|
||
```
|
||
|
||
**性能优化**：
|
||
```bash
|
||
--persona-performance --focus performance --benchmark
|
||
```
|
||
|
||
**学习和理解**：
|
||
```bash
|
||
--persona-mentor --verbose --explain
|
||
```
|
||
|
||
**质量改进**：
|
||
```bash
|
||
--persona-refactorer --focus quality --safe-mode
|
||
```
|
||
|
||
**专业文档**：
|
||
```bash
|
||
--persona-scribe --type guide --detailed
|
||
```
|
||
|
||
### 自动激活触发器
|
||
|
||
**强触发器**（通常效果很好）：
|
||
- "security audit" → 🛡️ security
|
||
- "UI component" → 🎨 frontend
|
||
- "API design" → ⚙️ backend
|
||
- "system architecture" → 🏗️ architect
|
||
- "debug issue" → 🔍 analyzer
|
||
|
||
**中等触发器**（通常有效）：
|
||
- "improve performance" → ⚡ performance
|
||
- "write tests" → 🧪 qa
|
||
- "clean up code" → 🔄 refactorer
|
||
- "deployment issue" → 🚀 devops
|
||
|
||
**上下文相关触发器**（因情况而异）：
|
||
- "document this" → ✍️ scribe 或 👨🏫 mentor（取决于受众）
|
||
- "analyze this" → 🔍 analyzer、🏗️ architect 或领域专家（取决于内容）
|
||
|
||
## 故障排除角色问题 🚨
|
||
|
||
### 常见问题
|
||
|
||
**"错误的角色激活"**
|
||
- 使用显式角色标志：`--persona-security`
|
||
- 检查您的关键词是否触发了自动激活
|
||
- 在请求中尝试更具体的语言
|
||
|
||
**"角色似乎不起作用"**
|
||
- 验证角色名称拼写：`--persona-frontend` 而不是 `--persona-fronted`
|
||
- 某些角色与特定命令配合效果更好
|
||
- 尝试结合相关标志：`--focus security --persona-security`
|
||
|
||
**"想要多个视角"**
|
||
- 手动使用不同角色运行相同命令
|
||
- 使用更广泛的焦点标志：`--focus quality`（激活多个角色）
|
||
- 让 SuperClaude 通过复杂请求自动协调
|
||
|
||
**"角色过于聚焦"**
|
||
- 尝试更通用的不同角色
|
||
- 使用导师角色获得更广泛的解释
|
||
- 结合 `--verbose` 获得更多上下文
|
||
|
||
### 何时覆盖自动激活
|
||
|
||
**覆盖当**：
|
||
- 自动激活选择了错误的专家
|
||
- 您想从不同视角学习
|
||
- 在典型域边界之外工作
|
||
- 需要特定专业知识处理边缘案例
|
||
|
||
**如何有效覆盖**：
|
||
```bash
|
||
# 强制特定视角
|
||
/sc:analyze frontend-code/ --persona-security # 前端的安全视图
|
||
|
||
# 结合多个视角
|
||
/sc:analyze api/ --persona-security
|
||
/sc:analyze api/ --persona-performance # 单独运行以获得不同视图
|
||
|
||
# 使用一般分析
|
||
/sc:analyze --no-persona # 禁用角色自动激活
|
||
```
|
||
|
||
## 有效角色使用技巧 💡
|
||
|
||
### 开始（诚实方式）
|
||
1. **首先完全忽略角色** - 自动激活处理一切
|
||
2. **正常使用基本命令** - `/analyze`、`/build`、`/improve` 在没有角色知识的情况下效果很好
|
||
3. **注意会发生什么** - 您会看到不同类型的专业知识自然出现
|
||
4. **相信自动化** - SuperClaude 通常比手动选择选择更好的专家
|
||
|
||
### 高级阶段（如果您想要）
|
||
1. **尝试手动覆盖** - 在前端代码上尝试 `--persona-security` 获得不同视角
|
||
2. **学习团队成员** - 当您好奇时阅读关于单个角色的内容
|
||
3. **观察角色组合** - 看多个专家如何在复杂问题上协作
|
||
4. **用于学习** - 向不同角色问相同问题以看不同方法
|
||
|
||
### 最佳实践（保持简单）
|
||
- **让自动激活首先工作** - 仅当您想要不同视角时覆盖
|
||
- **不要想太多** - 需要时正确的专家会出现
|
||
- **用于实验** - 在同一问题上尝试不同角色以学习
|
||
- **相信智能** - 自动激活从模式中学习并不断改进
|
||
|
||
---
|
||
|
||
## 最后说明 📝
|
||
|
||
**关于角色的真相** 💯：
|
||
- **自动激活通常比自己尝试选择专家效果更好**
|
||
- **您可以完全忽略本指南**仍然经常获得有用的专家帮助
|
||
- **角色存在是为了帮助您** - 不是为了创建您需要管理的复杂性
|
||
- **学习通过使用自然发生**，而不是通过研究角色描述 😊
|
||
|
||
**不要被团队压垮** 🧘♂️：
|
||
- 您不需要知道每个角色做什么
|
||
- SuperClaude 通常合理地处理专家选择
|
||
- 上面的详细描述是出于好奇，而非必要
|
||
- 通过让自动激活工作，您不会错过任何东西
|
||
|
||
**当您可能手动选择角色时**：
|
||
- **好奇** - "安全专家会如何看待这段前端代码？"
|
||
- **学习** - "不同专家会如何处理这个问题？"
|
||
- **实验** - "让我通过性能镜头看这个"
|
||
- **覆盖** - "我想在这个小实用函数上获得架构建议"
|
||
|
||
**保持简单** 🎯：
|
||
- 使用像 `/analyze some-code/` 这样的正常命令
|
||
- 让正确的专家自动出现
|
||
- 当您想要时提供手动角色控制，而不是因为您需要它
|
||
- 专注于您的工作，而不是管理谁帮助您
|
||
|
||
---
|
||
|
||
*在拥有 11 个专家的所有这些表面复杂性背后，SuperClaude 试图变得简单易用。只需开始编码，有用的专家通常在需要时出现！🚀*
|