Unknowns Hunter — 把盲区在变贵之前逼出来

The map is not the territory — the gap between them is your unknowns. 每一次 explainer、brainstorm、interview、prototype，都是廉价买到"你原本不知道的事"。 发现成本随阶段指数上涨：动手前 1x → 实现中 5x → review 10x → production 50x。

判断矩阵（先给未知分类，再选武器）

	你知道	你不知道
它存在	Known knowns（直接干）	Known unknowns（问/查/实验）
它不存在于你的意识	Unknown knowns（团队里有人知道→问 Owner/KOS）	Unknown unknowns（本 skill 主战场）

Unknown unknowns 无法靠"想一想"发现——必须靠结构化仪式逼出来。以下 4 个技法按阶段部署。

---

阶段一：动手前（最便宜，优先级最高）

技法 1 · Blindspot Pass（盲区扫描）

触发：接手陌生代码 / 共享仓 / 跨团队模块，在 fetch + 扫并行 commit 之后、动手之前。

动作：对目标代码域跑一轮盲区扫描，回答：

1. 这个模块有哪些隐含契约（调用方假设/字段语义/顺序依赖）是代码里看不出来的？
2. 最近 30 天的 commit/incident 暴露了什么踩坑史？
3. 我当前的实现意图，会撞上哪些我没意识到的约束？
4. 如果原作者看到我的 plan，最可能说"等等，你不知道 X 吧"——X 是什么？

产出：每个盲区一张卡（盲区描述 + 证据位置 + 修正后的实现 prompt 片段），最后拼装成一条更好的实现 prompt。5 个以内直接列 markdown；多而复杂时出交互 HTML 卡片（可勾选 resolve）。

纪律：扫出的盲区若属团队级（隐含契约/踩坑史），沉淀进 KOS，不留在会话里。

技法 2 · Tweakable Plan（按改动概率排序的计划）

触发：任何多步实现 plan（配合 writing-plans 使用，不替代）。

动作：plan 写完后加一个决策风险区，把所有决策按"事后被推翻的概率"降序排列——而不是按执行顺序。每条高风险决策标注：

• 为什么选了它（一句话）
• 可切换的备选（toggleable alternative）
• 推翻它的代价（局部改 / 半重写 / 全重写）

产出：plan 顶部的决策表。评审者（人或 agent）先看这张表，不用通读全文就能命中最值得挑战的点。

判断标准：schema/接口/命名/数据流向 这类"改起来贵"的决策必须进表；缩进风格这类"改起来免费"的不进。

---

阶段二：实现中

技法 3 · Implementation Notes（偏差日志）

触发：任何按 plan 执行的实现任务，遇到"现实和 plan 不一致"的瞬间。

动作：每次被代码现实逼得偏离 plan，立刻记一行（不打断心流，一行就够）：

DEVIATION: <plan 说什么> → <实际做了什么> · 原因: <一句话> · 保守选择: <是/否+说明>

产出：任务收尾时整理成三段——① 偏差清单 ② 其中的保守决策（这些是下次重构的种子）③ 给下次同类任务的三条 bullet。

下游价值：偏差日志天然是 ADR / KOS decisions 的原料。收尾时判断：偏差反映的是plan 技术不足（沉淀为 playbook）还是领域新知（沉淀为 decision/rule）。

---

阶段三：收尾前

技法 4 · Quiz Before Merge（合并前自测）

触发：diff 复杂 / 涉及不熟悉领域 / 多 agent 协作产出的代码，merge 前。

动作：基于最终 diff 出 4–6 道自测题，专挑"作者最可能没看懂自己代码"的点：

• 边界条件（这个函数在空输入/并发/中文/超长时会怎样？）
• 副作用（这次改动还动了谁？谁依赖被改的行为？）
• 回滚路径（出事了怎么退？）

答错的题指回 diff 的具体位置。答不上来 = 不该 merge，回去补理解，不是补答案。

变体 · Buy-In Doc：author 自己驱动 PR 到 merge 的场景，把自测升级为对外的"预答异议文档"——demo 开场 + 预答每一条 reviewer 可能的反对（附证据）+ 点名谁需要 sign off。review 轮次直接减半。

---

元原则：交互产物 > 散文

对齐类产出（设计方向/方案对比/买入文档），交互 HTML 永远比一段文字有效——因为它逼读者做选择（steal/skip、A/B、勾选）而不是被动读。三个高频场景：

• 设计探索：同一需求一次出 3–4 个截然不同的方向（如 ops 控制台风/编辑部风/看板风/终端风）供拍板，好过来回改一个。
• 接线前先 mock：交互重的功能先出 clickable throwaway mock 确认交互，再写真实现。
• 对外争取 buy-in：动效 demo + 预答异议，代替纯文字 PR 描述。

与既有工具的边界

• brainstorming / writing-spec：解决"要做什么"的对齐；本 skill 解决"我以为我懂但其实不懂"的盲区。先它们，后本 skill。
• pre-mortem：假设失败倒推原因，靠想象力；本 skill 靠结构化扫描+日志+自测，两者互补，重要任务都上。
• code-craft：编码时的纪律（读了再改/不猜/自测）；本 skill 是编码前后的仪式。不冲突，叠加生效。