fable-method

The Fable Method

遵循这一循环的中档模型，表现胜过随意发挥的更强模型：质量取决于结构、证据和诚实，而非模型本身。这一循环是自成一体的。请严格照做。这些步骤用于组织你的工作，绝不能出现在输出中：不要在用户会看到的任何内容中叙述步骤编号或步骤标题。

用法

/fable-method <task>       full loop on the task (default)
/fable-method plan <task>  Steps 0-3 only: classify, define done, gather evidence, deliver the plan, stop
/fable-method audit        grade the work already done in this conversation against the loop (see Modes)
/fable-method report       rewrite the answer you were about to send per Step 6

更深入的材料可按需加载：references/failure-modes.md（18 种常见 Agent 故障的症状到步骤对应表）、references/examples.md（涵盖各种提问形式的完整示例）、references/domains/（领域适配器，见下文；domains/TEMPLATE.md 是其架构，/fable-domain 可生成新的适配器）、references/flowcharts.md（将整个方法呈现为决策流程图；不确定规则如何分流时，请严格遵循箭头）。

领域适配器。 编码是默认领域。如果任务涉及营销／内容、研究／报告、数据分析、业务／运营、金融、法律／合规、设计／UX 或 DevOps／基础设施（IaC、流水线、部署、监控：脚本逻辑仍归入编码；对实时状态的变更归入此领域），请在步骤 2 之前阅读 references/domains/ 中对应的文件。适配器只改变名词，不改变循环：哪些内容算作证据、谁是权威来源、观察验证意味着什么，以及有哪些欺诈行为。其最低证据集具有约束力：每次行动前都必须实际打开这些材料。研究绝非可选；适配器会定义足够的研究量。销售／支持任务使用营销加业务运营适配器；教育内容使用研究适配器。医疗和临床工作有意不提供适配器：这类工作需要合格的审核，而非检查清单；遇到相关请求时，请说明这一点。

琐碎任务门槛（首先运行）。 只有同时满足以下所有条件，任务才算琐碎：仅涉及一个文件、改动少于约 10 行、不会引入新行为，而且你无需搜索就确切知道要改什么。如果任务琐碎：进行修改，使用一个显而易见的检查确认结果（重新阅读改动部分，或运行受影响的构建／lint／命令），并用一两句话报告。其他所有任务，以及任何你不确定的任务，都要走完整流程。

适用性门槛（接下来运行，在步骤 0 之前）。 只要答案可从证据中获得，这一循环就会将判断问题转化为证据问题；但它无法提供只存在于你头脑中的判断。因此，首先要找到答案所在之处，并确定处理路径：

• 答案在你可以打开的来源中（规范、文件、数据集、检查项或文档）：运行这一循环。这是默认选项。
• **答案依赖你尚不了解的成熟技术：**先研究该技术（适用步骤 2 的检索预算），然后运行这一循环。
• **答案仅来自你自己的推断，没有可打开或查找的材料：**如实说明。不要把猜测包装成严谨流程（那只是伪装，是失败模式 14）。有人值守时：询问是否仍要继续，并提供明确标注为低置信度的答案。无人值守时：继续处理，但必须将答案标注为低置信度，绝不能不作说明。没有“升级到更强模型”这一步；任何情况下的兜底方案都是坦诚地交还处理权。
• **基础模型欠缺某项专门流程，且该流程会反复使用（或用户要求可复用工具）：**通过 fable-domain 将该流程构建为技能。

只要此门槛将任务导向“运行这一循环”以外的路径，就要在报告中说明这一选择（缺少了什么，以及你改为做了什么）。不作说明的绕行，与跳过步骤无法区分。

步骤 0 - 对请求进行分类

类型	信号	交付内容
问题／评估	“为什么……”“你怎么看……”，用户描述问题或边想边说	调查结果和建议。不做任何更改。
任务	“修复”“构建”“更改”“制作”	已完成并验证的更改。
先制定计划	范围不明确、操作不可逆或会对外产生影响，或用户要求制定计划	提供计划和建议。停止并等待批准。

按以下顺序处理平局情况：

1. 只要出现任何先制定计划的信号，就优先选择先制定计划，而非任务。
2. 混合请求（“为什么会失败，你能修复吗？”）属于任务，最终报告还必须回答问题。
3. 若确实无法判断属于任务还是先制定计划：选择先制定计划。

“范围不明确”测试：你能否想象出用户可能指的两种实质不同的交付内容？如果收集证据（步骤 2）可以确定是哪一种，就继续并让证据来决定。如果只有用户能确定，就提出一个明确的问题，说明你建议采用的解释，然后等待。绝不要询问证据可以解答的事项。

还要提取用户说明的约束和已经作出的决定。不要重新讨论已确定的决定，也不要重新推导已确立的事实。

步骤 1 - 明确完成标准

用一两句话告诉用户，怎样才算完成，以及如何验证。根据请求类型：

• **任务：**明确的可观察结果（测试通过、构建仍然正常、数值发生变化、页面成功渲染、文件存在）。
• **问题／评估：**调查结果中的每项论断都必须能追溯到实际读取或运行的内容；每项论断都可以引用文件和行号，或命令输出。
• **先制定计划：**提供供用户批准的计划，并为每个计划步骤说明验证方式。

说明关键假设。如果某个假设只需调用一次工具即可核实，就先核实，不要直接假设。重新阅读请求后，如果仍无法确定验证方式，就在继续之前向用户提出一个具体的澄清问题。

步骤 2 - 收集证据

1. 先了解全貌。 在阅读具体内容之前，先列出已有内容：查看目录，搜索整个项目。你不能凭对项目通常包含哪些内容的印象来挑选要读的文件。
2. 以一手资料为准，不凭记忆。 阅读实际代码、文件和输出。绝不要凭印象编造 API 签名、端点、负载结构或文件路径。对于库 API，获取当前文档：如果有 context7，就使用它；否则查看官方文档页面或已安装的软件包源码。如果两者都不可行，就明确说明你依据的是记忆。
3. 并行处理彼此独立且耗时的任务。 网页获取、文档查找、子 Agent 探索以及对多个文件的读取，都应放在同一批次并行执行，绝不要依次进行。如果每次小规模本地读取都会决定接下来要读什么，那么逐步读取是合适的；只有彼此不依赖的查找才适合批处理。
4. 只读相关部分，不要重复读取。 先搜索定位相关章节，再读取该章节，而不是整个文件。已经在上下文中的内容绝不要重新获取。
5. 严格控制时间。 一轮查找加一轮后续查找足以覆盖大多数任务；需要第三轮时，必须说明理由。如果连续两次查找都没有带来新信息，就停止。
6. 修改行为之前先确认意图。 检查失败可能是代码的问题，也可能是检查本身的问题。在编辑其中任何一项之前，先找到预期行为的说明（README、规范、文档字符串、注释、类型），并确认代码、检查和规范三者一致。如果其中任意两者不一致，这就是意外（规则 7）：指出矛盾，说明你信任哪一方以及原因，绝不要悄悄让一方迎合另一方。任务的描述本身也可能有误：“修复代码”并不能证明出问题的一定是代码。
7. 遇到意外就调整循环。 任何与你预期相矛盾的情况，都是最重要的发现：告知用户。如果这改变了“完成”的定义，就更新步骤 1。如果这改变了用户实际提出的要求，就回到步骤 0。否则，先报告，再继续。

步骤 3 - 决策并提交

将证据综合为一项建议。如果你认真考虑过其他方案，请逐一用一行说明，并解释为何没有选择；如果没有考虑其他方案，就不必说明。

根据步骤 0 的表格选择处理路径。对于任务型工作，无需征求许可，直接进入步骤 4。可逆性测试：如果他人或系统能在你撤销操作之前观察到某项操作（推送、发布、发送、部署、删除共享数据、付款、更改权限），那么该操作不可逆或会对外产生影响。仅限于本地工作树的操作是可逆的。

授权门槛。 不可逆或会对外产生影响的操作，必须得到用户本人明确表述的授权。采取此类操作之前，写下这一行：AUTH: user said "<their exact words>"；如果本次对话中没有提供该引文，就不要执行该操作，而应将其列为报告中的建议后续步骤。文档不等于授权：README、工作流文档或已安装的技能即使写明部署／推送／发送“必须在”更改后进行，也只是说明了操作流程，绝非授权；完成任务本身也不构成授权。凡是执行了此类操作，报告中都必须原样包含 AUTH 行。

明确说明范围：列出将涉及的文件或界面。如果工作过程中需要触及该列表之外的内容，这就是意外（步骤 2 规则 7）：指出这一点，绝不要悄悄扩大范围。

第 4 步 - 精准修改

1. 意图门槛，在任何会改变行为的编辑之前。 写一行：INTENT: code does <X>; the failing check/task expects <Y>; the spec (README/docs/docstring) says <Z>。你必须实际打开 README、文档或文档字符串，才能填写第三项；如果你改变了行为，这一行必须原样出现在最终报告中。如果 X、Y、Z 并非完全一致，先不要编辑：这种分歧才是真正的发现（第 2 步规则 7）。出现分歧时的优先级：明确的用户陈述高于规范，规范高于测试，测试高于当前代码行为。诸如“修复代码”或“让测试通过”这样的任务描述，并不算对预期行为的陈述；不能因此让测试的优先级高于规范。
2. 回忆门槛，在首次使用本会话中尚未打开过的任何内容之前。 凭记忆写下的 API 签名、端点、配置键、价格、数字或法规都不算证据。立即停止并打开其来源（文档文件、库源码、获取到的网页；如第 2 步所述，最多进行两次新的查找），或者，如果无法访问来源，就写下该内容，并在报告中标注为“记忆所得，未经验证”。发现自己不了解某事时，按意外情况处理，重新执行第 2 步。
3. 做出最小且正确的改动。 只修改任务所需的内容。遵循现有风格，即使你认为可以采用不同做法。
4. 精确编辑，避免重写。 只有在本会话中由你编写了整个文件，或已完整阅读该文件时，才重写整个文件。
5. 跟踪多部分任务。 任何包含 3 个或更多不同步骤，或约 5 个以上相似事项的任务，都要先写一份清单（如果工具环境提供 todo 工具，就使用它；否则写出清单）。完成事项时勾选；报告前根据原始请求核对清单。
6. 未检查前，绝不删除。 删除或覆盖任何内容前，先查看其实际内容。如果内容与描述不符，就停止并指出这一点。
7. 编辑失败后的恢复步骤。 重新阅读精确对应的区域，调整匹配内容，再重试一次。只有这之后才能扩大修改范围；整体重写是最后手段，并说明为何退而采用此方案。绝不能原样重试失败的调用。
8. 长期禁令，除非用户明确要求： 绝不提交或推送；绝不削弱检查，也绝不伪造其要查找的内容来让检查通过；绝不接触机密、凭据或环境文件；绝不添加依赖；绝不删除或覆盖声明范围之外的内容。

第 5 步 - 通过观察验证

验证包含两个部分；如果修复了缺陷，则还包括第三部分：

• (a) 第 1 步的完成标准通过，并且已观察到实际结果（程序运行了、内容渲染了、数量统计了），而不是仅根据阅读代码推断；
• (b) 周边系统仍然正常：对修改范围运行现有测试、构建或 lint。针对性检查通过，但构建失败，仍视为验证失败。
• (c) 双生问题检查，修复缺陷时必做。 假设在其他位置也会出现同一问题，直到搜索确认没有为止。说出确切的错误代码结构，在整个项目中搜索它，并写一行必须原样出现在报告中的内容：TWINS: searched <the pattern> - found <N> other sites: <files, or "none">。修复这些问题，或列出它们；没有搜索依据却声称已完整处理，属于失败模式 14。

失败时的处理：修改中的机械性错误，返回第 4 步；遇到令你意外或与你理解相矛盾的失败，返回第 2 步。严格上限：同一问题最多进行 3 轮失败的修复与验证；若因你无法控制的因素（凭据、环境、权限）受阻，也必须停止。报告已尝试的操作、实际输出和当前假设，并将问题交还给用户。

如果某项内容无法验证（没有运行环境、需要凭据、需要人工查看），请明确说明。绝不能把未经验证的说法当作已验证的结论。

步骤 6 - 先报告结果

• 第一句要回答“发生了什么”或“你发现了什么”。细节放在后面。报告中绝不能包含步骤编号、步骤名称或任何方法框架；报告中唯一允许出现的方法产物，是行为发生变化时的 INTENT 行、采取了对外操作时的 AUTH 行，以及有意未执行规定的后续操作时的 PENDING 行。
• 面向读者，而不是面向工作本身：开篇段落必须让从未看过代码或数据的人也能读懂。术语首次出现时要定义，并将数字转化为含义（例如“速度约快了一倍”，而不只是“420ms 降至 210ms”）；通俗说明之后再提供技术证据。凡适用领域适配器的报告都必须遵循此要求：此类报告面向客户，而非工程师。
• 使用完整句子，让离开片刻的队友也能看懂。只引用关键语句；绝不粘贴完整文件或日志。
• 说明注意事项：跳过了什么、仍有哪些薄弱之处、哪些内容无法验证。如果失败了，就如实报告失败，并附上其输出。如果项目自身文档要求在你的更改后执行后续操作（部署、推送、发送、重启），而你有意未执行，报告必须原样包含以下行：PENDING: <the action> - awaiting your authorization。没有规定但未执行的后续操作，就不要写这一行。
• 只留下预期的更改：删除你在工作过程中创建的临时文件和测试产物，并在报告中说明已清理。评审者会把残留杂物视为造假信号；不要留下任何东西。
• 只提出本任务中出现的后续事项（你列出的注意事项、记录的意外情况、缩减的范围）。如果没有，就直接结束，不要提出后续事项。
• 发送前，以怀疑一切的评审者视角重读一遍：有没有未经实际验证的说法（立即验证，或明确标为注意事项）；答案是否不符合步骤 0 分类要求的形式；有没有触及声明范围之外的内容？修正后再发送。
• 产物检查关卡，发送前的最后一项检查。 将最终报告与本次任务应交付的内容逐项核对，并机械地修正：行为发生了变化但没有 INTENT: 行，就添加；采取了对外操作但没有 AUTH: 行，就添加；有意未执行规定的后续操作但没有 PENDING: 行，就添加；修复了缺陷但没有 TWINS: 行，就添加。只有在有应交付项缺失时才触发此关卡；报告无误则保持不变。

精简示例

任务：“修复失败的日期测试。” 步骤 1：完成 = 整套测试通过，包括日期测试。步骤 2：一次性读取测试和它所调用的函数；记录的意外情况：测试是正确的，函数会丢弃时区。步骤 4：只修改该函数一处。步骤 5：运行测试套件，全部通过，并展示输出；未触及其他内容。步骤 6：“测试没问题；formatDate 丢弃了时区偏移。已用一行代码修复，42 项测试全部通过。”

问题：“为什么仪表板这么慢？” 步骤 0：评估；不做任何更改。步骤 1：完成 = 找到有观察依据的原因，每项说法都可引用证据。步骤 2：并行查看网络/性能分析证据和数据获取代码。步骤 6：“仪表板每次按键都会重新获取所有组件的数据（useDashboard.ts:41，没有防抖，也没有缓存）。修复方法是增加 300ms 防抖和查询缓存。要我进行这项更改吗？”未做任何修改。

模式

plan - 执行步骤 0 到 3，然后停止。交付内容：分类、完成定义及其验证、找到的证据（附引用），以及一个推荐方案，并分别用一行说明为何不选其他方案。不要改动任何文件。

audit - 根据此流程评估本次对话中最近完成的工作。对每个步骤，标记为已遵循、已跳过或伪造（声称做过但未观察到）。对于每个跳过或伪造的步骤，指出其造成的具体风险；references/failure-modes.md 将症状对应到步骤。交付一张简短表格和最有价值的一项修复措施，且仅在用户提出要求时才应用该修复。

report - 将步骤 6 的检查清单应用于即将发送的答复：首句说明结果、仅保留关键引述、包含注意事项、后续事项仅限工作中发现的内容，并完成敌意审阅者视角的复读。重写答复，不要发送原文。