gilgameshcc SKILL · 简历整理（v0.1.0）
把本文件整份交给你的 agent 即可——不依赖任何特定 agent 产品，不需要注册命令、不需要放在特定目录、不需要装任何东西。连同 facts.md 一起贴给它，就能开始。
开跑前
要什么
| 要什么 | 缺了会退化成什么 | |
|---|---|---|
| 必需 | facts.md（事实池：经历条目 + 可复用指标 + 口径裁定记录，见 00-workspace） |
拒绝生成，不编。 没有它就没有"单一事实来源"这条纪律的锚点——先要你把经历材料整理成事实池，哪怕散着说的几段话也行，整理是 agent 的工作 |
| 可选 | 目标 JD | 没有就退化成"维护现有版本"，明确告知产出"未针对具体岗位定制" |
| 可选 | jd-triage 的定级结果 |
降级匹配度自检前置——不是跳过，第一步仍然会做，只是从结构化定级降级成常识性粗判（城市/薪资区间是否明显不合），并提示这一步的判断质量打了折扣 |
| 可选 | 现有的三个版本文件（主版本 / 转型版 / 副线版，见下方版本登记表） | 没有就从 facts.md 现场生成"主版本"，作为后续所有定制的起点 |
⭐ 最小可接受形态
一份 facts.md（哪怕只有两三段经历）+ 一句"我想投什么方向"。
不需要三个版本都齐全，不需要 JD，不需要匹配度自检的输入——这些没有都能跑，跑出来的是"未针对具体岗位定制的一份主版本"，明确标注这一点，不假装它已经是投递就绪的成品。
照最小形态给，你会拿到 X，但拿不到 Y
| ✅ X：你会拿到 | ❌ Y：你拿不到 |
|---|---|
| 一份从事实池摘录、按标准结构排好的简历 markdown | 针对具体岗位的定制——没有 JD，四处白名单里的"术语替换成 JD 原词"与"按 JD 强调排序"两条无从执行 |
| 单页校验（工具或 no-code 路径任选一条） | 匹配度自检——没有 jd-triage 的定级结果，判断不了这份材料值不值得投这个岗位，只能靠常识粗判 |
| 一句诚实的标注："这是未定制的主版本" | 一份"看起来已经准备好投递"的成品——这正是这个模块要避免的错觉 |
⛔ 四条禁止（对 agent）
- 不许报错退出。
facts.md格式不规整、经历条目写得很随意，都不是异常，是常态——按能理解的部分先跑，理解不了的部分明确列出来问 - 不许静默编造或润色。
facts.md里没写的经历、没有的数字，不许因为"读起来更完整"就补上；"参与了"不许因为"听起来平淡"就改写成"主导了" - 不许一次只问一个问题挤牙膏。 缺 JD、缺版本、缺匹配度输入——要什么一次列全，不要来回问
- 不许把整理工作推给用户。 用户口述的几段经历，由 agent 整理成结构化的
facts.md草稿存回去；不合格的答复是"请先把经历整理成事实池格式再给我"
第一步 · 匹配度自检前置
在动手定制之前，先判断这个岗位值不值得投。 这一步的位置很关键——它排在"定制"之前，不是之后：先判断，再决定要不要投入定制的时间，而不是先做好一份简历再回头发现根本不该投。
- 有
jd-triage的定级结果时：直接读它的级别。判「不投」的岗位，本模块拒绝为它生成定制稿——不是"生成一份但提醒你别投"，是不生成。这条纪律与"硬性排除条件不可被匹配度换"同源：给一份材料不该投的岗位定制简历，等于在鼓励"反正材料已经准备好了，要不还是投一下试试"这种回退。 - 没有定级结果时：只做常识性粗判（城市/薪资区间是否明显不合、职责描述是否与事实池完全不搭边），拦不住的照常往下走，但要明确提示"这一步没有结构化定级支撑，判断质量打了折扣"。
⛔ 不许靠改简历硬凑匹配度。 如果这份材料"不够贴合"，正确动作是"如实呈现 + 承认差距"或"判定不投"，不是在事实池里找一个能牵强附会上的条目硬塞进去。
第二步 · 版本选择：只维护三个，不许新建第四个
三个版本，各管一类岗位
| 版本 | 覆盖 | 典型场景 |
|---|---|---|
| 主版本 | 与过往经历直接相关的岗位 | 大多数投递会用这个 |
| 转型版 | 目标角色与过往经历有偏移，需要重新组织叙事重点的岗位 | 换赛道、换职能方向 |
| 副线版 | 依托一条与主线不同、但同样真实的经历线 | 比如主线是产品经理，副线是曾经做过的技术方向 |
用 templates/版本登记表.md 追踪这三个版本各自的目标、最后更新时间、对应文件路径。
⭐ 为什么是三个、为什么不许加第四个
版本数本身是一个需要控制的变量，不是越多越贴合越好。 每多一个版本，意味着：
- 事实池更新时，需要同步检查的下游文件多一份——这是事实口径漂移最常见的入口：主版本改了一个表述，转型版没同步改，三个月后两份材料对同一段经历的说法对不上
- 多一个"哪个版本该用在这个岗位上"的判断负担
遇到"三个版本都不太合适"时的正确动作：从三个里选最接近的一个，在第三步的白名单范围内做定制，而不是新建第四个"专门给这类岗位用"的版本。如果连续多次都在同一类岗位上觉得"三个都不合适"，那是一个信号——应该反过来去调整这三个版本的定位划分（比如转型版的目标角色本身该往这类岗位偏移一点），而不是加版本数来适配。
⛔ agent 不许自作主张新建第四个版本文件，哪怕用户说"这个岗位有点特殊"。正确回应是提示上面这条纪律，并从三个里推荐一个起点。
第三步 · 定制：白名单四处，改别的都算违规
用 templates/简历骨架.md 的结构，从选定的版本 + facts.md 出发，只做这四件事：
| # | 允许的动作 | 例 | ⛔ 不许做的相邻动作 |
|---|---|---|---|
| 1 | 优势条目顺序 | JD 强调"跨团队协调"，把对应的优势条目挪到最前 | ⛔ 不许改写优势条目的措辞让它"看起来更贴合" |
| 2 | 术语替换成 JD 原词 | JD 写"智能体"，把简历里的"Agent"换成"智能体" | ⛔ 不许借着"替词"的名义悄悄夸大——把"参与"换成"负责"不是替词，是改事实 |
| 3 | 经历条目排序 | 把与 JD 更相关的经历段落往前排 | ⛔ 不许删掉一段经历里的某个不利细节（"不利"不构成删除理由，"与这个岗位无关"才构成） |
| 4 | [可选] 条目增删 |
facts.md 里标了 [可选] 的经历/项目，可以按相关性决定是否出现在这一版里 |
⛔ 不许增删任何没有标 [可选] 的条目——那些是必须出现的核心事实 |
⚠️ #1 与 #2 在同一处文本上重叠时，#2 优先，但范围严格收窄：如果一条优势条目里恰好出现了待替换的术语（比如优势条目原文是"熟悉 Agent 相关开发"，JD 用词是"智能体"），允许换这一个词本身，但不许借这次改动顺带调整句子结构、语气或强调重点——换完只能是"熟悉智能体相关开发"，不能变成任何读起来"更贴合"的重写。分不清这处改动是"只换了词"还是"顺便润色了"，就按 #1 的禁止项处理，撤销这处改动。
⚠️ [可选] 标记本身也受白名单约束，不是白名单管辖之外的自由地带：[可选] 只能基于**"是否与目标岗位类型相关"**打标，⛔ 不许因为一段经历不利/不好看而标成 [可选]——这是白名单第 3 条"不许因不利删除"这条纪律在更早一步（facts.md 整理阶段）的延伸，标记环节被绕过 ≈ 删除环节被绕过。标记这一步发生在 facts.md 阶段，判据见 00-workspace/templates/facts.md 的对应说明；定制阶段引用某条 [可选] 标记时，如果你自己（或用户）说不清"这条为什么当初被标成可选"，视为标记本身可疑，先回去核实理由，不能直接当作合法的白名单第 4 条操作。
明确不改的东西：数字、事实、公司名、时间。任何一处改动，要能说清它属于上面四条里的哪一条；说不清，就不许做。
用 templates/定制白名单自查表.md 在定稿前把这次做的每一处改动过一遍——这不是形式主义，是这个模块唯一的质量保证机制：没有 evaluator、没有自动化检测能拦住"美化了一句话"，能拦住它的只有执行者自己在收尾前逐条核对。
定制阶段来源标注的特殊规则
见下方"来源标注"一节——定制阶段只允许两档：你给的（来自 facts.md）和"这处改动属于白名单第几条"。一旦出现任何"我推测的"内容，说明单一事实来源已经被破坏，立即回滚这处改动，不是"标注一下就放行"。
第四步 · 单页硬约束 + 视觉复核
光验字数或行数不够，必须看渲染图。 这条纪律专门为一类真实踩过的坑而立：文本量估算合格，但因为某个表格、某段过长的公司名、或字体渲染差异导致视觉上溢出到第二页——只看文本统计发现不了这类问题。
两条路径的具体步骤都收在 templates/单页校验checklist.md 里，走完这一步照着它逐项过一遍。
路径一：工具校验（tools/md2pdf）
node tools/md2pdf/md2pdf.js <定制稿.md> <输出.pdf>
- 退出码
0= 单页通过；1= 溢出到多页（脚本会报出实际页数）；2= 环境问题（找不到 Chrome，或输入文件有误） - 溢出时回到第三步精简——只能用白名单四条里"删条目 / 调顺序"这两条来减少内容，⛔ 不许靠缩小字号、压窄行距这类排版手段硬塞进一页（那会让简历难以阅读，牺牲的是可读性去换页数，本末倒置）
- 环境问题（退出码
2）不是失败，直接走路径二
路径二：no-code 校验法（与路径一效力相同，不是降级方案）
没有 Chrome、不想装任何东西的人，走这条：
- 行数与字符密度估算：单页 A4 在常规简历字号（约 10-11pt）下，通常能容纳约 45-55 行正文（含空行与分节间距）。数一下定制稿的总行数（含每条 bullet 单独算一行），明显超出这个区间就大概率溢出，先按第三步精简一轮再往下走
- 浏览器打印预览人工确认：把定制稿转成 Word / Google Docs / 任何文本编辑器能"打印预览"的格式（或者直接把内容贴进一个网页文本框用浏览器打印功能预览），用系统的打印预览功能看渲染后的分页——这一步不可省，第 1 步的估算只是筛掉明显超标的情况，真正的判定标准是这一步的肉眼确认
- 把这次校验的结论（估算行数 + 打印预览确认单页/未单页）记进定制稿末尾的一行备注，供下次迭代时参考
⛔ 两条路径都必须做"确认单页"这一步，不许只做估算就当完成。 估算是筛查，不是验收。
第五步 · 输出与台账登记
一次定制完成后：
- 定制稿存为 markdown（文件名规则见
00-workspace工作区骨架） - 单页校验通过的 PDF（工具路径）或校验记录（no-code 路径）
- 在
ledger.md补一行：日期 · 公司 · 岗位 · 用的版本（主版本 / 转型版 / 副线版）· 匹配度自检结论
⛔ 判定「不投」的也要留痕——第一步如果判定不投，同样在 ledger.md 记一行（版本栏留空，状态写"未定制：匹配度不达标"），这类记录是后续校准匹配度阈值的样本，不能因为没生成简历就当作没发生过。
来源标注
本模块的来源标注比其他模块更简单，因为它只消费一个上游文件：
| 标注 | 什么时候用 |
|---|---|
你给的 |
facts.md 里的一切——经历、数字、口径。定制阶段涉及的每一条事实性内容都必须是这一档 |
JD 原词 |
术语替换动作里使用的、来自 JD 原文的词——这不是"你给的"也不是"我推测的"，是第三个特殊来源，仅限白名单第 2 条使用 |
⛔ 我推测的 |
定制阶段不允许出现这一档。 一旦出现（比如"这段经历应该也涉及了跨团队协调"），说明正在编造或过度诠释，立即回滚这处改动，不是标注后放行 |
这与其他模块的"三档"体系不同——
interview-strategic-assessment、jd-triage、05-offer里我推测的是合法的一档（只是不能单独触发不可逆动作）；本模块里它从一开始就不合法，因为本模块处理的是"关于你自己"的事实，没有"推测"的空间——你自己的经历不需要被推测，只需要被准确摘录。
不对劲的时候
症状 → 最可能原因 → 你下一句该说什么
| 症状 | 最可能原因 | 你下一句该说什么 |
|---|---|---|
定制稿里出现了 facts.md 里没有的经历或数字 |
单一事实来源被破坏——agent 在"让简历更贴合"的压力下编造或过度诠释了 | "这条经历/数字不在事实池里，删掉；如果确实发生过但没记录，先补进 facts.md，走完确认流程再引用" |
| 同一段经历在不同版本里的表述对不上 | 版本之间没有对齐到同一份 facts.md，或某个版本改的是产物而不是源头 |
"检查这段经历在 facts.md 里的原始表述，所有版本都必须能追回到同一处" |
| 它想新建一个"专门给这类岗位用"的第四个版本 | 版本收敛纪律没被遵守 | "从三个版本里选最接近的一个，在白名单范围内定制；如果这类岗位反复出现，我们回头调整三个版本本身的定位，不是加版本" |
| 它说匹配度不够，但还是生成了一份定制稿 | 第一步的匹配度自检前置没有真正生效——判「不投」应该拒绝生成，不是生成后加一句提醒 | "匹配度不达标的岗位不该有定制稿，重新走一遍第一步，判不投就到此为止，只在 ledger 里留一行" |
| 单页校验只做了行数估算就说通过了 | no-code 路径的两步被当成了一步——估算只是筛查，不是验收 | "这只是估算，还没做浏览器打印预览人工确认，那一步不能省" |
tools/md2pdf 报错，它就停下来等你处理环境问题 |
没有意识到 no-code 路径是平级方案，不是工具失败后的补救 | "工具路径走不通就直接切 no-code 路径，两条路效力相同，不用先修好环境" |
三级自救阶梯
不要一出问题就把活推回给人。
| 级 | 什么时候到这一级 | 该做什么 | ⛔ 不该做什么 |
|---|---|---|---|
| L1 有现成的，直接走 | facts.md 格式规整、JD 齐全、版本清楚该用哪个 |
按规则执行，不问 | 不为"确认一下用哪个版本"打断用户——三问表里已经给了判据 |
| L2 没现成的，自己走通 + ⭐ 沉淀 | 用户口述的经历需要整理成 facts.md；三个版本都不太合适；facts.md 格式很随意 |
自己整理、自己按"最接近"原则选版本、自己把散乱格式理成结构化表；走通之后写回去——整理出的 facts.md 存回去，版本选择的判断记进 版本登记表.md |
⛔ 不把"这次绕过去了"只留在会话里；⛔ 不因为"三个都不太合适"就自作主张开第四个版本——这一条没有 L2 自主权，直接进 L3 问用户要不要调整版本划分本身 |
| L3 实在不行，才回报人 | L2 也走不通；或触及只有用户本人知道的事实（这条经历的真实细节、这个数字的真实口径） | 输出症状 + 已经试过什么 + 建议你做什么 | ⛔ 不输出裸错误；⛔ 不替用户编一个"看起来合理"的数字去填空 |
变更日志
v0.1.0（首发）
确立匹配度自检前置于定制之前，判「不投」的岗位拒绝生成定制稿 · 版本收敛为三个（主版本 / 转型版 / 副线版）并写明"三个都不合适"时的正确动作是调整版本定位而非新建 · 定制白名单四处，逐条给出"允许的动作"与"不许做的相邻动作"对照 · 定制阶段来源标注收窄为两档（你给的 / JD 原词），我推测的 从一开始就不合法 · 单页校验双路径（tools/md2pdf 工具路径 + no-code 路径），两条路径明确效力相同、都要求"确认单页"这一步不可省。