Fable 5.1官方提示词指南

Fable 5.1 发布后，Anthropic 同步发了一份《Prompting Claude Fable 5.1》提示词指南，列出了15 个5.1 跟 Fable 5 在行为上的差异，每条都附了可以直接复制的修正提示词。官方提示词指南在介绍这份指南之前，我们先回顾一下 Fable 5 的提示词变化。7 月 ......

本文来自微信公众号：AGI Hunt，作者：尹John，头图来自：AI生成

Fable 5.1 发布后，Anthropic 同步发了一份《Prompting Claude Fable 5.1》提示词指南，列出了 15 个 5.1 跟 Fable 5 在行为上的差异，每条都附了可以直接复制的修正提示词。

官方提示词指南

在介绍这份指南之前，我们先回顾一下 Fable 5 的提示词变化。

7 月 24 日，Anthropic 的 Thariq Shihipar 在官方博客发了一篇《The new rules of context engineering for Claude 5 generation models》，其核心结论是：

他们审查了 Claude Code 自己的系统提示词，删掉了 80% 以上的内容，编程评测上没有任何性能损失。

官方博客

原因很好理解，原有的大量指令是在修补旧模型的坏习惯，而新模型能力上来后，便已经不需要了。

指令互相打架

Anthropic 把这些冗余归纳成了六类：

六类冗余

绝对规则，比如“永远不写注释”，但新模型其实能自己判断什么时候该写。复制粘贴示例，本意是教模型怎么用工具，结果反而限制了它的推理空间。所有细节前置，把审查流程、边界情况全堆进系统提示词，其实只有特定场景才用得上。

重复指令，同一件事说两遍三遍，早期模型确实容易忘，现在则不会了。手动记忆，之前用户需要手写事实到 CLAUDE.md 里，现在工具自己已经有记忆功能能自己更新了。文字描述，用散文描述一个设计稿，不如直接给一份真实文件，比如一份 HTML 或一段代码。

其中一个例子是 Claude Code 的 TodoWrite 工具，原来的使用指令是 9100 个字符，现在砍到了一句话加一个状态枚举。

TodoWrite 前后对比

而 Fable 5.1 发布的今天，官方同样又出了这一份提示词指南，同样是：你的旧 prompt 大体也能用，但有些地方会变，而且你 prompt 里可能有不少内容其实是在伺候旧模型的坏习惯。

下面我们逐条来看一下。

七个行为变化

在 What's New 的 Changed from Fable 5 章节里，官方明确列出了七个不需要改代码、但模型行为会变的差异：

并行工具调用变少了：Agent 循环里可能退化成一轮只调用一个工具；

进度更新变少了：长时间工具调用期间，写给用户看的中间文字少了很多；

low effort 下更爱凭记忆回答：不去调搜索工具，直接从训练数据里来尝试作答；

文风变密了：句子更长，段落分隔更少；

聊天里格式反而变少了：加粗、标题、列表会比之前用得少了许多；

摘要里不标引号了：直接复述原文，不打引号；

小改动却整文件重写：改几行代码，结果把整个文件重新输出一遍。

每一条在官方指南里都有对应的修正提示词。

effort五档

effort 算是 Fable 5.1 上调控智能、延迟和成本最主要的一个手段了。共有五个档位：low、medium、high、xhigh、max，API 默认是 high。

官方建议从 high 起步，然后跑一遍自己的 eval，把能降的降下去。而重新扫一轮其实是有必要的，因为档位名在不同模型间不等价。

同一个 medium，在 Fable 5 和 Fable 5.1 上的行为是不同的。

Anthropic 工程师 Lance Martin 分享了一组 CursorBench 的数据：

CursorBench 成本对比

在 CursorBench 3.2.0 上，Fable 5.1 的 low effort 跟 Fable 5 的 high effort 打平，而成本只有三分之一。

也就是说，如果你之前在用 Opus 或 Sonnet 跑一些不太难的任务，现在可以考虑换成 Fable 5.1 的 low effort，分数更高，单任务成本也有竞争力。而 medium 则大致等于 Fable 5 的水平，但价格更低。

还有一个重要的变化：缓存读取价格降到了原来的四分之一，从 $1.00/MTok 降到 $0.25/MTok。长时间 Agent 会话里反复读取缓存前缀的成本，会大幅的下降。

Fable 5.1 还支持了在对话中途切换 effort（beta），且不会破坏提示词缓存。遇到难的步骤就临时拉到 xhigh，做完降回 high，缓存依然有效，依旧热乎。

进度更新变少

Fable 5.1 在长时间工具调用期间，写给用户看的中间更新文字变少了，effort 越高越明显。用户会看到 Agent 沉默好几分钟，或者只在最后一步才冒出一句话。

官方的建议是分两步走。

第一步，检查你的客户端是否开了 display: "updates"（beta）。模型在工具调用之间写的短笔记，是通过 thinking block 的 progress update 传回来的。默认的 "omitted" 模式下这些 block 是空的，所以模型其实有在写更新，但你的用户看不到。

第二步，检查 prompt 里有没有类似“hold all findings for the final response”这种压制叙述的旧指令，有就删掉。

如果还需要更多更新，官方给了一段 prompt：

官方原文：Before you start， say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own — what you found， what you did， and what's next — so a reader who only sees the last message has the full picture.

中文版：开始之前，用一句话说明你即将要做什么；工作过程中给出简短的进度更新，方便用户跟上。结尾写一段可以独立看懂的简短总结——你发现了什么、做了什么、下一步是什么——让只看到最后一条消息的读者也能了解全貌。

意思就是开工前先说一句要做什么，过程中给些简短更新，收尾的时候写一个能独立看懂的小总结。

一轮一个工具

在 Agent 循环里，Fable 5.1 有时候会退化成一轮只调用一个工具，特别是在编码和 computer use 场景下，模型需要自己判断下一步该读哪些文件时，它倾向于一个一个来。

这不影响结果质量，但每多一轮就多一次往返，token 消耗和等待时间都会往上涨。

对这个问题，官方也给了一句修正 prompt：

官方原文：First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

中文版：先在内部列出你接下来需要的东西；然后把所有不依赖其他结果的请求，全部放在这一次响应里发出来。

先在心里列出接下来需要什么，然后把不互相依赖的请求全部放到一次响应里发出来。

官方建议用 turn-scoped system message（clear_at: "next_user_message"，beta）每轮追加这句话。这是一种只在当前轮次生效的系统消息，下一条用户消息进来后自动清除，不会污染历史。

历史只能追加

这条跟 Preserved Thinking 的反蒸馏机制有关。

这里的核心约束在于：改了早先轮次的任何内容（system prompt、工具列表、历史消息），都会导致后面的 thinking block 失效。

8 月 31 日之后创建的新账号已经开始强制执行这个检查，后续新模型会对所有账号都生效。

应对的办法就是把对话历史当作 append-only 的日志来对待：不删、不改、不重写。新指令用 mid-conversation system message 追加，工具变更用 mid-conversation tool change 追加，需要压缩历史则交给服务端的 compaction 或 context editing。

上下文分层结构

以前很多人习惯在客户端做“提前压缩以省 token”，但 Fable 5.1 的缓存读取价格都降到四分之一了，那这个策略在成本上还划算吗？

官方建议可以尝试把压缩点推后一些。

文风变密

Anthropic 承认 Fable 5.1 的文风比 Fable 5 更密了，句子更长，段落分隔更少。

官方给了一段关于 mannered prose（矫饰文风）的定义，可以加到 system prompt 里：

官方原文：Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying，" the mannered writer produces "a dial worth turning." Instead of "this point still matters，" they write "this point earns its keep." The phrases exist to display the writer， not to convey the idea， and readers can tell.

中文版：矫饰文风用隐喻和修辞替代直接表述。本该说“一个值得调整的参数”，矫饰的写法则是“一个值得拧动的旋钮”；本该说“这一点仍然重要”，却写成“这一点挣得了它的位置”。这些措辞存在的目的是展示写作者，而不是传达想法，而读者是看得出来的。

意思是：矫饰文风用隐喻和修辞替代直接表述，存在的目的是展示写作者，而不是传达想法。

如果嫌长，也可以用简短版：

官方原文（简短版）：Please remove all mannered prose.

中文版：请去掉所有矫饰文风。

加这一句进去就可以了，就不会又密又空了。

格式反转

之前的 Claude 模型有个通病，爱在回复里加粗、标题、列表用得太多。很多人的 prompt 里都写了“别用列表”之类的反格式规则。

到了 Fable 5.1，情况反过来了，它倾向于不用这些格式元素。

所以，如果你的 prompt 里还有反格式规则的话，现在可以删掉了。甚至可能得加上正向引导：

官方原文：Use lists and bullet points when asked to， or when the content is multifaceted enough that they help with clarity.

中文版：在用户明确要求时，或者内容层次足够多、用列表更有助于表达清楚时，才使用列表和要点。

该用列表的时候才用，对话场景保持纯文本。

摘要不标引号

做文档摘要时，Fable 5.1 更容易直接复述原文而不标引号。

官方给的修正方式是：在 system prompt 里放一个完整的正确示例，包括用户请求、正确的回复、以及一段说明为什么这个回复是正确的。

官方系统提示词页

官方在这里给的示例是一个关于两家报纸报道对比的 case，要点是回复应该用自己的话来间接转述，只保留少量标记引用，而不是大段复制原文。

没做完就停

Fable 5.1 有时会在任务没做完的时候停下来问“要不要我继续”，或者描述一下接下来打算做什么，然后……就真的不做了。

官方给了两段 prompt。其中第一段的开头那一句，承担了大部分效果：

官方原文 · 自主执行：You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task， so asking 'Want me to…?' or 'Shall I…?' will block the work.

中文版：你正在自主执行任务。用户没有实时盯着，也无法在任务中途回答问题，所以问“要不要我……？”“我是否应该……？”会让工作卡住。

你正在自主执行，用户没有实时看着，中途问“要不要我……”会卡住工作流。这样能避免模型动不动就停下来提问。

第二段是关于交付范围的定义：

官方原文 · 交付范围：The user's request — or the plan they approved — sets the scope， and the scope is the deliverable: don't quietly narrow， widen， or swap it.

中文版：用户的请求——或者他们已经批准的方案——决定了范围，而范围就是交付物：不要悄悄地缩小它、扩大它或者替换它。

用户的请求就是交付范围，不要自行缩小、扩大或替换。

这两段加在一起，Fable 5.1 在跑长任务时会明显靠谱许多。

压缩摘要该保留什么

长对话做 compaction 的时候，如果你明确告诉 Fable 5.1 哪些东西必须保留，它的响应是很好的。

官方给了一段六条清单的摘要指令，核心的逻辑有：保留遇到的困难和解法、保留被排除的方案和原因、保留所有决策和约束（原话保留）、保留当前进度、保留待办事项、保留具体细节（名字、数字、日期、原文链接）。

其中有一条我自己 compact 时就会直接加的指令（感觉被蒸馏了）：

用户说的话要尽量保留原话，而模型自己的推理则可以大幅压缩。

这样压缩之后，新的上下文窗口里还是能读到用户较完整的原始意图。

额外改动

Fable 5.1 有时在完成一个功能的同时，会连带修改旁边的代码、并多提交一些测试文件。

官方说加上这段约束之后，多余改动降了不少，且任务成功率并不会受影响。完整的 prompt 是这样的：

官方原文 · 不做多余改动：If， while working or testing， you find a pre-existing bug， a performance concern， or behavior the task doesn't mention， don't fix， optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous， implement the reading its wording and the surrounding code most directly support， state that assumption in your summary， and don't build for the other readings as well.

Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change， sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for， completely.

中文版：如果你在工作或测试过程中，发现了一个本来就存在的 bug、一处性能隐患，或者任务没有提到的行为，不要在这次改动里修复、优化或扩展它——除非任务要求的行为离开它就无法运行；把它作为后续事项写在你的总结里。任务有歧义时，实现措辞和周边代码最直接支持的那种理解，在总结里说明这个假设，不要把其他理解也一并做出来。

你可以用任何方式验证自己的工作；临时脚本和快速检查不必保留。只在任务明确要求、或这个仓库对这类改动本来就有测试的情况下才提交测试，规模参照相邻的测试文件——大致每个明确的行为对应一个聚焦的测试——不要把临时检查变成额外的永久测试文件。这只针对多余的部分：任务要求的每一个行为，都要完整实现。

要点有几个：发现了跟任务无关的 bug 或优化点，不在当前 change 里修，而是作为 follow-up 报告；任务有歧义的时候，选最直接的理解去实现，不要把其他可能的理解也一起做了；测试文件只在任务要求或仓库惯例需要时才提交，规模参照旁边已有的测试文件。

四个工程细节

还有几个相对小的行为差异，也分别说一下。

low effort 不搜索。

在最低 effort 下，模型更倾向于凭记忆回答而不去调搜索工具。两个解法：要么那一轮提高 effort（支持 mid-conversation 切换），要么加一段 prompt 提醒它“认识一个名字不等于知道它的现状”：

官方原文 · 先搜再答：When a query centers on a name you do not confidently recognize， or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months， the name itself is the thing to verify: search before answering.

中文版：当一个问题围绕着某个你并不确信认识的名字，或者这个名字来自 AI 模型、开发者工具这类几个月就会变一轮的快速变化领域，那么这个名字本身就是需要核实的东西：先搜索，再回答。

在 AI 模型和开发工具这类变化快的领域，认识名字不等于了解现状，也要先搜索再回答。

安全分类器误报：

ClaudeDevs 在发布 thread 里提到，Fable 5.1 的安全能力有了进一步改进，现在可以帮你查自己代码的安全漏洞了，cyber-related fallback 比 Fable 5 降了约 40%。

有三个容易触发误报的场景，分别是问“这个程序能编译吗”（改成问“有什么 bug”）、冷门编程语言（给它文档）、工具输出里带 base64（去掉就好）。

整文件重写：小改动的时候，模型可能把整个文件重新输出一遍。可以用这样一句 prompt 来修正：

官方原文 · 局部修改：...try to surgically edit a file rather than rewrite the entire thing.

中文版：……尽量对文件做精准的局部修改，而不是把整个文件重写一遍。

能改哪里改哪里的，就别把整个文件重新输出一遍了。

xhigh/max 长文重复写：在 xhigh 特别是 max effort 下，模型可能先在 thinking 里把整篇长文写一遍，然后在输出里又写一遍，等于 output token 翻倍。

官方建议的做法是加一段 prompt，告诉它有 token 上限，推理空间用来推理，输出空间用来输出，不要在推理里完整起草然后再重写一遍。

此外还有两条工程建议：主 Agent 在子 Agent 跑的时候不要干等着（让启动子 Agent 的工具立即返回），以及给视觉任务提供裁剪放大工具（模型有了迭代分析图片的能力，但需要一个能裁剪指定区域的工具）。

清理旧补丁

Fable 5 发布时，Anthropic 删了 Claude Code 80% 的系统提示词，性能没有下降。发布 Fable 5.1 的同一天，又发了一份指南，告诉开发者们哪些旧 prompt 在新模型上需要修正。

这份指南的 16 个小节里，给了 14 段可以直接复制的 prompt，绝大多数是说 prompt 可能需要添些什么东西。

Lance Martin 推文

Anthropic 的工程师 Lance Martin 也特意发布推文里进行了整理：

Lance Martin：Remove verification rituals， emphasis boosters， scratchpad scaffolds， stale few-shot examples， or contradictory rules.

中文版：删掉验证仪式、强调增强词、草稿纸脚手架、过期的 few-shot 示例，以及互相矛盾的规则。

在 Claude Code 里，可以直接跑 /claude-api prompt-audit，它会自动检查你的 prompt 和 skill 中的常见反模式。

如果你的 Claude Code 或 API 集成还在跑 Fable 5 时代的 prompt，建议对照官方指南过一遍：老补丁该清的清掉，新差异该补的补上。

参考链接

官方提示词指南https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5-1

What's newhttps://platform.claude.com/docs/en/models/fable-5-1/whats-new-fable-5-1

effort 文档https://platform.claude.com/docs/en/build-with-claude/effort#recommended-effort-levels-for-claude-fable-5-1

官方博客《The new rules of context engineering》https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

Lance Martin tipshttps://x.com/RLanceMartin/status/2094854835854295296

素材来源AGI HUNT · https://agihunt.info

本文来自微信公众号：AGI Hunt，作者：尹John