本文经原作者授权转载，版权归原作者所有。原作者：小互（@xiaohu）。
Anthropic 上了新模型 Claude Fable 5，是现在能用到的最强的一个，专门用来接以前接不住的长活、难活。
Anthropic 同步发布了一份官方提示词工程指南：Fable 5 的能力跃升太大，旧的提示词和编排架构会拖后腿，你需要重新学怎么用它。
但其实官方指导总结下来很简单就是：让你先删提示词！
- Fable 5 能持续多天执行目标导向任务，单次请求在高 effort 下可运行数分钟，自主运行可达数小时
- 指令遵循能力强到不再需要逐条列举禁止行为，一条简短指令就能引导大多数行为
- 旧模型的提示词对 Fable 5 来说往往"过于规范化"，反而降低输出质量，官方建议做减法
- 新增 effort 分级控制（low/medium/high/xhigh），Fable 5 的 low 可能就超过旧模型的 xhigh
- 并行子代理调度成为一等能力，模型会主动分派并行任务
下面我把这份指南，挑出真正影响你怎么用它的几块说说：它强在哪、两个得你主动喂的新能力、effort 怎么调、一份按档位算账的省钱指南、它新冒出来的几个脾气怎么治（带能直接抄的提示词）、迁移要避哪些坑。
看你怎么用 Claude，各取所需。
先说为什么强了反而要删提示词
打个你熟的比方。
新来的实习生，你得把话说死：第一步干嘛、第二步干嘛、碰到这种情况怎么办、那种情况别碰。
不是他笨，是他没经验，你不写清楚他真会出岔子。
但同一张事无巨细的清单，拿去管一个干了十年的老手，会怎样？他本来凭经验就能把事办得漂亮，结果被这张清单捆住手脚，照着那些其实不太高明的规矩来，活儿反而干差了。
你给 AI 写的那些提示词，大多是当年伺候实习生攒下来的。
模型不够聪明的时候，你得一条条堵住它可能犯的错。Fable 5 的意思是，它已经是那个老手了，你那摞老规矩现在是绑手绑脚。
官方原话是，为旧模型写的规则对它来说常常管得太细，反而把输出质量拉低。
这条我自己的体感能印证。
昨天我测试的这个案例就是很简单的提示：帮我制作一个详细介绍黑洞是如何诞生的超炫酷动画页面。
它到底强在哪，值不值得你折腾
官方在讲技巧之前，先列了七项能力提升。挑你能直接感觉到的说：
- **长任务不忘事：**它能连着干好几天的目标任务，跨多天从头记到尾，不像老模型干到后面把你最初的要求丢了。
- 经常一遍就做对： 早期试用的人说，以前要来回返工好几天才跑通的系统，它单次就实现了。不是说它从不出错，是只要你把要求讲清楚，一把过的概率高了很多。
- 自己看图、自己查问题： 给它糊的、歪的截图，它自己想办法处理，还被专门训练过用工具裁剪图片；查老问题能翻代码的历史记录，定位到是哪次改动埋的雷。
- 找 bug 更准： 在安全限制之外的领域，它翻代码、翻仓库历史揪 bug 的能力，明显比上一代 Opus 4.8 高。
- 自己带一队分身： 它能把一个大活拆开，派给好几个子代理同时干，自己当调度的工头，还盯着每个分身的进度。
除了这几项，它几乎在所有任务上都比旧模型强。
一个实用建议是，别只拿简单活去测它，那样会低估它的上限；把你手头最难、最久、还没解开的问题丢给它，才看得出它到底能干到哪。
两个最值钱的新能力，得你主动喂
Fable 5 真正比上一代强一大截的地方，但你不主动给，它发挥不出来。
第一个，放手让它派一队分身。 它能当工头，但你得明确告诉它“可以多派分身、各干各的、别干等着一个个回来”，它才放得开。
Delegate independent subtasks to subagents and keep working while they run. Intervene if a subagent goes off track or is missing relevant context.
把相互独立的子任务派给子代理，它们跑的时候你接着干自己的。某个子代理跑偏了，或者缺了相关上下文，再去干预。
让分身长期留着、跨任务保留上下文，还能省缓存、不卡在最慢那个上。这个能力还能直接变成省钱手段，后面「省钱指南」一节有完整玩法。
第二个，给它一个记事本。
给它一个地方记笔记，简单到一个文本文件就行，让它把每次踩的坑、确认有效的做法记下来，下次翻出来用，它会越用越顺。
官方给的记笔记规矩是这样：
Store one lesson per file with a one-line summary at the top. Record corrections and confirmed approaches alike, including why they mattered. Don't save what the repo or chat history already records; update an existing note rather than creating a duplicate; delete notes that turn out to be wrong.
一个文件只存一条经验，顶上写一句话摘要。纠正和确认有效的做法都要记，连同它们为什么重要。仓库或聊天记录里已经有的别存；同一件事更新那条已有的笔记，别新建一条重复的；后来发现记错的，删掉。
这几条跟我自己给 Claude 配的记忆系统几乎一字不差。
我那套也是一个文件一条、顶上一句摘要、记纠正也记确认、都写明为什么、重复的更新不新建、错的直接删。我搭它的时候没参考任何标准，是自己踩着坑一条条补出来的土办法。
现在看到官方把同样的规矩写进指南，我的判断是：这份指南不只是教你用新模型，更像是官方把一批重度用户摸出来的土办法，收编成了标准。模型越能自己记事、自己复盘，“记忆该怎么管”这点功夫就越值钱。
还有个小习惯，省事又好用：交代任务时，把“为什么要这么做”也一起说了，别光丢一句命令。它懂了你的目的，自己就能把事跟相关信息对上，不用瞎猜。套个模板：
I'm working on [the larger task] for [who it's for]. They need [what the output enables]. With that in mind: [request].
我在做[更大的任务]，是给[谁]用的，他们需要[这个产出能带来什么]。基于这个背景：[具体请求]。
effort：Fable 5 上最重要的那个旋钮
这是这代最该先搞懂的一个参数。effort 控制的是模型的智力、速度、成本三者怎么权衡，分四档：low、medium、high、xhigh。
官方的建议是：大多数任务用 high 当默认，最吃能力的硬活用 xhigh，日常杂活用 medium 或 low。
Fable 5 的低档，比Opus旧模型拉满的 xhigh 还强。
所以别习惯性把它顶到最高，那既慢又贵。任务能做完但花的时间比该花的长，或者你想要更快、更能来回聊的节奏，就往下降档。
怎么配：
Fable 5 省钱指南：单价贵一倍，账单可能更便宜
Claude Fable 5 的 token 单价是 Opus 4.8 的两倍（输入 $10/M，输出 $50/M），但多个实测数据显示，因为模型更聪明、完成同一任务用的 token 更少，最终账单在复杂任务上反而可能更低。省钱的底层逻辑不是“少想”，而是“少犯错”。
先看数据：Fable 5 Low 档 vs Opus 4.8 Max 档
下面这组数据来自第三方代码基准测试，这组对比是省钱策略最直接的证据：
这背后的逻辑，Claude Code 之父 Boris Cherny 称：以前不够聪明的模型，写错了改、跑挂了重跑，每一轮都在烧 token。Fable 5 单任务 token 更少、纠错动作更少，实际上消耗的token更少，砍掉的就是这部分隐性成本。
策略一：日常任务直接开 Low 档
Fable 5 Low 档的 64.2% 得分，已经超过了榜单上除 Fable 自己以外的几乎所有模型配置，包括 Opus 4.7 Max（64.8%，但成本 $11.02）、GPT-5.5 Extra High（64.3%，成本 $4.37）、Opus 4.8 Extra High（62.1%）。
适用场景：代码编写、调试、日常开发。不是每个任务都需要模型全力思考，Low 档就够了。
策略二：要更高质量，Medium 是性价比甜区
Fable 5 各档位的成本收益曲线：
从 Low 到 Medium，多花 $2.57 换了 5.6 个百分点，性价比最高。从 Medium 往上，每多花一块钱换来的分数增幅越来越小。High 到 Max 之间多花了 $7.21，只多拿了 2.3 个百分点。
Medium 档的 69.8% 已经超过了榜单上所有非 Fable 的模型配置。对大多数任务来说，这就是天花板了。
策略三：复杂项目让 Fable 当指挥，Opus/Sonnet 干活
有人分享了一个更牛P、更省Token的玩法，那就是：用 Dynamic Workflow 模式，让 Fable 做编排器（orchestrator）负责理解需求、拆任务、做决策，把实际写代码、跑测试的执行层交给 Opus 或 Sonnet。
具体配置三步：
- 主模型设成 Fable 5
- effort 开到 Max（最大推理深度）
- 让 Claude 跑一个 Dynamic Workflow（动态工作流）：Fable 当编排器只管想清楚做什么，Opus 当执行层负责写代码、调试、分析
Fable 5 的核心优势是判断力和调度能力——前面「派一队分身」讲的就是这个，不需要用它的算力写每一行代码。就像公司请了一个年薪两百万的 CTO，不会让他天天写 CSS，让他定架构做决策就行了，写代码的活交给工程师团队。
适用场景：大型项目、多步骤工程任务、需要长时间运行的代理工作流。
选档速查表
两个注意事项
安全分类器会自动降级。 涉及网安、生化、模型蒸馏等敏感请求时，系统自动切到 Opus 4.8 回答，按 Opus 价格计费。Anthropic 说触发率不到 5% 的会话。
限时免费窗口。 6 月 22 日之前，Pro、Max、Team 及按席位计费的企业版用户可以直接使用 Fable 5。6 月 23 日起开始消耗用量积分。使用 Fable 5 需要开启 30 天数据保留。
它的几个新脾气，逐个治（带能抄的提示词）
模型变强是有代价的：它会自作主张、用力过猛，长时间跑还冒出几个怪毛病。这份指南大半篇幅都在讲这个，也是对你最实用的部分。
下面每段提示词，我都给了英文原文和中文版两个方框，抄英文或抄中文都行、效果一样；只想了解意思的，看中文那段就够。
1. 它默认跑很久，你的“等待方式”得改
一个难活它能跑好几分钟，全自动能跑好几个钟头。你的程序要是还按“几秒钟必回”设计的，会误以为它卡死了。治法：把超时放宽、给用户加进度提示，更聪明的是别干等，像交代完事就去忙别的、过会儿回来看一眼。
另外任务说得含糊时，它容易在那儿反复盘算。加这条让它信息够了就动手：
[text] When you have enough information to act, act. Do not re-derive facts already established in the conversation, re-litigate a decision the user has already made, or narrate options you will not pursue in user-facing messages. If you are weighing a choice, give a recommendation, not an exhaustive survey. This does not apply to thinking blocks.
[text] 信息足够就动手。不要重复推导对话里已经确认过的事实，不要再争论用户已经拍板的决定，也不要在给用户看的消息里罗列你不会采用的选项。如果你在权衡，就直接给一个建议，而不是把所有可能都铺一遍。本条不适用于思考过程。
2. 它太勤快，会干你没让它干的事
高 effort 下它爱顺手“打扫卫生”：修个 bug 顺带重构、一次性的操作非要写个 helper、给不可能发生的情况加一堆容错。一条按住它别过度收拾：
Don't add features, refactor, or introduce abstractions beyond what the task requires. A bug fix doesn't need surrounding cleanup and a one-shot operation usually doesn't need a helper. Don't design for hypothetical future requirements: do the simplest thing that works well. Avoid premature abstraction and half-finished implementations. Don't add error handling, fallbacks, or validation for scenarios that cannot happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use feature flags or backwards-compatibility shims when you can just change the code.
不要添加任务没要求的功能、重构或抽象。修一个 bug 不需要顺手清理周边代码，一次性的操作通常也不用单写一个辅助函数。不要为假想的未来需求做设计，用最简单、能跑好的办法就行。避免过早抽象和半成品实现。不要为不可能发生的情况加错误处理、兜底或校验。信任内部代码和框架本身的保证，只在系统边界（用户输入、外部接口）做校验。能直接改代码的地方，别用功能开关或向后兼容的垫片。
还有一种是你只想听它分析、没让它动手，它直接上手改了。一条划清边界，让它先给判断、别急着改：
When the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one. Before running a command that changes system state (restarts, deletes, config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.
当用户是在描述问题、提问、或者出声思考，而不是要求你动手改时，你要交付的是你的判断。给出结论就停下，别等他们开口就先去改。在执行任何会改变系统状态的命令（重启、删除、改配置）之前，先确认证据确实支持这个具体动作。一个看着像某种已知故障的信号，背后原因可能完全不同。
3. 一句话，能顶你过去一页的规则
这是“做减法”最直接的地方。它现在听话到你不用再一条条列禁止项，一句简短指令就能管住一类行为。
比如想让它说话简洁、别绕，一句就够，不用把“不许这样、不许那样”列一长串：
Lead with the outcome. Your first sentence after finishing should answer "what happened" or "what did you find": the thing the user would ask for if they said "just give me the TLDR." Supporting detail and reasoning come after. Being readable and being concise are different things, and readability matters more.
先说结论。做完之后的第一句话，要回答“发生了什么”或“你发现了什么”，也就是用户说“直接给我结论”时想要的那句。佐证和推理放在后面。可读和简短是两回事，可读更重要。
想管它“什么时候才该停下来问你”，也一句话，不用把情况列全：
Pause for the user only when the work genuinely requires them: a destructive or irreversible action, a real scope change, or input that only they can provide. If you hit one of these, ask and end the turn, rather than ending on a promise.
只在工作真正需要用户介入时才停下来问：一个有破坏性或不可逆的动作、一次真正的范围变更、或者只有他们能提供的信息。碰到这几种情况，就提问并结束这一轮，而不是停在一句空承诺上。
你去翻翻老提示词：很多当时你逐条写的限制，现在一句话能替，还更不容易自相矛盾。
4. 长时间跑，它会“虚报进度”
让它自主跑，它报“完成八成”，你一看才四成。它不是存心骗你，是照着计划报、没照着实际结果报。让它每报一条进度，都对一下真实的运行结果，官方说这条基本把虚报摁住了：
Before reporting progress, audit each claim against a tool result from this session. Only report work you can point to evidence for; if something is not yet verified, say so explicitly. Report outcomes faithfully: if tests fail, say so with the output; if a step was skipped, say that; when something is done and verified, state it plainly without hedging.
报告进度之前，把每一条说法都对照这次会话里的工具结果核一遍。只报你拿得出证据的工作；还没验证的，就明说没验证。如实汇报结果：测试挂了就把输出贴出来说挂了，跳过了某步就说跳过了，确实做完并验证过的，就干脆说做完了，别含糊其辞。
5. 它偶尔会“话说一半就停”和“怕篇幅不够”
跑到很深的地方，它会说一句“我现在去跑 X”然后就停了，那动作根本没做；或者信息明明够了，还停下来问你要不要继续。大多时候你回个“继续”就过去了。没人盯着的全自动流程，给它一段说明，让它该自己往下推就推、别老停下来请示。
还有一种，是它看到“还剩多少字数额度”的倒计时会发慌，突然说“要不开个新会话”，或者自己把活儿缩水。治法很简单：别把那个倒计时给它看。非给不可，就补一句“上下文还很充足，别停、别总结、别提议开新会话，接着干”。
迁移之前，这几个坑先避开
- “让它复述思考”的指令，先清掉： 如果你的老提示词里有“把你的思考过程写出来给我看”“解释一下你是怎么想的”这类要求，到了 Fable 5 会触发它的一条拒绝规则，结果是大量请求被打回、退到旧模型去处理。迁移前一定回去翻一遍清干净。真想看它怎么想的，官方有别的接口可以读，别硬让它在回答里复述。
- 它会拒绝一些请求，这是设计如此： 碰到攻击性网络安全（造病毒、攻击工具那种）、生物和生命科学这两类内容，它会直接拒，正经的安全防御、有益的生物研究也可能被误伤。被拒不算报错，是一次正常的成功响应、还带着是哪条分类器拦的，而且产出之前不计费。解法是配个备胎：被拒的请求自动转给上一代的 Opus 4.8 接手。
- 老技能可能太啰嗦： 为旧模型写的技能，对 Fable 5 往往管得太细，反而拉低质量。迁移时把旧指令审一遍，那些删掉之后它默认表现更好的，就删。
除了上面三条，官方脚手架建议里还有两条前文没展开的，一并列上：
说到底：从管教到放手
以前调 AI，琢磨的是怎么把话跟它说清楚。那是一种管教：预判它会在哪犯错，提前堵上；把不许做的事列成清单；把步骤拆细到它走不偏。功夫全花在“过程”上。
Fable 5 这代，琢磨的变成了怎么给它搭一个能放手干活的环境：给够空间让它自己拆活、自己跑；把真正不能碰的边界划死；配上能调度的分身、能记事的本子，剩下的交给它。功夫从“过程”挪到了“边界”。
注意一点：放手不等于放任。
你回头看上面那些脾气，它们都是放手之后冒出来的代价，不是模型变差。治法也都不是退回去重新事无巨细地管，而是把该划死的边界划死。管得越少它干得越好，前提是该划的边界你得划死。这两句不打架，是一体的。
最后，看你怎么用 Claude，对号入座：
- 只拿它聊天、查东西、写文案的： 不用动什么，知道新模型更能扛复杂长活就行。手头要真有个又难又长、以前嫌它做不利索的活，拿 Fable 5 试一次，这回说不定一把就做完。
- 做内容、做自动化的创作者和小团队： 回去把你给 AI 写的提示词翻一遍，当年为防它犯错写的，该删的删（尤其“让它复述思考”那类，会触发拒绝）。再挑一个你平时最烦、最想甩手的长流程，让它自己拆步骤、自己跑。
- 正经搭代理、写程序的： 上面方框里的原话直接抄进系统提示，下一节的速查卡可以当对症索引。再给它配上分身调度和记事本，这是它这代最值钱、又最得你主动给的两个能力。
十个调优模式速查卡
官方指南把这些场景归纳成十个调优模式。前面各节其实都讲透了，这里压成一张卡，给只想快速对症、抄提示词的人：
卡里有两条提示词前文没出现过，补在这里：
补充①：防"话说一半就停"（没人盯着的自主管道用）：
在结束轮次前检查你的最后一段。如果它是计划、分析或承诺（"我将……""请告诉我何时……"），现在就用工具调用完成它。只有在任务完成或被阻塞在只有用户才能提供的输入上时，才结束轮次。
补充②：让它从历史会话引导初始记忆（配合记事本用，第一次搭记忆系统时跑一遍）：
回顾我们之前的会话，用子代理识别核心主题和经验教训，存储在 [指定位置]。确保未来使用时参考这个位置。
两个值得单独讲的工具建议
面向用户的可读性指令
Fable 5 在长时间代理式工作中（大量工具调用、庞大上下文）可能产出"只有自己能看懂"的内容：密集的箭头链速记、内部术语、引用用户从未看到的思考过程。
官方给了一套沟通风格指令，核心逻辑是：工具调用之间你怎么速记都行，那是你的工作草稿；但最终面向用户的总结，要当成读者第一次看到这件事来写。
以结果开头，一句话说明发生了什么。写完整的句子，展开术语，不要用箭头链或自创标签。如果必须在简短和清晰之间选择，选清晰。
send-to-user 工具
这是一个面向长时间异步代理的设计模式。给代理一个工具，能在不结束当前轮次的情况下向用户推送消息。工具输入不会被模型摘要化，内容原样到达。
适用场景：需要中途向用户展示生成的代码片段、带数字的进度更新，或回复用户在循环中提出的问题。
实现很简单，就是一个接收 message 字符串的工具，你在 UI 端直接渲染输入内容，返回确认即可。
官方指南：https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5