Interview Evaluation

Use when writing a Chinese-language interview evaluation from interview audio transcripts, video recordings, or interviewer notes. Triggers include 把这段面试录音转写写成面评、根据这份面试转写帮我写面试评价、给候选人写录用建议、判断候选人是否进入下一轮、按用人单位视角写面评等。

Audits

Pending

ClawScanReview

Agentic behavior and permission review.

Static analysisPass

Pattern checks against bundled files.

VirusTotalPending

Multi-engine malware detections and file reputation.

Install

openclaw skills install interview-evaluation

面试评价

Overview

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

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

简历写的是"做过什么"，面试要验证"是不是真的做过""做到什么深度""下次遇到会不会"。
底层能力（钻研精神、学习速度、逻辑性、自我认知、表达沟通、自驱力）驱动解决复杂新问题。
能力不是凭空存在的，需要从候选人的具体行为和表达中推断。
面试能可靠考察的能力中，逻辑性最可靠，其他能力容易被表演，需要深挖细节验证。

When to Use

用户发来面试录音转写文字 / 面试视频转写 / 面试官记录，要求写面评。
用户要求"判断候选人是否进入下一轮 / 终面 / 录用"。
用户要求"按用人单位视角写面评"，而不是顾问报告。
用户在 [[recruiting-skillset]] 流程中走到面试评价阶段。

Output Structure（严格遵循）

## 综合建议
> ⭐⭐⭐ 强推 / ⭐⭐ 推荐 / ⭐ 待定 / ❌ 不推荐 进入下一轮

## 综合评价

### 优势（2-4 条）
每条格式：**先说能力判断，再接证据叙述**，能力融入叙述中，不单独标注。

### 不足（2-4 条）
同上，反映能力短板或经验缺口。

### 风险（1-3 条）
标注风险类型：□ 稳定性 □ 技术边界 □ 方向偏离 □ 团队适配 □ 其他

## 下一步建议
□ 进入二面 — 重点验证：...
□ 进入终面 — 重点验证：...
□ 不推荐 — 原因：...

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

Writing Rules

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

Capability Dimensions

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

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

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

Probing Techniques

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

关键提醒：

真实性验证最重要：流畅讲细节 → 大概率真实参与；答不上来或绕 → 参与深度有限或非主导。
技术深度 ≠ 表达流畅：必须追问关键技术替代方案、数据 / 指标 / 失败案例 / 权衡。
新概念 ≠ 探索能力强：必须核实是否实际读过源码、跑过 demo、改造过旧系统。

Anti-Patterns

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

完整列表见 attribution-errors.md。

Pre-Output Discipline

必须先读完整转写 / 记录，再判断，不只根据简历印象。
批量面试转写姓名误识别风险：同一候选人在转写中可能有多个称呼（姓名、昵称、口误）。若用户提到"昨天那批名单 / 按名字匹配"，必须先用历史会话和本地简历文件核对正式姓名，再在内部材料里加"姓名匹配说明"表。正式报告中不要出现姓名匹配过程。
PDF 简历提取：见 [[recruiting-resume-screening]] 的 pdf-extraction.md。

Output Discipline

Markdown 格式，中文输出。
每条优势 / 不足不加"体现：XXX"括号标注，能力直接融入叙述。
优势不超过 4 条，不足不超过 4 条，风险不超过 3 条（精炼）。
不回避矛盾——候选人某方面强但另一方面有风险，两面都写。
下一步建议要具体，"重点验证：xxx"要写清楚验证什么。
完成面评后必须落为 .md 文件并交付给用户（保存到本地或发送到对话），不要只在回复中给出一次性文本。
正式报告只保留评价内容：综合建议、优势、不足、风险、下一步。姓名匹配、修订说明、材料定位、工具执行痕迹不要混入正式报告，除非用户明确要求。

Self-Check

输出前逐项确认：

Feedback Loop

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

评价是否准确？哪些地方评高了 / 评低了？后续面试 / 共事结果是否验证了判断？
是否有遗漏的能力维度？哪些维度过度关注，哪些被忽略？
归因是否准确？有没有新的常见归因错误？
追问技巧是否有效？哪些追问挖出了有效信息，哪些是无效问题？

反馈类型	更新内容
评价偏差	在 EVOLUTION.md 记录预测命中率，形成校准数据
归因错误	补充到 attribution-errors.md
追问无效	优化 probing-techniques.md
维度缺失	补充到 capability-dimensions.md
新发现	记录到 EVOLUTION.md