AI 编程任务拆分：把大需求切成可验证小步
AI 编程的瓶颈是任务拆分
AI 编程的瓶颈是任务拆分。Anthropic 2026 年 Agentic Coding 趋势报告指出，Coding Agent 交付功能的能力已经显著提升，但任务分解能力仍然是区分「可用」和「不可用」的分水岭。Google Chrome 工程负责人 Addy Osmani 在他的 LLM 编程工作流中也反复强调：先写规格说明，再生成分步计划，然后把计划切成离散阶段。
问题出在任务太大。大任务会同时触发上下文漂移、范围扩张和验证缺口，三者叠加，Agent 改了几十个文件，你连怎么验证都不知道。
大任务为什么会放大不确定性
上下文漂移：Agent 的注意力在衰减
The New Stack 在 2026 年初的一篇文章中直接点明：上下文管理是 AI 编程的瓶颈。LangChain 的 State of Agent Engineering 报告把 模型漂移（model drift） 列为 AI Agent 的核心失败模式——随着任务推进，Agent 对任务和环境状态的理解会逐渐偏离真实情况。
具体到编码场景，上下文漂移有三个典型表现：
- 文件遗忘：Agent 在处理第 15 个文件时，忘记了第 3 个文件中的约束条件。
- 决策矛盾：Agent 在前半段用了方案 A，在后半段不自觉地切回了方案 B。
- 规范丢失：Agent 一开始遵循项目风格，写到后面开始用通用写法。
任务越大，Agent 需要同时追踪的文件、接口和约束越多，上下文漂移就越严重。这是 LLM 注意力机制的固有特征——上下文窗口越大，信号密度越低。
范围扩张：一个需求变成一次重构
当你说「实现分类筛选」，Agent 可能理解为：
- 需要修改 API 层 → 顺手优化接口设计
- 需要修改列表组件 → 顺手改成虚拟滚动
- 需要修改 URL → 顺便加上 deep link 支持
- 需要做搜索 → 顺手抽象一个搜索框架
每一步单独看都合理，叠加起来就是一场失控的重构。敏捷开发中把这个现象叫做 范围蔓延（scope creep）。传统团队用 sprint scope 约束它，AI 编程中你需要用任务切片约束它。
验证缺口：改了很多东西，但不知道对不对
大任务的另一个问题是验证成本指数级增长。改了 5 个文件可以逐个检查，改了 47 个文件只能跑 typecheck 和肉眼扫 PR。typecheck 只能验证类型安全，不能验证业务正确性；肉眼扫 PR 在超过 20 个文件时，人类注意力的覆盖率急剧下降。
没有可验证的交付，就是在制造技术债。
任务拆分的四个维度
以下四个维度来自需求工程和敏捷开发中的用户故事拆分方法论，并针对 AI 编程场景做了适配。
维度 1：按用户可见行为拆分
先拆出最小可体验变化。这是敏捷中 垂直切片（Vertical Slice） 的核心思想——每个切片都应该是一个端到端的、可演示的、有独立价值的功能片段。
判断标准：如果一个改动能让用户在页面上看到一个新行为，它就是一个切片。如果两个改动在用户看来是独立的，就应该分开。
反面模式：按技术层拆——「先做数据层、再做展示层、最后做交互层」。这种拆法的问题是每个中间状态都不可演示，用户看不到任何进展，直到所有层都完成。
正确做法：按用户感知拆——「文章列表支持按分类筛选」和「文章详情展示目录大纲」是两个独立切片，即使用户在同一个页面使用，它们是可独立交付和验收的。
维度 2：按数据边界拆分
当用户行为切片涉及多层架构时，还需要按数据边界做二次拆分。这是经典的分层架构思维：数据读取 → 数据转换 → 组件渲染 → 交互处理。
核心原则：先让数据读取稳定，再接展示层。这样排查问题时能知道失败发生在哪一层。
为什么数据层优先？因为数据层的验证最确定性最高——输入确定，输出确定，测试可以自动化。而 UI 层的验证依赖浏览器环境，不确定性更高。把确定性高的部分先稳定下来，就是降低整体不确定性。
维度 3：按风险等级拆分
权限、存储、支付、Prompt 输出和跨端兼容属于高风险区域。高风险切片应更小，并提前定义失败路径。
判断标准：如果改动出错会影响用户数据、资金或隐私，就是高风险。高风险切片应该单独验收，不能和其他改动混在一起。
这个原则在敏捷中有对应概念——风险驱动的迭代计划。高不确定性、高影响的功能应该尽早交付，以便尽早暴露问题。
维度 4：按验证方式拆分
每个切片都要能被一种证据覆盖：typecheck、测试、构建、浏览器验收、截图或日志。没有验证方式的切片通常还没有拆清楚。
判断标准：如果你无法说出「用什么命令或操作能证明这个切片完成了」，说明它还需要继续拆。
这个维度是前面三个维度的约束条件。它确保每个切片不只是「看起来小」，而是「小到可以被验证」。
四个维度的对照表
| 维度 | 拆什么 | 判断标准 | 典型产物 | 对应敏捷概念 |
|---|---|---|---|---|
| 用户可见行为 | 最小可体验变化 | 用户能在页面上看到一个新行为 | 功能切片 | 垂直切片 / 用户故事 |
| 数据边界 | 数据流经的每一层 | 数据读取稳定后才接下一层 | 分层任务 | 分层交付 |
| 风险等级 | 高风险操作单独隔离 | 出错会影响数据、资金或隐私 | 独立验收切片 | 风险驱动迭代 |
| 验证方式 | 每个切片可被一种证据覆盖 | 能说出用什么命令证明完成 | 验收条件 | Definition of Done |
两个完整案例
案例一：文章分类筛选
假设需求是「给博客首页加上文章分类筛选，支持按标签过滤文章列表」。
错误拆法：「实现文章分类筛选功能」——同时触达列表组件、分类页、API 层、URL 参数处理、移动端响应式，Agent 容易顾此失彼。
正确拆法（四个切片）：
- 切片 1（数据层）：目标
getArticles(tag?: string)按标签过滤；不改页面、不改 URL；范围apps/src/api/articles.ts；约束向后兼容；验收pnpm test覆盖有 tag、无 tag、空 tag - 切片 2（展示层）：目标首页列表调用新接口按标签过滤；不改 URL、不改分类页；范围
page.tsx+ArticleList.tsx；验收 typecheck + 本地浏览器 - 切片 3（URL 同步）：目标筛选状态同步
?tag=xxx，刷新保留；不改 API、不改样式；约束不请求全量数据；验收手动测试 URL 变化 + 刷新保留 - 切片 4（响应式）：目标移动端标签栏可横向滚动，空分类降级 UI；不改 API、不改桌面端；验收浏览器覆盖 1440px / 375px
每个切片按「目标 → 非目标 → 范围 → 约束 → 验收」的结构组织，来自需求工程中结构化需求规格的简化版。如果切片 3 出问题，可以单独回滚；切片 2 验收不通过时，问题一定在展示层——因为切片 1 已经验证通过。
案例二：用户头像上传
假设需求是「支持用户上传和裁剪个人头像」。
错误拆法：「实现头像上传功能」
正确拆法（三个切片，按风险递进）：
- 切片 1（上传接口，高风险优先）：目标
POST /api/avatar接收图片、校验格式大小、存储到对象存储返回 URL；不做前端、不做裁剪；约束仅 JPEG/PNG/WebP，≤5MB，路径含用户 ID；验收集成测试 - 切片 2（前端预览）：目标设置页点击「更换头像」→ 选择文件 → 预览；不裁剪不上传，预览本地文件，圆形裁剪效果；验收 typecheck + 浏览器
- 切片 3（裁剪提交）：目标裁剪区域 → 生成固定尺寸图片 → 上传 → 更新头像；输出 256×256 PNG，失败保留原头像；验收浏览器全流程 + 网络异常降级
这个案例展示了按风险分阶段验证——文件上传涉及安全和存储，风险最高所以最先验证；前端 UI 风险低，放在后面。
任务描述的好坏对比
任务拆分最终要落地为给 Agent 的指令。以下是两种写法的对比：
坏的写法
给博客加上分类筛选功能，支持按标签过滤文章。问题：没有边界、没有范围限定、没有验收标准、没有风险提醒。Agent 可能同时改 20 个文件，你无法控制它的行为。
好的写法
## 任务：文章列表按标签过滤（数据层）
### 目标
`getArticles(tag?: string)` 接口能按标签过滤文章列表。
### 非目标
- 不修改任何页面组件
- 不修改 URL 处理逻辑
- 不修改路由配置
### 范围
- `apps/src/api/articles.ts`：新增可选参数 tag
- `apps/tests/api/articles.test.ts`：新增测试用例
### 约束
- 保持向后兼容：不传 tag 时返回全部文章
- tag 为空字符串时等同于不传
- 不存在的 tag 返回空列表，不报错
- 遵循项目规范：API 逻辑在 `apps/src/api/` 目录，测试在 `apps/tests/` 目录
### 验收
1. `pnpm typecheck` 通过
2. `pnpm test apps/tests/api/articles.test.ts` 通过
3. 测试覆盖三种情况：有效 tag、无 tag、空 tag
### 交付要求
完成后说明：修改了哪些文件、每个文件改了什么、运行了哪些验证命令、验证结果。对比总结
| 要素 | 坏的写法 | 好的写法 |
|---|---|---|
| 目标 | 模糊 | 精确到接口签名 |
| 边界 | 无 | 显式列出非目标 |
| 范围 | 无 | 指定文件和目录 |
| 约束 | 无 | 兼容性、边界条件、项目规范 |
| 验收 | 无 | 具体命令和预期结果 |
| 交付 | 无 | 要求分文件说明和验证证据 |
给 Agent 的任务模板
以下是一个可以直接复用的任务模板：
## 任务：[一句话描述]
### 目标
[用户完成什么动作后能看到什么结果]
### 非目标
- [本次不处理哪些相邻问题 1]
- [本次不处理哪些相邻问题 2]
### 范围
- [预计触达的文件/模块 1]
- [预计触达的文件/模块 2]
### 约束
- [项目规范/兼容要求 1]
- [性能/安全注意事项 1]
### 验收
1. [必须运行的命令 1]
2. [必须运行的命令 2]
3. [人工检查点]
### 交付要求
完成后说明：修改了哪些文件、每个文件改了什么、运行了哪些验证命令、验证结果。把模板写进任务描述或 PR 正文，Agent 就能更稳定地交付。模板把四个维度的思考结构化，给 Agent 清晰的输入。
常见错误清单
拆分任务时，以下是高频犯错场景：
| 错误 | 表现 | 修正方法 |
|---|---|---|
| 拆得太粗 | 一个切片改了 10 个以上文件 | 继续按数据边界或行为拆分 |
| 拆得太细 | 每个切片只改一行代码，切片间强耦合 | 合并为有独立价值的垂直切片 |
| 没有非目标 | Agent 自由发挥，改了不该改的文件 | 显式列出每个切片的非目标 |
| 没有验收 | 「完成了」但没有证据 | 每个切片至少绑定一条验收命令 |
| 忽略风险 | 高风险操作和普通改动混在一个 PR | 高风险切片独立交付、独立验收 |
| 跳过数据层 | 直接从 UI 开始做 | 先稳定数据读取，再接展示层 |
| 无回滚空间 | 多个切片共用文件，无法单独回滚 | 确保切片间文件不重叠，或至少可逻辑隔离 |
| 验收依赖肉眼 | 只能靠人看对不对 | 尽量用 typecheck、测试、构建命令自动化验证 |
交付时看证据
拆分是否有效，最后看交付说明是否清楚。一个健康的交付应该长这样：
## 切片 1 交付：文章列表按标签过滤（数据层）
### 修改文件
- `apps/src/api/articles.ts`：getArticles 新增可选参数 tag，当 tag 有值时按标签过滤
- `apps/tests/api/articles.test.ts`：新增 3 个测试用例
### 验证结果
- `pnpm typecheck` ✅ 通过
- `pnpm test apps/tests/api/articles.test.ts` ✅ 3/3 通过
### 未做的事项
- 未修改任何页面组件
- 未修改 URL 处理逻辑如果 Agent 的交付说明是「完成了分类筛选功能」，没有分切片说明，通常意味着拆分不够细，或者 Agent 跳过了某些步骤。这时应该要求它补充分切片说明和每个切片的验证证据。
检查清单：拆分完问自己五个问题
- 每个切片能否独立验收？ 如果不能，说明切片之间有依赖，需要调整拆分顺序或继续拆分。
- 每个切片是否有明确的非目标？ 如果没有，Agent 可能会自由发挥。
- 每个切片是否有自动化验收命令？ 如果只能靠人看，验证成本太高。
- 高风险切片是否独立交付？ 如果高风险改动和普通改动混在一起，回滚会很痛苦。
- 切片间的文件是否尽量不重叠？ 如果多个切片改同一个文件，冲突和回滚的风险会上升。
总结
AI 编程的瓶颈在于任务拆分。大任务会放大上下文漂移、范围扩张和验证缺口，最终导致返工和技术债。
我用四个维度的拆分框架来应对——用户可见行为、数据边界、风险等级、验证方式——来自需求工程和敏捷开发的实践，针对 AI 编程场景做了适配。核心原则：每个切片都要有明确的输入、清晰的边界、可执行的验收和独立的回滚空间。
下次和 Agent 协作时试试这套方法，问题多半出在任务太大。
参考资料
- Anthropic 2026 Agentic Coding Trends Report
- Addy Osmani - My LLM Coding Workflow Going into 2026
- Context is AI Coding's Real Bottleneck in 2026 - The New Stack
- A Deep Dive into AI Coding Agents' Task Decomposition Architecture
- Separation of Planning and Execution: The Key Pattern for Reliable AI Coding Agents
- LangChain State of Agent Engineering
- AI-Assisted Greenfield Software Development, Part 6: Vertical Slices