Send this link to your agent, and it’ll help you prompt!把这个链接发给你的 Agent，它就知道该怎么写提示词了。
Every time I show something I built with Fable, I get the same questions. “I can’t get results like this.” “How did you do that?” “There’s no way that’s real.”每次我展示用 Fable 做出来的东西，大家问的都是那几句：“我怎么做不出这种效果？”“你是怎么做到的？”“这不可能是真的吧。”
And people assume each one came out of some insanely complicated prompt, or that it took way more work than it actually did. It’s usually the opposite. The demos are simpler than they look. I’m just using the model differently than most people are.人们总觉得这些东西背后藏着什么极其复杂的提示词，或者我付出了巨大的劳动。其实正好相反。这些演示比看着简单得多。我只是用模型的方法和别人不一样。
Fable is a real next-generation model. Prompt it the way you prompt the current ones and you’ll get results like the current ones. Change how you prompt it, and how you think about what it can take on, and the door really opens.Fable 确实是新一代的模型。如果你还按老一套去写提示词，那出来的结果也就跟老模型差不多。换个思路，重新审视一下它能干什么，路子自然就宽了。
Here’s how I actually do it.我是这么做的。
Give it the goal, not the steps给它目标，别给它步骤
The biggest change is that I stopped spelling out how to do things. With older models you had to specify how to do something, or they’d often wander off. Fable is the opposite. The more room you give it, the better it does.最大的改变是我不再事无巨细地交代怎么做。以前用老模型，你得把步骤写得清清楚楚，不然它就跑偏了。Fable 正好相反，你给它留的空间越大，它干得越好。
So I hand it big, sweeping, underspecified work; the way you’d hand a goal to a brilliant person you trust and let them find the best way there. Except Fable is often better at figuring out the “how” than I am. Every step I dictate is just me overriding its judgment with mine, and mine is usually worse.所以我只给它一个宏大、模糊的目标，就像你把任务交给一个信得过的聪明人，让他们自己去找最好的路径。而且 Fable 在寻找“怎么做”这件事上，往往比我更在行。我每多写一个步骤，其实都是在用我那点有限的判断力去干预它，而我的判断力通常还不如它。
That feels risky at first, when you’re used to controlling the details. What makes it safe is the next part.习惯了掌控细节的人，刚开始会觉得这事儿挺悬。但只要做好下一步，这就很安全。
Set house rules so you can trust it立好规矩，才能放心
An underspecified goal works when you fence it with a few rules it can’t cross. House rules are the handful of things you always want to be true, no matter how Fable gets to the goal.目标可以模糊，但必须得有几条不能逾越的红线。这些规矩就是你无论如何都想守住的底线，不管 Fable 用什么法子达到目标，都得遵守。
For example, when I’m building an agent, models love to over-engineer. They’ll reach for a regex filter to catch some specific case, when what I actually want is a prompt that describes the behavior and lets the model handle it. So one of my standing rules is basically: don’t hard-code special cases, describe what you want in the agent’s system prompt and let the agent reason.举个例子，我在写 Agent 的时候，模型总喜欢过度设计。它们爱用正则过滤来处理特殊情况，但我真正想要的是在系统提示词里描述好行为逻辑，让模型自己去判断。所以我的硬性规定之一就是：别把特殊情况写死在代码里，在系统提示词里写清楚逻辑，让 Agent 自己去推理。
And for extra protection, you can have Fable always hand a sub-agent one job: check the work against the house rules before anything is pushed. Now you can let Fable run wide open on the goal and still know it won’t ship something that breaks the things you care about.为了加层保险，你还可以让 Fable 专门派一个子 Agent 处理一件事：在任何东西发布之前，先检查它是否符合规矩。现在你可以放手让 Fable 去冲目标，同时确信它不会搞出什么破坏底线的东西。
Give it a real bar for “done”给“完成”设一个硬标准
If you tell Fable to make something “high quality,” it stops at its own idea of good enough, which is usually lower than yours. So I don’t use adjectives. I give it a bar it can check itself against, and I make that bar hard.如果你告诉 Fable 要“高质量”，它就会按它自己觉得“差不多就行”的标准停下来，而那个标准通常比你的低。所以我不用形容词。我给它一个它自己能验证的硬指标，而且这个指标定得很高。
Sometimes I write the test myself… something concrete, like “a stranger can’t tell our render from the real photo.” Other times I don’t even know how to measure the thing I want, so I hand that problem to Fable too.有时候我自己写测试用例，写得具体点，比如“让外行看不出这是渲染图还是真照片”。有时候我连怎么衡量都不知道，那就把这个问题也扔给 Fable。
For example, a friend was trying to clone a component library and was getting nowhere. Two things were wrong. First, he was building on top of ShadCN and trying to clone the components off of ShadCN, so Fable was fighting all of ShadCN’s conventions instead of just building the components. And second, he had no way to say when it was done. He was just telling it “clone this.”有个朋友想克隆一个组件库，一直没进展。原因有二。第一，他是在 ShadCN 之上构建的，试图从 ShadCN 克隆组件，结果 Fable 总是被 ShadCN 的那一套规矩束缚，而不是直接去写组件。第二，他没法定义什么时候算“完成”。他只是告诉它“克隆这个”。
So we did two things. We threw out ShadCN and started from scratch, because a component library is completely buildable from nothing and the existing code was just baggage. Then, since neither of us knew how to measure “does this match the original,” we asked Fable to figure it out. It took a screen recording of the real components in use, turned it into a heat map of where everything moved, and kept working until its version matched. We never told it how to do that. We told it what “done” meant and let it invent the measuring stick.于是我们做了两件事。我们扔掉了 ShadCN，从零开始，因为组件库完全可以从无到有地建起来，现成的代码反而是累赘。接着，既然我们俩都不知道怎么衡量“这东西是否和原版一致”，我们就让 Fable 自己去想办法。它录了一段原版组件的屏幕操作，转成热力图来对比移动轨迹，然后一直改，直到它的版本和原版对得上。我们从没教过它怎么做，我们只是定义了什么叫“完成”，然后让它自己发明了衡量标准。
One rule I never break here: whatever builds something never gets to grade it (the ‘build’ agent is often biased, and has a whole trajectory of ‘why I made these decisions’ that it can use to justify that it’s done the job). I always have it spin up a separate Fable sub-agent with a fresh context window, point it at the real output (the actual pixels, the actual running app, etc.) and have it try to prove the thing is not passing.这里我有个绝不打破的规矩：负责构建的 Agent 绝不能负责验收（因为构建 Agent 往往有偏见，它有一套“我为什么要这么做”的辩解逻辑，能证明自己已经干完了）。我总是会启动一个新的 Fable 子 Agent，给它一个全新的上下文窗口，让它对着实际产出（像素、运行中的应用等）去挑毛病，试图证明这东西不合格。
Loop it until it hits the bar (especially for creative tasks)循环迭代，直到达标（特别是做创意工作时）
Once there’s a bar, I put Fable on a loop against it and let it go. It builds, checks itself, finds the biggest gap, closes it, and goes again… for hours, sometimes days. I use /loop for this constantly, especially on creative work, where there’s always something concrete to keep measuring against until it’s actually there.只要有了标准，我就让 Fable 循环去跑。它构建、自检、找差距、修补，再来一遍……有时一跑就是几个小时甚至几天。我经常用 /loop，特别是在做创意工作时，总能找到具体的指标去衡量，直到它真正达标。
The whole point of the loop is that Fable never gets to decide it’s finished. There’s always a next gap. It stops when I say it’s done, or when it genuinely can’t find anything left to fix (which is rare, if you’ve set this up right).循环的意义在于，Fable 永远没有权利说“我干完了”。总有下一个差距需要弥补。它要么等我说停，要么就是实在找不出还有什么能改的（如果你设置得当，这种情况很少见）。
One trick I use on every long run: I have Fable post its progress to Simple Markdown Editor (this site! it’s a Markdown editor that supports images, videos, html, and anything else, and is built agent-first). As it works, it keeps the doc updated with screenshots, notes, whatever shows where things stand. Then I can glance at my phone and see exactly how far along it is, and I can add comments anytime I want to adjust the agent’s direction.长任务中我有个小技巧：让 Fable 把进展发到 Simple Markdown Editor（就是这个网站！它支持图片、视频、HTML 等，而且是为 Agent 设计的）。它边干边更新文档，贴截图、写笔记，记录当前进度。我随时看一眼手机就知道它干到哪了，想调整方向随时可以加评论。
Another way I use the editor: it works as a shared workspace when I’m running multiple Fables at once. Simple Markdown Editor has a built-in Trello-style board and a Slack-like chat component, so the agents can post tasks for each other, claim them, ask questions, and flag conflicts. When a team of them is working on the same codebase, that one document becomes the coordination layer, and I can watch (or jump into) the whole conversation.我还把这个编辑器当作共享工作区，同时运行多个 Fable。Simple Markdown Editor 有内置的 Trello 式看板和类似 Slack 的聊天组件，Agent 可以在里面发布任务、认领、提问、标记冲突。当一个团队在同一个代码库工作时，这个文档就成了协调层，我可以随时围观或者插手整个对话。
Let it build on what you’ve already done让它基于你已有的成果去构建
Fable gets better at something the more of it you’ve already done, so your old work becomes fuel for the new work.你做得越多，Fable 就越擅长。你的旧工作就是新工作的燃料。
The first real thing I built when Fable came out was a photorealistic 3D forest. I wrote that prompt more carefully than almost anything since, because I had no reference point… no example of the quality I wanted, no idea yet how to get there. It took real work to get the initial prompt right.Fable 刚出来时，我做的第一个像样的东西是一个照片级的 3D 森林。那个提示词我写得格外小心，因为当时没有参照物，不知道想要的效果是什么样，也不知道该怎么做。写好那个初始提示词确实费了番功夫。
But once I had one great 3D scene, everything after it got easier. When I built the Hogwarts demo, I could just point Fable at the forest: here’s the code, here’s the quality bar, match this and go beyond it. I didn’t have to re-explain any of it.但一旦有了第一个出色的 3D 场景，后面的事就简单多了。做霍格沃茨演示时，我直接把森林指给 Fable 看：这是代码，这是质量标准，照着这个做，再好一点。我根本不需要重新解释任何细节。
It goes further than reusing code. Fable can read the traces of my old Claude Code sessions… what it actually tried while building the forest, what worked and what didn’t. So instead of telling it “use a separate sub-agent for each object in the scene,” I can just say “read the forest traces and learn what worked.” It picks up the approach on its own. Hogwarts came together far faster than the forest, mostly because of that.这不仅仅是复用代码。Fable 能读取我以前 Claude Code 会话的痕迹，看看它在做森林时尝试过什么，什么管用，什么不管用。所以我不必告诉它“给场景里的每个对象都分配一个子 Agent”，我只需要说“读一下森林任务的记录，学学什么管用”。它自己就能领悟方法。霍格沃茨做得比森林快得多，主要就是因为这个。
Get out of its way别挡它的路
Every time Fable has to stop and ask you something, you’ve lost time. So I clear the obstacles up front. For example, if I’m connecting it to a real-world service that costs money, I’ll give it a budget instead of making it ask permission for every use. I tell it where the keys and credentials live. And I tell it, in writing, to make its own calls and only come back to me if it’s truly blocked or hits something only I can decide.Fable 每停下来问你一次，你都在浪费时间。所以我提前扫清障碍。比如，如果我要连接一个要花钱的外部服务，我会给它一个预算，而不是让它每次用都来请示。我告诉它密钥和凭证在哪。我也书面告知它，自己去调用接口，除非真的卡住了或者遇到只有我能决定的事，否则别来找我。
The one exception is planning (but only for huge, extremely consequential things). On a really big build I want the plan before any code, and I want it to ask me everything it’s unsure about up front. Once the plan is settled, it runs without stopping.唯一的例外是规划（仅限于非常宏大、后果严重的事情）。在大工程开始前，我需要先看到计划，并要求它把所有不确定的地方提前问清楚。一旦计划定下来，它就该自己跑，别停。
Two ways I run this我用这套方法的两种场景
Everything above is the same whether I’m shipping features or building a world (or anything else creative). What changes is the setup around it.无论是在开发功能还是构建世界（或者其他任何创意工作），上述逻辑都是一样的。变的只是外围的设置。
For engineering, I run a team. Several Fable sessions working at once, pulling tasks from wherever… a list, a Linear board, the Trello-style board in Simple Markdown Editor, or I just hand them out. Each one does its task, triple-checks its own work with sub-agents, and opens a PR with the evidence I mentioned. Then one more Fable does nothing but integrate: it merges the PRs, runs everything, tests like a real user, and keeps the whole thing green. When two features overlap, I tell one Fable to watch the other’s traces as it’s being built and stay compatible… they’re working in parallel, so they can coordinate in the doc’s chat… one keeps an eye on the other, flags conflicts as they come up, and integrates as it lands.工程开发时，我组建一个团队。同时运行多个 Fable 会话，从任务列表、Linear 看板或者 Simple Markdown Editor 的看板里领任务。每个 Agent 完成任务后，用子 Agent 三重自检，然后提交 PR 并附上证据。最后再由一个 Fable 专门负责集成：合并 PR、运行测试、像真实用户一样操作，确保整个系统不出错。如果两个功能有冲突，我就告诉一个 Fable 去盯着另一个的构建记录，保持兼容。它们并行工作，在文档的聊天区里协调，互相盯着，有冲突随时标记，随时集成。
For creative work, I lean on momentum and detail. Same loop, same hard bar, but I usually fan out sub-agents to nail the individual pieces instead of making one Fable do all of it… a separate sub-agent perfecting each kind of tree in a forest, say. Sometimes I’ll run a few completely separate attempts at once, keep the best one, and carry what worked into the next round.创意工作时，我更看重节奏和细节。还是同样的循环和硬标准，但我通常会拆分出多个子 Agent 来打磨各个部分，而不是让一个 Fable 包揽一切。比如，让一个子 Agent 专门去优化森林里的树。有时我会同时跑几个完全不同的方案，留最好的那个，把成功的经验带到下一轮。
You can mix these however you want. It depends on what you’re building.你可以随意组合这些方法，全看你在做什么。
When to spend on ultracode什么时候该用 ultracode
There’s a heavier mode called ultracode that costs a lot more. I almost never use it. A good loop with an ambitious enough goal gets me there without it.有一种更重的模式叫 ultracode，费用高得多。我几乎不用。只要目标够明确，循环迭代足够好，普通模式就够了。
Where it earns its cost is foundations. If I’m building a new system from scratch that I’ll be working on for months (for example, something that becomes the core of a business or a codebase), I want the base right from day one. It’s the same reason we threw out ShadCN: a good foundation makes everything you build on top of it easier, and a bad one makes everything harder forever. For that kind of work, and pretty much only that kind, the extra cost is worth it.只有在打地基的时候，它才值回票价。如果我要从零开始构建一个要维护好几个月的系统（比如业务核心或基础代码库），我第一天就得把底子打好。这就好比为什么要扔掉 ShadCN：好的基础让后续构建事半功倍，坏的基础则会让你永远痛苦。对于这种工作，也基本只有这种工作，多花点钱是值得的。
One more thing最后一点
If this is a lot to hold in your head, you don’t have to. Hand this whole article to your Fable and tell it to help you write your prompts from here on. It’ll know what to do with it.如果这些东西记不住也没关系。把整篇文章扔给你的 Fable，让它以后帮你写提示词。它自然知道该怎么做。
None of this is complicated. It’s the same model everyone has. My results look different because I don’t spoon-feed it, I hold it to a bar it can’t talk its way out of, and I let it build on everything it’s already made. Start there.这些都没什么复杂的。大家用的都是同一个模型。我的结果之所以不同，是因为我不喂饭，我用它无法推脱的硬标准去要求它，并且让它在已有的成果上不断迭代。从这开始吧。