简历 Claim、项目证据与面试回答的可追溯链

用 Claim → Question → Knowledge → Evidence → Answer 把简历表述、面试题、长期知识与真实代码证据连接起来，防止回答超过当前实现。

#howto #evergreen #work #interview

[!info] related notes

所属 MOC：面试准备 MOC

题源规范：面试题来源、置信度与答案依据

答题方法：技术面试回答框架

简历 Claim、项目证据与面试回答的可追溯链

目标

任何写进简历、用于项目介绍或出现在面试回答中的关键技术表述，都应该能够沿下面的链条追溯：

Resume Claim
  ↓
可能的 Interview Question
  ↓
Thought Forest 长期知识
  ↓
Project Evidence（代码 / 测试 / ADR / 运行结果）
  ↓
有边界的 Interview Answer

知识笔记负责回答“这个机制是什么”；项目证据负责回答“我的项目是否真的这样做”。两者不能互相替代。

证据强度

等级	证据	面试允许的措辞
`E3`	当前运行代码 + 自动化测试 + ADR/文档，三者一致	“当前实现是……，并由……测试验证”
`E2`	当前代码或自动化测试可以直接证明	“当前已有……实现；完整端到端闭环仍在……”
`E1`	ADR、方案或计划明确，但实现尚未完整	“当前设计为……，尚未全部落地”
`E0`	只有想法、旧稿、AI 对话或未验证描述	不能作为已实现经历；只能说“我考虑过……”

建立索引

对每条重要 claim 记录：

## Claim

### 简历当前表述

### 题库入口
- [[某面试题库#稳定章节]]

### 长期知识
- [[某概念笔记]]
- [[某关系笔记]]

### 当前项目证据
- 代码：
- 测试：
- ADR / 文档：
- 运行结果：

### 证据等级
E0 / E1 / E2 / E3

### 可以说

### 不能说

### 最后核验日期

回答生成规则

E3

可以讲完整调用链、失败路径和验证方式，但仍不能编造吞吐、准确率或成本数字。

E2

明确已有的局部实现，同时指出还缺什么。不要用“完整闭环”“生产级”覆盖未验证部分。

E1

先说“这是当前设计/正在实施的方案”，再讲为什么这样设计。不要使用完成时态。

E0

从简历和标准项目答案中移除。它可以留在 roadmap 或方案笔记，不应成为个人经历 claim。

项目变化后的更新顺序

先更新项目代码和测试；
更新项目 ADR / evidence index；
调整简历 claim；
调整项目面试题答案；
只有机制本身变化时，才修改长期知识笔记。

这样可以避免一次项目发版导致所有通用知识页都被重写。

面试前核验

面试前只重新核验高风险 claim：

框架行为容易说错，例如 interrupt/resume；
数字容易过度外推，例如 9 个 qualification case；
名词比实现强，例如 singleflight、exact-SHA、production-ready；
当前项目近期重构过，旧答案可能已经漂移；
多服务、权限、安全、数据一致性等会被连续追问的边界。

Resume 中应继续保留什么

resume/materials/interview-prep/02-source-evidence-index.md 继续作为动态项目证据索引，因为代码路径、commit 和测试会频繁变化。Thought Forest 只保存本页的稳定方法和项目架构知识，不复制容易漂移的每一条文件路径。