interview-prep-brief

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. 调用题库或知识库

如果用户提供飞书文档：

1. 用 lark-doc 读取 outline。
2. 按公司名、岗位名、岗位族关键词检索章节。
3. 只读取相关章节，不全量塞入上下文。
4. 抽取题目、答案框架、追问、岗位关键考察重点。

题库不是题目唯一来源。并不是每道高概率题都必须在题库里找到原题；题库主要提供三种价值：

• 题目参考：已有题库里出现过的真实问题
• 答题思路参考：题库答案中的拆解方式、指标口径、表达结构
• 岗位考察点参考：同类岗位反复出现的能力要求

如果某题没有在题库中找到原题，但能从 JD 和同类题推导出来，标为 JD 推演题 或 相似题迁移，不要硬标 真题参考。

如果没有题库，说明缺少真题来源，只生成 相似题迁移 和 JD 推演题。

3. 外部参考

需要网上参考时，优先查 GitHub 上的 mock interview / interview prep / question generator 项目，参考它们的产品机制，而不是照搬题目。

重点观察：

• 是否有按岗位生成题目的机制
• 是否有答案评分或反馈
• 是否有追问链路
• 是否区分行为面、业务面、技术理解、案例面

高星只是热度信号，不是采用结论。

4. 生成备书结构

备书文档必须包含：

1. 岗位速读：一句话解释这个岗位到底要解决什么问题
2. 能力模型：4-6 个维度，每个维度说明面试官想验证什么
3. 高概率题目地图：按能力维度列题，标注来源级别和优先级
4. 核心题答案骨架：不是完整背诵稿，而是可替换个人素材的回答结构
5. 直接可用参考答案：每道 P0 题给一版 60-120 秒可直接开口练习的回答
6. 追问链路：每道核心题至少 2-3 个可能追问
7. 评分标准：好答案、普通答案、危险答案的差异
8. 个人素材缺口：候选人需要补哪些项目、数据、案例
9. 3 天备面计划：按时间安排输入、练习、复盘

5. 答案生成规则

答案不要写成万能空话。核心题必须同时给两种形态：

• 答案骨架：告诉用户如何替换成自己的经历

• 参考答案：给一段可以直接开口练的 60-120 秒示范稿

• 面试官真实考察点

• 推荐回答结构

• 可以套用的个人素材位置

• 关键指标或业务口径

• 常见追问

• 避坑提醒

参考答案规则：

• 不能写成完美但虚假的个人经历；缺少简历材料时，可以构造一个合理的“示例项目故事”，但必须标注为 示例故事，可替换
• 示例故事要有统一业务背景，不要每道题换一个互不相关的案例
• 每段必须带数据：至少包含 2-4 个指标，例如 CTR、转化率、完播率、留存率、满意度、负反馈率、召回率、回答成功率、人工兜底率、ROI
• 如果没有真实数据，用 [你的真实指标] 占位，并给出合理的示例口径，例如“从 12% 提到 16%”“负反馈率下降 18%”
• 语言要像真实面试回答，不要像申论作文或培训资料
• 每段控制在 250-450 中文字，适合用户直接朗读
• 先回答结论，再展开 2-3 个关键点，最后回到岗位匹配
• 对 P0/P1 题都优先给直接可用版；不因题目不是原题就只给骨架

连续追问场景：

• 如果用户要求模拟面试，至少生成 2-3 轮连续对话：面试官追问 -> 面试者回答 -> 面试官继续追问
• 连续问题必须围绕同一个案例深挖，指标、业务背景和个人角色保持一致
• 每轮回答后补充评分与优化建议，最后给一版满分答案

项目经历类题目优先用：

背景 + 任务 + 存在问题 + 解决方案 + 量化结果

策略/业务题优先用：

目标定义 + 对象拆解 + 指标诊断 + 策略方案 + 验证闭环

AI/产品技术理解题优先用：

用户场景 + 模型能力边界 + 评估指标 + 体验兜底 + 迭代机制

6. 飞书交付

输出优先级：

1. 如果用户明确要求飞书交付，并且当前环境可用 lark-cli 且已授权，创建飞书文档。
2. 如果飞书不可用、未授权、用户没有配置飞书 CLI，或创建失败，自动生成本地 Markdown 文档，不要阻塞任务。
3. 如果用户只想先预览，在对话中输出精简版，并提示可继续生成飞书/Markdown 完整版。

飞书文档标题建议：

<公司><岗位> 面试备书

文档中使用表格承载题目地图、评分标准和素材缺口；使用 callout 写结论和风险提醒。

本地 Markdown 文件建议保存到当前工作目录的 interview-briefs/ 下，文件名使用：

<公司或岗位>-面试备书.md

Markdown 内容也必须保留题目来源标注、直接可用答案、追问链路、评分标准和个人素材缺口。

验证标准

交付前自检：

• 是否用了 JD，而不是泛泛生成题库
• 是否区分题目来源级别
• 是否有追问链路
• 是否有评分标准
• 是否指出候选人素材缺口
• 是否能让用户当天开始练，而不是只读一遍

材料使用说明（输出文档末尾必带）

在交付文档的最后只保留一张“材料使用说明”表；表格后不再增加知识库提示、营销文案或额外解释。

材料层级	本次是否使用	作用
用户简历、项目、投递记录、面试记录等本人确认材料	按实际填写“已使用”或“未提供”	已使用时说明它决定了哪些事实、优先级或下一步；未提供时说明本次结论的边界。
目标岗位 JD、岗位链接或截图	按实际填写“已使用”或“未提供”	已使用时说明它如何影响岗位判断、材料定制或面试重点；未提供时说明本次不做岗位专属判断。
互联网求职知识库	默认“未调用”	无知识库权限，本次仍可基于用户提供的材料完成完整输出；如需进一步按目标行业、岗位能力和真实案例校准表达，可引入高质量知识库语料提升输出效果。

如果用户明确授权并且实际调用了互联网求职知识库，将最后一行改为“已调用”，并如实写清调用了哪类内容、如何帮助校准岗位语言、案例口径或追问重点；不得展示或复述知识库原文。