# Writing Plans

> 详细实施计划制定技能，将功能分解为多个可执行阶段。适用于大型功能、多文件更改、需要分步骤完成的项目。当用户开始新任务、需要制定计划、分解复杂工作时使用。

- Skill: `gaoqiongxie/writing-plans` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add gaoqiongxie/writing-plans`
- Raw SKILL.md: https://api.skillmd.com/api/skills/gaoqiongxie/writing-plans/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: gaoqiongxie (https://skillmd.com/u/gaoqiongxie)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/gaoqiongxie/writing-plans

---


# 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小时)
```markdown
## 任务：添加用户头像上传功能

### 步骤
1. 添加文件上传API
2. 配置OSS存储
3. 添加前端上传组件
4. 集成头像显示
5. 添加测试

### 验证
- [ ] 上传成功
- [ ] 正确显示头像
- [ ] 测试通过
```

### 中等任务 (半天-1天)
```markdown
## 任务：实现用户评论功能

### 阶段1: 数据库设计
1. 创建评论表
2. 添加索引
3. 验证迁移

### 阶段2: 后端API
1. 评论列表API
2. 发布评论API
3. 删除评论API
4. 单元测试

### 阶段3: 前端
1. 评论列表组件
2. 评论输入框
3. 集成API

### 阶段4: 联调测试
1. 前后端联调
2. 边界测试
3. 性能测试

### 完成标准
- [ ] 所有API测试通过
- [ ] 前端功能正常
- [ ] 代码审查通过
```

### 大型任务 (3天以上)
```markdown
## 任务：支付系统重构

### 概述
将现有支付模块重构为插件化架构，支持多支付渠道

### 阶段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: 验证
```

### 检查点
每个阶段完成后：
1. 提交代码
2. 运行测试
3. 确认无误
4. 开始下一阶段

### 计划调整
如果发现计划不合理：
- ❌ 不继续硬着头皮做
- ✅ 停下来重新分析
- ✅ 更新计划
- ✅ 继续执行

## 输出示例

### 用户说："帮我实现一个秒杀系统"

**AI制定计划**：

```markdown
## 秒杀系统实现计划

### 概述
实现一个高并发的秒杀系统，支持库存扣减、限流、防止超卖

### 阶段1: 库存扣减 (Day 1)
**目标**: 解决超卖问题

**步骤**:
1. 设计库存表结构
   - `秒杀商品表`
   - `秒杀订单表`

2. 实现乐观锁扣减
   ```sql
   UPDATE stock 
   SET count = count - 1 
   WHERE id = ? AND count > 0
   ```

3. 添加Redis分布式锁
   - 获取锁
   - 执行扣减
   - 释放锁

**验证**:
- [ ] 100并发不超卖
- [ ] 单元测试通过

### 阶段2: 限流 (Day 2)
**目标**: 防止系统崩溃

**步骤**:
1. 接口限流
   - 限流算法选择
   - 限流配置

2. 验证码
   - 秒杀前答题
   - 过滤机器人

**验证**:
- [ ] 1000QPS正常
- [ ] 验证码有效

### 阶段3: 前端 (Day 3)
**目标**: 用户界面

**步骤**:
1. 秒杀倒计时
2. 秒杀按钮状态
3. 结果展示

### 阶段4: 完整测试 (Day 4)
**目标**: 系统稳定

**步骤**:
1. 全链路压测
2. 监控告警
3. 应急预案

### 完成标准
- [ ] 不超卖
- [ ] 可抗1000并发
- [ ] 用户体验流畅
- [ ] 监控完善
```

---

## 注意事项

- ✅ 每个步骤要具体可执行
- ✅ 明确验证点
- ✅ 识别风险
- ✅ 留有余地
- ❌ 不要过度计划（YAGNI）
- ❌ 不要模糊步骤（"做XX功能"）