Interview Evaluation

面试评价 Overview

根据面试录音转写、视频记录或面试官笔记，撰写结构化、可直接用于用人决策的面试评价。

Core principle: 面试是筛选"能力合适"的候选人，而非"经验匹配"的候选人。

简历写的是"做过什么"，面试要验证"是不是真的做过""做到什么深度""下次遇到会不会"。 底层能力（钻研精神、学习速度、逻辑性、自我认知、表达沟通、自驱力）驱动解决复杂新问题。 能力不是凭空存在的，需要从候选人的具体行为和表达中推断。 面试能可靠考察的能力中，逻辑性最可靠，其他能力容易被表演，需要深挖细节验证。 When to Use 用户发来面试录音转写文字 / 面试视频转写 / 面试官记录，要求写面评。 用户要求"判断候选人是否进入下一轮 / 终面 / 录用"。 用户要求"按用人单位视角写面评"，而不是顾问报告。 用户在 [[recruiting-技能设置]] 流程中走到面试评价阶段。 输出 Structure（严格遵循）

综合建议

⭐⭐⭐ 强推 / ⭐⭐ 推荐 / ⭐ 待定 / ❌ 不推荐 进入下一轮

综合评价

优势（2-4 条）

每条格式：先说能力判断，再接证据叙述，能力融入叙述中，不单独标注。

不足（2-4 条）

同上，反映能力短板或经验缺口。

风险（1-3 条）

标注风险类型：□ 稳定性 □ 技术边界 □ 方向偏离 □ 团队适配 □ 其他

下一步建议

□ 进入二面 — 重点验证：... □ 进入终面 — 重点验证：... □ 不推荐 — 原因：...

空白模板见 evaluation-template.md。完整示例见 example-evaluation.md。

Writing Rules 用人单位视角：直接输出内部面评结论（"建议进入下一轮""不建议继续推进""不满足我们当前预期"），不要写成第三方顾问式建议。 避免条件化、顾问式表达：不要使用"更准确地说""如果团队当前更需要…那么…""可以保留观察"这类外部视角措辞，除非用户明确要求顾问报告。 优势 / 不足每条只描述一件事，不要把多件事揉在一起。 证据为能力判断服务：证据要有具体行为，而非泛泛描述。 能力名称直接出现在句首或句中，不加括号标注，不单独列维度。 描述具体可感，避免"有一定经验""表现出色"等模糊表达。 不足的归因必须准确：把"经验不匹配""岗位不要求的能力"和"真正的能力短板"分清。详见 attribution-errors.md。 Capability Dimensions

候选人评估参考 16 个维度（不作为固定框架，需揉进优势 / 不足 / 风险描述）：

底层能力（6）：钻研精神、学习速度、逻辑性、自我认知、表达沟通、自驱力。 经验维度（5）：领域 上下文 理解、产品场景匹配度、工程落地深度、产品 sense、技术栈覆盖。 风险维度（5）：稳定性、技术边界、方向偏离、团队适配、意愿真实性。

完整定义、行为信号和打分提示见 capability-dimensions.md。

Probing Techniques

面试追问 / 复核证据的 3 类技巧：真实性验证、能力深度验证、风险验证。详见 probing-techniques.md。

关键提醒：

真实性验证最重要：流畅讲细节 → 大概率真实参与；答不上来或绕 → 参与深度有限或非主导。 技术深度 ≠ 表达流畅：必须追问关键技术替代方案、数据 / 指标 / 失败案例 / 权衡。 新概念 ≠ 探索能力强：必须核实是否实际读过源码、跑过 demo、改造过旧系统。 Anti-Patterns 错误归因 正确归因 产品经理不深度参与模型微调 → 钻研精神弱 → 简历夸大 / 不实 跨行业没经验 → 学习能力差 → 面试准备不充分 / 方向偏离 回答绕 → 逻辑不清 → 可能是细节参与有限（自我认知问题） 说不清楚 → 表达差 → 可能是没想清楚（钻研 / 认知问题） 表达流畅、项目链路讲得完整 → 技术能力强 → 表达能力好；技术深度看关键追问下能否讲清实现细节、指标、badcase、方案权衡 说"我设计 / 我负责" → 独立主导 → 需核实 mentor、正式员工、数据 / 测试团队边界 提到新框架 / 新概念 → 探索能力强 → 需核实是否实际读源码、跑 demo、改造旧系统

完整列表见 attribution-errors.md。

Pre-输出 Discipline 必须先读完整转写 / 记录，再判断，不只根据简历印象。 批量面试转写姓名误识别风险：同一候选人在转写中可能有多个称呼（姓名、昵称、口误）。若用户提到"昨天那批名单 / 按名字匹配"，必须先用历史会话和本地简历文件核对正式姓名，再在内部材料里加"姓名匹配说明"表。正式报告中不要出现姓名匹配过程。 PDF 简历提取：见 [[恢复-screening]] 的 pdf-提取ion.md。 输出 Discipline Markdown 格式，中文输出。 每条优势 / 不足不加"体现：XXX"括号标注，能力直接融入叙述。 优势不超过 4 条，不足不超过 4 条，风险不超过 3 条（精炼）。 不回避矛盾——候选人某方面强但另一方面有风险，两面都写。 下一步建议要具体，"重点验证：xxx"要写清楚验证什么。 完成面评后必须落为 .md 文件并交付给用户（保存到本地或发送到对话），不要只在回复中给出一次性文本。 正式报告只保留评价内容：综合建议、优势、不足、风险、下一步。姓名匹配、修订说明、材料定位、工具执行痕迹不要混入正式报告，除非用户明确要求。 Self-检查

输出前逐项确认：

简历 PDF 是否已正确提取？ 面试转写文字是否完整阅读？ 优势 2-4 条，每条先说能力再接证据？ 不足 2-4 条，归因是否准确（产品不该背工程的锅）？ 风险标注了类型？ 下一步建议是否具体？ 没有"体现：XXX"类型括号标注？ 把"表达好"与"技术深度强"分开？ 核实了候选人个人贡献边界，没有把"我负责"默认成"独立主导"？ 把"提到新技术"与"真实探索 / 实践"分开？ 已将面试评价保存为 Markdown 文件并交付给用户？ 正式报告里没有姓名匹配、修订说明、工具执行痕迹？ Feedback Loop

每次完成面评后主动询问用户：

评价是否准确？哪些地方评高了 / 评低了？后续面试 / 共事结果是否验证了判断？ 是否有遗漏的能力维度？哪些维度过度关注，哪些被忽略？ 归因是否准确？有没有新的常见归因错误？ 追问技巧是否有效？哪些追问挖出了有效信息，哪些是无效问题？ 反馈类型 更新内容 评价偏差 在 EVOLUTION.md 记录预测命中率，形成校准数据 归因错误 补充到 attribution-errors.md 追问无效 优化 probing-techniques.md 维度缺失 补充到 capability-dimensions.md 新发现 记录到 EVOLUTION.md See Also capability-dimensions.md — 16 个能力维度的定义。 attribution-errors.md — 常见归因错误对照。 probing-techniques.md — 真实性 / 深度 / 风险 3 类追问技巧。 evaluation-template.md — 空白面评模板。 example-evaluation.md — 完整面评示例（含写作要点说明）。 EVOLUTION.md — 演化日志。 总控流程：[[recruiting-技能设置]]；简历筛选：[[恢复-screening]]。