resume-jd-tailor

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. 调用知识库或外部参考

如果用户提供飞书文档或默认简历知识库可访问：

1. 用 lark-doc 读取 outline。
2. 按岗位方向、经历类型、模块名检索相关章节，例如“校园经历”“项目经历”“转行”“运营”“市场”“产品”。
3. 只读取相关章节，不全量塞入上下文。
4. 抽取写法规则、结构参考、关键词表达和样例模式。

如果本地/私域材料不足以支撑高质量改写，或用户要求进一步参考外部项目，可以查 GitHub 上的 resume / cv / resume tailoring / ATS resume / job matching 项目。参考它们的产品机制，而不是照搬简历内容。

重点观察：

• 是否有 JD 关键词抽取
• 是否有简历与 JD 匹配度评分
• 是否有 ATS 关键词覆盖
• 是否有 bullet 改写评分
• 是否区分事实、推断和待补充数据

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

5. 经历岗位化改写

对低颗粒经历，不要用“丰富版/精修版”这种让用户二次判断的结构。直接输出三层内容：

1. 可切入岗位：这段经历可以往哪些岗位/岗位族靠，按推荐程度排序。
2. 对应岗位怎么写：每个岗位应该抓哪类问题、动作和指标。
3. 直接可复制版本：给用户一版可以直接放进简历的改写稿，保留 [待补充] 数据占位。

每个可切入岗位的写法包含：

• 背景/问题：当时存在什么问题，或为了达成什么目标
• 调研/诊断：用什么方式确认问题，例如问卷、访谈、数据观察、用户反馈、复盘
• 动作拆解：从哪些维度做了什么，例如用户分层、内容供给、活动流程、社群规范、转化链路
• 结果指标：带来什么变化；真实数据缺失时用 [待补充真实数据] 和示例口径

直接可复制版本要求：

• 优先给段落式/长 bullet，确保用户能直接复制
• 如果存在多个可切入方向，用表格对比呈现，不要只用分散段落；表格至少包含“切入方向 / 无真实数据占位版 / 逻辑自洽示例数据版 / 使用建议”
• 一段经历建议给 3 个方向版本：用户运营、社群运营、活动运营；如果 JD 明确，可以只给最相关的 1-2 个版本
• 每个版本都必须包含目标、调研/诊断、动作、结果
• 优先覆盖 JD 关键词
• 数据真实优先；无真实数据时保留占位，不编造成果
• 必须额外给一版“逻辑自洽示例数据版”，用来示范数据应该如何填；示例数据必须前后一致、符合小型校园社团规模，并明确标注为示例口径，需用户确认后才能放入正式简历
• 不要只给抽象建议，必须给最终可用文本

推荐表达骨架：

[岗位方向]：围绕 [目标/问题]，通过 [调研/诊断方式] 识别 [关键问题]，从 [动作维度1/2/3] 推动 [具体动作]，最终实现 [指标结果/待补充指标]。

6. 输出结构

默认输出一份“岗位定制简历改写文档”，必须包含：

1. 岗位速读：一句话说明这个 JD 最想要什么人
2. 匹配度判断：用户经历与目标岗位的匹配分、优势、风险
3. JD 关键词地图：岗位关键词、简历覆盖状态、待补关键词
4. 改写策略：每段经历应该往哪个岗位能力上靠
5. 可切入岗位与写法：列出可切入岗位，以及每个岗位如果要写经历应该怎么写
6. 直接可复制改写版本：给出可以直接放进简历的最终文本，必要时提供 2-3 个岗位方向版本
7. 一页简历排序建议：哪些经历放前面，哪些弱化
8. 素材补齐清单：需要用户补的真实数据、证明材料、项目细节
9. 面试复用提示：这段简历后续面试可能怎么被追问

7. 飞书交付

输出优先级：

1. 如果用户明确要求飞书交付，并且当前环境可用 lark-cli 且已授权，必须使用 lark-cli docs +create --api-version v2 创建飞书文档，默认 doc-format 走 XML。不要用 Markdown 导入或把 Markdown 文件上传成飞书文档。
2. 只有在飞书不可用、未授权、用户没有配置飞书 CLI，或创建失败时，才自动生成本地 Markdown 文档兜底，不要阻塞任务。
3. 如果用户只想先预览，在对话中输出精简版，并提示可继续生成飞书/Markdown 完整版。

飞书文档标题建议：

<公司或岗位> 简历定制改写

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

<公司或岗位>-简历定制改写.md

飞书 XML 文档至少包含：开头 callout、岗位速读、匹配度判断、JD 关键词地图、可切入岗位与写法、直接可复制改写版本、素材补齐清单和面试复用提示。

质量检查

交付前自检：

• 是否用了 JD，而不是泛泛润色简历
• 是否先判断方向和匹配度
• 是否区分用户事实、合理转译、待确认补充、示例口径
• 是否把低颗粒经历拆成问题、目标、动作、数据
• 是否输出了可直接复制进简历的最终改写版本，而不只是分析和建议
• 是否有 JD 关键词覆盖检查
• 是否列出素材缺口，避免用户拿虚假数据投递
• 是否能自然衔接到后续 interview-prep-brief 做面试准备

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

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

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

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