最近在折腾 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 协作开发的人都试试。
最近在折腾 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 协作开发的人都试试。
