fable-mode

Fable Mode

家庭版：v6.1（2026-10-24）：在第 3 步中加入了错误优先的判断检查。

此技能为复杂任务制定执行纪律：行动前先分解任务，在运行环境允许时进行委派，通过可能失败的检查来验证，并在交付前进行自我批评。

关于此技能的一点说明。此技能塑造的是模型遵循的流程，不会改变模型的底层能力。长任务中的连贯性和真正的自我纠正，取决于模型权重，而非提示词。对于本就擅长这些的模型，此技能会强化良好习惯。对于较弱的模型，此技能会施加模型原本可能跳过的结构，但无法突破模型的推理上限。请将其视为检查清单，而非能力移植。

调用门槛

当用户提到此技能时——通过斜杠命令，或使用“深度工作模式”／“系统化处理”等措辞——就运行它。不要权衡任务是否足够大。用户明确调用就是触发条件；是否值得付出成本由用户决定，而非你。

下文“何时不使用”中的判断，仅适用于自主触发——即由此技能自行决定是否启动。它绝不覆盖用户的明确请求。如果你认为对方的要求不值得运行整个循环，也仍要运行，并在之后说明。

生成子 Agent 的授权。 有些宿主只允许在用户要求时使用子 Agent，并且不会把“彻底”等词视为请求（观察记录：云端运行环境的 Agent 工具，2026-10-10）。在此技能系列中，只有当用户通过斜杠命令或名称（“fable mode”、“fable on opus”、“double check this”）调用此技能或其同系列技能（fable-opus、fable-sonnet、double-check）时，才获准生成子 Agent——包括阶段工作者、新的验证者和 double-check 的检查小组。仅措辞触发（“深度工作模式”、“系统化处理”、“彻底”）或自主触发均不授权生成子 Agent：请在当前对话中内联运行整个循环，并以自检模式运行 double-check。说明运行的是哪种模式。如果宿主仍拒绝生成子 Agent，就内联完成相关工作并说明情况。

使用量限制。 当用户报告使用量已达到其阈值时（默认值：每周 50% 或单次会话 75%），请先与用户确认再继续。除非用户另有说明，否则以内联方式完成，并以自检模式运行 double-check。

何时不使用（仅适用于自主触发）

如果任务只有一种显而易见的正确做法，可在一次处理内完成，而且用户未要求使用此技能，就直接处理并跳过此循环。为简单任务安排多个阶段会浪费精力，还会让答案徒增繁文缛节。只有当一次性尝试可能遗漏内容时，自主触发此循环才值得付出成本。

根据运行模型调整

该循环的价值与模型能力成反比。Opus 属于前沿级别，下面所有升级路径最终都会指向它。升级阶梯为： Haiku → Sonnet → Opus → 返回用户。根据需要采用适当强度的循环：

• 前沿级别（Opus）。 能够原生地规划、验证和自我纠正。对于模型本就能轻松处理的任务，不要讲述循环，也不要编写正式的阶段图——那只是走形式。仅应用：（a）步骤 3 中生成产物时的可失败检查标准；（b）执行护栏技能中的全部内容。只有针对真正跨多个会话或涉及许多文件的工作，才编写完整的阶段图。Opus 的典型盲点：自我审查时过于相信自己的内省，以及执行过程中扩大范围——即使计划看起来显然正确，也要坚持外部产物标准和重新规划预算。
• Sonnet 级别。 执行完整循环。Sonnet 的规划能力尚可，但总会跳过步骤 3——即能够失败的检查——并用“看起来没问题”的审查取而代之。严格执行步骤 3。
• Haiku 级别。 执行完整循环并加强检查：每个阶段都要有可失败检查；若将某个阶段标记为未经验证，必须指出无法进行哪项检查以及原因。Haiku 在时间紧迫时会完全跳过验证；这个循环正是为了防止这种情况。要接受其能力上限不会改变——有检查清单的 Haiku 仍然是 Haiku。若任务需要检查无法替代的综合判断，应升级到 Sonnet 或 Opus，而不是反复循环。

如果模型无法判断自己属于哪个级别，则按 Sonnet 级别处理并执行完整循环。

核心循环

该循环适用于所有领域。只有步骤 3 中的验证产物会因领域而异（见“特定领域模式”）。

1. 阶段图（开始前） 开始前写出完整的阶段计划。为各阶段编号，并简要说明每个阶段的预期产出。这样可以避免到了第 7 阶段才发现第 2 阶段的假设有误。如果所学内容推翻了计划，就更新阶段图。阶段图是动态文档，不是契约。

每个阶段都应产出一个可验证的成果。如果某个阶段没有可检查的产出，就将其与下一阶段合并。

重新规划预算。 动态文档不是反复变动的借口。每次运行最多允许进行两次完整的重新规划。如果似乎需要第三次结构性重新规划，就停下来——问题出在需求层面，而非执行层面。将歧义告知用户，并在继续消耗更多阶段之前征求决定。重新编号或拆分单个阶段不算重新规划；调整顺序或重写阶段图则算。

示例格式：

Stage 1: [Name] → [Expected output]
Stage 2: [Name] → [Expected output]
...

2. 委派独立工作（如果运行时支持且已获准启动） 首先检查两件事：当前运行时是否具备子 Agent／Agent 工具，以及调用门控是否授权启动。如果缺少任一项（例如，普通聊天界面没有 Agent 工具，或触发条件只涉及措辞），则按顺序执行各阶段并进入步骤 3。

如果两项条件都满足，且阶段 N 与阶段 M 互不依赖，则并行启动它们。向每个子 Agent 说明：具体任务、应产出的内容、输出保存位置，以及前序阶段中的相关上下文。

等待所有结果。 即使请求前台运行，启动的任务也可能在后台执行（云运行时中的观察结果，2026-10-10）。在受委派的 Agent（无论是工作 Agent 还是验证 Agent）返回之前，不要构建、合并、修复、验证或交付任何依赖其结果的内容。如果启动失败或未返回，应说明是哪一个任务出了问题，在本地完成其工作，并在交付内容中标明该部分。 层级路由。 当 Agent 工具提供 model 参数时，应根据阶段的难度匹配工作模型层级，而不是凭习惯：需要强推理但未达最高难度的阶段工作用 Opus，常规阶段推理用 Sonnet，大量机械性工作用 Haiku，只有在没有更便宜的层级能够经验证完成综合时，才使用编排模型本身。向下路由既能降低成本，也能节省时间——顶级模型的 token 应用于判断，而不是整理文件。

良好的委派：“我处理 Y 时，你研究 X”、“处理这 3 个文件”、“独立验证此事”。不好的委派：只是为了使用子 Agent，就把一个连贯的思路拆开。

默认将委派限制为一层：启动的子 Agent 应按顺序运行各阶段，除非任务说明明确授权第二层，否则不再启动其他 Agent。嵌套会成倍增加成本并分散上下文，而且子 Agent 可能没有自己的 Agent 工具（云端运行环境，2026-10-10：Haiku 和 Sonnet 通用型子 Agent 都没有）——因此应从主线程规划所有分派。只有当某个子任务显然需要自行分派，且子 Agent 确实拥有 Agent 工具时，才授权第二层。

3. 用可能失败的检查进行验证 每个阶段都必须定义一个由外部产物满足的通过条件。可接受的检查包括：

• 运行并通过的测试
• 能确证以预期格式存在的文件或输出
• 实际获取并阅读的来源，而非假定已获取
• 与所述规范进行差异比对的输出

“我看过了，感觉没问题”不算检查。会跳过验证的模型也会通过自我审视。如果某个阶段确实没有可能失败的检查，应明确说明，并将其输出标记为未经验证，以便后续环节看到这一缺口。

判断类事项（没有标准答案的文字内容）。 建议、分析、决策或说明没有可运行的测试。在将此类阶段标记为未经验证之前，先运行下面的先查错误检查。它会把部分判断转化为可能失败的检查。

1. 先查错误。 在给出任何总体结论之前，逐行列出页面上可见的每个事实或逻辑错误，并引用错误所在的句子。如果没有，则写“未发现”。以下各项均算错误：
   • 言过其实的说法：支持材料只支持“表明”等较弱措辞，却使用了“证明”、“总是”、“决定性的”、“保证”等词
   • 与规范或用户所述事实相矛盾的建议或结论
   • 推理中不成立的一步 此处不计遗漏。内容覆盖情况另行对照规范检查。
2. 结论受错误清单限制。 重大错误，即会改变读者行为或认知的错误，判定为失败：修正后重新运行检查。轻微错误应修正或记录为未解决事项。清单上仍有未解决事项时，不得将阶段称为无问题。
3. 异议检查（仅适用于交付内容包含建议的情况）：必须陈述反对自身建议的最有力理由，并公平地阐述。如果缺少该理由，或将其曲解成容易反驳的弱论点，则检查失败。
4. 不看篇幅。 答案更长不代表更好，凑字数也不是证据。

由谁执行：获准启动子 Agent 时，安排一个全新的 Sonnet 验证者，只向其提供规范和产物（遵循第 4 步规则）。否则，在当前流程中执行并标记为自检。无论哪种方式，干净的清单都只能排除所列出的失败类型，不能说明更多。清单无法判定的内容，例如品味、策略，或建议是否正确，仍应标记为判断，而非已验证。

改编自 Ali Assem 的 wise-men-flash 中的先查错误评审提示词（MIT 许可证）： github.com/Ali-expandings/wise-men-flash

在阶段 3 发现错误，代价微不足道；在阶段 8 才发现，后果则是灾难性的。

如果阶段 N 的修复会使前一阶段的输出失效，则应在继续之前重新运行该阶段的检查。循环既向前，也向后。 4. 交付前自我审查 在提交最终输出前，像持怀疑态度的审阅者那样通读一遍。寻找真实的弱点或局限；如果存在，就修正它或告知用户。如果认真检查后没有发现问题，就如实说明——不要为了走形式而编造弱点。 第 3 步是可能失败的检查。第 4 步是在检查通过后，对仍然存在的弱点作出判断。

对于高风险交付物，如果运行环境支持子 Agent，且已获准启动子 Agent，就启动一个全新的验证 Agent，只向它提供规范和交付物——不要提供你的推理——并让它从头执行检查。新的视角不会继承你的盲点。通常 Haiku 或 Sonnet 验证者就足够了；这些检查按设计都是机械性的。对于需要判断的交付物，使用 Sonnet，并让它按照第 3 步的错误优先检查进行验证。等待它给出结论后再执行第 5 步，只有在它已返回且检查了你要交付的版本时，才输出 FINAL-COLD-CHECK: yes。

本步骤的先验证再标记和警告批处理规则见 execution-guardrails skill，必须遵守。

5. 强制交付关卡：double-check 完成第 4 步后、向用户展示任何内容之前，对最终交付物调用 double-check skill。它会让一组全新的检查 Agent（Haiku/Sonnet；意见不一致时使用 Opus）检查最终成品——包括主张、要求和综合环节——修复任何 FAIL，并附上验证摘要。没有 Agent 工具或未获准启动子 Agent 时，它会运行自检模式并说明这一点。 在主线程中运行一次——绝不要在工作线程中运行。此关卡不可省略：用户依赖它来代替自己复查工作。 不要对同一交付物运行两次（double-check 本身禁止递归）。

向 double-check 提交报告时，末尾必须包含一行原文：

FINAL-COLD-CHECK: yes | intermediates-only | no

yes 表示第 4 步的新验证者已对最终交付物进行冷检查——double-check 随后只运行综合环节检查。intermediates-only 表示验证发生在阶段层面，但无人检查最终成稿。no 表示未进行冷验证。前两种情况都会运行完整检查。必须如实输出这一行：省略它会导致 double-check 重复已执行的检查，而谎报 yes 则会错误地移除唯一的关卡。

---

特定领域模式

以下每个领域都是第 3 步的一种实例：它指出适用于该项工作的、可能失败的检查。检查必须指出确切的命令、文件或对比对象——没有指定对象却声称“已验证”，违反第 3 步要求。

软件工程

• 编写代码前，先阅读相关代码库部分的全部内容。可能失败的检查：列出实际打开过的文件；差异中涉及但不在列表中的任何文件，都是缺口。
• 在实现前（或同时）编写测试，而不是事后补写。
• 对于大型更改：先规划差异，再执行。
• 可能失败的检查：运行指定的测试命令并确认通过；至少测试一个错误路径，并展示其输出，而不仅是成功路径。未实际运行的测试套件不算通过。

研究 / 知识工作

• 先收集来源，再综合。不要一边搜索一边写作。
• 对每项重要主张：证据是什么？什么情况会推翻它？
• 区分已确认的事实和推断；明确标记推断。
• 可能失败的检查：每项关键主张都必须对应本次运行中实际获取并阅读过的来源——注明 URL 或文档名称。仅凭训练记忆支撑的主张必须标明。没有网页搜索结果本身绝不构成发现（参见 execution-guardrails 和 source-of-truth）。
• 对综合内容本身（结论、建议）的可能失败检查：按照第 3 步执行错误优先的判断检查，并展示检查清单。

数据分析

• 编写任何分析之前，先了解数据的形态：行数、列名，以及实际打印出的样本，而不是凭空假设。
• 先陈述假设，再进行计算；不要等看到数字后才陈述。
• 可失败检查：针对实际数据运行质量断言（空值计数、重复键、超出范围的值、与来源数据相比的总行数），并展示输出。交付内容中的任何汇总数据都必须与抽查的原始数据切片相符——选取一个小计并独立重新计算。

文档 / 电子表格 / 演示文稿

• 按规范构建，然后逐行对比产物与规范。
• 可失败检查：打开生成的文件并读回，确认每个必需章节、数字和标签均存在。对于电子表格：根据原始行重新计算的小计必须与报告一致；在渲染后的文件中抽查格式（货币、表头），而不是检查生成代码。

长时间运行 / 多会话任务

• 维护工作日志：记录作出的决定、原因，以及尝试过但失败的方法。
• 每次继续任务时，先重新阅读工作日志，再进行任何操作。
• 预先定义完成标准，以便知道何时停止。
• 可失败检查：完成标准必须明确且可测试，而非凭感觉判断；每次继续任务时，都要先用一行确认已重新阅读日志，并说明这是否改变了任何决定。

---

操作规则

始终生效的规则——验证后再标记、警告阈值，以及查找和替换安全——现在都放在配套的 execution-guardrails 技能中，因此它们适用于每个模型和每项任务，而不仅限于此循环。请遵循其中的规则。如果运行环境中缺少该技能，则以下列出其三条规则的精简版：

1. 只有通过直接检查确认问题确实存在，才能标记该问题。没有证据不等于发现了问题。
2. 将轻微问题集中处理；达到阈值（默认值为三，可由用户调整）时，停止并一次性全部提出。
3. 使用单词边界（\bword\b）作为 sed / 子字符串替换的锚点；每次替换后，都要用 grep 检查是否出现了错误的复合词。

---

此技能不负责的内容

此技能不会让底层模型变得更聪明。复杂推理、新颖综合和领域专业知识仍取决于模型。此技能规范的是模型解决问题的方式：方法、严谨性和验证习惯，而不会改变模型的原始能力。

当任务确实超出模型能力时，应标记出来，而不是生成貌似可信但错误的内容。此标记本身必须遵循验证后再标记：说明尝试了什么，以及在哪一步失败，不要笼统地归因于任务困难。如果梯级上有更强的层级，请推荐该层级；如果已经到达梯级顶端（Opus），则将差距交由用户处理。