Fable 5 实战教程：8 步从“能用”到“惊艳”

这是一份跟着做就能上手的教程，整理自一份公开发布的 Fable 5 提示方法指南。原作者是一位在 AI 圈颇有影响力的海外开发者，我把他的方法论拆解成 8 个可操作的步骤，每一步都有具体提示词模板、操作清单和检查点。

读法建议：别跳读，按顺序做一遍。 这套方法的核心是一个“心智转换”，前面几步是地基。

图：原指南《How I Prompt Fable》封面

教程概览

8 个步骤，由浅入深：

图：8 步工作流总览

第 1 步：从“给步骤”改成“给目标”

这一步要解决什么

你以前用 AI 的习惯，多半是把任务拆成详细步骤喂给它。这在上一代模型上有效，但在 Fable 5 上反而限制了它。

原作者的原话：

“我规定的每一步，都是在用我的判断覆盖它的判断，而我的判断通常更差。”

Fable 5 强到你越放手，它越能找到更好的解法。

具体操作

拿出你最近一个任务，把它从“步骤式”改写成“目标式”。

反面写法，步骤式（老方法）：

帮我做一个搜索框：
1. 在导航栏右侧加一个 input
2. 绑定 onChange 事件
3. 回车时跳转到 /search?q=关键词
4. 移动端要适配
5. 加个 loading 状态

推荐写法，目标式（Fable 方法）：

在导航栏加一个搜索功能，用户输入关键词回车后能跳到搜索结果页。
要在桌面和移动端都好用。

看出区别了吗？目标式只说**“要什么”和“完成长什么样”**，完全不说“怎么做”。怎么做，交给 Fable。

检查点

• 你的提示词里有没有“先做 A 再做 B”这种步骤？有的话删掉
• 你有没有规定具体技术实现（用哪个库、调哪个 API）？能删就删
• 你描述的是“目标”还是“过程”？应该是前者

心法：如果你能用一句话说清“我想要什么”，就别说三句话解释“怎么做”。

第 2 步：写“家规”，给信任加一道护栏

这一步要解决什么

第 1 步让你放手，但放手不等于放任。你需要几条不可跨越的红线，确保 Fable 无论怎么达成目标，都不会跑偏到无法接受的方向。

家规不是步骤，而是“无论怎么做，这几件事永远为真”。

具体操作：写一份 house-rules.md

新建一个文件 house-rules.md，写 3-5 条你认为最重要的红线。

模板：

# 家规（House Rules）

无论怎么达成目标，以下规则永远为真：

1. 【不硬编码特例】遇到边界情况，把期望行为写进系统提示词
   让 agent 自己推理，不要写正则去抓特定输入。

2. 【不引入新依赖】除非现有依赖确实无法满足，否则不要加新的 npm 包。
   加之前必须说明理由。

3. 【错误处理要具体】不要用笼统的 try-catch 吞掉错误。
   每个错误都要有明确的处理逻辑或日志。

4. 【保持向后兼容】本次改动不能破坏现有 API 的调用方。

写完之后，在每个项目的开头告诉 Fable：

从现在起，严格遵守 house-rules.md 里的所有规则。
任何输出在提交前，对照家规逐条自检。

检查点

• 家规是“原则”还是“步骤”？应该是原则
• 家规数量控制在 3-5 条，太多就失去焦点
• 每条家规能否用“是/否”判定违反？不能的话写具体一点

提示：原作者还加了一层保险，让 Fable 在推送任何东西之前，专门起一个子 agent 对照家规检查。这条我们在第 4 步会展开。

第 3 步：把“完成”定义成可验证的标准

这一步要解决什么

这是整份指南里最能拉开差距的一步。

如果你告诉 Fable“做一个高质量界面”，它会停在自己认为“够好”的点上，而这个点通常远低于你的标准。因为“高质量”是形容词，AI 没法证明自己没达到，所以可以理直气壮地说“我做完了”。

具体操作：把形容词换成可验证标准

每开始一个任务，先问自己：“怎么算完成？” 然后把答案写成 Fable 能自查的标准。

对照表：

原作者的神来之笔：让 Fable 自己发明尺子

有时你也不知道怎么衡量想要的东西。这时把“怎么衡量”这个问题也交给 Fable。

提示词模板：

我的目标是 [XXX]。
但我还没想好怎么判断“完成了”。

请你先帮我定义一个可量化的、很难达到的“完成”标准。
这个标准要能让你自己反复自查，不需要我人工判断。
标准定好之前，先别动手做。

指南里讲过一个真实案例：原作者想克隆一个组件库，但没法定义“匹配原版”。Fable 自己发明了衡量方法，录原版的屏幕录像、转成运动热力图、一直工作直到自己的版本热力图匹配。

检查点

• 你的“完成”定义里有形容词吗？（好看、流畅、高质量）有的话全删
• 这个标准 Fable 能自己反复测量吗？不能的话它还是会“自评”
• 标准够难吗？太容易等于没有标准

铁律：干活的人不能给自己打分。这条非常重要，单独放到第 4 步。

第 4 步：起一个对抗性子 agent 当裁判

这一步要解决什么

第 3 步定义了标准，但有个致命问题：如果让干活的 Fable 自己检查自己，它永远会偏向“宣布完成”。因为它做了一堆决策，会有一整套“我为什么这么做”的话术来自证。

原作者的铁律：

做东西的那个 agent，永远不能给它自己打分。

具体操作

干完一个阶段后，另起一个全新上下文的 Fable 会话，让它当对抗性裁判。

裁判提示词模板：

这是一个 [项目类型] 的输出，运行在 [地址/路径]。
目标是 [XXX]，完成标准是 [YYY]。

你的任务是：尽力证明这个东西【没达标】。
不是检查它“是否达标”，而是假设它不达标，去找证据。

具体做：
1. 真实运行/打开它，不要只看代码
2. 对照完成标准，逐条找反例
3. 列出所有不达标的点，按严重程度排序
4. 如果找不到任何不达标的点，明确说“我试图证明它不达标但失败了”

不要客气，不要为了鼓励我而放松标准。

三个关键细节

为什么这套比“自我检查”强得多：

1. 全新上下文：裁判 agent 没有沉没成本偏见，它不知道构建过程的艰辛
2. 指向真实输出：看运行中的产物（真实像素、运行的应用），不是看代码
3. 目标是“证明不达标”：对抗性思维，比“检查是否达标”更严格，会主动找茬

检查点

• 裁判是“全新会话”吗？如果复用构建会话，偏见还在
• 裁判看的是真实运行结果，还是只读代码？应该是前者
• 裁判的任务是“找茬”还是“验收”？应该是找茬

第 5 步：开循环，让它自检、补差、再来

这一步要解决什么

有了目标、家规、标准、裁判，剩下的就是把 Fable 放进循环里跑。

原作者的循环逻辑：构建 → 自检（用第 4 步的裁判）→ 找最大差距 → 补上 → 再来。 几小时，有时几天。

循环的全部意义用一句话说：

Fable 永远不能自己决定“我完成了”。总有一个下一个差距。它停下来是我说了算，或者它真的找不到可修的东西（很少见）。

具体操作

用 /loop 启动循环（这是 Claude Code / Fable 的命令）。

循环提示词模板：

/loop
目标：[XXX]
家规：见 house-rules.md
完成标准：[YYY，可验证的标准]

每一轮：
1. 检查当前输出离标准还差多远
2. 找出最大的那个差距
3. 修掉它
4. 起一个全新会话的子 agent 做对抗性审查（见第 4 步）
5. 如果审查通过，进入下一轮找更小的差距
6. 如果审查不通过，先修审查指出的问题

只有当我明确说“停”，或者你连续两轮找不到任何可修的差距，才停下。

图：对抗性审查循环，裁判在环外，停止权在你手里

检查点

• 循环里有“裁判”环节吗？没有的话会退化成 AI 自说自话
• 停止条件是谁定的？应该是你，不是 AI
• 每一轮聚焦“最大的差距”，而不是“随便改点啥”

第 6 步：建一个“进度页”，手机瞄一眼就知道跑到哪

这一步要解决什么

长循环最头疼的是：你怎么知道它跑到哪了？ 频繁去查会打断你自己的工作，不查又心里没底。

原作者的解法特别聪明：让 Fable 自己建一个状态页面，边干边更新。

具体操作

在循环开始时加一条指令：

另外，建一个简单的 HTML 状态页面，部署到 [某个可访问的地址]。
边干边更新它，包含：
- 当前轮次
- 最近的 5 个改动（带截图）
- 裁判最近一次审查的结果（通过/不通过 + 发现的问题）
- 离完成标准的进度（百分比或剩余差距清单）

这个页面是给我用手机随时看的，要简洁、加载快。

然后你只需要时不时用手机打开那个页面，就像看一个仪表盘。绿灯就继续忙自己的，红灯再回来介入。

为什么这个设计聪明

它把“监控 AI”这件事本身也自动化了。你不用切回终端、不用读日志、不用问“现在怎么样了”，一个页面全搞定。

而且这个页面本身就是“证据”，比你口头问 Fable“做得怎么样了”可靠得多。

检查点

• 进度页里有截图/真实输出吗？纯文字容易被 AI 美化
• 有裁判结果吗？这是最关键的进度信号
• 你能从手机访问吗？不能的话部署失败了

第 7 步：复用旧成果，让新项目站在旧作品肩膀上

这一步要解决什么

每一个你认真打磨过的高质量作品，都应该成为后续项目的“参考实现”。Fable 强到能读懂你旧的工作并复用它。

原作者的原话：

“Fable 对某件事做得越多，它就越擅长。你的旧工作，成为新工作的燃料。”

具体操作

做新项目时，别从零开始描述质量要求。指向你旧的优秀作品。

提示词模板：

我要做一个新项目：[新项目描述]。

参考实现：这是我之前做的一个 [森林场景/组件库/工具]，质量是我满意的。
代码在 [路径/链接]。

目标：匹配这个参考的质量标准，并在此基础上超越。
不要重新解释任何东西，直接读参考实现的代码，理解它的质量水平。

更进一步：让 Fable 读你旧的 session 痕迹

原作者还揭示了一个很多人不知道的能力：Fable 能读你旧的 Claude Code session 痕迹，包括你实际尝试过什么、什么有效什么没用。

所以你不用告诉它“为每个对象用单独子 agent”这种具体方法，只要说：

读我之前做森林场景时的 session 痕迹（路径：XXX）。
从里面学会什么方法有效、什么没效。
把有效的方法应用到这次的任务上。

检查点

• 你有没有一个“代表作”可以当参考？没有的话，先认真打磨一个
• 新项目开始时，指向了旧作品吗？
• 旧作品的 session 痕迹保留了吗？删了就浪费了

关键启示：认真打磨你的第一个代表作。它不是一次性产出，而是后续所有项目的地基。这是复利的起点。

第 8 步：预先清障，别让它停下来问你

这一步要解决什么

原作者有一句话非常实在：

每次 Fable 停下来问你，你就损失了时间。

Fable 跑长循环时，最容易卡在“我需要权限/凭据/许可”上。每一次停下来问你，循环就被打断一次。

具体操作：在开始前把障碍清掉

启动任何长任务前，预先把以下信息全部告诉 Fable：

清障清单：

启动前授权信息：

1. 【预算】连接 [某个付费 API] 时，预算上限是 $X，自己控制，不用每次问我。

2. 【凭据】需要的密钥都在 .env 文件里，自己读取，包括：
   - API_KEY_XXX
   - DATABASE_URL
   - 部署 token

3. 【决策权】以下决定你自己做，不用请示：
   - 选哪个库实现某个功能
   - 文件结构怎么组织
   - 测试用哪个框架

4. 【例外】只有这两种情况才停下来问我：
   - 你撞到了只有我能拍板的决策（比如业务逻辑的取舍）
   - 你尝试了多个方案都卡住，需要我的判断

唯一的例外：大事先规划

原作者只在一个场景下会主动介入，巨大、后果极重的构建。这种情况下：

这是个大项目，动手前先做两件事：
1. 给我一份完整计划，包括分几个阶段、每阶段产出
2. 把所有不确定的地方列出来，一次性问完

计划我确认后，再开始执行，执行过程中不要再停下来问。

分类原则：小事全权放手，大事先规划后放手。

检查点

• 任务开始前，凭据/密钥位置告诉 Fable 了吗？
• 付费服务的预算授权了吗？
• 哪些决策它自己做、哪些要问你，写清楚了吗？

8 步之后的进阶：两种“跑法”

做完上面 8 步，你已经能拿到 Fable 5 大部分的价值。如果你想再进一步，原作者分享了他自己的两种“高阶跑法”。

工程模式：跑一个“AI 团队”

不再是一个 Fable 干所有事，而是多个 Fable 分工协作：

你只做最高层的调度：派任务、审 PR、拍板决策。

创意模式：靠势头和细节

同样是循环 + 硬标准，但操作上：

• 把子 agent 扇出去各自打磨单件（比如森林里每种树一个子 agent）
• 同时跑多个完全独立的尝试，保留最好的，把有效的带入下一轮

创意模式不追求“一次做对”，而是“快速产生多个变体，择优进化”。

一张速查表：8 步要点

把整个教程浓缩成一张表，存手机里随时查：

常见问题

Q：我不用 Fable，用 Claude / GPT，这套方法适用吗？ 适用。这套方法的本质是“如何用好新一代强模型”。只要模型足够强（能自主推理、能跑长任务），“给目标不给步骤”这套就比老方法有效。模型越强，这套方法越有效。

Q：新手第一步从哪开始？ 从第 1 步和第 3 步开始，改掉“给步骤”的习惯，学会把“完成”写成可验证标准。这两步不花钱、立刻见效，是整套方法的入门钥匙。

Q：我担心放手后 AI 跑偏怎么办？ 这正是第 2 步（家规）和第 4 步（对抗性审查）的作用。你不是无脑放手，而是“用红线 + 独立裁判”来兜底。家规越清晰，你越敢放手。

Q：循环会不会很贵？ 会烧 token，但原作者的观点是：一个有野心的目标加一个好循环，性价比远高于你用微观管理反复沟通。而且第 8 步的“预先清障”能避免循环被打断造成的浪费。

Q：ultracode（更贵的重模式）什么时候用？ 原作者几乎从不用。只在打地基时值，也就是从零建一个会用几个月的核心系统。日常迭代、功能开发、创意实验，普通模式就够。

记不住怎么办

原作者给了一个终极偷懒办法：

把这份教程（或原指南）交给你的 Fable，告诉它：“从现在起帮我写提示词。” 它知道该怎么做。

这不是玩笑。Fable 5 强到能理解这套方法论，然后帮你应用它。

但如果只记一句话，记这条：

给目标，不给步骤；给标准，不给形容词；给信任，不给微观管理。

然后让开，看它跑。

本文基于公开指南《How I Prompt Fable》改编整理，方法、案例与引文均出自该指南。