| name | interview-prep-brief |
| description | 根据用户要面试的岗位 JD、公司、候选人背景、已有题库或飞书求职知识库，生成岗位专属面试备书文档。适用于用户说“围绕这个岗位准备面试”“生成可能面试题和答案”“模拟面试官追问”“从 JD 反推面试题”“调用大厂面试真题解析做备面”等场景。输出必须包含岗位能力模型、高概率题目、答案骨架、追问链路、评分标准、个人素材补齐清单，并标注题目来源级别。 |
Interview Prep Brief
为陌生岗位快速生成“面试备书”。不要只生成题目和答案；普通题库输出和通用聊天模型没有差异。必须把 JD、已有真题、候选人经历和面试官考察逻辑合成一份可训练、可复盘、可发给用户的备面作战书。
输入
尽量收集以下信息；缺失时先合理假设并标注缺口：
- 岗位 JD 或岗位链接/截图
- 公司和岗位名称
- 候选人背景、简历、项目经历或自我介绍
- 用户已有题库/飞书知识库链接，例如“大厂面试真题解析”
- 面试阶段：一面、二面、HR 面、终面或未知
- 输出目标：飞书文档、本地 Markdown、题卡、模拟面试脚本
默认参考库
默认可参考用户私域里的《大厂面试真题解析》：
https://gte09oerz5.feishu.cn/wiki/E5UxwObpMiwyfVk6j0BcsMS7nGc
使用规则：
- 如果当前环境能访问该飞书知识库，就优先把它当作题库和答题思路参考。
- 如果访问失败、没有权限、没有飞书 CLI，或用户不是该知识库成员，不要中断任务；直接说明“默认题库不可用”，然后基于 JD、简历和通用面试逻辑生成备书。
- 公开用户可以提供自己的题库、面经、飞书文档、Notion、Markdown 或截图来替代默认参考库。
- 不要假设默认知识库中的题目都是真题来源；它只提供题目参考、答题思路参考和岗位考察点参考。
核心判断
题目分三类，必须显式标注：
真题参考：来自用户提供的题库或可信原始材料相似题迁移：从同公司/同岗位族/同能力点题目改写JD 推演题：根据 JD 职责、能力要求和业务场景推断
不要把 JD 推演题 写成“真题”。用户可以用它备考，但不能误导为真实面经。
工作流
1. 解析 JD
提取四类信息：
业务场景：岗位服务的业务、用户、产品场景关键任务：岗位入职后要完成的工作能力要求：数据、产品、运营、策略、协作、技术理解等隐含考点：JD 没明说但面试官大概率会追问的点
输出一个岗位能力模型，建议 4-6 个能力维度。
2. 调用题库或知识库
如果用户提供飞书文档：
- 用
lark-doc 读取 outline。
- 按公司名、岗位名、岗位族关键词检索章节。
- 只读取相关章节，不全量塞入上下文。
- 抽取题目、答案框架、追问、岗位关键考察重点。
题库不是题目唯一来源。并不是每道高概率题都必须在题库里找到原题；题库主要提供三种价值：
题目参考：已有题库里出现过的真实问题答题思路参考：题库答案中的拆解方式、指标口径、表达结构岗位考察点参考：同类岗位反复出现的能力要求
如果某题没有在题库中找到原题，但能从 JD 和同类题推导出来，标为 JD 推演题 或 相似题迁移，不要硬标 真题参考。
如果没有题库，说明缺少真题来源，只生成 相似题迁移 和 JD 推演题。
3. 外部参考
需要网上参考时，优先查 GitHub 上的 mock interview / interview prep / question generator 项目，参考它们的产品机制，而不是照搬题目。
重点观察：
- 是否有按岗位生成题目的机制
- 是否有答案评分或反馈
- 是否有追问链路
- 是否区分行为面、业务面、技术理解、案例面
高星只是热度信号，不是采用结论。
4. 生成备书结构
备书文档必须包含：
岗位速读：一句话解释这个岗位到底要解决什么问题能力模型：4-6 个维度，每个维度说明面试官想验证什么高概率题目地图：按能力维度列题，标注来源级别和优先级核心题答案骨架：不是完整背诵稿，而是可替换个人素材的回答结构直接可用参考答案：每道 P0 题给一版 60-120 秒可直接开口练习的回答追问链路：每道核心题至少 2-3 个可能追问评分标准：好答案、普通答案、危险答案的差异个人素材缺口：候选人需要补哪些项目、数据、案例3 天备面计划：按时间安排输入、练习、复盘
5. 答案生成规则
答案不要写成万能空话。核心题必须同时给两种形态：
参考答案规则：
- 不能写成完美但虚假的个人经历；缺少简历材料时，可以构造一个合理的“示例项目故事”，但必须标注为
示例故事，可替换
- 示例故事要有统一业务背景，不要每道题换一个互不相关的案例
- 每段必须带数据：至少包含 2-4 个指标，例如 CTR、转化率、完播率、留存率、满意度、负反馈率、召回率、回答成功率、人工兜底率、ROI
- 如果没有真实数据，用
[你的真实指标] 占位，并给出合理的示例口径，例如“从 12% 提到 16%”“负反馈率下降 18%”
- 语言要像真实面试回答，不要像申论作文或培训资料
- 每段控制在 250-450 中文字，适合用户直接朗读
- 先回答结论，再展开 2-3 个关键点，最后回到岗位匹配
- 对 P0/P1 题都优先给直接可用版；不因题目不是原题就只给骨架
连续追问场景：
- 如果用户要求模拟面试，至少生成 2-3 轮连续对话：
面试官追问 -> 面试者回答 -> 面试官继续追问
- 连续问题必须围绕同一个案例深挖，指标、业务背景和个人角色保持一致
- 每轮回答后补充评分与优化建议，最后给一版满分答案
项目经历类题目优先用：
背景 + 任务 + 存在问题 + 解决方案 + 量化结果
策略/业务题优先用：
目标定义 + 对象拆解 + 指标诊断 + 策略方案 + 验证闭环
AI/产品技术理解题优先用：
用户场景 + 模型能力边界 + 评估指标 + 体验兜底 + 迭代机制
6. 飞书交付
输出优先级：
- 如果用户明确要求飞书交付，并且当前环境可用
lark-cli 且已授权，创建飞书文档。
- 如果飞书不可用、未授权、用户没有配置飞书 CLI，或创建失败，自动生成本地 Markdown 文档，不要阻塞任务。
- 如果用户只想先预览，在对话中输出精简版，并提示可继续生成飞书/Markdown 完整版。
飞书文档标题建议：
<公司><岗位> 面试备书
文档中使用表格承载题目地图、评分标准和素材缺口；使用 callout 写结论和风险提醒。
本地 Markdown 文件建议保存到当前工作目录的 interview-briefs/ 下，文件名使用：
<公司或岗位>-面试备书.md
Markdown 内容也必须保留题目来源标注、直接可用答案、追问链路、评分标准和个人素材缺口。
验证标准
交付前自检：
- 是否用了 JD，而不是泛泛生成题库
- 是否区分题目来源级别
- 是否有追问链路
- 是否有评分标准
- 是否指出候选人素材缺口
- 是否能让用户当天开始练，而不是只读一遍
