Grill

---
name: grill
description: 面试官出题技能：基于最难核验或最可疑的经历，生成 3—6 道扎在候选人自己项目具体实现细节上的追问题，通过锚定私有细节、反事实推理、错误前提陷阱、现场量级估算四种机制让通用 AI 难以代答，并附参考答案要点、评分标准、典型错误回答与"答不上来不说明什么"。凡是要为一次面试准备问题就使用本技能——包括用户说"面试该问他什么""帮我准备几个问题""怎么问才能问出他是不是真做过""出几道能压住他的题"时。
---

# /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](references/question-design-patterns.md) 获取常见方向的深水区清单。

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

### 第三步：包装成题

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

## 输出格式

每道题按此结构：

```markdown
### 第 N 题

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

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

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

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

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

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

## 纪律

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