# Planning And Task Breakdown

> 将工作拆成有顺序的任务。适用于你已经有 spec 或明确需求，需要把工作拆成可实现任务的时候。也适用于任务大到难以下手、需要估算范围，或存在并行工作的可能性时。

- Skill: `233i/planning-and-task-breakdown` (Agent Skill)
- Install (CLI): `npx skillmds@latest add 233i/planning-and-task-breakdown`
- Raw SKILL.md: https://api.skillmd.com/api/skills/233i/planning-and-task-breakdown/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: 233i (https://skillmd.com/u/233i)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/233i/planning-and-task-breakdown

---


# 规划与任务拆解

## 概览

把工作拆成小而可验证的任务，并给每个任务明确的验收标准。好的任务拆解，是 agent 能稳定完成工作与把事情做成一团乱麻之间的区别。每个任务都应该小到可以在一次专注会话中完成实现、测试和验证。

## 何时使用

- 你已经有 spec，需要把它拆成可执行单元
- 任务太大或太模糊，难以下手
- 工作需要在多个 agent 或多个会话之间并行展开
- 你需要向人类说明工作范围
- 实现顺序并不明显

**不适用的场景：** 单文件且范围显而易见的改动，或 spec 中已经包含了定义清晰的任务。

## 规划流程

### 步骤 1：进入规划模式（Plan Mode）

在写任何代码之前，先以只读模式工作：

- 阅读 spec 和相关代码区域
- 识别现有模式和约定
- 绘制组件间依赖
- 记录风险与未知项

**规划阶段不要写代码。** 产出应该是一份计划文档，而不是实现。

### 步骤 2：识别依赖图

先画清楚谁依赖谁：

```
Database schema
    │
    ├── API models/types
    │       │
    │       ├── API endpoints
    │       │       │
    │       │       └── Frontend API client
    │       │               │
    │       │               └── UI components
    │       │
    │       └── Validation logic
    │
    └── Seed data / migrations
```

实现顺序应该沿依赖图自底向上推进，先打基础。

### 步骤 3：做纵向切片

不要先做完整数据库、再做完整 API、再做完整 UI。应该一次打通一条完整功能路径：

**坏例子（水平切片）：**
```
Task 1: Build entire database schema
Task 2: Build all API endpoints
Task 3: Build all UI components
Task 4: Connect everything
```

**好例子（纵向切片）：**
```
Task 1: User can create an account (schema + API + UI for registration)
Task 2: User can log in (auth schema + API + UI for login)
Task 3: User can create a task (task schema + API + UI for creation)
Task 4: User can view task list (query + API + UI for list view)
```

每个纵向切片都能交付可工作的、可测试的功能。

### 步骤 4：编写任务

每个任务都遵循如下结构：

```markdown
## Task [N]: [简短描述性标题]

**Description:** 一段话说明这个任务完成什么。

**Acceptance criteria:**
- [ ] [具体且可测试的条件]
- [ ] [具体且可测试的条件]

**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] Manual check: [需要检查什么]

**Dependencies:** [依赖哪些任务编号，或写 "None"]

**Files likely touched:**
- `src/path/to/file.ts`
- `tests/path/to/test.ts`

**Estimated scope:** [Small: 1-2 files | Medium: 3-5 files | Large: 5+ files]
```

### 步骤 5：排序并设置检查点

排列任务时确保：

1. 依赖先满足，基础优先
2. 每个任务完成后系统仍处于可工作状态
3. 每做完 2 到 3 个任务就设置一次验证检查点
4. 高风险任务尽量提前，尽早失败

加入显式检查点：

```markdown
## Checkpoint: After Tasks 1-3
- [ ] All tests pass
- [ ] Application builds without errors
- [ ] Core user flow works end-to-end
- [ ] Review with human before proceeding
```

## 任务大小指南

| 大小 | 文件数 | 范围 | 示例 |
|------|--------|------|------|
| **XS** | 1 | 单个函数或配置改动 | 新增一个校验规则 |
| **S** | 1-2 | 一个组件或一个 endpoint | 新增一个 API endpoint |
| **M** | 3-5 | 一个完整功能切片 | 用户注册流程 |
| **L** | 5-8 | 多组件功能 | 带筛选和分页的搜索 |
| **XL** | 8+ | **太大了，必须继续拆** | — |

如果任务达到 L 或更大，就应该继续拆小。Agent 最擅长的是 S 和 M 尺寸的任务。

**以下情况说明任务还要继续拆：**
- 一次专注会话做不完，大致超过 2 小时 agent 工作量
- 你无法用 3 条以内 bullet 描述清验收标准
- 它同时涉及两个或更多相互独立的子系统，例如 auth 和 billing
- 你在任务标题里开始写 “and”，这通常意味着其实是两个任务

## 计划文档模板

```markdown
# Implementation Plan: [功能/项目名称]

## Overview
[一段话总结我们要做什么]

## Architecture Decisions
- [关键决策 1 及原因]
- [关键决策 2 及原因]

## Task List

### Phase 1: Foundation
- [ ] Task 1: ...
- [ ] Task 2: ...

### Checkpoint: Foundation
- [ ] Tests pass, builds clean

### Phase 2: Core Features
- [ ] Task 3: ...
- [ ] Task 4: ...

### Checkpoint: Core Features
- [ ] End-to-end flow works

### Phase 3: Polish
- [ ] Task 5: ...
- [ ] Task 6: ...

### Checkpoint: Complete
- [ ] All acceptance criteria met
- [ ] Ready for review

## Risks and Mitigations
| Risk | Impact | Mitigation |
|------|--------|------------|
| [Risk] | [High/Med/Low] | [Strategy] |

## Open Questions
- [需要人类输入的问题]
```

## 并行化机会

当你有多个 agent 或多个会话可用时：

- **适合并行：** 相互独立的功能切片、已实现功能的测试、文档编写
- **必须串行：** 数据库迁移、共享状态变更、存在严格依赖链的工作
- **需要协调：** 共享同一个 API 契约的功能，先定义契约，再并行实现

## 常见自我安慰

| 自我安慰 | 现实 |
|---|---|
| “边做边想就行” | 这样最容易做成一团乱麻然后返工。10 分钟规划，能省掉数小时。 |
| “这些任务很明显，不用写” | 还是要写下来。显式任务能暴露隐藏依赖和遗漏的边界情况。 |
| “规划是额外开销” | 规划本身就是任务的一部分。没有计划的实现，只是在打字。 |
| “这些我都能记在脑子里” | 上下文窗口是有限的。写下来的计划能跨会话保存，也能在压缩后继续存在。 |

## 危险信号

- 没有书面任务列表就开始实现
- 任务只写“实现这个功能”，没有验收标准
- 计划里没有验证步骤
- 所有任务都是 XL 大小
- 任务之间没有检查点
- 完全没考虑依赖顺序

## 验证

开始实现前，确认：

- [ ] 每个任务都有验收标准
- [ ] 每个任务都有验证步骤
- [ ] 任务依赖已识别并排序正确
- [ ] 没有任务会改动超过约 5 个文件
- [ ] 主要阶段之间设置了检查点
- [ ] 人类已经审阅并批准了计划