- Anthropic 为 Claude Fable 5.1 和 Mythos 5.1 发布了专门的提示工程指南，组织成 16 类“症状 → 修补”条目，覆盖 effort、进度更新、工具调用、对话历史、写作密度、安全护栏等场景；官方明确旧 Fable 5 提示词不做修改也能正常工作。
- effort 档位是 5.1 上智能、延迟与成本的主要权衡项，官方建议用自家评测重跑一次档位扫描：medium 档结果大致追平 Fable 5 且成本更低，low 档在单任务成本上可与小模型竞争。
- 对话历史必须只追加、不改写：对 8月31日之后新建的账户，回传思考块时只要它产生时的前缀（系统提示、工具或更早消息）被改过，请求就会返回 400 错误。
- 写作行为出现反转：5.1 的散文比 5.0 更密，句子更长、段落更少，官方建议加一条定义反模式的提示；而此前为压制格式滥用写的“少用粗体列表”类规则，在新模型上反而应该删掉。
- 其余修补覆盖进度更新、工具调用批处理、压缩摘要保留项、变更与测试范围、低 effort 的搜索触发、护栏误报三种诱因、长输出空间、子代理并行与视觉裁剪工具。
这份指南解决什么问题
这份指南的定位不是教程，而是一张排查表。Anthropic 在开头说明：现有的 Fable 5 提示词在 5.1 上不做修改也能正常工作，但有几处行为差异值得知道，开发者只需要按自己观察到的症状跳到对应小节。比如工具调用之间几乎没有文字输出，就看进度更新那一节；请求报 bound to a different conversation 错误，就看对话历史那一节。
16 个小节可以归成四组：算力与成本（effort 档位、长输出）、对话结构（历史只追加、进度更新、工具批处理、压缩摘要）、输出风格（写作密度、聊天格式、引用标注、任务完成与变更范围），以及工具行为（搜索触发、护栏误报、定向编辑、子代理、视觉）。值得注意的是，其中“对话历史只追加”一条与 8月31日生效的思考块回传新规是同一套机制的两面：思考块只在与产生它完全一致的上下文里有效，改动历史前缀的旧习惯在新账户上会直接报错。
effort 档位：升级后最该重做的一件事
指南把 effort 称为 5.1 上智能、延迟与成本三者之间的主要权衡项，给了两个具体判断。其一，5.1 相对 5.0 的能力提升在各档位都存在，且档位越高提升越大；在 medium 档，结果大致追平 Fable 5，成本更低，评测显示质量够用的场景应该往下调档。其二，low 档的 5.1 在单任务成本上常能与 Opus、Sonnet 系竞争而得分更高，原本用小模型跑高 effort 的场景值得把它纳入对比。
官方特别提醒：档位名字在不同模型上对应的思考量并不相同，在 Fable 5 上跑过一次档位扫描不代表 5.1 可以沿用，需要重跑。两个档位还有专属行为：low 档下模型更少调用搜索和检索工具，更倾向凭记忆回答；xhigh 和 max 档下模型会在动笔前思考更久，长交付物要给输出留够空间，这两点在指南里各有独立小节。
对话历史只能追加，不能改写
这是整份指南里约束最硬的一条。每个 assistant 轮次要按 API 原样回传，思考块 included，请求之间不要编辑更早的轮次。对 8月31日之后新建的账户，回传思考块时若其前缀（系统提示、工具列表或任何更早消息）已被改动，API 返回 400 错误；也可以通过 beta 参数选择只丢弃受影响的思考块。官方明确说，未来的模型预计会对所有账户执行这项检查，建议现在就改。
容易触发检查的历史操作有三个：注入又移除每轮提醒、原地摘要旧轮次、会话中途改系统提示。替代方案官方也给全了：每轮提醒用轮次级系统消息发送（带 clear_at 参数的 beta 功能，旧副本会被自动清除且不计入输入 token）；要改指令或工具，用会话中段的系统消息而不是重写 system 字段；裁剪上下文交给服务端的压缩或上下文编辑功能。历史改动还会重启提示缓存，而 5.1 上缓存读取已经变便宜，官方建议重新实验压缩时机，过早压缩未必再划算。
写作与格式：两处行为反转
写作密度是这篇指南里对普通用户影响最直接的小节。5.1 的写作整体比此前模型高一个台阶，套话和无解释的行话更少，但在部分场景下散文比 5.0 更密：句子更长，段落切分更少。官方给出的修法是在用户消息（优先）或系统提示里加一条定义反模式（mannered prose）的指令，并给了一个更短的版本同样有效。具体提示文本见官方文档的对应小节。
聊天格式则是方向相反的反转。此前的模型爱用粗体和列表，很多提示词里都写着压制格式的规则；5.1 恰好相反，更少使用粗体，也更少主动上标题、列表和引号。如果你的提示词里还留着反格式化语句，官方建议删掉，或者改写成一条规定何时使用何种格式的规则。同类还有引用标注：5.1 在摘要文档时更容易照搬原文而不标注为引用，官方的修法是在系统提示里放一个完整的正确响应示例。
任务完成与变更范围
在复杂异步任务上，5.1 有时会在工作完成前结束回合：要么写下“接下来我会……”却不执行，要么停下来询问一个原始请求已经覆盖的步骤。官方给了两条系统提示修补并建议同时使用，预算有限时只用第一条即可保留大部分效果；第一条的开头一句（告知用户不在实时看屏幕）承担了主要作用。指南同时提醒，这类修改会让模型更少就不明确的请求提问，需要在自己的任务上验证这个权衡。
变更范围是同类问题：实现开放式功能时，5.1 可能顺手修复旁边的代码、扩展任务没提到的行为、提交超出需要的测试文件。官方称加上明确指令后，未经要求的添加和提交的测试代码显著下降，而任务成功率没有可测变化。小改动重写整个文件的倾向也类似，一条追加指令就能把它拉回 Fable 5 的定向编辑习惯。
检索、引用与安全护栏
低 effort 档的 5.1 更少调用搜索工具、更多凭记忆回答。修法分两档：要么只为受影响的回合调高 effort（官方支持会话中途改档），要么在系统提示里加一句校验提醒——认识一个名字不等于知道它的现状，这类名字应该按用户写法去搜索。
安全护栏的误报比 Fable 5 发布时更少，源码漏洞挖掘已被明确允许，但仍有三种情况容易触发拦截：用“这段代码能否无错编译”这类措辞提问（官方建议改成“这段程序有没有 bug”）、使用冷门编程语言而未提供上下文、工具返回 base64 编码数据进入模型上下文。被拦截的请求会以 refusal 作为停止原因返回。
长输出、子代理与视觉
xhigh 和 max 档下模型可能在思考里起草长交付物，再把同样的内容写一遍作为回复，等待时间和输出 token 都会翻倍。官方的建议是长交付请求留在默认的 high 档，确有质量收益再上更高档；确需使用时，把 max_tokens 设为思考加回复的总和，并在用户消息末尾追加一条让思考变短的提示。
多代理场景有一条结构性建议：不要强制主代理停下等每个子代理，让发起子代理的工具立即返回、结果就绪后再以用户消息回传、另给主代理一个主动等待的工具。官方承认模型仍经常选择等待，时间收益来自它继续干活的那些回合。视觉方面，5.1 开箱视觉能力更好，处理密集图表时给它一个能裁剪和放大图像的工具（或带 PIL、OpenCV 的容器）收益最大，官方食谱里给出了现成的裁剪工具定义。
升级检查清单
按指南的优先级，升级 Fable 5.1 时可以照着做五件事。
第一，重跑 effort 档位扫描，重点验证 medium 和 low 是否能在自家评测上扛住，这是成本影响最大的一项。第二，检查集成是否在请求之间改写历史（注入提醒、原地摘要、改系统提示），改成轮次级系统消息或会话中段系统消息，并用 drop_block 模式跑一轮日志确认。第三，翻一遍旧提示词，删掉压制叙述和压制格式的规则，按需加一条控制写作密度的指令。第四，长任务场景加上“完成整个任务”的系统提示，同时观察模糊请求的误触发。第五，视觉和子代理场景按官方食谱配置裁剪工具与非阻塞的子代理工具，这两项改动小、收益直接。
AI 速览
