Find Blind Spots

---
name: find-blind-spots
description: Use when the user asks for consequential knowledge, assumption, implementation, or verification gaps in accessible chats and current projects, including architecture, technology selection, completed changes, post-launch operations, and peer practices. Also use a lightweight pass at consequential decision checkpoints when a specific unexamined assumption could change the recommendation. 适用于“结合我们可访问的聊天和当前项目，找出一个我最有必要知道、但可能尚未考虑或落实的关键点”“重点检查这次改造上线后的问题，给出证据和最小验证动作”“基于所有聊天说一个我必要但可能不知道的知识”“我没想到什么”“还有什么坑”“同行做了什么而我没做”等请求；不要求出现“盲点”或四象限术语。普通事实问答、翻译、窄范围编辑和仅解释概念不触发。
---

# find-blind-spots

找出当前最值得补齐、能改变行动的 Knowledge gap（知识缺口）、Assumption gap（假设缺口）、Implementation gap（实施缺口）或 Verification gap（验证缺口）。覆盖损失规避、收益机会、已有知识的新用途和实施后的运行责任，不追求惊奇、焦虑或检查项数量。默认回答一个主发现，附 ASCII 四象限表，用用户的语言解释到足以行动。

## 适用边界

Explicit invocation（显式调用）时完成盲点分析；Implicit invocation（隐式调用）仅在具体未验证假设可能改变架构、选型或发布建议时做轻量检查，先交付主任务，有实质发现才附简短提醒和紧凑的 ASCII 四象限表，无发现则不追加表格。仅出现“架构”一词不触发；普通事实问答、翻译、窄范围编辑和单纯画概念图不升级为审查。

技能支持分析和任务范围内的只读取证；不新增改代码、部署、外发信息或付费权限。实验、Fault injection（故障注入）和真实副作用遵循当前授权。不将运行时取得的个人敏感信息或项目私有材料写回可复用技能。

## 先区分四件事

这是工程化分析框架，不是统一的学术分类或对用户心理状态的测量。

| 维度 | 可用状态 | 判断依据 |
| --- | --- | --- |
| Awareness（问题觉察） | 明确考虑过／当前材料未体现／无法判断 | 对话、设计决策、实际检查范围 |
| Evidence（命题证据） | 已验证／用户陈述／推断／待验证／证据冲突 | 来源、日期、版本、适用条件 |
| Confidence calibration（信心校准） | 与证据匹配／信心超过证据／不确定自己是否知道 | 显式信心与证据，不猜测内心 |
| Decision impact（决策影响） | 会改变路线／局部影响／暂不影响 | 若命题为假，具体哪个选择要变 |

**Known Unknowns 是知道自己不知道；其中会改变方案的部分才是 Critical unverified assumptions（关键未验证假设）。** 不确定自己是否知道时，保留 Metacognitive uncertainty（元认知不确定）：先尝试找到已有解释、记录或演示能力，再核验，不硬塞进“知道／不知道”。

组织默认四象限表时，读取 [认知模型与来源](references/knowledge-model.md) 的四象限定义；研究背景仅在需要解释或引用理论时展开。需要架构、选型、上线或同行差距的扫描方向时，读取 [决策与生命周期视角](references/decision-lenses.md)，仅应用与当前阶段相关的部分。

以下流程把 Layered Prompt、Prompt Chaining、Self-Contrast 和有工具时的 ReAct 思路落实为具体动作。仅在维护策略、比较替代方法或解释研究依据时读取 [策略取舍与来源](references/prompt-strategies.md)，不要每次叠加全部策略。对用户只展示结论、关键依据与验证动作，不输出内部候选推演、模拟辩论或逐步思考记录。

## 工作流程

### 1. 锚定上下文

用一句话锚定目标、当前决定或已做的改动、阶段及成功条件。用户给出多个方向时跟随当前明确任务；历史里的高频兴趣不自动等于最重要的缺口。

请求“所有聊天”时按环境规则使用实际可访问的历史检索，针对候选主题查决定、反例、已实施措施和后续更新；当前上下文充分则不重复检索。说明覆盖限制，不声称读过不可见历史，也不无目标地扫描整个仓库。

项目以已读的当前文件、配置、Call chain（调用链）和 Runtime evidence（运行证据）为准；旧聊天只说明当时状态。文档、组件安装、Unit tests（单元测试）通过各自仅支持其实际覆盖范围。区分用户陈述、实读证据、外部来源和推断；变化中的版本、价格、许可或平台限制查当前一手资料，受限时标明未核验。

为会影响主发现的命题维护简短 Evidence ledger（证据底稿）：`命题 → 来源及日期/版本/范围 → 支持或反驳什么 → 仍缺什么`。后续筛选沿用这些状态，不把推断在转述时升级为事实。多个摘要若来自同一原始材料，只算一个来源；模型生成的答案和自选示例不能成为它自己的验证证据。时间戳描述来源适用性，不改变模型的 Knowledge cutoff（知识截止时间）。

先看当前证据，再用经验生成候选。没有材料只能给条件性候选；仅当缺少的信息会改变首要建议时问一个有区分力的问题。用户不想回答时，明确条件后继续分析。

### 2. 发现候选并寻找 Counter-evidence（反证）

按相关视角生成少量候选，兼顾边界失效、收益与简化、已有知识的重新连接。每项建立 Causal chain（因果链）：“当前选择或遗漏 → 触发条件 → 具体机制 → 目标结果”，不能建立联系的通用提醒不列为发现。架构、选型及已实施改动至少追踪一个与变化直接相关的 Post-launch scenario（上线后情境），不展开通用运维清单。

再检查“用户是否已经处理过它”“已有材料是否埋着答案”“当前阶段是否根本不需要它”。区分个人、团队、Agent 各自掌握的知识。记录与口述冲突时保留两者的来源、时间和范围，先核对，不能把旧证据直接当作当前验证。

对暂定主发现做一次 Falsification check（可证伪检查）：什么具体证据出现后，应撤回或缩小这个发现？优先核对最有力的替代解释，例如其他层已提供等价能力。找到支持、反驳或仍无法区分的证据后，分别保留、修正或降级为待核验项；不要为完成“自我反驳”强行改答案，也不要求凑三条反证或用分数相加决定真伪。

有可用工具且允许读取时，按 `待核验命题 → 最小只读查询 → 实际 Observation（观察结果）→ 更新证据状态` 补齐关键缺口。工具失败、无权限或未找到结果都不证明能力不存在；无法取证时保留 Unknown，并给可执行的验证建议。同一查询未带来新证据时不反复重试，除非有具体可修正的错误或数据已更新。

分别判断**领域机制的可靠性**和**用户缺口的证据**，前者不能证明后者。缺口标为：Confirmed（已确认：明确陈述，或界定范围内查到缺失、冲突、失败）、Suggestive（有线索：具体迹象但存在其他解释）、Unknown（尚不清楚：仅未提及或资料不可访问）。后者只能称待核验项。

再单独标记 Implementation status（落地状态）：未决定／已决定未落实／已落实未验证／已验证但范围有限／已验证且当前适用／有意不做。区分“实施已确认”和“用户说已实施”。知道风险但没演练是 Verification gap；已接受的 Trade-off（取舍）只有在新证据改变条件时才重提。

### 3. 选择最有决策价值的一项

依次考虑决策相关性、影响与时间窗口、缺口证据、相对现有知识与防护的增量价值、验证及实施成本。收益、删减和复用也能改变决策；优先能以合理成本取得新证据的候选。后果严重可提高核验优先级，不能提高结论置信度。

若多个候选都可能改变同一决策，做 Bounded comparison（有限比较）：保留最多 2–3 个机制不同的候选，比较支持证据、最强反证和能区分它们的检查；被证据淘汰才切换。证据明显支持一项时直接采用，不为模拟 Tree of Thoughts 扩搜；证据仍分不出时优先选择最有信息价值的验证。不要把同一模型生成的多个答案当作独立证明，也不用多数票代替证据。

不用无依据的概率或精确风险分数。低成本试用不自动需要生产级治理；同行采用某做法不是本项目必须采用的理由。外部案例须交代规模、负载、团队或约束的可比性，检查现有等价能力。一个案例仅证明该案例，不证明行业采用率。

存在真实可比性且要断言当前同行做法、技术行为或政策时，检查最新的一手资料并引用。无法检索时改写为待验证的经验假设，不虚构公司、普及率或来源。

没有足够证据支持新的重要盲点是有效结果：简要说明，最多给一个条件性候选或用于区分的检查，避免硬凑结论。

### 4. 把发现变成最小验证

为首要发现写清：待验证命题、最小检查或实验、可观察的 Pass/fail criteria（通过／失败标准），以及两种结果分别如何影响选择。阈值优先来自现有目标；没有目标时给出标明为建议的判据，不能替用户编造 SLA、预算或已获批准的门槛。

**Known Unknowns → 按影响验证。** 对会推翻当前路线的关键假设标 `★ 优先验证（阻断点）`，在相关重大投入前安排最小可行性验证，必要时用 MVP（Minimum Viable Product，最小可行产品）或准备 Fallback（备选方案）。已有记录、样例或小实验足够时无需先造完整产品。明确：通过后推进什么；失败后停止哪项投入、如何止损或调整方向；结果不明确时补什么证据，不能按通过处理。普通已知未知不自动成为阻断点。

**Unknown Knowns → 显性化并核验。** 有已有记录、经验或代码线索尚未用于当前决策时，读取 [显性化方法](references/decision-lenses.md#unknown-knowns显性化方法)，按缺口选用接盘人文档、AI 对立面提问或 Reverse extraction（反向萃取）；把结果连接到具体设计约束或可复用能力。输出分清“提取到的事实”“推测的理由”和“仍待验证的契约”。

其他证据缺口用检查或实验；信心超过证据用反例与失败路径；剩余未识别风险用有界试用、Observability（可观测性）、隔离、余量和恢复能力应对。

能命名的未知已进入候选问题集；不能宣称列举完了 Unknown Unknowns。完成首要候选的证据、影响、验证和结果分支后结束，交代关键范围限制即可。

## 默认 Output contract（输出契约）

默认顺序：**一个主发现 → ASCII 四象限表 → 主发现的证据、影响和最小验证**。用户明确指定其他格式或不要表格时遵从。

四象限表放在 `text` 代码块中，用 ASCII 字符 `+`、`-`、`|` 画边框，不用 Markdown 表格。固定布局如下；单元格中的文字是填表规则，实际回答替换为当前材料支持的内容：

```text
                        已纳入考虑                     尚未提取或纳入
              +------------------------------+------------------------------+
已有可用知识  | Known Knowns                 | Unknown Knowns               |
              | 已知已知                     | 未知已知                     |
              | 1. 最重要的有据事实          | 1. 最重要的已有知识连接      |
              +------------------------------+------------------------------+
尚缺可用知识  | Known Unknowns               | Unknown Unknowns             |
              | 已知未知                     | 未知未知                     |
              | 1. 最值得验证的问题          | 尚未识别，无法具体列出       |
              +------------------------------+------------------------------+
```

- 每个象限独立按决策重要程度降序编号 `1.`、`2.`、`3.`，最多显示三项；只有一项或两项就只列相应项，不为填满数量新增候选。
- 每项用简短具体措辞；长句在同一单元格内换行，尽量按等宽显示对齐边框。表中条目是主发现的背景与定位，不自动扩展成多个主发现。
- 已知未知、未知已知中的条目用 `事项 -> 对应动作` 简写：关键假设可写 `1. ★ 付费意愿 -> 优先验证`，已有知识可写 `1. 重试约束 -> 接盘人文档`。表后仅展开主发现的具体方法及结果分支，不因有多个条目新增多套行动计划。
- 没有可支持条目时写“暂无确认项”或“尚不清楚”，无需编号。未知未知默认注明“尚未识别，无法具体列出”；已能明确命名的问题归入已知未知，不伪造未知风险清单。觉察无法判断的待核验项应明示这一限制，不强行推断用户此前没想到。
- 编号仅表示各格内优先级；主发现的全局优先级在开头说明。用户要求全量时，表中保留每格前三项，其余合格条目放在表后续列，不能截断。

表后用短段落或短列表说明主发现：

- **证据与影响：** 引用聊天、文件或已做的决定，区分事实与推断；说明知识、假设、实施、验证或适用范围缺口，以及触发机制、不适用条件和用户缺口确认程度。
- **最小验证：** 做什么、看到什么算通过、失败后怎样调整。

可以用“最值得检查的是……；目前材料证明了 X，还没证明 Y”。避免“你大概率不知道……”式心理断言。

要求展开审查时，默认展开优先级最高的 3–5 项，不凑数；用户指定数量则遵守，明确要求全量时保留所有合格发现，不能用默认数量截断。保留 ASCII 四象限总览，另用平行列表列出各发现的来源与范围、缺口状态、影响、验证及结果分支。

## 交付前 Contract check（契约检查）

通常做一次静默检查：主结论和表格是否沿用同一证据状态；是否把计划写成了已观察结果；最小验证能否区分结果并改变行动；是否符合上面的数量、ASCII 和编号规则。发现矛盾时只修正受影响内容，必要时针对性取证；没有新证据不反复自评或提高置信度。保留完整交付内容，不套用“只输出修改后一句”的 Mirror Test 模板。