Fable 提示词指南解读：给目标，不给步骤

最近，一份名为《How I Prompt Fable》的提示方法指南在 AI 圈被大量收藏转发。作者是 AI 领域的知名投资人，投资名单里有 Groq、OpenRouter 等基础设施公司，也曾创办并执掌一家知名的 AI 写作工具公司。指南的社交分享拿到了三万多次浏览、四百多次收藏，收藏比例明显高于一般分享，侧面说明读者普遍认为它实用。

它的核心主张只有一句话：用老方法提示新一代模型，只能得到老结果。Fable 正是这样的新一代模型，改变提示方式，改变你对「它能承担什么」的心智预期，能力的大门才会真正打开。整份指南围绕八个要点展开，下面逐一拆解。

一、给目标，不给步骤

作者认为这是最大的一个改变：不再详细规定怎么做。老模型必须把步骤写清楚，否则会跑偏；Fable 恰恰相反，你给的空间越大，它做得越好。他会把大而模糊的任务直接交给模型，就像把目标交给一个你信任的聪明人，让对方自己找最好的路。

理由很直白：你规定的每一步，都是在用自己的判断覆盖模型的判断，而多数情况下，你的判断更差。

二、设家规，让你能信任它

模糊的目标之所以可行，是因为外面围了几条不能跨越的规则。家规的定义是：无论模型怎么达成目标，这几件事必须永远为真。

作者举了自己的例子。构建 agent 时，模型爱过度工程化，动不动写一堆正则过滤器去抓特例，而他真正想要的是把期望行为写进系统提示词，让模型自己推理。于是他的固定家规之一是：别硬编码特例，把想要的写进系统提示词。再加一道保险：永远安排一个子 agent，在推送任何东西之前对照家规逐条检查。

三、给完成一个真正的标准

只说「做高质量」，模型会停在它自己认为够好的位置，而那个位置通常低于你的标准。所以作者不用形容词，他给的是可自查的标准，而且故意定得很高。有时他自己写测试，比如「陌生人分不出渲染结果和真实照片」；有时连他也不知道怎么衡量想要的东西，那就把「怎么衡量」这个问题一并交给模型。

指南里最有说服力的案例，是一位朋友克隆组件库：第一次失败了，问题有两个。一是在 ShadCN 之上改，处处跟它的约定打架；二是只说「克隆这个」，没有定义什么叫完成。他们最后扔掉 ShadCN 从零开始，并让模型自己发明尺子：Fable 录制真实组件的使用过程，转成运动热力图，然后反复迭代，直到自己的版本与原版匹配。全程没人告诉它怎么做，只告诉它「完成」意味着什么。

这里还有一条铁律：做东西的那个 agent 永远不能给自己打分。构建者有偏见，总有一套「我为什么这么决策」的说辞来自证完成。正确做法是另起一个全新上下文的子 agent，指向真实输出，让它专门试图证明这个东西不达标。

四、让它循环，直到达标

有了标准，就把模型放进循环里去撞标准：构建、自检、找最大差距、补上、再来一轮，持续几个小时甚至几天。作者常用 /loop 这类循环指令，尤其在创意工作上。

循环的全部意义在于：模型永远不能自己宣布完成，永远存在下一个差距。什么时候停，要么你说了算，要么它真的找不到可修的东西，后者很少见。

一个实用技巧：让 Fable 顺手做一个简单的进度页部署出去，边干边更新截图和笔记，你用手机瞄一眼就知道进展，什么都不用碰。

五、让它在已有成果上构建

Fable 对某类事做得越多就越擅长，前提是旧成果还在。作者的说法是：旧工作是新工作的燃料。

他做的第一个 3D 场景花了很多心思，因为没有参考点。一旦有了一个出色的 3D 森林，后面就快了：做另一个大型场景 demo 时，他直接指向森林，这是代码，这是质量标准，匹配并超越，不用重新解释任何东西。更进一步，模型还能读过去的会话痕迹，了解实际尝试过什么、什么有效、什么没用。所以他不用解释方法，一句「读森林的痕迹，学会什么有效」就够了。

六、让开道，别频繁打断

模型每次停下来问你，都在损失时间。所以要提前清障：接付费服务时，直接给预算，而不是让它每次都来请求许可；告诉它密钥和凭据在哪；白纸黑字授权它自己拍板，只有真正卡住、或撞到只有你能定的决策时才回来。

唯一的例外是规划，而且仅限巨大、后果极重的构建：动手之前先要计划，让它把所有不确定的问题问完。计划定了，它就不停地跑。

七、工程跑团队，创意靠势头

工程上，作者跑的是一个团队：几个 Fable 会话同时工作，从任务列表里拉任务；每个会话完成任务后，用子 agent 做三重检查，再开一个附带证据的 PR；另有一个专门的会话负责集成，合并 PR、把一切跑起来、像真实用户一样测试、保持整体绿色。两个功能可能重叠时，就让一个会话盯着另一个的痕迹，保持兼容。

创意上，靠的是势头和细节：同样的循环、同样硬的标准，但把子 agent 扇出去各自打磨单件，比如森林里每一种树交给一个子 agent；有时还会同时跑几个完全独立的尝试，保留最好的一个，把有效的部分带进下一轮。

八、ultracode 只用在打地基

ultracode 是更贵、更重的使用模式，作者几乎不用：一个好的循环加上足够有野心的目标，不用它也能达标。它值回成本的地方只有一个：地基。如果要从零建一个会维护几个月、可能成为业务核心或代码库核心的系统，就要在第一天把地基打对。这也正是前面扔掉 ShadCN 的原因：好地基让你上面的一切都更容易，坏地基让你接下来永远更难。只有这类工作，多花的钱才值得。

结尾的钥匙

指南的最后给了一个收尾技巧：这些要点记不住也没关系，把整篇指南交给你的 Fable，告诉它从现在起帮你写提示词，它知道该怎么做。

整份指南归结起来是三句话：不喂给它嚼碎的东西；给它一个无法靠说辞逃脱的标准；让它在你已有的一切上继续构建。模型大家都一样，结果不同，差别全在这三件事上。

来源说明

本文是对公开指南《How I Prompt Fable》的解读整理，原文于 2026 年 7 月发布在作者的个人公开文档页（simplemarkdowneditor.com），并同步分享于其社交账号；文中的方法、案例与引述均来自该指南，浏览与收藏数据为分享时的统计。本站此前已发布基于同一指南整理的实操教程《Fable 5 实战教程：8 步从「能用」到「惊艳」》，偏重可直接照做的步骤与模板；本文侧重方法背后的逻辑与案例，可对照阅读。