gaoqiongxie Writing Plans - 详细实施计划
来源: obra/superpowers (142K⭐) - AI辅助开发方法论框架
参考: github.com/JackyST0/awesome-agent-skills
核心理念
"计划是成功路线图" —— 没有计划的行动是盲目的
Writing Plans 帮助将复杂任务分解为清晰的、可执行的步骤，确保每次只专注于一件事。
计划结构
## 任务名称
### 概述
[简要描述要做什么]
### 阶段1: [阶段名称]
#### 目标
[这个阶段要完成什么]
#### 具体步骤
1. [步骤1]
2. [步骤2]
3. [步骤3]
#### 验证点
- [ ] 验证1
- [ ] 验证2
### 阶段2: [阶段名称]
...
### 风险与应对
| 风险 | 应对措施 |
|-----|---------|
| [风险1] | [措施1] |
| [风险2] | [措施2] |
### 完成标准
- [ ] 所有验证点通过
- [ ] 测试通过
- [ ] 代码审查通过
分解原则
1. 原子化
每个步骤应该：
- 单一职责
- 可独立验证
- 耗时 5-30 分钟
2. 顺序依赖
明确步骤间的依赖：
步骤1 → 步骤2 → 步骤3
↓
步骤4 → 步骤5
3. 可验证
每个阶段后检查：
- 功能是否按预期工作？
- 是否有破坏性变更？
- 测试是否通过？
阶段划分策略
按功能模块划分
阶段1: 数据层（Entity, Repository）
阶段2: 业务层（Service）
阶段3: 接口层（Controller）
阶段4: 前端（如需要）
阶段5: 测试
阶段6: 部署
按风险高低划分
阶段1: 低风险部分（建立基础）
阶段2: 核心功能（重点测试）
阶段3: 高风险部分（仔细验证）
阶段4: 完善优化
按价值交付划分
阶段1: MVP（最小可用版本）
阶段2: 完整功能
阶段3: 优化完善
计划模板
简单任务 (1-2小时)
## 任务：添加用户头像上传功能
### 步骤
1. 添加文件上传API
2. 配置OSS存储
3. 添加前端上传组件
4. 集成头像显示
5. 添加测试
### 验证
- [ ] 上传成功
- [ ] 正确显示头像
- [ ] 测试通过
中等任务 (半天-1天)
## 任务：实现用户评论功能
### 阶段1: 数据库设计
1. 创建评论表
2. 添加索引
3. 验证迁移
### 阶段2: 后端API
1. 评论列表API
2. 发布评论API
3. 删除评论API
4. 单元测试
### 阶段3: 前端
1. 评论列表组件
2. 评论输入框
3. 集成API
### 阶段4: 联调测试
1. 前后端联调
2. 边界测试
3. 性能测试
### 完成标准
- [ ] 所有API测试通过
- [ ] 前端功能正常
- [ ] 代码审查通过
大型任务 (3天以上)
## 任务：支付系统重构
### 概述
将现有支付模块重构为插件化架构，支持多支付渠道
### 阶段1: 基础架构 (第1天)
**目标**: 建立插件框架
**步骤**:
1. 设计插件接口
2. 实现插件加载器
3. 基础测试
**验证**:
- [ ] 插件接口可用
- [ ] 加载器工作正常
### 阶段2: 迁移微信支付 (第2天)
**目标**: 微信支付作为第一个插件
**步骤**:
1. 创建微信支付插件
2. 迁移现有逻辑
3. 适配插件接口
4. 单元测试
**验证**:
- [ ] 微信支付可用
- [ ] 测试通过
### 阶段3: 迁移支付宝 (第3天)
**目标**: 支付宝插件
[同上结构]
### 阶段4: 完善与文档 (第4天)
**目标**: 完善和文档
- 添加其他插件示例
- 编写开发者文档
- 完整集成测试
### 风险与应对
| 风险 | 应对 |
|-----|------|
| 支付中断 | 回滚方案 |
| 接口兼容 | 抽象层隔离 |
| 测试覆盖不足 | 增加自动化测试 |
### 完成标准
- [ ] 微信/支付宝可用
- [ ] 插件可热插拔
- [ ] 文档完整
- [ ] 覆盖率 > 80%
执行技巧
番茄工作法结合
🍅 番茄钟 1 (25min): 步骤1-2
☕ 休息 5min
🍅 番茄钟 2 (25min): 步骤3-4
☕ 休息 5min
🍅 番茄钟 3: 验证
检查点
每个阶段完成后：
- 提交代码
- 运行测试
- 确认无误
- 开始下一阶段
计划调整
如果发现计划不合理：
- ❌ 不继续硬着头皮做
- ✅ 停下来重新分析
- ✅ 更新计划
- ✅ 继续执行
输出示例
用户说："帮我实现一个秒杀系统"
AI制定计划：
## 秒杀系统实现计划
### 概述
实现一个高并发的秒杀系统，支持库存扣减、限流、防止超卖
### 阶段1: 库存扣减 (Day 1)
**目标**: 解决超卖问题
**步骤**:
1. 设计库存表结构
- `秒杀商品表`
- `秒杀订单表`
2. 实现乐观锁扣减
```sql
UPDATE stock
SET count = count - 1
WHERE id = ? AND count > 0
- 添加Redis分布式锁
- 获取锁
- 执行扣减
- 释放锁
验证:
- 100并发不超卖
- 单元测试通过
阶段2: 限流 (Day 2)
目标: 防止系统崩溃
步骤:
接口限流
- 限流算法选择
- 限流配置
验证码
- 秒杀前答题
- 过滤机器人
验证:
- 1000QPS正常
- 验证码有效
阶段3: 前端 (Day 3)
目标: 用户界面
步骤:
- 秒杀倒计时
- 秒杀按钮状态
- 结果展示
阶段4: 完整测试 (Day 4)
目标: 系统稳定
步骤:
- 全链路压测
- 监控告警
- 应急预案
完成标准
- 不超卖
- 可抗1000并发
- 用户体验流畅
- 监控完善
---
## 注意事项
- ✅ 每个步骤要具体可执行
- ✅ 明确验证点
- ✅ 识别风险
- ✅ 留有余地
- ❌ 不要过度计划（YAGNI）
- ❌ 不要模糊步骤（"做XX功能"）