# 常见归因错误对照

面评的核心难点不是写不出来，而是**归因写错**——把"经验不匹配"当成"能力不合适"，或者把"表达好"当成"能力强"。

## 错误归因 → 正确归因

| 错误归因 | 正确归因 |
| --- | --- |
| 产品经理不深度参与模型微调 → 钻研精神弱 | → 简历夸大 / 不实（模型微调是工程师的活，产品经理不擅长是正常的） |
| 跨行业没经验 → 学习能力差 | → 面试准备不充分 / 方向偏离（学习速度要看主动做功课的证据，不是看是否做过该行业） |
| 回答绕 → 逻辑不清 | → 可能是细节参与有限（自我认知问题，不愿意承认没参与） |
| 说不清楚 → 表达差 | → 可能是没想清楚（钻研 / 认知问题） |
| 表达流畅、项目链路讲得完整 → 技术能力强 | → 表达能力好；技术深度必须看关键追问下能否讲清实现细节、指标、badcase 和方案权衡 |
| 说"我设计 / 我负责" → 独立主导 | → 需核实 mentor、正式员工、数据团队、测试团队的参与边界，区分独立决策、方案调研、编码实现和协作交付 |
| 能提到新框架 / 新概念 → 探索能力强 | → 需看是否实际读过源码、跑过 demo、改造过旧系统；只"看到过但没深度用过"应降级为概念了解 |
| 候选人与简历姓名不一致 → 学习能力差 | → 身份存疑，需核实（可能是转写姓名误识别、可能是候选人代面） |
| 对岗位不了解未做功课 → 学习速度慢 | → 面试准备不充分 / 意愿存疑 |

## 表达能力 vs 技术深度

候选人讲项目流畅、链路完整、有 PPT 感 → 只能说明**表达能力强**，不能直接推论技术能力强。

要判断技术深度，必须追问：

- **替代方案**：为什么不用大模型直接做？为什么用 BERT / 规则 / 工作流？
- **数据**：这个项目的数据规模、清洗逻辑、标注质量？
- **指标**：用什么指标评估？基线是什么？
- **失败案例**：badcase 是什么？怎么处理？
- **权衡**：成本、延迟、稳定性、可解释性之间怎么取舍？

如果候选人在关键追问下**讲不清实现细节、指标、badcase、权衡**，技术深度判断应明确写"技术深度不足 / 不推荐"，**即使简历堆了 SpringCloud、K8s、RAG、LoRA 等关键词**。

## 个人贡献 vs 团队成果

候选人说"我负责""我设计"时，要核实：

- 是否有 mentor / 正式员工把关方案？
- 数据团队 / 测试团队 / 算法团队是否参与？
- 候选人在其中独立决策 vs 方案调研 vs 编码实现 vs 协作交付的边界是什么？

如果不能区分边界，默认按"参与"处理，**不要**默认成"独立主导"。

## 新概念 vs 实际探索

候选人提到 Claude Code、OpenHands、LangGraph、Agent Skill、MCP 等新名词时，**不要**直接加分。必须追问是否：

- 实际阅读源码？
- 跑通过 demo？
- 改造过旧项目？
- 形成具体方案 / 文档 / 复盘？

承认"看过但没深度用过"时，应把**探索能力评价下调**，不应该把概念了解写成探索能力强。

## AI Coding 经验

评价 AI Coding 经验时要区分"会用工具"和"有工程化方法论"：

- 仅能描述 Codex / Cursor 生成 plan、分步执行、本地联调 → 工具使用熟练。
- 强信号应包括：规范化上下文 / skill、自动化测试、代码审查清单、失败复盘、质量门禁、可复用工作流。

只有上面这些工程化方法论的证据，才能写"AI 工程化能力强"。

## 技术岗的"基础题"判断

技术岗面评要敢基于核心基础问题下判断：网络链路、部署架构、JVM/OOM、线上排障等基础问题回答明显偏浅时，**即使简历堆满 SpringCloud / K8s / RAG / LoRA 等关键词**，也应明确写为"技术深度不足 / 不推荐"，避免被关键词光环带偏。

## 姓名 / 身份类

| 现象 | 应归因 |
| --- | --- |
| 候选人面试时自称姓名与简历不一致 | 身份存疑，需核实（不是能力问题） |
| 批量面试转写中候选人有多个称呼（昵称、口误） | 转写噪声，需用历史会话与本地简历核对正式姓名 |
| 候选人在转写中明显照念准备好的稿子 | 表达 / 真实性存疑，需结合追问观察 |