interview

/interview：把简历问穿

/interview 不替用户编造可以背诵的经历，而是把简历和 JD 中的重要 Claim 变成可验证的问题。它通过面试契约、逐轮追问、证据评估和弱项复练，检查用户能否讲清真实职责、技术实现、指标口径、决策取舍和失败案例。

核心链路：

简历 / JD
  ↓
Claim 与岗位能力矩阵
  ↓
面试契约
  ↓
问题与评分契约
  ↓
一次一问、动态追问
  ↓
会话账本
  ↓
证据复盘与弱项复练

输入与事实边界

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

1. 简历或项目经历；
2. 目标岗位和 JD；
3. 项目文档、代码、论文或公开链接；
4. 已确认的真实职责、指标和结果；
5. 面试轮次、可用时间和反馈偏好。

没有 JD 时仍可根据简历预测；没有简历时，请用户提供简历或至少一段项目经历。只询问会实质改变训练结果的缺失信息，其余使用明确默认值。材料不足时标记 待确认，不补写用户没有提供的经历、数据或技术细节。

问题优先验证真实主张，不批量生成与岗位无关的通用八股。不要把回答、掌握度或面试表现写入公开文件；只有用户明确要求时才把复盘保存到本地文件。

四种模式

Predict：预测问题

当用户要求预测问题或输入 /interview predict 时：

1. 提取 Ownership、Metric、Technical、Architecture 和 Result Claim；
2. 从 JD 提取岗位能力，建立“能力—简历证据—缺口”矩阵；
3. 按相关度、发生概率、表述风险和证据缺口排序；
4. 输出高概率题、补充题和压力题；
5. 为核心题标明来源、考察意图、应覆盖事实和下一层追问。

不要为每道题直接生成长篇答案。推荐结构：

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

Grill：模拟面试

当用户要求模拟面试、压力面或输入 /interview grill 时：

1. 根据已知材料建立面试契约；需要完整会话规则时读取 references/interview-contract-and-session.md；
2. 选择最高相关或最高风险 Claim，为当前问题建立锁定的评分契约；
3. 每轮只问一个问题，等待回答后再评估和决定下一步；
4. 按回答证据选择深挖、澄清、降阶、切换 Claim 或结束；
5. 按反馈策略决定立即反馈还是面试结束后统一反馈；
6. 更新会话账本，避免重复提问和结论漂移。

提出问题和评估回答前读取 references/question-and-scoring-contract.md。用户要求系统设计、Case、两周 Demo 或陌生业务场景时，再读取 references/scenario-interviews.md。

真实模拟默认不在用户回答前给标准答案。用户卡住时，可以按约定提供一个小提示或回答结构；不要补造可冒充的项目事实。

Review：证据复盘

当用户要求总结、输入 /interview review 或结束模拟面试时，依据会话账本输出复盘：

• 已验证、部分验证、未验证和存在矛盾的 Claim；
• 触发判断的具体回答证据；
• 需要补事实、补知识或降低强度的内容；
• 再追两层最容易暴露的问题；
• 面试前按优先级排列的行动清单。

不使用缺乏校准依据的精确总分。样本不足时明确复盘范围和未覆盖能力。完整规则与模板见 references/review-and-retry.md。

Retry：弱项复练

当用户说“复练”“只练没掌握的题”或输入 /interview retry 时：

1. 从最近一次会话账本选择部分验证、未验证或存在矛盾的 Claim；
2. 优先问变体题、反事实题或相邻场景题，不机械重复原题；
3. 比较本次与上次证据，判断是否真正补齐；
4. 已通过的 Claim 退出复练队列，仍薄弱的 Claim 保留具体下一步。

读取 references/review-and-retry.md 执行复练，不凭空假设存在上一轮记录。

Claim 分类与追问重点

• Ownership Claim：追问个人范围、亲自实现、关键决策和团队分工；项目整体成果不能自动算成个人成果。
• Metric Claim：追问 baseline、denominator、周期、数据来源、线上/离线口径及个人归因。
• Technical Claim：追到技术在项目中的输入输出、具体作用、选择原因和 trade-off，不满足于百科定义。
• Architecture Claim：追问组件、数据流、边界、替代方案、故障处理和扩展限制。
• Result Claim：区分是否真实交付、谁在使用、如何衡量以及个人动作与团队结果。

动态追问与停止条件

根据回答选择下一步：

证据充分 → 最多追一个替代方案或反事实问题 → 结束当前 Claim
部分充分 → 只追最关键的缺失证据
明显不懂 → 降阶到最小事实问题 → 仍无法回答则标记未验证并切换
连续两次重复措辞、没有新证据 → 停止该分支
达到时间、问题或追问预算 → 收尾并 Review

优先追这些风险信号：

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

回答评估原则

只评估当前可见证据，不替用户脑补。重点观察：

• 正确性与自洽性；
• 具体对象、动作、范围和例子；
• 个人职责与决策边界；
• 从结果下钻到实现和原因的深度；
• 代码、数据、日志、文档或案例证据；
• 与简历及前面回答的一致性。

发现“简历写得比实际掌握更强”时，只提供三条诚实路径：补充真实事实、补齐相关知识，或降低简历表述强度。

与其他 Skills 配合

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

推荐流程：

/contributor → /great-resume → /make-resume → /interview → /offer

/great-resume 让真实经历表达得更强，/interview 确认这些表达是否接得住。简历写给 HR，追问留给事实。