planning-and-task-breakdown

Planning and Task Breakdown

概览

把工作拆解成小而可验证的任务，并为每个任务写明验收标准。好的任务拆解，是可靠完成工作的 agent 和产出纠缠混乱结果的 agent 之间的区别。每个任务都应该足够小，能在一次专注会话中实现、测试和验证。

何时使用

• 你已有 spec，需要把它拆成可实现单元
• 一个任务感觉太大或太模糊，难以下手
• 工作需要跨多个 agents 或会话并行
• 你需要向人类沟通范围
• 实现顺序并不明显

何时不要使用： 范围显而易见的单文件变更，或 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]: [Short descriptive title]

**Description:** One paragraph explaining what this task accomplishes.

**Acceptance criteria:**
- [ ] [Specific, testable condition]
- [ ] [Specific, testable condition]

**Verification:**
- [ ] Tests pass: `npm test -- --grep "feature-name"`
- [ ] Build succeeds: `npm run build`
- [ ] Manual check: [description of what to verify]

**Dependencies:** [Task numbers this depends on, or "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. 高风险任务靠前（快速失败）