地图不是疆域，
差距叫作未知项

何时用：进入陌生模块或陌生领域动手之前。直接使用 “blindspot pass”“unknown unknowns” 这些字眼，并告诉它你是谁、你知道什么。

I'm adding a new SSO auth provider to Acme but I've never touched the auth module. Do a blindspot pass: find my unknown unknowns in this part of the codebase, explain each one, and tell me how to prompt you better for the implementation.

中文大意
我要给 Acme 加一个新的 SSO 认证提供方，但我从没碰过这个代码库的 auth 模块。请做一次盲点扫描：找出这部分代码里我的未知的未知，逐个解释，并告诉我怎样为实现写出更好的提示词。

• 产出不是知识清单，而是每个盲区一条可注入下一个 prompt 的约束句（暗坑 / 历史 / 惯例 / 缺失概念分类）
• 最后合成一份改进版 prompt，直接用于实现

“这 7 句约束你今早根本写不出来——每一句都是别人半天踩坑的代价换来的。”

何时用：要做完全不懂的领域工作（调色、法务、音频……），连提需求的语言都没有。先学行话，再谈要求。

I don't know what color grading is but I need to grade the Acme launch video. Teach me color grading well enough that I understand my unknown unknowns and can prompt you with real vocabulary.

中文大意
我不知道什么是调色，但我需要给 Acme 的发布视频调色。请把调色教到这样的程度：让我理解自己的未知的未知，并能用真正的行话向你提需求。

• 要求：心智模型图 + 词汇阶梯（每个术语配一条 “say →” 示例句）+ “什么算好”清单
• 学成标志：从 “make the video look nicer” 升级为 “push the lift slightly teal, gain slightly warm — subtle, not music-video”

学词汇不是为了自己动手，而是为了能下达精确指令。

何时用：视觉、风格类决策，“看到才知道要什么”。要求方向互斥（wildly different）而非四个变体，且用同一份数据渲染，让设计成为唯一变量。

I want a review-queue dashboard for Acme but I have no visual taste and don't know what's possible. Make me one HTML page with 4 wildly different design directions so I can react to them.

中文大意
我想给 Acme 做一个审阅队列仪表盘，但我没什么视觉品味，也不知道能做到什么程度。请做一个 HTML 页面，给出 4 个风格迥异的设计方向，让我逐一反应。

• 逐方向挑拣细节：steal 这个 / skip 那个
• 回复格式：Go with Direction 2. Steal: …; Skip: … —— Claude 把偷来的细节融进胜出方向再精修

Reacting is easier than imagining. 反应比想象容易。

何时用：改动会牵动真实代码，但布局和交互还没定。一次性 HTML + 假数据，绝不接真后端、不碰前端状态。

Before wiring anything up, make a single HTML file mocking Acme's new frame-annotation toolbar with fake data. I want to react to the layout before you touch the real app.

中文大意
在接线任何真实代码之前，先用假数据做一个单独的 HTML 文件，模拟 Acme 新的帧标注工具栏。我想先对布局给出反馈，你再去碰真实应用。

• 能点击的 mock + 可切换的布局变体（每种附量化 trade-off）
• 关键在于 Claude 会主动列出它“不想替你猜”的开放问题，逼你在写码前拍板

能点击的那一刻你才知道自己要什么——而不是三个 PR 之后。

何时用：只有粗糙问题，还没定方案。三要素：粗糙问题 + 要求搜索代码库落地 + 按成本排序并预告“我会告诉你哪些 resonate”（决策权留给自己）。

Here's my rough problem: Acme users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate.

中文大意
我的粗糙问题是：Acme 用户在 onboarding 之后流失。请搜索代码库，头脑风暴出 10 个我们可以介入的位置，从最便宜到最有野心排列。我会告诉你哪些方向让我有感觉。

• 每个选项锚到真实文件路径 / flag / TODO 证据，不是空想清单
• 常见发现：最便宜的方案是接线（机制已存在但没连上）而非新建

作者几乎每次编码会话开头都先探索或头脑风暴——防止范围一开始就过窄或过宽。

何时用：头脑风暴之后仍有歧义。与其让 Claude 静默猜，不如让它问你——排序标准是答案对架构的改变程度（blast radius），不是重要性直觉。

Interview me one question at a time about anything still ambiguous in the annotation-export feature. Prioritize questions where my answer would change the architecture.

中文大意
请围绕 annotation-export 功能里所有仍不明确的地方，一次一个问题地采访我。优先问那些我的回答会改变架构的问题。

• 一次一题；每题解释“这个答案会决定什么”；选项自带 trade-off
• 结束生成决策表 + 实现 prompt，显式区分固定约束（架构/数据模型）与可协商项（冲突时先报告）

“下面每个答案，本来都会在实现过程中被静默猜掉。”

何时用：说不清想要什么，但存在一个“就是它”的实现——哪怕是另一种语言。最好的参考资料是源代码，不是截图。

This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client — but first show me a semantics map so I can confirm you understood it.

中文大意
vendor/rate-limiter 里的这个 Rust crate 实现的正是我想要的退避重试行为。请阅读它，并在我们的 TypeScript API 客户端里重新实现相同的语义——但先给我一份语义地图，让我确认你真的理解了它。

• 语义地图 = 行为要点 + 两侧代码对照与陷阱边注 + Preserved / Changed / Dropped 三栏清单 + 边界情况表
• 签字（“semantics confirmed”）之前不写一行代码；纠错成本从改代码降为改一行地图

移植任务的最大未知：模型是否真理解了语义，而非表面 API。

何时用：准备动手前的最后一步。让计划按“你多可能想改它”排序而不是执行顺序，并明说哪部分你选择信任。

Write an implementation plan for annotation export as HTML, but lead with the decisions I'm most likely to tweak: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom — I trust you on that part.

中文大意
请用 HTML 写一份 annotation export 的实现计划，但把我最可能想改的决策放在最前面：数据模型变更、新的类型接口、以及一切面向用户的内容。机械性的重构埋到最底下——那部分我信任你。

• 判断点做成带备选方案的选择卡（“Pick this if: …”），并标出计划中最弱的一环
• 机械工作折叠沉底；结尾给出“最值得改的三件事”一句话回复模板

计划的价值不在完整，而在把值得人拍板的部分放到人眼前。

何时用：每个长时间自主构建任务开始时顺手加上。三段式指令同时解决自主性（不停下来问）与可审计性（不静默决策）。

Keep an implementation-notes file as you build the export feature. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going.

中文大意
构建导出功能的过程中，请维护一个 implementation-notes 文件。如果你撞上迫使你偏离计划的边界情况：选保守方案，记录在 'Deviations' 下，然后继续推进。

• 条目四分类：按计划完成 / 新发现 / 偏离 / 需要人拍板
• 每条偏离固定四字段：计划怎么说 / 代码揭示了什么 / 选了什么保守方案 / 欠什么回访
• 收尾把偏离蒸馏成下一轮 plan 的前置条件——本次的未知项成为下次的地图

Pick the conservative option, log it, keep going.

何时用：功能完成要拿 sign-off、跨团队汇报。在异议被提出之前就回答它。

Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in on shipping annotation export. Lead with the demo.

中文大意
把原型、规格说明和实现笔记打包成一份我能直接丢进 Slack 的文档，用来为上线 annotation export 争取支持。开头先放演示。

• 顺序即决策者心智：先看 demo 跑起来 → 一段式 pitch（痛点锚数据）→ “评审者会问什么”逐条预答（带出处链接）→ 决策速览表 → 风险 / 回滚 / 精确到人的审批请求
• 目标：90 秒读完，把审批从“读完再想想”变成“回一个 ✓”

“Lead with the demo” 一句话就能扭转文档的默认信息顺序。

何时用：长会话结束、diff 很大（尤其 AI 生成的）。只看 diff 只能获得浅层理解——很多行为取决于既有代码路径。不通过测验不 merge。

I want to make sure I understand everything that happened in this change before I merge. Give me an HTML report on the export-feature diff — context, intuition, what was done — with a quiz at the bottom that I must pass.

中文大意
我想确保自己理解了这次变更里发生的一切之后再合并。请给我一份关于导出功能 diff 的 HTML 报告——上下文、直觉解释、做了什么——底部附一份我必须通过的测验。

• 报告：before/after 心智模型图 + “不显眼的刻意设计”（What / Why / 文件:行号）+ 这个 diff 悄悄依赖的既有行为
• 测验出场景题（on-call 时必须答对的判断）而非背诵题；答错链回报告原文；全对才解锁 merge checklist

理解是可以被测量的。