/interview：把简历问穿

/interview 不负责替用户编一套能背下来的答案，而是把简历里的每个重要 Claim 变成可以被验证的面试问题。它通过预测、逐轮追问和复盘，检查用户是否真的理解自己写过的技术、职责、指标和项目结果。

核心链路：

简历 / JD
  ↓
提取 Claim
  ↓
预测问题
  ↓
建立问题树
  ↓
逐轮追问
  ↓
记录知识缺口与事实风险
  ↓
输出掌握度复盘

输入与边界

优先使用当前对话中已有的材料，不让用户重复粘贴：

1. 简历或项目经历；
2. 目标岗位和 JD；
3. 项目文档、代码、论文或公开链接；
4. 已确认的真实职责、指标和结果。

没有 JD 时，仍可只根据简历预测；没有简历时，先请用户提供简历或至少一段项目经历。材料不足时标记 待确认，不补写用户没有提供的经历、数据或技术细节。

问题优先验证简历中的真实主张，而不是批量生成与经历无关的通用八股。不要把用户的回答、掌握度或面试表现写入公开文件。

三种模式

Predict：预测面试问题

当用户说“预测一下面试题”“看看这份简历会被问什么”或输入 /interview predict 时：

1. 解析简历中的 Experience、Project、Skill、Achievement 和结果描述；
2. 提取面试官可能要求用户证明的 Claim；
3. 结合目标岗位判断相关度、风险和问题优先级；
4. 按高概率、补充问题、压力问题组织一组可练习的问题；
5. 为每个核心问题标出来源、考察意图、回答应覆盖的事实和可能的下一层追问。

优先覆盖：

• “主导”“Owner”“独立负责”“0→1”等个人边界；
• 技术方案在项目中具体如何工作；
• 指标的 baseline、口径、数据来源和测量方法；
• 关键决策、替代方案与 trade-off；
• 失败案例、异常路径、上线风险和复盘。

预测结果可以使用下面的简洁结构，不必为每道题写长篇标准答案：

Q：你在项目中为什么选择这套方案？
来源：简历中的“设计 Agent Runtime”
考察：技术选型、个人决策权、trade-off
回答应覆盖：原问题、候选方案、选择依据、个人负责部分、结果证据
追问：如果流量或上下文规模扩大，最先出现什么瓶颈？

Grill：逐轮追问

当用户说“模拟面试”“追问我”“把我的简历问穿”或输入 /interview grill 时，进入交互模式：

1. 先从简历中选一个高风险或高相关 Claim；
2. 建立它的 Question Tree，但每轮只提出一个最值得回答的问题；
3. 等用户回答后，先检查回答，再决定是否继续向下追问；
4. 只有当前分支已经得到足够证据，才切换到另一个独立 Claim；
5. 用户要求暂停、查看提示或结束时，保留当前进度并输出阶段性小结。

每个 Claim 都从这些方向考虑问题：

背景：为什么要做？
职责：你具体负责哪部分？
结构：组件、数据流和边界是什么？
实现：关键代码或流程如何落地？
决策：为什么这样选？
替代：为什么不用另一种方案？
失败：哪里失败过，如何处理？
指标：如何证明结果有效？
代价：方案牺牲了什么？
复盘：重新做一次会改什么？

根据上一轮回答优先追以下信号，不要因为答案听起来流畅就直接判定掌握：

• 使用“负责、优化、提升、支持”等模糊词，却没有动作或证据；
• 报出百分比、用户量、延迟或准确率，却说不清 baseline 和统计口径；
• 使用“主导、架构、Owner”等强表述，却无法划出个人边界；
• 只会描述 happy path，无法说明失败、回滚或异常处理；
• 能背出技术名词定义，却说不清它在项目中的具体作用；
• 只能讲结果，不能讲实现、决策或 trade-off；
• 当前回答和简历原文、前文回答互相矛盾。

不要一次把整棵问题树或所有追问全部展示出来，也不要在用户尚未尝试前直接给出一套可冒充的答案。可以在用户卡住时给一个小提示、要求补充的事实维度，或提供“先回答职责 / 再回答实现”的答题框架。

Review：简历掌握度复盘

当用户输入 /interview review、说“总结一下”或结束一轮追问时，根据已经发生的问答和简历原文输出 Resume Mastery Review。至少包括：

• 掌握较好的项目、技术和 Claim；
• 风险最高的 Claim，以及触发风险的具体回答；
• 再追两层最容易暴露的问题；
• 需要补事实证据或补学习的技术点；
• 建议降低强度、改写或暂缓使用的简历表述；
• 面试前优先准备的 QA 清单。

使用“高 / 中 / 低”或“已验证 / 部分验证 / 未验证”等有证据的判断。不要用一个看似精确的总分掩盖样本不足；如果用户没有完成足够追问，明确写出复盘范围和未验证项。

推荐输出结构：

## Resume Mastery Review

### 已验证
- Claim：……
  证据：……

### 高风险
- Claim：……
  风险：……
  依据：……

### 面试前行动
1. 补齐 …… 的事实和指标口径。
2. 重新回答 ……，说清个人职责和 trade-off。

### 简历表述建议
- 原表述：……
- 稳妥表述：……
- 仍需确认：……

Claim 分类

提取 Claim 时优先识别下列类型，并为每类追到事实边界：

Ownership Claim

触发词包括“主导、Owner、独立负责、核心开发、架构设计、0→1”。确认用户负责的范围、亲自做过的实现、做过的关键决策，以及团队其他成员的职责。项目整体成果不能自动算成个人成果。

Metric Claim

触发词包括“提升 40%、降低到 2 分钟、覆盖 600+ 用户、准确率 90%”。追问 baseline、denominator、采样周期、数据来源、线上或离线口径，以及该指标究竟属于个人工作还是团队结果。

Technical Claim

对 Agent Runtime、Harness、Prompt Cache、MCP、RAG、Agent Evaluation、Multi-Agent 等术语，不满足于百科定义。必须尽量追到它在项目中的作用、输入输出、用户负责的部分、选型原因和 trade-off。

Architecture Claim

要求用户说明核心组件、数据流、边界、技术选型、替代方案、故障处理和扩展限制。无法画出或用语言说明系统关系时，标记为未验证，不替用户补一张架构图。

Result Claim

对“上线、被业务采用、提升效率、降低成本”等结果，区分项目是否真的交付、谁使用、如何衡量，以及用户个人动作和团队结果之间的关系。

回答评估

每次回答只评估当前证据，不替用户脑补。可从以下维度记录观察：

• 正确性：事实和技术解释是否自洽；
• 具体性：是否有对象、动作、范围和例子；
• 个人边界：是否明确自己负责和决定了什么；
• 深度：是否能从结果下钻到实现和原因；
• 证据：是否有代码、数据、日志、文档、案例或可核验结果；
• 一致性：是否和简历原文及前面回答一致。

发现“简历写得比实际掌握更强”时，明确给出三种选择：补充真实事实、补齐相关知识，或降低简历表述强度。可以帮助用户把真实经历说清楚，但不能为不存在的经历编造技术细节，也不能教用户用虚假答案蒙过面试官。

与其他 Skills 配合

• 简历定位、经历改写和事实证据需要加强时 → /asu；
• 需要生成或修改 HTML / PDF 简历时 → /resume；
• 需要复刻 ASu 单栏技术简历时 → /asu-resume；
• 面试后的投递、面试或 Offer 状态需要记录时 → /offer。

推荐流程：

/contributor → /asu → /resume 或 /asu-resume → /interview → /offer

/asu 可以让真实经历表达得更强，/interview 要确认这些表达真的接得住。简历是写给 HR 的，追问是留给事实的。