Fable 5.1 使用心得和经验，如何落实到团队中
如果你已经开始用 Fable 5.1，大概率很快就会碰到一个问题：
它确实更聪明，但也更容易把额度用完。
这不是模型能力问题，而是任务调度问题。
声明：Fable 5.1 发布时间还很短，下面不是长期统计结论。
为什么 Fable 额度总是先用完
Fable 使用会同时消耗周度总额度，而 Fable 最多只能占总周额度的 50%。所以你打开 /usage，会看到两条进度：一条是周度总消耗，一条是 Fable 周度消耗。
而这两条进度对于大多人来说都是失衡的，这正是一种正常的表现，人在拥有更好、更优秀的产品后，会天然的嫌弃旧的、垃圾的产品，这是人性使然。
但我们毕竟花着钱在使用它，opus、sonnet 额度也是花了钱的，不用的话就浪费了，先不说这是不是 A 社利用人性的策略，就是为了让订阅用户用量减少，我们得自己学会如何最大化的利用这些额度。
先不考虑 Anthropic 内部具体怎么折算，假设周度总额度是 T，Fable 上限是 0.5T，Fable 已经消耗 F，其他模型消耗 O：
Fable 进度 = F / 0.5T
总进度 = (F + O) / T两条进度相等时，F 大约等于 O。换句话说，按照系统内部的用量单位计算，Fable 和其他模型各承担一半左右的消耗，Fable 的 50% 上限才更可能和总额度一起走到重置日。
你当然不需要把两条进度控制到完全一致。不同模型处理的任务不同，输入长度、输出长度、缓存和工具调用也不同。更实用的做法，是把它当成一个反馈控制系统：每天看几次 /usage。
Fable 那条跑得太快，就把执行类工作移给 Opus 或 Sonnet；总进度跑得太快，就把关键判断、架构设计和最终验收交回 Fable。
我觉得，这个思路比单纯研究“怎么少用 Token”更有用。我的目标不是省，而是让一周里的每一档模型都用在合适的位置。
Fable 负责判断，Opus 和 Sonnet 负责执行
想让两条进度大致同步，最简单的办法，是让 Fable 做主会话，但不要让它包办所有工作。
主会话使用 Fable，默认 high，有时用 medium。 Fable 主要负责任务分析、任务编排和结果验收；大量读代码、检索、写代码、跑测试和批量修改，则交给 Opus 或 Sonnet 子代理。
Fable 指挥其他 Agent 的效果好，一个重要原因是它写出来的任务说明更完整，执行模型不容易跑偏。
下面是宝玉老师的一段给 Fable 的默认指令，这样写：
你负责需求判断、任务划分和结果验收。 把大范围检索、批量读取、编码和测试交给指定的 Opus 或 Sonnet Agent。 每次委派都要写清输入、允许修改的范围、交付物、验证方法和停止条件。 工作代理完成后，你要检查证据，不能直接转述它的“已完成”。 涉及架构取舍、不可逆修改或验收标准变化时，由你自己处理。
为什么这样分工有效？因为一个工程任务里的信息价值并不平均。
决定型、判断型、总结型、架构型、拆解型等任务，它们的不确定性高，选错以后返工代价也很大，这些任务适合交给 Fable。
读取一批文件、同步修改多个调用点、运行测试、整理错误日志，这些工作量可能很大，但目标和验收方法通常能写清楚。只要边界清楚，Opus 或 Sonnet 就足够完成。
把 Fable 放在“不确定性高、错误代价大”的位置，把子代理放在“步骤多、结果容易验证”的位置。
子代理还有一个经常被低估的价值：它有独立上下文。
大量文件内容、搜索结果和测试日志可以留在子代理里，主会话只接收结论、证据和需要决策的问题。
主会话一旦塞满执行细节，Fable 后面的判断质量也会下降。你看起来省掉了委派步骤，实际上却在消耗最需要保护的上下文。
这件事对长任务非常重要。
Claude Code 官方文档也把上下文隔离列为 SubAgent 的主要用途。
子代理并不天然省钱
子代理每次启动都是新上下文，前面的缓存和会话历史用不上，重新传递项目背景也要花 Token。
如果任务只是改一行配置、查一个函数、跑一条命令，Fable 自己做完通常更便宜。你为了形式上的“主从分工”，先启动子代理，重新讲一次背景，等它返回摘要，再让 Fable 复核一遍，成本一定更高。
但下面几类工作适合交出去给 subAgent：
- 一次需要读取很多文件；
- 工具输出和测试日志很长；
- 多个任务可以彼此独立执行；
- 结果可以通过测试、编译、截图、差异文件或明确字段验证。
这些任务有一个共同点：你能给它写出清楚的交付协议。
任务越容易验收，子代理越有价值。
所以我不建议你把“所有实现一律交给子代理，有些任务确实适合让 Fable 直接完成。
更合理的方式，是做一个按需调用的 fable-coordinator Agent，或者把这套判断写成 Skill，只在复杂任务里启用。
判断要不要委派时，我会问三个问题：
- 这项工作会产生多少中间信息？
- 我能不能在不传递完整历史的情况下讲清任务？
- 我能不能独立验证它的结果？
而这，也牵扯出一个重要的灵魂拷问：如果是 opus 和 sonnet 的额度，那不就是合理的消耗吗？😓 毕竟我们是在解决这些家伙的额度花不完的问题。
High 和 Medium 可以常用，Max 不要当默认值
Fable 5.1 默认使用 high。
Anthropic 的 effort 文档建议先从 high 建立基线，再根据自己的评测降到 medium、low，或者在确实需要时升到 xhigh、max。medium 的定位是兼顾质量、速度和成本；max 优先追求最高能力，不限制推理 Token 的消耗，通常来讲 Token 消耗是其他推理强度的 1.5 倍。
max 不是一个简单的“再聪明一点”按钮。
你选择它，相当于告诉模型：先不要管成本，尽可能多想。拿它处理普通开发任务，很容易在短时间内同时消耗 5 小时窗口和 Fable 周额度。
如果一个问题已经失败两三次，判断错误可能造成资金损失、数据损坏或线上事故，而且你有清楚的验收标准，max 仍然有价值。
这里真正的前提是评测。
你需要拿同一批任务比较 high 和 max：成功率提高了多少，返工减少了多少，多消耗的额度值不值得。如果没有这样的对比，只因为名字叫 Max 就选择 Max，本质上还是凭感觉买算力。
我自己的默认顺序会是：先用 medium 处理边界清楚的任务，用 high 处理复杂判断；如果 high 在同一个关键问题上连续失败，再把任务收窄、补齐证据，最后才考虑 max。
1M 上下文不是免费的记忆
宝玉老师做过一次很有意思的个人对比。他用两台电脑、两个 Claude Code 账号同期工作，一个启用 1M 上下文，一个禁用。启用 1M 的账号消耗明显更快；关闭 1M 后，消耗速度很快降了下来。配置是：
{ "env": { "CLAUDE_CODE_DISABLE_1M_CONTEXT": "1" } }
他同时保留 Auto Compact，并把自动压缩目标放在 200K 左右。
1M 上下文的问题，是上下文越长，每一轮需要重新处理的信息就越多。很多团队看到 1M，会下意识把它当成一种不会丢失的长期记忆，于是什么都留在会话里。结果是模型每次都带着大量已经失效的搜索结果、旧方案和日志继续工作。
Fable 5.1 的 API 缓存读取价格下降以后，Anthropic 建议 API 用户重新测试压缩时机，不要只为了节省缓存读取费用而过早压缩上下文。 但宝玉老师专门补充过，这个价格折扣针对 API，订阅用户看到的 /usage 不能直接按照 API 单价换算；他自己的订阅体验仍然是，把自动压缩控制在 200K 左右更耐用。
如果你换了项目、换了目标，直接 /clear。如果同一个长任务进入了新阶段，先把已经确认的决策、当前修改状态、失败路径和验收条件写进文件，再执行 /compact。
不要为了追求一个整齐的数字机械压缩，因为压缩也需要模型重新阅读并生成摘要。
就跟人类的总结、沟通时的信息传递一样，AI 压缩一定会丢上下文信息，一旦漏掉的是关键的约束，后面的返工成本，会比省下来的上下文更贵。
你还可以运行 /context，看看究竟是谁占用了上下文；运行 /mcp，查看连接的服务占了多少空间；必要时再用 /doctor 诊断配置。
/doctor 的诊断效果很重要，它的作用是帮你发现问题，帮你决定哪些 Skill 和 MCP 应该删除。
ps：中午吃饭回来的会话、隔夜的会话，可以先 /compact 一下，再继续，否则缓存失效，用量很快。
模型能力强之后，提示词需要轻量化
以前模型能力不够时，我们喜欢写“必须仔细核对两遍”“尽可能详尽”“严格按照下面十几个步骤思考”，这些句子当时是在帮住模型更好的工作。
前段时间爆火的 $eli5 Skill，简单到就两行，这给我们的提示是，在 AI 掌握的很成熟的、比人类比使用者更强的领域，过多的描述反而对它是限制，它需要的仅仅是合适的引导。
模型升级以后，还原封不动地继承旧的冗余的规则，消耗的 Token 也会变多，但这并不是核心的问题，核心问题是新模型在你旧的规则下，并没有发挥出应该有的实力。
我尤其建议你删掉那些没有停止条件的词，比如“全面检索”“尽可能完善”“反复确认”。如果你真的需要全面，就写清范围；如果你需要确认，就写清证据；如果你需要反复，就写清最多几轮以及什么结果可以停止。
可执行的边界，比情绪化的强调更可靠。
团队如何落地，项目如何架构
使用经验、要求，都只是软性约束，只要涉及到人类使用，软性约束就约等于没预约束，相信所有在互联网团队工作过的人都懂得这个道理，否则我们也不用费尽心思的把各种流程平台化、CICD 化、自动化，就是为了通过这些手段保障稳定性，而不是依赖于人。
到了 AI 时代，也一样，我们无法去约束一个在工程里开发的人，但可以通过一些规则、工具从工程层面、从全局层面去进行一些落地，从而让全工程受益，保障整个团队的效率和体验。
在团队中，把复杂的、固定流程的工作沉淀下来，成为资产。是 ai 团队必须考虑的问题。 大部分直观想法仅仅是定义几个 skill，因为可能大家对 skill 比较熟悉。但 skill 并不是万能的，要根据实际情况定义具体的形态。 subagent 的优势在于整合和限制，可以指定模型、工具、权限等，劣势是需要有上下文传递，多少都会导致主agent的注意力分散和上下文信息丢失，也会消耗更多的token。 合适的事情选择合适的解决办法，落成合适的形态，是团队合作、企业工程必不可少的一步
如果你准备把个人经验交给整个团队，我建议先问清它解决的是什么问题，再决定放在哪里：
需要解决的问题我会使用的形式每次会话都必须知道的项目约定精简的 CLAUDE.md偶尔使用、需要推理的流程和知识Skill需要隔离上下文、指定模型和限制工具的工作角色.claude/agents/每次都必须执行、不能依赖模型自觉的检查Hook数据库、浏览器、内部服务等新增工具MCP需要向多个项目或整个团队分发Plugin 或纳入版本控制的项目配置
项目的 Agent 的定义可以指定模型、允许和禁止使用的工具、权限模式、预加载 Skill、MCP 以及最大轮数。Claude Code 的 Subagent 文档已经支持这些字段。
如果你要禁止工作代理写生产数据库，就不要只在提示词里写一句“不要写”。你应该只给它只读工具，或者用 PreToolUse Hook 阻止写操作。提示词表达的是要求，权限和 Hook 才能形成约束。
这也是 Skill 和 Subagent 最重要的区别。
Skill 解决的是“它应该知道什么、按照什么流程处理”；Subagent 解决的是“谁来做、在什么上下文里做、能用哪些工具、结果返回给谁”。如果你把所有东西都做成 Skill，大量说明最终还是会进入主会话，而且执行权限并没有真正受到限制。
宝玉老师整理过 Warp 的自我改进 Agent。Warp 没有让模型凭感觉修改自己的 Code Review Skill，而是自动收集工程师在 PR 中留下的评论，再由改进 Agent 把评论整理成候选规则，最后保留人工审核。规则写的是原则和原因，不是把每一个历史问题追加成一条“永远必须”。文件太长时，再按需加载引用资料。
我认为，这套机制真正解决的是团队经验怎么留下来。
一个高级工程师今天纠正了 Agent 的审查结果。如果反馈只停留在 PR 评论里，下周另一个 Agent 还会犯同样的错。只有当这条反馈被整理成经过审核的 Skill、测试或 Hook，整个团队才真正得到了一项可以复用的资产。
但你也不能让 Agent 自动吸收所有人的意见。评论可能是错的，不同项目的经验也可能互相冲突。能自动判断的事情，优先写成测试和静态检查；没有标准答案的事情，只接收有责任和领域知识的人提供的反馈，并且让每次规则变化都经过 Review。
否则所谓“自我进化”，最后往往只是文件越来越长，规则越来越多，模型越来越不知道该听谁的。
先做这三类 Agent
如果让我给一支 AI 团队实施这套方案，我不会先写十几个 Skill。
我会先挑 15 到 20 个每周都会发生的真实任务，记录五类数据：Fable 和总额度的消耗、一次验收通过率、人工接管次数、子代理数量、返工时间。然后只做三个工作代理：
- explorer：只读，负责搜索和读取代码，禁止修改。
- implementer：允许局部编辑和执行指定测试，不能修改发布配置。
- verifier：负责运行测试、查看差异和核对验收条件，不能替实现代理宣布任务完成。
主会话使用 Fable high 或 medium。它负责决定任务要不要做、应该怎么分、哪些证据足以证明完成。工作代理先用 Opus 或 Sonnet。
两周以后，我再看 /usage 的两条进度是否接近，质量有没有下降，子代理的冷启动成本有没有超过上下文隔离带来的收益。到这个时候，我才会决定哪些经验应该变成 Skill，哪些检查必须做成 Hook，哪些 Agent 需要更严格的权限。
这个顺序不能反。
没有真实任务、消耗数据和失败记录，先写一套看起来很完整的 Agent 体系，最后很可能只是在装修提示词。团队真正需要的不是更多 Agent 名字，而是一套可以回答下面三个问题的运行机制：
- 为什么把这项任务交给这个模型？
- 它做完以后，谁用什么证据验收？
- 这次失败留下了什么可以复用的改进？
我现在会怎么使用 Fable 5.1
用 Fable high 或 medium 做主会话，把它的 Token 花在需求判断、架构设计、任务划分和最终验收上。
大量检索、批量读取、代码修改和测试执行，交给 Opus 或 Sonnet。
每周用 /usage 的两条进度检查模型分工是否失衡，再用测试、权限和 Hook，把提示词里的“建议”变成工程里的约束。
不把 1M 上下文当成免费的长期记忆，也不会把 Max 当成默认的质量开关。任务换了就 /clear，阶段换了就整理状态后 /compact。模型升级时，重新检查旧提示词，而不是默认过去的经验永远有效。