需求拆解四步法
脑子里有想法,但说不清楚——这是大多数人用 AI 编程效率低的第一原因。四步法帮你把模糊想法变成 AI 能执行的精确需求。
为什么 AI 给的总不是你想要的
最常见的情况是这样的:你脑子里有个想法,比如"做个待办清单"。你跟 AI 说"帮我做个待办清单"。AI 给了你一个——但不是你想要的那种。你说"不对",AI 改了一版——还是不对。来回三五次,你烦了,AI 也"晕"了。
问题不在 AI 的能力,在你的需求没有拆解。"做个待办清单"是一个模糊想法,不是一个可执行的需求。AI 不知道你要什么样的待办清单,它只能猜——猜对了是运气,猜错了是常态。
AI 不是读心术。你说的越模糊,AI 的发挥空间越大(等于越容易跑偏)。你说的越具体,AI 的选择范围越小(等于越容易命中)。需求拆解的本质,就是把 AI 的「猜」变成「执行」。
四步法:从模糊到精确
第一步:模糊想法 → 功能清单
把"做个待办清单"拆成具体功能。问自己:这个东西要能做什么?
- 添加任务
- 标记完成
- 删除任务
- 按优先级排序
- 显示日期
这一步的关键是把"做什么"变成"有哪些功能"。每个功能是一个具体的、可描述的行为。
第二步:功能清单 → 优先级
不是所有功能都要一次性做完。把功能分三档:
- 必须有:没有它就不算待办清单(添加、完成、删除)
- 最好有:有了更好,没有也能用(优先级、日期)
- 以后再说:先不做(分类、标签、提醒)
先让 AI 做"必须有"的部分。这比一次塞一堆需求效果好得多——AI 的注意力有限,需求越聚焦,产出越精准。
第三步:优先级 → 验收标准
每个"必须有"的功能,你要能回答:"什么样算做好了?"这就是验收标准。
比如"添加任务":
- 有一个输入框,输入文字后按回车能添加
- 添加后任务显示在列表里
- 输入框清空,可以继续添加下一个
验收标准不需要写代码,只需要描述用户看到什么、能做什么。这正是 AI 能理解的语言。
第四步:组合成需求描述
把前三步的结果组合起来,就是一份 AI 能执行的需求:
做一个待办清单网页。功能:
1. 输入框 + 回车添加任务
2. 每个任务有完成按钮,点击后划线
3. 每个任务有删除按钮
先做这三个功能,不要排序和日期。
对比一下"帮我做个待办清单"——哪一个能让 AI 一次命中,一目了然。
以后每次跟 AI 提需求前,过一遍: ① 拆功能清单(这东西要能做什么)→ ② 定优先级(哪些必须有)→ ③ 写验收标准(什么样算做好了)→ ④ 组合描述(把前三步串成一段话给 AI)。 多花 3 分钟做拆解,少花 30 分钟改 AI 的错。
完整走一遍:从模糊想法到可执行需求
换个新场景,从头走一遍四步法,感受它到底有多实用。假设你想做一个AA 记账工具——朋友聚餐后自动算每个人该付多少。
起点:一个模糊想法
「我想做个小工具,帮我记账。」——如果直接把这句话丢给 AI,它可能给你做一个带银行同步、预算分析、报表导出的重型财务系统。而你可能只是想算个简单的 AA 饭钱。
这就是为什么需要拆解。
第一步:拆功能清单
坐下来想 2 分钟,这个东西到底要能做什么:
AA 记账工具 - 功能初步拆解:
1. 添加记录(金额、人数、日期)
2. 自动计算每人应付(总金额 / 人数)
3. 查看历史记录
4. 删除某条记录
第二步:定优先级
- 必须有:添加记录、自动算 AA、历史列表、删除
- 最好有:按日期筛选记录
- 以后再说:图表统计、多群组、导出 Excel
先让 AI 做「必须���」的四个功能。一口气塞太多,AI 容易出错。
第三步:写验收标准
以「添加记录」为例,什么叫「做好了」?
- 有一个表单:金额输入框 + 人数输入框 + 日期选择器
- 填写后点击「添加」,记录出现在下方列表
- 列表中每条记录自动显示「每人应付」金额
- 金额支持小数(38.5 元),人数必须是整数
第四步:组合成需求描述
把前三步串起来,就是一份 AI 能直接执行的需求:
做一个 AA 记账网页。功能:
1. 表单添加记录:输入金额、人数、日期,点击添加
2. 历史列表,每条自动计算「每人应付 = 金额 / 人数」
3. 可删除某条记录
4. 数据存在浏览器本地就行
约束:纯 HTML/CSS/JS,深色背景,手机上方便看。
先做这四项基础功能,不要图表和导出。
从「帮我做记账工具」到这 9 行需求,花了不到 5 分钟。但 AI 给你的第一版,大概率已经能用了。
这个 walkthrough 的每一步,都可以直接套到你的项目上。把「AA 记账」换成你的需求,照着这四个步骤走一遍,你就能产出第一版可执行需求。养成习惯——每次都这么拆,而不是扔一句话给 AI 然后慢慢改。
先说"要什么"再说"怎么做"
四步法的核心原则是:先描述你要什么结果,再描述你想怎么做。
很多人习惯一上来就指挥 AI 怎么写代码——"用 React,用 Tailwind,先写一个组件……"。这是在替 AI 做它擅长的事。你只需要告诉它你要什么,怎么实现让它决定。如果它选的方案你不满意,再在反馈阶段调整。
例外:如果你有明确的技术约束(必须用某个框架、必须兼容某个环境),那要在需求里说清楚。但这是"约束",不是"指令"。
一个常见陷阱:需求太细
和需求太模糊相反的极端,是需求太细——把每个 CSS 属性、每个函数名都指定好了。这不叫"提需求",叫"口述代码"。
太细的问题在于:你在替 AI 做它擅长的事(写代码),而忽略了它不擅长的事(理解你的意图)。结果是你累死、AI 还不一定按你想的来。
正确的粒度是:描述行为和结果,不描述实现细节。"点击后划线"是好需求,"给 text-decoration 加 line-through"是太细了。
需求太模糊 → AI 瞎猜,命中率低。
需求太细(口述代码) → 你累死,AI 还不一定听。
正确的中间点:描述用户看到什么、能做什么,不描述代码怎么写。
本章小结
- AI 没给对,不是它不行——是你的需求没拆。
- 四步法:模糊想法 → 功能清单 → 优先级 → 验收标准 → 组合成需求描述。
- 先描述要什么结果,再说怎么做。让 AI 决定实现方式。
- 恰到好处的粒度:描述行为和结果,不描述代码怎么写。