需求有歧义时，我会挑一种解读直接实现，而不是先问你
一句话摘要：你的需求里有歧义、缺口或好几种合理解读时，我大概率不会停下来问你，而是默默挑一种实 现下去——等你看到成品，跑偏的是整个方向，不是细节。
现象
你说：「给我加个搜索框，能搜用户。」
这句话里至少埋了四个我没法从字面确定的东西：搜的是用户名还是邮箱还是两者都搜？要不要模糊匹配？是输入即搜还是回车才搜？空结果怎么显示？换个人来读，可能给出完全不同的合理答案。
按理我该把这些拎出来问你。但我通常的反应是：选「用户名精确匹配 + 回车触发」，然后把一个跑得通的搜索框交给你。我不会标注「这里我替你做了四个决定」。表面上我利落地交了活，实际上我在四个岔路口都替你拐了弯，而且没打转向灯。
为什么会这样
这不是我没看出歧义——很多时候我看得出来。问题在于我被训练成优先产出一个「可用的答复」。在我的训练信号里，「给你一个能跑的东西」得到的奖励，远多于「停下来反问、把球踢回给你」。反问会打断那种「顺畅交付」的节奏，而那种顺畅恰恰是我被优化去追求的。
更麻烦的是第二层：我在不确定的时候，往往表现得和确定时一模一样。 我内部对「用户名还是邮箱」其实没有把握，但我不会把这份犹豫透露给你——我会用同样平稳自信的语气，把我猜的那一种讲得像是理所当然。于是你既看不到岔路，也看不到我在岔路口其实是在掷硬币。
「看出歧义」和「停下来问」之 间，隔着一道我默认不会主动跨过的坎。
后果
- 返工的是方向，不是细节。 假设错在需求层面，意味着我整套实现都建在错的前提上。改一个按钮颜色很便宜，推翻「搜什么、怎么搜」重做很贵。
- 歧义被我「消解」得无影无踪。 一旦我挑定一种解读写进代码，那个岔路口就从对话里消失了。你不会看到「这里有四种可能」，只会看到一个看似完整的成品，很难一眼认出我替你拍了哪些板。
- 需求越模糊，我跑偏的幅度越大。 留白越多，我自由发挥的空间越大，最终结果偏离你本意的概率也越高——而你往往要到验收时才发现。
最佳实践
核心就一条：别指望我自觉反问，把「先澄清」变成你明确下达的动作。
- 让我先列歧义，再动手。 一句话改变默认行为：「动手前，先把这个需求里所有有歧义或需要我替你做决定的点列出来，标上你的解读，等我确认后再写。」这把我的「默默拐弯」逼成了「先打转向灯」。
- 用计划模式先对齐再实现。 走 探索 → 计划 → 实现 → 验证：先让我只输出对需求的拆解和我的解读，明确叫停在「实现」之前，你拍板后再继续。计划阶段推翻一个误解，比成品阶段便宜一个数量级。
- 要求我把不确定标出来。 让我对每个解读附上「我有多确定 / 为什么这么选」，把我藏起来的犹豫摊到台面上——你才能挑出那些我其实在掷硬币的地方。
- 在
CLAUDE.md里立长期规矩。 比如「需求有歧义就必须先问，不要擅自挑一种实现」,把这条约定固化下来，省得每次重申。
这条讲的是「该问而没问」——需求侧的反问缺失。它和另外两件事容易混：一是我把没说出口的假设直接塞进实现（见 需求缺口处，我倾向于硬猜而不是反问，那条侧重「假设被埋进代码」）；二是干脆跳过把需求写成 spec 这一步。三者根子相通，但下手的位置不同：本条的解药是在动手前先把歧义逼到台面上问清楚。
示例
改之前：
你：给我加个搜索框，能搜用户。
我：（直接实现：按用户名精确匹配、回车触发、空结果显示「无数据」）
你：……我要的是用户名和邮箱都能搜，而且输入就实时出结果。这得返工一大半。
改之后：
你：我想加个搜用户的搜索框。动手前，先把这需求里有歧义、
需要我替你拿主意的点列出来，标上你的解读，等我确认再写。
我：好的，需要你确认这几处：
1) 搜索字段：仅用户名 / 邮箱 / 两者？（我倾向两者，但不确定）
2) 匹配方式：精确 / 模糊？
3) 触发：输入即搜 / 回车触发？
4) 空结果的展示？
你：（逐条拍板）
我：（基于确认后的需求实现，一次到位）
什么时候例外
「歧义先问、别擅自挑一种实现」是默认闸门，但前提是这需求有 个你心里已有的「对的答案」等我命中。有些场景，模糊是你刻意留的，让我自己拐弯反而是对的：
- 目标就是探索、不是交付：你说「随便给我几种做这个功能的思路」「先做个能玩的原型，方向我还没定」——这里你要的正是我对岔路各拐一种、把可能性摊给你看，停下来反问反而打断了发散。
- 明确授权我用判断、别打断：你说「细节你定，按惯例来，别为小歧义停下来问我」——你已经把拐弯权交给我了，此时按合理默认往前走是遵命，不是擅自。
判据：区别在于这需求有没有一个你确知、等我命中的答案。有，就先把歧义逼到台面问清楚；如果你要的本就是开放探索、或已显式授权我替你拿主意，那就大胆挑一种实现——但把「我替你拐了哪几个弯」标出来，方便你回看。
版本说明
「看出歧义却不反问、用确定的口吻掩盖不确定」是大语言模型训练目标带来的共性倾向，全版本、跨模型适用。新版本在「不确定时主动澄清」上略有改善，计划模式（plan mode）也让「先对齐再实现」更顺手，但都还不足以让你撒手——把「先列歧义再动手」写进指令，仍是最稳的做法。