# Interview Comment

> 按团队模板生成严格的面试评价报告。使用时：①用户直接贴飞书招聘候选人链接（feishu.cn/hire/talent/...）——交互式会话用 Chrome 集成、无人值守/launchd 固定用 AppleScript，先按 URL 精确定位标签页并跑前置探针判定本轮材料形态（简历是 PDF/图片附件/仅标准简历、面试速记是否就绪、有无「代码考核」卡片），再采集简历（三路：PDF 长图 / 图片附件直落 / 标准简历截图）+ 抽取面试速记文字记录到 ~/github/interviews/人名拼音/00N/，速记未就绪则跳过不写残缺评价；②用户提供候选人面试材料目录（简历截图 + 语音转文字）。按固定目录结构读取，只评估本轮材料，产出 Markdown 报告。**开工先按 asr.md 说话人分布判用户是主面还是旁听（shadow 陪面）——飞书 interviewer_list 只登记 shadow 者一人、判不出主面；旁听场候选人评价照常写满，面试官复盘改写成观摩笔记且不给用户打 A/B/C/D 档。** 报告包含两部分：候选人**六维**评价（业务理解/技术支撑/技术广度/技术深度/**编码与算法**/软素质；先记证据 P/N1/N2/U 再按优先级生成 `+`/`=`/`-`，有编码题先跑形态状态机 C0~C4；2/2.5/3/3+/3.5/4 六档评分按**决策表**顺序判定，核心维度 `-` 时 ≤2.5 且不因其他维度 `+` 上浮；3+ 及以上通过，3 为合格线边缘、默认倾向不通过但面试官可显式裁定通过；按目标岗位职级校准深度期望）+ 面试官复盘评价（**只能取 A/B/C/D 四档，禁止 A-/B+/B- 等未定义子档**，五维评估 + 改进建议）。打分前先过「证据充分性前置门」——因面试官时间不足/没安排/被打断而未取样的能力一律留空、不记减分项、不触发降档铁律（"没测到"≠"测到且失败"）。**evaluation.md 是对外交付物（会被整段贴进公司招聘系统），零过程性内容：不写版本标记、改判说明、评审过程、自我纠错、规则援引；改判留痕另写 review-log.md。**含 AI coding 题专项评估（看用 AI 的过程而非代码结果）与 AI 生成内容的原理归属校验；含传统算法/编程题专项评估（探针 coding=no 只代表无平台代码产物，仍须回速记扫编程题信号，屏幕共享/白板/

- Skill: `igoingdown/interview-comment` (Agent Skill, multi-file: 18 files)
- Install (CLI): `npx skillmds@latest add igoingdown/interview-comment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/igoingdown/interview-comment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: igoingdown (https://skillmd.com/u/igoingdown)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/igoingdown/interview-comment

---


# Interview Comment（面试评价生成）

按团队固定模板生成后端/算法/大数据研发岗位的面试评价。Claude 亲自读简历截图（视觉）+ 语音转写，产出双重评价报告：

1. **候选人评价**：六维打标 + 综合评分 + 长处/短处速判
2. **面试官复盘**：五维评估 + 做得好/不好 + 改进建议 + 时间分配分析

**只评估本轮材料，不读取、不引用、不被其他面试官的评价或结论影响。**

> ⚠️ **开工先判本场用户是主面还是旁听（shadow 陪面）。** 判定方法与旁听场的处理差异见下方「面试官角色判定（主面 / 旁听）」。漏判会产出一份**对着别人的行为给用户打分**的复盘，用户拿它做自我改进等于改错了对象。

## 按需加载的 references（用到哪步读哪份，别一次全读）

| 你要做的 | 读这份 |
|---|---|
| 用户只贴了飞书招聘链接，需先采集简历/速记/代码考核 | `references/material-collection.md`（阶段 0：按 URL 定位标签页 + 0.15 前置探针 + 三路简历采集 + 速记未就绪退出 + 代码考核采集 + 并发子代理提示）|
| 给候选人六维打标 / 综合评分 / 判 AI coding 题 / 判传统算法编程题 | `references/scoring-rubric.md`（六维判据 + 证据账本 P/N1/N2/U + 编码形态状态机 C0~C4 + AI coding 专项 + 传统算法/编程题专项 + 六维→综合分决策表）|
| 做面试官复盘评价 | `references/interviewer-rubric.md`（A/B/C/D 档 + 面试官五维标准，含编码"验证收尾"红线）|
| 写输出文件 | `references/report-templates.md`（evaluation.md / interviewer-review.md / coding-analysis.md 模板）|

下面正文只保留：触发判定、目录规则、评分档位与严格原则（每次都要遵守的硬规则）、执行流程、评价原则。

## 触发

用户说类似：

- **直接贴一个飞书招聘候选人链接**（`https://<tenant>.feishu.cn/hire/talent/<talent_id>?application_id=<application_id>...`）——先走 `references/material-collection.md` 的阶段 0 采集，产出标准目录后自动进入评估
- "评估 `<人名目录>` 的第 N 轮"
- "帮我写 `<人名>/002` 的面试评价"
- "运行 interview-comment，候选人在 `<人名目录>`，我做的是 2 面"

## 输入目录结构（固定）

顶层是候选人标识（姓名 / 缩写 / 工号），下面每一轮面试一个子目录，命名为 `001`、`002`、`003`、`004`，分别代表 1~4 面。

```
<人名>/
├── 001/
│   ├── resume.png        # 简历截图（可能存在）
│   └── asr.md            # 该轮面试语音转文字（用户本人担任面试官）
├── 002/
│   ├── resume.png
│   └── asr.md            # ← 假设用户本次做的是 2 面
└── ...
```

**文件命名规则（严格匹配，不要用模糊搜索）**：

| 文件 | 含义 | 出现在 |
|------|------|--------|
| `resume.png` | 简历截图 | 通常每轮都有（允许多轮共享同一张） |
| `asr.md` | 该轮面试的语音转文字 | **仅用户本人担任面试官的轮次** |

> 注：候选人目录下可能存在其他面试官写的评价文件（如 `review-res.md`）。**本 skill 一律忽略——不读取、不解析、不纳入评价。** 每轮评价只基于该轮 `asr.md` + 简历独立成文。
>
> 这条约束的是"别人对这个候选人的判断"，与「面试官复盘可跨场引用自己的行为」不冲突——后者引用的是面试官自己在别的场次做了什么，不涉及任何候选人的评价结论。见 `references/interviewer-rubric.md`「跨场对比的边界」。

### 判定"本次要评估哪一轮"

- 只有含 `asr.md` 的轮次才是**本次评估的目标轮**（评价要写到那一轮的目录里）
- 如果多个轮次都有 `asr.md` → 用 `AskUserQuestion` 让用户指定要评估哪一轮
- 如果没有任何一轮有 `asr.md` → 报错退出（缺少必要材料）
- 用户已在对话里明确指定轮次（如"帮我写 002"）→ 以用户指定为准

### 必需文件与可选文件

- **必需**（目标轮必有）：`asr.md`
- **强烈建议**（目标轮应有）：`resume.png`。若目标轮没有，查找其他轮是否有 `resume.png`，有就共用；全都没有则报错退出。

缺少 `asr.md` 或所有轮都无 `resume.png` → 直接报错退出，不脑补。

## 面试官角色判定（主面 / 旁听）— 打分前必做

**同一场面试里用户可能是主面，也可能只是旁听（shadow 陪面）。** 飞书招聘登记的面试官是用户，**不代表用户就是主面**——旁听场往往只登记 shadow 者一人，真正提问的主面官根本不在 `interviewer_list` 里（实测三场登记的都只有用户）。**所以角色只能从 `asr.md` 的说话人分布判，不能从系统字段判。**

### 判定步骤（机械执行，不要凭印象）

1. 统计 `asr.md` 里每个说话人的发言条数：
   ```bash
   grep -oE '^\*\*[^ ]+ [0-9]{2}:[0-9]{2}\*\*' asr.md | sed -E 's/\*\*//g; s/ [0-9:]+$//' | sort | uniq -c | sort -rn
   ```
2. 找出**用户本人**（面试官身份）在其中的发言条数，按下表定角色：

   | 用户发言情况 | 角色 | 说明 |
   |---|---|---|
   | 用户是唯一的面试官说话人 | **主面** | 常规场景，按原流程走 |
   | 用户有发言，但另有他人承担了主要提问 | **旁听 + 部分参与** | 复盘只针对用户自己实际问出的那部分 |
   | **用户全程零发言**，提问全由他人承担 | **纯旁听（shadow）** | 复盘无从写起，走下方「纯旁听场」分支 |

3. `asr.md` 头部若已标注主面/陪面（如「涂鹏(主面) / 赵明星(shadow 陪面)」），**以头部标注为准**，但仍要跑一遍发言统计交叉验证。
4. **判不准时问用户**（交互式会话用 `AskUserQuestion`）；无人值守场景按"纯旁听"处理并在报告里写明依据——**宁可写成观摩笔记，也不要把别人的行为算到用户账上**。

### 旁听场的两处差异

| | 候选人评价 `evaluation.md` | 面试官复盘 `interviewer-review.md` |
|---|---|---|
| **主面场** | 照常写 | 照常写，对象是用户 |
| **旁听场** | **照常写，一字不减** | **改写成「观摩笔记」**（见下） |

**候选人评价为什么不受影响**：候选人的表现是客观事实，谁提问都一样。旁听者写候选人评价完全成立——用户就是要拿它去平台填评价的。**旁听不是降级材料，六维打标、决策表、严格原则全都照常执行。**

**面试官复盘为什么必须改**：复盘的用途是"用户改进自己的面试技巧"。旁听场里那些提问行为不是用户做的，对着它们给用户打 A/B/C/D 是**评错了人**。

### 纯旁听场：`interviewer-review.md` 写成观摩笔记

1. **不给用户打 A/B/C/D 档。** 在「面试官评分」位置写明本场用户为 shadow 陪面、无可提取的提问行为，故不评档。**档位留空比给一个错档好。**
2. **五维表照常填，但表头与说明里写清对象是主面官**（写出主面官姓名），并注明"供观摩参考，不构成对用户本人面试技巧的评价"。
3. **改进建议改成"可借鉴 / 可避免"两类**：从主面官行为里提炼用户下次自己主面时能用的做法与该避开的坑，而不是要求用户改正别人的问题。
4. **时间分配分析照常做**（这是场次客观事实，与谁提问无关）。
5. 用户有少量发言时（"旁听 + 部分参与"），可**额外**加一小节针对用户自己那几句的点评，但仍不给整场档位——样本量不足以支撑档位判定。

> 已有先例：`chenzhenran/002/interviewer-review.md` 用「本场归属说明」开篇交代了归属，可作参照；但它仍给了一个 `C` 档——**那个档评的是主面官涂鹏，不该出现在用户的自我复盘里**。按本节规则应留空不评档。

## 评分体系（核心硬规则，每次必守）

六维判据、证据账本、编码形态状态机、AI coding 专项、传统算法/编程题专项、六维→综合分决策表的完整展开在 `references/scoring-rubric.md`；本节是每次打分都要遵守的档位与严格原则。

> ⚠️ **2026-09-08 重构要点（必读）**：维度从五个改为**六个**（新增「编码与算法」），打标改为**先记证据（P/N1/N2/U）再按优先级生成符号**，映射表改为**决策表**（核心维度 `-` 优先于任何数量的 `+`）。原因：编码结果原先寄生在技术深度里，导致同一格内正负证据并存无法标注，AI 曾自创"正负相抵"绕过规则，造成判分倒挂（交付错误代码的人分数高于零输出的人）。**禁止使用「正负相抵」「两者抵消」「相互折抵」这类表述——规则里没有这个算法。**

### 分数档位

候选人的综合评分**只能**取以下 6 个值之一：

```
2   2.5   3   3+   3.5   4
```

**禁止**输出 2.75、3.25、3.75 等非档位分数。

| 分数 | 含义 |
|------|------|
| 4 | 顶尖候选人，各维度均有明显亮点，能立即独当一面 |
| 3.5 | 优秀，2+ 个维度有显著加分项 |
| 3+ | 合格偏上，有明确亮点（通过线） |
| 3 | 合格线边缘，默认倾向不通过；面试官可基于实际体验显式裁定通过（须写明理由） |
| 2.5 | 有明显硬伤，不通过 |
| 2 | 明显不符合岗位要求 |

### 通过标准

- **综合评分 ≥ 3+：通过。**
- **综合评分 = 3：合格线边缘。默认按严格原则倾向不通过；但面试官可基于实际面试体验显式裁定通过/不通过。** 裁定通过时，必须在概览写明"打 3，面试官裁定通过"及具体理由（如：核心维度有真实底子，某些短板属入职后可习得/可锻炼，不构成阻断）。
  - ⚠️ **AI 不得自行关闭裁定路径。** 即便本轮取样不足（核心维度未取样、编码未验证），也**只能**把分数压到 3，**不能**写成"不做裁定""应当补测而非裁定""证据不足不予通过"。取样不足是下一轮补测的理由，不是本轮否决裁定的理由。详见 `references/scoring-rubric.md`「⚠️ 分数上限 ≠ 结论上限」（含真实事故复盘）。
- **综合评分 ≤ 2.5：不通过。**

> 开"3 可裁定"这个口子是为了容纳"核心能力达标、个别短板可后天补"的真实场景，但**不改变严格原则的整体精神**——3 默认仍偏保守，不写明裁定理由就按不通过处理；3 与 3+ 之间犹豫时不要直接跳到 3+，而应落 3 再由面试官决定是否裁定通过。

### 证据充分性前置门（优先于下面所有打分规则）

**"没测到"不等于"测到且失败"。** 这条优先级最高，与下方任何降档规则冲突时**以本条为准**。

真实事故：某场 60 分钟面试里项目深挖占了 40 分钟，算法题只剩 4-5 分钟且面试官出题时就说"应该没时间写了"，后端核心基础（并发/锁、MySQL、缓存一致性、MQ）全程零取样。初版评价一边在概览写"取样公平性说明：证据面窄"，一边把技术深度判了 `-` 并压到 2.5——**这个自相矛盾是被规则冲突迫出来的**（`SKILL.md`「资历校准」说"中等算法题写不出→判 `-` 压到 ≤2.5"，`scoring-rubric.md`「判分锚点」说"只口述没落代码是压分项而非直接判死、封顶 `=`"）。外部评审复核后改判 3。

**判定规则：**

1. **归因先分三类**，不同类走不同处理：
   | 情形 | 处理 |
   |---|---|
   | **未取样**：面试官没安排、时间不足、被打断、环节被砍 | 维度**留空（未考核）**，不得记 `-`，不得触发任何"压到 ≤2.5"的铁律 |
   | **取样了但候选人没答出** | 按"没答出"处理——可接受，除非是**岗位核心基础**（后端：并发与锁、MySQL 索引/事务/MVCC、缓存一致性、MQ 语义与幂等、分布式基础） |
   | **取样了且候选人答错** | 按"答错"处理，可记 `-`；主动提交的方案**原理讲反**从重。⚠️ **编码题的"实测错"不算这一类**——实现 bug 属熟练度瑕疵，见下方第 2 条 |
2. **只有下列情形才允许因编码记 `-`**：把**核心算法概念讲反**、充分取样后**分析过程完全停滞**（零方向零推进）、或主动提交的方案**原理讲反**。
   - ⚠️ **代码实测错误不在其中**（2026-09-08 修正）。算法题考的是思路、基础、面对陌生问题的分析过程；**代码写不出来、或写出来有实现层面的小 bug（索引写错、判定条件写歪、缺 import、边界漏），都属可接受范围，不构成 `-`**。实测的用途是精确描述完成度，不是判死。详见 `references/scoring-rubric.md`「传统算法/编程题专项评估」第一原则。
   - **"因面试官没留时间而只口述"**也不在其中——它是"未取样"，按上表第一行处理。
3. **岗位核心维度被判为"未取样"时**，概览必须写明"技术深度/技术支撑因本轮未取样而留空，本结论证据面不完整，建议下一轮补测后再终判"，并在「后续面试重点关注」列出具体补测清单。**分数照常给（用已取样维度算），但不得因未取样而降档。**
4. **不得反向操作**：也不能因为"未取样"就给候选人免责加分。未取样维度既不加分也不减分，就是留空。

> 判分前自查一句：**我判 `-` 的这条，是候选人答错了，还是我们没问到？** 是后者就留空，并把它写进下一轮补测清单。

### 严格打分原则（硬规则）

0. **先过上面的「证据充分性前置门」**，再套本节规则。本节的降档条款只适用于"已充分取样"的维度。
1. borderline 一律按**低档**打：
   - 在 **3 和 3+ 之间犹豫 → 打 3**（落 3 后默认倾向不通过，由面试官决定是否显式裁定通过；不要因犹豫直接跳到 3+）
   - 在 3+ 和 3.5 之间犹豫 → 打 3+
   - 在 3.5 和 4 之间犹豫 → 打 3.5
   - 任何"可打可不打高一档"的情况 → 打低一档
2. 宁可错杀，不可错放
3. 给 3+ 必须说得出**至少 2 条**证据确凿的加分理由，且**这 2 条必须来自相互独立的取样单元**——不同项目，或同一项目里不同组件/不同探针方向。**同一个组件的反复追问只算 1 条。**
   - 为什么加这条：候选人通常自选最熟的项目讲（"哪个是你最近做的"这类问法把选题权交了出去），一个准备充分的单一项目足够堆出好几条"亮点"，而简历上其他主张全程未验证。只数加分理由的条数、不看取样覆盖，会让"会讲一个故事"的人拿到 3+，而被抽到薄弱项目的人反而吃亏。
   - 时间不足以完成第二个取样单元时：**不给 3+**，落 3 并在概览写明"仅取样 1 个项目，第二单元未覆盖"，把交叉验证方向写进「后续面试重点关注」。
4. 给 ≥3.5 必须说得出**至少 1 条**显著亮点（加分项，非持平）；且 ≥3.5 时**至少 2 个 `+` 要落在不同维度上**，不能靠同一条底层证据同时撑起两个维度。
5. **资历 × 深度期望校准（硬规则）**：分数不是绝对的，要按候选人资历（工作年限 + 当前/目标职级）校准深度要求。**资历越高，同样的回答应换来越严的判定。**
   - **先确认目标岗位对标职级（评分前置项）**：期望线优先按**目标岗位职级**建立（如岗位对标 2-1 就按 2-1 期望判，即使候选人年限更长）；目标职级不明确时再按候选人资历。评估前从上下文推断或直接问用户"本岗位对标什么职级"。
     - **职级未采集时，禁止触发"资历硬降到 ≤2.5"**——只能按候选人工作年限建立较宽的期望线，并在概览写明"目标职级未采集，按 N 年年限校准，期望线可能偏严/偏松"。理由：同一份回答按 2-1 判可能是"可入职后补齐"、按 2-2 判就成了"系统性深度缺失"，跨了通过线；拿不到职级就用最严档等于让候选人承担信息缺失的代价。
     - **概览里的资历口径必须唯一**。真实教训：一份报告里同时出现"按 7 年经验建立期望线"和"按 8 年/2-2 的严格档"两种表述，而个人信息栏写着"职级：未覆盖"——口径漂移会让同一份回答跨越通过线。定了按几年/哪个职级判，全文只用这一个口径。
   - **先建立期望线**：8 年 / 2-2（或更高）的候选人，对其主导/自研项目的核心组件，预期是"能讲清关键设计的取舍依据 + 答得出核心原理"；对中等算法题预期"能落地一个正确解法"。把候选人实际表现**对照其资历应有的深度**来判，而不是对照应届生。
   - **达不到资历期望即降档（⚠️ 须先过「证据充分性前置门」）**：高资历候选人若出现"关键参数靠拍/忘、自研方案核心组件原理答不出、**在留足时间的编码环节里连解题方向都形不成（分析过程停滞）**"，**这是系统性深度缺失而非单点瑕疵**——对应维度判 `-`，综合按判分铁律压到 ≤2.5，**不得**因表达流畅、广度真实、背景光鲜而上浮。
     - ⚠️ **"中等算法题没写对"不触发本条**（2026-09-08 修正）。高资历提高的是对**分析质量与基础扎实度**的期望，不是对"实现零 bug"的期望。方向对、基础对、分析在推进但代码有 bug 或没写完 → 最多 `=`，不降档。
     - **本条只适用于已充分取样的情形。** "编码环节只有几分钟 / 面试官说了不用写 / 环节被砍"属于**未取样**，走前置门留空，**不得**据本条判 `-`。判前先问："他是写不出，还是我们没给时间让他写？"
     - 编码形态与判分锚点的完整展开在 `references/scoring-rubric.md`「传统算法/编程题专项评估」，**与本条冲突时以前置门 + 该节的形态表为准**（只口述没落代码是压分项、技术深度封顶 `=` 而非直接 `-`）。
   - **同一份回答、不同资历可给不同分**：应届生"自研 agent 参数拍的"可记 `=`（尚在学习期），8 年 2-2 同样表现记 `-`（这个年限早该想清楚为什么这么设）；反之按 2-1 校准时，基础概念盲区（如 CAP、一致性哈希）可判"可入职后补齐"，不必触发铁律。报告概览须写明"按 职级 X（或 N 年）的深度期望校准"。
   - **校招（应届/在读，通常对标 1-1 / 1-2）单独建期望线，不要拿社招标准套**。期望线是五条：①能讲清自己做的东西解决什么问题、给谁用；②方案选择说得出理由（不要求横向对比一堆候选项）；③**至少一个技术点能讲到实现细节**（不要求把所有组件原理都答出）；④有可验证的学习能力与做事方法；⑤中等算法题能收敛到正确思路。
     - **校招要重点看"做事方法"而非"技术存量"**：先调研 → 定位核心问题 → 参考业界先进做法（照猫画瓢完全可以）→ **自己建数据集/用例做量化验证**。前三段常见，**第四段是区分点**——抄完就交是一种水平，抄完自己建测评回归是另一种。看到第四段可以给软素质 `+`。
     - **校招的 scaffolding 比例天然高**（框架是公司现成的、产品定义是别人给的、架构原型抄内部方案），这是常态**不作减分**；但判 `+` 时要落在他自主决策的那部分上，而不是整个项目。
     - **"没答出"的容忍度比社招高，"答错"同样严重**。基础盲区可判"可入职后补齐"；但把核心概念讲反仍按答错处理。
     - **校招必问的硬信息**（漏问会导致结论无法执行）：毕业时间/届次、可入职时间、能否长期实习、**base 接受度**（在读城市与岗位城市不同时必问）、三方签约情况。
   - **面试官现场观察可参与裁定（AI 的观测盲区不能否决它）**：ASR 转写体现不出的信号（反应速度、吸收提示的速度、冲劲、现场紧张程度、是否边想边说、现场给过提示导致的失分）由面试官口头补充后，可作为裁定依据修正评分；修正后在概览留痕初判与上调/下调理由，供后续轮次参考。
     - **这类信号在转写里根本不存在**，所以**不得**用"我没看到足够证据"去否决"面试官现场看到了"——那是把自己的信息缺失当成候选人的缺陷。典型：转写里只能看到编码环节 5 分钟静默，看不出他是在从容推导还是已经卡死；面试官说"反应挺快"就是有效补充证据。
     - 面试官口头反馈与 AI 初判冲突时（如 AI 判 3 倾向不通过、面试官裁定通过），**以面试官为准**，两者理由都写进概览。
6. **警惕"广度/流畅"冒充深度（反陷阱）**：候选人把一个项目讲得完整、流畅、有量级，**不等于**该项目经得起深度追问。判 `+`（尤其技术支撑/技术深度）前，必须确认其**核心组件/关键设计**在被追问时答得出原理与取舍——**核心组件原理答不出，整个项目的"亮点"要打折，不能用流畅讲述撑起 `+`**。典型反例：自研高性能服务讲得头头是道，但其核心数据结构（如无锁队列）候选人没主动提、被问原理答"不太清楚"——此时该方案不构成技术深度加分。

## 执行流程

1. **（仅"贴链接"入口）采集材料**：按 `references/material-collection.md` 的阶段 0：0.1 按 URL 精确定位标签页 → **0.15 前置探针**判定本轮材料形态（简历 pdf/image/standard、速记 ready/not_ready、代码考核 yes/no）→ 按探针结果分支采集简历（三路）与速记，**探针 coding=yes 才走 0.4 捞题面+代码原文+运行记录**，产出 `<拼音>/00N/{resume.png, asr.md[, candidate-code.<ext>, coding-analysis.md]}` 后再继续。已是材料目录则跳过。
   - ⚠️ **`coding=no` 不等于"本轮没考编程题"**（实测漏判 3 次）。无论探针值如何，**都要回 `asr.md` 扫编程题信号**（`算法题`/`看一个题`/`共享一下`/`编程题` 等）。
     - 前两次是屏幕共享出题、确实无平台产物 → 按"只口述、没落代码"形态评估。
     - **第三次（2026-09-09）是探针假阴性：卡片其实存在、代码完整留存 33 行，但探针返回 no。** 原因是「代码考核」卡片只在**评价弹窗打开后**才进 DOM。后果很严重——报告据此写成"屏幕共享无代码留存、正确性未验证"，把"编码正确性未验证"列为最大短处、把"出题通道不留痕"列为面试官最高优先改进项，**全是错的**（实测代码 9/9 通过）；且当轮多路 review 沿用同一错误前提也没发现。
     - **因此：扫到编程题信号后，必须先点开评价弹窗再探一次卡片**，不能只凭首次探针就断言"无代码产物"。
   - ⚠️ **平台「候选人运行记录/输出」面板为空 ≠ 候选人没运行**（同日第二次踩坑）。该面板有同样的渲染时机问题。判"零自测"是负向判定，**举证责任在判定方**：先看 `asr.md` 里有无运行结果的痕迹（面试官说"示例跑出来是正确的"就是旁证）、代码是否自带测试用例调用；仍不确定时问面试官或按"有自测"处理。详见 scoring-rubric 形态状态机 C3/C4 的判定注意。
   - **速记未就绪即止（硬分支）**：若探针判 `asr=not_ready`（面试未进行 / 转写未生成 / 内容明显不完整）→ **不写任何 asr.md、不产出评价**，向调用方返回 `SKIPPED: 速记未就绪` 并说明原因，让其跳过该候选人、下次再试。**绝不基于残缺或空转写脑补评价。**
2. **定位目标轮次**：
   - 用 `Glob` 扫 `<人名>/[0-9][0-9][0-9]/` 列出所有轮次子目录
   - 含 `asr.md` 的轮次是**目标轮候选**
   - 按前述"判定本次要评估哪一轮"规则确定目标轮。必要时 `AskUserQuestion`。
3. **读取目标轮材料**：
   - `Read` 目标轮的 `asr.md`
   - `Read` 目标轮的 `resume.png`（视觉）；若目标轮无 resume 则查找其他轮的 `resume.png` 复用
   - 若有 `candidate-code.<ext>`：读代码原文，准备实跑（见步骤 5）
   - **只读这些材料。候选人目录下若有其他面试官的评价文件，一律不读、不纳入。**
4. **岗位定位**：从简历 + asr.md 判断 backend / algorithm / bigdata（或混合）。用户已指定则以用户为准。混合岗位取**严格**的那个标准。
4.5 **判定用户角色（主面 / 旁听）**：按「面试官角色判定」跑发言条数统计 + 核对 `asr.md` 头部标注。**这一步的结论只影响步骤 9 的复盘写法，不影响候选人评价的任何环节。** 判不准时 `AskUserQuestion`；无人值守按纯旁听处理并写明依据。
5. **六维打标**（判据见 `references/scoring-rubric.md`）：
   - 只基于目标轮材料做判断。**先给每个维度逐条记证据并标强度（P/N1/N2/U），再按固定优先级生成 `+`/`=`/`-`**，全部为 U 则留空。每条证据必须有来自 `asr.md` 的原话或实测结果支撑
   - **有编码题时先跑「编码形态状态机」定 C0~C4**，形态决定「编码与算法」维度能取的符号
   - 自查：**某一格填 `=` 是因为真的持平，还是因为里面同时有好和坏、不知道填什么？** 后者说明漏了"有 N2 就是 `-`"这一条
   - **本轮有编程题且有 `candidate-code`：必先用题面用例实跑再下结论**（判据/审查清单见 scoring-rubric「传统算法/编程题专项评估」；AI coding 题走该文件「AI coding 题专项评估」）
6. **综合评分**：按 scoring-rubric 的**决策表顺序判，命中即止**，在 6 档中选一个分数。**核心维度（技术支撑/技术深度/编码与算法）出现 `-` 时综合 ≤2.5，不因其他维度有 `+` 而上浮**
7. **严格原则校验**：两档之间犹豫 → 取低档。**这个犹豫过程记进 `review-log.md`，不写进概览**——"在 X 和 Y 之间犹豫按严格原则打 X"属内部举证，对外交付物只给结论（见步骤 10 的概览三条硬约束）
8. **结论判定 + 长短处速判**：≥ 3+ 通过；≤ 2.5 不通过；**= 3 时默认倾向不通过，但面试官可基于实际体验显式裁定通过（裁定通过须在概览写明"打 3，面试官裁定通过"+ 理由）**。并在概览用一两句话**点出候选人最大长处 + 最大短处**（各带证据）
   - ⚠️ **取样不足时的正确写法**：分数压到 3、核心维度标"未充分取样"、补测清单写进「后续面试重点关注」，结论写"打 3，等待面试官裁定"。**不要**写成"不做裁定""证据不足不予通过"——那是替面试官行使了他的裁定权。见 `references/scoring-rubric.md`「⚠️ 分数上限 ≠ 结论上限」。
9. **面试官复盘评价**（标准见 `references/interviewer-rubric.md`）——**先看步骤 4.5 的角色结论再决定怎么写**：
    - **主面场**：从 `asr.md` 中提取面试官（用户）的所有发言，逐项打标（✓/△/✗）；分析时间分配（从时间戳推算）；识别做得好/不好的行为（必须有原话证据），重点看**是否在有限时间内高效判断出候选人长短处**，而非面面俱到；生成最多 3 条按优先级排列的改进建议，综合给出 A/B/C/D 评分
    - **纯旁听场（用户零发言）**：写成**观摩笔记**——不给用户打 A/B/C/D（档位留空并写明原因），五维表的对象写明是主面官（点名），改进建议改成"可借鉴 / 可避免"两类，时间分配照常做。见「纯旁听场」小节。
    - **旁听 + 部分参与**：主体同纯旁听，另加一小节点评用户自己那几句发言，**仍不给整场档位**。
10. **写报告**：按 `references/report-templates.md` 的模板，用 `Write` 输出到 **`<人名>/<目标轮目录>/`**：
    - `evaluation.md`（候选人评价）、`interviewer-review.md`（面试官复盘）
    - 若本轮有编程题：另写 `coding-analysis.md`（题面 + 审查清单 + 验证结果），代码原文存 `candidate-code.<ext>`。**有代码必先实跑再下结论。**
      - ⚠️ **判 C0 前先做一次"补收尾"实测，不要靠读代码目测。** 把未闭合的花括号补上、递归入口接上、`return` 挪对位置、目标值算出来——**这些都是被打断时最先丢的收尾动作，不影响主体成立**。补完能跑就是 `C2`（编码维度按分析过程记 `=` 或 `-`），跑不了才是 `C0`（留空）。**真实事故 2026-09-11：三份报告都因目测"缺 return、缺递归入口"而误判 C0，实测后全部改判 C2**，详见 `references/scoring-rubric.md`「可验收主体」定义。
      - ⚠️ **写实测结果时必须交代改了什么。** 只补收尾就写明"只补 X/Y/Z 三处收尾，算法逻辑一行未动"；补了收尾以外的东西要显式列出；本机无运行时的语言（如 Java）忠实移植到别的语言验证，要写明是移植而非原样运行。禁止把审查者改动过的代码结果笼统写成"候选人代码实测"。
    - ⚠️ **`evaluation.md` 是对外交付物——用户会整段复制进公司招聘系统。零过程性内容**：不写 v1/v2、不写"初判改判"、不写"经 CodeX 评审"、不写"我上一轮误读"、不写规则援引（"按前置门…"）、不用删除线。**结论写成当前唯一结论的样子。** 改判过程写进独立的 `review-log.md`。完整禁止清单与正反例见 `references/report-templates.md`「evaluation.md 是对外交付物」。
    - **重评/改判场景同样适用**：用新规则重跑旧评价时，直接覆写出干净的终态版本，把新旧差异记进 `review-log.md`，**不要**在 evaluation.md 里逐条标注"这条 v1 判 X、v2 改 Y"。
    - 🚨 **概览正文合计不超过 400 字，只给结论、不带原话与时间戳。** 依据写进紧随其后的「维度依据」小节。四条硬约束（模板里有完整示例）：① **结论与校准基准写同一句**（`本轮按<岗位><职级>校准，综合评分：X，通过`）；② **总述 200 字以内，速判每条 50 字以内**，每个方面只写最核心的那一条亮点或缺陷；③ **禁止把评分推导过程写进概览**（"证据分布在几个独立取样单元""在 X 和 Y 之间犹豫按严格原则打 X""决策表第几条"都属内部举证，进 `review-log.md`）；④ 同一条证据不得在"维度依据 + 优点清单 + 速判"里重复三遍。
      - **真实事故 2026-09-11**：上一版规则要求"维度依据集中写在概览、一维一段"，结果三份报告的概览写到 **2230 / 1669 / 1256 字**，单段最长 449 字。用户原话："预览部分每一个环节都写得太长了……概览部分最好不要超过 100 字，最长绝对不要超过 200 字"。**根因是规则自相矛盾**：既要"概览是给只读一段的人看的"，又要"六个维度的依据都塞进来"。现已拆成「概览给结论 + 维度依据给证据」。
      - **真实事故 2026-09-09**：为应对 review 对"3.5 站不站得住"的质疑，在概览塞了一张"四个加分维度分布在三个独立方向"的举证表，同一批证据讲三遍、结构碎——被用户整段重写。举证进 `review-log.md`，不进对外交付物。
    - 🚨 **每条引语落笔前必须回 `asr.md` grep 一次，确认它出自本候选人。** 连续评估多人时最危险的错误不是判分偏差，而是**把 A 的原话写进 B 的报告**——它会凭空制造一段候选人没说过的话，且读者无法察觉。**真实事故 2026-09-09**：范思远那份的软素质写着"量化验证部分以'3 万多条''比较多'代替样本质量论证"，而"3 万多条"是**同批次另一位候选人韩旭**的项目数据，范思远全程没说过；这条还被当成软素质判定的依据。外部 review 三路独立指出"该数字在 asr 与简历中均不存在"才发现。
      - **落笔规则**：写进报告的每个引号内容和每个具体数字，都要能在**本人** `asr.md`/简历里 grep 到；grep 不到就删掉或改写成不含引号的概述。
      - **ASR 清洗的边界**：转写有口误和重复词（"重新拉缩，也拉取"、"跟，就是改变"），清洗可读性可以，但**清洗过就不能再用直引号冒充原话**——改成"他的说法是……"这类概述，或引用未清洗的原句。
      - **同批次多人时尤其危险**：证据提取子代理并行跑、上下文里同时装着多人材料，串台是系统性风险而非偶发。**逐份报告独立核对引语，不要跨报告复用句式。**
      - 🚨 **污染不止发生在引号和数字里，纯文字的技术专名同样会串（2026-09-11 第二次踩）**：赵胤淞那份的「优点」写着"代码行相关监控明确说明归属"，而 `asr.md` 里"代码行"零命中——这是同批次另一位候选人**殷康龙**的项目内容（他的智能研发平台有代码行覆盖率采集，14:40 明确说过"这个监控不是我做的"）。赵胤淞全程没提过任何代码行监控。
        - **为什么 `verify.sh` 拦不住**：引语溯源只查**含数字的引号短语**（纯文字引语在 ASR 清洗后误报率过高，实测把技术专名也纳入检查会天量误报——简历是 PDF 无法 grep、合理概括也会被判缺失）。所以这一条**只能靠落笔纪律，没有机械兜底**。
        - **落笔自查**：写「优点」「风险点」这类清单时，每条里出现的**项目名、系统名、技术组件名**都要能在本人 `asr.md` 或简历里定位。特别当这条读起来"很顺、很像该有的内容"时更要查——串台的内容往往正是因为它在另一个人那里成立才顺。
11. **确定性门禁（写完就跑，不依赖自查）**：`scripts/verify.sh`（运行副本在 `~/hire_patrol/verify.sh`，两份保持同步）。
    ```bash
    T=$(mktemp) && echo "$HOME/github/interviews/<人名>/<轮次目录>" > "$T" \
      && bash ~/hire_patrol/verify.sh "$T" 0; rm -f "$T"
    ```
    - 校验：报告完整性、分数档位白名单、面试官档位无子档、六维表头、禁内部术语与断链引用、禁自造标题、禁复述简历字段、**引语回本人 `asr.md` 溯源**（防跨候选人证据污染）。逐条对应的事故见 `scripts/README.md`。
    - **退出码非 0 就必须改到通过再进下一步**，不要人工判断"这条可以放过"——能被 shell 确定性判定的规则，自查不可靠（实测：同一批报告我自查认为没问题，门禁一跑拦下 8 条）。
12. **多路独立 review（发布门禁，默认必做）**：报告写完后跑 `~/hire_patrol/multi-review.sh <人名>/<轮次目录>`，用 3 个模型 × 2 个侧重共 6 路独立复核。
    - **为什么这一步不能省**：自查查不出自己的系统性偏差。三次真实事故都是外部 review 才发现的——① 把手写编造的"正确解"当成程序实测输出写进报告；② 自创"正负相抵"绕过评分决策表，导致判分倒挂（交付错误代码的人分数**高于**零输出的人）；③ 连续三份用 `A-`/`B+`/`B-` 等未定义档位。这三类错误在自查时都"看起来没问题"。
    - 产出 `<轮次目录>/review/<model>-pass<N>.md` 与 `review/SUMMARY.md`。**有高危 findings 时先改判再对外提交**，改判过程写进 `review-log.md`（不进 `evaluation.md`）。
    - 脚本退出码：0 = 无高危；1 = 有高危需人工确认。
13. **对话简报**：告知候选人综合分、通过/不通过、核心理由（长处/短处速判）；另附面试官评分和核心改进建议；multi-review 的结论与是否改判；最终给出所有产出文件路径

## 评价原则（必须全部遵守）

1. **严格标准**：相邻档之间犹豫一律按低档打；3 默认倾向不通过。唯一例外：3 档可由面试官基于实际面试体验显式裁定通过（须写明理由），其余档位不放水。
2. **证据驱动**：每一个 `+`/`=`/`-` 和每一条优点/风险都**必须引用 `asr.md` 原话或简历原文**（引用原话，不意译）作为依据；编程题结论以**实跑结果**为硬证据。
3. **主动核对**：把简历上写的项目/技术栈 vs 面试回答交叉比对，重点暴露简历夸大、贡献边界不清
4. **不做政治正确**：不因学校、公司、态度好而放宽判断；也不因背景弱而扣分
5. **区分"没答出"与"答错了"**：没答出可接受（除非是岗位核心基础）；答错了严重扣分
6. **区分"背答案"与"真懂"**：被追问时是否崩溃来判断
7. **不脑补**：简历没写、转写没讲的内容，在报告里明确写"未覆盖"
8. **只看本轮（仅约束候选人评价）**：`evaluation.md` 完全基于本轮 `asr.md` + 简历，不读取、不引用、不被其他面试官的评价影响，也不引用其他候选人的材料。
   - **例外：`interviewer-review.md` 允许跨场引用面试官自己的行为做对比**（根因往往要跨场才看得出来），但只能引用面试官自己的话术与行为、不得引用其他候选人的评分或技术表现、不得反向影响候选人评分。完整边界见 `references/interviewer-rubric.md`「跨场对比的边界」。
9. **`evaluation.md` 零过程性内容（对外交付物）**：用户会把它整段贴进公司招聘系统。**只写"候选人怎么样"，不写"这份评价怎么写出来的"**——禁止 v1/v2 版本标记、改判说明、"经 XX 评审"、自我纠错叙事、规则援引、删除线。改判留痕写进 `review-log.md`。禁止清单与正反例见 `references/report-templates.md`。
   - 自查一句：**把这段贴到招聘网站上，HR 和下一轮面试官会不会看到不该看的内部工作过程？**

## 使用示例

用户：
> 评估 `~/interviews/zhang-san`，我做的是 2 面

Claude：
1. `Glob` 扫 `~/interviews/zhang-san/[0-9][0-9][0-9]/`，找到 `001/`、`002/`、`003/`
2. 定位目标轮：`002/asr.md` 存在 → 目标轮为 002（其他轮即使有别的面试官评价文件也忽略）
3. `Read` `002/asr.md` + `002/resume.png`（视觉）；有 `candidate-code.ts` 则读入准备实跑
4. 六维打标：业务理解 `=` / 技术支撑 `=` / 技术广度 `=` / 技术深度 `-`（MySQL 聚簇索引回表答不出，是原理层硬伤）/ 编码与算法 `=`（形态 C2：方向对、基础对，但实现有 bug 且零自测——实现瑕疵不判 `-`）/ 软素质 `=`
5. 技术深度 `-` 的证据：简历写"精通 MySQL"，被问"聚簇索引回表"卡壳（引用 `asr.md` 原话）。编码与算法 `=` 的证据：独立提出解题方向、基础概念无误，但实跑用例 1 期望 True 实际 False（第 12 行循环变量写错），且零自测——**实现瑕疵与零自测写进风险，不判 `-`**（写入 coding-analysis.md）
6. 综合分在 3 和 3+ 之间犹豫 → 严格原则 → 打 **3**；速判：长处=系统设计链路完整，短处=MySQL 基础不扎实 + 代码零自测
7. 面试官复盘：提问路径 `✓`，节奏控制 `△`（编码缺"验证收尾"，写完没让跑用例），追问精准度 `✓`，面试官纪律 `✓`，表达效率 `△`。综合 **B**。
8. `Write` 到 `~/interviews/zhang-san/002/`：`evaluation.md`、`interviewer-review.md`、`coding-analysis.md`
9. 对话简报：
    - 候选人：**3，非 3+，不通过**。核心理由：MySQL 原理层不扎实（技术深度 `-`）；编码方向对但实现有 bug、零自测（记风险，不判 `-`）。
    - 面试官：**B**。核心改进：编码环节留最后 2-3 分钟做验证收尾。

### 示例 2：用户直接贴飞书招聘链接（端到端）

用户：
> 参考上一个候选人的处理方式，处理这个候选人 https://xxx.feishu.cn/hire/talent/765…?application_id=765…

Claude：
1. **阶段 0 采集**（`references/material-collection.md`）：Chrome 打开链接 → title 取姓名 → 拼音建目录 → fetch 简历 API 渲染 `resume.png` → 抽「面试速记」生成 `asr.md` → **有编程题则走 0.4 从「代码考核」详情捞 `candidate-code.<ext>` + 题面**
2. **并行**发起两个子代理：候选人五维证据提取 + 面试官复盘证据分析；主对话同时亲读 asr.md + 简历，并**实跑候选人代码**
3. 确认目标岗位对标职级（如 2-1）→ 按职级校准打分 → 写 `evaluation.md` + `interviewer-review.md`（+ 有编程题则 `coding-analysis.md`）
4. 对话简报（评分/通过与否/长短处/面试官评分/改进建议/文件路径）
5. 若用户基于现场观察裁定改分 → 更新报告并在概览留痕初判与裁定理由

## 不做什么

- ❌ 不联网搜索候选人信息（隐私 & 偏见）
- ❌ 不对背景（学校/公司/籍贯/性别）做倾向性评价
- ❌ 不脑补简历没写、转写没讲的信息
- ❌ 不为凑字数编造"优点"——没有就写"无突出亮点"
- ❌ 不使用 2/2.5/3/3+/3.5/4 以外的分数
- ❌ 不在 borderline 放水打高档
- ❌ 不给"未考核"维度勉强打 `=`（直接留空）
- ❌ 不读取、不引用其他面试官的评价文件——每轮只基于本轮 `asr.md` + 简历独立成文
- ❌ 不强求面面俱到覆盖每个项目——优先在有限时间内高效判断出候选人长短处
- ❌ 不把报告写到错误的路径——候选人评价必须是 `<人名>/<目标轮目录>/evaluation.md`，面试官复盘必须是 `<人名>/<目标轮目录>/interviewer-review.md`
- ❌ 不靠 asr 转写推断编码结果就下结论——有「代码考核」记录必去捞代码原文，有代码必先实跑，如实写出跑到哪一步
- ❌ 不因代码"看起来对/结构清晰"就判其正确——以题面用例实测结果为准（实测用于**精确描述完成度**）
- ❌ **不因"实测不通过"就判编码能力不行**——算法题考的是思路、基础、面对陌生问题的分析过程；实现 bug、写不完、零自测都是可接受瑕疵，只有"核心概念讲反"和"分析过程完全停滞"才判 `-`
- ❌ 不把"口述思路顺畅"等同于"这题做完了"——完成度要如实写；但**没写完 ≠ 能力不行**，别把描述完成度和判能力混为一谈