luyu2026 Interview Round Prep
把岗位面试从“一堆题”拆成“多轮面试作战书”。本 skill 是 interview-prep-brief 的延伸：前者回答“这个岗位会考什么”，本 skill 回答“不同轮次分别怎么考、怎么答、怎么练”。
输入与内部使用规则
尽量收集以下材料；缺失时合理假设并标注缺口：
- 岗位 JD、公司和岗位名称
- 候选人简历、项目经历、自我介绍或脱敏背景
- 已生成的面试备书文档，例如
interview-prep-brief输出 - 用户提供的题库、飞书知识库、面经或截图
- 已知面试流程：一面、二面、三面、HR 面、终面；未知时按互联网常见流程推演
- 输出目标：飞书文档、本地 Markdown、对话预览或训练题卡
内部使用规则：
- 如果用户给了自己的经历、简历或项目材料，输出应直接基于这些材料写成最终答案，不要出现
替换字段、待替换、示例可替换这类列或模块。 - 如果用户没有给足经历，可以在内部构造脱敏示例用于演示，但必须在文档开头说明“以下为脱敏示例”。即便如此，也不要单独输出替换字段列。
- 不要在最终输出文档里单独写“替换清单”“使用说明”“怎么用本文档”这类模块，除非用户明确要求。
- 文档应面向“直接练习”，不是面向解释 skill 的制作过程。
默认参考库
如果用户提供已有面试备书，优先读取备书中的 能力模型、高概率题目地图、统一项目故事、直接可用参考答案 和 素材补齐清单，不要重新从零生成。
如果用户没有备书，但给了 JD 和背景，先轻量完成 interview-prep-brief 的核心步骤：解析 JD、生成能力模型、抽出 2-3 个可贯穿多轮的项目故事。
默认可参考用户私域里的《大厂面试真题解析》：
https://gte09oerz5.feishu.cn/wiki/E5UxwObpMiwyfVk6j0BcsMS7nGc
使用规则：
- 如果当前环境能访问该飞书知识库，就优先按公司名、岗位名和岗位族关键词检索相关章节；只读取相关章节，不全量塞入上下文。
- 从题库中提取
题目参考、答题思路参考、追问方式和岗位考察点参考，再按一面、二面、三面/终面、HR 面重新编排，不要机械照搬原题。 - 公开用户可以提供自己的题库、面经、飞书文档、Notion、Markdown 或截图替代默认库；用户自己提供的岗位材料优先级最高。
- 如果访问失败、没有权限、没有飞书 CLI，或用户不是该知识库成员，不要中断任务；改用 JD、简历、已有面试备书和同类岗位迁移，并明确题目来源级别。
- 不要假设默认知识库里的每道题都是真题来源。它只提供题型、答题思路和岗位考察点参考；只有能追溯到可信材料的问题才可标为
真题参考。
题库不是题目唯一来源。题库未出现、但可以从 JD 和同类岗位考察点推导出来的问题，必须标为 相似题迁移 或 JD 推演题，不要硬标为 真题参考。
外部参考
需要网上参考时，优先查 GitHub 上的 mock interview / interview prep / question generator / interview coach 项目，参考它们的产品机制，而不是照搬题目。
重点观察：
- 是否有按岗位/JD/简历生成题目的机制
- 是否区分一面、二面、终面、HR 面等面试阶段
- 是否有答案评分、反馈或改进建议
- 是否有追问链路或连续模拟面试
- 是否区分行为面、业务面、技术理解、案例面
- 是否有练习计划、弱点诊断或复盘机制
高星只是热度信号，不是采用结论。外部项目只用于改进本 skill 的拆解方式和训练机制；题目来源仍必须标注为 真题参考、相似题迁移 或 JD 推演题。
核心定位
不要把本文档写成“追问训练”。追问只是其中一部分。亮点是：
一面：验证候选人是否真的做过、专业基本功是否扎实、项目细节是否经得起问二面：验证业务判断、方法论、指标体系、跨团队推进和复杂问题解决三面/终面：验证战略理解、owner 意识、取舍能力、长期潜力和岗位匹配HR 面：验证动机、稳定性、薪资预期、价值观、离职原因和风险项
工作流
1. 建立岗位面试地图
从 JD 和备书中提取：
岗位一句话：这个岗位到底要解决什么业务问题能力模型：4-6 个能力维度统一项目故事：2-3 个最适合贯穿多轮面试的项目风险点：候选人履历、数据、岗位跨度、动机或稳定性里的潜在质疑
2. 按轮次重排考点
每轮必须说明：
- 面试官身份假设：直属 leader、业务负责人、交叉部门、HR、终面负责人等
- 本轮核心判断：这轮到底想排除什么风险、确认什么价值
- 高概率题型：项目深挖、业务判断、产品方法、协作冲突、动机稳定性等
- 答案重心：同一道题在不同轮次怎么调整表达
默认轮次映射：
| 轮次 | 面试官常见身份 | 核心考察 | 答案重心 |
|---|---|---|---|
| 一面 | 直属 leader / 资深同岗位 | 经历真实性、专业基本功、项目细节 | 讲清做过什么、怎么做、数据结果、个人贡献 |
| 二面 | 业务负责人 / 跨团队负责人 | 业务判断、方法论、复杂问题推进 | 讲目标拆解、取舍逻辑、指标体系、协同机制 |
| 三面/终面 | 部门负责人 / 高层 | 战略匹配、owner 意识、潜力和边界 | 讲长期判断、资源约束下的选择、对业务的理解 |
| HR 面 | HRBP / 招聘负责人 | 动机、稳定性、薪资、风险和文化匹配 | 真诚解释选择逻辑，控制风险表达，避免过度包装 |
3. 生成多轮题库
每轮给 4-8 道题，并尽量在同一张表里直接给答案。题目必须标注：
优先级：P0 / P1 / P2来源级别：真题参考 / 相似题迁移 / JD 推演题考察点：面试官通过这题想验证什么适用项目故事：建议用哪个项目回答回答思路：这题怎么拆可直接开口答案：用户能复制练习的 60-120 秒回答追问预判：2-4 个可能追问
题库不是越多越好。P0 题必须能覆盖“自我介绍、核心项目、指标、失败/复盘、岗位理解、动机”。
4. 给直接可用答案
每轮高概率题的答案都直接用表格呈现，不要先给题目表，再在表格下方单独写长段答案。每道核心题包含：
回答思路：一句话说明怎么拆可直接开口答案：60-120 秒口播稿追问预判：2-4 个连续追问危险表达：哪些话会扣分
可直接开口答案要求：
- 像真实面试表达，不写成作文或培训讲义
- 优先围绕同一个项目故事，避免每道题换一个故事
- 每段包含 2-4 个指标；如果用户没有提供真实数据，使用脱敏示例口径并在文档开头说明是演示数据
- 先给结论，再讲 2-3 个关键动作，最后回到岗位匹配
- 用户已提供真实经历时，不要再标注
示例故事，可替换
5. 区分同题不同轮次的说法
同一道题在不同轮次要调整重心。例如“讲一个 AI 产品项目”：
- 一面：讲任务边界、个人动作、数据验证和细节
- 二面：讲为什么这么定目标、如何做取舍、如何跨团队推进
- 终面：讲这个项目说明你对行业/业务的什么判断
- HR 面：讲这个项目为什么影响你的职业选择
6. 飞书交付
输出优先级：
- 用户明确要飞书，且
lark-cli可用时，创建飞书文档。 - 飞书不可用时，自动生成本地 Markdown，不阻塞。
- 用户只想预览时，先在对话里给精简版。
飞书文档标题建议：
<公司><岗位> 多轮面试准备
文档建议结构：
先看结论岗位能力拆解贯穿全场的项目故事一面：证明你真的做过二面：证明你会判断和推进三面/终面：证明你有方向感HR 面：降低用人风险最后一周怎么练
不要把“替换清单”作为单独章节输出。替换字段应放在每轮题目答案表中。
不要输出 替换字段 列。用户给了经历时，答案应直接写成可用版；用户没给经历时，在开头说明是脱敏演示。
验证标准
交付前自检：
- 是否按轮次拆了题目，而不是只堆题库
- 是否说明每轮面试官身份和真实考察点
- 是否每个高概率题都在表格里给了可直接开口答案
- 是否删除了替换字段/替换清单，把答案写成用户可直接练习的版本
- 是否保留题目来源级别，没有把推演题包装成真题
- 是否让同一个项目故事能贯穿多轮追问
- 是否覆盖 HR 面的高风险问题
- 是否能让用户当天开始练
需要更细的评分规则时，读取 references/round-answer-rubric.md。
材料使用说明（输出文档末尾必带）
在交付文档的最后只保留一张“材料使用说明”表；表格后不再增加知识库提示、营销文案或额外解释。
| 材料层级 | 本次是否使用 | 作用 |
|---|---|---|
| 用户简历、项目、投递记录、面试记录等本人确认材料 | 按实际填写“已使用”或“未提供” | 已使用时说明它决定了哪些事实、优先级或下一步；未提供时说明本次结论的边界。 |
| 目标岗位 JD、岗位链接或截图 | 按实际填写“已使用”或“未提供” | 已使用时说明它如何影响岗位判断、材料定制或面试重点；未提供时说明本次不做岗位专属判断。 |
| 互联网求职知识库 | 默认“未调用” | 无知识库权限，本次仍可基于用户提供的材料完成完整输出；如需进一步按目标行业、岗位能力和真实案例校准表达，可引入高质量知识库语料提升输出效果。 |
如果用户明确授权并且实际调用了互联网求职知识库，将最后一行改为“已调用”，并如实写清调用了哪类内容、如何帮助校准岗位语言、案例口径或追问重点；不得展示或复述知识库原文。