左列是 Thariq 找「未知」的每一招，右列把每一招焊到你自己的酒仙桥 / 就三桌 / AI 工程 / 视频 / 风水勘察上——不泛化，只落到你真实的项目、规则号和原话。模型强到瓶颈变成「你能不能讲清自己不知道什么」，这篇讲的正是你已经在做的事。
源：Thariq Shihipar（Anthropic Claude Code Team）2026-07-03《A Field Guide to Fable: Finding Your Unknowns》 · 提炼见 wiki/concepts/finding-your-unknowns.md · book-mirror 镜像
你给 Claude 的 prompt / skill / context 是「地图」——对要做的活的一份表征；真实的代码库、现实世界、它的实际约束是「疆域」。两者之差 = unknowns（未知）。Claude 每撞上一个 unknown，就得基于"对你意图的最佳猜测"做一次决策；活越大，撞上的越多。
核心断言：Fable 5 是第一个"工作质量瓶颈在于你能否澄清它的 unknowns"的模型。模型强到这份上，你表达的清晰度成了短板，不再是模型能力。
光提前规划不够——unknown 可能藏在实现深处，也可能反过来告诉你"这问题该换个方式解"。所以跟 Fable 协作是一个"在实现前 / 中 / 后不断发现自己 unknowns 的迭代过程"。
"瓶颈从模型能力转到你能不能讲清要什么"——这就是你 Loop Engineering 的命门"定义目标 = 管理"。你早就把这句话拆成规则：r_070 短指令/模糊任务先升级成目标协议（目标·背景·约束·验证器·停止条件·交付）。Thariq 说的"讲清 unknowns"，就是你说的"把祈使句转成可验证目标"。
"地图 ≠ 疆域" ≈ 你的〔现象大于环境〕：别信"专业环境=安全"的地图预设，信亲身现象的疆域。也 ≈ 你的铁律「Read before write」——"Looks orthogonal 是这套代码里最危险的话"，正是"我的地图漏画了疆域里的一条路"。
"发现 unknowns 与验证器先行是一体两面"：验证器先行是"先钉死怎么算成了"，发现 unknowns 是"先挖清哪些你还没定义"——都是在变贵之前把不确定性挖出来。这篇不是新方法论，是给你已有纪律的一套更细的手法。
拆一个问题的四种缺口。最好的 agentic coder 不是没 unknowns，而是懂得预判、为它留余地——这恰恰是 agentic coding 的核心手艺，而且能通过跟 Claude 协作练出来。
| 象限 | 是什么 / 怎么办 |
|---|---|
| 已知的已知 | 你 prompt 里明确写了的 |
| 已知的未知 | 你知道自己还没想清 → 让它采访你 / 出计划暴露 |
| 未知的已知 ⚠ | 太显然懒得写、但一看就认得 → 早期原型逼出来（最易漏） |
| 未知的未知 ⚠ | 压根没考虑到 → Blindspot pass 盲点扫描 |
你已经把整个"未知的已知"象限做成了基础设施——记忆中枢的牌匾。那些"太显然懒得每次写、但错了你一眼认得"的隐性判据，你没靠每次 prompt 重写，而是沉进 placard：时区永远北京 CST、称"他"不称"她"、「就三桌」不能写成「三桌就」、「尚衡」是风水艺名不是餐饮项目。这些正是 Thariq 说"一看就认得、平时不会写下来"的东西——你把它们从"每次靠记性"升级成"中枢无条件 prepend"。
"未知的未知"= 你进新领域的默认动作（下一张卡 · 视频调色 / 陌生代码库）。
"已知的未知"= 你的 r_070 目标协议 + brainstorming skill：先把"我知道自己还没定的"逼到台面。
Thariq 说"这手艺能练出来"，对你就是：你不是天生知道所有约束，是靠一次次被 agent 踩坑（pitfall 命中）反推出规则、沉进中枢——你的规则库就是你把 unknowns 逐条驯化的账本。
指令是个微妙的平衡：太具体，Claude 死守指令、该 pivot 时也不 pivot；太模糊，Claude 套行业默认最佳实践，未必合你的活。
不为 unknowns 留余地 = 两头都输：你既不知道哪段路有坑，也不知道哪段路其实通畅（本该让 Claude 放手改）。
这条张力你两端各有一条铁律，别把它们对着用。
· 防"太模糊"：你的「不确定处停下来问、不瞎猜」+ r_070「无可验证终点先反问」——判据太弱（"让它 work / 跑起来"）就停下来问怎么算成功。
· 防"太具体到锁死"：你的「不过度设计、不加用不到的抽象」（此条优先级更高）+ Implementation Plan"机械重构埋底下我信你"——该放手的地方放手。
正确合并理解：把"验证器/红线"钉死（这里要具体），把"具体做法"留松（这里给 Claude 余地）。你的原话就是这个结构——"尺子不动，做法随便迭代"。别反过来：把做法写死、却没定义什么算成功，那正好两头输。
这个过程最重要的动作：给 Claude 你的起点上下文——你在思考的哪一步、你对这问题/这代码库的经验深浅、把它当 thought partner 用。
Claude 搜代码库和网络极快、平均知识比你广、从失败迭代也快，所以它能帮你更快发现你的 unknowns。多数产物用 HTML artifact 承载最合适。
你反向做了同一件事——把"你的起点"固化进中枢，让每个 agent 一上来就知道跟谁在协作。牌匾里写死：高中学历 + IT 背景的餐饮经营者、懂网络基础但不懂 git/PR/daemon、用 AI 做真实生意不是程序员。配套规则〔说人话 + 英文术语带中文注释〕〔别凭空编 baseline，拿不准当面问〕——这正是 Thariq 说的"disclose your experience with the problem"，只不过你做成了一次配置、全 agent 复用。
"把它当 thought partner" ≈ 你的〔活档协作模式〕：TG 口述 + 活档 + 回执闭环，agent 是搭档不是下属（〔跟飞飞是搭档不是下属〕）。
"HTML artifact 最适合承载" = 这篇作者的前作，也是你的默认：html-first-output skill——发你看的一律纯静态 HTML（iOS 文件 App 不跑 JS，这份镜像就是照这条做的）。
进代码库不熟的区、或用 Claude 做不熟的活（如迭代设计），你手里全是 unknown unknowns——不知道该问什么、好是什么样、历史上踩过哪些坑。让 Claude 帮你找盲点并讲给你听，用字面词"blindspot pass"和"unknown unknowns"。给它你的身份和已知很重要。"我要加个新 auth provider 但完全不懂这代码库的 auth 模块。做个 blindspot pass 帮我理出相关的 unknown unknowns，好让我更好地 prompt 你。"
"我不懂什么是调色但得给这视频调色。教我理解我关于调色的 unknown unknowns，好让我 prompt 更准。"
Thariq 举的第二个例子就是调色——这几乎是照着你的 DJI Pocket4P 视频专题写的。你启动视频项目、定了 D-Log2 调色优先，但你是这行外行。碰到"视频发闷"时，正确动作不是"让 AI 出几版我挑"（你没有判据，挑不动），而是"让 AI 先教我调色是什么"——先消掉自己的 unknown 再动手。这条你可以直接抄作业。
你的〔5 步 debug 不瞎猜〕就是代码侧的盲点扫描：报错/搜不到先复现再归因，禁"听起来合理"的无证据猜——"听起来合理"往往正是盲点在冒充已知。
你已有的习惯 = concept-fable / 费曼式学习：碰到值得真正搞懂的概念（复利、幸存者偏差、过拟合）先讲透再用。把它前移到"进新领域第一步"：碰第一次的代码库（当年 memory-hub 加 session_id）、第一次的风水古籍、第一次的调色——先让 Claude 做 blindspot pass，而不是硬试。
在"看到才知道要什么"的地方（尤其视觉），早期原型能廉价逼出"未知的已知"——实现中才发现代价高得多（小改动可能引起代码里剧烈的重写，agent 也更难回退）。
他几乎每次 coding session 都从 exploration/brainstorm 开局，用意图定 scope，防止 scope 定太窄或太宽。"我要给这堆数据做看板，但没视觉品味也不知道能做成啥样。给我一个 HTML 页，放 4 个差异极大的设计方向，我来挑。"
"接后端之前，先用假数据做个单 HTML 文件 mock 新工具栏，我要先对布局做反应，你再碰真 app。"
"用户 onboarding 后流失——搜代码库、头脑风暴 10 个能干预的点，从最便宜到最激进，我告诉你哪个 resonates。"
你装了 superpowers:brainstorming skill，而且已经在真项目里跑通了这一招。酒仙桥排风方案动画 HTML就是典型："先做能跑的交互原型（滑块调参、实时算风量）让飞飞对着反应，再定方案"——正是"先 mock 布局、别急着接后端"。
"没视觉品味、给我几个差异极大的方向我挑" = 你看板改版的默认路径：restaurant-insight / dashboard 风格默认逻辑（单人手机→简约、多人桌面→中后台），本质就是"给我几版差异极大的挑"。
"从最便宜到最激进列 10 个干预点" ≈ 你的〔复合信号决策〕+ 就三桌 erosion 诊断：利润下滑不是二元 go/no-go，先让 AI 把"能动的地方"从便宜到激进摊开（改配方 / 调价 / 联营 / 引流…），你再挑哪个 resonates——而不是一上来锁死一个方案。
"用意图定 scope、防太窄太宽" = 你〔深入项目前先轻量收口再推进〕：接项目先扫 followups-pending、别一头扎进去。
风暴够了通常还剩 unknowns。让 Claude 采访你——一次一个问题，优先问"答案会改架构"的。采访时给它你的问题背景来引导它提问。"就任何模糊/有歧义的点，一次问我一个问题，优先那些我的回答会改变架构的。"
你的风水 / 命理线本来就是"结构化访谈优先"，这一招你天天在用。feiver-fengshui-collaboration 项目初始化 9 步里，勘察前先逐个问——酒仙桥就是"Q1–Q5 逐题发，Q5 发了 4 个现场尺寸，等飞飞测量回数"，不是一次糊一大坨。bazi / qimen-dunjia / ziwei-doushu 三个 skill 全是"正式排盘前先做结构化访谈，再调脚本计算"——排盘前那句"信息够了，开算 🔮"，就是采访收敛的信号。
"优先问会改架构的" = 你的〔连发多条澄清先等说完再改〕：分多条逐步澄清同一件事，hold 到语义收敛再落地，别每条跳枪导致 toggle——本质是"先把会改结构的答案等齐，再动手"。
增量提示：餐饮 / 合同这类你目前偏"自己想清再交代"的活，也可以让 Claude 先反向采访一轮——酒仙桥合同哪些条款"我的答案会改整份协议结构"（分账口径、退出条款），先被问出来，比事后返工便宜。
有时你讲不清要什么——没那个词汇，或复杂到描述半天。这时最好的答案是给参考。图/文档/图片都行，但绝对最好的参考是源码。
有个库以某种方式实现了、或有个你喜欢的设计组件，就把 Fable 指向那个文件夹、告诉它看什么，哪怕是别的语言。Claude Design 也是这么干的——你指它一个网站上的模块，它读底层代码而非截图，拿到的是 markup、结构、组件真正怎么搭的丰富细节。"vendor/rate-limiter 这个 Rust crate 实现了我要的退避行为，读它，用同样语义在我们的 TS API 客户端里重写。"
"指源码当参考、别用文字描述"已经是你 book-mirror 自己的硬规：这份镜像的做法就是"必读 02-report-wechat-2026-05-09-mirror.html 当 class 体系 + inline CSS 样板"——不描述"我要个双列卡片深色 hero"，直接指现成源码照搬结构。
≈ 你的〔cp 文件后必须 Read 才能 Edit〕+ 看板复用现有 wrangler 项目：改看板"读现有 index.js 当样板、别凭记忆写"，新 worker "复用 goalmirror 同模式"——都是"指现有源码，不凭空描述"。
≈ 你沉淀的〔设计稿当真相源驱动开发〕（宝玉）+ codebase-design："UI 不对回改设计稿不改码""接口即测试面、读现有代码找 seam"——同一个信念：一份真实的参考物 > 一段自然语言描述。
可直接抄的新用法：做新看板/新页面时，与其跟 Claude 描述风格，不如指它一个你截过图存着的好页面/一个现成组件目录，让它读底层实现——比你 IT 背景硬憋前端词汇省事得多。
准备实现时，让 Claude 出一份计划给你 review，但聚焦在最可能改的部分——数据模型、类型接口、UX 流程。把这些摆前面，让 Claude 浮出你可能真得改的东西；机械重构埋最底下，那部分信它。"写个 HTML 实施计划，但先摆我最可能改的：数据模型改动、新类型接口、任何面向用户的部分；机械重构埋最底下，我信你。"
"把最可能改的摆最前"直接对应你迭代最频繁的两样东西——合同条款和看板数据模型。
· 酒仙桥股东协议已经迭到 v1.6，最常动的是分账口径（40/30/30）、借款利率（5–6%）、退出/锁定条款（锁 2 年）——这些就是"我最可能 tweak 的"，让 Claude 出方案时摆最前逐条 review；措辞润色那种机械活埋底下。
· 看板改版同理：先把数据模型 / KV key 结构 / 分账规则摆前（你踩过〔加新字段必须同步上下游 whitelist〕〔cleanup 脚本 PUT 必须保留全字段〕的雷，正是"数据模型改动"最贵），CSS 微调埋底下。
"机械重构信你" = 你的 surgical + 不过度设计：机械活让 agent 自主，但改动范围只碰直接相关的几行。
"出计划给我 review" = 你的〔多步任务先列带验证点的 plan〕：每步明确 verify=怎么算成了——Thariq 把"易变项前置"叠加进来，让 review 更聚焦在会翻车的地方。
再多规划也有潜伏的 unknown unknown——agent 干着干着发现代码里有个 edge case 逼它换招。让 Claude Code 维护一个临时 implementation-notes.md，记它做的决策和偏离，好从下一次尝试里学。"维护一个 implementation-notes.md。如果撞上边缘 case 逼你偏离计划，选保守方案，记到 'Deviations' 下，继续走。"
"撞边缘 case → 选保守 → 记下来 → 继续"几乎逐字复刻你的三条纪律。
· ≈ Checkpoint（Mnilax Rule 10）：多步任务每完成 1 步必 checkpoint——这步做了啥 / 验证了啥 / 还剩啥；说不清当前状态就立刻停。implementation-notes.md 就是把 checkpoint 落成文件。
· "选保守方案、留债明说" ≈ 你的 no-tech-debt 铁律："必须留债时明确告诉飞飞拍板"——Thariq 的 'Deviations' 段就是这块债的登记簿。
· ≈ Fail loud（Mnilax Rule 12）：不确定是否成功必须明说，默认浮出不藏。"偏离了计划"绝不能静默吞掉——正是你最恨的"30 条静默 skip 了"。
你现在的偏离记录散在 TG 回执和活档里；Thariq 这招提示你可以让长任务 agent 自己维护一份 implementation-notes.md，跑完连同 diff 一起交，比事后翻聊天记录复盘"它到底为啥这么干"省事——尤其你常派 Codex/subagent 跑大改动。
发布一样东西，很大一部分是拿到认可和审批。把 pitch / explainer 打包进最终文档能：①当 reviewer 和你起点相同的 unknown 时，加速理解；②当专家想看到你把 unknown 和常见失败点都考虑到了时，加速审批。"把原型、spec、implementation notes 打包成一个能丢 Slack 要 buy-in 的文档，用 demo GIF 开头。"
你要 buy-in 的对象不是 Slack 里的工程 reviewer，是酒仙桥的合伙人和风水客户——但逻辑一模一样。
· 酒仙桥：给杨哥 / 张姐 / 张济大的合伙材料、shigong.shangfei.shop 现场施工看板、ssot-to-multi-artifact（一份 Markdown SSOT → PDF + 网页 + 部署同源）——正是"把方案打包成一个能发出去要拍板的文档"。
· "reviewer 起点和你相同" = 你的〔说人话 + 术语带中文注释〕：合伙人不懂你那套，材料得从他们的起点讲起，正是 Thariq 说的"accelerate understanding when reviewers start with the same unknowns"。
· 风水线（尚衡）：给客户的方案 Living Doc，同一招——先把"你考虑到的失败点/化解"摆清楚，加速对方点头。
"用 demo GIF 开头" = 你的〔complete-work-showcase〕：展示能力优先给能点开、能体验、能转发的完整作品，在线版是试玩橱窗。你的看板 URL 就是你的 demo GIF。
长 session 后，Claude 可能干了比你意识到的多得多。只读 code diff 只能给你浅理解，因为很多行为依赖既有代码路径。让 Claude 给你一堆上下文后考你一遍，帮你真搞懂发生了什么。他只在测验全对之后才 merge。"给我一份 HTML 报告讲清这次改动的上下文/直觉/做了啥，底部出个测验我必须全对。"
这是全篇对你最实在的一条增量——正好补你一个已知的缺口。你经常派 Codex / subagent 跑完大改动，自己常常只看 diff 浅懂就收了。Thariq 这招提示把它固化成"考我一遍再收"。
要看清它跟你现有招的分工——别当重复：
· 你的 codex-cross-review / 〔让 Codex 5.5 复核〕考的是机器：改对没、有没有 gap（trust-but-verify，防 LLM 自验自骗）。
· 你的 rubric-gate / 5 问 audit 考的是流程：收口该查的逐条机核过没。
· Thariq 的 quiz 考的是你自己：你到底懂不懂这次改了什么——补的是"人这一侧的理解"，前两者都不覆盖。
正好接住你〔报完成前必须独立回核〕（Maker ≠ Verifier）的精神：机器要被独立验，人也一样——"我看过 diff"不等于"我懂这次改动"，正如"测试过了"不能是"跳了几条"。建议：大改动 merge / push 前，让 agent 出个 HTML 报告 + 底部 quiz，全对再收——把它加进你的收口/存盘协议当可选步。
Fable 发布视频整支由 Claude Code 剪辑，Thariq 是这个领域的外行。他的做法完美示范"先发现 unknown 再动手"：
① 从已知起步——知道 Claude 能用代码剪+转写视频，但不确定精度够不够 → 让 Claude 解释 Whisper 转写原理、能否用 ffmpeg 精确剪掉 "um"/停顿。
② 想要 UI 跟说话的词同步但不确定能做到 → 让 Claude 用 Remotion + 转写做个原型验证。
③ 视频发闷（调色问题）——但他不知道"好的调色"长啥样，"让 Claude 出几版挑"行不通（没判据）→ 改为让 Claude 教他调色，先消除自己的 unknown。
这个案例就是给你 DJI Pocket4P 视频专题写的剧本——你也是外行，装了整套视频 skill（hyperframes / faceless-explainer / motion-graphics），路数可以照搬。
① 从已知起步、验证精度 = 你的验证器先行：不确定 AI 剪辑精度够不够，先让它解释原理 + 小样验证，别一上来押整条片子。
② 先做原型验证"能不能做到" = 你已经在跑的路（尚衡风水科普 MP4 demo、HyperFrames 原型）——先出一小段验证 UI/字幕同步，再铺全片。
③ 调色那段是你的原句剧本：你定了 D-Log2 调色优先但你是外行。记住 Thariq 的教训——视频发闷时别急着"让 AI 出几版我挑"（你没判据挑不动），先让 AI 教你调色是什么、把自己的 unknown 消掉，再谈出版本。
一句话记忆（原文收尾）：每一次 explainer、brainstorm、interview、prototype、reference，都是在它变贵之前，廉价地发现你原本不知道的东西——这跟你〔验证器先行〕〔止损框架〕〔轻量测试优于重投入〕是同一句话。下个项目第一步：让 Claude 帮你找 unknowns。