挑战循环（Gauntlet Loop）
将用户的初始指令或目标转化为一个 挑战循环——一种基于 Matt Shumer 的 Claude of Duty 技术、robonuggets/gauntlet-loop、duolahypercho/gauntlet-loop 以及 AI 循环工程三要素框架 的自主构建者与评判者反馈循环。
大多数代理的输出仅停留在“对 AI 来说足够好”，因为构建者会根据模糊的词语给自己的作业打分。而挑战循环则用一个基于三个核心要素的持久性周期取代一次性提示：
- 目标 (Objective)：必须成为现实的、具体的可交付成果和结果状态。
- 参考或指标（标杆与严苛评判者，Reference or Metric）：一个有名称、可获取、可并排比较的基准——在适用处配以客观测试或指标——由拥有全新上下文的独立评判者进行盲评。
- 边界 (Boundary)：明确的成功标准、轮次/停滞上限、策略切换规则以及决定循环何时停止或升级的安全/权限门控。
第一步：识别种子指令与上下文
- 如果用户通过
/gauntlet-loop <instructions>内联传递了指令，则将其作为种子。 - 如果用户在正在进行的对话中调用了不带参数的
/gauntlet-loop，则使用当前正在讨论的任务、计划或提示。 - 如果消息或对话历史中没有明确的任务，则在继续之前询问用户想要构建或实现什么。
- 如果任务涉及本地代码库或工作区，则快速检查目录结构、技术栈、测试运行器或构建脚本，以便你提出的默认值能引用真实项目的工具和命令。
第二步：澄清三个循环要素（提出默认值）
根据下面的三个核心要素审核用户的请求。当任何要素缺失、指定不足或使用了模糊的质量标准时，向用户提出你的默认方案，并要求用户确认或调整这三个要素。
快速通道规则：如果用户已经提供了明确的目标、具体的可获取参考/指标以及清晰的边界——或者明确表示“使用默认值”/“直接写提示”——则跳过询问，直接使用你认为最佳的默认值进入第三步。
1. 目标（必须成为现实的、具体的结果是什么？）
- 用可观察的结果状态和可交付成果替换模糊的意图（“让网站更好”、“写一个好的 CLI”）（“用 Next.js + Tailwind 构建一个响应式 SaaS 定价页面，让首次访问者可以比较所有计划并在移动端完成结账”）。
- 建议的默认值：为用户草拟一份精炼过的 1-2 句目标（包括检测到或推荐的技术栈/格式），供他们批准或调整。
2. 参考或指标（质量标准与外部裁判）
挑战循环中的一切都取决于质量标准。有效的参考标准必须通过三项测试：
- 有名称的：一个具体的真实世界产物，而非形容词或类别。（以“Stripe 的实时定价页面”或“Hades 战斗截图”为准；仅凭“获奖级的 SaaS 设计”或“AAA 质量”则不行。）
- 可获取/可检查的：评判者可以在运行期间实际获取并检查它——截图实时 URL、阅读已发布的文章、运行二进制文件或检查仓库。如果代理无法获取参考，它将凭空编造比较结果并批准平庸的作品。
- 可比较的：我们实际的输出和参考可以并排放置，且去掉标签，这样由一个新评判者进行二元盲 A/B 选择（“哪个更好？”）并指出仅剩的最大差距。绝不使用 1-10 的评分，因为每轮评分都会上浮。
品味 + 数字胜过仅仅依靠品味：只要目标具有可衡量的维度（单元/集成测试套件、p95 延迟、Lighthouse/可访问性分数、360px 宽度下零水平溢出、基准测试吞吐量、字数或原始来源引用追溯），就将定性的参考标准与一个硬性的客观验证器配对。
| 目标类型 | 有效的参考标准 + 指标 |
|---|---|
| 网站、应用、UI | 特定最佳产品的实时 URL (linear.app, stripe.com/pricing, vercel.com) 在桌面和移动视口下的截图 + 零控制台/可访问性/溢出错误 |
| 代码、CLI、库 | 一个命名的开源仓库或工具的实现 (ripgrep, jq, esbuild) + 自动化测试套件、属性模糊测试器以及延迟/吞吐量基准测试脚本 |
| 游戏、3D、交互 | 来自已发布标题 (Call of Duty, Hades, Brotato) 的实际游戏截图或视频，与游戏内实时帧进行对比 + 目标 FPS / 可玩性检查 |
| 写作、文档、解释性内容 | 2-3 篇由指定作者或出版物（例如 Julia Evans、Stripe Engineering Blog、Gwern）发表的特定作品，在去掉署名的情况下进行盲比 + 目标长度/阅读时间检查 |
| 研究、策略、分析 | 一份指定的分析师报告、基准论文的方法论部分或法务做空备忘录 + 所有主张与原始源数据的自动核对 |
| 幻灯片、可交付品 | 来自标杆公司的特定公开演示文档或备忘录，页数/幻灯片数相同 + 叙述清晰度检查 |
- 建议的默认值：提供 2 到 3 个具体、有名称、可获取的候选标准（将最具挑战性但确实可达的标记为“
(推荐)”），并配以一个具体的客观指标/验证器。
3. 边界（停止条件、预算与安全门控）
“循环到完全完美”的动机是好的，但针对一个无法达到的标准进行无界循环可能会永远运行、消耗代币或做出不安全更改。需在三个子维度上定义明确的边界：
- 成功与收敛停止：当每个组件都通过其客观验证器并在与参考的盲比中胜出时退出（或当人为指定的“刹车”停止运行时）。
- 迭代与停滞上限：限制每个组件的轮数（默认：每个部分最多 5 轮 或 连续 2 轮无实质性改进后停止）。如果完全相同的差距连续两次失败，要求构建者改变策略。
- 权限与安全门控：允许本地读取、起草、编辑、构建、渲染和测试。禁止在未经明确人工批准的情况下进行不可逆或外部操作（不得进行生产环境部署、破坏性删除、付费 API 消费、凭据/密码更改或外部消息发送）。
如何询问用户
如果需要澄清，请提供一个简短、可扫描的提示（或如果可用的话使用框架的结构化 ask_question 工具），仅涵盖未解决的要素，并预先填入默认值，以便用户能够用简写回复（例如：“1，使用默认值”）：
- 目标：陈述你提出的精炼目标 + 技术栈，并询问是否有任何需要更改的地方。
- 参考与指标：列出 2-3 个有名称、可获取的候选标准（
A、B、C，其中A (推荐)）以及提议的客观验证器/测试。 - 边界：提出默认的停止条件（例如：“赢得盲 A/B 比较 + 通过检查，每部分最多 5 轮，连续两次相同失败后切换策略，仅限本地编辑”）或 “人为刹车模式（持续循环直到我停止它）”，并询问他们更喜欢哪种模式。
第三步：输出转化后的挑战循环
一旦目标、参考/指标和边界被选定（或使用默认值），将结果以三部分形式呈现：
1. 挑战循环设计卡片
输出一个简洁的摘要表格，锁定循环架构：
- 目标：必须成为现实的精确结果和可交付成果。
- 参考标准（品味）：有名称、可获取的产物，以及如何在构建前获取/检查它。
- 客观指标（数字）：在评判者审查之前需要的自动化测试、基准测试、布局检查或事实验证。
- 分解规则：如何将工作拆分成小的、可独立判断的部分（仅并行化真正独立的部分；保持紧密耦合系统处于连贯的、顺序的自主权之下）。
- 评判者协议：独立的子代理，拥有全新上下文；检查实际渲染/执行的产物（从不检查构建者的摘要）；运行去标签的盲 A/B 比较；做出二元选择并指出仅剩的最大差距。
- 状态与进度：用于持久化循环记忆的文件（
GAUNTLET_PROGRESS.md或实时进度页面），记录已完成部分、证据、失败方法和剩余差距，以便上下文不腐烂。 - 边界：活跃的停止规则、轮次上限和安全门控。
2. 挑战循环提示
在一个围栏 markdown 代码块内输出一个自包含、可复制粘贴的提示。提供下方的通用挑战循环提示（针对用户的任务、工具和技术栈进行调整），如果用户想要超紧凑的 Matt Shumer 风格的 3 段式提示或框架特定的循环命令，则相应调整结尾（请参阅 references/examples.md）。
在 [技术栈/格式] 中构建 [可交付成果/目标]。
## 1. 质量标准与指标（先获取）
质量标准是 [有名称、可获取的参考]。在构建或评判之前，直接获取并检查真实参考（[如何获取：在桌面和移动端截图实时 URL / 拉取发布的文本 / 克隆或运行参考实现]）——绝不与记忆或对它的描述进行比较。
每个部分还必须通过这些客观检查：[客观指标/测试/基准测试]。
## 2. 分解与所有权
将工作分解成可以独立构建、验证和评判的最小部分：[初始候选部分]。
- 仅对于真正独立的部分，并行派出构建者子代理。
- 保持紧密耦合系统处于顺序的、连贯的所有权下，以便组件不冲突。
## 3. 构建者 vs. 严苛评判者循环
对于每个部分，运行一个构建者子代理和一个独立的评判者子代理，后者拥有全新上下文（无权访问构建者的思考链或辩解）：
1. **构建与验证**：构建者创建或修改该部分，并运行客观检查（[测试 / 代码检查 / 基准测试 / 渲染]）。
2. **检查真实产物**：评判者打开并检查实际输出（[截图 / 正在运行的二进制文件 / 测试日志 / 草稿文本]）——绝不检查构建者的摘要。
3. **盲 A/B 选择**：评判者将我们的产物与[有名称的参考]并排放置，去掉标签，做出二元选择哪个更好，并且——如果我们的输了——识别出**仅剩的最大差距**，附上具体证据，并将其发送回构建者。
4. **无软性评分**：评判者必须极其严苛。禁止表扬和 1-10 的数值评分。如果我们的产物未能在盲比中获胜或通过所有客观检查，则继续循环。
## 4. 状态追踪与策略转移
每轮后维护一个紧凑的 `GAUNTLET_PROGRESS.md`（和/或实时进度视图），记录：当前部分、轮次编号、评判者裁定、目标差距、失败方法和客观检查结果。如果同一差距连续两次失败，放弃当前方法并尝试结构上不同的策略。
## 5. 最终集成检查与边界
- **集成评判者**：一旦单个部分获胜，生成一个全新的集成评判者来端到端检查完整的装配产物的一致性、接缝、性能以及与原始目标的契合度。
- **边界**：[停止条件：例如，当所有部分 + 集成赢得盲 A/B 比较并通过所有客观检查时停止，或每部分达到 N 轮 / 连续 2 轮无实质性改进时停止]。允许的操作：[允许的本地操作]。未经明确的人为批准，不要 [禁止的操作：部署到生产环境、删除数据、花钱或触及凭据]。
[框架循环结尾：持续循环，直到评判者在每个部分都选择我们的，将构建者和评判者作为子代理运行。 / 对于 Claude Code：在每个部分上使用 `/loop` 直到胜出；派出子代理和 `ultracode`。 / 对于 Codex：在每个部分上使用 `/goal` 直到胜出。]
3. 执行提议
最后询问：
“你希望我现在就以首席编排者的身份运行这个挑战循环，调整三个要素（目标、参考/指标、边界）中的任何一个，还是切换提示风格（通用有界式 vs. 用于 Claude
/loop或 Codex/goal的经典 150 字目标提示）？”
如果用户说运行它，则立即将生成的提示作为你活跃的操作指令：首先获取参考，初始化 GAUNTLET_PROGRESS.md，分解部分，并开始第一轮。
什么会打破挑战循环（护栏）
绝不允许这些失败模式进入生成的挑战提示中：
- 模糊或不可获取的标准：“让它成为世界级”或命名一个付费墙/无法访问的产物迫使评判者凭空捏造比较结果并盲目放行所有内容。
- 构建者评判自己的作品：构建者会记住它做出的每一个妥协并为其辩护。评判者必须是一个拥有全新上下文的子代理（或一个剥离构建者辩护理由的干净的验证过程）。
- 使用 1-10 的数值分数代替二元选择：10 分制评分会随着轮次自动从 7/10 漂移到 9/10。要求进行二元盲 A/B 选择（“哪个更好？”）加上仅剩的最大差距。
- 评判者阅读摘要而非检查产物：一份漂亮的 Markdown 状态报告不是证据。评判者必须检查渲染的像素、执行二进制文件/测试或阅读实际文本。
- 并行化紧密耦合的代码：在同一状态循环或共享渲染管道上派出 10 个子代理会导致合并冲突和视觉接缝。仅并行化独立部分