interview

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