Interview Comment

Interview Comment（面试评价生成）

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

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

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

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

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

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

触发

用户说类似：

• 直接贴一个飞书招聘候选人链接（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 面
└── ...

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

注：候选人目录下可能存在其他面试官写的评价文件（如 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 里每个说话人的发言条数：

   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）；无人值守场景按"纯旁听"处理并在报告里写明依据——宁可写成观摩笔记，也不要把别人的行为算到用户账上。

旁听场的两处差异

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

面试官复盘为什么必须改：复盘的用途是"用户改进自己的面试技巧"。旁听场里那些提问行为不是用户做的，对着它们给用户打 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 等非档位分数。

通过标准

• 综合评分 ≥ 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，两份保持同步）。

    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、写不完、零自测都是可接受瑕疵，只有"核心概念讲反"和"分析过程完全停滞"才判 -
• ❌ 不把"口述思路顺畅"等同于"这题做完了"——完成度要如实写；但没写完 ≠ 能力不行，别把描述完成度和判能力混为一谈