---
description: 重新阐述需求、评估风险并创建分步实施计划。在接触任何代码之前，等待用户确认。
---

# 计划命令

此命令调用 **planner** 代理，在编写任何代码之前创建一个全面的实施计划。

## 此命令的作用

1. **重新阐述需求** - 明确需要构建什么
2. **识别风险** - 揭示潜在问题和阻碍
3. **创建分步计划** - 将实施分解为多个阶段
4. **等待确认** - 必须获得用户批准才能继续

## 何时使用

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

* 开始新功能时
* 进行重大架构变更时
* 处理复杂重构时
* 多个文件/组件将受到影响时
* 需求不明确或存在歧义时

## 工作原理

planner 代理将：

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

## 使用示例

```
User: /plan 我需要为市场结算时添加实时通知功能

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

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

## 实施阶段

### 第一阶段：数据库架构
- 添加 notifications 表，包含列：id, user_id, market_id, type, status, created_at
- 添加 user_notification_preferences 表用于存储渠道偏好设置
- 在 user_id 和 market_id 上创建索引以提升性能

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

### 第三阶段：集成点
- 接入市场结算逻辑（当状态变为 "resolved" 时）
- 查询在市场中有持仓的所有用户
- 为每个用户将通知加入队列

### 第四阶段：前端组件
- 在头部创建 NotificationBell 组件
- 添加 NotificationList 模态框
- 通过 Supabase 订阅实现实时更新
- 添加通知偏好设置页面

## 依赖项
- Redis（用于队列）
- 电子邮件服务（SendGrid/Resend）
- Supabase 实时订阅

## 风险
- 高：电子邮件送达率（需要配置 SPF/DKIM）
- 中：市场用户超过 1000+ 时的性能问题
- 中：市场频繁结算可能导致通知泛滥
- 低：实时订阅开销

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

**等待确认**：是否按此计划进行？（是/否/修改）
```

## 重要说明

**关键**：planner 代理在您明确用“是”、“继续”或类似的肯定性答复确认计划之前，**不会**编写任何代码。

如果您希望修改，请回复：

* "修改：\[您的修改内容]"
* "不同方法：\[替代方案]"
* "跳过阶段 2，先执行阶段 3"

## 与其他命令的集成

计划之后：

* 使用 `/tdd` 通过测试驱动开发来实现
* 如果出现构建错误，请使用 `/build-fix`
* 使用 `/code-review` 来审查已完成的实现

## 相关代理

此命令调用由 ECC 提供的 `planner` 代理。

对于手动安装，源文件位于：
`agents/planner.md`