简历岗位匹配

用途

把一份简历转化为一份可直接执行的求职决策报告：先构建脱敏候选人画像，再在主流招聘平台检索匹配岗位，按加权匹配度排序输出清单，最后指出技能差距并给出优先投递顺序。

何时使用

用户上传/指定了简历，要求分析并推荐岗位
用户描述自身背景，询问适合什么工作、能投哪些岗位
用户要求做求职方向规划、转行可行性分析、城市机会扫描

触发词（命中任一即启动）

A. 明确指令类

「分析我的简历」「帮我看看这份简历」「解析简历」
「推荐岗位 / 推荐工作」「帮我找岗位」「匹配岗位」
「生成岗位推荐清单」「按匹配度排序」
「简历岗位匹配」「人岗匹配」「求职匹配」

B. 意图描述类（无简历文件也算命中）

「我适合什么工作」「我能投哪些岗位」「我这背景能做什么」
「XX 背景在 XX 城市有什么机会」
「帮我看看这个岗位适不适合我」
「转行可行吗 / 转行能做什么」「求职方向规划」

C. 隐式信号类

消息中同时出现「简历/履历/CV/resume」+「岗位/招聘/求职/找工作/面试机会」
附带了简历文件（pdf/doc/docx/图片）+ 任何求职相关提问
提到具体平台名（Boss 直聘、猎聘、智联招聘）+ 找工作意图

不触发（本清单优先级最高——当消息同时命中触发信号与本清单时，一律按不触发处理，转交相应技能或直接回应）：

只要求「帮我写/改/优化简历」→ 属简历撰写，不是岗位匹配
只要求面试模拟、笔试题讲解
询问某家公司的背景/评价（非岗位匹配）
已有明确目标岗位，只要求准备面试

能力边界（本技能不能做什么，须向用户明示）

不能代投简历：无 API 且属外部动作，投递必须由用户本人在平台内完成
不能登录平台实时抓取：所有信息只来自公开可索引页面，覆盖率天然不完整
不能保证岗位此刻仍在招：只能证明「核验时存在正向在招证据」，投递前须平台内确认
不能覆盖全部在招岗位：登录墙与动态渲染导致大量岗位无法核实，主清单条数少是正常结果
不能处理无文字层的扫描版简历：需用户换带文字层的版本，不用 OCR 兜底猜内容

硬性约束（不可违反）

没有 API，必须如实声明。Boss 直聘 / 猎聘 / 智联招聘均未提供对外岗位查询 API，无法代为登录、实时抓取或自动投递。所有信息只能来自公开可索引的搜索结果。每份报告必须包含来源声明（模板见 assets/report-template.md 文末）。
绝不虚构。不得编造岗位名称、公司名、薪资或 JD。检索不到就写「本轮未检索到公开信息」并给出用户自行核实的检索路径。薪资页面未标注时写「面议」，禁止估算。
简历为图片或扫描版 PDF 时（.jpg / .png 等，或无文字层的扫描 PDF—— 表现为读取后正文为空/乱码），读取依赖多模态能力。若当前模型不支持图片或读取结果为空，直接告知用户切换多模态模型或改用带文字层的 PDF/Word 版本，不要用 OCR 兜底猜内容。
只读扫描。定位简历文件时只扫描不移动，不触碰个人目录下的其他文件。
缺失才问，不重复问。解析出画像后、发起搜索前，用 AskUserQuestion 补齐用户尚未表达的偏好项（清单与优先级见第 3 步）。已在原始消息或简历中明确的项直接采用，不再追问。用户未回答时走默认值并在报告中标注「默认假设，可随时调整」。
未拿到正向在招证据，一律默认「不在招」。这是时效性判断的第一原则，判断方向必须反转：不是「没发现失效迹象就当在招」，而是「没找到正向在招证据就当不在招」。原因有三：
- 搜索引擎与聚合站的索引天然滞后数周至数月，搜索结果本身就是滞后快照；
- 招聘平台详情页有登录墙与 JS 渲染，WebFetch 打开的多半是空壳页或登录提示页， 「页面能打开」不等于「岗位在招」，「无下架字样」也不等于「未下架」—— 空壳页里根本没有岗位状态字段；
- 因此禁止设「疑似在招」这类宽松中间档。凡是拿不到正向证据的，一律按「证据不足」处理，移入「待核实清单」，不得进主清单。 正向在招证据只有四种：① 页面上明确的绝对日期（发布/更新/截止日）且距今天在阈值内；② 实时访问页面时看到的更新类标记（今日更新 / X 天前更新， X ≤ 21）；③ 官方公告的报名窗口未关闭；④ 企业官网招聘页上该岗位仍挂着。（注意：「X 小时前在线 / 今日活跃」是在线类标记，只反映 HR 登录状态，不算证据，见约束 7。）
必须区分「更新」类标记与「在线」类标记——这两者常被混为一谈，但价值完全不同（实测猎聘移动版详情页会同时出现「今日更新」与「10 小时前在线」）：

| 标记类型 | 例子 | 含义 | 能否作在招证据 | |---|---|---|---| | 更新类 | 今日更新、X 天前更新、X 月 X 日更新、刚刚发布 | 岗位内容被发布/刷新的时间 | 能。「今日更新」是最强信号，说明岗位当前仍被维护 | | 在线类 | X 小时前在线、今日活跃、刚刚活跃、7 日内活跃 | HR 的登录/活跃状态，与岗位状态无关 | 不能。HR 人还在、岗早招满的情况极常见 | | 营销类 | 近期、日前、火热招聘中、急招 | 无时间信息 | 不能 |

关键：WebFetch 实时访问页面时看到的相对时间（「今日更新」）是可信的，因为它反映的就是访问那一刻的状态；而搜索摘要里留下的绝对日期（如「8月26日更新」）是搜索引擎抓取那一刻的快照，要按抓取时间折算—— 两者都要记录，取更有利的那个，并注明来源。「近期」「刚刚」「日前」等不含具体天数的模糊表述一律不采信。
聚合站与内容农场不作在招证据。全职网、面经站、外企岗聚合站、各类「XX 年最新岗位汇总」SEO 文章的日期是页面发布/存档日期，与岗位是否在招无关。这类源只能用于补充 JD 摘要与发现公司名，不能作为在招依据，不能作为入口链接，也不能据此把岗位放进主清单。
时效优先于数量。经严格过滤后主清单只剩 2-3 条是正常结果，禁止为凑满 8-12 条而放宽标准。数量不足时走「时效不足时的替代交付」（见失败与降级路径）—— 交付目标公司清单 + 官方招聘入口 + 平台订阅关键词，比交付一堆失效链接有用得多。
当前日期必须用命令取。所有日期判断前先执行 date +%F，以命令输出为准，禁止凭记忆推断今天是几号，否则截止日判断会系统性出错。
默认脱敏输出（详见下节）。涉及姓名、证件号、联系方式、年龄、婚育、民族、政治面貌、现雇主全称等字段，一律不得写入报告，也不在对话中回显简历原文。
不采集与就业歧视相关的字段做推荐依据。若岗位本身有年龄/性别/户籍等报考条件，不写入报告，改为在「用户自查清单」里提示用户自行到官方公告核对。

隐私与脱敏规则（默认开启）

字段敏感分级

| 级别 | 字段 | 处理方式 | |---|---|---| | L1 可写 | 工龄、行业赛道、公司性质与规模档位、岗位序列、职级/职等、带人规模、技能与工具、项目成果（量化但不涉密）、学历层次与性质、院校层次、外语水平、证书 | 正常写入报告 | | L2 受限 | 现居城市（只到城市，不写区县以下）、期望薪资区间、可接受城市与出差强度、空档期区间 | 只写区间/档位，不写精确地址与流水数字 | | L3 脱敏后写 | 姓名 → 只保留姓氏或匿名代号（如「候选人 W」）；现/前雇主 → 用「行业 + 规模 + 性质」描述（如「某头部新能源上市公司」）；院校 → 用层次描述（如「中部 985」），用户要求时保留全称 | 必须改写后再写 | | L4 禁写 | 身份证/护照号、手机号、邮箱、家庭住址、出生日期与年龄、民族、政治面貌、婚育状况、健康状况、宗教、现薪流水与社保记录、直属领导姓名与联系方式、简历原文段落 | 一律不写入报告、不回显到对话 |

执行要求

输出文件名不含真实姓名：岗位推荐分析_{岗位方向}_{YYYYMMDD}.md （例：岗位推荐分析_产品经理_20260902.md），存放于工作区 职业发展/ 下。
简历原文不回显：对话与报告中只出现结构化提取结果，不逐段引用简历原文。
体制内/国企岗位的年龄、户籍、政治面貌等报考门槛，只在报告末尾「用户自查清单」中提示「请到官方公告核对 XX 条件」，不把候选人这些属性写进正文。
仅在用户明确要求（如报告需打印投递、需带姓名抬头）时才关闭脱敏，且需二次确认。
报告生成后提示一句：报告含个人职业信息，建议本地保存，勿上传公共仓库。
信任与安全基线（TRACE·T）：最小权限（只读处理指定简历、不触碰其他文件）、无第三方依赖且不依赖海外 API（纯标准库脚本 + 国内平台检索 + 全中文）、平台安全检测（SkillHub 交叉扫描硬标准，无恶意代码 / 后门 / 凭据读取）。逐项核验见 references/trust-and-safety.md。

候选人画像：通用属性字典（概述）

完整的字段字典（A 基础与求职状态 / B 经验与资历 / C 教育与认证 / D 能力与可迁移性 / E 地域与用工约束 / F 期望与偏好 / G 风险卡点）见 references/candidate-profile.md，解析简历与构建画像时必须先读取该文件，逐项对照提取。核心原则：

通用字段集，与候选人所在行业无关；逐项对照，缺项写「简历未体现」，不要留空或推断填充
L3 字段（姓名/雇主/院校）当场脱敏，L4 字段不落笔
风险卡点（G 组）主动识别不回避，空档期要给出叙事包装方案

执行逻辑总览

① 拿简历（用户给路径 / find_resume.py 只读扫描，扫不到就问，不猜）
  ↓
② 解析画像（A~G 字段；缺项写「简历未体现」，L3 当场脱敏，L4 不落笔）
  ↓
③ 问偏好（只问用户未表达的项；未答走默认值并标注）
  ↓
④ 并行搜索 4-6 条（不同方向；搜不到换行业词反向捞；仍无则如实声明）
  ↓
⑤ 初筛（剔风险岗 + 合并多源 + 剔失效词）
  ↓
⑥ 时效核验【决定能否进主清单】date +%F → 找正向在招证据 → T0/T1 主清单，
   T2 待核实，T3 剔除；空壳页/登录墙 = 核验失败 = T2
  ↓
⑦ 打分排序（六维加权；异地/转行/低于期望各自分组；T2/T3 不参与排序）
  ↓
⑧ 展开 + 写报告（脱敏）→ present_files 呈现 → 结尾给 2-4 个后续可选项

第一原则：任一步拿不到真实信息，就如实标注并给出用户自查路径，绝不用推测填充——优先级高于「输出完整报告」。

工作流

第 1 步：定位并解析简历

先在工作区查找；查不到再扫描常见目录：

SKILL_DIR="$HOME/.workbuddy/skills/resume-job-match"   # 项目级安装时改为：项目根/.workbuddy/skills/resume-job-match

python3 "$SKILL_DIR/scripts/find_resume.py"                     # 默认扫描 ~/Downloads ~/Desktop ~/Documents ~/Pictures
python3 "$SKILL_DIR/scripts/find_resume.py" --depth 4 ~/Documents
python3 "$SKILL_DIR/scripts/find_resume.py" --all ~/Downloads   # 不限文件名关键词，列出全部文档类文件
python3 "$SKILL_DIR/scripts/find_resume.py" --limit 15          # 限制输出条数

必须用绝对路径调用脚本。skill 执行时当前工作目录是用户工作区，不是 skill 目录，写相对路径 scripts/find_resume.py 会直接报 No such file or directory。若 SKILL_DIR 下找不到脚本，先用 find "$HOME/.workbuddy/skills" -name find_resume.py 定位真实路径再替换，不要凭猜测构造路径。

脚本只读、按修改时间倒序输出候选文件的元数据（路径/大小/时间），不读取也不回显文件内容。用户直接给了路径则跳过此步。

读取后按「通用属性字典」A~G 逐组提取，缺失项标注「简历未体现」，L3 字段当场脱敏， L4 字段不落笔。若扫描到多个候选文件，先列给用户确认用哪一份，不要自行挑。

文件名脱敏（必做，最易漏的一步）：扫描结果的文件名通常自带真实姓名 （实测输出形如 ~/Downloads/张三-个人简历.pdf）。姓名属 L3、可识别身份的完整路径属 L4，而脚本只输出元数据不做改写，因此回显候选清单到对话前必须先改写：

只保留「目录 + 序号 + 扩展名」，剔除姓名、公司名等身份标识： ~/Downloads/张三-个人简历1.wps → ~/Downloads/候选简历1.wps
同一目录下多份时按修改时间编号为 候选简历1 / 候选简历2
报告中一律使用改写后的名字；让用户确认「用哪一份」时，用「编号 + 修改时间 + 文件大小」区分，不要贴原文件名
唯一例外：用户需要自己在 Finder 里打开该文件时，才给出原始路径，并同时提醒「该路径含个人信息，勿外传」

空档期处理：不要回避。在画像表中单列一行，并在行动建议里给出叙事包装方案（例如把体制内信息化工作重述为 toG 政企项目经验）。

第 2 步：构建候选人画像

核心竞争力 —— 限 4 条以内，每条必须满足其一：

带量化成果（如「将 XX 指标从 A 提升到 B」）
或是一种稀缺组合（如「工程技术 + 行政管理 + AI 数字化」）

写不出证据的条目不写，不要为凑数填满 4 条。避免「沟通能力强」这类无信息量的描述。

可迁移能力 —— 用表格列出，每行写清「能力 → 来源经历 → 可迁移到什么岗位」。这一步是转行/跨行业岗位匹配的依据，不可省略。

第 3 步：确认求职偏好

在画像完成、发起搜索之前，用 AskUserQuestion 补齐用户尚未表达的项：

| 询问项（按对搜索结果影响排序） | 说明 | 选项设计原则 | |---|---|---| | ① 岗位方向 | 简历已写明或用户已口述则跳过 | 基于复合背景归纳 2-4 个方向 | | ② 意向工作城市 | 留在现居地，还是接受异地；具体到哪几个城市 | 基于现居地给默认项 + 「接受异地 / 一线城市新一线」等；支持多选 | | ③ 目标行业 | 原行业深耕 / 转行，转行到哪几个方向 | 基于简历背景归纳 2-4 个可行方向 | | ④ 期望薪资范围 | 月 base 下限 / 年薪包预期 | 结合城市与行业水平给分档区间 | | ⑤ 用工形式与公司性质 | 是否接受派遣/外包/驻场，是否排斥某类公司 | 有明确排斥项时一定要问 |

执行原则：

一次最多 4 问、每问最多 4 个选项：上表已按影响排序，超出 4 问时从 ⑤ 起依次降级为默认值并在报告中标注；绝不砍掉 ①② 等高影响项去问 ⑤。
每个选项必须基于「简历画像」动态生成，禁止给不相关选项。
用户未回答时，用「现居地 + 原行业 + 简历体现的方向 + 未设薪资下限」作默认值，报告中标注「以下为默认假设，可随时调整」。
后续所有搜索关键词、匹配度排序、投递优先级都必须受这些偏好约束：城市不符 → 降档并移入「异地机会」分组；行业不符 → 归入「转行机会」分组；薪资低于下限 → 标注「低于期望」而非直接剔除（除非用户明确要求过滤）。

第 4 步：并行搜索岗位

参考 references/platform-search-guide.md（渠道分层与可索引性、关键词公式、加权打分标准、方向→搜索词映射、风险岗位识别）。

一次发 4-6 个并行搜索，每个覆盖一个不同职业方向；主清单满 5 条及以上时单一方向占比不超过 60%，避免全部堆在一个方向上（条数不足时不适用）。串行会漏方向。

关键词公式：[平台名/渠道名] + [核心技能或行业词] + [岗位名称] + [城市或区县] + [可选: 年限/薪资/年份]。完整的构造模板、填充示例与 7 条关键技巧（并行搜索、英文职位名搜外企岗、城市落到区县、带年份搜体制内岗、跨平台交叉验证、反向捞公司）见 references/platform-search-guide.md。

搜索侧只建候选池，不判在招。搜索阶段的目标是"尽可能全地捞到候选"，在招与否一律留到第 5 步用证据判定——不要在这里就把岗位当成有效的。

时效性检索要点（详细技巧见 reference「提高命中在招岗位的检索技巧」）：

freshness（d7/d14/d30，默认 d30）只用于排序优先级，不能当作在招证据—— 它过滤的是网页被收录/更新的时间，不是岗位发布时间
查询里带绝对时间词（{YYYY}年{M}月招聘、报名截止、site:{官方域名}），年月由 date +%F 输出推得
渠道按时效可信度取优：企业官网招聘页 > 政府公告 > 国企公告 > 平台详情页 > 垂类站 > 聚合站（完整排序表见 reference）
体制内/国企岗核对报名截止日期（已过期剔除）；校招/实习按当年批次核对时间窗

真实入口链接要点：

只收录岗位详情页 URL（各平台 URL 形态见 reference「真实入口链接」表）；列表页与聚合页摘要只能作辅助检索路径
优先官方源（企业官网/政府/国企公告）：有明确报名窗口、无需登录、时效可信度最高
每项岗位注明「时效证据等级 + 绝对日期 + 证据来源」；拿不到直链时如实写定位路径，禁止伪造直链

岗位风险校验：命中收费/押证/培训贷/扣证件/无明确主体/描述模糊且薪资虚高等风险特征即剔除，完整风险特征表与处理方式见 reference「岗位风险识别」。

第 5 步：时效核验（决定岗位能否进主清单）

这一步是整份报告可信度的关键。先取当天日期：

date +%F    # 所有日期判断以命令输出为准，禁止凭记忆推断

时效证据分级

| 等级 | 判据 | 处理 | |---|---|---| | T0 强证据 | ① 企业官网招聘页上该岗位仍挂着；② 官方公告页且报名截止日 ≥ 今天；③ 平台详情页含明确的发布/更新日期且距今天 ≤ 21 天；④ 实时访问页面显示更新类标记「今日更新 / X 天前更新」（X ≤ 21） | 进主清单，标注证据日期 | | T1 中证据 | 平台官方域名详情页可访问且能读到日期或更新类标记，但距今 22-60 天；或 ≥2 个独立来源均命中且都含近期日期 | 进主清单，标注「投递前建议在平台内确认」 | | T2 弱证据 | 只有搜索快照时间；日期锚点 > 60 天；来自聚合站 / SEO 文章 / 面经站；WebFetch 只拿到空壳页、登录墙、反爬提示（＝核验失败）；页面读不到任何日期 | 移入「待核实清单」，不占主清单名额 | | T3 无证据 / 已失效 | 命中失效特征词；404 或页面已删除；报名截止日 < 今天 | 剔除；有长期关注价值的归入「持续关注」 |

本表是时效判定的唯一标准。reference 中不再重复维护此表——历史上曾因两处重复导致判据漂移（reference 漏了 T0 的 ④，同一岗位被判出两个不同等级）。核验流程细则、URL 可读性实测、标记类型辨析的完整说明见 references/platform-search-guide.md。

核验预算与动作（只核验匹配度靠前的候选，不必全量）：

核验预算：按初步匹配度排序后只核验前 8-12 条；其余候选直接归 T2 「待核实清单」，不得因未核验而反复追加 WebFetch 调用
先扫搜索摘要：摘要里常直接带绝对日期（「8月26日更新」「报名截止 2026-09-10」），最省成本，先摘下来再决定是否打开页面
优先用移动版详情页：m. 域名（如 m.liepin.com/job/{id}.shtml）常可被 WebFetch 完整读取（含 JD、薪资、更新标记）；www 版多为列表页或需登录，读不到单岗日期。读不到时先换域名形态（www ↔ m.）再试一次
打开页面只找三样：① 是否可访问 ② 是否命中失效特征词（完整词表见 reference） ③ 日期或更新类标记
读不到日期（空壳页、登录墙、JS 渲染）→ 一律 T2，写明「核验失败」
企业官网招聘页命中 → 直接 T0；≥2 个独立来源命中且日期较近 → T2 可升 T1 （镜像站与原平台不算独立来源）

四个高频误判点（上一版失效问题就出在这里，详情与实测记录见 reference）：

空壳页陷阱：「页面无失效词」≠「在招」——空壳页里根本没渲染出状态字段，读不到就是 T2 核验失败，不是通过
快照时间 ≠ 岗位时间：只有页面正文里的「发布于/更新于/报名截止」才算数
聚合站日期 ≠ 在招：镜像/面经/汇总文章的日期是抓取存档日，只能用来补 JD
模板资源文件名 ≠ 岗位状态（2026-09-03 E2E 实测新增）：智联移动版详情页普遍内嵌 icon-offline 之类模板资源名，与岗位是否下线无关，禁止据此判失效——失效判定只认正文里的失效词与日期证据。代招岗（发布方为人力资源公司、实际入职主体与发布主体不一致）不剔除，但报告中必须标注「代招：实际入职主体待核实」

第 6 步：匹配度打分与排序

入门门槛优先于打分：只有 T0 / T1 岗位参与主清单排序；T2 进「待核实清单」， T3 剔除。不允许因为「匹配度很高」把证据不足的岗位捞回主清单——一个匹配度 95 分但已失效的岗位，对用户的价值是零。

合并同源重复岗位后，对剩余岗位按六维加权打分。

| 维度 | 权重 | 判据 | |---|---|---| | 技能 / 经验对口度 | 35 | 硬技能与工具链是否直接覆盖 JD 核心要求 | | 行业与业务场景 | 20 | 同行业 / 可迁移行业 / 完全陌生 | | 职级、年限与带人规模 | 15 | 是否达标、是否过度资历 | | 城市与用工形式 | 15 | 城市符合度、是否接受该用工形式 | | 薪资包匹配 | 10 | 是否达到用户下限 | | 硬卡点 | 扣分 | 每个不可短期补齐的硬卡点扣 10 分；存在不可跨越卡点则直接淘汰 |

总分换算为 5 档（★★★★★ 高度匹配 / ★★★★ 较匹配 / ★★★ 中等 / ★★ 弱匹配 / ★ 不建议）呈现，便于阅读，排序仍按加权总分；定量换算标准与各档判据见 reference「匹配度加权打分标准」（90+ 五星 / 75-89 四星 / 60-74 三星 / 45-59 二星 / <45 一星且不进主清单）。

硬卡点识别（命中即扣分或降档，且必须在差距分析里写明）：外语要求、学历层次与性质、专业限制、证书（区分「要求」与「优先」）、城市/出差/驻场、竞业限制、年限与职级断层、行业准入资质、用工形式不接受。

分组规则：异地岗、转行岗、低于期望薪资岗各自单独分组列出，不要混进主清单稀释优先级。

第 7 步：逐项展开 + 差距分析

清单表格之外，每项岗位单独展开：工作地点、薪资、入口链接、JD 摘要（3-5 句）、 匹配理由要具体到「简历中哪段经历对上 JD 哪一条」、时效证据（等级 + 证据日期 + 证据来源，如「T0 · 页面标注更新 2026-08-28」）、主要差距、投递建议。

差距分析用表格：差距项 → 影响哪些岗位 → 补齐方式（具体到动作）→ 周期。区分「要求」和「优先」——优先项不影响投递，只影响竞争力。

第 8 步：输出报告并呈现

套用 assets/report-template.md 结构（已内置脱敏字段、时效证据列与来源声明），写入工作区 职业发展/岗位推荐分析_{岗位方向}_{YYYYMMDD}.md。

完成后调用 present_files 呈现文件，并在回复中给出高信息量摘要：画像表 + 岗位清单表（含时效证据）+ 差距表 + 优先投递 TOP 3。 回复中必须明说主清单条数与核验结论，例如「本轮核验 23 个候选，7 个已失效、 11 个无法核实，最终 5 条进主清单」——让用户自行判断可信度。

报告结尾附 2-4 个后续可选项（如：简历按方向拆 A/B 版 / 面试 STAR 故事 / 证书备考计划 / 目标岗位笔面试拆解），让用户直接选。

失败与降级路径

扫不到简历：不猜测。请用户提供绝对路径，或让用户口述背景（此时按「无简历模式」运行，画像字段标注「用户提供」而非「简历未体现」）。
搜不到任何岗位：不允许编造。输出「本轮未检索到公开信息」+ 一组可直接复制的检索关键词（按方向分组，含平台词 + 城市 + 岗位名 + freshness 建议），并给出让用户自行核实的渠道指引。这份「检索关键词清单」本身就是有效交付。
只搜到过期岗位 / 主清单不足 3 条（时效不足，最常见）： 绝不降低标准凑数。全部移入「持续关注」+「待核实清单」，主清单有多少写多少（允许为空），然后改走替代交付——这比一堆失效链接有价值得多：
1. 目标公司清单：本轮命中的公司里，剔除已失效岗位后，按「仍在招该方向」列出 8-15 家目标公司，标注公司性质 / 规模档 / 行业，并给出官方招聘入口链接 （企业官网 careers 页）。官网入口不会失效，是最稳定的长期资产。
2. 平台内订阅关键词：给出可直接粘进 Boss / 猎聘 / 智联 App 的搜索订阅词（岗位名 + 城市 + 年限 + 薪资），让平台在新岗发布时主动推送——这是绕过「搜索引擎索引滞后」的根本办法。
3. 渠道蹲守清单：官方公告的发布渠道与历史发布规律（如某人事考试网通常在每月上旬发公告），标注下次关注时间。
4. 用户核实动作清单：对「待核实清单」每个岗位给出 30 秒核实法（打开链接看是否提示职位已下线 / 在 App 内搜公司名看该岗是否还在）。
并在报告开头明说这一情况：「本轮公开可索引信息中未找到足量经核实的在招岗位，以下以目标公司与订阅渠道为主」。
图片简历且模型不支持多模态：直接告知切换模型或改用 PDF/Word，不用 OCR 兜底。
核验遇登录墙 / 空壳页 / 安全验证墙：先换域名形态（www ↔ m.）重试一次，仍读不到即按 T2 处理并记录「核验失败」，禁止对同一 URL 反复重试。单个岗位核验失败不中断整份报告，其余岗位照常核验与排序。

反模式、FAQ 与错误处理（执行前必读，见 reference）

完整清单见 references/faq-and-antipatterns.md，此处只列执行时必须记住的四条：

先避开反模式再动手：最容易翻车的三类是——把「页面能打开」当在招、把「今日活跃」当证据、把聚合站日期当在招（该 reference 共 14 条，逐条对照）
用户问「为什么只有 2 条 / 能代投吗 / 现在还在招吗」：直接答 reference 的 FAQ 8 条，不要临时编答案
出错时给修正动作，不只报错：脚本 exit=2、扫不到简历、搜索零结果等 7 类场景的「原因 + 用户该做什么」见该 reference 的错误码表
报告交付前跑 30 秒自检：6 个检查项（脱敏 / 证据等级 / 匹配理由 / 薪资 / 分组 / 核验结论数字）全在该 reference 末尾，缺一项就不要交付

本文件不重复维护这些规则——重复必然导致判据漂移。

输出质量要求

交叉验证：同一岗位在 ≥2 个独立来源命中则合并为一条（注意：镜像站与原平台不算独立来源）
链接：只交付真实详情页直链，优先企业官网与官方公告页；拿不到直链时如实写定位路径，禁止伪造
方向均衡：主清单满 5 条及以上时，单一方向占比不超过 60%（条数少时不适用）
报告用中文，风格结构化（表格 + 分层列表）

以上要求前文已规定，此处不重复（避免判据漂移）。

资源

scripts/find_resume.py —— 只读扫描常见目录定位简历文件，支持 --depth / --all / --limit
references/candidate-profile.md —— 候选人画像通用属性字典（A~G 字段集），解析简历与构建画像时必读
references/faq-and-antipatterns.md —— **反模式 14 条 + FAQ 8 条 + 错误码表
- 30 秒自检清单**（执行前必读，避免已踩过的坑）
references/platform-search-guide.md —— 渠道分层与时效可信度、核验流程细则、失效特征词表、关键词公式与模板、加权打分定量标准、风险岗位识别
assets/report-template.md —— 脱敏报告结构模板（含时效证据列、待核实清单、替代交付小节、来源声明与用户自查清单）
references/trust-and-safety.md —— 信任与安全基线（TRACE·T 逐项核验：最小权限 / 无第三方依赖 / 不依赖海外 API / 国内可用 + 中文 / 平台安全检测）

无内置示例简历，以用户真实简历为输入；输出形态见 assets/report-template.md。