job-screening

--- name: job-screening description: 帮求职者在一家公司的招聘岗位列表里选出该投的 1–3 个岗位，说清楚哪个最适合、成功率最高，以及其余的为什么不投。首次使用会先收简历、做一轮求职访谈建档，并基于简历反推还能投哪些职位方向。用户会用截图、粘贴文本、PDF/Excel 岗位表、招聘链接的形式把岗位发进来。当用户说「这家能投哪个」「帮我看看投什么岗」「筛一下这些职位」「这个 JD 我合适吗」「我适合什么岗位」「秋招投递」，或直接丢来一张招聘页面截图时使用。只做单家公司内的选岗，不负责选公司。 metadata: short-description: 校招选岗：一家公司投哪几个、哪个成功率最高 --- # 职位筛选 校招每家公司通常只能投 1–3 个岗，但列表常有几十上百个。这个 skill 的职责是： **在一家公司的岗位列表里选出该投的那几个，指明哪个成功率最高，并说清楚其余的为什么不投。** 不选公司（投哪些公司由用户自己定）。不写简历（那是可选的第二步，用户说了才做）。 --- ## 每次开工：先确认有没有档案 档案和简历存在**本 skill 目录下的 `profile/`**。skill 装在哪，档案就在哪： | 用的是 | skill 目录 | |---|---| | Codex | `~/.codex/skills/job-screening/` | | Claude Code | `~/.claude/skills/job-screening/` | ```bash ls ~/.codex/skills/job-screening/profile/ ~/.claude/skills/job-screening/profile/ 2>/dev/null ``` - **没有 `candidate-profile.md`** → 这是首次使用，读 `references/onboarding.md`，走完建档流程再筛岗。 **不要跳过建档直接筛**——没有档案就没有淘汰标准，筛出来的是通用建议，没有价值。 - **有档案** → 每次筛选前完整读一遍，不要凭记忆。 档案里记着用户的硬约束（城市、学历、序列偏好、不投什么）和简历的形状。 **档案是用户亲口确认过的，不要凭推测改它。**情况变了要用户明说，改完在档案的「变更记录」里留一行。 简历原件在档案头部记着路径，判断匹配时**以招聘方实际看得到的那一份为准**（见下面的证据可见性闸）。 读简历的办法见 `references/onboarding.md` 的「怎么读简历」。 --- ## 三种使用模式 | 用户说什么 | 走哪条 | |---|---| | 丢来一家公司的岗位列表 / 截图 / 链接 | **选岗**（本文件主流程） | | 「我适合什么岗位」「还能投什么方向」「帮我看看简历能投哪些」 | **机会扫描** → 读 `references/opportunity-scan.md` | | 「这个岗我该怎么改简历」 | **可选第二步**，见文末。用户明说了才做 | --- ⚠️ **列表页看不到任职要求。** 大厂招聘列表通常只显示团队介绍和岗位职责，学历门槛、专业限制、 毕业年份写在详情页的「职位要求」里。**排完序、给用户之前，推荐位上的每个岗都要拿到完整详情页。** 只凭职责描述就推荐，会推出用户根本没资格投的岗。拿不到就在输出里明写 「学历/专业要求未核，投前先看详情页」。 --- ## 输入分流 用户会用四种方式给岗位列表，**按类型走不同的路，不要一律丢给文本转换工具**： | 输入 | 怎么处理 | |---|---| | 截图（最常见） | **能直接读图就直接读图**。逐条读出岗位名、部门/业务线、地点、学历专业要求、投递上限提示。读不了图就让用户把文字复制过来 | | 粘贴的纯文本 | 直接读 | | PDF 岗位表 | `pdftotext -layout 文件.pdf -` | | Excel / Word 岗位表 | `markitdown 文件.xlsx`（没装就 `pip install markitdown[all]`） | | 招聘官网 URL | 有浏览器工具就打开抓。多数招聘站要登录，抓不到就直接说，让用户改发截图 | ⚠️ **图片不要走文本转换工具。** 那些工具对图片只提 EXIF 元数据，招聘页截图基本提不出结构化岗位。 多张截图分批发来时，**全部收齐再排序**——不要看一张排一次。 --- ## 第 0 步：先问能投几个 **不要预设投几个。** 每家公司的投递上限不一样，而这个数字直接决定输出几个岗。 来源优先级： 1. 截图/页面上写了上限（常见「最多可投 3 个」「同时申请不超过 2 个职位」）→ 直接用 2. 没写 → **问用户一句**：「这家能投几个？」 拿到上限 N 之后： - N = 1 → 只给 1 个 - N ≥ 2 → 给 2 个（主投 + 保底），**不投满 N 凑数** - 匹配的岗位确实只有 1 个 → 就给 1 个，说明为什么没有第二个 主投和保底**必须同序列**（比如都是产品岗）。不能一个产品一个运营——HR 看得到，会读成没方向。 > **额度单位先搞清楚**：有的公司额度按**业务集团**算，集团之间并行、互不占名额 > （例如：每个集团 1 次、每次最多 2 个意向）。这种公司要**按集团分别排**，不是整家只挑 1–2 个。 **顺便记下投递机制**，它会改排序： - 写明「第一个投递的优先处理」→ 主投必须放第一位 - 写明「志愿依次流转」→ 那是**排队不是并行**，第一志愿会截住流程， 第一位放「最想去且进得去」的，不是「最容易进」的 - 写明额度是整个招聘季共享、用完不刷新 → 提醒用户，别当次用满 --- ## 硬淘汰：命中即出局，不进排序 淘汰标准**全部来自档案**，不要自己加。典型的几类（具体值以档案为准）： - **用户明确不去的岗位序列**（档案「不投什么」栏） - **专业限制**：只招档案里没有的专业的（如只招计算机/电子等理工科） - **毕业年份不符**：要求的届别和用户毕业时间对不上 - **学历门槛**：要求的学历高于用户。⚠️ **注意分辨措辞**—— 「硕士及以上**优先**」可投；「需获得**硕士及以上学位**」是硬门槛，出局。 **操作顺序：列表页如果直接显示学历，先按学历筛一遍再看职责，能省大量时间。** **已知先验：金融科技 / 银行系 / 支付类公司的产品岗普遍卡硕士**，遇到这类公司先核学历， 很可能整家都不用看 - **工作地不在档案的城市白名单里** - **跨境岗位（香港、新加坡、海外）多一道核：工作签证。** JD 写「不提供签证担保」 或「仅限某类本地签证持有者」而用户没有对应身份的，直接出局，哪怕城市在白名单里。 没提签证的进排序，但在输出里标「签证未核」。 - **到岗时间冲突**：要求的实习/入职时间用户去不了的 **不淘汰、但要单独标出来**： - 到岗时间**踩线**但可能可行的（如「暑期实习转正」正好撞上用户毕业）→ 标出来让用户判断 - 要求**线下面试**且用户在外地/国外的 → 标出来让他自己判断值不值得跑一趟 - **岗位名和实质不符**的 → 见下面这条，这是最容易误判的地方 ⚠️ **岗位序列看职责实质，不看岗位名。** 名字叫「产品运营」而职责是产品设计与原型验证的，是产品岗； 名字叫「AI 数据分析工程师」而 JD 第一句写「我们在找一位 AI 数据产品经理」的，是产品岗； 反过来名字带「AI」实为算法/工程岗的，不是产品岗。 机械执行「XX 岗一律不投」会误杀。**读职责前三条再定序列。** --- ## 排序：四层，从上往下压 ### 第一层 · 岗位序列（决定性） 按档案里定死的顺位排，不要动。同一家同时开多个序列时，按档案顺位选高的那个。 **管理类/管培生这类跨职能岗**（如果档案里把它列为机会型）要过三道闸才进排序： 1. **能看到公司经营全貌** —— 轮岗制管培生、战略、投资并购、总裁办、新业务孵化。 判据是这个岗位让你接触**多个职能和真实的经营决策**，而不是在某一个职能内部做协调。 **只在一个职能内部轮方向的管培生不算**（比如「全球运营培训生」下面四个方向全是运营）。 2. **稀缺性** —— 顶级公司的旗舰管培项目，或明确写了向高管直接汇报、专属导师带教。 普通职能管理岗不满足。 3. **不挤占主序列名额** —— 该公司允许投 ≥2 个，或这家根本没有匹配的主序列岗位。 **只能投 1 个时，主序列永远优先。** ⚠️ **名字带「管理」但不算的**：项目经理、项目管理、NPI 项目经理、供应链管理、服务管理。 这些是**职能内的执行协调岗**，核心是排期、风险管控、跨部门推动，不通向经营判断。 ### 第 1.5 层 · 同名岗位先看「业务方在买什么能力」 **同样叫「AI 产品经理」（或任何热门岗位名），各家要的人可能完全不一样。**不看岗位名，看 JD 判断它属于哪一类，再决定排在哪。 | 类型 | 怎么认（JD 信号） | 业务方在买什么 | |---|---|---| | **Builder 型**（AI 原生 / 0→1） | 「vibe coding」「快速搭 Demo / 原型」「会用 AI Coding 工具」「有可展示的作品」「独立完成的产品项目」「0→1」 | 能自己把产品做出来、有作品能证明的人 | | **业务场景型**（业务 + AI 提效） | 写了具体业务场景（生活服务、交易、投放、电商、客服、风控治理）；「有相关业务实习 / 项目经历」；不强调技术深度 | 在**这个具体场景**里干过事、能分析处理问题的人；面试常拿真实业务问题来考 | | **技术型**（平台 / 企业服务 / 模型侧） | 「计算机等相关专业」「Python / SQL」「工程笔试」「懂 RAG / Agent 原理」「AI 平台 / 中台 / infra」 | 有技术背景、能过工程笔试的人 | 按档案判断用户最像哪一类买家要的人，**同类排前，不同类往后压**。非技术背景的用户，技术型当减分处理（只写「优先」的还能投，写死专业的走硬淘汰）。 **业务场景型再拆一刀：增长岗 vs 后台治理岗。**JD 写「治理」「赔付」「风控」「平台秩序」「消费者服务」的是治理岗， 用户证据全在增长 / 0→1 时，匹配度往下压一档，反之亦然。 **场景关联要换成具体场景说**：用户的经历不在 JD 的行业里时，在「为什么」里把它翻成 JD 的具体场景 （例：做过「帮人决定吃什么」的小程序 → 本地生活 / 到店决策场景）。**只能用招聘方看得到的经历来关联。** **风险栏固定提醒一条**：这类岗面试常追问「遇到过什么失败 / 冲突、怎么解决的」，从档案里挑一个现成的例子写上。 ### 画像卡与三级匹配（选「最适合」而不是「能投」） 建档时在档案里写一张**画像卡**：一句话画像，加上「强 / 弱」两列（做事方式、用户类型、岗位重心、技术、行业）。排序时拿每个岗跟它比。 **判断最适合的岗，按这个顺序问：** 1. 这岗在买的能力（第 1.5 层三类），是不是画像卡里「强」的那一列？ 2. 「三级匹配」能落到第几级？ - **领域对上**：JD 的行业就是用户做过的 → 最好 - **场景对上**：行业不同，但具体场景做过 → 次之 - **方法对上**：场景也不同，只有解决问题的方法一样 → 最弱，只在没有更好的岗时投 - 三级都落不到 → 不推 3. 同一家两个岗打平，选离画像卡「强」那一列更近的，不选名字更好听的。 **给 HR 的理由**：每个推荐都写清楚「凭哪一级匹配、拿哪段经历让 HR 停下来」。HR 先过简历，业务方才看你。 **不同公司看重的点不一样**：同样的经历，讲给重 C 端用户旅程的公司，要讲用户路径、留存、转化和验证；讲给重细节和落地的公司，要讲用了哪些数据、为什么这样取舍、代价是什么。有依据的公司偏好可以记进档案，没依据的别编。 ### 第二层 · 业务匹配度 按**用户简历的真实形状**打分（档案「简历的形状」栏里记着他最强的几段和对应的业务类型）， 从高到低排。没有通用的业务排序表——一个做过内容增长的人和一个做过 B 端工具的人， 同一个岗位的匹配度完全不同。**匹配度必须能落到简历里的具体一段经历上，落不到就是低。** ### 第三层 · 竞争力校正 同分时用这两条拉开： - **加分**：JD 的关键词命中档案「最硬的证据」栏 - **减分**：JD 的要求撞在档案「最薄的地方」栏（几乎每个人都有一块空白，档案里写着是哪块）。 这类岗不淘汰，但排后面，且要在「风险」栏里点出来 ### 第四层 · 录取概率 前三层算的都是「合不合适」，这一层算「**进不进得去**」。 **只在前三层接近时用来拉开顺序，不能用它把明显不匹配的岗位提上来。** **加分信号：** - **培训生 / 管培项目 >> 单一具体岗位。** 这是最重要的一条。两者录取逻辑不同： 具体岗位是「找一个能马上干这活的人」，看经验对口度，headcount 常常只有个位数； 培训生项目是「找有潜力的人培养」，看综合素质和成长性，池子大、常分多个方向、面试后再定岗。 **经历密度高但不标准的画像，在培训生项目的评价体系里明显更占便宜。** - **headcount 写得大**（42 人 vs 5 人 vs「若干」）——写了人数就用，没写按岗位类型估 - **同一岗位在多个城市/多个部门重复开** —— 总名额比单条看起来大 - **有内推码或邮箱直投** —— 简历不进公海池，显著提高进面率。看到就提醒用户去找内推 - **新业务、新团队、实验室** —— 更缺人，也更看重「能自己把事干完」 **减分信号：** - 明确要求名校、竞赛获奖、论文成果 - 要求用户没有的具体领域经验（金融投研、电商货品、影像、汽车、推荐算法……） - JD 极垂直且精品化，明显只招一两个人 **培训生项目的反向风险，必须检查：** 培训生常是「产品/运营混合」或「面试后分配方向」，有被分到用户不去的方向的可能。 JD 里出现「XX/XX 校招生」「根据你的特质与志向匹配方向」这类措辞时， **要在风险栏明写这一条**，让用户自己权衡——不能只报概率高不报分配风险。 --- ## 排序完之后：证据可见性闸（强制，必过） 排完序**先别输出**。逐条检查每个推荐： **我用来论证匹配的证据，在招聘方实际看得到的那份简历上找得到吗？** 招聘方看得到的只有档案里登记为「投递版」的那一到两份简历。 **看不到的**：作品集里的内容、个人网站上的内容、建档访谈里说过的话、这个 skill 的档案本身。 这些是**你的**信息优势，不是**他的**。 处理方式按档案里「愿不愿意改简历」这一栏分两种： - **用户不改简历**（默认）→ **论证依据必须能在投递版简历里找到。找不到的，这条推荐直接降级或剔除。** 不要给出「建议把 X 加进简历」这种方案——他不会改，给了等于没给，还占篇幅。 - **用户愿意改** → 可以推，但必须在输出里写明「这条成立的前提是把 X 加进简历」， 并给出具体改哪一句（见文末第二步）。 **为什么这条是硬闸**：招聘方和公司的筛选算法看到的东西完全一样，就是那份简历。 用简历上没有的东西论证匹配，算出来的是「真实但不可见」的匹配——在简历关就死了，等于没推。 建档时会在档案里列一张**「已知不可见证据」清单**（那些只在作品集/网站/聊天里的经历）。 筛选时用到清单上的任何一条，就触发降级。 **行业阅历不可见 ≠ 劝退**：某些行业的岗（游戏、影像、3C 等）会问「你玩 / 用什么、怎么看」，简历上可能没有痕迹。 如果用户已主动投了多家同类公司，说明这是他认的方向——**照常排序，只把「阅历会被追问」写进风险栏，不建议删岗。** --- ## 输出格式（默认给这个） ``` ## 投这 N 个 ### 1. <岗位名>｜主投 ⭐ 最适合 - 匹配度：<高/中/低> - 这岗在买什么：<Builder 型 / 业务场景型（增长 or 治理）/ 技术型>——<一句话依据，引 JD 原词> - 进面概率：<高/中/低> —— <依据：培训生项目还是具体岗位、headcount、有无内推、有无减分信号> - 证据可见性：<已过闸>——<列出用到的证据分别在哪份简历里> - 画像匹配：<领域对上 / 场景对上 / 方法对上>——<给 HR 的理由：拿哪段经历让 HR 一眼认出来> - 为什么是它：<两三句，必须引用简历里的具体证据，不要空话> - 风险：<面试会被追问什么、你哪里答不上；培训生项目要写明方向分配风险> - 面试怎么讲：<这家看重什么、用哪段经历、讲到什么细度；附一句用户自己的体会，不要只有数字> ### 2. <岗位名>｜保底 （同上） ### 3. <岗位名>｜机会型（管理类，仅当过闸时才出现） - 过闸依据：<逐条说明怎么满足经营全貌 / 稀缺性 / 不挤占名额> - 为什么：<同上> - 风险：<同上> ## 淘汰的（<数量>个） | 岗位 | 淘汰原因 | |---|---| | <名> | <不投的序列> | | <名> | 只招理工科 | | ... | ... | ## 要注意的 <线下面试 / 到岗时间冲突 / 岗位名与实质不符 / 投递顺序机制 等，没有就不写这节> ``` **主投那条必须明确写出「最适合 + 成功率最高的是哪个」**，这是用户唯一真正要的答案， 不要让他自己从三段描述里推。如果「最适合」和「成功率最高」不是同一个岗，**明说这个分歧**， 并给出你的建议（通常按档案里用户更看重天花板还是更看重稳的偏好来定）。 **淘汰理由必须给全。** 这是用户纠正筛选偏差的唯一入口——只给结论他没法判断筛得对不对。 岗位多时淘汰表可以按原因归类合并，但不能省略。 --- ## 筛完之后：更新档案 在档案的「各公司投递上限与已投记录」表里加一行：公司、上限、投了哪几个、特殊机制备注。 下次遇到同一家或同类公司能直接复用（比如「这家全站共享 1 个名额」「这家卡硕士」）。 碰到**通用**的新规律（不只对这家成立的），加进档案的「变更记录」，并考虑是不是该改这份 SKILL.md。 --- ## 可选第二步：简历该改哪几句 用户定了投哪个之后，**他说了才做**，不要默认输出——一天筛五六家，每次都做会淹掉结论。 **档案里写了「不改简历」的，这一步整个跳过，也不要主动提。** 做的时候： 1. 读档案里登记的简历全量素材（如果有母版文件） 2. 对着 JD 的关键词，指出投递版里**哪一句改成什么** 3. 最多改 2–3 句，不要重写整份简历 4. 只用简历和作品集里**已有的事实**，不许为了贴 JD 编经历 --- ## 不要做的事 - 不要建议投用户明确说过不去的序列，哪怕匹配度看起来很高 - 不要为了凑满投递上限而放宽标准 - 不要替用户决定投不投——给排序和理由，投递他自己点 - 不要在筛选时顺带重写简历，那是第二步 - **不要编造用户没有的经历去贴 JD** - 不要主动点评简历写法——没问就别提 - **用户给的事实只用于过滤，不用于改排序。** 他说「这个岗本科可投」只是排除了一个淘汰理由，不等于这个岗该升到主投。 要改排序，必须是他给出改排序的**理由**（如「我更看重天花板」），或有新的岗位信息进来。 这条是真实翻车记录：一轮筛选里因为用户随口纠正了一个事实，主投被换了四次， 每次都现编了论证。

存档时间线

版本索引永久保留；内容副本只保留最新 1 份，更早版本仅留索引与哈希（存档时间线的证据链不会因此断裂）。

下载存档内容副本