任务拆分¶

大任务是 Vibe Coding 失败的主要原因之一。本章讲解如何把复杂需求切成可独立验证的小任务。

为什么要拆分¶

AI 的注意力随上下文增长而分散，小任务的输出质量更高
小任务失败时，回滚成本低
每个小任务都能独立验证，问题更容易定位
并行执行多个小任务，整体效率更高

拆分原则¶

原则一：每个任务只改一件事¶

错误：添加用户登录功能（包含前端表单、后端接口、数据库表、邮件验证）

正确：
任务 1：创建 users 数据库表（迁移文件）
任务 2：实现 POST /auth/login 接口
任务 3：实现前端登录表单组件
任务 4：集成前后端登录流程
任务 5：添加邮件验证逻辑

原则二：每个任务都有独立的验证方式¶

每个任务完成后，必须能独立运行验证，不依赖其他任务的完成。

原则三：按依赖顺序排列¶

识别任务之间的依赖关系，确保前置任务先完成。

graph LR
    A[数据库表] --> B[后端接口]
    B --> C[前端集成]
    A --> D[数据迁移脚本]

拆分方法¶

按技术层拆分¶

适合全栈功能：

数据层（Schema、迁移）
服务层（业务逻辑）
API 层（接口定义）
前端层（UI 组件）
集成层（端到端联调）

按功能边界拆分¶

适合复杂业务逻辑：

核心路径（Happy Path）
错误处理
边界情况
性能优化

按文件范围拆分¶

适合重构任务：

每次只改动 1–3 个文件
改动超过 5 个文件时，重新评估拆分粒度

任务卡模板¶

任务编号：#3
标题：实现 POST /auth/login 接口
前置：任务 #1（users 表已创建）
范围：只修改 src/routes/auth.py
输入：{ email, password }
输出：{ token, user_id } 或 401 错误
验证：pytest tests/test_auth.py::test_login
估计：1 个 AI 对话轮次

常见拆分错误¶

反模式：一次性大任务

"帮我实现完整的用户认证系统" 这类请求会导致 AI 做出大量假设，生成难以验证的大量代码。

反模式：过度拆分

把一个 3 行的函数修改拆成 5 个任务，会增加不必要的协调成本。拆分粒度以"一个 AI 对话轮次能完成"为基准。