Fable 5 的工作质量瓶颈在你澄清 unknowns 的能力，而不是模型本身。用 Thariq 的方法论系统性地把 unknown unknowns 变成 knowns，明天用 fable 做一次 Unknowns Sprint。
背景：Thariq 的 Fable 方法论
Thariq 在 "A Field Guide to Fable: Finding Your Unknowns" 中提出了一个核心框架：
- Map ≠ Territory — 你给 Claude 的 prompt/skills/context 是"地图"，真实代码库和问题是"领土"，两者差距 = unknowns
- 4 种 Unknowns：Known Knowns（prompt 里写的）、Known Unknowns（你知道自己不懂的）、Unknown Knowns（太显然不会写但看到会认的）、Unknown Unknowns（完全没考虑过的）
- 核心技能：在实施前、中、后系统性地发现和澄清 unknowns
Thariq 的技巧清单
| 阶段 | 技巧 | 解决什么 unknown |
|---|---|---|
| Pre | Blind Spot Pass | Unknown Unknowns → Known Unknowns |
| Pre | Brainstorms / Prototypes | Unknown Knowns（看到就知道） |
| Pre | Interviews | 模糊点 → 明确决策 |
| Pre | References | 无法描述的需求 → 源码参考 |
| Pre | Implementation Plan | Known Unknowns → 可执行步骤 |
| During | Implementation Notes | 追踪新发现的 unknowns |
| Post | Pitches / Explainers | 让 reviewer 快速对齐 |
| Post | Quizzes | 验证你真的理解了改动 |
选什么项目？
从手上活跃项目里，选 unknown 密度最高的。推荐排序：
| 优先级 | 项目 | 理由 | Unknown 密度 |
|---|---|---|---|
| 🥇 | Zouk PR #401（read-cursor persistence） | 你是 assignee；daemon ↔ server ↔ client 三层交互；崩溃恢复/并发/多设备同步都有 unknown | 高 |
| 🥈 | Tech News Automation 首跑 review | 明天 13:00 第一次自动跑；观察实际行为 vs 预期差距 | 中 |
| 🥉 | 下一个 blog 选题 | 用 brainstorm + blind spot pass 找写作角度 | 中低 |
5 阶段执行流程
预计总时长 3 小时（含 30 分钟风险 spike）。在 fable tmux session 里进行。
Phase 1: Blind Spot Pass (30 min)
目标：把 unknown unknowns 变成 known unknowns
我是 Zayn，Zouk 项目的 owner。我要做 read-cursor persistence（PR #401）。 我对这个 feature 的理解是：- 需要持久化每个用户/channel 的最后阅读位置- 涉及 server 端存储和 client 端上报- 可能和 WS push / activity feed 有交互 帮我做一个 blind spot pass：1. 读 zouk daemon 和 server 的相关代码（message_visibility, last_read, cursor 相关）2. 找出我可能没考虑到的 unknown unknowns3. 按风险排序：崩溃恢复 / 并发写入 / 多设备同步 / 性能 / 安全4. 每个 unknown 给我一个具体问题，让我回答后能缩小 map-territory 差距输出：一份 unknowns.md，列出 5-10 个 blind spots
Phase 2: Interview (20 min)
目标：澄清 unknown knowns
基于刚才的 blind spot pass，逐个问我问题。一次只问一个。优先问"我的回答会改变架构决策"的问题。对于每个问题，给我 2-3 个选项让我选（而不是开放式回答）。输出：澄清后的架构决策清单
Phase 3: Implementation Plan (30 min)
目标：把澄清后的 unknowns 变成可执行计划
基于我们的讨论，写一个 implementation plan。要求：- 重点放在最可能变的部分（数据模型变更、新类型接口、用户可见行为）- 机械性重构放最后（我信任你）- 每个步骤标注：这步解决了哪个 unknown- 用 HTML 格式输出，方便我在浏览器里看输出：plan.html — 带决策树的实施计划
Phase 4: Implementation + Notes (60-90 min)
目标：动手实现，追踪偏差
开一个新 session（保持 plan session 干净）：
这是 spec 文件和实施计划。开始实现 read-cursor persistence。 规则：- 保持 implementation-notes.md- 如果遇到 edge case 迫使你偏离计划，选保守选项，记在 "Deviations" 下，继续- 每个 deviation 标注：触发了哪个 unknown（如果是新发现的 unknown unknown，标 ⚠️）- 写完后跑相关测试输出：代码 + implementation-notes.md（含 deviations 列表）
Phase 5: Quiz (15 min)
目标：验证你真的理解了改了什么
我想确保我完全理解这次改动。给我一个 HTML 报告：- 改了什么（文件/函数级别）- 每个改动解决了哪个 unknown- 有什么 trade-off- 残留风险是什么 然后底部给我一个 quiz（5 道选择题），我必须全对才算理解了。输出：review.html + quiz
实现期防线
上面的主线解决开工前想清楚，这一层解决做的过程中出问题怎么办。unknowns 不只出现在计划阶段，实现中途冒出来的往往更贵。四条规则：
规则 1：先给参照物，再让它写码
Thariq 的观点：最好的 reference 是源码。Phase 4 开工前，把 zouk 里已有的持久化实现直接指给 Fable：
开始实现前，先读这两个参照：- daemon 里现有的 state persistence 路径（session / activity 相关）- server 端已有的 per-user 存储模式 用同样的语义和错误处理风格实现 read-cursor，不要发明新模式。规则 2：最险的一片先做 spike
Phase 3 计划完成后，先不要全量实现。挑风险最高的交互（多设备并发写 cursor）做一个 30 分钟的一次性 spike，验证假设再动真代码。prototype 阶段发现 unknown 的成本，远低于实现中途返工。
规则 3：deviation 分级，卡住就升级
- 小偏差（命名、内部结构）：记入 notes，继续
- 中偏差（接口、数据形状变化）：选保守选项，标 ⚠️，继续
- 大偏差（发现应该换一种解法）：停下来，回到 Phase 3 重新计划。Thariq 提醒过：unknowns 有时指向的结论是这个问题本身该换个解法
配一条 timebox：单个 bug 卡超过 20 分钟，让 Fable 先写 debug notes（已排除什么、当前假设是什么），再换角度或换 session。
规则 4：收尾产出 explainer，喂回下一篇 note
Quiz 通过后，让 Fable 把 spec、implementation notes、quiz 打包成一页 explainer。这份材料同时是 PR 描述、给 reviewer 的对齐文档、下一篇 zj note 的底稿。整个 sprint 的经验就沉淀下来了。
为什么这是好计划
- 直接应用文章方法论 — 每个 phase 对应 Thariq 的一个技巧
- 低风险高回报 — Blind Spot Pass 成本极低（30 min），但能避免实现中踩大坑
- 可验证 — Quiz 确保你真的理解了改动，不只是"让 Claude 写了代码"
- 可复用 — 这套流程可以套用到任何项目上
备选方案
如果不做 #401：
- Tech News Automation Review — 用 Blind Spot Pass 分析实际输出 vs 预期输出的差距；Interview 你对"好的 tech digest"的 unknown knowns
- Blog 选题 Brainstorm — "写一篇关于 agent 协作的文章，给我 5 个截然不同的切入点"