/plan

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

Plan 命令

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

此命令的功能

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

何时使用

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

• 开始新功能开发
• 进行重大架构变更
• 处理复杂的重构工作
• 多个文件/组件将受到影响
• 需求不清楚或有歧义

工作原理

planner 代理将：

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

使用示例

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

代理（planner）：
# 实施计划：实时市场结算通知

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

## 实施阶段

### 阶段 1：数据库架构
- 添加 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 实时订阅

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

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

**等待确认**：继续执行此计划？（是/否/修改）

重要说明

**关键**：planner 代理在您明确确认计划（使用 "是"、"继续" 或类似肯定回复）之前**不会**编写任何代码。

如果您想要更改，请回复：

• "修改：[您的更改]"
• "换个方案：[替代方案]"
• "跳过阶段 2，先做阶段 3"

与其他命令的集成

计划完成后：

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

相关代理

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