用途
Fabled 是一套六阶段构建纪律，用于把单次提示转化为完整、可运行、零占位符的交付物。它适用于任何非平凡的单次提示构建任务。其定位不是提升模型原始智能，而是把前沿模型隐性的工作过程显式化，使其可被逐步遵循。资料指出，大多数一次性失败来自跳过这些工作，而不是写不出某个函数。
主要能力
Fabled 通过硬性规则约束输出质量：
- 只写完整文件：每个文件从头到尾完整写出。理由是不运行的片段对用户完全失败，“基本完成”不等于完成。
- 禁止字符串：最终输出不得包含作为延迟标记的 TODO（# TODO、// TODO 或裸大写 TODO）、“rest of the code”、“rest of code here”、“you can implement”、“for brevity”、“left as an exercise”，以及空函数体或仅含 pass、... 或未实现错误的函数体。理由是这些可被词法检查，因此禁令可执行。普通领域词不受限，例如待办事项应用可以包含 todo 条目，禁令针对的是延迟标记。
- 从不提问，假设并记录：提示含糊时选择最合理的默认值，写入 ## Assumptions 并继续。理由是单次提示场景没有第二轮，反问等于不回答。
- 响应前验证：完成前对照 Phase 0 的每条编号需求重新检查实际输出，并引用证据。
- 按顺序填写输出模板，结构强制各阶段真正发生。
严格度校准
流程在所有能力层级都是正确行为，校准只调整额外纪律的量。调整仅依据客观信号，任何层级都不跳过检查门或硬性规则。模型识别仅来自客观来源：运行时或系统上下文报告的模型 ID，或用户显式标志（如“strict mode”）。禁止通过内省或自测估计自身能力。可选的外部排名：若有命令/网络工具，可获取前沿模型追踪器（如 curl -s https://www.demandsphere.com/research/demandsphere-radar/ai-frontier-model-tracker/api.json），查询运行模型的相对位置；若调用失败、响应无法解析或模型未列出，静默忽略并回退到名称关键词。绝不阻塞或重试该调用。
分档与调整：
- S — 前沿：追踪器顶级；名称类似 “Fable”/“Mythos” 级旗舰。计划叙述可用简短要点，其余照写。
- A — 强：追踪器上层；“Opus”/“GPT-5.x” 级旗舰。照写；回答 Phase 0 Q3 时格外注意边界。强模型的典型失败是在会话内彻底验证，却跳过交付的测试文件和失败回退——两者都要做。
- B — 有能力/未知：中型模型，或无可靠信号。照写。未知总是落在此档，绝不更高。
- C — 小/廉价：追踪器下层；名称含 “mini”、“nano”、“haiku”、“flash”、“lite”、“slim”、“tiny”。照写，外加：每个文件保持在约 80 行以内；每个文件前重述契约；每个文件后运行 Gate B，而非仅在最后；最多允许 2 个隐式功能；进行第二次完整 Phase 4 遍历。
使用方式
努力预算：在写任何代码或最终内容前，将约前 20% 的输出用于 Phase 0–2。理由是规划不足是默认失败模式，显式比例可纠正分配。
强制输出模板，按此顺序填写：
-
Plan（Phase 0 输出：一句话完成定义、编号需求清单、四个自访谈答案）
-
Assumptions（为含糊之处所选默认值的编号列表）
-
File tree & contracts（Phase 2 输出：完整树，然后是数据形状/签名/接口）
- 每个文件完整写出，每个文件前有一行契约
-
How to run（前置条件 → 安装命令 → 运行命令，按此顺序）
-
Verification（Phase 0 清单逐字复制，每项附证据打勾）
按任务类别路由：选择信号最匹配的一行，它决定交付形式以及下游“运行”和“验证”的含义。类别包括：CLI/脚本（“tool”、“script”、“tracker”、“automation”）、网页/应用/游戏（“website”、“web”、“page”、“game”、“UI”）、服务器/API（“backend”、“endpoint”、“service”）、数据/分析（“analyze”、“from this CSV”、“report on the data”）、文档/计划（“write me a … plan/doc/report/spec”）。每类有对应的交付形式、“如何运行”含义、验证重点和质量标准补充。
阶段流程
Phase 0 — 重建意图：重读整个提示两次；提取每条显式需求为编号清单；把每个主观形容词翻译为 3–6 个客观可检查项；添加用户显然需要但未说的隐式需求；写一句话完成定义；书面回答四个自访谈问题。GATE A：四个自访谈答案已写、所有需求已编号？通过则进入 Phase 1，否则重读用户提示并完成，不得写代码。
Phase 1 — 决定范围与技术栈：应用所选类别行；选择无聊、主流、依赖最少的技术，除非用户另有指定，并固定运行时获取内容的精确版本；明确说明范围内与范围外；把答案视为最终，必须零后续独立成立。
Phase 2 — 先设计后代码：先写完整文件树；定义契约（数据形状、函数签名、API 路由、模块接口）；为验证而设计，把核心逻辑（规则、数学、状态转换）放在纯函数中，与 I/O、UI 或渲染分离；规划状态→视觉绑定检查，列出每个状态字段及其驱动的视觉元素；按依赖排序构建。
Phase 3 — 完整构建：写每个文件前用一两行重述该文件必须导出什么、消费什么；若能写文件，完成即写盘；完整写出每个文件；写文件 N 时对照文件 1..N−1 实际导出重新检查其导入；内联处理明显失败模式。GATE B：搜索自身输出中硬性规则 2 的每个禁止字符串，零命中则通过。若可执行命令且文件在磁盘上，运行 python scripts/check.py <output-dir> 而非肉眼扫描。检查点：Phase 4 前立即把 Phase 0 编号需求清单逐字复制到 ## Verification。
Phase 4 — 交付前验证：先选验证模式——能执行代码则 Mode B（执行检查），否则 Mode A（静态追踪）。Mode A：从运行命令到输出心理执行快乐路径；机械交叉检查导入、文件存在、依赖列表、运行命令与入口点。Mode B：对确切交付物写并运行真实检查（解析/语法检查、纯逻辑核心单元测试、禁止字符串扫描器、可行时实际运行命令）；交付检查，测试文件是交付物一部分，出现在 Phase 2 文件树中，用户可用一条命令重跑；证据是粘贴的命令输出，不是声明。检查失败时先判断代码还是检查错了，需求清单是仲裁者。然后两种模式都：对照产出输出为每条编号需求打勾，粘贴满足它的确切行或测试结果。GATE C：每条编号需求都有引用证据打勾？通过则 Phase 5，否则回到 Phase 3。
Phase 5 — 面向人类交付：交付物是可运行工件本身，关于构建的报告不是构建；交付前清扫脚手架残留；以如何运行开头（前置条件、安装命令、运行命令）；简要重述 Assumptions 列表；不做关于努力或过程的元叙述。
适用场景
Fabled 适用于任何非平凡的单次提示构建任务，包括 CLI/脚本、网页/应用/游戏、服务器/API、数据/分析、文档/计划等类别。非代码交付物（文档、计划、报告、分析）也适用同一循环：需求 → 范围 → 每节一行契约的章节大纲 → 每节完整草稿 → 用引用证据验证每条需求 → 交付。禁止等价物包括 “[add details here]”、“section left for the author”、空标题和用 “etc.” 代替真实内容。“如何运行”变为“如何使用本文档”。
限制
资料未提供 Fabled 的收费、价格、平台支持、效果保证等信息。它不能传递原始智能，只能传递过程纪律。小任务若客观上极小（单个短函数或单文件片段、无持久化、无多组件），可将 Phase 0–2 压缩为三行计划，但硬性规则和 Gate B–C 仍完全适用；仅在这些客观信号下压缩，绝不因为任务“感觉简单”。