9.2 核心概念详解
引言
SuperClaude 框架由多个相互协作的组件构成。本节将深入讲解这些核心概念：
- PM Agent - 项目管理代理（核心中枢）
- 命令系统 - 30 个斜杠命令
- 代理系统 - 16 个专业代理
- 行为模式 - 7 种自适应模式
- 五大设计原则 - 框架哲学
- 绝对规则系统 - 不可妥协的边界
1️⃣ PM Agent：项目管理代理
核心定位
PM Agent 是 SuperClaude 的核心中枢，负责所有请求的分析、委托和监控。它总是活跃，无需手动激活。
┌─────────────────────────────────────────────────────────────┐
│ PM Agent 架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 用户请求 ──────────────────────────────┐ │
│ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ PM Agent │ │
│ │ │ │
│ │ 1. 请求分析 │ │
│ │ └── 意图分类 + 复杂度检测 │ │
│ │ │ │
│ │ 2. 策略选择 │ │
│ │ ├── 头脑风暴 (模糊请求) │ │
│ │ ├── 直接执行 (简单任务) │ │
│ │ ├── 多代理协作 (复杂任务) │ │
│ │ └── Wave 并行 (批量操作) │ │
│ │ │ │
│ │ 3. 代理委托 │ │
│ │ └── 选择最优专家代理 │ │
│ │ │ │
│ │ 4. MCP 编排 │ │
│ │ └── 按阶段动态加载工具 │ │
│ │ │ │
│ │ 5. 进度监控 │ │
│ │ └── TodoWrite 实时追踪 │ │
│ │ │ │
│ │ 6. 自我检查 │ │
│ │ └── 四问验证 + PDCA 循环 │ │
│ │ │ │
│ │ 7. 知识积累 │ │
│ │ └── 成功模式 → patterns/ │ │
│ │ └── 失败教训 → mistakes/ │ │
│ │ │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘三大核心模式
PM Agent 内置三种关键检查机制：
1. ConfidenceChecker（置信度检查器）
python
# 执行前检查置信度
class ConfidenceChecker:
def assess(self, context) -> float: # 返回 0.0-1.0
checks = [
self.check_duplicates(), # 检查是否重复实现
self.check_architecture(), # 检查架构合规性
self.check_references(), # 检查文档引用
self.check_root_cause() # 检查根本原因
]
return average(checks)
# 决策逻辑
置信度 ≥ 90% → 继续实现
置信度 70-89% → 提出替代方案，继续调查
置信度 < 70% → 停止，提出问题，深入研究实际效果：
场景：用户要求实现登录功能
ConfidenceChecker:
├── 检查重复: 项目中是否已有登录实现？
│ └── 发现 auth.py 已有基础实现 → 置信度 -10%
│
├── 检查架构: 登录方式符合项目规范吗？
│ └── 使用 Context7 MCP 查阅最佳实践
│
├── 检查引用: 需求清晰吗？
│ └── 缺少安全要求 → 置信度 -15%
│
└── 综合评估: 75%
→ 提出问题："需要确认密码复杂度要求和 2FA 需求"ROI 分析：
花费: 100-200 token（检查）
节省: 5,000-50,000 token（避免错误方向）
ROI: 25-250x2. SelfCheckProtocol（自我检查协议）
python
# 执行后验证
class SelfCheckProtocol:
def validate(self, implementation) -> (bool, list):
issues = []
# 四问验证
if not self.all_tests_passed():
issues.append("测试未通过")
if not self.all_requirements_met():
issues.append("需求未满足")
if self.has_unverified_assumptions():
issues.append("存在未验证假设")
if not self.has_evidence():
issues.append("缺少证据")
return (len(issues) == 0, issues)四问验证详解：
| 问题 | 检查内容 | 正确答案示例 |
|---|---|---|
| 所有测试通过了吗？ | 实际测试输出 | ✅ 15 tests passed |
| 所有需求都满足了吗？ | 逐条对照需求 | ✅ Requirement 1: ✓ |
| 没有未验证的假设吗？ | 文档引用 | 📖 Per React docs v19... |
| 有证据吗？ | 测试结果/代码变更 | 📊 diff +45 -12 |
红旗警告（幻觉信号）：
❌ "测试通过了"（无输出）
❌ "一切正常"（无证据）
❌ "实现完成"（测试失败中）
❌ 跳过错误信息
❌ 忽视警告
❌ "可能奏效"的语言3. ReflexionPattern（反思模式）
python
# 错误学习机制
class ReflexionPattern:
def on_error(self, error, context):
# 1. 分析错误
root_cause = self.analyze_root_cause(error)
# 2. 记录教训
self.write_to_mistakes_doc(
what_happened=error,
root_cause=root_cause,
why_missed=self.analyze_gap(),
fix=self.get_fix(),
prevention_checklist=self.create_checklist()
)
# 3. 更新全局规则（如果适用）
if self.is_global_pattern(root_cause):
self.update_claude_md(new_rule)文档输出示例：
markdown
# docs/mistakes/2024-01-15-auth-token-bug.md
## 发生了什么
JWT token 验证失败导致用户无法登录
## 根本原因
使用了过期的 secret key，未从环境变量读取
## 为什么遗漏了
- 未检查现有配置
- 假设 secret key 是硬编码的
## 修复
从 .env 文件读取 JWT_SECRET
## 防止检查表
- [ ] 始终检查现有配置文件
- [ ] 敏感信息从环境变量读取
- [ ] 添加配置验证启动检查会话生命周期管理
PM Agent 通过 Serena MCP 管理跨会话记忆：
┌─────────────────────────────────────────────────────────────┐
│ 会话生命周期 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 会话开始协议（自动执行） │
│ ├── list_memories() → 检查现有状态 │
│ ├── read_memory("pm_context") → 恢复总体上下文 │
│ ├── read_memory("current_plan") → 恢复当前计划 │
│ ├── read_memory("last_session") → 恢复上次会话 │
│ └── read_memory("next_actions") → 恢复下一步行动 │
│ │
│ 用户报告: │
│ ┌──────────────────────────────────────┐ │
│ │ 前回: [上个会话摘要] │ │
│ │ 進捗: [当前进度状态] │ │
│ │ 今回: [计划的下一步行动] │ │
│ │ 課題: [阻止程序或问题] │ │
│ └──────────────────────────────────────┘ │
│ │
│ 工作期间（PDCA 循环） │
│ ├── Plan: write_memory("plan", goal) │
│ ├── Do: TodoWrite + checkpoint 每30分钟 │
│ ├── Check: think_about_task_adherence() │
│ └── Act: 成功→patterns/, 失败→mistakes/ │
│ │
│ 会话结束协议 │
│ ├── think_about_whether_you_are_done() │
│ ├── write_memory("last_session", summary) │
│ ├── write_memory("next_actions", todo_list) │
│ └── write_memory("pm_context", complete_state) │
│ │
└─────────────────────────────────────────────────────────────┘2️⃣ 命令系统：30 个斜杠命令
命令分类
SuperClaude 提供 30 个斜杠命令，组织为 7 个类别：
┌─────────────────────────────────────────────────────────────┐
│ 命令系统概览 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🧠 规划设计 (4 个) │
│ ├── /sc:brainstorm 结构化头脑风暴 │
│ ├── /sc:design 系统架构设计 │
│ ├── /sc:estimate 时间/工作量估算 │
│ └── /sc:spec-panel 规范分析 │
│ │
│ 💻 开发 (5 个) │
│ ├── /sc:implement 代码实现 │
│ ├── /sc:build 构建工作流 │
│ ├── /sc:improve 代码改进 │
│ ├── /sc:cleanup 重构 │
│ └── /sc:explain 代码解释 │
│ │
│ 🧪 测试和质量 (4 个) │
│ ├── /sc:test 测试生成 │
│ ├── /sc:analyze 代码分析 │
│ ├── /sc:troubleshoot 调试 │
│ └── /sc:reflect 回顾 │
│ │
│ 📚 文档 (2 个) │
│ ├── /sc:document 文档生成 │
│ └── /sc:help 命令帮助 │
│ │
│ 🔧 版本控制 (1 个) │
│ └── /sc:git Git 操作 │
│ │
│ 📊 项目管理 (3 个) │
│ ├── /sc:pm 项目管理代理 │
│ ├── /sc:task 任务追踪 │
│ └── /sc:workflow 工作流自动化 │
│ │
│ 🔍 研究与分析 (2 个) │
│ ├── /sc:research 深度网络研究 │
│ └── /sc:business-panel 商业分析 │
│ │
│ 🎯 工具 (9 个) │
│ ├── /sc:agent AI 代理 │
│ ├── /sc:index-repo 仓库索引 │
│ ├── /sc:recommend 命令推荐 │
│ ├── /sc:select-tool 工具选择 │
│ ├── /sc:spawn 并行任务 │
│ ├── /sc:load 加载会话 │
│ ├── /sc:save 保存会话 │
│ └── /sc 显示所有命令 │
│ │
└─────────────────────────────────────────────────────────────┘核心命令详解
/sc:brainstorm - 交互式需求发现
yaml
触发器:
- 模糊的项目想法: "想建一个...", "考虑创建..."
- 探索关键词: brainstorm, explore, discuss
- 不确定指标: "maybe", "possibly", "thinking about"
行为流:
1. 探索阶段
└── Socratic 对话，通过提问发现隐藏需求
2. 分析阶段
└── 多人格调整，根据领域匹配专家视角
3. 验证阶段
└── 跨域可行性评估
4. 规范阶段
└── 生成具体规范
5. 交接阶段
└── 创建可操作的摘要
MCP 集成:
- Sequential: 复杂多步推理
- Context7: 框架特定可行性
- Magic: UI/UX 可行性
- Serena: 跨会话持久化使用示例：
用户: /sc:brainstorm 我想做一个任务管理应用
Claude (Brainstorm Mode):
🤔 让我问几个问题来更好地理解你的需求：
1. 目标用户是谁？
- 个人使用
- 小团队 (2-10人)
- 企业级 (10+ 人)
2. 核心场景是什么？
- 日常待办管理
- 项目协作
- 敏捷开发看板
3. 有哪些必须的功能？
4. 有什么不想要的功能？
5. 技术偏好？(Web/Mobile/Desktop)
请回答这些问题，我会基于你的回答生成详细规范.../sc:implement - 功能实现
yaml
触发器:
- 功能开发请求
- 代码实现需要
- 多域开发协调
行为流:
1. 分析: 检查实现需求和技术上下文
2. 规划: 选择方法和相关代理
3. 生成: 创建框架特定代码
4. 验证: 应用安全性和质量验证
5. 集成: 更新文档和测试建议
MCP 集成:
- Context7: 框架模式和文档
- Magic: UI 组件生成
- Sequential: 复杂多步骤分析
- Playwright: 测试验证使用示例：
用户: /sc:implement 添加用户登录功能
PM Agent:
1. 置信度检查 ✅ (92%)
- 需求清晰
- 无现有实现冲突
2. 代理选择
- Backend Architect (API 设计)
- Security Engineer (安全审计)
- Frontend Architect (UI 实现)
3. 并行执行
Wave 1: [设计 API] + [设计 UI]
Checkpoint: 整合设计
Wave 2: [实现后端] + [实现前端]
4. 四问验证
✅ 测试通过
✅ 需求满足
✅ 假设验证
✅ 有证据
5. 文档更新
→ 更新 API 文档
→ 添加到 KNOWLEDGE.md/sc:research - 深度网络研究
yaml
触发器:
- /research 命令
- 网络研究需求
- 技术调研
能力:
- 自主网络研究（最多 5 次迭代搜索）
- 多跳推理
├── 实体扩展: 论文 → 作者 → 作品
├── 概念深化: 主题 → 细节 → 示例
├── 时间进展: 当前 → 历史
└── 因果链: 效果 → 原因 → 防止
- 质量评分
├── 源可信度评估 (0.0-1.0)
├── 覆盖完整性追踪
└── 综合一致性评估
自适应策略:
- Planning-Only: 清晰查询直接执行
- Intent-Planning: 模糊请求先澄清
- Unified: 协作计划细化（默认）3️⃣ 代理系统：16 个专业代理
代理架构
┌─────────────────────────────────────────────────────────────┐
│ 代理层级结构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ PM Agent (总控) │
│ │ │
│ ┌─────────────────────┼─────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ 研究类 │ │ 架构类 │ │ 质量类 │ │
│ ├────────┤ ├────────┤ ├────────┤ │
│ │ Deep │ │Backend │ │Security│ │
│ │Research│ │Architect│ │Engineer│ │
│ │ │ │ │ │ │ │
│ │ Root │ │Frontend│ │Quality │ │
│ │Cause │ │Architect│ │Engineer│ │
│ │Analyst │ │ │ │ │ │
│ │ │ │System │ │Perform-│ │
│ │Require-│ │Architect│ │ance │ │
│ │ments │ │ │ │Engineer│ │
│ │Analyst │ │DevOps │ │ │ │
│ │ │ │Architect│ │Refactor│ │
│ │ │ │ │ │Expert │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
│ ┌─────────────────────┬─────────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ 专业类 │ │ 文档类 │ │ 教育类 │ │
│ ├────────┤ ├────────┤ ├────────┤ │
│ │ Python │ │Technical│ │Socratic│ │
│ │ Expert │ │ Writer │ │ Mentor │ │
│ │ │ │ │ │ │ │
│ │ │ │ │ │Learning│ │
│ │ │ │ │ │ Guide │ │
│ └────────┘ └────────┘ └────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘代理列表
| 代理名称 | 专业领域 | 典型任务 |
|---|---|---|
| Deep Research Agent | 网络研究 | 技术调研、竞品分析 |
| Backend Architect | 后端架构 | API 设计、数据库建模 |
| Frontend Architect | 前端架构 | UI 组件、状态管理 |
| System Architect | 系统架构 | 分布式设计、微服务 |
| DevOps Architect | DevOps | CI/CD、容器化、部署 |
| Security Engineer | 安全 | 威胁建模、代码审计 |
| Quality Engineer | 质量 | 测试策略、覆盖率 |
| Performance Engineer | 性能 | 性能优化、负载测试 |
| Refactoring Expert | 重构 | 代码重构、技术债务 |
| Python Expert | Python | Python 最佳实践 |
| Requirements Analyst | 需求 | 需求分析、用户故事 |
| Root Cause Analyst | 问题分析 | Bug 根因、故障排查 |
| Technical Writer | 技术写作 | API 文档、用户指南 |
| Socratic Mentor | 教学 | 概念讲解、引导学习 |
| Learning Guide | 学习 | 学习路径、资源推荐 |
代理自动激活
PM Agent 根据上下文自动选择代理：
用户请求分析 → 关键词匹配 + 上下文理解 → 代理选择
示例映射:
┌────────────────────────────────────────────────────────────┐
│ 用户请求 │ 激活代理 │
├────────────────────────────────────────────────────────────┤
│ "设计用户认证 API" │ Backend + Security │
│ "创建登录页面" │ Frontend + Security │
│ "为什么这个 bug 会出现？" │ Root Cause Analyst │
│ "优化数据库查询性能" │ Performance + Backend │
│ "重构这个模块" │ Refactoring Expert │
│ "帮我理解 React hooks" │ Socratic Mentor │
│ "部署到 Kubernetes" │ DevOps Architect │
└────────────────────────────────────────────────────────────┘多代理协作示例
场景: 实现实时聊天功能
PM Agent 编排:
Phase 1: 需求分析
├── Requirements Analyst: 梳理功能需求
└── Security Engineer: 识别安全需求
Phase 2: 架构设计 (并行)
├── Backend Architect: WebSocket 服务设计
├── Frontend Architect: 聊天 UI 组件设计
└── System Architect: 消息队列架构
Phase 3: 实现 (并行)
├── Backend: 实现消息服务
├── Frontend: 实现聊天界面
└── DevOps: 配置 WebSocket 负载均衡
Phase 4: 质量保证
├── Quality Engineer: 测试覆盖
├── Performance Engineer: 负载测试
└── Security Engineer: 安全审计
Phase 5: 文档
└── Technical Writer: API 文档 + 用户指南4️⃣ 行为模式：7 种自适应模式
模式概览
┌─────────────────────────────────────────────────────────────┐
│ 7 种行为模式 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Brainstorming Mode 协作发现模式 │
│ └── 触发: 模糊请求、探索性对话 │
│ │
│ 2. Business Panel Mode 商业分析模式 │
│ └── 触发: 战略问题、商业决策 │
│ │
│ 3. Deep Research Mode 深度研究模式 │
│ └── 触发: /research 命令、调研需求 │
│ │
│ 4. Introspection Mode 元认知分析模式 │
│ └── 触发: --introspect 标志 │
│ │
│ 5. Orchestration Mode 多工具协调模式 │
│ └── 触发: 复杂多步骤任务 │
│ │
│ 6. Task Management Mode 任务管理模式 │
│ └── 触发: 3+ 步骤操作 │
│ │
│ 7. Token Efficiency Mode Token 效率模式 │
│ └── 触发: 上下文 >75%、--uc 标志 │
│ │
└─────────────────────────────────────────────────────────────┘关键模式详解
Business Panel Mode（商业面板模式）
商业面板模式激活 9 个商业思想领袖人格，提供多视角分析：
┌─────────────────────────────────────────────────────────────┐
│ 9 个商业专家 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. Christensen 颠覆性创新 / Jobs-to-be-Done │
│ 2. Porter 竞争战略 / Five Forces │
│ 3. Godin 营销 / 紫牛理论 │
│ 4. Kim/Mauborgne 蓝海战略 │
│ 5. Collins 从优秀到卓越 │
│ 6. Taleb 反脆弱 │
│ 7. Meadows 系统动力学 │
│ 8. Doumont 清晰沟通 │
│ 9. Drucker 管理基础 │
│ │
└─────────────────────────────────────────────────────────────┘三阶段分析流程：
| 阶段 | 模式 | 适用场景 |
|---|---|---|
| DISCUSSION | 协作分析 | 战略计划、市场分析 |
| DEBATE | 对抗分析 | 争议决策、风险评估 |
| SOCRATIC | 问题驱动 | 学习请求、能力开发 |
Token Efficiency Mode（Token 效率模式）
当上下文使用超过 75% 时自动激活，使用符号系统压缩输出：
符号系统:
逻辑流:
→ 导致、暗示
⇒ 转换为
← 回滚、反向
& 和、结合
| 分隔符、或
状态:
✅ 完成、通过
❌ 失败、错误
⚠️ 警告
🔄 进行中
⏳ 等待中
技术域:
⚡ 性能
🔍 分析
🔧 配置
🛡️ 安全
🏗️ 架构
示例压缩:
标准: "认证系统在用户验证函数中存在安全漏洞"
压缩: "auth.js:45 → 🛡️ sec risk in user val()"
效果: 30-50% token 削减，≥95% 信息保留5️⃣ 五大设计原则
原则 1：证据驱动开发
核心: 永远不要猜测 - 总是验证
实践方法:
┌────────────────────────────────────────────────────────────┐
│ 验证类型 │ 工具 │ 成本 │
├────────────────────────────────────────────────────────────┤
│ 官方文档验证 │ Context7 MCP │ 100 token │
│ 现有代码检查 │ Glob/Grep │ 50 token │
│ 网络搜索验证 │ WebFetch/WebSearch │ 150 token │
│ 测试结果验证 │ Bash/Playwright │ 200 token │
└────────────────────────────────────────────────────────────┘
ROI: 花 100-200 token 验证 → 节省 5,000-50,000 token原则 2：置信度优先实现
决策矩阵:
置信度 ≥ 90%
└── 行动: 继续实现
└── 原因: 充分理解，风险可控
置信度 70-89%
└── 行动: 提出替代方案，继续调查
└── 原因: 需要更多验证
置信度 < 70%
└── 行动: 停止，提出问题，深入研究
└── 原因: 风险太高，可能浪费大量 token原则 3：并行优先执行
Wave → Checkpoint → Wave 模式:
传统串行:
Read file1 → Read file2 → Read file3 → 分析 → Edit file1 → ...
时间: 30 秒
并行模式:
Wave 1: [Read file1, Read file2, Read file3] (并行) → 3 秒
↓
Checkpoint: 统一分析
↓
Wave 2: [Edit file1, Edit file2, Edit file3] (并行) → 3 秒
时间: ~9 秒
性能提升: 3.5x 平均，最高 10x原则 4：无幻觉承诺
四问验证协议:
1. 所有测试通过了吗？
✅ 正确: "15 tests passed, 0 failed" (显示输出)
❌ 错误: "测试通过了"
2. 所有需求都满足了吗？
✅ 正确: "Requirement 1: ✓, Requirement 2: ✓" (逐条列出)
❌ 错误: "需求满足了"
3. 没有未验证的假设吗？
✅ 正确: "Per React docs v19, useEffect..." (引用文档)
❌ 错误: "应该是这样的"
4. 有证据吗？
✅ 正确: "diff +45 -12, test output: ..." (具体证据)
❌ 错误: "已经实现了"
检测准确率: 94%原则 5：跨会话记忆
记忆系统 (Serena MCP):
存储内容:
├── pm_context: 完整项目状态
├── current_plan: 活跃计划
├── last_session: 上次会话摘要
├── next_actions: 计划的下一步
└── checkpoint_*: 执行进度快照
操作流程:
会话开始 → list_memories() → read_memory() → 恢复状态
工作期间 → write_memory() → 每 30 分钟检查点
会话结束 → write_memory() → 保存完整状态
效果: 100% 自动上下文恢复6️⃣ 绝对规则系统
规则层级
🔴 CRITICAL（永不妥协）
├── 安全和数据安全
├── 生产环境破坏
├── 文件操作前检查 git 状态
├── 测试失败不跳过
└── 永远使用功能分支
🟡 IMPORTANT（强烈偏好）
├── 完整性: 开始 = 完成
├── 范围纪律: 只构建所要求的
├── 代码组织
└── 工作空间卫生
🟢 RECOMMENDED（实际适用时应用）
├── 并行操作
├── 工具专业化
└── 代码风格一致性规则详解
安全规则
yaml
OWASP Top 10 检查:
- SQL 注入
- XSS
- CSRF
- 认证破坏
- 敏感数据暴露
- ...
敏感文件保护:
- 永不提交: .env, credentials.json, *.pem
- 警告: 检测到敏感信息时立即停止
Git 安全:
- 禁止: git push --force (除非明确要求)
- 禁止: git commit --amend (非当前用户提交)
- 强制: 功能分支开发实现完整性规则
yaml
禁止:
- TODO 注释
- 占位符代码
- 未实现的函数
- 跳过的测试
要求:
- 开始 = 完成
- 工作状态提交
- 所有路径覆盖工具专业化规则
yaml
文件操作:
- 读取: 使用 Read 工具（不是 cat/head/tail）
- 编辑: 使用 Edit 工具（不是 sed/awk）
- 搜索: 使用 Glob/Grep 工具（不是 find/grep）
- 写入: 使用 Write 工具（不是 echo >）
原因: 更好的用户体验 + 更可靠的结果📊 核心概念总结
概念关系图
┌─────────────────────────────────────────────────────────────┐
│ SuperClaude 核心概念关系 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 五大设计原则 │
│ └── 指导 PM Agent 的决策逻辑 │
│ │ │
│ ▼ │
│ PM Agent (核心中枢) │
│ ├── 使用命令系统 (30 个命令) │
│ ├── 委托代理系统 (16 个代理) │
│ ├── 激活行为模式 (7 种模式) │
│ └── 遵循绝对规则 │
│ │
│ 三大核心模式 │
│ ├── ConfidenceChecker → 执行前验证 │
│ ├── SelfCheckProtocol → 执行后验证 │
│ └── ReflexionPattern → 错误学习 │
│ │
│ MCP 集成 │
│ ├── Serena → 跨会话记忆 │
│ ├── Context7 → 文档验证 │
│ ├── Sequential → 多步推理 │
│ └── 其他 5 个服务器 │
│ │
└─────────────────────────────────────────────────────────────┘关键要点
- PM Agent 是核心 - 所有请求都经过 PM Agent 处理
- 置信度决定行动 - ≥90% 才执行，<70% 停止研究
- 四问防止幻觉 - 测试、需求、假设、证据
- 并行提升效率 - Wave 模式 3.5-10x 加速
- 记忆跨越会话 - Serena MCP 100% 自动恢复
- 规则不可妥协 - CRITICAL 级规则永不违反
下一节： 9.3 安装与配置 — 学习如何安装和配置 SuperClaude！
SuperClaude 教程 v1.0 | 2025 Edition | 基于 SuperClaude Framework v4.1.9