夜雨聆风
你有没有遇到过这种情况：
需求会写，想法也很清楚，甚至脑子里已经有了产品大概长什么样。
但一到开发排期，就卡住了。
到底先做哪一步？
比如，你想给一个工具站增加“收藏夹”功能。
听起来是不是很简单？
用户看到喜欢的工具，点一下收藏；下次打开收藏夹，就能快速找到。
一句话就能说清楚。
但真正开始拆的时候，问题马上来了：
用户从哪里点击收藏？ 收藏之后展示在哪里？ 未登录用户能不能收藏？ 前端要做哪些页面状态？ 后端要不要新增数据表？ 接口失败时怎么提示？ 重复点击收藏按钮怎么办？ MVP 版本到底做到什么程度就可以上线？
你会发现，一个看似简单的功能，一旦进入开发层面，就会突然长出很多细节。
这也是很多独立开发者、小团队、产品经理经常遇到的问题：
不是没有需求，而是需求没有被拆成能执行的任务。
最近我在看一个开源项目：alirezarezvani/claude-skills。
它整理了很多可复用的 Skills 思路，很适合把产品、研发、运营中的重复流程，变成一套固定的指令模板。
它不是让 AI 替你拍板，也不是让 AI 直接决定产品怎么做。
更准确地说，它像一个“流程助理”：
帮你按模板拆需求、列风险、生成任务清单，让你在真正动手开发之前，先把思路理顺。
今天这篇文章，就用一个具体案例来聊聊：
怎么用 AI，把一句功能想法，拆成可以执行的开发 Todo。
一、为什么需求写完之后，开发还是会卡住？
很多时候，需求文档看起来已经写完了。
但开发依然不知道从哪里开始。
问题通常不是大家能力不够，而是需求还停留在“描述层”，没有进入“任务层”。
比如一个需求描述可能是这样的：
希望给工具站增加收藏夹功能，用户可以收藏自己常用的工具，方便下次快速访问。
这句话有问题吗？
没有。
它清楚表达了目标。
但它还不能直接进入开发。
因为开发真正需要知道的是：
页面入口在哪里； 用户点击后发生什么； 数据如何存储； 接口如何设计； 有哪些异常状态； 测试时需要验证哪些场景； 哪些功能必须做，哪些功能可以后做。
如果这些内容没有提前拆清楚，排期时就很容易出现三种情况。
第一种：看起来是小功能，做起来发现牵一发动全身
一开始以为只是加个按钮。
结果发现要改用户系统、数据库、接口、个人中心页面，还要补一堆状态。
最后一个“小需求”，变成了一个“隐形大项目”。
第二种：开发做到一半，才发现边界条件没想清楚
比如：
未登录用户点收藏怎么办？
工具下架之后，收藏夹还展示吗？
重复点击收藏按钮，状态会不会错乱？
这些问题如果开发中途才发现，就很容易打断节奏。
第三种：上线前临时补状态、补提示、补测试
功能主流程做完了，但上线前才发现：
没有空状态。
没有失败提示。
没有登录引导。
没有测试边界条件。
于是临时补、临时改、临时测，整个节奏被打乱。
所以，需求拆解的核心不是“把事情写得更多”，而是：
把模糊想法变成明确动作。
二、AI 在需求拆解里能帮什么？
AI 最适合做的，不是替你决定产品方向。
而是帮你把重复性的思考框架标准化。
比如，每次拆需求时，你都可以让 AI 按固定结构输出：
用户故事； 边界条件； 页面与交互； 接口与数据结构； 前端任务； 后端任务； 异常状态； 测试点； MVP 优先级。
这就是类似 claude-skills 这类项目的价值。
它不是给你一个“万能答案”，而是提供一组可以反复复用的工作流模板。
你每次只需要替换具体业务背景、功能目标和用户场景。
AI 就能帮你快速生成一版结构化初稿。
当然，这里一定要注意：
AI 不一定比你更懂业务。
但它可以比你更稳定地执行流程。
AI 不一定比你更懂业务，但它可以比你更稳定地执行流程。
这句话很关键。
因为在真实工作里，很多问题不是不会想，而是每次都想不全。
今天漏了异常状态。
明天忘了测试点。
后天又没拆清楚 MVP 范围。
AI 的价值，就是帮你把这些“应该想但容易漏”的部分，先完整铺出来。
三、小教程：把一个功能需求拆成开发任务
下面我们用一个具体例子来演示：
给工具站增加“收藏夹”功能。
这个需求非常适合练习。
因为它看起来简单，但实际会涉及：
用户行为； 页面状态； 数据存储； 接口设计； 权限判断； 异常处理； 测试验收。
接下来，我们用 4 步把它拆成可执行任务。
第 1 步：先准备一段真实需求
不要一上来就对 AI 说：
“帮我拆一下收藏夹功能。”
这个指令太模糊了。
AI 当然能回答，但输出大概率会泛泛而谈。
比如它可能会说：
“需要前端页面、后端接口、数据库设计、测试验证。”
听起来没错。
但你还是不知道具体下一步做什么。
更好的方式，是先准备一段相对完整的真实需求。
比如：
我有一个工具导航站，用户可以浏览不同分类下的 AI 工具。现在希望增加“收藏夹”功能。登录用户可以在工具卡片上点击收藏按钮，收藏后可以在个人中心的收藏夹页面查看已收藏工具，并支持取消收藏。目标是让用户下次能更快找到常用工具。
这段需求里，至少包含了几个关键信息：
- 用户：
登录用户； - 入口：
工具卡片上的收藏按钮； - 核心动作：
收藏、查看收藏、取消收藏； - 结果：
用户可以快速访问常用工具； - 页面：
个人中心的收藏夹页面。
你给 AI 的上下文越具体，它拆出来的任务就越接近真实开发。
所以第一步的关键是：
不要只给功能名，要给业务背景、用户场景和目标结果。
第 2 步：选择偏 Product / Engineering 的拆解思路
接下来，不要只让 AI “帮我拆任务”。
你应该给它一个固定结构，让它同时从产品和工程视角输出。
可以使用类似这样的提示词：
请你作为产品经理和工程负责人，帮我把下面的功能需求拆成开发任务。
请按以下结构输出：
1. 用户故事
2. 功能范围
3. 边界条件
4. 页面与交互
5. 接口与数据结构
6. 前端任务
7. 后端任务
8. 异常状态
9. 测试点
10. MVP 必做项与可延后项
需求如下：
【粘贴你的真实需求】
这一步的关键是：
不要让 AI 自由发挥，而是让它进入你的工作流程。
因为好的需求拆解，不只是列 Todo。
它要把两件事连接起来：
一边是：
用户怎么用。
另一边是：
系统怎么实现。
如果只从产品角度看，很容易停留在用户体验描述。
如果只从工程角度看，又可能忽略用户场景和业务目标。
所以比较好的方式，是让 AI 同时扮演两个角色：
产品经理 + 工程负责人。
这样它输出的内容，会更接近真实协作场景。
第 3 步：让 AI 生成任务表
当 AI 按结构拆完之后，建议继续让它整理成任务表。
为什么？
因为任务表更适合进入排期、协作和执行。
一段文字说明，适合讨论。
但真正排期时，大家需要的是清晰的任务颗粒度。
一个比较实用的任务表，可以包含这些字段：
任务模块； 任务名称； 任务说明； 负责人； 优先级； 是否 MVP 必做； 依赖项； 验收标准。
对于“收藏夹”功能，AI 可能会拆出这样的任务方向。
1. 前端任务
在工具卡片上增加收藏按钮； 处理已收藏和未收藏状态； 增加收藏成功和取消收藏提示； 新增个人中心收藏夹页面； 处理空状态，例如“你还没有收藏任何工具”； 处理加载状态和接口失败状态； 未登录用户点击收藏时，引导登录。
这些任务看起来很细，但这正是开发需要的。
因为“做一个收藏功能”太大。
但“在工具卡片上增加收藏按钮”就可以开始估时间。
2. 后端任务
新增收藏关系数据表； 提供新增收藏接口； 提供取消收藏接口； 提供收藏列表接口； 校验用户登录状态； 防止重复收藏； 处理工具不存在或下架的情况。
后端任务的重点，是数据关系和接口稳定性。
尤其是收藏这种功能，最容易出现状态不一致的问题。
比如前端显示已收藏，但后端其实失败了。
或者用户连续点击两次，导致重复记录。
这些都需要提前考虑。
3. 数据结构
可以初步包含：
用户 ID； 工具 ID； 收藏时间； 收藏状态； 必要时记录来源页面。
如果只是 MVP，数据结构可以很简单。
但至少要保证能支持三个核心动作：
收藏、取消收藏、查看收藏列表。
4. 异常状态
这部分非常容易被忽略，但很重要。
常见异常包括：
用户未登录时点击收藏； 工具不存在或已下架； 重复点击收藏按钮； 接口请求失败； 收藏列表为空； 网络慢导致状态不同步； 用户取消收藏后页面状态没有及时刷新。
如果这些异常状态不提前列出来，开发后期就会变成“补窟窿”。
主流程能跑，不代表功能完整。
真正影响体验的，往往就是这些边界状态。
5. 测试点
测试点可以包括：
登录用户是否可以正常收藏； 是否可以取消收藏； 刷新页面后收藏状态是否保持； 收藏夹页面是否正确展示数据； 未登录用户是否出现正确引导； 重复收藏是否被拦截； 接口失败时页面是否有提示； 工具下架后收藏列表是否按预期处理。
你会发现，当需求被拆到这个程度时，开发排期就不再是“凭感觉估时间”。
而是可以逐项评估：
这个任务要多久？
有没有依赖？
是不是 MVP 必做？
验收标准是什么？
这就是任务拆解的价值。
第 4 步：人工改一遍优先级
AI 拆出来的任务，不能直接当最终方案。
最后一定要人工过一遍优先级。
因为 AI 很容易把功能拆得比较完整。
但完整，不等于适合当前阶段。
尤其是独立开发者和小团队，最怕的不是功能不够多，而是一开始做太多。
这里建议把任务分成三类：
- MVP 必做：
没有它功能就不能上线； - 可延后优化：
做了更好，但不影响第一版上线； - 待确认问题：
现在还没想清楚，需要进一步讨论。
以收藏夹功能为例。
MVP 必做可能包括：
登录用户可以收藏工具； 登录用户可以取消收藏； 有一个收藏列表页面； 刷新后收藏状态不丢失； 未登录用户点击收藏时有提示。
这些是基础闭环。
只要缺一项，功能体验就不完整。
可以延后的功能可能包括：
收藏夹分组； 收藏备注； 收藏排序； 收藏工具批量管理； 收藏夹分享功能； 多端同步优化。
这些功能不是不好。
但它们不一定适合第一版就做。
很多产品之所以迟迟上线不了，不是因为核心功能太难，而是被一堆“顺手也做一下”的功能拖住了。
待确认的问题可能包括：
未登录用户是否允许本地临时收藏？ 工具下架后，收藏夹里是否继续展示？ 收藏数量是否需要上限？ 是否需要同步到多端？ 收藏数据是否需要导出？ 是否要在工具列表页展示收藏数量？
这些问题，不确定就不要硬编答案。
最好的方式是单独列出来，等评审或决策时讨论。
这一步非常重要。
因为 AI 能帮你把功能拆完整，但它不知道你现在最该做什么。
它不知道你的开发时间有多少。
不知道你的用户规模。
不知道你是要快速验证，还是要做完整体验。
所以最终优先级，一定要由人来判断。
会做减法，才是真正的产品判断。
四、这个方法适合迁移到哪些场景？
虽然上面的例子是开发一个“收藏夹”功能。
但这套拆解方式，其实可以迁移到很多场景。
因为它解决的不是某一个具体功能的问题，而是一个更通用的问题：
怎么把模糊需求拆成明确动作。
1. 独立开发者：把新功能拆成可执行 Todo
独立开发者最容易遇到的问题是：
想法很多，但时间有限。
今天想做收藏夹。
明天想做登录系统。
后天又想加会员、积分、分享、数据看板。
但真正能推进产品的，不是想法数量，而是执行顺序。
用 AI 先拆一版任务，再人工筛选 MVP，可以避免一开始就陷入“大而全”的开发。
尤其适合：
工具站； SaaS； 小程序； 浏览器插件； AI 应用； 内容平台； 个人产品。
你可以先让 AI 帮你把任务铺出来，再判断：
哪些现在必须做？
哪些可以后做？
哪些其实根本不用做？
2. 产品经理：把口头需求整理成评审稿
很多需求一开始都来自一句话：
“能不能加一个收藏？”
“能不能做一个导出？”
“能不能支持批量操作？”
“能不能加一个数据看板？”
这些口头需求如果直接进入评审，很容易讨论发散。
大家聊着聊着，就从“收藏”聊到了“推荐系统”。
从“导出”聊到了“权限体系”。
从“批量操作”聊到了“自动化工作流”。
最后会议开了很久，但下一步还是不清楚。
这时候，可以先用 AI 把口头需求整理成：
用户故事； 功能范围； 页面交互； 边界条件； 验收标准； 待确认问题。
再拿去评审，效率会高很多。
因为讨论不再是空泛地聊“要不要做”，而是围绕具体问题做判断。
3. 运营和设计：把活动需求拆成物料和排期
运营和设计也可以用类似方法。
比如一个活动需求，可以拆成：
活动目标； 用户路径； 页面物料； 海报文案； 上线时间； 渠道分发； 数据回收； 风险预案； 复盘指标。
这和开发需求拆解，本质上是同一件事。
都是把一个模糊目标，拆成可以执行、可以协作、可以验收的动作。
比如：
“做一个双十一活动页。”
这句话太大了。
但如果拆成：
活动主视觉； 活动规则； 商品模块； 优惠券领取； 分享海报； 上线排期； 数据埋点； 异常预案。
它就变成了可以推进的任务。
五、避坑建议：不要把 AI 输出当最终方案
AI 很适合帮你补充视角。
但它并不知道你的真实资源、团队节奏和业务优先级。
所以在使用这类流程时，建议注意 3 点。
第一，不要直接照搬
AI 输出的是初稿，不是最终 PRD。
它可以帮你列出很多可能性，但你要判断哪些真的适合当前项目。
尤其是一些看起来很完整的功能建议，不一定都该做。
很多时候，AI 给你的不是答案，而是选项。
第二，要结合当前阶段
早期产品最重要的是验证。
不是一次做完。
如果你还在验证用户是否需要收藏功能，那就没必要第一版就做：
收藏夹分组； 收藏备注； 批量管理； 分享收藏夹； 智能推荐收藏。
先把最小闭环做出来。
看看用户会不会用。
再决定要不要继续加功能。
第三，保留待确认项
不确定的问题，不要让 AI 硬编答案。
比如：
“未登录用户能不能收藏？”
这个问题不是技术问题，而是产品策略问题。
如果 AI 随便给一个答案，反而可能误导你。
正确做法是：
把它列为待确认项。
等你结合业务目标、用户体验和开发成本再做判断。
最好的方式，是把这个流程沉淀成自己的：
需求拆解模板。
每次只替换业务背景、用户场景和功能目标。
这样用得越多，输出越稳定，也越来越像团队资产。
六、推荐模板：AI 需求拆解提示词
如果你想直接复用，可以从下面这个模板开始：
请你作为一名产品经理和工程负责人，帮我拆解下面这个功能需求。
请按以下结构输出：
一、需求理解
- 目标用户
- 使用场景
- 用户核心动作
- 预期结果
二、用户故事
- As a ...
- I want to ...
- So that ...
三、功能范围
- MVP 必做
- 可延后功能
- 不做的范围
四、页面与交互
- 入口
- 页面状态
- 操作反馈
- 空状态
- 异常状态
五、接口与数据
- 需要的接口
- 主要字段
- 数据关系
- 权限校验
六、开发任务表
请用表格输出：
- 模块
- 任务名称
- 任务说明
- 优先级
- 是否 MVP
- 依赖项
- 验收标准
七、测试点
- 正常流程
- 异常流程
- 边界条件
八、待确认问题
请列出需要产品或业务进一步确认的问题。
需求内容：
【在这里粘贴你的需求】
这个模板不一定完美，但它能帮你避免一个常见问题：
需求讨论了半天，最后还是没人知道下一步做什么。
如果你是独立开发者，可以用它给自己拆 Todo。
如果你是产品经理，可以用它整理评审稿。
如果你是小团队负责人，可以用它统一大家的需求拆解标准。
它真正的价值，不在于一次输出多完美。
而在于让每次需求讨论，都有一个稳定的起点。
七、工具推荐：alirezarezvani/claude-skills
本文提到的项目是 GitHub 上的开源项目：
alirezarezvani/claude-skills
它整理了很多 Claude Skills 的使用思路，可以帮助你把一些重复性工作，沉淀成可复用的 AI 工作流。
项目地址可以在 GitHub 搜索：
alirezarezvani/claude-skills
当然，工具不是最重要的。
你也可以用 Claude、ChatGPT，或者其他 AI 工具来实现类似流程。
关键不在于你用哪个工具，而在于你有没有建立这套机制：
需求输入 → 结构化拆解 → 任务表输出 → 人工判断优先级 → 进入执行。
八、总结：需求拆解的本质，是把不确定变成可执行
对独立开发者和小团队来说，最宝贵的不是“功能想法”。
而是把想法快速变成可验证版本的能力。
AI 可以帮你把需求拆得更完整。
帮你列出遗漏的边界条件。
帮你把任务表整理得更清楚。
但它不能代替你判断：
什么该做。
什么不该做。
什么应该先做。
所以，正确的使用方式不是：
“AI，帮我决定怎么做。”
而是：
“AI，按我的流程，帮我把问题拆清楚。”
需求写清楚，只是开始。
任务拆明白，才是真正能推进。
如果你正在做新功能、活动页面、工具站或者小产品，不妨试试把需求先交给 AI 拆一版。
你可能会发现，卡住你的不是开发能力。
而是任务还没被拆到能动手的程度。
最后送你一句话：
需求写清楚，只是开始；任务拆明白，才是真正能推进。
如果让 AI 帮你拆需求，你最想让它先帮你解决哪一步？
是写用户故事、拆开发任务，还是列风险和测试点？