/plan

description: 重述需求、评估风险并制定分步实施计划。在修改任何代码之前，必须等待用户确认（CONFIRM）。

计划命令（Plan Command）

此命令调用**规划者智能体（Planner Agent）**，在编写任何代码之前创建一个全面的实施计划。

此命令的作用

1. **重述需求** - 澄清需要构建的内容 2. **识别风险** - 发现潜在问题和阻塞因素 3. **创建分步计划** - 将实施分解为不同阶段 4. **等待确认** - 在继续操作之前**必须**获得用户批准

何时使用

在以下情况下使用 `/plan`：

• 开始开发新功能
• 进行重大的架构调整
• 进行复杂的代码重构
• 涉及多个文件/组件的变动
• 需求不清晰或存在歧义

工作原理

规划者智能体（Planner Agent）将：

1. **分析请求**并以清晰的术语重述需求 2. **分解为多个阶段**，并附带具体、可操作的步骤 3. **识别组件之间的依赖关系** 4. **评估风险**和潜在的阻塞因素 5. **预估复杂度**（高/中/低） 6. **展示计划**并等待您的明确确认

使用示例

用户: /plan 我需要添加市场结算时的实时通知功能

智能体 (planner):
# 实施计划：实时市场结算通知

## 需求重述
- 当用户关注的市场结算时发送通知
- 支持多种通知渠道（应用内、电子邮件、Webhook）
- 确保通知可靠送达
- 包含市场结果和用户的持仓结果

## 实施阶段

### 阶段 1: 数据库 Schema
- 添加 notifications 表，包含列：id, user_id, market_id, type, status, created_at
- 添加 user_notification_preferences 表用于渠道偏好设置
- 为 user_id 和 market_id 创建索引以优化性能

### 阶段 2: 通知服务
- 在 lib/notifications.ts 中创建通知服务
- 使用 BullMQ/Redis 实现通知队列
- 为发送失败的任务添加重试逻辑
- 创建通知模板

### 阶段 3: 集成点
- 挂载到市场结算逻辑（当状态变为 "resolved" 时）
- 查询在该市场中持有仓位的所有用户
- 为每个用户生成通知并入队

### 阶段 4: 前端组件
- 在页头创建 NotificationBell 组件
- 添加 NotificationList 弹窗
- 通过 Supabase 订阅实现实时更新
- 添加通知偏好设置页面

## 依赖项
- Redis (用于队列)
- 邮件服务 (SendGrid/Resend)
- Supabase 实时订阅

## 风险
- 高 (HIGH): 电子邮件可送达性（需要 SPF/DKIM）
- 中 (MEDIUM): 每个市场超过 1000 名用户时的性能问题
- 中 (MEDIUM): 如果市场频繁结算可能导致通知轰炸
- 低 (LOW): 实时订阅的额外开销

## 预估复杂度: 中 (MEDIUM)
- 后端: 4-6 小时
- 前端: 3-4 小时
- 测试: 2-3 小时
- 总计: 9-13 小时

**等待确认**: 是否按照此计划执行？(yes/no/modify)

重要提示

**关键 (CRITICAL)**: 在您通过 "yes"、"proceed" 或类似的肯定回复明确确认计划之前，规划者智能体（Planner Agent）**不会**编写任何代码。

如果您需要修改，可以回复：

• "modify: [您的修改内容]"
• "different approach: [替代方案]"
• "skip phase 2 and do phase 3 first"（跳过阶段 2，先做阶段 3）

与其他命令的集成

规划完成后：

• 使用 `/tdd` 进行测试驱动开发实施
• 如果出现构建错误，使用 `/build-fix`
• 使用 `/code-review` 审查已完成的实施

相关智能体（Agents）

此命令调用位于以下位置的 `planner` 智能体： `~/.claude/agents/planner.md`