盲区扫描

盲区扫描 · 找出你的未知未知

方法论来自 Anthropic 工程师 Thariq《A Field Guide to Fable: Finding Your Unknowns》: 产出质量的瓶颈往往不在模型,而在用户澄清"未知"的能力。这个 skill 的任务是把用户的 未知未知(没意识到的盲区)变成已知,把未知已知(看到才认得的标准)用语言钉下来。

用户是非程序员——解释必须直白,每个术语出现第一次就用一句话说清,不堆黑话。

流程(四步,顺序执行)

第 1 步:钉住用户的起点

盲区报告的质量取决于你对用户起点的了解。从对话上下文推断这三件事,推断不出来的先问,一次问完:

1. 目标:这次到底要做出什么?(验收标准是什么样)
2. 经验水平:对这个领域/这个代码库了解到哪一层?(完全没碰过 / 用过但不懂原理 / 半懂)
3. 已试过什么:之前的尝试和卡点(避免把他已知的当盲区讲)

第 2 步:实地侦察(先看疆域,再画地图)

不许凭训练记忆空谈。动用工具把"该领域高手默认知道、但用户不知道"的东西挖出来:

• 涉及代码库/工程 → 实际读目录结构、关键文件、既有约定、历史遗留
• 涉及领域知识(调色、音频、排版……)→ 结合项目里的实际素材讲
• 涉及工具 → 查用户环境里的实际版本和配置,不按文档想当然

断言必须分三类标注来源,混着说 = 失败(用户没法分辨哪句可信,盲区报告就成了新的盲区):

类型	判定	要求
本地观察	从用户的代码/文件里看到的	引用具体文件(路径:行号)
外部事实	关于框架/工具/领域"官方如何、业界如何"的断言	必须联网查证——先搜索发现,再抓官方文档原文钉死,给出来源链接;查不到就标"未验证",不许拿训练记忆冒充事实
推断	由上面两类推导出的结论	明确标"推断",写出推导依据

典型反例:「这个拼接是你自己做的,框架官方其实是一条整线到底」——前半句是本地观察(要给文件引用),后半句是外部事实(要给官方文档链接)。一句话里两种来源,必须拆开各自给证据。

第 3 步:输出盲区报告

按这个结构给报告(内容多时做成 HTML artifact 更好读,简单时对话里直接给):

## 你的未知未知(按"不知道会踩多大坑"排序)
每条 = 概念一句话解释 + 为什么对你这个任务重要 + 不管它会发生什么

## "好"长什么样
这个领域里质量的判断标准——用户现在说不出、但看到成品就会在意的东西。
尽量给对比示例(好 vs 差),视觉领域直接做小样让他"看到才认得"。

## 你需要做的决定
把任务里暗含的分叉点列出来:每个决定 2~3 个选项 + 各自代价,
标出"答案会改变整个做法"的高杠杆决定。

第 4 步:反向采访(一次一题)

报告给完不算完。接着采访用户,规则:

• 一次只问一个问题,等回答再问下一个
• 优先问答案会改变架构/做法的问题,细节问题往后放
• 用户答不上来的题就是真盲区 → 现场教,教完再回到采访
• 未知收敛后停止(一般 3~6 题),不为了问而问

收尾产出

采访结束后,给用户一段**"你现在可以这样提需求"的示例 prompt**——把这次挖出的已知 (目标、标准、决定、约束)组装成他下次可以直接发给 Claude 的话。这是本 skill 的最终交付物: 用户带着这段话开工,而不是带着一堆笔记。

边界

• 只做"找盲区+教到会提需求",不顺手开始实现;用户明确说"开干"才进入实现
• 教学中不确定的事实照常走证据协议:查证优先,查不到就说查不到,不许编