用 Fable 5.1 完成更长的编程任务

有人指责我偏爱 OpenAI，也有人说我偏爱 Anthropic。我在日常工作中更喜欢 Fable 而非 Astra，原因是它们的表现：Astra 的高点可能更高，低点也更低，而 Fable 给我的感觉更稳定。这是我的个人经验，并非普遍适用的模型排名。

大量使用 Fable 后，我读了 Anthropic 的 Fable 5.1 提示词指南，真希望自己早点发现它。我想结合指南和自己的经验，谈谈指令、工具、长时间运行的任务，以及如何用另一个模型检查结果。

指南首先讨论推理强度。我觉得按完整 API 价格使用 Fable 很贵，所以这里主要谈订阅使用。我也见过 Astra 偶尔陷入耗费额度的循环。这些印象以及我提到的订阅额度分配，都取决于录制时的价格和限制。

我说过，当时我每周额度的大约一半留给 Fable，另一半可以用于其他模型。我经常先用光 Fable 的部分。这种分配影响了我如何选择设置，但不能假设所有方案或当前条款都一样。

Anthropic 建议从 high 开始，再用自己的评估比较其他强度。拿一个结果可预期的任务试不同设置，可以看出差异，但会花时间和 Token。就我自己的工作而言，low 和 medium 失败得较频繁，所以我通常用 high，遇到需要深入调查的工作偶尔用 x-high。

如果第一次低成本尝试失败，还要重新运行，最终未必更省钱。我发现简单请求即使用 high，也不一定会消耗很多 Token；在我的小规模比较中，Astra 调整得更好。结果取决于任务和模型，因此我的默认设置只是个人偏好，不是价格保证。

较低强度仍然有用：比如你明确希望答案更短、更浅，或想限制模型钻进某个细节。订阅额度的限制也让我把 Fable 留给我认为较强设置更有价值的任务。

与前一版本相比，Fable 5.1 在长时间工具调用期间默认给用户的进度更新更少。我见过它连续调用约 150 次工具都没有更新。这适合我的工作方式，因为我启动任务后会去看其他会话；但如果你想看到过程，可以直接要求它汇报。

提示词可以要求它开始前简述计划、工作时定期更新，最后概括发现、行动和后续步骤。如果你的应用隐藏了工具输出，也应该告诉模型；否则它可能以为用户能看到界面实际隐藏的信息。

指南还介绍了编辑对话历史时推理轨迹的变化。Theo 将其理解为防范蒸馏攻击的一项措施。开发集成的人员应查看自己环境中的实际 API 行为和当前文档。

另一节讨论文字密度。Fable 5.1 可能使用更少的套话，但句子更长、分段更少。如果风格影响阅读，可以要求更直接的表达；指南建议明确描述你想避免的那种刻意修饰的文字。

旧模型经常过度使用粗体和列表，因此人们添加了限制格式的指令。如果新模型本来就减少了格式，同样的规则可能矫枉过正。我建议重新检查 CLAUDE.md 或 AGENTS.md 中旧的行为指令，再根据实际结果调整。

我提到，在我讨论的配置中，没有 CLAUDE.md 时，Claude Code 也可能读取 AGENTS.md。这可能让旧指令意外进入工作流程。指南还提醒，模型有时会复现原文却不加引号；提供正确标注来源的示例可能有帮助。

对于长时间的异步工作，可以明确要求智能体完成任务，而不是只描述下一步打算做什么。根据我的经验，Fable 通常比 Astra 更能持续推进；对提示词做小调整或增加技能也可能有所帮助。

我的 PR 监看技能会检查新的审查意见和 CI，根据源码核实机器人发现，修复真实问题，同时避免不必要的范围扩张和填充式评论。它还处理基础分支变化，并要求在关闭过时 PR 前取得授权。

遇到 T3 Code 图片预览故障时，我提供了截图和会话 ID，描述渲染及保存失败，并让 Fable 检查历史、找出根因，提交一个 PR。提示词既给了证据，也说明了具体的预期结果。

另一位贡献者认为之前的 PR 更好。我让智能体比较两者并选择路径：重新打开并完成旧方案、复用提交，或继续我们的方案。它评估了差异，吸收有用的改动并处理审查意见；最后由我选择合并。

对我来说，变化在于：我花更少时间从模型给出的选项中挑选，花更多时间提供证据和授权，让它作出有依据的选择。当然，哪些决定适合委派，仍需要人来判断。

接下来的例子刻意选择了高风险场景，我不建议把它照搬到重要的生产代码库。Lakebed 是尚未发布的实验项目，我用 Astra 做了一项大规模运行时改动，合并前请 Fable 独立评估。

Fable 不建议将改动作为一个 PR 合并。它指出迁移难以回退、多个功能捆在一起、默认运行时发生变化以及存在未解释的失败等问题。我问它怎样降低风险，以及预发布环境能否发现回归。

模型说预发布环境有助于诊断崩溃、延迟和资源问题，却无法有信心地发现错误查询结果。现有日志和指标不够，因为该环境缺少流量、错误视图的信号和复现路径。它建议增加影子模式、合成流量、失败原因和运行时计数器。

我让它在运行时重写分支之上实现这些增强信心的改动。约一小时后，它完成了代码；随后我明确要求它提交 PR，因为我最初没有提出这一点。看过它的回复后，我在这个实验环境中授权继续合并和测试。

智能体工作了约一个半小时，即使当时使用的是 medium 强度。它的测试使我的笔记本和网络负载过高，于是我介入，要求它停止那样使用我的 IP。它报告了额外的 PR，也解释了运行方面的取舍，包括影子模式的开销。

我要求它与现有生产构建比较，随后询问最终评价。模型报告称，差分测试在 160 个步骤中触发了 1,400 次重新播种，没有出现错误答案。它修正了自己的看法：无声的查询错误值得仔细检查，而运行时发布是主要风险。这些是该项目报告的特定结果，并不能证明代码完全正确。

审查还发现了其他可以改进的地方，我便要求它另开一个引擎预热 PR，并在检查通过、它对改动满意后监看和合并。只有用户选择授予相应权限时才可能这样做；我也承认许多代码库不适合这种工作方式。

你可以先在更简单的任务中尝试较小规模的工作流程。我发现 Codex 在 macOS 上的某些计算机操作方面更强，所以有时让 Fable 请 Codex 或 Astra 测试或审查改动。根据我的经验，Astra 可能更擅长审查，而我更喜欢 Fable 编写代码。

提示词的核心是完成状态。有时我希望它提交 PR 并报告；有时希望它监看检查；有时我授权它在满足条件后合并。应当给模型明确的停止条件，并在适当时提供替代路径，以便证据不足以继续时改变方向。

我把重复监督比作在 TypeScript 函数里添加多余的类型检查。如果一个工具能可靠地验证某个属性，委派检查就能让人把注意力用在别处。不过外部输入等边界仍可能需要运行时检查；对智能体的监督也需要同样的判断。

你可以告诉模型，压缩长对话时应保留哪些内容。如果重要约束或事实反复丢失，可以把保留要求加入相关提示词或项目指令。我认为许多人过度考虑压缩，但针对具体问题做这种调整很有用。

Anthropic 提醒，开放式请求可能导致模型做出未要求的改动或添加额外测试。我在自己的工作流程中很少遇到，但如果你遇到了，可以要求模型不要修改无关问题，除非任务依赖这些改动，并单独报告发现。

指南还指出，low 强度可能降低触发搜索的概率，并建议在保护机制产生误报时提供更多上下文。我自己遇到此类问题的次数较少；合适的应对方式取决于具体工具和任务。

对于围绕模型构建的应用，指南强调可以让主智能体在子智能体运行时继续独立工作，并为视觉任务提供裁剪和放大工具。这些是特定环境中的能力，不能假设每个智能体都具备。

我最重要的建议是重新审视围绕旧版 Claude Code 形成的习惯。许多开发者一直担心上下文进入所谓的“变笨区”。我认为目前的默认设置和压缩已足以满足我的工作方式，因此我从 T3 Code 中移除了上下文监视器。

我认为上下文限制是根据观察到的行为选择的，而更频繁的压缩可能因重写上下文而增加成本。缓存读取价格和缓存过期情况也影响费用。这些是我对录制时工具和价格的看法；上下文质量与成本仍取决于具体模型、工作负载和配置。

如果上下文管理让你困惑，我的实际建议是先使用默认设置，不要仅凭社交媒体帖子改变配置。我自己的配置使用全屏和代理，也关闭了对我没帮助的记忆功能。T3 Code 提供某些选项，是因为 Claude Code 本身也提供了它们。

在自己的工作中，我也偏好自主程度更高的权限模式。这反映了我的风险容忍度；合适的权限取决于系统、出错后果和用户授权。更广泛的观点是重新评估旧的变通方案，不要假定以前的每个限制都依然存在。

可以从几乎不做定制的新配置开始，遇到实际问题后再逐步增加针对性指令。Fable 5.1 的行为变化看起来也许只是渐进改进，但对我的日常工作影响很大。请根据自己的需求测试模型，判断这些取舍是否适合你。