Map vs Territory：这段距离就是 unknowns
您给出的提示/上下文 Claude 是 地图。实际的代码库和绑定是 领土。 这两者之间的距离称为 unknowns.
对于 Fable 5，output 的质量受到 unknowns 澄清能力的限制 用户 ——不是因为model的能力。 模型越强大，坏地图的成本就越大，因为它会自信地朝错误的方向执行，而不是停下来询问。
你在prompt里写得很清楚了。 Claude 只需阅读并遵循 - 无需猜测。
你自己了解什么 未定 — 权衡、变量名称、策略 migration 保持开放。
标准是“一看就知道”，但你无法用语言表达——只有当 output 错误时它才会出现。
您不知道需要问的问题。这是最危险的差距，也是要消除的主要目标。
merge 修复费用要贵很多倍，因为当时的领土被地图歪曲了。
我写的三个 custom skill，用来补齐三个关键空缺
不是 ClaudeKit core 的一部分 — 3 个小型 skill 旨在填补此方法所需的空白：在编码之前找到 unknown unknowns，在发生时记录 deviation，以及在编码后了解人们的 gate。
将“我不知道我不知道什么”变成尖锐的、即插即用的 prompt。
在每一个偏差发生的那一刻就抓住它——在它成为一个谜之前。
如果你没有完全通过测验，你就不会合并。就是这么简单。
每个 skill 的详细信息
/blindspot — 进入领地前进行盲扫
- 侦察兵 codebase + 桃子
git log找到 unknown unknowns 的用户，而不是为他们解决任务。 - 任何发现都必须引用 evidence：特定文件、commit 哈希值或文档 - 不接受一般推测。
- 最有价值的技巧：找到做过类似任务的commit（
git log --grep） 已经git show --stat <hash>— 其footprint文件是可用的checklist touchpoint，通常是最高信号artifact。
/ck:brainstorm 或者 /ck:plan 在下一步中。/impl-notes — 在发生时记录 deviation
- File
implementation-notes.mdghi Decisions / Deviations / Surprises 在它们发生的时候——而不是像会议结束时的回顾/ck:journal. - 常设规则就在那里 文件头 — 不要依赖对话记忆，因为随着对话变长，context compaction 会打破规则。任何重新读取该文件的 agent 都会自动“重新采用”该规则。
- 遭遇edge case偏离计划→选择选项 保守的 （reversible 最小），记录 4 行，继续前进 - 不停地等待用户做出可逆的决定。
quiz-gate （deviations = 最佳 quiz material）和 /ck:journal./quiz-gate — 人来检查人
- 通过行为测验生成有关更改（TL;DR、上下文、直觉、blast radius）的 HTML explainer，而不是变量重命名琐事。
- 门仅在应答时通过 100%正确。哪个句子是错误的→用正确的相关代码解释被误解的概念，然后针对正确的地方重新测试新句子，重复直到通过。
- 应用了重要修复：初始 report 仅包含问题, answer key 仅写入 HTML gate 解析后 （通过或中止）——如果先写，用户读取答案，则 gate 毫无意义。
/ck:git 或者 /ck:ship.把 custom skill 与 ClaudeKit 结合成 6 阶段 pipeline
每个周期都是查找 unknowns 的前期成本。
/blindspot扫描 codebase + git history → 报告 unknown unknowns、坑洼和更清晰的 prompt 以进入阶段 1。
/ck:brainstorm --html从 blindspot 获取 prompt → 侦察 + 内置面试 → 2-3 方法 + 设计文档。
高风险：更多 /ck:predict （5个人辩论）或 /ck:scenario （edge case 12 路）。
/ck:plan （或者 --tdd)出口 plans/<ts>-<slug>/plan.md + phase files.
高风险： + red-team （敌对的 reviewer 撕毁了计划）。 + validate （验证声明与真实的 codebase）。
案例关键（需要 OpenAI 子）： /codex:adversarial-review 按计划 — gate 穿过 model，运行 最终的 red-team + validate之后：攻击精炼计划，找到两个Claude都盲的地方。
/impl-notes init → /ck:cook → /impl-notes review/impl-notes init 创造 implementation-notes.md 在计划目录中 前 当 cook 时。 /ck:cook <plan> 实施——偏离计划时：选择保守的选项， /impl-notes log， 前进。会议结束： /impl-notes review 为下一次课程提炼学习内容。
/ck:code-review + /quiz-gate代码审查检查代码质量（代码检查器）； quiz-gate 测试人类知识（人检查人）——两个不同的轴。
高风险（需要OpenAI子）： /codex:adversarial-review 代码差异 - gate 交叉 model，在两者之间运行 /ck:code-review 和 /quiz-gate, focus text 取自 impl-notes 的偏差部分。
/ck:git 或者 /ck:ship + /ck:journal提交/推送或 PR pipeline，仅在 gate 处于阶段 4 后运行 PASSED。日志读取 impl-notes 作为反映的提要。
围绕 ck:cook 的 3 个固定 gate + 2 个可选跨模型 gate
检查不重复 - 每个 gate 都针对一个单独的未知轴，位于执行步骤的任一端。 /quiz-gate 总是 gate 最后一个引脚：谁是停止条件。
在计划中
关于代码差异
水平滚动查看所有 6 个节点 →
Gate 1 · /ck:plan red-team — agent 检查 agent
2-4 reviewer subagent 敌对人物撕毁了计划，找到了没人想到的失败模式。哪个发现没有 evidence？ file:line 特别自动拒绝——避免含糊的抱怨。
Gate 2 · /ck:plan validate — 在 red-team 之后、cook 之前运行
验证通过检查“地图与领土”字面意义：grep codebase 以查看计划的声明（文件、符号、端点）是否确实存在。然后面试3-8个问题 朋友 关闭剩余的开放假设。 red-team → validate 的目的是：让 agent 在与其他人最终确定计划之前，先将计划撕毁并编辑，以避免最终敲定即将修改的草案。
选配门· /codex:adversarial-review 计划中 — cook 之前，validate 之后（需要 OpenAI 子）
仅适用于严重情况（migration、security、public contract）。跑步 最终的 在规划阶段，在计划经过red-team + validate的细化后——攻击完整的计划，寻找整个Claude家族盲点的地方。
选配门· /codex:adversarial-review 代码差异 - cook 之后，quiz-gate 之前（需要 OpenAI 子）
固定的 gate 都是检查 Claude 的 Claude — 相同的 model 系列，相同的盲点，reviewer 不会捕获它自己产生的错误。跨门 model 至 agent 除 model 以外 (GPT-5.5) in — 正确消除剩余的未知类型：unknown unknowns 由 model 本身。焦点文本取自 impl-notes 的偏差部分。详情请参阅第 07 节。
Gate 3 · /quiz-gate — 人类检查员，gate 最后一个引脚
发货前的最后一道关口，停用您自己的刚刚发货的 unknowns - 机器审核代码（或其他 model）已通过并不意味着您完全理解新行为。人是停止条件。
场景组合——支付与风险相称的保险费
完整的pipeline（阶段0→5）仅适用于奇怪的区域+模糊的scope+高风险。更常见的情况需要更薄的组合。
| 场景 | 使用组合 | 跳过 |
|---|---|---|
| 上一届会议有一个计划，现在继续 | /ck:watzup 阅读状态→阅读旧impl-notes中的“下一课的学习”→ /impl-notes init → /ck:cook 下一阶段 → /quiz-gate。还没有旧的 impl-notes（刚刚向之前使用 ClaudeKit 的项目添加了 3 个 custom skill）？跳过阅读学习内容 — /impl-notes init 在活动计划目录中创建一个新文件，从本次会议中积累经验。 |
阶段0-2 — unknowns 支付上一会话的费用 |
| 小错误修复，熟悉的区域 | /ck:fix → commit。然后Loi deviation /impl-notes log |
整个 gate — quiz-gate 用于修复 10 条线是过量的 |
| 奇怪的区域，但scope是清晰的 | /blindspot <area> → 直接粘贴更好的-prompt /ck:plan |
ck:brainstorm — 当 scope 被锁定时，没有什么可讨论的 |
| 全新的域（不是代码） | /blindspot --domain （教学第一，学习词汇）→ /ck:brainstorm --html |
Scout codebase — 差距在于知识，而不是仓库 |
| 高风险（public contract、security、migration） | Full pipeline + /ck:predict//ck:scenario 在第 1 阶段+ red-team → validate 2+阶段 /codex:adversarial-review 在第 4 阶段（如果有 OpenAI 子）； quiz-gate 强制性的 |
不要放弃任何东西 |
| Claude 卡住了 - debug loop，一次又一次修复但失败 | /codex:rescue （需要 OpenAI 子）——将任务分配给从另一个盲点看的 GPT-5.5； --resume 继续旧线程 |
改变gate并不能解决问题——问题出在model的盲点，需要另一个model |
| 计划已完成，风险中等——不值得一拥而上 red-team | /ck:plan validate — 验证主张 + 访谈最终假设 → /ck:cook |
red-team （中度风险服用过量）， /ck:predict//ck:scenario |
| 审查其他人撰写的 PR | /quiz-gate --pr <n> 单独使用——测验是深入阅读 PR 的一种方式 |
blindspot, impl-notes ——不是我写的代码 |
| 纯粹重构，行为不变 | /ck:code-review + test suite |
quiz-gate 可选——没有新的行为会被误解 |
Fable 5 参与哪些阶段？
原理：寻找unknowns的前期成本很便宜。推断将最昂贵的model放入流程中 检测并决定，使用便宜的 model 进行该过程 按指示执行 — 计划越好，model 的实施就会越好。
| 阶段 | 模型 | 为什么 |
|---|---|---|
/blindspot |
Fable 5 | 价值在于解读：将git history读入“坑洞”，认识到commit是一个值得遵循的模式。弱模型仅列出文件。 |
/ck:brainstorm, /ck:plan, /ck:predict |
Fable 5 | 架构决策——如果这里错了，所有后续步骤都将毫无意义。 |
/quiz-gate （生成问题） |
Fable 5 / Opus | 一个好的干扰者需要比代码编写者更深入地理解行为。回答的人是你，model指出了话题。 |
/ck:plan red-team |
Fable controller + Opus/Sonnet | 审稿人subagent只需用evidence找到故障模式 file:line （预定角色——Opus 能力超群）。新的裁决结果需要情报，在主要会议上进行。例如per-subagent是最漂亮的pipeline。 |
/ck:plan validate |
Sonnet/Opus | 验证通过是根据层 checklist 的机械 grep。智慧在于回答者——model 只需要提出正确的问题。 |
/ck:cook 根据详细计划 |
Sonnet | 一个好的计划已经消除了unknowns；实施是按照地图进行的。最大的节省地方。 |
/ck:code-review |
Opus/Sonnet | 由checklist + evidence审核； Fable 只值得更改为 public contract。 |
/impl-notes log, /ck:git, /ck:ship, /ck:watzup |
Haiku/Sonnet | 机制：附加几行，commit，总结状态 - 不用动脑子。 |
/ck:scout raw discovery |
Haiku | Glob/Grep 找文件不值得消耗 Fable usage。若用 Explore/subagent 做大范围 scout，先 pin 到便宜 model；blindspot 才是更上层的解释工作。 |
/codex:review, /codex:adversarial-review, /codex:rescue |
GPT-5.5 （使用OpenAI，单独订阅） | 跨门model——无Claude代币销毁，单独计费；价值在盲点 其他 不是更强大的model。 |
Explore 从 v2.1.198 起可能继承 main conversation 的 model。如果 main session 正在用 Fable 5，Explore 也可能消耗 Fable usage。想低成本 scout 且不影响其他 subagent，就创建自定义 subagent explore.md，设置 name: Explore，并 pin model: haiku 或 model: sonnet。参考 Claude Code built-in subagents 文档。
要避免的反模式： 对cook使用Fable，而对计划使用Sonnet——这意味着支付昂贵的model，让它猜测unknowns应该已经被消除，这正是文章警告的“糟糕的地图，昂贵的领土”的陷阱。
Codex — 引入另一个 model 来检查 Claude
本节内容需要 OpenAI 订阅计划（ChatGPT Plus/Pro 或 API）以及已登录的 Codex CLI。如果没有，可以跳过；上面的固定 3-gate pipeline 仍然够用。
Plugin codex-plugin-cc 将 Codex/GPT-5.5 插入 Claude Code。核心价值观不是“model更强”而是 model KHÁC：每个内部 gate 都是一个 Claude 测试 Claude - 通过相同的训练，具有相同的 systematic 偏差，reviewer 不会捕获它也犯的错误。 Codex还有其他盲点→可以从model中消除unknown unknowns。
环境
/plugin marketplace add openai/codex-plugin-cc /plugin install codex@openai-codex /codex:setup
如果使用 Codex MCP 而不是 plugin
Codex CLI 也可以作为 MCP server 让其他 agent 调用，但走 MCP 路线时，Claude 不再被 plugin 的 command/gate 约束。它可以在 brainstorm、plan、cook、review、close phase 都去问 Codex。这个方式可以用，但必须有清晰的 guardrails：
- 什么时候问：只在真实风险 checkpoint 问 — critical plan、material code diff、security/migration/public contract，或 debug loop 已经试过 2 个方向仍然卡住。
- 问什么：每次调用都要有具体 artifact、具体 scope、具体问题，以及 reject 没有 evidence 的 finding 的规则。
- 最多几轮：默认 1 轮；只有 round 1 导致 material change 时才跑 round 2。不要跑无限的 ask → red-team → review → 再 ask 链条。
- 谁做最终决定：Codex 不能自己 approve plan、close phase、或允许 ship。Claude/human 必须 adjudicate 每个 finding：带 evidence accept/reject，然后才修。
在 Claude Code workflow 中，如果用类似 ultracode 的 keyword/feature 去调用 Codex，并 spawn 权限更宽的 review session，除非用户明确 approve edit，否则把它当成 review-only。不要把它当成默认路径：宽范围 review session 加上多轮往返，很容易造成严重 token burst。参考 OpenAI 关于 Codex MCP 的文档。
pipeline 中每个命令的位置
| 命令 | 时机 | 作用 |
|---|---|---|
/codex:adversarial-review 多于 plan |
第 2 阶段结束，red-team + validate 之后 | 计划中的第三个 model 十字门 - 仅适用于紧急情况（migration、security、public contract） |
/codex:adversarial-review 多于 code diff |
第 4 阶段，稍后 /ck:code-review， 前 /quiz-gate |
真正的用例（“发货前审查”）——挑战设计选择、隐藏的假设、权衡； focus text 取自 impl-notes 的偏差部分 |
/codex:rescue |
任何时候 Claude 被卡住 (debug loop) | Escape hatch — --resume 每个会话保持线程 Codex 分开 |
/codex:review |
第四阶段 | 对结果的第二意见 /ck:code-review 可疑的;不接受 focus text 所以请勿用于计划 |
Review gate (/codex:setup --enable-review-gate) |
每回合都有一个编辑代码 | 默认关闭 — 看看下面的原因 |
示例提示——对计划的对抗性审查
在计划完善后，将 Codex 放在第三个审查层上 - 明确这一点，这样它就找不到下层捕获的内容：
/codex:adversarial-review --wait Đây là implementation plan tại plans/<dir>/, chưa phải code — đã qua red-team và validate nội bộ. Đừng verify chi tiết file/symbol. Thay vào đó: (1) challenge HƯỚNG ĐI — đây có phải cách tiếp cận đúng không, có alternative đơn giản hơn không; (2) hidden assumptions mà plan đứng lên trên nhưng không nói ra; (3) tradeoffs bị đánh giá một chiều; (4) pressure-test các phase liên quan [điền risk area thật: auth/data loss/rollback/race].
没有commit的计划被视为working-tree变更（untracked files可审核）；如果计划是 commit 则添加它 --base <ref>.
结果处理循环——人为触发，而不是自动触发
对抗性审查锁定了 read-only，返回了 output verbatim。用户控制的循环：
- Codex 对抗性运行 round 1，返回结果 verbatim。
- Claude (Fable/Opus) adjudicate：Accept/Reject 用于与 evidence 一起查找 — 如果查找结果与已验证的决策相同，则拒绝源。
- 人批准 接受名单 — gate 人，无法删除。
- Claude apply 批准的修复+一致性扫描。
- Round 2 仅当应用修复后，材质才会发生变化； focus text 指向正确的校正区域。 最多 2 轮。
--resume 仅在 rescue; adversarial-review stateless — 第 2 轮必须在 focus text 中携带自己的上下文。
Review gate — 为什么默认关闭？
该插件的唯一自动版本是 Stop hook，它会审查具有编辑代码的每个回合。关闭的三个原因：
- 每回合超时时间长达 900 秒 — 每次编辑都必须等待审核完成才能继续。
- 代码中没有看到硬循环保护 — OpenAI 本身也会警告 Claude-Codex 循环。
- 每回合门控悖论： 仅对 unattended run 来说值得，但 OpenAI 建议仅当您坐在显示器上时才将其打开 - 并且观看的人已经是 gate。
代替： /codex:adversarial-review 跑步 一次 在第四阶段——同样的覆盖范围，一次付款，有人做广告。
用正确方式重设计你的 system
Alex Finn 的文章提出了与 Thariq 相同的论点，但级别更高：不是修复每个地图，而是升级 地图绘图仪 — 您自己的编码操作 system。这里有 4 个需要立即应用的原则。
system 层中的缺陷付出了上述复利代价 全部 任务 - 因此用于重新设计编码循环的一个 Fable 会话将分摊数百个后续 cook 会话。当 output 为 Fable 时，Fable 性价比最高 可重复使用的结构 （system、skill、计划），当 output 只是一次执行时最便宜。
Thay vì làm ngay task này, hãy thiết kế cho tôi một skill/workflow tái sử dụng để MỌI task cùng loại về sau chạy qua nó. Loại task: [mô tả]. Output cần: quy trình từng bước, file SKILL.md (nếu phù hợp), và tiêu chí đo để biết nó có đang hoạt động tốt không.
让Fable直接读取 rules/、skills 和 git history — 有关您工作方式的真实数据比您自己的言语更有力量。工件反映实际行为；叙述反映了行为的形象。
Đừng hỏi tôi làm việc thế nào — lời tự kể không đáng tin. Hãy đọc: thư mục rules/, danh sách skills đang cài, và `git log --oneline -50` của repo này, rồi tự dựng lại bức tranh workflow THỰC TẾ của tôi. Chỉ ra 3 chỗ friction lớn nhất, mỗi chỗ phải cite file hoặc commit làm bằng chứng — không nhận nhận định không có dẫn chứng.
新的 System 必须经过测试 一个真正的任务 然后测量 output - system 只揭示实际负载下的弱点，而不是在讨论期间。先原型，后扩展。
System/skill vừa thiết kế xong: chạy thử nó trên đúng MỘT task thật sau đây: [task]. So sánh với cách làm cũ theo 3 tiêu chí: thời gian, số lần phải sửa lại, chất lượng output. Nếu không hơn rõ rệt, liệt kê chỗ cần chỉnh — đừng khen.
出现相同类型的摩擦 ≥3次 在impl-notes/日志/复古中，值得重新设计system。循环：工作→构建deviations→复古揭示模式→重新设计→测试运行→保留或丢弃。
Đọc implementation-notes.md và journal/retro gần nhất của tôi. Nhóm các deviation/friction theo loại. Loại nào xuất hiện từ 3 lần trở lên? Với MỖI loại đó, đề xuất một thay đổi system NHỎ NHẤT khử được nó. Loại nào dưới 3 lần: bỏ qua, đừng đề xuất gì.