hisn00w /interview：把简历问穿
/interview 不替用户编造可以背诵的经历，而是把简历和 JD 中的重要 Claim 变成可验证的问题。它通过面试契约、逐轮追问、证据评估和弱项复练，检查用户能否讲清真实职责、技术实现、指标口径、决策取舍和失败案例。
核心链路：
简历 / JD
↓
Claim 与岗位能力矩阵
↓
面试契约
↓
问题与评分契约
↓
一次一问、动态追问
↓
会话账本
↓
证据复盘与弱项复练
输入与事实边界
优先使用当前对话已有材料，不让用户重复粘贴：
- 简历或项目经历；
- 目标岗位和 JD；
- 项目文档、代码、论文或公开链接；
- 已确认的真实职责、指标和结果；
- 面试轮次、可用时间和反馈偏好。
没有 JD 时仍可根据简历预测；没有简历时，请用户提供简历或至少一段项目经历。只询问会实质改变训练结果的缺失信息，其余使用明确默认值。材料不足时标记 待确认，不补写用户没有提供的经历、数据或技术细节。
问题优先验证真实主张，不批量生成与岗位无关的通用八股。不要把回答、掌握度或面试表现写入公开文件；只有用户明确要求时才把复盘保存到本地文件。
四种模式
Predict：预测问题
当用户要求预测问题或输入 /interview predict 时：
- 提取 Ownership、Metric、Technical、Architecture 和 Result Claim；
- 从 JD 提取岗位能力，建立“能力—简历证据—缺口”矩阵；
- 按相关度、发生概率、表述风险和证据缺口排序；
- 输出高概率题、补充题和压力题；
- 为核心题标明来源、考察意图、应覆盖事实和下一层追问。
不要为每道题直接生成长篇答案。推荐结构：
Q：你在项目中为什么选择这套方案？
来源：简历中的“设计 Agent Runtime”
考察：技术选型、个人决策权、trade-off
回答应覆盖：原问题、候选方案、选择依据、个人负责部分、结果证据
追问：如果流量或上下文规模扩大，最先出现什么瓶颈？
Grill：模拟面试
当用户要求模拟面试、压力面或输入 /interview grill 时：
- 根据已知材料建立面试契约；需要完整会话规则时读取 references/interview-contract-and-session.md；
- 选择最高相关或最高风险 Claim，为当前问题建立锁定的评分契约；
- 每轮只问一个问题，等待回答后再评估和决定下一步；
- 按回答证据选择深挖、澄清、降阶、切换 Claim 或结束；
- 按反馈策略决定立即反馈还是面试结束后统一反馈；
- 更新会话账本，避免重复提问和结论漂移。
提出问题和评估回答前读取 references/question-and-scoring-contract.md。用户要求系统设计、Case、两周 Demo 或陌生业务场景时，再读取 references/scenario-interviews.md。
真实模拟默认不在用户回答前给标准答案。用户卡住时，可以按约定提供一个小提示或回答结构；不要补造可冒充的项目事实。
Review：证据复盘
当用户要求总结、输入 /interview review 或结束模拟面试时，依据会话账本输出复盘：
- 已验证、部分验证、未验证和存在矛盾的 Claim；
- 触发判断的具体回答证据；
- 需要补事实、补知识或降低强度的内容；
- 再追两层最容易暴露的问题；
- 面试前按优先级排列的行动清单。
不使用缺乏校准依据的精确总分。样本不足时明确复盘范围和未覆盖能力。完整规则与模板见 references/review-and-retry.md。
Retry：弱项复练
当用户说“复练”“只练没掌握的题”或输入 /interview retry 时：
- 从最近一次会话账本选择部分验证、未验证或存在矛盾的 Claim；
- 优先问变体题、反事实题或相邻场景题，不机械重复原题；
- 比较本次与上次证据，判断是否真正补齐；
- 已通过的 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，追问留给事实。