| name | resume-jd-tailor |
| description | 根据目标岗位 JD、候选人原始简历/低颗粒经历、求职方向和可选参考知识库，生成岗位定制简历改写方案。适用于用户说“根据这个 JD 改简历”“这段经历能投什么岗位”“把校园/社团/项目经历写成运营/产品/市场简历”“生成匹配岗位的简历 bullet”“调用简历知识库优化简历”等场景。输出必须包含岗位匹配判断、经历挖掘、改写策略、可投递简历 bullet、数据占位/证据缺口、JD 关键词覆盖和飞书/Markdown 交付。 |
Resume JD Tailor
把低颗粒、弱表达、跨方向的经历改写成贴合目标 JD 的简历材料。目标不是把经历“包装得更厉害”，而是把用户真实做过的事翻译成目标岗位能读懂的证据。
输入
尽量收集以下信息；缺失时先合理假设并标注缺口：
- 目标岗位 JD、岗位链接或截图
- 用户原始简历、经历片段、项目描述、自我介绍
- 目标方向：产品、运营、市场、商业化、数据、AI 产品等；如果没有目标方向，先做方向匹配
- 用户已有简历知识库、优秀简历样例、飞书文档、Notion、Markdown 或截图
- 输出目标：飞书文档、本地 Markdown、简历 bullet、完整简历段落、投递版一页简历
默认参考库
默认可参考用户私域里的简历写作知识库：
https://gte09oerz5.feishu.cn/wiki/HDbTwrxIoinTQqkaGIvcVheznUj
使用规则：
- 如果当前环境能访问该飞书知识库，就优先参考其简历写作思路、模块结构和优秀样例。
- 如果访问失败、没有权限、没有飞书 CLI，或用户不是该知识库成员，不要中断任务；直接说明“默认简历知识库不可用”，然后基于 JD、用户经历和通用简历逻辑生成。
- 公开用户可以提供自己的简历知识库、优秀简历、飞书文档、Notion、Markdown 或截图来替代默认参考库。
- 不要把默认知识库内容原样复制到输出；它只提供写法参考、岗位化表达参考和结构参考。
核心原则
简历改写分四类信息，必须显式区分：
用户事实：用户原文明确提供的信息合理转译：把用户事实换成目标岗位语言，不改变事实待确认补充：需要用户补数据、规模、动作细节、结果示例口径：为了帮助用户理解而给出的示例指标或表达，不能当作真实经历
不要把 待确认补充 或 示例口径 写成已经发生的事实。简历可以更会表达，但不能替用户编经历。
工作流
1. 解析 JD
提取四类信息：
业务场景：岗位服务的用户、业务、产品、渠道或增长场景关键任务：入职后要承担的动作，例如拉新、留存、转化、内容、策略、数据、项目推进能力要求：岗位显性要求和隐性能力，例如用户洞察、数据分析、活动策划、跨团队协作关键词：简历需要覆盖的岗位词、业务词、能力词、工具词
输出 4-6 个岗位能力维度，并给每个维度标注简历证据需求。
2. 解析用户经历
把原始经历拆成证据库存：
- 做过什么：职责、任务、项目、活动、社群、内容、产品功能、调研
- 面向谁：用户、社员、客户、商家、创作者、达人、学生、企业
- 为了什么：增长、留存、活跃、转化、满意度、效率、质量、成本
- 怎么做：调研、分层、策略、流程、内容、活动、工具、协作
- 有什么结果：人数、频次、转化、留存、曝光、效率、满意度、收入
- 缺什么：用户没有给出的数据、背景、角色边界、证明材料
如果用户只给低颗粒经历，例如“电竞社社员，负责日常事务”，先不要直接改写。先做方向匹配。
3. 方向匹配
当目标岗位不明确时，先给 3-5 个可投方向，并打分：
匹配分：原经历和岗位能力的重合度可写证据：已有经历能支持哪些 bullet缺口：缺少哪些数据、项目深度或岗位关键词优先建议：先投什么方向，为什么
例如电竞社经历可以往用户运营、社群运营、活动运营、内容运营、市场活动等方向转译，但要分别说明证据强弱。
4. 调用知识库或外部参考
如果用户提供飞书文档或默认简历知识库可访问：
- 用
lark-doc 读取 outline。
- 按岗位方向、经历类型、模块名检索相关章节，例如“校园经历”“项目经历”“转行”“运营”“市场”“产品”。
- 只读取相关章节，不全量塞入上下文。
- 抽取写法规则、结构参考、关键词表达和样例模式。
如果本地/私域材料不足以支撑高质量改写，或用户要求进一步参考外部项目，可以查 GitHub 上的 resume / cv / resume tailoring / ATS resume / job matching 项目。参考它们的产品机制，而不是照搬简历内容。
重点观察：
- 是否有 JD 关键词抽取
- 是否有简历与 JD 匹配度评分
- 是否有 ATS 关键词覆盖
- 是否有 bullet 改写评分
- 是否区分事实、推断和待补充数据
高星只是热度信号，不是采用结论。
5. 经历岗位化改写
对低颗粒经历，不要用“丰富版/精修版”这种让用户二次判断的结构。直接输出三层内容：
可切入岗位：这段经历可以往哪些岗位/岗位族靠，按推荐程度排序。对应岗位怎么写：每个岗位应该抓哪类问题、动作和指标。直接可复制版本：给用户一版可以直接放进简历的改写稿，保留 [待补充] 数据占位。
每个可切入岗位的写法包含：
- 背景/问题：当时存在什么问题，或为了达成什么目标
- 调研/诊断：用什么方式确认问题，例如问卷、访谈、数据观察、用户反馈、复盘
- 动作拆解：从哪些维度做了什么，例如用户分层、内容供给、活动流程、社群规范、转化链路
- 结果指标：带来什么变化；真实数据缺失时用
[待补充真实数据] 和示例口径
直接可复制版本要求：
- 优先给段落式/长 bullet，确保用户能直接复制
- 如果存在多个可切入方向，用表格对比呈现，不要只用分散段落；表格至少包含“切入方向 / 无真实数据占位版 / 逻辑自洽示例数据版 / 使用建议”
- 一段经历建议给 3 个方向版本：用户运营、社群运营、活动运营；如果 JD 明确，可以只给最相关的 1-2 个版本
- 每个版本都必须包含目标、调研/诊断、动作、结果
- 优先覆盖 JD 关键词
- 数据真实优先；无真实数据时保留占位，不编造成果
- 必须额外给一版“逻辑自洽示例数据版”，用来示范数据应该如何填；示例数据必须前后一致、符合小型校园社团规模，并明确标注为示例口径，需用户确认后才能放入正式简历
- 不要只给抽象建议，必须给最终可用文本
推荐表达骨架：
[岗位方向]：围绕 [目标/问题]，通过 [调研/诊断方式] 识别 [关键问题]，从 [动作维度1/2/3] 推动 [具体动作]，最终实现 [指标结果/待补充指标]。
6. 输出结构
默认输出一份“岗位定制简历改写文档”，必须包含：
岗位速读：一句话说明这个 JD 最想要什么人匹配度判断：用户经历与目标岗位的匹配分、优势、风险JD 关键词地图：岗位关键词、简历覆盖状态、待补关键词改写策略：每段经历应该往哪个岗位能力上靠可切入岗位与写法：列出可切入岗位，以及每个岗位如果要写经历应该怎么写直接可复制改写版本：给出可以直接放进简历的最终文本，必要时提供 2-3 个岗位方向版本一页简历排序建议：哪些经历放前面，哪些弱化素材补齐清单：需要用户补的真实数据、证明材料、项目细节面试复用提示：这段简历后续面试可能怎么被追问
7. 飞书交付
输出优先级：
- 如果用户明确要求飞书交付，并且当前环境可用
lark-cli 且已授权，必须使用 lark-cli docs +create --api-version v2 创建飞书文档，默认 doc-format 走 XML。不要用 Markdown 导入或把 Markdown 文件上传成飞书文档。
- 只有在飞书不可用、未授权、用户没有配置飞书 CLI，或创建失败时，才自动生成本地 Markdown 文档兜底，不要阻塞任务。
- 如果用户只想先预览，在对话中输出精简版，并提示可继续生成飞书/Markdown 完整版。
飞书文档标题建议：
<公司或岗位> 简历定制改写
本地 Markdown 文件建议保存到当前工作目录的 resume-tailors/ 下，文件名使用：
<公司或岗位>-简历定制改写.md
飞书 XML 文档至少包含：开头 callout、岗位速读、匹配度判断、JD 关键词地图、可切入岗位与写法、直接可复制改写版本、素材补齐清单和面试复用提示。
质量检查
交付前自检：
- 是否用了 JD，而不是泛泛润色简历
- 是否先判断方向和匹配度
- 是否区分用户事实、合理转译、待确认补充、示例口径
- 是否把低颗粒经历拆成问题、目标、动作、数据
- 是否输出了可直接复制进简历的最终改写版本，而不只是分析和建议
- 是否有 JD 关键词覆盖检查
- 是否列出素材缺口，避免用户拿虚假数据投递
- 是否能自然衔接到后续
interview-prep-brief 做面试准备
