给 Agent 派活前，先让它找一次盲点
Thariq Shihipar 在一篇 Fable 使用记录里写过一条实际使用的提示：准备给陌生代码库增加一种登录方式时，他不会马上叫 Claude 开工，而是先告诉它，自己不了解这个项目的认证模块，请它做一次 blindspot pass。
这句话比”帮我做个方案”窄得多。Claude 只找那些他还不知道、却会影响下一步提问的问题：项目已经支持哪些 provider，回调在哪里处理，账号靠邮箱合并还是各自独立，测试又是怎么跑的。
做过类似需求的人都知道，OAuth 那几段代码未必最拖时间。写到一半才发现用户模型不允许同一邮箱绑定两个来源，前面的表结构和流程就得一起改。
需求写得很长，也挡不住这种返工。那一刻，问题本身还没有进入你的视野。
先查缺口，再谈方案
我们平时给 Agent 补上下文，补的都是已经知道的东西。页面放哪里、字段叫什么、这次不能改哪张表，都能提前写进去。可你第一次进入认证模块，连哪几个决定会牵动架构都不知道，自然也写不出来。
Agent 恰好可以先干这件事。它能搜索相邻实现、测试和提交记录，把”这里通常要注意什么”压到当前仓库里。这个顺序很重要：先让它暴露缺口，人补上会改方向的决定，再进入实现。
blindspot pass 可以翻成一句更直接的中文：
先别实现。结合当前代码和需求，找出最多 5 个我没有提到、但答案不同会改变实现方案的问题。说明你从哪里看出这个问题，以及它需要我决定，还是可以沿用项目现状。
盲点检查要交出来的东西不多，就一小撮需要确认的缺口。
“最多 5 个”是为了拦住通用清单。没有数量限制，回答很容易变成安全、性能、兼容性、可维护性全套术语。看着周全，没一项能让任务往前走。
“答案不同会改变方案”则把问题筛了一遍。按钮图标以后能换，账号能否合并会改数据模型；错误文案以后能改，回调是否需要支持多租户会改接口边界。前一类先放下，后一类现在问。
证据比提醒有用
原稿里那句”代码库证据”被检测意见指出像故意摆进去的具象化点缀。这个批评成立了一半：如果只写”请结合代码库”，确实像一句正确口号。它得落到能核对的输出上。
假设 Agent 说”需要确认 token 保存方式”，后面应当跟着项目事实：现有 Google 登录在 auth/callback.ts 把 refresh token 加密后写进 oauth_accounts；新 provider 是否沿用同一张表，需要人确认。这样的提醒才值得停下来处理。
如果它找不到任何调用点，只是依据常见做法猜风险，也可以说，但要把”仓库事实”和”外部经验”分开。人看到前者，会检查既有约定；看到后者，只需要判断这次是否相关。
这轮检查不追求把所有未知都消灭。五个问题里，有些可以直接沿用旧实现，有些能推迟到下一版。只要提前抓住一个会推翻数据结构、权限或用户流程的决定，两分钟就没有白花。
哪些活值得多问这一句
改一段文案、调一个明确参数，不必加流程。blindspot pass 适合三种情况：第一次碰某个模块，任务涉及权限或数据迁移，或者你只知道想要的结果，却不知道项目里有哪些限制。
判断起来更简单：如果 Agent 做到一半再问，前面写的代码会不会大面积作废？会，就先查缺口。
Thariq 那条提示的价值，不在 blindspot 这个英文词。换成任何说法都行。关键是把 Agent 的第一次搜索用来找问题，而不是急着交方案。
下一次进入陌生模块，可以先看它找出的五个问题。里面很可能有一个，本来要等代码写完才会露面。