9.4 实战案例
引言
本节通过三个完整的实战案例，展示 SuperClaude 在实际开发中的应用：
- 案例 1：使用 PM Agent 开发新功能 - 用户认证系统
- 案例 2：Deep Research 深度研究 - 技术选型调研
- 案例 3：多代理协作开发 - 实时聊天功能
每个案例都包含完整的对话流程、PM Agent 的决策过程，以及最终输出。
📦 案例 1：使用 PM Agent 开发新功能
场景描述
项目: 电商后台管理系统
需求: 添加用户认证功能（登录、注册、密码重置）
技术栈: Python FastAPI + PostgreSQL + JWT完整对话流程
步骤 1：会话开始
用户打开 Claude Code，PM Agent 自动激活...
PM Agent [自动]:
┌──────────────────────────────────────────────────────────────┐
│ 🚀 SuperClaude PM Agent 已激活 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 📋 会话恢复 │
│ ├── list_memories() ✅ │
│ └── 未发现之前的会话状态 │
│ │
│ 🆕 这是新项目会话 │
│ │
│ 请告诉我你想做什么？ │
│ │
└──────────────────────────────────────────────────────────────┘步骤 2：用户提出需求
用户: 我需要为这个 FastAPI 项目添加用户认证功能，包括登录、注册和密码重置步骤 3：PM Agent 分析和规划
PM Agent [分析中]:
┌──────────────────────────────────────────────────────────────┐
│ 🔍 请求分析 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 意图分类: 功能实现 │
│ 复杂度: 中高（多组件、安全敏感） │
│ 策略选择: 多代理协作 │
│ │
│ 📊 置信度检查 │
│ │
│ ✓ 检查现有实现... │
│ └── Glob: **/auth*.py → 0 matches │
│ └── 无现有认证实现 ✅ │
│ │
│ ✓ 检查项目结构... │
│ └── 发现 FastAPI 项目 (main.py, routers/, models/) │
│ └── 使用 SQLAlchemy + PostgreSQL ✅ │
│ │
│ ✓ 检查安全要求... │
│ └── PLANNING.md 未指定具体要求 │
│ └── 需要确认: 密码复杂度、2FA 等 │
│ └── 置信度 -15% │
│ │
│ 🎯 综合置信度: 75% │
│ │
│ ⚠️ 建议: 在实现前确认安全需求 │
│ │
└──────────────────────────────────────────────────────────────┘
PM Agent: 我理解你需要添加用户认证功能。在开始实现之前，我需要确认几个安全相关的问题：
1. **密码要求**: 是否有密码复杂度要求？（如最少 8 位、大小写字母、数字等）
2. **双因素认证**: 是否需要支持 2FA？
3. **Token 有效期**: JWT token 应该多久过期？
4. **会话管理**: 是否需要支持同时多设备登录限制？
请确认这些需求，我将基于你的回答制定实现方案。步骤 4：用户澄清需求
用户:
1. 密码至少 8 位，包含大小写字母和数字
2. 暂时不需要 2FA
3. Token 24 小时过期
4. 允许多设备登录步骤 5：PM Agent 更新置信度并开始实现
PM Agent [置信度更新]:
┌──────────────────────────────────────────────────────────────┐
│ 📊 置信度重新评估 │
├──────────────────────────────────────────────────────────────┤
│ │
│ ✅ 需求已明确 │
│ ✅ 安全要求已确认 │
│ ✅ 无现有冲突实现 │
│ │
│ 🎯 综合置信度: 92% │
│ │
│ ✅ 继续实现 │
│ │
└──────────────────────────────────────────────────────────────┘
PM Agent [代理选择]:
┌──────────────────────────────────────────────────────────────┐
│ 🤖 代理分配 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Backend Architect │
│ └── API 设计 + 数据模型 │
│ │
│ Security Engineer │
│ └── 安全审计 + 密码哈希 │
│ │
│ Python Expert │
│ └── FastAPI 最佳实践 │
│ │
└──────────────────────────────────────────────────────────────┘
PM Agent [任务规划]:
┌──────────────────────────────────────────────────────────────┐
│ 📋 任务分解 (TodoWrite) │
├──────────────────────────────────────────────────────────────┤
│ │
│ Phase 1: 数据模型 │
│ ├── [ ] T1.1 创建 User 模型 │
│ └── [ ] T1.2 创建数据库迁移 │
│ │
│ Phase 2: 核心功能 │
│ ├── [ ] T2.1 实现密码哈希工具 │
│ ├── [ ] T2.2 实现 JWT 工具 │
│ ├── [ ] T2.3 实现注册端点 │
│ ├── [ ] T2.4 实现登录端点 │
│ └── [ ] T2.5 实现密码重置流程 │
│ │
│ Phase 3: 中间件和验证 │
│ ├── [ ] T3.1 实现认证中间件 │
│ └── [ ] T3.2 添加路由保护 │
│ │
│ Phase 4: 测试 │
│ ├── [ ] T4.1 单元测试 │
│ └── [ ] T4.2 集成测试 │
│ │
└──────────────────────────────────────────────────────────────┘
PM Agent: 好的，我已经制定了实现计划。让我开始实现...步骤 6：并行执行
PM Agent [执行中]:
┌──────────────────────────────────────────────────────────────┐
│ 🚀 Wave 执行模式 │
├──────────────────────────────────────────────────────────────┤
│ │
│ Wave 1: 信息收集 (并行) │
│ ├── Read main.py ✅ │
│ ├── Read models/__init__.py ✅ │
│ ├── Read routers/__init__.py ✅ │
│ └── Context7: FastAPI 认证最佳实践 ✅ │
│ │
│ Checkpoint: 分析项目结构 │
│ └── 确认使用 SQLAlchemy 2.0 + Pydantic v2 │
│ │
│ Wave 2: 实现核心组件 (并行) │
│ ├── 创建 models/user.py ✅ │
│ ├── 创建 utils/security.py ✅ │
│ └── 创建 utils/jwt.py ✅ │
│ │
│ Wave 3: 实现 API 端点 (并行) │
│ ├── 创建 routers/auth.py ✅ │
│ ├── 创建 schemas/auth.py ✅ │
│ └── 更新 main.py ✅ │
│ │
└──────────────────────────────────────────────────────────────┘步骤 7：代码实现示例
# models/user.py
from sqlalchemy import Column, Integer, String, DateTime, Boolean
from sqlalchemy.sql import func
from database import Base
class User(Base):
__tablename__ = "users"
id = Column(Integer, primary_key=True, index=True)
email = Column(String, unique=True, index=True, nullable=False)
hashed_password = Column(String, nullable=False)
is_active = Column(Boolean, default=True)
is_verified = Column(Boolean, default=False)
created_at = Column(DateTime(timezone=True), server_default=func.now())
updated_at = Column(DateTime(timezone=True), onupdate=func.now())
# utils/security.py
from passlib.context import CryptContext
import re
pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
def verify_password(plain_password: str, hashed_password: str) -> bool:
return pwd_context.verify(plain_password, hashed_password)
def get_password_hash(password: str) -> str:
return pwd_context.hash(password)
def validate_password_strength(password: str) -> tuple[bool, str]:
"""验证密码复杂度: 至少8位，包含大小写字母和数字"""
if len(password) < 8:
return False, "密码至少需要8个字符"
if not re.search(r"[a-z]", password):
return False, "密码需要包含小写字母"
if not re.search(r"[A-Z]", password):
return False, "密码需要包含大写字母"
if not re.search(r"\d", password):
return False, "密码需要包含数字"
return True, ""
# routers/auth.py
from fastapi import APIRouter, Depends, HTTPException, status
from sqlalchemy.orm import Session
from datetime import timedelta
from database import get_db
from models.user import User
from schemas.auth import UserCreate, UserLogin, Token, PasswordReset
from utils.security import get_password_hash, verify_password, validate_password_strength
from utils.jwt import create_access_token, ACCESS_TOKEN_EXPIRE_HOURS
router = APIRouter(prefix="/auth", tags=["authentication"])
@router.post("/register", status_code=status.HTTP_201_CREATED)
async def register(user: UserCreate, db: Session = Depends(get_db)):
# 验证密码强度
is_valid, error_msg = validate_password_strength(user.password)
if not is_valid:
raise HTTPException(status_code=400, detail=error_msg)
# 检查邮箱是否已注册
if db.query(User).filter(User.email == user.email).first():
raise HTTPException(status_code=409, detail="邮箱已被注册")
# 创建用户
db_user = User(
email=user.email,
hashed_password=get_password_hash(user.password)
)
db.add(db_user)
db.commit()
db.refresh(db_user)
return {"message": "注册成功", "user_id": db_user.id}
@router.post("/login", response_model=Token)
async def login(user: UserLogin, db: Session = Depends(get_db)):
db_user = db.query(User).filter(User.email == user.email).first()
if not db_user or not verify_password(user.password, db_user.hashed_password):
raise HTTPException(
status_code=status.HTTP_401_UNAUTHORIZED,
detail="邮箱或密码错误"
)
if not db_user.is_active:
raise HTTPException(status_code=400, detail="账户已被禁用")
access_token = create_access_token(
data={"sub": str(db_user.id)},
expires_delta=timedelta(hours=ACCESS_TOKEN_EXPIRE_HOURS)
)
return {"access_token": access_token, "token_type": "bearer"}步骤 8：四问验证
PM Agent [自我检查]:
┌──────────────────────────────────────────────────────────────┐
│ ✅ 四问验证 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 1. 所有测试通过了吗？ │
│ $ pytest tests/test_auth.py -v │
│ ✅ test_register_success PASSED │
│ ✅ test_register_duplicate_email PASSED │
│ ✅ test_register_weak_password PASSED │
│ ✅ test_login_success PASSED │
│ ✅ test_login_wrong_password PASSED │
│ ✅ test_password_reset_request PASSED │
│ ✅ test_password_reset_confirm PASSED │
│ ──────────────────────────────────────── │
│ 7 passed in 2.34s │
│ │
│ 2. 所有需求都满足了吗？ │
│ ✅ 登录功能 │
│ ✅ 注册功能 │
│ ✅ 密码重置功能 │
│ ✅ 密码复杂度验证（8位+大小写+数字） │
│ ✅ JWT 24小时过期 │
│ ✅ 支持多设备登录 │
│ │
│ 3. 没有未验证的假设吗？ │
│ 📖 Per FastAPI docs: OAuth2PasswordBearer 用于 JWT │
│ 📖 Per passlib docs: bcrypt 是推荐的哈希算法 │
│ 📖 Per OWASP: 密码复杂度要求符合标准 │
│ │
│ 4. 有证据吗？ │
│ 📊 代码变更: +245 行，-0 行 │
│ 📊 新文件: 6 个 │
│ 📊 测试覆盖: 92% │
│ │
│ 🎯 验证通过 │
│ │
└──────────────────────────────────────────────────────────────┘步骤 9：知识积累
PM Agent [知识积累]:
┌──────────────────────────────────────────────────────────────┐
│ 📚 更新 KNOWLEDGE.md │
├──────────────────────────────────────────────────────────────┤
│ │
│ ## 成功模式: FastAPI JWT 认证 │
│ │
│ ### 技术选型 │
│ - 密码哈希: passlib + bcrypt（成本因子 ≥12） │
│ - JWT: python-jose │
│ - 验证: Pydantic v2 │
│ │
│ ### 关键实现 │
│ - 密码验证在注册时进行，使用正则表达式 │
│ - JWT payload 只包含 user_id，不存敏感信息 │
│ - 使用 HTTPException 返回标准错误响应 │
│ │
│ ### 测试覆盖 │
│ - 正常流程 + 边界条件 + 错误情况 │
│ │
└──────────────────────────────────────────────────────────────┘
PM Agent [会话保存]:
write_memory("pm_context", {
"project": "电商后台",
"last_feature": "用户认证",
"status": "completed"
})
write_memory("last_session", "完成用户认证功能实现")最终输出
PM Agent: ✅ 用户认证功能已完成实现！
📁 创建的文件：
├── models/user.py # User 数据模型
├── schemas/auth.py # Pydantic schemas
├── utils/security.py # 密码哈希工具
├── utils/jwt.py # JWT 工具
├── routers/auth.py # 认证 API 路由
└── tests/test_auth.py # 测试用例
🔒 安全特性：
✅ bcrypt 密码哈希（成本因子 12）
✅ 密码复杂度验证
✅ JWT 24小时过期
✅ 标准错误响应
📊 测试结果：7 passed, 92% coverage
💡 下一步建议：
1. 运行数据库迁移: `alembic upgrade head`
2. 添加邮箱验证功能
3. 考虑添加登录日志🔍 案例 2：Deep Research 深度研究
场景描述
任务: 为新项目选择前端状态管理方案
要求: 比较 Redux、Zustand、Jotai、Recoil
输出: 技术选型报告完整对话流程
步骤 1：启动研究
用户: /sc:research 比较 React 状态管理方案：Redux vs Zustand vs Jotai vs Recoil，
给出 2024-2025 年的最新建议步骤 2：Deep Research Agent 激活
PM Agent → Deep Research Agent [委托]:
┌──────────────────────────────────────────────────────────────┐
│ 🔬 Deep Research Agent 已激活 │
├──────────────────────────────────────────────────────────────┤
│ │
│ 📋 研究计划 │
│ │
│ 策略: Unified（协作计划细化） │
│ │
│ 研究维度: │
│ 1. 基本特性对比 │
│ 2. 性能基准测试 │
│ 3. 学习曲线和开发体验 │
│ 4. 生态系统和社区 │
│ 5. 2024-2025 趋势 │
│ 6. 适用场景推荐 │
│ │
│ MCP 工具: │
│ ├── Tavily: 网络搜索 │
│ ├── Context7: 官方文档 │
│ └── Sequential: 多步推理 │
│ │
└──────────────────────────────────────────────────────────────┘步骤 3：多跳搜索执行
Deep Research Agent [搜索中]:
┌──────────────────────────────────────────────────────────────┐
│ 🔎 迭代搜索 (最多 5 轮) │
├──────────────────────────────────────────────────────────────┤
│ │
│ 轮次 1: 基础搜索 │
│ ├── "Redux vs Zustand 2024 comparison" │
│ ├── "Jotai vs Recoil performance benchmark" │
│ └── "React state management 2025 trends" │
│ │
│ 轮次 2: 深入搜索（基于轮次 1 结果） │
│ ├── "Zustand bundle size vs Redux Toolkit" │
│ ├── "Jotai atomic state management benefits" │
│ └── "Recoil Facebook deprecation status 2024" │
│ │
│ 轮次 3: 验证搜索 │
│ ├── Context7: Redux Toolkit 官方文档 │
│ ├── Context7: Zustand GitHub README │
│ └── npm trends: downloads comparison │
│ │
│ 质量评分: │
│ ├── 源可信度: 0.87 │
│ ├── 覆盖完整性: 0.92 │
│ └── 综合一致性: 0.89 │
│ │
│ ✅ 达到目标阈值 (0.8)，停止搜索 │
│ │
└──────────────────────────────────────────────────────────────┘步骤 4：研究报告
# React 状态管理方案对比报告 (2024-2025)
## 执行摘要
经过深度研究，**Zustand** 被推荐为 2024-2025 年大多数 React 项目的首选状态管理方案。
对于需要复杂派生状态的项目，**Jotai** 是优秀的替代选择。
## 详细对比
### 1. 基本信息
| 维度 | Redux Toolkit | Zustand | Jotai | Recoil |
|------|--------------|---------|-------|--------|
| **维护者** | Redux Team | Poimandres | Poimandres | Meta |
| **首次发布** | 2019 | 2019 | 2020 | 2020 |
| **Bundle Size** | 31KB | 3KB | 4KB | 21KB |
| **学习曲线** | 中高 | 低 | 低 | 中 |
| **TypeScript** | ✅ 优秀 | ✅ 优秀 | ✅ 优秀 | ⚠️ 一般 |
### 2. 性能基准 (2024 数据)重渲染性能（更新 1000 个组件）: ├── Zustand: ~45ms ⭐ ├── Jotai: ~52ms ├── Redux: ~68ms └── Recoil: ~75ms
内存占用（10K 状态更新）: ├── Jotai: ~12MB ⭐ ├── Zustand: ~15MB ├── Redux: ~22MB └── Recoil: ~28MB
### 3. NPM 下载趋势 (2024 年)周下载量 (2024 Q4): ├── Redux Toolkit: 3.2M (稳定) ├── Zustand: 2.8M (↑ 45% YoY) ├── Jotai: 0.9M (↑ 62% YoY) └── Recoil: 0.4M (↓ 23% YoY)
### 4. 代码对比
**Zustand (推荐)**
```typescript
import { create } from 'zustand'
interface Store {
count: number
increment: () => void
}
const useStore = create<Store>((set) => ({
count: 0,
increment: () => set((state) => ({ count: state.count + 1 })),
}))Redux Toolkit
import { createSlice, configureStore } from '@reduxjs/toolkit'
const counterSlice = createSlice({
name: 'counter',
initialState: { value: 0 },
reducers: {
increment: (state) => { state.value += 1 },
},
})
const store = configureStore({
reducer: { counter: counterSlice.reducer },
})Jotai
import { atom, useAtom } from 'jotai'
const countAtom = atom(0)
const doubleAtom = atom((get) => get(countAtom) * 2)
function Counter() {
const [count, setCount] = useAtom(countAtom)
return <button onClick={() => setCount(c => c + 1)}>{count}</button>
}5. 2024-2025 趋势分析
Zustand 趋势 ⬆️
- Server Components 兼容性最佳
- 社区活跃度持续增长
- 被 Vercel/Next.js 社区广泛采用
Jotai 趋势 ⬆️
- 原子化状态模型获得认可
- 与 React 19 兼容性好
- 适合复杂派生状态场景
Redux 趋势 ➡️
- 企业级项目仍是首选
- Redux Toolkit 简化了使用
- 但新项目采用率下降
Recoil 趋势 ⬇️
- Meta 减少维护投入
- 社区担忧长期支持
- 新项目不推荐使用
6. 场景推荐
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 新项目/小团队 | Zustand | 简单、轻量、学习曲线低 |
| 复杂派生状态 | Jotai | 原子化模型更适合 |
| 企业级大型项目 | Redux Toolkit | 成熟、可预测、易调试 |
| 需要持久化 | Zustand | 内置 persist 中间件 |
| 需要 DevTools | Redux/Zustand | 都有良好支持 |
7. 最终建议
首选: Zustand
- ✅ 最小 bundle size
- ✅ 最简单 API
- ✅ 最佳性能
- ✅ Server Components 兼容
替代: Jotai
- 适合需要复杂派生状态的场景
- 更接近 React 原生思维模型
企业级: Redux Toolkit
- 如果团队已有 Redux 经验
- 需要严格的状态管理规范
避免: Recoil
- Meta 支持减少
- 长期维护不确定
数据来源:
- npm trends (2024-12)
- GitHub Stars & Issues
- State of JS 2024 Survey
- 官方文档 (Context7 MCP)
#### 步骤 5：知识保存PM Agent [知识积累]: write_memory("research_state_management", { "date": "2024-12", "recommendation": "Zustand", "alternatives": ["Jotai", "Redux Toolkit"], "avoid": ["Recoil"] })
更新 KNOWLEDGE.md:
技术选型: React 状态管理 (2024-12)
- 首选: Zustand
- 替代: Jotai（复杂派生状态）
- 企业级: Redux Toolkit
- 避免: Recoil（维护风险）
---
## 🤝 案例 3：多代理协作开发
### 场景描述项目: 企业协作平台 需求: 添加实时聊天功能 要求:
- WebSocket 实时通信
- 消息持久化
- 已读状态
- 文件附件支持 技术栈: React + Node.js + PostgreSQL + Redis
### 完整对话流程
#### 步骤 1：需求分析用户: 我需要为协作平台添加实时聊天功能。要求支持 WebSocket 实时通信、 消息持久化、已读状态和文件附件。技术栈是 React + Node.js。
#### 步骤 2：PM Agent 规划多代理协作PM Agent [分析]: ┌──────────────────────────────────────────────────────────────┐ │ 🔍 请求分析 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 意图: 功能实现 │ │ 复杂度: 高（多组件、实时通信、跨域协作） │ │ 策略: 多代理并行协作 │ │ │ │ 📊 置信度: 88% │ │ └── 需求清晰，技术栈明确 │ │ │ │ ✅ 继续实现 │ │ │ └──────────────────────────────────────────────────────────────┘
PM Agent [代理分配]: ┌──────────────────────────────────────────────────────────────┐ │ 🤖 多代理协作计划 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Phase 1: 架构设计 (并行) │ │ ├── System Architect │ │ │ └── 整体架构 + WebSocket 方案 │ │ ├── Backend Architect │ │ │ └── API 设计 + 数据模型 │ │ └── Frontend Architect │ │ └── UI 组件 + 状态管理 │ │ │ │ Phase 2: 安全审查 │ │ └── Security Engineer │ │ └── 消息加密 + 认证机制 │ │ │ │ Phase 3: 实现 (并行) │ │ ├── Backend 实现 │ │ └── Frontend 实现 │ │ │ │ Phase 4: 质量保证 │ │ ├── Quality Engineer │ │ │ └── 测试策略 │ │ └── Performance Engineer │ │ └── 负载测试 │ │ │ └──────────────────────────────────────────────────────────────┘
#### 步骤 3：Phase 1 - 架构设计│ 🏗️ 系统架构设计 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Client (React) │ │ │ │ │ ├── HTTP ──→ API Server (REST) │ │ │ │ │ │ └── WS ───→ WebSocket Server │ │ │ │ │ ├──→ Redis (Pub/Sub + Cache) │ │ │ │ │ └──→ PostgreSQL (Persistence) │ │ │ │ 推荐方案: │ │ ├── WebSocket: Socket.io (自动重连、房间管理) │ │ ├── 消息队列: Redis Pub/Sub (跨实例消息分发) │ │ ├── 缓存: Redis (最近消息、在线状态) │ │ └── 存储: PostgreSQL (消息历史、附件元数据) │ │ │ └──────────────────────────────────────────────────────────────┘
│ 📦 数据模型设计 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Message │ │ ├── id: UUID │ │ ├── conversation_id: UUID │ │ ├── sender_id: UUID │ │ ├── content: Text │ │ ├── message_type: Enum (text, file, system) │ │ ├── attachment_url: String? │ │ ├── created_at: Timestamp │ │ └── read_by: UUID[] │ │ │ │ Conversation │ │ ├── id: UUID │ │ ├── type: Enum (direct, group) │ │ ├── participants: UUID[] │ │ ├── last_message_at: Timestamp │ │ └── created_at: Timestamp │ │ │ │ API 端点: │ │ ├── POST /api/conversations 创建对话 │ │ ├── GET /api/conversations 获取对话列表 │ │ ├── GET /api/conversations/:id/messages 获取消息 │ │ ├── POST /api/messages 发送消息 │ │ ├── POST /api/messages/:id/read 标记已读 │ │ └── POST /api/upload 上传附件 │ │ │ └──────────────────────────────────────────────────────────────┘
│ 🎨 前端架构设计 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 组件结构: │ │ └── ChatApp │ │ ├── ConversationList │ │ │ └── ConversationItem │ │ └── ChatWindow │ │ ├── MessageList │ │ │ └── MessageItem │ │ │ └── AttachmentPreview │ │ ├── MessageInput │ │ │ └── FileUploader │ │ └── TypingIndicator │ │ │ │ 状态管理 (Zustand): │ │ ├── useConversationStore │ │ │ ├── conversations[] │ │ │ ├── activeConversationId │ │ │ └── unreadCounts{} │ │ └── useMessageStore │ │ ├── messages{} │ │ ├── sendMessage() │ │ └── markAsRead() │ │ │ │ WebSocket 集成: │ │ ├── useSocket() hook │ │ ├── 自动重连机制 │ │ └── 消息事件处理 │ │ │ └──────────────────────────────────────────────────────────────┘
#### 步骤 4：Phase 2 - 安全审查│ 🔒 安全审查报告 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ ✅ 认证机制 │ │ ├── WebSocket 连接使用 JWT 认证 │ │ ├── Token 在 handshake 时验证 │ │ └── 无效 token 立即断开连接 │ │ │ │ ✅ 消息安全 │ │ ├── 输入验证: 消息长度限制 (10KB) │ │ ├── XSS 防护: 内容转义 │ │ └── 权限检查: 只能发送到参与的对话 │ │ │ │ ✅ 文件上传 │ │ ├── 文件类型白名单 │ │ ├── 文件大小限制 (10MB) │ │ ├── 病毒扫描集成 │ │ └── 存储到安全的对象存储 │ │ │ │ ⚠️ 建议 │ │ ├── 添加消息速率限制 (防刷) │ │ ├── 考虑端到端加密 (可选) │ │ └── 添加审计日志 │ │ │ └──────────────────────────────────────────────────────────────┘
#### 步骤 5：Phase 3 - 并行实现PM Agent [并行执行]: ┌──────────────────────────────────────────────────────────────┐ │ 🚀 Wave 并行实现 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ Wave 1: 基础设施 (并行) │ │ ├── 后端: 数据模型 + 迁移 ✅ │ │ ├── 后端: WebSocket 服务器 ✅ │ │ └── 前端: 基础组件结构 ✅ │ │ │ │ Checkpoint: 接口对齐 │ │ └── 确认 API 契约和 WebSocket 事件格式 │ │ │ │ Wave 2: 核心功能 (并行) │ │ ├── 后端: REST API 实现 ✅ │ │ ├── 后端: 消息处理逻辑 ✅ │ │ ├── 前端: 对话列表组件 ✅ │ │ └── 前端: 消息组件 ✅ │ │ │ │ Wave 3: 高级功能 (并行) │ │ ├── 后端: 文件上传 ✅ │ │ ├── 后端: 已读状态 ✅ │ │ ├── 前端: 文件上传组件 ✅ │ │ └── 前端: 已读状态显示 ✅ │ │ │ │ Wave 4: 集成测试 │ │ └── 端到端测试 ✅ │ │ │ └──────────────────────────────────────────────────────────────┘
#### 步骤 6：Phase 4 - 质量保证│ 🧪 测试报告 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 单元测试: │ │ ├── 后端: 45 tests, 94% coverage ✅ │ │ └── 前端: 38 tests, 89% coverage ✅ │ │ │ │ 集成测试: │ │ ├── API 测试: 12 tests ✅ │ │ └── WebSocket 测试: 8 tests ✅ │ │ │ │ E2E 测试 (Playwright): │ │ ├── 发送消息流程 ✅ │ │ ├── 文件上传流程 ✅ │ │ ├── 已读状态同步 ✅ │ │ └── 断线重连 ✅ │ │ │ └──────────────────────────────────────────────────────────────┘
│ ⚡ 性能测试报告 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 负载测试结果: │ │ ├── 并发连接: 10,000 ✅ │ │ ├── 消息延迟: <100ms (P99) ✅ │ │ ├── 吞吐量: 50,000 msg/s ✅ │ │ └── 内存使用: 稳定，无泄漏 ✅ │ │ │ │ 优化建议: │ │ ├── ✅ 已实现消息批量发送 │ │ ├── ✅ 已实现连接池 │ │ └── 建议: 考虑消息压缩 (大规模部署时) │ │ │ └──────────────────────────────────────────────────────────────┘
#### 步骤 7：四问验证和总结PM Agent [四问验证]: ┌──────────────────────────────────────────────────────────────┐ │ ✅ 四问验证 │ ├──────────────────────────────────────────────────────────────┤ │ │ │ 1. 所有测试通过了吗？ │ │ ✅ 后端: 45/45 passed │ │ ✅ 前端: 38/38 passed │ │ ✅ E2E: 4/4 passed │ │ │ │ 2. 所有需求都满足了吗？ │ │ ✅ WebSocket 实时通信 │ │ ✅ 消息持久化 │ │ ✅ 已读状态 │ │ ✅ 文件附件支持 │ │ │ │ 3. 没有未验证的假设吗？ │ │ 📖 Socket.io docs: 房间管理最佳实践 │ │ 📖 Redis docs: Pub/Sub 模式 │ │ 📖 安全最佳实践已审查 │ │ │ │ 4. 有证据吗？ │ │ 📊 代码: +2,450 行 │ │ 📊 测试覆盖: 91% │ │ 📊 负载测试: 10K 并发 ✅ │ │ │ │ 🎯 验证通过 │ │ │ └──────────────────────────────────────────────────────────────┘
#### 最终输出PM Agent: ✅ 实时聊天功能已完成！
📁 后端新增文件: ├── models/message.js ├── models/conversation.js ├── routes/conversations.js ├── routes/messages.js ├── services/socketService.js ├── services/uploadService.js └── tests/
📁 前端新增文件: ├── components/Chat/ ├── hooks/useSocket.ts ├── stores/conversationStore.ts ├── stores/messageStore.ts └── tests/
📊 测试结果: ├── 后端: 45 tests, 94% coverage ├── 前端: 38 tests, 89% coverage └── E2E: 4/4 passed
⚡ 性能指标: ├── 并发连接: 10,000+ ├── 消息延迟: <100ms (P99) └── 吞吐量: 50,000 msg/s
🔒 安全特性: ├── JWT 认证 ├── 输入验证 ├── 文件类型白名单 └── 速率限制
💡 代理协作统计: ├── System Architect: 架构设计 ├── Backend Architect: API 设计 ├── Frontend Architect: UI 设计 ├── Security Engineer: 安全审查 ├── Quality Engineer: 测试策略 └── Performance Engineer: 负载测试
🎯 下一步建议:
- 部署到预发布环境测试
- 考虑添加消息撤回功能
- 考虑添加端到端加密
---
## 📊 案例总结
### 三个案例的关键差异
| 维度 | 案例 1 | 案例 2 | 案例 3 |
|------|--------|--------|--------|
| **任务类型** | 功能实现 | 技术调研 | 复杂功能 |
| **代理数量** | 3 个 | 1 个 | 6 个 |
| **执行模式** | Wave 并行 | 迭代搜索 | 多阶段并行 |
| **MCP 使用** | Context7 | Tavily + Context7 | 全部 |
| **耗时** | ~30 分钟 | ~15 分钟 | ~2 小时 |
### SuperClaude 的核心价值体现
1. **置信度检查** - 避免盲目实现，提前确认需求
2. **代理协作** - 专业分工，并行执行
3. **四问验证** - 确保质量，防止幻觉
4. **知识积累** - 经验沉淀，持续改进
---
**下一节：** [9.5 本章小结](./9.5-本章小结.md) — 回顾核心知识点，掌握最佳实践！
---
*SuperClaude 教程 v1.0 | 2025 Edition | 基于 SuperClaude Framework v4.1.9*