Appearance
任务拆解技能解决的是“大任务直接丢给 AI，结果 diff 失控”的问题。它要求把需求拆成小而可验证的步骤，每一步都有验收标准、依赖关系和验证方法，适合多文件功能、重构和复杂 bug 修复。
AI 一次改太多文件怎么办：任务拆解技能怎么用
下载 planning-and-task-breakdown 中文版 Skill ZIP
一个“帮我优化设置页”的任务，AI 可能改组件、改样式、改接口、改状态管理，还顺手把命名规范统一了一遍。
看上去很勤快。
review 的人会很痛苦。
planning-and-task-breakdown 这个技能要解决的就是这个问题：不要把一整个大需求丢给 AI。先拆成小任务，每个任务都能单独验证。
AI 为什么喜欢一次改很多
AI Agent 不知道你的忍耐阈值。
你说“优化”，它会理解成可以动一切看起来不顺眼的地方。你说“重构”，它会理解成可以重新设计结构。你说“修一下登录问题”，它可能会把登录页、认证状态、请求封装都扫一遍。
这不是恶意，是任务边界太宽。
任务越大，AI 越容易出现三种问题：
- 改动范围失控，review 不知道从哪里看。
- 中途引入新 bug，很难定位是哪一步造成的。
- 做到一半上下文变乱，后面开始补救前面的补救。
任务拆解不是为了仪式感，而是为了让失败变小。
好任务要小到什么程度
一个适合 AI 的任务，最好能用一句话说清楚，并且有明确验证方式。
比如：
- 给用户列表增加邮箱搜索输入框。
- 让查询接口支持 email 参数。
- 给 email 过滤逻辑补一个单元测试。
- 在空结果时显示“没有找到用户”。
这些都是可以单独完成、单独检查的任务。
不太适合直接交给 AI 的任务是：
- 重做用户管理模块。
- 优化后台体验。
- 把认证系统整理一下。
- 让这个页面更专业。
这些不是不能做，而是需要继续拆。
一个简单的拆解方法
你可以按“用户路径”拆，而不是按技术层拆。
假设要做一个 API Key 管理功能，不要一上来拆成数据库、接口、组件、样式。更稳的拆法是：
- 页面能展示当前 API Key 状态。
- 用户能输入新的 API Key。
- 点击保存后能调用已有保存接口。
- 保存成功后页面状态更新。
- 保存失败时显示错误。
- 给关键逻辑补测试或手动验证路径。
每一步都接近一个用户能理解的结果。这样 AI 不容易沉迷内部结构。
每个任务都要有验收标准
任务描述只写“实现保存逻辑”还不够。
更好的写法是：
md
任务：实现 API Key 保存按钮
范围：只改设置页组件和已有保存函数调用，不新增后端接口。
验收标准：
- 输入框为空时按钮不可点击。
- 输入非空内容后点击保存，会调用已有保存函数。
- 保存成功后显示成功提示。
- 保存失败后显示错误提示。
验证方法：
- 本地打开设置页手动操作一次。
- 如果已有组件测试，补一条保存成功和失败测试。AI 看到这类任务，产出的 diff 通常会更收敛。
大任务不要硬拆成平均小块
拆任务不是切蛋糕。
有些任务天然依赖前一步，必须按顺序做；有些任务可以并行；有些任务看似小，但风险很高。
比如数据库迁移就不能只按“文件少”判断。它可能只改一个 migration 文件，但影响生产数据。相反，文案替换可能改十几个 Markdown 文件，但风险低得多。
更好的判断方式是：
- 这一步失败了，能不能容易回滚？
- 这一步能不能单独验证？
- 这一步会不会改变公共接口？
- 这一步是否依赖另一个任务完成？
如果答案不清楚，就继续拆，或者先写 spec。
任务拆解和古法编程的关系
古法编程不是拒绝 AI，而是拒绝把判断交给 AI。
任务拆解对应 P1 和 P2 之间的桥：人先把路线切出来，再让 AI 一段一段走。每一段都要能看见结果，能验证，能回退。
AI 很适合执行明确任务，不适合替你决定整个工程节奏。
你可能还需要
同类技能：
如果一个任务拆完后还是很大，先别急着让 AI 写代码。把它继续拆到每一步都有验收标准。