别再跟 AI 说「帮我做个 XX」：22 个方法论让需求从模糊变清晰

“帮我做一个用户管理系统。”

你把这句话丢给 AI，它给你吐了一堆代码。打开一看——跟你想要的完全不是一回事。或者跟同事讨论需求，讲了半小时，发现大家理解的根本不是同一个东西。

问题不在 AI 不够聪明，也不在同事不配合，而是需求描述太模糊了。

我最近在研究怎么更高效地和 AI 讨论产品需求时，系统整理了 22 个经典方法论。这些方法论有些来自麦肯锡，有些来自丰田，有些来自哈佛商学院——但它们解决的核心问题一直没变：怎么把脑子里模糊的想法，变成别人（包括 AI）能准确理解和执行的方案。

这篇文章按五个阶段来组织：定义目标 → 拆解问题 → 描述需求 → 排优先级 → 持续改进。每个方法论都配了真实案例和"怎么跟 AI 用"的场景，拿来就能用。

一、定义目标：先想清楚你要去哪

1. SMART：把目标写得不像许愿

SMART 是最经典的目标管理框架，由管理学家 George T. Doran 在 1981 年的论文 “There’s a S.M.A.R.T. Way to Write Management’s Goals and Objectives” 中首次提出。它要求目标满足五个条件：

一个真实的踩坑案例：

“我要做一个博客系统”——这不是目标，这是许愿。用 SMART 改写：

“在 2 月 28 日前，搭建一个基于 Hugo 的个人博客，支持 Markdown 写作和自动部署到 GitHub Pages，首页加载时间 < 3 秒。”

跟 AI 怎么用： 在给 AI 提需求之前，先用 SMART 过一遍。与其说"帮我写个爬虫"，不如说"帮我写一个 Python 爬虫，每天定时抓取 Hacker News 前 30 条热帖的标题和链接，保存为 JSON 文件，运行时间控制在 10 秒以内"。关于怎么把需求精准地传达给 AI 工具，可以参考 AI 工作流实战手册。

2. OKR：目标对齐的利器

OKR（Objectives and Key Results）由 Intel 的 Andy Grove 发明，后经 John Doerr 引入 Google 并大规模推广。它和 SMART 的区别在于：SMART 管单个目标的质量，OKR 管一组目标的对齐。

OKR 的结构很简单：

Objective（目标）：我想达成什么？— 定性的、鼓舞人心的方向
Key Result（关键结果）：怎么知道达成了？— 定量的、可衡量的指标

实际例子：

O：让新用户注册流程丝滑到无感
  KR1：注册转化率从 40% 提升到 70%
  KR2：平均注册耗时从 3 分钟降到 45 秒
  KR3：注册后 7 日留存率从 20% 提升到 40%

注意：OKR 的关键结果不是任务清单（“上线 Google 登录"“重做注册页面”），而是你期望看到的结果变化。怎么做是团队自己决定的。

跟 AI 怎么用： 在规划产品方向时，先让 AI 帮你用 OKR 格式梳理目标。给它业务背景，让它建议 3-5 个 KR。AI 擅长从宏观目标拆出可衡量的指标，能帮你补上没想到的维度。

3. 第一性原理：从最底层重新想

第一性原理这个概念来自亚里士多德，但真正让它火起来的是 Elon Musk。

核心思路很简单：别管"别人怎么做的"和"一直以来怎么做的”，把问题拆到最底层的物理事实和基本规律，然后从零开始搭方案。

就像盖房子，第一性原理不是去参考别人家的装修风格，而是回到"砖头多少钱、水泥多少钱、人工多少钱"这个层面去思考。

经典案例：SpaceX 的火箭降本

当年 Musk 想造火箭，供应商报价一枚要 6500 万美元。传统做法是找更便宜的供应商，或者砍配置。Musk 用第一性原理思考：

火箭的原材料是什么？→ 铝合金、钛、铜、碳纤维
这些材料在市场上值多少钱？→ 大约只占火箭价格的 2%
为什么差这么多？→ 中间环节、传统工艺、供应链溢价
能不能自己造？→ 能。

结果 SpaceX 把发射成本降到了 NASA 的十分之一。

跟 AI 怎么用： 当你让 AI 帮你解决问题时，先问自己：“我是不是被旧做法绑住了？” 比如不要说"帮我优化这个 SQL 查询"，先想"这个数据真的需要实时查询吗？是不是预计算一下就行了？" 关于质疑惯性思维这件事，在 产品思维三板斧 这篇里有更深入的讨论。

4. 5W2H：把信息问全

5W2H 是一个帮你"问全"信息的检查清单。很多项目出问题，不是技术不行，而是一开始就没把事情搞清楚。

跟 AI 怎么用： 在跟 AI 讨论需求之前，先用 5W2H 列一遍。你会发现，很多"我以为我想清楚了"的事情，其实根本没想清楚。把这些信息一次性给 AI，比来回追问高效十倍。

5. 奥卡姆剃刀：能简单就别复杂

奥卡姆剃刀由 14 世纪哲学家奥卡姆的威廉提出，原话是"如无必要，勿增实体"。翻译成大白话就是：多个方案都能解决问题时，选最简单的那个。

这不是偷懒，而是对复杂度的敬畏。每多一层抽象、多一个依赖、多一个配置项，就多一个出 bug 的可能。

举个例子：

需求是"用户登录后记住状态"。

如果你的产品只有几千用户、没有多端登录需求，用框架自带的 Session 就够了。非要上 JWT + Redis 全家桶，就是过度设计。

跟 AI 怎么用： 当 AI 给你一个很复杂的方案时，追问一句：“有没有更简单的方式实现同样的效果？” 你会发现，很多时候真的有。关于"做减法"的思维方式，推荐看 AI 时代，一个人的 Taste 比以往任何时候都重要，里面聊了为什么"品味"是最稀缺的能力。

二、拆解问题：把大象装进冰箱

6. MECE：不重不漏地拆分

MECE（Mutually Exclusive, Collectively Exhaustive）由麦肯锡的 Barbara Minto 在 1960 年代发明，是她著名的"金字塔原理"的核心组成部分。Minto 是哈佛商学院 1963 届毕业生（600 人中仅 8 名女性之一），也是麦肯锡聘用的第一位女性 MBA。

两个核心要求：

• 互斥（ME）：每个子项之间不重叠
• 穷尽（CE）：所有子项加起来覆盖全部情况

听着像废话，但实际操作中特别容易犯错。

反面教材：

把"用户类型"分成"免费用户、VIP 用户、活跃用户"——这就不是 MECE 的，因为一个 VIP 用户也可以是活跃用户（有重叠），而且"沉默的付费用户"没被覆盖到（不穷尽）。

正确拆法：

按付费状态分：免费用户 / 付费用户          ← MECE ✓
按活跃度分：  活跃用户 / 不活跃用户        ← MECE ✓
交叉得到四种：免费活跃 / 免费沉默 / 付费活跃 / 付费沉默

跟 AI 怎么用： 在拆解需求时，让 AI 帮你检查是否 MECE。比如"帮我检查这个分类是否有重叠或遗漏"。AI 在逻辑检查方面很强，善用这个能力。

7. 二八法则：先抓最关键的 20%

二八法则（帕累托法则）说的是：80% 的结果，往往来自 20% 的原因。

这个规律最早由意大利经济学家 Vilfredo Pareto 在 1906 年发现——他观察到意大利 80% 的土地归 20% 的人口所有。后来人们发现这个比例在各种场景下都成立：

• 80% 的 bug 来自 20% 的代码模块
• 80% 的用户投诉集中在 20% 的功能上
• 80% 的收入来自 20% 的客户

实际应用：

假设你在优化一个 App 的性能，与其全面优化所有接口，不如先看监控数据，找出响应最慢的那 20% 接口。大概率优化完这 20%，用户体感就好了 80%。

跟 AI 怎么用： 在让 AI 帮你做优化之前，先识别关键的 20%。不要说"帮我优化整个项目的性能"，而是说"这三个接口占了 80% 的响应时间，帮我优化它们"。

8. 5 Whys：连问五个"为什么"

5 Whys（五个为什么）是丰田生产方式的核心工具，由丰田创始人丰田佐吉发明。方法极其简单：对一个问题连续追问"为什么"，通常问到第五次就能找到根本原因。

举个例子：

问题：用户注册转化率突然下降了 30%

为什么下降了？    → 因为很多用户在验证码环节流失了
为什么在验证码流失？→ 因为验证码短信经常收不到
为什么收不到？    → 因为短信供应商在高峰期限流了
为什么会限流？    → 因为我们用的是最低档套餐，有并发限制
为什么用最低档？  → 因为当时用户量小，选了最便宜的，之后没人review过

看到了吗？表面问题是"转化率下降"，根因是"供应商套餐选型过时，且缺少定期review机制"。如果只看表面，你可能会去优化注册页面的 UI——完全跑偏。

跟 AI 怎么用： 把问题描述给 AI，让它连续追问"为什么"。AI 不会碍于面子停下来，它会很诚实地一路追到根因。

9. SWOT：四个象限看清局势

SWOT 分析几乎是所有商学院的必修内容，从 Strengths（优势）、Weaknesses（劣势）、Opportunities（机会）、Threats（威胁）四个维度评估一个项目或产品的战略态势。

实际例子：评估要不要做一个 AI 写作助手

SWOT 的价值不在于填表本身，而在于填完之后的策略推导：

• SO 策略（用优势抓机会）：用 NLP 经验做企业定制化写作产品
• WT 策略（避劣势防威胁）：不做通用写作工具，避开大厂战场

跟 AI 怎么用： 在做产品决策前，让 AI 帮你做 SWOT 分析。把你的产品背景、市场信息给它，让它从四个维度列出分析。AI 能帮你想到你可能忽略的威胁和机会。

三、描述需求：让别人（和 AI）准确理解你要什么

10. JTBD：关注用户要完成的任务

JTBD（Jobs To Be Done）由哈佛商学院教授 Clayton Christensen 提出，核心理念是：用户不是在"购买产品"，而是在"雇佣产品来完成某个任务"。 Christensen 指出，75%-85% 的新产品在市场上失败，原因正是它们没有瞄准用户真正想要完成的"工作"。

最经典的案例——麦当劳奶昔：

麦当劳想提升奶昔销量，传统做法是做用户调研——问"你想要什么口味的奶昔"，然后按反馈改配方。结果销量纹丝不动。

后来 Christensen 的研究团队换了个思路：不问用户想要什么，而是去观察用户什么时间买奶昔、买完在哪里喝。

结果发现：40% 的奶昔在早上 8:30 前卖出，买的人都是开车通勤的上班族。

他们"雇佣"奶昔的"任务"是什么？——在无聊的通勤路上，单手就能吃、能管饱到中午、比面包有意思的东西。

奶昔的竞争对手不是隔壁店的奶昔，而是香蕉、能量棒、百吉饼。

理解了这个"任务"之后，麦当劳把早上的奶昔做得更稠（喝得更久）、加了水果颗粒（更有嚼劲），销量翻了 7 倍。

跟 AI 怎么用： 描述需求时，不要只说"我要一个 XX 功能"，而是说"我的用户在 XX 场景下需要完成 XX 任务，目前的痛点是 XX"。这样 AI 才能理解需求背后的"为什么"，给出更贴合的方案。

11. 用户故事：用三段式描述需求

用户故事的标准格式：

作为 [某类用户]，
我想要 [某个功能/行为]，
从而 [达到某个目的/获得某个价值]。

这个格式强迫你回答三个问题：谁要用？要干嘛？为什么？

举个例子：

❌ "做一个导出功能"

✅ "作为运营人员，
    我想要将上周的用户行为数据导出为 Excel，
    从而能在周一的例会上做数据汇报。"

第二种写法多了什么？上下文。你知道了是谁在用（运营人员）、用在什么场景（周一例会）、需要什么格式（Excel）。这些信息直接影响技术方案——比如数据量大不大、需不需要异步导出、格式要不要支持自定义。

跟 AI 怎么用： 直接用用户故事格式给 AI 提需求。AI 特别擅长从结构化输入中提取关键信息。试试看，效果比一句话需求好太多。现在很多 AI 编程工具也支持用 Skill 或自定义指令 来预设需求模板，让这个流程更顺滑。

12. 验收标准 GWT：把"做完了"定义清楚

GWT（Given/When/Then）是行为驱动开发（BDD）中常用的验收标准格式：

给定（Given）：某个前置条件
当（When）：用户执行某个操作
则（Then）：系统应该产生某个结果

为什么需要它？

因为"做完了"这三个字，不同人的理解完全不同。产品经理觉得"能用就行"，测试觉得"边界情况都得覆盖"，老板觉得"界面还得好看"。GWT 把验收标准写死，避免扯皮。

实际例子：

功能：用户登录

场景：正常登录
  给定 用户已注册且账号状态正常
  当 用户输入正确的邮箱和密码，点击登录
  则 跳转到首页，显示用户昵称

场景：密码错误
  给定 用户已注册
  当 用户输入正确的邮箱但密码错误
  则 提示"邮箱或密码错误"，不透露具体是哪个错

场景：账号被锁定
  给定 用户连续输错密码 5 次
  当 用户第 6 次尝试登录
  则 提示"账号已锁定，请 30 分钟后重试"

跟 AI 怎么用： 这是跟 AI 协作时的大杀器。你把 GWT 格式的验收标准给 AI，它写出来的代码会精准得多。而且你可以直接让 AI 根据 GWT 生成测试用例——一个方法论同时解决了需求描述和测试覆盖两个问题。

13. Kano 模型：需求也分三六九等

Kano 模型由东京理科大学教授狩野纪昭（Noriaki Kano）在 1984 年提出。当时业界普遍认为"处理投诉 + 增强热门功能"就能提升满意度，Kano 用 900 名参与者的研究证明，客户满意度远比这复杂。他把需求分成几种类型：

关键洞察： 先把必备型做到位，再投入期望型提升体验，最后用惊喜型做差异化。很多团队犯的错误是必备型还没做好就去搞惊喜型——支付经常失败，但花了一个月做了个花哨的开屏动画。

跟 AI 怎么用： 在跟 AI 讨论功能列表时，先用 Kano 模型分类，告诉 AI “这个是 Must-have，必须稳定可靠；那个是 Nice-to-have，可以简单实现”。这样 AI 会合理分配方案的复杂度。

14. SCQA：结构化表达你的想法

SCQA 由 Barbara Minto（没错，又是她）在金字塔原理中推荐的叙事框架，用四步把复杂信息讲清楚：

为什么 SCQA 有用？

因为大多数人讲事情是"从头讲到尾"——背景说半天，听的人还不知道你到底要说什么。SCQA 强迫你先制造冲突再给答案，让听的人（或读你需求文档的 AI）一下就抓住重点。

跟 AI 怎么用： 当你要跟 AI 讨论一个复杂需求时，用 SCQA 格式开头。比如：

“我们的博客系统目前用 Hugo 构建，每篇文章要手动创建目录和写 Front Matter（S）。随着文章数量增多，这个流程越来越慢且容易出错（C）。有没有办法自动化这个流程（Q）？我希望通过一个脚本或工具，输入标题就能自动创建完整的文章骨架（A）。”

这样 AI 立刻就知道你的背景、痛点和期望，给出的方案会精准得多。

四、排优先级：决定先做什么

15. Eisenhower 矩阵：紧急的不一定重要

这个矩阵据传来自美国总统艾森豪威尔的一句话：“重要的事很少紧急，紧急的事很少重要。” 它按紧急和重要两个维度把任务分成四个象限：

核心洞察： 大多数人把时间花在第一象限（救火）和第三象限（杂事），而真正决定长期成败的是第二象限——那些重要但不紧急的事。

跟 AI 怎么用： 把你的待办列表给 AI，让它帮你按 Eisenhower 矩阵分类。AI 不会被"紧急"的情绪裹挟，能更客观地区分什么是真的重要。

16. MoSCoW：四刀切出优先级

MoSCoW 由 Dai Clegg 在 1994 年于 Oracle UK Consulting 工作期间创建，后被纳入 DSDM 敏捷框架广泛使用。它把所有需求分成四档：

“Won’t have” 是最重要的一档。 很多项目失败不是因为做少了，而是因为什么都想做。把"不做"的事情写下来，比"要做"的事情更重要——它划定了边界。

实际操作：

项目：公司内部知识库系统 v1

Must have：
  - 文档的创建、编辑、删除
  - 全文搜索
  - 基于角色的权限控制

Should have：
  - Markdown 编辑器（先用纯文本也行）
  - 文档版本历史

Could have：
  - AI 智能搜索
  - 文档模板

Won't have（这次明确不做）：
  - 多语言支持
  - 移动端 App
  - 第三方集成（Slack、飞书）

跟 AI 怎么用： 在给 AI 分配任务时，明确告诉它 MoSCoW 分级。比如"先完成 Must have 的三个功能，Should have 的两个如果时间允许再加，Could have 的先不考虑"。

17. RICE：给优先级打个分

RICE 评分框架由 Intercom 产品团队的 Sean McBride 开发，用四个维度给每个需求打分，让优先级排序更客观。创建背景是 Intercom 发现之前的排序方式偏向"个人偏好项目"，而非真正影响最多客户的想法。

计算公式：

RICE 分数 = (Reach × Impact × Confidence) / Effort

实际打分示例：

结论很清晰：先优化搜索结果。

注意： RICE 不是法律，是参考。有些低分需求可能是高分需求的前置依赖，有些是"桌面赌注"（不做就没法卖），需要结合实际判断。

18. MVP：先做最小闭环

MVP（Minimum Viable Product，最小可用产品）核心思想是：用最少的功能完成一个完整的使用闭环，快速上线验证价值。

关键词是"闭环"——不是做一半丢在那里，而是用户能完整走通整个流程，只是每一步都是最简版本。

经典案例：Dropbox

Dropbox 的 MVP 不是一个简陋版的云盘，而是一个 3 分钟的演示视频。创始人 Drew Houston 在视频里演示了文件同步的概念，发布到 Hacker News。一夜之间，等待列表从 5000 人涨到 75000 人。

19. MLP：在"能用"的基础上让人"想用"

MLP（Minimum Lovable Product，最小可爱产品）由 Aha! 公司 CEO Brian de Haaff 在 2013 年提出。它是对 MVP 的升级——不仅要"能用"，还要有让用户"想用下去"的关键体验点。

怎么选：

跟 AI 怎么用： 让 AI 帮你梳理"哪些功能构成 MVP 闭环，哪些是 MLP 的体验加分项"。给出明确边界，AI 写代码时就不会过度设计，也不会遗漏关键流程。

20. Pre-mortem：假设已经失败了，倒推原因

Pre-mortem（事前验尸）是心理学家 Gary Klein 在 Harvard Business Review 上提出的方法，获得了诺贝尔经济学奖得主 Daniel Kahneman 的推荐。1989 年的研究表明，这种"前瞻性后见之明"能将准确预测风险的能力提高 30%。

做法很反直觉：项目还没开始，就假设它已经失败了，然后让团队倒推"可能是因为什么失败的"。

为什么这比"风险评估"管用？因为当你说"大家想想有什么风险"时，没人愿意当乌鸦嘴。但当你说"项目已经失败了，你觉得是因为什么"——心理负担一下就没了，大家反而会畅所欲言。

怎么做：

步骤 1：宣布"假设我们的项目在 3 个月后彻底失败了"
步骤 2：每个人独立写下"可能的失败原因"
步骤 3：汇总、分类、识别高频原因
步骤 4：针对高频原因制定预防措施

常见的失败原因模板：

跟 AI 怎么用： 这是 AI 特别擅长的场景。把你的项目计划给 AI，让它"假设这个项目失败了，列出 10 个最可能的原因"。AI 没有人际关系的顾虑，会非常直接地指出你没想到的风险点。

五、持续改进：做完之后怎么办

21. PDCA：转起来的改进飞轮

PDCA 循环（也叫戴明环）由质量管理大师 W. Edwards Deming 推广，是精益生产和六西格玛的基石。它的四个步骤形成一个不断转动的飞轮：

Plan（计划）→ Do（执行）→ Check（检查）→ Act（改进）→ 再 Plan...

看着像废话？关键在Check 和 Act 这两步大多数人会跳过。

实际例子：

Plan：本周优化搜索功能，目标是搜索响应时间从 2 秒降到 500 毫秒
Do：  加了 Elasticsearch 索引，重写了查询逻辑
Check：上线后实测 800 毫秒，没达标；发现是分词策略导致索引过大
Act：  调整分词策略，优化索引结构 → 进入下一轮 PDCA

每转一圈，系统就好一点。看起来慢，但复利效应惊人。

跟 AI 怎么用： 每次让 AI 帮你做完一件事，不要止步于"能跑了"。追加一轮 Check——“帮我 review 这段代码有没有性能问题或安全隐患”，然后根据反馈再 Act。这就是 PDCA 在 AI 协作中的应用。关于怎么在 AI 开发中建立这样的反馈循环，可以看 我的 AI 开发工作流：从需求到上线。

22. Design Thinking：以用户为中心的创新流程

Design Thinking 由 IDEO 公司推广，被 Uber、Airbnb、IBM 等公司广泛采用。它是一个以用户为中心的创新流程，包含五个阶段：

共情（Empathize）→ 定义（Define）→ 构思（Ideate）→ 原型（Prototype）→ 测试（Test）

Design Thinking 的价值在于：它是前面所有方法论的"操作系统"。共情阶段用 JTBD，定义阶段用 MECE 和 5 Whys，构思阶段用 SCQA 表达方案，原型阶段用 MVP 控制范围，测试阶段用 GWT 做验收。

跟 AI 怎么用： AI 在 Design Thinking 的每个阶段都能帮上忙——共情阶段让它分析用户反馈数据，定义阶段让它帮你做 MECE 拆解，构思阶段让它头脑风暴方案，原型阶段让它快速生成代码。把 Design Thinking 当做你和 AI 协作的主流程框架，效率会高很多。关于如何在实际开发中应用这套流程，推荐参考 Claude Code 最佳实践。

六、串起来用：一个完整的需求分析流程

这 22 个方法论不是互相独立的，它们可以串成一个完整的工作流：

1. 定义目标
   SMART → 把单个目标写清楚
   OKR → 确保目标之间对齐
   第一性原理 → 确认目标本身是对的
   5W2H → 把相关信息补全
   奥卡姆剃刀 → 确认没有过度设计

2. 拆解问题
   MECE → 不重不漏地拆分
   二八法则 → 找到最关键的 20%
   5 Whys → 追到根本原因
   SWOT → 看清内外部态势

3. 描述需求
   JTBD → 明确用户要完成的任务
   用户故事 → 用标准格式描述
   GWT → 写清验收标准
   Kano 模型 → 区分需求类型
   SCQA → 结构化表达方案

4. 排优先级
   Eisenhower → 区分紧急和重要
   MoSCoW → 四档分类
   RICE → 量化打分
   MVP/MLP → 确定第一版的范围
   Pre-mortem → 提前识别风险

5. 持续改进
   PDCA → 每轮迭代都有检查和改进
   Design Thinking → 以用户为中心持续创新

在跟 AI 讨论产品需求时，这个流程特别有用。 你不需要每次都用全部 22 个，但至少过一遍相关的几个，你会发现 AI 的输出质量会显著提升——因为你给的输入质量先提升了。

总结

方法论不是教条，是工具。就像你不会每次拧螺丝都用扳手（有时候手拧就行），你也不需要每次写需求都把 22 个方法论过一遍。

但当你发现——

• 目标说不清楚 → 试试 SMART + OKR
• 需求描述模糊 → 试试用户故事 + GWT + SCQA
• 不知道先做什么 → 试试 RICE + MoSCoW + Eisenhower
• 方案太复杂 → 试试奥卡姆剃刀 + 二八法则
• 项目总出意外 → 试试 Pre-mortem + SWOT
• 功能做了没人用 → 试试 JTBD + Kano + 5 Whys
• 做完了不知道下一步 → 试试 PDCA + Design Thinking

——的时候，回来翻翻这篇文章，挑一两个方法论用起来。不用全记住，用的时候查就行。

最后说一句：这些方法论最大的价值，不是让你"显得专业"，而是帮你把脑子里模糊的东西变成清晰的、别人能理解的、可以执行的东西。 不管你是跟人沟通还是跟 AI 协作，这都是最核心的能力。

相关阅读

• 产品思维三板斧：删除优先、质疑一切、亲赴火线 — 用删除思维做产品决策
• AI 时代，一个人的 Taste 比以往任何时候都重要 — 当 AI 什么都能做，什么值得做是核心问题
• AI 工作流实战手册：从提示词到编程 — 把 AI 从聊天玩具变成生产力工具
• 我的 AI 开发工作流：从需求到上线 — 软件开发全流程中的 AI 实战经验