233i 规划与任务拆解
概览
把工作拆成小而可验证的任务，并给每个任务明确的验收标准。好的任务拆解，是 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：编写任务
每个任务都遵循如下结构：
## 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：排序并设置检查点
排列任务时确保：
- 依赖先满足，基础优先
- 每个任务完成后系统仍处于可工作状态
- 每做完 2 到 3 个任务就设置一次验证检查点
- 高风险任务尽量提前，尽早失败
加入显式检查点：
## 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”，这通常意味着其实是两个任务
计划文档模板
# 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 个文件
- 主要阶段之间设置了检查点
- 人类已经审阅并批准了计划