Fable 实战指南：用 AI 找出你还不知道自己缺什么
很多人用 AI，卡在一个很隐蔽的问题上：
你不知道自己不知道什么。
你可能只丢给 AI 一句：
帮我做一个用户增长方案。
AI 当然能写。几秒钟就能给你一份结构完整、语气专业、看起来很像那么回事的方案。
可问题来了：
- 目标用户是谁？
- 现有渠道转化率多少？
- 用户为什么流失？
- 哪些假设已经验证过？
- 预算、团队和时间有什么限制？
- 方案失败时，谁来承担代价？
这些问题没被问出来，AI 写得越顺，结果可能越偏。
Fable 的价值，正是在这里。
它不是一个“替你生成答案”的按钮，而是一套帮助你发现未知、拆解问题、验证假设的探索式工作流。
一、Fable 到底解决什么问题？
你可以把问题分成四层：
1. 已知的已知
你明确知道的信息。
比如：
- 产品上线三个月
- 当前有 10 万注册用户
- 月活约 2 万
- 主要用户来自小红书
这部分通常写在需求文档里。
2. 已知的未知
你知道自己缺信息。
比如：
- 不清楚用户为什么不续费
- 不知道竞品的真实定价策略
- 不确定哪些功能带来转化
这类问题相对好处理。列出来，再去查资料、做访谈、跑实验。
3. 未知的已知
信息其实存在，只是没人整理过。
例如：
- 客服聊天记录里反复出现同一个抱怨
- 数据看板里已经有流失趋势
- 销售团队早就知道客户最在意什么
- 产品经理脑中有判断，却没写进文档
Fable 可以帮你把这些零散信息拼起来。
4. 未知的未知
这才是最危险的区域。
你甚至没意识到自己漏掉了问题。
比如你准备做一个 AI 客服，却没考虑：
- 用户是否愿意把敏感信息交给机器人
- 机器人答错后有没有人工兜底
- 不同客户的知识库是否会串数据
- 员工会不会因为 AI 上线而抵触
- 这个项目的成功指标到底是什么
一个好工作流，不是帮你更快地冲向答案。
它会先拉你停下来，问一句：
咱们是不是漏掉了什么？
二、Fable 的核心流程
一套实用的 Fable 流程，可以压缩成五步：
描述目标
↓
整理已知信息
↓
暴露未知与假设
↓
设计验证动作
↓
沉淀成知识地图
别急着让 AI 输出完整方案。
先让它帮你检查问题本身。
这一步看起来慢，实际能省掉大量返工时间。尤其是写产品方案、研究报告、技术架构和商业计划时，效果很明显。
三、第一步：给 AI 一个“粗糙但真实”的目标
别一上来写成正式需求文档。
真实工作里，你通常只有一句模糊描述：
我想给独立开发者做一个 AI 写作工具，帮助他们更快写出产品介绍页。
这就够了。
Fable 不要求你一开始就把所有细节交代清楚。它要的，是一个可以继续追问的起点。
可以直接使用这个提示词：
我正在考虑做一个项目：
[用几句话描述你的想法]
请不要直接给我方案。
请先帮我拆解：
1. 我已经明确知道的内容
2. 我可能默认了、但没有说出来的前提
3. 目前缺失的重要信息
4. 可能影响结果的未知问题
5. 你认为最值得优先验证的三个问题
请把问题分成：用户、场景、目标、资源、风险、验证方式六类。
如果我的描述太模糊，请直接指出模糊在哪里。
这个提示词有个关键点：
禁止 AI 立刻给答案。
否则它很容易进入“自动补全模式”，把你的空白直接填上。填得还挺像，但未必是真的。
四、第二步：让 AI 区分事实、判断和猜测
很多项目混乱，不是资料少，而是大家把三种东西混在了一起：
- 已经确认的事实
- 基于经验的判断
- 暂时没有证据的猜测
举个例子：
我们的用户喜欢短视频，所以他们应该也喜欢 AI 自动剪辑。
这里至少有三个假设：
- 这些用户真的喜欢创作短视频
- 他们愿意使用自动剪辑工具
- 他们当前的痛点是剪辑耗时，而不是内容质量、流量或选题
可以让 Fable 按表格整理：
请分析下面这段项目描述，并把内容拆成四列：
- 已确认事实
- 我的主观判断
- 尚未验证的假设
- 需要补充的证据
项目描述：
[粘贴你的描述]
不要替我判断假设是否正确。
请说明每条内容为什么属于这一类。
输出可能长这样：
| 内容 | 类型 | 需要什么证据 | |---|---|---| | 用户每周发布 3 条短视频 | 已确认事实 | 用户行为数据 | | 用户希望减少剪辑时间 | 主观判断 | 用户访谈、问卷 | | 自动剪辑会提升留存 | 未验证假设 | A/B 测试 | | 用户更在意成片质量而非速度 | 未知问题 | 访谈与任务测试 |
这张表的作用很大。
它能防止你把一句“我觉得”写进商业计划书，再拿它指导整个项目。
五、第三步：专门寻找“没被问过的问题”
普通提问通常会围绕你已经想到的方向展开。
你问用户增长，AI 就讲渠道、内容、转化和留存。
真正有价值的追问，需要逼它跳出你的框架。
试试下面这组提示：
请扮演一个经验丰富、但不迎合我的项目顾问。
针对下面的计划，请专门寻找：
- 我完全没有提到、但可能决定成败的问题
- 只有项目失败后才会暴露的问题
- 团队容易忽略的运营问题
- 用户可能不会主动告诉我的真实顾虑
- 资源、法律、隐私、成本和维护方面的隐性风险
- 如果这个计划成立，我仍然可能低估的工作量
不要重复常规建议。
每个问题请说明：
1. 为什么容易被忽略
2. 它可能造成什么后果
3. 如何用低成本方式验证
项目计划：
[粘贴内容]
这一步的重点不是让 AI 变得悲观。
而是把“项目想象中的世界”和“真实运行的世界”分开。
举个例子，你想做一个给企业内部使用的知识库问答机器人。
AI 可能帮你发现这些隐藏问题：
- 同一个词在不同部门的含义不一样
- 文档过期后，谁负责更新
- 员工不敢把真实问题输入系统
- 高管希望看到提问记录，员工却需要隐私
- 答案看起来正确，但引用的制度已经失效
- 用户问不到答案时，会不会直接放弃使用
这些问题，通常不会出现在产品宣传页里。
它们却很容易决定项目能不能活过三个月。
六、第四步：把未知问题排出优先级
问题多了，不能一股脑全查。
你需要判断：哪些问题值得现在验证，哪些可以晚点再管。
可以用一个简单的四象限：
| | 影响较低 | 影响较高 | |---|---|---| | 容易验证 | 顺手确认 | 立刻验证 | | 难以验证 | 暂时记录 | 拆成小实验 |
也可以让 AI 帮你排序：
下面是我整理出的未知问题：
[粘贴问题清单]
请为每个问题打分：
- 影响程度：1-5 分
- 不确定程度：1-5 分
- 验证成本：1-5 分
- 如果判断错误，返工代价：1-5 分
然后按“高影响、高不确定、低验证成本”的顺序排序。
给出前五个最值得验证的问题，并为每个问题设计一个 48 小时内能完成的小实验。
例如：
| 问题 | 影响 | 不确定 | 验证成本 | 建议动作 | |---|---:|---:|---:|---| | 用户是否愿意上传内部文档 | 5 | 5 | 2 | 找 5 名目标用户做访谈 | | 用户更在意速度还是准确率 | 5 | 4 | 2 | 做二选一任务测试 | | 是否需要支持多语言 | 2 | 3 | 4 | 记录需求，暂不开发 |
注意一个常见误区：
不要优先验证最容易验证的问题。
“按钮用蓝色还是绿色”很容易测试，也很容易让人产生忙碌感。
真正该验证的，是那些一旦判断错误，就会让你白做几个月的问题。
七、第五步：让 Fable 充当“反方团队”
你可以让 AI 分别扮演不同角色，从多个角度攻击方案。
用户视角
请扮演目标用户。
你第一次看到这个产品时：
- 哪句话让你感兴趣
- 哪句话让你怀疑
- 哪个功能你觉得多余
- 哪个风险会让你拒绝使用
- 你会在什么情况下立刻关闭页面
运营视角
请从运营角度审查这个计划。
重点检查：
- 用户从哪里来
- 谁负责持续触达
- 用户为什么留下
- 用户不活跃时怎么办
- 这个方案是否依赖过多人工维护
财务视角
请从成本和商业模型角度审查。
请找出：
- 被低估的固定成本
- 随用户增长而增加的成本
- 难以规模化的人工环节
- 用户愿意付费和实际成本之间的矛盾
- 可能导致现金流断裂的环节
反对者视角
请假设这个项目最终失败了。
写出五种最可能的失败路径。
每条路径说明：
- 最早会出现什么信号
- 团队为什么可能忽略它
- 哪个小实验可以提前发现
这类角色切换很适合团队讨论。
会议上没人愿意当那个“泼冷水的人”，AI 可以补上这个位置。
当然，AI 的批评也可能不靠谱。它的作用是扩大检查范围，不是替你做判断。
八、一个完整案例：做 AI 求职助手
假设你的想法是：
做一个 AI 求职助手，帮用户修改简历、生成求职信、准备面试。
原始目标
看起来很清楚。
实际上还有很多空白：
- 面向应届生，还是工作多年的人？
- 用户最缺的是写作、信息整理，还是面试训练？
- 用户愿不愿意提供真实经历？
- AI 生成的内容会不会让简历变得千篇一律？
- 求职失败后，用户会把问题归咎于工具吗？
- 招聘方是否能识别 AI 生成内容？
让 AI 继续追问
我想做一个 AI 求职助手，提供简历修改、求职信生成和面试模拟。
请不要设计功能列表。
请从求职者、招聘方、平台运营、隐私合规四个角度，找出这个项目中被隐藏的假设。
请特别关注：
- 用户真正愿意为哪一步付费
- 哪些信息属于高敏感个人数据
- AI 生成内容可能带来的反效果
- 如何判断工具确实帮助用户找到工作
得到的关键未知
可能会发现：
- 用户不缺一封求职信，缺的是不知道该投什么职位
- 简历修改不是核心需求，岗位匹配才是
- 用户最在意的是“通过筛选”，不是文字是否漂亮
- 面试模拟很有吸引力，但重复使用率可能很低
- 用户可能会直接复制 AI 内容，导致简历缺乏可信度
低成本验证
别急着开发完整产品。
可以在两天内做三个实验：
- 找 10 名求职者，观察他们实际修改简历的过程
- 提供人工辅助的岗位匹配服务，记录用户愿意付费的环节
- 让同一份简历分别由人工和 AI 修改，再邀请招聘人员盲评
一轮实验后，你可能会发现：
真正值得做的不是“万能求职助手”，而是“针对特定岗位的简历诊断工具”。
这就是 Fable 的意义。
它帮你从“我能做什么”，转向“用户真正需要什么”。
九、把探索结果沉淀成一张“未知地图”
每次和 AI 聊完，不要让结论散落在聊天记录里。
建议保存成下面这种结构：
# 项目名称
## 目标
- 我想解决什么问题
- 为谁解决
- 成功的具体表现是什么
## 已确认事实
- 用户已经做过什么
- 有哪些数据支持
- 哪些限制已经确定
## 核心假设
- 用户真的有这个痛点
- 用户愿意改变当前行为
- 用户愿意为解决方案付费
## 未知问题
- 哪些问题还没有证据
- 哪些问题可能影响项目成败
## 验证记录
| 日期 | 假设 | 验证动作 | 结果 | 下一步 |
|---|---|---|---|---|
## 暂时不处理
- 低影响问题
- 与当前阶段无关的问题
- 没有足够证据支持的问题
这张地图会不断变化。
新的访谈结果会推翻旧判断。
某个风险被验证后，就从“未知”变成“已知”。
项目也会从模糊想法，慢慢变成一组可检查的判断。
十、适合直接复制的 Fable 提示词模板
模板一：发现遗漏
这是我的项目描述：
[项目描述]
请不要直接给建议。
请找出我没有提到、但可能影响项目结果的问题。
按用户、需求、竞争、技术、成本、运营、合规七类整理。
每个问题附上风险说明和验证方式。
模板二：检查隐藏假设
请从下面的计划中提取所有隐藏假设：
[计划内容]
把每条假设改写成可以被验证的句子。
标注它属于：用户假设、行为假设、技术假设、商业假设或资源假设。
模板三：设计小实验
我有一个待验证假设：
[假设]
请设计三个不需要开发完整产品的验证实验。
要求：
- 48 小时内可以完成
- 尽量接近真实行为
- 不要只依赖口头反馈
- 说明成功标准和失败信号
模板四：复盘新信息
这是我们刚获得的新信息：
[访谈、数据或反馈]
请判断它对现有项目假设有什么影响：
1. 哪些假设被支持
2. 哪些假设被削弱
3. 哪些新问题出现
4. 下一步最值得做什么
请区分证据和推测。
十一、使用 Fable 时最容易踩的坑
坑 1：把 AI 的问题当成事实
AI 提出的风险，只是待检查的方向。
它说“用户可能担心隐私”，不代表用户真的担心。
去访谈。 去看数据。 去观察真实行为。
坑 2：问题列得很满，验证动作为零
写出 50 个未知问题很容易。
真正有价值的是：今天能验证哪一个？
每次最多挑三个。否则清单会变成新的拖延工具。
坑 3：让 AI 过早收敛
一上来就要求：
请给我最终方案。
你会得到一份漂亮的答案，也会失去探索空间。
先问问题，再整理假设，再做方案。
坑 4：只让 AI 顺着你的方向思考
如果你一直说“我想做一个”，AI 很容易默认这个想法值得做。
可以直接加一句：
如果这个方向本身不值得做，请明确指出，并给出判断依据。
坑 5：把角色扮演当成真实调研
AI 可以模拟用户。
它不能替代真实用户。
模拟适合找问题，真实调研才适合做决策。
坑 6：忽略项目之外的人
一个产品的使用者，不一定是购买者、审批者和受影响的人。
企业软件尤其如此。
把用户、老板、采购、法务、客服和维护人员都放进问题清单里，很多盲区会自己冒出来。
十二、什么时候最适合用这套方法？
Fable 特别适合这些场景：
- 你只有一个模糊想法，还没准备写方案
- 团队对目标用户各有一套理解
- 项目投入很大，试错成本很高
- 需要做技术选型或架构设计
- 要写研究报告、商业计划或产品需求文档
- 已经有很多资料，却不知道缺哪块
- 项目进行了一段时间，结果和预期不一致
它不太适合用来处理：
- 只需要查一个明确事实的问题
- 已经有标准答案的操作任务
- 必须由专业人士确认的法律、医疗和安全决策
Fable 更像项目开始前的一盏探照灯。
它不能替你走路。
但能帮你看清前面是不是有坑。
收尾：别急着找答案，先确认问题问对了
AI 最擅长的事情之一，是快速补全空白。
这也是它容易把人带偏的地方。
当背景不完整、目标不清楚、假设没验证时，AI 仍然会给你一份流畅答案。读起来很舒服，执行起来可能很痛苦。
Fable 提供了另一种用法：
- 先把想法说出来
- 让 AI 标记事实、判断和猜测
- 专门寻找没被提到的问题
- 按影响和验证成本排序
- 用小实验替代大投入
- 把结果沉淀成一张持续更新的未知地图
下次你准备让 AI“直接写方案”时，先换成这句：
在给出方案之前，请告诉我还缺哪些关键信息，以及哪些假设最值得验证。
这句话，可能比一百条复杂提示词更有用。
