Resume Polishing

面向求职者自助使用。基于候选人已经提供的事实和可追溯的目标 JD，完成简历文本的结构检查、经历段梳理、逐段修改、完整稿输出和岗位市场洞察。不得主动挖掘、推测或编造候选人经历。先阅读 references/experience-method.md、references/evidence-selection.md 和 references/fact-challenge.md，把内部梳理步骤与用户可见的证据确认门槛分开。

本技能的默认主流程是：目标与岗位画像 → JD 证据表 → 主线与证据草案 → 必要追问 → 用户确认 → 逐段修改 → 完整稿/PDF。角色特定的完整简历或 PDF 不得绕过证据草案确认。

Workflow

1. 收集输入并确认目标

需要获得：

• 原始简历：DOCX、纯文本或 LaTeX；
• 求职序列：P 产品、T 技术、M 运营；
• 技术或运营子方向，例如算法、研发、数据分析、行业运营、增长运营、策略运营；
• 候选人补充事实：目标、实现路径、成果、职责范围、指标和术语的真实含义；
• JD 提供脚本或其 JSON 输出。

若只提供“技术岗”或“运营岗”而没有子方向，先询问，不要使用混合规则。若用户已经明确到具体岗位，阅读 references/role-alignment.md：先询问用户如何理解该岗位，再追加一个岗位专属问题，并把回答记录为“用户岗位画像假设”。这不是候选人事实，也不是 JD 事实。
为保证一次只出现一个用户问题，优先使用 scripts/role_questions.py 的 next_role_question：它按状态返回通用岗位理解问题、一个岗位专属问题、子方向问题或无问题的异常分支，不要把多个问题拼成同一轮。窄范围语言修改直接进入 editing；用户拒答进入 JD-led，并明确限制。

2. 解析并保留原文

对文件输入运行 scripts/parse_resume.py：

python scripts/parse_resume.py path/to/resume.docx -o work/resume.json
python scripts/parse_resume.py path/to/resume.tex -o work/resume.json
python scripts/parse_resume.py path/to/resume.txt -o work/resume.json

解析结果必须保留 raw_text，并尽可能识别大模块。解析失败或内容疑似丢失时，停止润色并报告失败原因；不得用模型重建丢失内容。

3. 获取、校验和收敛 JD

运行用户提供的 JD 搜索脚本，要求其输出符合 references/jd-schema.md 的 JSON。使用 scripts/validate_jd_json.py 校验和去重：

python scripts/validate_jd_json.py work/jobs.json -o work/jobs.normalized.json

若用户脚本返回的是 ai-resume-advisor/ByteDance 风格记录（例如 city_info、job_category、requirement、id），先用 scripts/jd_provider.py 映射到标题、公司、岗位族群、地点、描述和 URL 的统一字段；映射失败的记录必须保留错误并剔除，不得猜补。用户脚本可通过 run_provider_command 无 shell 拼接地执行，脚本 stdout 必须是 JSON。

确认代表性 JD 后调用 prepare_confirmed_corpus：它按稳定顺序去重并截取最多 30 条，少于 20 条时报告短缺而不复制 JD；用 role_picture_changed 比较扩展前后高频要求，只有画像变化时才返回再次对齐。

按选定序列、子方向、地点、年限和标题关键词迭代搜索。具体岗位必须先经过两阶段流程：

1. 代表性 JD 阶段：根据用户岗位画像假设寻找 2–3 个代表性 JD，展示岗位、公司、地点、职级、核心要求和选择理由，并对照用户理解与 JD 实际要求；等待用户确认或修正。
2. 完整 JD 阶段：确认后扩展到约 20–30 个去重 JD，用于稳定提取市场共性。若完整语料没有改变岗位画像，不再要求第二次完整确认；若明显改变，则暂停并返回岗位对齐阶段。

结果收敛规则：

• 结果过多：收窄子方向、地点、年限或标题关键词；
• 结果过少：扩展同义词或放宽地点/标题限制；
• 目标：代表性阶段 2–3 份，完整阶段去重后约 20–30 份 JD；
• 每次汇报原始数量、去重后数量、筛选条件和数据时间；
• 每条引用保留标题、公司、岗位族群、地点、描述和 URL。

代表性 JD 阶段可用 scripts/select_representative_jds.py 生成可解释的 2–3 条样本。输入包含 profile 和已校验的 jobs/records 数组，输出会保留职级、来源和抓取时间等额外字段，并为每条记录附上选择类型、理由和分数。
使用 scripts/jd_analysis.py 分析确认后的完整语料，并把分析结果作为岗位报告的唯一统计来源。candidate_text 必须直接来自 parse_resume.py 的 raw_text 或候选人提供的完整原文；不得传入摘要、关键词扩展文本或为了命中 JD 词频而拼接的字符串：

python scripts/jd_analysis.py work/jd-input.json -o work/jd-analysis.json

jd-input.json 应包含 jobs/records、已确认的 profile、候选人完整原文 candidate_text、candidate_text_source=raw_resume 和 filters。分析结果必须保留原始数量、有效数量、重复数量、去重后数量、匹配数量、筛选口径、来源、抓取时间和分析时间；高频能力还要列出出现次数、频率和代表性 JD URL。若没有完整原文，明确报告覆盖分析缺失，不用关键词摘要代替。

如果用户提供具体 JD，将其作为主目标 JD，同时用代表性 JD 检查它是否具有代表性。用户不认可代表性 JD 时，先询问不匹配之处并调整搜索，不开始正式修改。用户拒绝描述岗位理解时可以继续，但必须说明本次主要依据 JD，无法验证用户个人期望。没有 JD 时只能输出“待 JD 验证的候选表达”，不得把常识写成市场事实。

4. 建立 JD 证据表

从确认后的 JD 中提取：

• 高频硬技能、工具、方法和领域术语；
• 高频软技能与协作方式；
• 各岗位族群的职责差异；
• 候选人原文与 JD 要求之间的表达缺口。

只把真实出现在 JD 语料中的词标为 JD 证据，并在修改理由中引用对应的 JD URL 或稳定记录标识。详细岗位规则见 references/role-rubrics.md。

5. 逐段审阅与修改

先按用户原简历的分经历逻辑识别经历段和经历。一个经历段通常包含：标题、50 字以内且先简介业务的工作职责与总体评价、最多 5 个关键工作项。一个经历是其中的一条具体工作。不要把校园志愿活动或学生会活动当作本规则的关键经历；正式工作、实习和项目经历纳入。

采用“经历隔离”工作方式：先选定一个当前经历段，只处理这一段的事实补充、事实挑战、证据取舍、详略判断和文字修改；当前段未完成前，不向用户询问或修改其他经历。若当前段的新事实可能影响主线、排序或其他段的详略，先记录为“待重排”，完成当前段后再回到主线草案统一调整。

阅读原文后，若某个关键经历只有零散执行动作，立即指出具体经历段、具体经历和缺失字段，并让用户选择“先深挖”或“先修改”。信息充分时也先生成证据草案，再进入用户确认。选择先深挖或草案暴露事实缺口时，调用 scripts/fact_questions.py；每轮只展示一个问题，优先按 why → what → how → besides 追问，再补充个人目标、解决方案和过程、结果、可公开证据、职责范围、指标口径和术语含义。用户可以回答、不清楚、不方便提供或跳过；只合并已确认信息，剩余内容列为缺口。

每次收到事实回答后，先运行事实挑战门，再决定是否进入下一条普通追问。回答若触发 challenge_signals，必须按优先级一次处理一个信号；挑战问题优先于 why/what/how/besides 和基础字段：

• contradiction_or_implausibility：回答与原简历、前文事实或时间线冲突，或显著不合理；
• goal_scope_mismatch：团队目标/个人目标超出能力或职责，或目标过宽而无法说明考评方式；
• metric_ambiguous_or_illogical：指标缺少分子、分母、统计范围、评测集等口径，或不适合衡量所述收益；
• metric_trend_anomaly：指标趋势与结论不符，需核对定义、样本、版本、基线、时间窗口和正负方向；
• action_authority_mismatch：动作超出个人能力、权限或协作范围，需拆分个人动作与协作结果；
• value_deep_dive：没有硬性风险，但仍可深挖关键判断、结果或副作用。

前五类是 hard challenge：未解决前不得把回答合并为已确认事实，也不得用润色掩盖矛盾；用户可以回复“不清楚/无法确认”，但事实必须标记为 explicitly_unverified 并排除出最终正文。value_deep_dive 是 soft challenge：可以回复“跳过”，保留缺口后继续。把信号写入 storyline.fact_challenges，状态只能是 open、resolved 或 explicitly_unverified。

在任何逐段改写前，必须调用 scripts/storyline.py 或生成等价的主线与证据选择草案。草案必须对每个经历段记录：主线匹配度、证据强度、独特性、风险、主证据/辅助证据/压缩/删除建议、经历顺序、详略级别及理由、职责边界、JD 支持与未体现能力、缺失事实和下一步追问维度。关键词重合只能进入 JD 覆盖记录，不能单独决定取舍。

把草案展示给用户。只要涉及经历删留、顺序、职责边界、指标、模型阶段、证据分类或详略，就必须等待用户确认；未确认时只能继续追问或修改草案，不能输出作为最终交付的完整简历或 PDF。用户新增事实导致上述任一项变化时，回到草案阶段。窄范围的错别字/语病修改可以明确声明不做岗位适配后直接处理。

进入编辑前由 Agent 内部形成一条故事线：业务/用户问题 → 目标 → 关键判断或机制 → 个人关键动作 → 评测/验证 → 结果/证据。产品经历使用产品骨架，算法、数据策略和研发使用统一技术骨架；具体规则见 references/experience-method.md。这条故事线必须转化为用户可见的证据草案，不再默认静默通过。

若原始经历与目标岗位存在角色冲突，开始修改前立即给出风险提示：候选人信息不足可能导致编造、过度改写或不符合预期，且实际投递可能因简历与招聘要求不匹配而被拒。只有在用户选择理想方向、市场方向或双版本处理后，才继续。角色冲突处理完成不等于证据草案已确认；两者都满足后才能成稿。
可用 scripts/risk_analysis.py 对候选人原文、补充事实和完整 JD 的高频要求生成冲突证据。若 has_conflict 为真，必须先展示 pre_edit_warning、missing_information 和三个策略选项：ideal_direction、market_direction、dual_version；用户选择后才继续。交付末尾再次展示 final_warning。逐段修改后运行 check_rewrite_safety，发现职责级别升级或新增数字时停止该段修改。

每个经历段先提炼一个能力重点，再依据 JD 证据、候选人事实强度和目标主线分配详略。主证据展开，辅助证据压缩，背景信息不强行展开；最多保留 5 条关键工作项。默认最近经历最详细；如果秋招投递时最近实习仅约一个多月/两个月以内，上一段实习可适当详细，但必须在证据草案中解释并经用户确认。

按原文顺序逐段处理，每条逻辑经历输出下列字段：

评分使用 1–5 分：1 严重不足，2 明显需要修改，3 基本合格，4 较好，5 达到目标岗位要求。每个经历段评分，整份简历另行评分；评分必须给出简短依据。

检查规则：

• 信息完整度：是否明确说明目标、实现路径和成果；
• 语言简洁度：删除冗余连词、逻辑词、重复背景，但保留因果链和证据；
• 语言专业度：使用贴近目标 JD 的领域术语，无语法或拼写错误；
• 关键工作项：按关键杠杆或架构拆解，不按分步执行动作堆叠；一个经历段不超过 5 个小点；
• 不提高职责级别：参与/协助 不得无证据改成 负责/主导；
• 不扩大指标范围、数据规模、技术阶段、所有权或生产结果；
• 缺失事实写“原材料未提供，未补写”，并列入建议补充信息。

指标不清时，只能推荐指标名称、定义和待补充口径，不能推荐或推测数字。指标趋势反常时先核对口径、样本、版本和基线，不得直接改写成“提升”。证据可分为公开可验证、可公开表述但需脱敏、无法公开或无法确认三类。

6. 输出完整修改稿

保持原文整体结构清晰一致。整体简历专业度必须单独评分并说明：

1. 大模块标题清晰，学习经历、实习经历、论文发表、个人项目等板块相互独立；
2. 学习经历至少包含学校、专业、就读时间；
3. 每段实习经历包含“公司 + 职位 + 在职时间”的大标题、80 字以内经历概括和至少两条分点经历；
4. 各段经历尽量形成“目标 → 实现路径 → 成果”的证据链；总体评价必须先简介业务；
5. 整份简历按目标主线生成一个完整版本，最多附两条备选主线的定位、适配经历、缺口和风险。

证据草案确认后，才输出完整的修改后简历文本；不在正文中混入未经确认的占位事实。PDF 只能由已确认的完整文本生成。

7. 输出岗位招聘洞察与发展建议

报告必须展示：

• 当前查询到的 JD 原始数量、去重后数量、抓取时间、筛选口径和来源；
• 高频能力、工具、职责和经验要求；
• 候选人原文中已覆盖、部分覆盖和未体现的表达；
• 基于 JD 能力要求和候选人已提供信息的前三年建议路径。

路径使用“建议”“常见路径”“可验证目标”等措辞，不做保证性预测，不进行人格判断或未经事实支持的个人诊断。

8. 交付前质量门

运行 scripts/resume_checks.py 做结构性检查，并人工完成以下检查：

• 没有新增候选人事实、指标、职责、工具、论文、数据集或生产结果；
• 每处重要修改均有理由和 JD 依据；
• P、T、M 序列使用对应规则，未把不同子方向混为一谈；
• 结构、时间、职位、学校、专业等字段一致；
• 语言评分和整体专业度评分均有证据；
• 重复运行时核心建议稳定；
• 抓取或解析失败被明确报告，而不是静默降级。
• 角色特定交付的 storyline.status=confirmed、storyline.confirmation=confirmed 且 storyline.editing_gate=editing_allowed；每个经历段都有已确认的证据分类和详略级别。
• 运行事实挑战门；角色特定交付要求 storyline.fact_challenge_gate=passed，每条 storyline.fact_challenges 只能是 resolved 或 explicitly_unverified，不得存在 open challenge。
• explicitly_unverified 事实必须从最终正文、指标和职责表述中排除，只能保留在风险或待补充说明中。
• 若存在角色冲突，最终交付再次列出上述风险及具体缺失信息。
  运行 check_experience_segments 检查用户定义的经历段边界、标题字段、概括字数、关键工作项数量和必填事实缺口。结构问题影响整体专业度评分和风险提示，但不阻止文字修改；事实准确性风险才是阻断条件。
  每次交付生成修改历史和摘要，记录修改日期、修改产物链接、修改要点和重要信息。距离上次修改约 3 个月时只建议重新搜索 JD，不自动联网。最终交付只发起一次保存确认，允许用户分别选择修改历史、用户规则和经历归档；确认后统一调用对应脚本。
  规则按 references/rule-hierarchy.md 执行：Skill 中的强制规则不能被覆盖；用户规则覆盖预设推荐规则；用户规则只有在用户确认长期保存并提供适用范围后才写入当前项目的 user-rules/。
  将最终 JSON 交付先通过 scripts/validate_deliverable.py：

python scripts/validate_deliverable.py work/deliverable.json -o work/deliverable.validation.json

该校验器只检查字段、类型、评分范围和三阶段路径是否完整；不把结构校验当成语义事实核验，候选人事实、职责、指标和工具仍必须逐项人工复核。

Resource routing

• 需要输入文件统一化：运行 scripts/parse_resume.py。
• 需要校验 JD：运行 scripts/validate_jd_json.py，并阅读 references/jd-schema.md。
• 需要选择代表性 JD：运行 scripts/select_representative_jds.py，并阅读 references/role-alignment.md。
• 需要选择序列规则：阅读 references/role-rubrics.md。
• 需要在具体岗位与 JD 之间做对齐：阅读 references/role-alignment.md。
• 需要组织经历段、故事线、关键工作项、能力重点和详略：阅读 references/experience-method.md 和 references/evidence-selection.md。
• 需要核对冲突、目标/职责边界、指标口径/趋势、权限和高价值深挖：阅读 references/fact-challenge.md，按信号调用 scripts/fact_questions.py。
• 需要建立主线、证据取舍和经历详略草案：调用 scripts/storyline.py，并等待用户确认。
• 需要逐个追问 why/what/how/besides 或事实字段：阅读 references/fact-follow-up.md，调用 scripts/fact_questions.py。
• 需要处理强制规则、预设推荐规则和用户规则：阅读 references/rule-hierarchy.md。
• 需要组织最终交付：阅读 references/output-contract.md。
• 需要生成 JD 市场报告：运行 scripts/jd_analysis.py，并保留输出中的数量、筛选、来源和时间字段。
• 需要校验最终结构化交付：运行 scripts/validate_deliverable.py。
• 需要按状态提问或处理异常分支：运行 scripts/role_questions.py，确保每一轮最多一个问题。
• 需要补充一段经历的缺失事实：运行 scripts/fact_questions.py，每轮只展示一个问题，维护已回答/已跳过维度，不自行补写。
• 需要写入修改历史和摘要：运行 scripts/revision_history.py，仅在最终保存确认后写入。
• 需要写入长期用户规则：运行 scripts/user_rules.py，仅接受用户明确确认的内容和适用范围。
• 需要检查经历段结构：运行 scripts/resume_checks.py 的 check_experience_segments。
• 需要检测岗位冲突或保护职责级别：运行 scripts/risk_analysis.py，并阅读 references/output-contract.md 中的风险字段。
• 需要接入用户 JD 脚本或 legacy provider：运行 scripts/jd_provider.py，并单独记录外部依赖测试结果。

只加载当前任务所需的参考文件，保持主 Skill 简洁。

Confirmed extensions

Independent JD sources

When the user requests the multi-source market view, treat 字节跳动、美团 and 腾讯 as three independent provider entries. Run or receive each source separately, then call the multi-source aggregation boundary in scripts/jd_provider.py. Do not treat the listed page URLs as permission to crawl. Each result must retain source, source URL, source-specific query, permission status, and retrieval time. A blocked or unavailable source is reported explicitly.

Use global normalized-URL/content deduplication for market frequencies, retain source_names and source_urls for mirrored jobs, and display raw, valid, invalid, duplicate, selected, and deduplicated counts per source. The confirmed corpus remains capped at 30 and must not be padded when fewer than 20 valid JDs are available.

Experience facts and archive

When a candidate adds a supplementary experience fact or chooses deep dive, first set one active experience segment and call scripts/fact_questions.py only for that segment. Show exactly one next question, and do not switch segments until its fact collection, challenge review, evidence selection, and paragraph edit are complete. Use the why, what, how, and besides dimensions before the basic fact fields. The user may answer, say that a fact is unknown, or skip. A skipped or partial response does not authorize inference; it can update a working evidence draft but cannot pass the final role-specific gate without confirmation. If a new fact changes the global thesis or order, mark the plan for reordering and revisit it only after the active segment is complete.

Fact challenge gate

After every factual answer, compare it with the raw resume, previously confirmed facts, the experience timeline, the role boundary, and the metric definition. If the comparison produces a hard challenge, call scripts/fact_questions.py with one challenge_signals item and pause normal questioning until it is resolved or explicitly marked unverified. If it produces only a soft deep dive, ask one optional question and allow the user to skip. Never classify a challenge as resolved merely because the answer sounds more polished; record the concrete evidence and the user's clarification.

At final delivery, bundle the archive decision with revision-history and user-rule save decisions in one confirmation. Only after explicit consent call scripts/experience_archive.py. The archive root is 经历项目 and each entry uses 经历项目/{公司-岗位}/{编号-项目名称}/ with facts.md and facts.json. Save only candidate-supplied experience facts; missing company, role, or project name must be requested, and existing target directories must not be overwritten.

Storyline gate

After the JD evidence table and before section-by-section editing, call scripts/storyline.py or produce the equivalent user-visible structured record. The record must state one primary thesis, experience order, candidate evidence, JD-supported capabilities, JD capabilities not shown, responsibility boundaries, ability focus, detail level and reason, evidence selection factors/classification, and missing information. Keep JD evidence separate from candidate facts.

Use pending/draft mode by default and record editing_gate=evidence_confirmation_required. Ask for user confirmation after showing the evidence plan; only a confirmed plan may record editing_gate=editing_allowed. If fact supplementation changes the plan, show the changed plan again. Pause for material role conflict, factual accuracy risk, or an unconfirmed evidence decision; a narrow language-only request may bypass role alignment with an explicit limitation. The explicit storyline_gate helper moves a plan to confirmed only after the user confirms.

Revision history and rule persistence

At the final resume/report delivery, ask once whether to save revision history, the experience archive, and any newly confirmed long-term user rule. Let the user choose each item independently, then update the confirmed files together. Use scripts/revision_history.py for append-only 修改历史.md plus one file under 修改摘要/; use scripts/user_rules.py for user-rules/rules.json. Never write a user rule before asking whether it is long-term and, if yes, asking its scope.

AI and algorithm reference pack

When the target role is T-算法, or when the resume/JD contains AI training, candidate data pool, Benchmark, Reward, CPT, SFT, RL, multimodal, LLM Judge or algorithm-evaluation terms, load only the relevant files under references/ai-algorithm/:

• rules.md for evidence boundaries, mechanism preservation, training-stage separation, metric scope, ownership and one-page budget;
• error-cases.md for case IDs and regression behavior;
• terminology.md when normalizing technical wording.

Treat this pack as domain guidance, not as candidate evidence. Never copy its example terms, metrics, projects or training stages into a resume without candidate facts or target JD support. Before finalizing an affected paragraph, run scripts/ai_algorithm_checks.py alongside scripts/risk_analysis.py. A hard violation pauses that paragraph; a warning requires an explicit review note.