最近在折腾 mattpocock 的 skills 工作流，连续跑了几个真实需求，发现一个特别值得说的点：需求拆解这件事，才是决定 AI 干活质量的分水岭。
以前我的习惯是拿到需求直接往对话框里丢，让 AI 自己发挥，结果经常是一顿操作猛如虎，输出方向全凭运气。后来把 mattpocock 这套 skills 升级思路套进来，把“需求”改成“任务清单”再交给 AI 执行，跑出来的结果基本没怎么返工过。这篇文章就结合我这几天的实测，聊聊为什么拆任务比写提示词更重要，以及具体怎么拆。
1. 为什么 AI 会跑偏：需求模糊是根源
先说一个最容易被忽略的事实：现在的 AI 再聪明，本质上也只是在做预测与补全。你给它一句“帮我写个登录页面”，它就按常见登录页的统计分布去生成代码，至于你有没有特别要求，它根本不知道。
模型判断你没有给更多信息，默认就补全程。于是你会看到 Kotlin 风格的登录页、按钮配色随机、没有国际化、没有错误处理——其实不一定错，但大概率不是你要的。
mattpocock 在他的 skills 体系里很强调一点：AI 的能力上限取决于你把上下文结构化的程度。他让我印象最深的一个结论是：与其花时间调 prompt 措辞，不如把需求拆成“任务 + 验收条件 + 边界约束”三段式，让模型在每段里只做一个判断。
这一点的实际效果，我用一个很生活化的类比来解释：你让一个新人开发去写页面，如果你只说“把登录做了”，他只能自由发挥；但如果你告诉他“先做表单校验，再做接口对接，最后处理错误提示，每步完成后给我看结果”，他跑偏的概率就低很多。AI 也一样，只是它比新人更需要这种明确的任务分解。
所以跑偏的根源不是模型笨，而是我们没有把需求翻译成它擅长处理的语言。
2. 我用的需求拆解框架：把一句话变成任务树
在实测 mattpocock skills 的过程中，我把一个完整的 AI 辅助开发流程总结为三步：需求解析、任务拆分、执行验证。其中任务拆分是最核心的一步。
具体来说，我会把任何一句笼统的需求先改写成这种格式：
- 明确输入与输出
- 明确步骤顺序
- 明确每一步的验收标准
- 明确不做什么（边界约束）
举一个真实例子。我想让 AI 写一个带登录验证的前端项目，原话是“帮我写个登录系统”。这个需求如果直接丢给 AI，结果大概率是：
- 生成一个纯前端的假登录
- 没有路由守卫
- 没有 token 存储
- 没有接口异常处理
拆完以后变这样：
- 任务1：设计登录表单，包含邮箱与密码两个输入框，必填校验，前端错误提示
- 任务2：实现登录接口调用，基于返回的 JWT 存储到本地，并跳转到首页
- 任务3：实现路由守卫，未登录访问首页时自动跳回登录页
- 任务4：实现 token 过期后的自动登出逻辑
每个任务都带验收条件。AI 执行起来，就等于在做一个只有四步的小项目，而不是一个一提出来就让人懵的“登录系统”。这个过程我管它叫“任务树拆解”，结构上很像软件工程里的 WBS（工作分解结构），只不过对象换成了 AI。
3. mattpocock 的 skills 升级实测流程
这部分说一下具体的实测过程。我用的环境是支持 skills 机制的 AI 编程客户端，配合 Claude 系模型跑的前端任务。mattpocock 的 skills 本质上是把一些特定工作流封装成可复用的“技能包”，你调用某个 skill，它就会自动注入对应的任务指令上下文。
我的实操流程分成五步：
- 在客户端里新建一个项目目录
- 挂上 mattpocock 的前端开发相关 skill
- 把拆好的任务清单写进项目说明文件
- 让 AI 按清单一步步执行，每步都要求先解释思路再写代码
- 每完成一个任务，我手动检查一次，再放行下一个
有一个比较关键的配置细节：在任务清单里，我给每一项都加上了“独立可运行”的要求。也就是说，每个任务执行完以后，项目本身必须仍然处于可用状态，不能因为某一步的中间代码破坏了整体结构。
这个要求非常重要，实测下来直接省掉了很多联调时间。AI 如果只负责写一段孤立代码，它很可能会忽略接口路径、变量命名、样式引入这些全局事项。加上这个约束以后，它在写第二步的时候会主动考虑第一步留下的数据结构。
最终测试效果：原本大约要来回拉扯 7-8 轮对话才能写好的功能，在任务树模式下 3-4 轮全部搞定，且基本不需要返工。
4. 任务拆分的三个坑：我也踩过
第一个坑是拆得太细。我一开始恨不得把每个函数都单独拆成任务，结果 AI 每走一步都要停下来等我确认，整个流程变得非常拖沓。后来我意识到，拆任务应该以“可验收的交付物”为单位，而不是以“可执行的函数”为单位。细到能单独验收就够了，不必细到每一行。
第二个坑是任务的依赖顺序没写清楚。比如先写页面还是先接接口，这事如果不交代，AI 可能会先写一个没有数据联动的静态页面，然后你在验收时发现它没法运行，只能打回重写。我把依赖关系写进每个任务里，明确“本任务基于任务2的接口结构”，AI 的执行顺序就顺了。
第三个坑是没有负面约束。AI 特别擅长做加法，不擅长做减法。如果你忘了说“不需要记住密码功能”“不做第三方登录”，它会顺手加一堆你没要求的特性，导致项目变得臃肿。现在我在每个任务后面都加一句“不得包含”列表，实测效果立竿见影。
这三个坑的解释逻辑也简单：AI 的上下文窗口是有限的，它没办法像人一样记住所有闲聊里的信息。你给它太多零散指令，它会模糊处理；你给它太多的可选内容，它会自作主张。所以我后来的原则是，宁可少写，也要做到每条指令都是必须遵守的硬性约束。
5. 什么时候不要用任务拆分
任务拆解当然不是银弹。我在实测中发现，有些需求类型其实不适合拆得很细。
比如早期的头脑风暴、风格探索、技术选型评估这类探索性任务，拆得越细反而越限制可能性。你让 AI 在一个明确约束的框架里做创意，结果往往很平庸。这种时候我更倾向于只给一个大的方向，然后逐轮追问，让 AI 在对话中逐步收敛。
还有一种情况是小型一次性脚本，比如临时写一个数据处理脚本，运行完就丢。这种任务拆成任务树纯属浪费时间，直接描述清楚目标和输入输出格式，一把梭效率最高。
所以要学会判断：**任务是流程性的，还是探索性的。**流程性的任务适合用 skills 和任务树去拆解执行；探索性的任务适合保持对话的开放性，靠追问来逐渐逼近目标。
mattpocock 的这套 skills 体系给我的最大启发，不是说 AI 变得更强了，而是我们和 AI 协作的方式变得更工程化了。它把“写提示词”这种玄学，变成了“拆任务”这种可以复制的方法论。
我在实际使用中最大的体会是：当我不再幻想 AI 能读心以后，它的执行力反而超乎预期。每一次翻车，几乎都能回溯到某个需求表述不够结构化的地方。把任务拆清，把验收条件写死，把领域边界画好，剩下的执行工作，AI 是真的做得又快又稳。这套方法现在已经成为我的默认工作流，也建议每个跟 AI 协作开发的人都试试。