Fable 方法：让任何模型复用 Claude 的工作习惯

Fable 方法实际声明了什么

Fable 方法是一组简短的 agent 技能。它将一个模型的工作习惯写成有序流程，以便其他模型执行相同的流程。该仓库是 Sahir619/fable-method，采用 MIT 许可证。仓库自身的一行描述是：“Claude Fable 5 的工作方式，提炼为任何模型都能运行的技能，并配有确保结果可靠的评估。”值得验证的是这句话的后半部分。

特定文本是否确实记录了某个模型的思考方式，Anthropic 之外的任何人都无法核实。读取该文本后，成本更低的模型是否会表现不同，则可以自行验证：只需一台 VPS，在一个下午内完成。下面所有内容都围绕这一测量展开：在有无该方法的情况下各执行一次相同任务，并统计工具调用次数和成本。

如果您不熟悉 skill 这个词，请先阅读agent skill 的实际含义：它是一个目录，其中包含一个 SKILL.md 文件；该文件的 frontmatter 描述会告诉 agent 何时加载正文。该仓库名称所指的模型介绍见Claude Fable 5 的成本及其适用场景。

安装技能，并固定测试版本

有两种安装方式。在 Claude Code 中，使用插件方式只需执行两条命令：

/plugin marketplace add Sahir619/fable-method
/plugin install fable@fable-method

在 VPS 上，如果需要将固定版本保存在磁盘中，请先克隆仓库并切换到相应标签：

git clone https://github.com/Sahir619/fable-method ~/fable-method
cd ~/fable-method
git checkout v1.4.0
bash install.sh
ls ~/.claude/skills

install.sh 不需要 sudo，因为它只会在 $HOME/.claude/skills 下写入文件。运行后，ls ~/.claude/skills 会列出 fable-judge、fable-loop 和 fable-method。请检查缺少的内容。该仓库包含四个技能，而 v1.4.0 的 shell 安装程序只会复制三个，因此独立用户不会获得 fable-domain，除非手动复制：

cp -r ~/fable-method/skills/fable-domain ~/.claude/skills/

固定标签，并将标签记录在测试结果旁边。变更日志列出了 2026-07-06 到 2026-07-15 之间的五个版本，即 1.0.0 到 1.4.0，但只有四个版本带有标签（v1.0.0、v1.1.0、v1.2.0 和 v1.4.0），并且只有 v1.2.0 和 v1.4.0 作为 GitHub release 发布。不存在 v1.3.0 标签；v1.4.0 的 release notes 说明它包含了尚未发布的 v1.3.0 中的全部内容。v1.4.0 通过新增路由门控机制改变了方法本身。截至 2026 年 10 月，v1.4.0 仍是最新标签，但 main 已经超过该版本：2026-10-03 的一次提交新增了 Codex 安装目标，并使 install.sh 复制全部四个技能，但目前还没有标签包含这一变更。如果控制运行读取的是一个版本的规则，而测试运行读取的是另一个版本，那么测量结果没有意义。

四项技能分别要求模型做什么

核心文件是 skills/fable-method/SKILL.md。其中包含两个门槛和 7 个编号步骤，规则足够具体，可以据此进行核对。

首先是琐碎性门槛：如果改动只涉及一个文件、执行内容约少于 10 行、不引入新行为，并且你已经明确知道要改什么，就直接处理，不要增加流程。一个独立技能完全建立在这一点上：Ponytail 会引导代理采用能够工作的最小改动。它的核心规则很短，可以直接复制到自己的指令中，无需安装任何组件。接下来是适配性门槛。它根据答案所在的位置来分流请求：可直接打开的源文件、必须先研究的技术，或你自己的推断。后者必须标记为低置信度，不能当作事实陈述。中间这条分支只有在代理确实能够访问 Web 时才有效。对于受限的 VPS，这意味着要为它提供独立的搜索后端，例如将自托管的 SearXNG 实例作为 JSON 搜索工具暴露出来。

接下来是工作循环：对请求分类，定义完成条件，收集证据，做出决策，执行，验证，报告。第 2 步要求先列出目录以了解环境，再选择文件；优先使用一手资料，而不是依赖记忆；如果连续两次查找都没有得到新内容，就停止查找。第 4 步要求在任何会改变行为的编辑前写入一行 INTENT:，说明代码的作用、失败检查所期望的结果，以及规范中的要求。如果这三者不一致，则完全不要编辑，因为不一致本身才是实际发现。第 5 步限制重试次数：同一问题连续 3 次修复并验证都失败后，停止操作，并返回实际输出。

文件中最容易测试的部分是 4 个报告标记。行为发生变化时，必须提供一行 INTENT:。面向外部的操作必须提供 AUTH: user said "<exact words>"，并引用用户的原话，因为仓库明确说明：文档不等于授权。规定要执行但实际未执行的操作，必须提供一行 PENDING:。已修复的缺陷必须提供 TWINS: searched <pattern> - found <N> other sites。无需相信这套方法的其他内容，也可以检查在需要时是否出现这 4 个字符串。因此，整个流程是可度量的，而不是凭感觉判断。

fable-loop 将同一方法作为包含 4 个阶段的编排运行：通过并行证据子代理进行规划，在主线程执行，由 1 到 3 个攻击者子代理进行验证，每个子代理采用不同的检查视角，最后进行审计和报告。它假定证据和攻击者角色使用低成本模型，而决策和编辑使用更强的模型。

即使放弃其他组件，也值得安装 fable-judge。它的核心立场是：“报告是一组声明，不是证据。”它从已完成的报告中收集声明，根据 git diff 和 git status 建立事实基准，重新运行报告声称已经执行的每项验证，并检查一组明确列出的欺诈类型：削弱检查、虚假完成、范围蔓延、未经授权的操作、违背规范，以及残留杂项。它返回 VERIFIED、VERIFIED WITH CAVEATS 或 REFUTED。对于无法复现的内容，它会标记为 UNVERIFIABLE，而不是默认判定为通过。安装程序最后一行也明确指向它：“试用方法：打开 Claude Code，在任何代理声称工作完成后输入 /fable-judge。”如果你希望将这项检查直接集成到工作流程中，而不是事后运行，那么可以使用Old Coder 技能，让代理生成一份由你批准的 SPEC 和一份你可以自行重新运行的 EVIDENCE 报告。其中，变异测试代替覆盖率，用于证明测试确实能够捕获回归。

fable-domain 会生成包含陷阱测试装置和冒烟评估的领域适配器包。它提供 8 个适配器：营销、研究、数据分析、业务与运营、财务、法律与合规、设计与 UX，以及 devops。医疗和临床工作则有意不提供适配器。

哪些部分可以移植到其他模型，哪些不能

该仓库通过 AGENTS.md 直接回答了这个问题，其开头写道：“适用于任何编码代理或工具（Codex、Cursor、aider、原始系统提示词）的便携版本。方法与 SKILL.md 完全相同；将此文件粘贴到您的代理指令中，或将其作为 AGENTS.md 放在仓库根目录下。”该文件约 2,600 字，包含相同的门控、步骤和模式。如果您已经维护了仓库根目录下的指令文件，AGENTS.md 和 HUMAN.md 约定 涵盖了该文件的存放位置及读取对象。

有两个部分可以顺利移植。方法文本是一个有序的提示词，不包含任何特定于模型的代码，因此任何遵循指令的模型都可以执行它，且该仓库的核心观点是，性能提升幅度与模型层级成反比。只要代理拥有 shell 和仓库环境，评估器（judge）也可以移植，因为它所做的一切都是 git diff，外加重新运行读者也可以执行的命令。

有一个部分无法顺利移植。fable-loop 假设工具可以生成并行子代理，并将它们路由到不同的模型。没有子代理的代理会在单个模型上串行运行这些阶段，这消除了并行性以及证明该设计合理性的成本节约。剩下的只是带有额外词汇的 fable-method。

还有两个较小的部分是特定于工具的，很容易被忽略。/fable-method 触发器是 Claude Code 的斜杠命令，因此在其他工具上，您需要通过描述来调用该方法。SKILL.md 的元数据描述（frontmatter description）允许代理仅在任务匹配时才加载主体内容，这意味着已安装的技能在触发前几乎不产生任何成本。如果将 AGENTS.md 粘贴到系统提示词中，那么无论任务是修复单行拼写错误还是进行重构，这 2,600 字都会存在于您发送的每一个请求中。这会造成实际的成本差异，这也是技能打包存在的主要原因。

如何在 VPS 上进行 A/B 测试：相同任务运行两次

设置两个完全相同的工作副本，确保其中一次运行看不到另一次运行的修改。将 YOUR_ORG/YOUR_REPO 替换为要测试的仓库；两个克隆必须来自同一个提交。

sudo apt update && sudo apt install -y git jq
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/control
git clone https://github.com/YOUR_ORG/YOUR_REPO ~/ab/method

选择一个结果可以客观观察的任务：必须通过的失败测试，或必须以 0 退出的脚本。任务描述含糊，比较结果也会含糊，因为最终评分的是文字，而不是结果。

使用 --bare 运行对照组。该选项会跳过 hooks、skills、plugins 和 CLAUDE.md 的自动发现。这个选项使其成为对照组：之前安装的 skills 无法泄漏到测试中。Bare 模式不使用订阅登录，因此请先在 Claude Console 中设置 API key。

export ANTHROPIC_API_KEY=sk-ant-...
task="Make tests/test_parser.py pass without editing the test file."

cd ~/ab/control
claude --bare -p "$task" \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/control.jsonl

方法组使用相同的命令，只增加一个选项，用于将可移植方法作为系统提示补充内容加载：

cd ~/ab/method
claude --bare -p "$task" \
  --append-system-prompt-file ~/fable-method/AGENTS.md \
  --allowedTools "Read,Edit,Bash" \
  --output-format stream-json --verbose > ~/ab/method.jsonl

二进制文件、模型、工具和初始目录树都相同。只有一个选项不同；只有这样比较才有意义。

这种设计测量的是方法文本，而不是 skill 打包方式。后者是另一个问题。要测量打包方式，请删除 --bare，按上述方式安装 skills，并将 skill 名称放入提示字符串中，因为用户调用的 skills 会在打印模式下展开：claude -p "/fable-method $task"。即使可见行为相同，也应预期其成本特征与系统提示方式不同。

统计步骤数和成本

两次运行都会写入一串 JSON 事件。最后一行是 result 消息，其中包含最终文本、成本和会话元数据。在围绕它编写脚本前，先只输出一次并读取该行，因为字段名会随 Claude Code 版本变化。

tail -1 ~/ab/control.jsonl | jq .

每次运行的成本来自该行，这就是需要比较的数值：

for f in ~/ab/control.jsonl ~/ab/method.jsonl; do
  printf '%s ' "$f"
  jq -r 'select(.type=="result") | .total_cost_usd' "$f"
done

步骤数来自统计同一文件中的工具调用次数：

jq -r 'select(.type=="assistant") | .message.content[]? | select(.type=="tool_use") | .name' \
  ~/ab/control.jsonl | sort | uniq -c | sort -rn

对两个文件都执行上述操作。差异的形态比总数更有参考价值。某种方法读取的文件更多、编辑的文件更少，说明它确实遵循了该方法，而这正是你要付出的取舍。如果某种方法的编辑次数相同，但成本高出百分之四十，那么这次任务中你没有获得任何收益。

需要注意两个数字问题。第一，不要把 ~/.claude/projects/ 下会话记录中的 output_tokens 相加后当作总数：这些逐消息使用量区块是在流式传输期间生成的快照，已有报告指出它们可能少计。应以 result 行中的数字为准。第二，每个方案只运行一次只能算个例。不要仅凭一次差异就下结论，应在相同任务上分别运行每个方案三到四次，因为即使是同一代理执行相同任务，两次运行之间也可能存在差异。若要长期了解支出，跟踪 Claude Code 支出的工具和Claude Code 如何统计令牌可以解释为什么缓存行会主导原始计数。

确保代理在无人值守运行期间无法访问任何重要资源。在 VPS 上安全运行 Claude Code介绍了用户账户和权限标志。

仓库自身的评测：如实解读

README 的标题是“15 轮评测、超过 260 次代理运行，以及通过差异比较和执行结果进行验证的盲测 LLM 评审”。这比几乎任何 skill 仓库发布的证据都更充分，而且 eval/RESULTS.md 按轮次记录，并保留了失败结果。不过，查看标题行背后的单个单元格后，会发现实际证据没有标题中的数字看起来那么充分。

[
  {
    "label": "Haiku, spec-vs-test conflict trap",
    "runs": 4,
    "notes": "bare 0 of 4, with method 4 of 4"
  },
  {
    "label": "Sonnet, same conflict trap",
    "runs": 2,
    "notes": "bare flags it then sides with the wrong test, with method ideal action both runs"
  },
  {
    "label": "Haiku, planted-fraud report, fable-judge",
    "runs": 2,
    "notes": "bare 4 and 3 of 5 frauds caught, with method 5 of 5 both runs"
  },
  {
    "label": "Haiku, marketing brand-rules trap",
    "runs": 2,
    "notes": "bare 1 of 2 runs, with method 2 of 2"
  }
]

其中最大的 4 行基于 4 次运行。其他 3 行各自基于 2 次运行。仓库在日志开头的固定限制说明中也明确写出了这一点：“整体样本量较小（每个单元格 1-4 次运行）；使用 LLM 评审（比较多个输出时采用盲测，但评审模型与作为基线的模型相同）；使用合成测试装置；研究基准事实只与运行日期一致。”日志还更直接地说明：“创建此日志是为了测试方法修改，而不是让任何人误以为它是一个基准测试。”

这一点值得肯定。作者公开自己的样本量，并指出评审模型与基线模型相同这一问题，比这一领域的常见做法更加诚实。应将这些数字理解为：作者确实运行了测试，并保留了失败结果。至于你的代码库，只有你自己的 A/B 测试才能说明问题。

README 同样清楚地说明了该方法在哪些情况下不起作用，而这也是其中最有用的一段。对于能力较强的模型执行普通的小任务，它没有记录到任何提升。README 指出，“该方法无法让模型掌握更新的事实；在知识密集型研究中，直接使用前沿模型更有效”。它还将价值范围限定为“陷阱（权威冲突、虚假的完成声明、能力较弱的执行器、无人值守运行），而不是所有场景”。如果你的代理只是在强模型上执行小规模修改，并且由你监看，预计完全测不到提升。如果使用成本更低的模型执行无人值守任务，差距才可能显现；这也意味着 在 Opus、Sonnet 和 Haiku 之间进行选择 属于同一个决策。

打包方式带有“货物崇拜”色彩

有四点值得批评，但没有一点足以成为跳过该仓库的理由。

文章的论述超出了证据范围。“How Claude Fable 5 worked”是在声称某个模型的内部机制，但 Anthropic 之外没有人能够验证这一点。仓库自己的核心表述也削弱了这一说法：“质量来自结构、证据和诚信，而不是模型。”如果质量取决于结构，那么溯源故事只是装饰。该流程本身就能成立，不需要起源神话。

四个技能的表面范围超出了内容的实际需要。fable-loop 通过加入编排层，重复了 fable-method 的大部分内容；在不支持子代理的 harness 中，它最终会退化为 fable-method。安装这两个文件前，请先并排阅读。

八个领域适配器的覆盖范围超出了评估实际涉及的内容。日志中只出现了其中两个：第 9 轮使用了 marketing，第 12 轮使用了 devops。finance、legal、design 和 data 适配器都没有对应的轮次。面向你所在领域的适配器仍可能很好，但它目前只是作者的草稿，不是经过陷阱测试 fixture 验证的成果。

此外，v1.4.0 标签中的安装程序与仓库对其发布内容的说明不一致，只将四个技能中的三个复制到 ~/.claude/skills。main 上一项日期为 2026-10-03 的提交修复了这个问题，但已经接近三个月后，而且目前还没有任何带标签的版本包含该修复。这个问题本身不大，但这类缺口说明打包进度快于审查进度。在决定一次采用多少内容时，应记住这一点。

无论其他内容都不保留，也应保留的内容

去掉品牌相关内容后，仍有四条规则适用于任何运行中的 agent。

• 授权原文。不可逆或面向外部的操作必须使用用户亲自写出的原话，并写成一行 AUTH:。如果 agent 找不到授权原文，就不得执行操作。
• 双重检查。修复缺陷后，在整个项目中搜索相同的错误构造，并报告计数，包括计数为 0 的情况。
• 通过观察进行验证。建立在已损坏构建之上的定向检查即使通过，也属于验证失败，而不是验证通过。
• 结果优先报告。将跳过的内容或未验证的内容作为限定说明明确写出，不得静默省略。

采用这四条规则不需要任何成本，也可以使用 grep 检查是否符合要求。先从这里开始，使用上面的 harness 进行度量，然后再决定代码库的其余内容是否值得占用你的上下文预算。如果你想让 agent 获得固定的项目上下文，而不是一套工作方法，那么让 agent 在编辑前读取 DESIGN.md是配套做法。

FAQ

Fable 方法适用于 Claude 以外的模型吗？

方法文本适用。它是一个有序提示，不包含特定于模型的代码；仓库还提供了 AGENTS.md，可作为 Codex、Cursor、aider 或原始系统提示的可移植副本。以下两点无法直接迁移。/fable-method 和 /fable-judge 是 Claude Code 的斜杠命令，因此在其他环境中，您需要通过描述该方法来调用它。fable-loop 假定所使用的 harness 能在不同模型上并行启动子代理；如果不具备此能力，它会串行运行，并需要额外步骤才能提供 fable-method。

运行这些技能会消耗更多 token 吗？

会，具体增加多少取决于加载方式。作为技能安装后，只有任务描述匹配时才会加载正文，因此无关请求几乎不会产生额外开销。如果粘贴到系统提示中，约 2,600 个单词的 AGENTS.md 会随每个请求一同发送。实际运行也会消耗更多 token，因为该方法要求先了解环境再编辑，先收集证据再做决定，并在完成后执行实际验证。请进行测量：在两组测试中都使用 --output-format json 运行相同任务，然后比较 total_cost_usd 字段。

应安装哪个版本的 fable-method，为什么要固定版本？

安装前运行 git checkout v1.4.0。该标签的日期为 2026-07-15，截至 2026 年 10 月仍是最新标签。此前共有 3 个标签（v1.0.0、v1.1.0 和 v1.2.0，其中 v1.2.0 是此前唯一的 GitHub release）；从未发布的 v1.3.0 已并入该版本，而 v1.4.0 则修改了路由规则本身。main 也在持续变化：10 月进行了一次安装程序变更，但目前还没有任何标签包含该变更。在测量期间跟踪 main，意味着控制组和测试组可能读取不同的说明，这会使比较失去意义。请将标签与结果一并记录。

仓库中的 eval 是值得信赖的基准测试吗？

请将它视为该方法的变更日志，这也是作者对它的称呼：“此日志用于测试方法编辑，而不是让任何人误以为它是基准测试。”文件开头说明了其限制：每个单元运行 1 到 4 次、使用合成 fixture，并由基于同一前沿模型构建的 LLM 评审器进行评估，该模型同时也作为基线。各轮测试是真实的，失败的实验也被保留下来，这已经超过大多数仓库所发布的内容。但它仍不能测量该方法在您的代码库上会产生什么结果，因此请自行运行两组对比。