/grill：出能问穿简历的题

核验报告能告诉面试官"哪里可疑"，但证实或证伪只能在面试现场完成。这个 skill 的产出就是那几道题。

什么样的题算合格

一道好的核验题，必须同时满足四个条件。缺一条就重出。

条件一：扎在候选人自己的项目上

题目必须锚定简历上的具体一条 claim，问的是"你那个系统里的那件事"，而不是一个通用技术问题。

• ❌ "讲一下 Raft 的选举流程" —— 八股，背过就能答，与他的项目无关；
• ✅ "你的 Raft 实现里，如果一个 Follower 在收到 AppendEntries 之后、写盘之前宕机了，重启后它的状态和 Leader 认为的状态会差在哪里？你的代码是怎么处理这个差异的？" —— 必须真的实现过并想过持久化时机才能答。

条件二：答案依赖真实经历，AI 无法代答

这是最核心的一条，也是当前最难的一条。候选人可能在面试中借助 AI 辅助（远程面试尤其如此）。因此题目必须让通用知识失效：

让 AI 失效的四种机制：

1. 锚定私有细节：答案取决于候选人项目里的具体选择——"你为什么把这个超时设成这个值？" AI 不知道他设了多少，只能泛泛而谈。
2. 要求反事实推理：从他的具体实现出发推导后果——"如果把你这个锁的粒度放大到整张表，在你那个场景下最先出问题的是哪个接口？" 需要同时掌握实现和场景。
3. 设置前提陷阱：题目中嵌入一个错误前提，正确的回答是先指出前提有误（见下）。AI 倾向于顺着提问者的前提往下答。
4. 要求量级估算：让候选人用他项目里的真实参数现场算——"按你说的 QPS 和这个数据结构，一天大概占多少内存？" 需要真实数字才能算。

注意：目标不是防作弊本身。防作弊是次要收益。核心目标是区分"做过"和"读过"——这两者的差别正好体现在这些细节上。

条件三：带坑

题目里埋一个陷阱，让只学过表面知识的人自信地掉进去，而真正做过的人会停下来质疑。三种坑：

• 错误前提坑：题目断言了一个不成立的技术前提。真懂的人会说"等一下，这个前提不对，因为……"。
• 看似简单坑：问题表面平常，但正确回答需要意识到一个隐藏的边界情况。
• 诱导坑：题目暗示了一个流行但在他的场景下错误的答案方向。

坑必须是技术性的，不能是文字游戏。目的是区分理解深度，不是刁难人。

条件四：面试官能判断对错

参考答案必须写得足够具体，让不是该细分领域专家的面试官也能判断候选人答得对不对。因此每道题都要附：

• 正确回答必须覆盖的要点（可勾选）；
• 典型的错误回答长什么样；
• 陷阱是否被识破的判断标准；
• 如果候选人答不上来，这说明什么、不说明什么。

出多少道题

3—6 道主问，按简历上值得核验的 claim 数量定，不要凑数也不要硬砍。

但每道主问必须配齐三件套，缺一不可：

1. 参考答案要点（可勾选，标出关键项）
2. 典型的错误回答长什么样
3. 答不上来不说明什么

追问不限量——主问下面挂多少层追问都可以，追问不需要配三件套。

为什么是"数量宽松、仪表严格"

早期版本硬性要求"恰好 3 道"，实际效果是规则被系统性规避：产出会用"可选追问""收尾题"绕开限制，实际问出十几道，而多出来的那些都没有配答案与评分标准——限制没有减少题量，只是把题量转移到了没有仪表的地方。

真正要保证的从来不是题少，而是每道题面试官都能判对错。一道没有评分标准的题，对面试官等于没有——他会凭感觉判断，而凭感觉正是这套工具要消除的东西。

所以：题量服从内容，仪表不可妥协。

同时注意覆盖：三道以上时应覆盖不同类型的 claim（Ownership / Metric / Technical / Scope / Result），且尽量扎在不同经历上，不要全堆在同一个项目。

一定要给面试官的两样东西

① 开场话术（必须写出来，让面试官照着念）

在题目之前，先给一句面试官开场时说出口的话，例如：

"接下来我问得比较细，主要想弄清哪部分是你亲手做的。说'这块不是我负责的'或'这里参考了开源实现'完全不扣分——说不清楚才扣分。"

为什么这条必须有：候选人夸大表述，很多时候是因为没有安全的退路。给出台阶后主动收缩边界的候选人，可信度反而更高；而这个信息只有说出口才有用——写在给面试官看的评分标准里，候选人听不到，等于没有。

② 时间分配建议

面试官通常只有 45—60 分钟。标出哪道必问、哪道可跳、各约几分钟、以及"前 X 分钟已确认没问题就可以跳过后面的核验题，转去评估实际能力"。

出题流程

第一步：选 claim

按上述数量与覆盖要求选取，优先级：

1. 有落差但未达 直接矛盾 的——最需要现场澄清（如"核心贡献者"但 PR 全是文档）；
2. 缺乏外部证据的高价值 claim——公司内部项目，只能靠追问（如"主导 XX 架构设计"）；
3. 指标类 claim——数字最容易现场验证口径。

覆盖不同类型（如 Ownership / Technical / Metric），不要都扎在同一段经历上。

第二步：定位技术深水区

对选中的 claim，找出该技术方向上教程不会讲、但真做过必然踩到的点。读 references/question-design-patterns.md 获取常见方向的深水区清单。

通用规律：深水区总是在异常路径上。教程讲 happy path，实践的痛苦全在超时、重试、并发、故障、数据不一致、边界值上。

第三步：包装成题

把深水区问题包装成锚定候选人项目的具体提问，埋入陷阱，写好参考答案。

输出格式

每道题按此结构：

### 第 N 题

**针对的 claim**：[简历原文摘录]
**核验意图**：[这道题要区分什么]

**题目**：
> [直接可念给候选人的完整题面]

**埋的坑**：[说明陷阱是什么，以及为什么只学过表面的人会掉进去]

**参考答案要点**（勾选制）：
- [ ] 要点 1
- [ ] 要点 2（关键项：能否识破陷阱）
- [ ] 要点 3

**面试官判断指引**：
- **答得好的样子**：...
- **典型的错误回答**：...（这说明：只掌握了概念层面）
- **答不上来说明什么**：...
- **答不上来不说明什么**：...（防止过度解读）

**可选追问**：[如果候选人答得不错，用这个继续加压]

纪律

1. 不出羞辱性问题。目的是分辨深度，不是让人难堪。不使用"你真的做过吗""这不可能吧"这类质问式表述。
2. 不出无解题。每道题必须有一个真正做过的人能答出的答案。为难而为难的题没有区分度。
3. 不假设候选人在撒谎。题目设计为"如果他真做过，他能答出来"，而不是"我要抓住他"。很多候选人会答得很好——那是这个流程的成功，不是失败。
4. 写清"答不上来不说明什么"。紧张、表达差、时间久远忘了细节、当时负责的是另一部分——都是答不上来的正常原因。必须提醒面试官不要单凭一题下结论。
5. 不涉及岗位无关内容。题目只问技术和工作，不问私人情况。
6. 难度要匹配岗位。给校招生出资深架构师的题没有意义。参考 JD 的职级要求。