我一度以为自己很会“用AI找工作”。简历让大模型润色JD丢给AI提炼关键词然后一键批量投递效率高得惊人。结果三个月下来我投出去两百多份简历面试邀请屈指可数来的还都是和方向不太对口的岗位。这个结果逼着我重新想了一件事所谓的AI辅助求职如果只是把“生成简历海投”这套链路跑得更快那它本质上是在帮我更高效地制造垃圾投递。问题不在AI在于我让AI替我做了一个本该由我自己做的判断——这个岗位到底值不值得投。后来我把整套思路推翻搭了一套跑在本地、全程可复盘、会明确说“不投”的求职决策框架。它会拆JD、会对比能力库、会标出风险信号最后冷静地告诉我这个岗位投还是再等等。这套框架最适合海投没效果、转行方向不明确、或者对简历隐私比较在意的人。如果你也受够了闭着眼投简历这篇内容应该能给你一些参考。1. “越投越没回音”不是岗位的错是投递动作出了偏差先说结论绝大多数人在AI时代投简历姿势都是错的。这个错不在“用了AI”而在“投递逻辑”本身。1.1 批量投递的幻觉简历不是“覆盖关键词”的游戏很多人习惯把JD里的关键词全部塞进简历觉得词对上了HR的筛选系统就会把你捞出来。这个思路在五年前可能有点用但现在AI生成简历太容易了人人都能用同一个大模型把“负责”“优化”“推动”这类动词铺满一页纸。当所有人的简历都长成一个样子HR看到的不是“这个人很匹配”而是“又一封模板”。我用过一段时间这类打法把同一段项目经历复制粘贴到不同岗位的简历里只改几个关键词。偶尔有一两场面试但面试官问的稍微深一点对方就知道你根本没理解这个岗位在做什么。简历是敲门砖不是遮羞布。这里要搞清楚一个底层逻辑HR筛人的核心依据是“你做过什么、做得怎么样”而不是“你抄了多少个词”。ATS系统确实存在但它只是第一道粗筛真正决定生死的还是后面的阅读和面试。你花大量精力去迎合关键词不如花精力把一个岗位的“需求”和你的“经历”真正对齐。1.2 问题不是AI而是你让AI替你做了“判断”现在的AI工具在文本生成上很强但它不知道你过去几年到底干了什么不知道你讨厌什么、擅长什么更不知道你目前的职业阶段该赌什么岗位。你把JD丢给AI让它生成一份“匹配简历”本质上是让一个对你毫无了解的模型替你做了职业方向决策。这就像你去医院直接让药房的人给你拿药跳过医生诊断。药可能是对症的但更大概率只是“看起来对症”。AI在求职场景里应该扮演“分析工具”而不是“决策大脑”。它能把JD拆成条目、能把你的技能库结构化、能算出匹配分数但最后拍板要不要投的人必须是你自己。所以我后来做的这套本地框架核心原则就一条AI负责分析和呈现人负责最终决策。框架给的不是一个“投”的答案而是一份足够清醒的决策依据。2. “清醒”的本地框架由哪三块构成这套框架之所以强调“本地”不是装酷是真的有实际需求。求职数据——简历内容、投递记录、薪资期望、联系方式——都属于高度敏感的个人信息。你把它们丢给云端AI处理就等于让第三方公司拿着你的核心隐私去做模型训练和数据分析。本地部署能从根本上解决这个问题。整个框架分三层每一层解决一个具体问题。2.1 数据私有层简历与投递记录不出本机本地模型这块我选的是Ollama配合开源模型Qwen2.5系列。部署完成后所有推理都在本机GPU或CPU上跑不联网、不上传。你可能会问为什么不用云端大模型效果好得多啊。对单论生成质量云端模型确实更强。但求职这个场景有个特殊性你要处理的不是“写一段营销文案”这种低风险内容而是你全部的职业履历和薪资预期。这些数据一旦泄露影响的是你未来的谈薪空间和职业安全。本地模型跑起来之后我第一次体会到“数据完全在自己手里”的踏实感。简历、JD、投递反馈、面试记录全部以结构化文件存在自己电脑上想怎么处理就怎么处理没有任何平台规则约束。对于准备骑驴找马、跳槽换方向的人来说这种私密性不是锦上添花而是刚需。2.2 语义匹配层用向量库替代关键词堆砌第二层是语义匹配。我把历史JD、简历片段、技能库都切成小块用embedding模型转成向量存进ChromaDB这个本地向量数据库。匹配的时候通过计算向量相似度来找“语义上相关”的内容而不是靠关键词硬碰。这个设计的价值在于JD里写“熟悉分布式系统设计”和你的简历里写“负责过订单系统的架构拆分”关键词完全不同但语义上是高度相关的。传统的关键词匹配根本识别不了这种关系而embedding能做到。我用的是bge-m3中文模型也可以换nomic-embed-text看你对中文语义的敏感度需求。2.3 决策编排层三个小Agent各司其职最上面一层是决策编排。我设计了三个小AgentJD解析Agent、能力对照Agent、风险提示Agent。每个Agent只干一件事输出结构化JSON最后由一个汇总程序把三份结果拼装成最终判断。有人会问这不就是一个大提示词的事吗为什么要拆成三个Agent因为拆开之后每个环节都能单独调试、单独测试、单独换模型。JD解析不准你只需要改JD解析的提示词和逻辑完全不影响另外两个环节。单个Agent的职责边界清晰出了bug很好定位这是“多AI协作”落地的正确姿势而不是把所有需求塞进一个上下文里。3. 搭建这套本地求职决策框架的完整步骤下面就是这套框架的具体搭建过程。我尽量按可复现的方式写依赖、目录、核心代码都会给出来。3.1 环境准备与模型选型基础环境是Python 3.10以上电脑上先装好Ollama。然后把两个关键模型拉下来# 安装Ollama之后拉取推理模型和embedding模型 ollama pull qwen2.5:7b ollama pull bge-m3选Qwen2.5:7b的理由有三个体积适中普通笔记本能跑中文JD理解效果在开源模型里属于第一梯队完全离线数据不出本机。如果你的电脑配置好可以上qwen2.5:14b理解能力更强但速度会慢不少。再装向量数据库和必要依赖pip install chromadb requests pydantic3.2 核心目录与数据流我的项目目录结构长这样job_hunter/ ├── raw_jd/ # 原始JD文本从招聘网站复制粘贴存成txt ├── parsed/ # 解析后的结构化JSON ├── skills/ # 个人技能库手动维护的yaml或json ├── matches/ # 匹配打分结果 ├── reports/ # 最终投递建议报告 └── main.py # 主流程脚本数据流很简单把JD文本丢进raw_jd跑主流程JD解析Agent把它转成结构化字段能力对照Agent检索技能库和向量库做匹配打分风险提示Agent扫风险信号最后输出一份报告到reports。3.3 关键代码JD解析与能力匹配打分这是核心逻辑我贴一个精简版本。import json import requests from chromadb import Client # Ollama本地API端口 OLLAMA_URL http://localhost:11434/api/generate def parse_jd(text: str) - dict: JD解析Agent把原始JD文本转为结构化JSON prompt f 你是一个严谨的岗位分析师。解析下面的JD只输出JSON不要任何解释。 字段要求 - job_title: 岗位名称 - responsibilities: 岗位职责列表 - requirements: 任职要求列表只放硬性要求 - bonuses: 加分项列表出现优先、加分、更好等词的内容 - salary: 薪资范围 - risk_flags: 可疑措辞列表如薪资面议、抗压能力强、弹性工作等 JD内容 {text} resp requests.post(OLLAMA_URL, json{ model: qwen2.5:7b, prompt: prompt, stream: False, format: json }) return json.loads(resp.json()[response]) def match_score(jd: dict, skills: dict) - dict: 能力对照Agent计算匹配度分数 # 硬技能命中率requirements中命中skills里任一标签的比例 hard_hit [r for r in jd[requirements] if any(s in r for s in skills[hard_skills])] hard_rate len(hard_hit) / max(len(jd[requirements]), 1) # 经验年限匹配 exp_match 1.0 if skills[years] jd.get(min_years, 0) else 0.5 # 行业/场景相似度这里用向量检索结果归一化 scene_score semantic_similarity(jd[responsibilities], skills[projects]) # 软技能匹配 soft_hit [r for r in jd[requirements] if any(s in r for s in skills[soft_skills])] soft_rate len(soft_hit) / max(len(jd[requirements]), 1) # 加权最终分 score 0.4 * hard_rate 0.3 * exp_match 0.2 * scene_score 0.1 * soft_rate return {score: round(score, 2), detail: { hard_rate: hard_rate, exp_match: exp_match, scene_score: scene_score, soft_rate: soft_rate }} def semantic_similarity(a, b): 向量语义相似度简化写法 client Client() col client.get_or_create_collection(jd_skills) # 实际查询时要将a、b转成向量再算cosine这里略 return 0.8 # 伪实现实际用embedding模型计算打分公式这样设计是有原因的。硬技能命中率占最高权重因为JD里的“熟悉”“精通”字段是你能不能过初筛的决定因素经验年限占三成是为了防止你被一个明显要求高级资历的岗位拖进去浪费时间场景相似度占两成用来衡量你过去的项目经历和这个岗位要做的事是不是一个领域软技能占一成属于锦上添花不指望它救命。3.4 提示词设计让本地模型输出结构化结论本地小模型和云端大模型有一个显著差距它很容易在长文本中丢失指令细节。所以提示词设计必须极简、明确、可执行。我自己踩出来的经验是两句话第一明确要求“只输出JSON不要任何解释”第二把字段含义写清楚尤其是“要求”和“加分项”的区别要单独标注。比如JD里写“熟悉Docker者优先”如果你不单独定义“优先”这个词本地模型很可能把它归进硬性要求导致后面的匹配分数虚高。注意如果你用Ollama可以在请求里加一个format: json参数强制模型输出JSON结构。但本地模型可能仍然输出格式错误建议在解析代码里加一层异常捕获和重试逻辑。4. 投递决策链路一个JD进来框架怎么判断该不该投框架搭好了重点看业务逻辑。一条JD从进入系统到输出结论要经过五个环节。4.1 一条JD的完整处理流第一个环节是JD解析把文本转成结构化数据。第二个环节是硬门槛预检看学历、年限、证书这类硬性条件满不满足不满足直接拦掉不进入打分。第三个环节是能力匹配打分用上一节的公式计算匹配分数。第四个环节是风险信号识别扫出JD里的可疑措辞和异常结构。第五个环节是输出最终结论分“投递”“观望”“不投”三类。结论类型触发条件建议动作投递硬门槛全过匹配分75风险信号为0直接投并按报告建议调整简历侧重点观望匹配分60-75或有1-2个中等风险信号先补充材料找内推不要裸投不投硬门槛不过或匹配分60或出现高风险信号放弃不浪费简历机会这里要特别说一下“观望”档。很多人的问题是明明觉得一个岗位“还行”就直接投了。但其实匹配分在60-75之间的岗位投了大概率石沉大海因为竞争者里一定有比你更匹配的人。这个区间最合适的动作是先围绕这个JD去补一个能力短板或者找内部人了解真实情况再做决定。4.2 风险信号识别比打分更重要的“一票否决”清单打分解决的是“匹配度”问题风险信号解决的是“值不值得”问题。一个岗位可能匹配度很高但本身是个烂岗位投了就算拿到offer也是坑。我把风险信号做成了一个规则清单写进Agent提示词里JD中出现“薪资面议”且同时出现“抗压能力强”“弹性工作”这类高频组合大概率是加班文化严重但薪资竞争力不足。岗位职责列出五条以上且没有明显主次说明岗位职责边界混乱进去可能就是打杂。岗位名称和行业常规定位不符。比如“运营助理”却要求“带团队经验”要么是岗位挂羊头卖狗肉要么是公司自己都没想清楚要招什么人。公司突然大批量招聘同一个岗位且JD内容高度模板化可能是人员流失率过高在补血。这四条不是绝对的但它们是有效的提醒信号。碰到任何一个信号框架会把该岗位标记为“观望”或“不投”你要做的是去核实而不是盲目投。4.3 投递后跟踪与数据回流这套框架最容易被忽略但最重要的环节是投递后的数据回流。投了之后收到面试邀请没有、电面聊完什么感受、终面挂在哪一环这些结果都可以标记回数据库。框架会根据历史结果反向校准匹配权重。比如你连续投了二十个“匹配分80以上”的岗位一个面试邀请都没有那说明你的打分公式里某个维度的权重和实际市场不匹配。可能是你高估了“项目场景相似度”的权重在HR眼里行业背景之外更看重的是硬技能的直接匹配。把这些反馈喂回去一两个月后框架的胜率会明显改善。5. 跑了一个月的实测数据与踩坑复盘框架搭建完成后我自己跑了整整一个月。这个章节包括我测出来的数据变化、踩过的具体坑以及针对每个坑的调整方案。5.1 一个月的真实变化对比我使用框架前后一个月的数据指标使用前使用后月投递量11048面试邀请36面试转化率2.7%12.5%无效面试占比80%20%我明确说一下这个数据样本量很小而且存在幸存者偏差不代表任何普适规律。但它至少证明了一件事少投一点、投得准一点大概率比海投有效。投递量降了一半以上面试邀请反而翻倍这背后的逻辑很简单——你花在分析上的时间最终体现在匹配的精度上。5.2 踩坑一本地小模型会把“加分项”当成“硬要求”这个坑前面提过实际影响很大。Qwen2.5-7B解析JD时会把“熟悉Docker、Redis者加分”这类内容划分到任职要求里导致匹配分数虚高。我第一次跑完一批JD发现所有岗位的分数都在85以上一看解析结果才知道模型把一大半的“优先”“加分”内容并进了硬性要求。解决方法是在提示词里强制区分先从JD原文里提取所有包含“优先”“加分”“更好”“了解即可”等词块的内容单独放到bonuses字段并且要求模型在打分阶段完全忽略bonuses字段。这一步做扎实之后分数分布立刻变得合理。5.3 踩坑二向量检索的语义偏移向量库有个经典问题你往里塞的内容越多检索出来的结果越“泛”。我一开始把半年内的所有JD都存了进去结果语义检索经常抓出一些看起来相关、实际方向完全不同的岗位。比如目标是后端开发向量库却返回了几个偏前端的岗位只因为都提到了“架构设计”。解决方式有三个一是给向量库里的每一条记录打上技能栈标签检索时先用标签粗筛再在粗筛结果里做语义匹配二是把top-k值调小我最后用5-8个召回结果就够了三是定期清理向量库里的旧数据三个月前的JD信息大概率已经失效留着只会增加噪音。5.4 踩坑三不要只信本地模型给的建议本地模型受限于参数量在总结能力和对长JD的语义理解上确实不如云端的大模型。我一开始让Qwen2.5-7B直接生成“面试追问方向”和“简历调整建议”结果发现它的建议非常空泛永远是“深入了解业务背景”“梳理自己的项目亮点”。后来我改成双层方案离线部分JD解析、打分、风险提示全部用本地模型保证敏感信息不出本机在线部分只做一件事——把脱敏后的结构化信息不含公司名、联系人、真实薪资交给云端模型让它生成更有深度的面试追问方向。生成结果再存回本地数据库。双层方案兼顾了隐私和效果。注意这里的“脱敏”很关键。技术栈、项目描述、行业方向这些信息可以脱敏后发到云端但公司名称、面试官信息、具体薪资数字这些绝对不能出去。隐私干系重大宁可不用云端也不要心存侥幸。6. 给想照抄这套思路的人几句实在话如果你也想搭一套类似的框架我有几个建议。第一不要一上来就搞全流程。我建议你先从最轻量的版本开始建一个Excel表竖列是JD里的核心需求横列是你过去的三段经历每拿一个JD就花十分钟手填一次。这个动作本身就能让你大幅减少乱投。等你发现表格流程已经不能满足你再上Agent和向量库不迟。第二框架的核心价值不在“AI”而在“流程可复盘”。很多人搭这类工具是为了炫技但真正让结果变好的是你在过程中建立起来的、对“岗位需求”和“个人能力”之间映射关系的敏感度。AI只是在帮你把这件事做得更快、更稳定。第三本地模型不是万能的。如果你的核心诉求是“文本生成质量”而不是“隐私和可控”那部署本地模型的意义不大直接用云端产品可能更省事。我的建议是所有涉及隐私判断的环节放本地所有不涉及隐私的创意生成环节放云端各用各的长处。最后说一点真实的体会。这套框架跑了一个月之后我最深刻的感受不是AI有多厉害而是我终于知道自己过去的简历为什么没人看。因为我从来没有把一个岗位“需要做什么”和自己“做过什么”真正对齐过。框架里的打分公式、风险清单、匹配报告本质上都是逼着我完成这个过程。用不用AI其实没那么重要重要性在于你是否真的开始认真对待每一次投递。
我一度以为自己很会“用AI找工作”。简历让大模型润色JD丢给AI提炼关键词然后一键批量投递效率高得惊人。结果三个月下来我投出去两百多份简历面试邀请屈指可数来的还都是和方向不太对口的岗位。这个结果逼着我重新想了一件事所谓的AI辅助求职如果只是把“生成简历海投”这套链路跑得更快那它本质上是在帮我更高效地制造垃圾投递。问题不在AI在于我让AI替我做了一个本该由我自己做的判断——这个岗位到底值不值得投。后来我把整套思路推翻搭了一套跑在本地、全程可复盘、会明确说“不投”的求职决策框架。它会拆JD、会对比能力库、会标出风险信号最后冷静地告诉我这个岗位投还是再等等。这套框架最适合海投没效果、转行方向不明确、或者对简历隐私比较在意的人。如果你也受够了闭着眼投简历这篇内容应该能给你一些参考。1. “越投越没回音”不是岗位的错是投递动作出了偏差先说结论绝大多数人在AI时代投简历姿势都是错的。这个错不在“用了AI”而在“投递逻辑”本身。1.1 批量投递的幻觉简历不是“覆盖关键词”的游戏很多人习惯把JD里的关键词全部塞进简历觉得词对上了HR的筛选系统就会把你捞出来。这个思路在五年前可能有点用但现在AI生成简历太容易了人人都能用同一个大模型把“负责”“优化”“推动”这类动词铺满一页纸。当所有人的简历都长成一个样子HR看到的不是“这个人很匹配”而是“又一封模板”。我用过一段时间这类打法把同一段项目经历复制粘贴到不同岗位的简历里只改几个关键词。偶尔有一两场面试但面试官问的稍微深一点对方就知道你根本没理解这个岗位在做什么。简历是敲门砖不是遮羞布。这里要搞清楚一个底层逻辑HR筛人的核心依据是“你做过什么、做得怎么样”而不是“你抄了多少个词”。ATS系统确实存在但它只是第一道粗筛真正决定生死的还是后面的阅读和面试。你花大量精力去迎合关键词不如花精力把一个岗位的“需求”和你的“经历”真正对齐。1.2 问题不是AI而是你让AI替你做了“判断”现在的AI工具在文本生成上很强但它不知道你过去几年到底干了什么不知道你讨厌什么、擅长什么更不知道你目前的职业阶段该赌什么岗位。你把JD丢给AI让它生成一份“匹配简历”本质上是让一个对你毫无了解的模型替你做了职业方向决策。这就像你去医院直接让药房的人给你拿药跳过医生诊断。药可能是对症的但更大概率只是“看起来对症”。AI在求职场景里应该扮演“分析工具”而不是“决策大脑”。它能把JD拆成条目、能把你的技能库结构化、能算出匹配分数但最后拍板要不要投的人必须是你自己。所以我后来做的这套本地框架核心原则就一条AI负责分析和呈现人负责最终决策。框架给的不是一个“投”的答案而是一份足够清醒的决策依据。2. “清醒”的本地框架由哪三块构成这套框架之所以强调“本地”不是装酷是真的有实际需求。求职数据——简历内容、投递记录、薪资期望、联系方式——都属于高度敏感的个人信息。你把它们丢给云端AI处理就等于让第三方公司拿着你的核心隐私去做模型训练和数据分析。本地部署能从根本上解决这个问题。整个框架分三层每一层解决一个具体问题。2.1 数据私有层简历与投递记录不出本机本地模型这块我选的是Ollama配合开源模型Qwen2.5系列。部署完成后所有推理都在本机GPU或CPU上跑不联网、不上传。你可能会问为什么不用云端大模型效果好得多啊。对单论生成质量云端模型确实更强。但求职这个场景有个特殊性你要处理的不是“写一段营销文案”这种低风险内容而是你全部的职业履历和薪资预期。这些数据一旦泄露影响的是你未来的谈薪空间和职业安全。本地模型跑起来之后我第一次体会到“数据完全在自己手里”的踏实感。简历、JD、投递反馈、面试记录全部以结构化文件存在自己电脑上想怎么处理就怎么处理没有任何平台规则约束。对于准备骑驴找马、跳槽换方向的人来说这种私密性不是锦上添花而是刚需。2.2 语义匹配层用向量库替代关键词堆砌第二层是语义匹配。我把历史JD、简历片段、技能库都切成小块用embedding模型转成向量存进ChromaDB这个本地向量数据库。匹配的时候通过计算向量相似度来找“语义上相关”的内容而不是靠关键词硬碰。这个设计的价值在于JD里写“熟悉分布式系统设计”和你的简历里写“负责过订单系统的架构拆分”关键词完全不同但语义上是高度相关的。传统的关键词匹配根本识别不了这种关系而embedding能做到。我用的是bge-m3中文模型也可以换nomic-embed-text看你对中文语义的敏感度需求。2.3 决策编排层三个小Agent各司其职最上面一层是决策编排。我设计了三个小AgentJD解析Agent、能力对照Agent、风险提示Agent。每个Agent只干一件事输出结构化JSON最后由一个汇总程序把三份结果拼装成最终判断。有人会问这不就是一个大提示词的事吗为什么要拆成三个Agent因为拆开之后每个环节都能单独调试、单独测试、单独换模型。JD解析不准你只需要改JD解析的提示词和逻辑完全不影响另外两个环节。单个Agent的职责边界清晰出了bug很好定位这是“多AI协作”落地的正确姿势而不是把所有需求塞进一个上下文里。3. 搭建这套本地求职决策框架的完整步骤下面就是这套框架的具体搭建过程。我尽量按可复现的方式写依赖、目录、核心代码都会给出来。3.1 环境准备与模型选型基础环境是Python 3.10以上电脑上先装好Ollama。然后把两个关键模型拉下来# 安装Ollama之后拉取推理模型和embedding模型 ollama pull qwen2.5:7b ollama pull bge-m3选Qwen2.5:7b的理由有三个体积适中普通笔记本能跑中文JD理解效果在开源模型里属于第一梯队完全离线数据不出本机。如果你的电脑配置好可以上qwen2.5:14b理解能力更强但速度会慢不少。再装向量数据库和必要依赖pip install chromadb requests pydantic3.2 核心目录与数据流我的项目目录结构长这样job_hunter/ ├── raw_jd/ # 原始JD文本从招聘网站复制粘贴存成txt ├── parsed/ # 解析后的结构化JSON ├── skills/ # 个人技能库手动维护的yaml或json ├── matches/ # 匹配打分结果 ├── reports/ # 最终投递建议报告 └── main.py # 主流程脚本数据流很简单把JD文本丢进raw_jd跑主流程JD解析Agent把它转成结构化字段能力对照Agent检索技能库和向量库做匹配打分风险提示Agent扫风险信号最后输出一份报告到reports。3.3 关键代码JD解析与能力匹配打分这是核心逻辑我贴一个精简版本。import json import requests from chromadb import Client # Ollama本地API端口 OLLAMA_URL http://localhost:11434/api/generate def parse_jd(text: str) - dict: JD解析Agent把原始JD文本转为结构化JSON prompt f 你是一个严谨的岗位分析师。解析下面的JD只输出JSON不要任何解释。 字段要求 - job_title: 岗位名称 - responsibilities: 岗位职责列表 - requirements: 任职要求列表只放硬性要求 - bonuses: 加分项列表出现优先、加分、更好等词的内容 - salary: 薪资范围 - risk_flags: 可疑措辞列表如薪资面议、抗压能力强、弹性工作等 JD内容 {text} resp requests.post(OLLAMA_URL, json{ model: qwen2.5:7b, prompt: prompt, stream: False, format: json }) return json.loads(resp.json()[response]) def match_score(jd: dict, skills: dict) - dict: 能力对照Agent计算匹配度分数 # 硬技能命中率requirements中命中skills里任一标签的比例 hard_hit [r for r in jd[requirements] if any(s in r for s in skills[hard_skills])] hard_rate len(hard_hit) / max(len(jd[requirements]), 1) # 经验年限匹配 exp_match 1.0 if skills[years] jd.get(min_years, 0) else 0.5 # 行业/场景相似度这里用向量检索结果归一化 scene_score semantic_similarity(jd[responsibilities], skills[projects]) # 软技能匹配 soft_hit [r for r in jd[requirements] if any(s in r for s in skills[soft_skills])] soft_rate len(soft_hit) / max(len(jd[requirements]), 1) # 加权最终分 score 0.4 * hard_rate 0.3 * exp_match 0.2 * scene_score 0.1 * soft_rate return {score: round(score, 2), detail: { hard_rate: hard_rate, exp_match: exp_match, scene_score: scene_score, soft_rate: soft_rate }} def semantic_similarity(a, b): 向量语义相似度简化写法 client Client() col client.get_or_create_collection(jd_skills) # 实际查询时要将a、b转成向量再算cosine这里略 return 0.8 # 伪实现实际用embedding模型计算打分公式这样设计是有原因的。硬技能命中率占最高权重因为JD里的“熟悉”“精通”字段是你能不能过初筛的决定因素经验年限占三成是为了防止你被一个明显要求高级资历的岗位拖进去浪费时间场景相似度占两成用来衡量你过去的项目经历和这个岗位要做的事是不是一个领域软技能占一成属于锦上添花不指望它救命。3.4 提示词设计让本地模型输出结构化结论本地小模型和云端大模型有一个显著差距它很容易在长文本中丢失指令细节。所以提示词设计必须极简、明确、可执行。我自己踩出来的经验是两句话第一明确要求“只输出JSON不要任何解释”第二把字段含义写清楚尤其是“要求”和“加分项”的区别要单独标注。比如JD里写“熟悉Docker者优先”如果你不单独定义“优先”这个词本地模型很可能把它归进硬性要求导致后面的匹配分数虚高。注意如果你用Ollama可以在请求里加一个format: json参数强制模型输出JSON结构。但本地模型可能仍然输出格式错误建议在解析代码里加一层异常捕获和重试逻辑。4. 投递决策链路一个JD进来框架怎么判断该不该投框架搭好了重点看业务逻辑。一条JD从进入系统到输出结论要经过五个环节。4.1 一条JD的完整处理流第一个环节是JD解析把文本转成结构化数据。第二个环节是硬门槛预检看学历、年限、证书这类硬性条件满不满足不满足直接拦掉不进入打分。第三个环节是能力匹配打分用上一节的公式计算匹配分数。第四个环节是风险信号识别扫出JD里的可疑措辞和异常结构。第五个环节是输出最终结论分“投递”“观望”“不投”三类。结论类型触发条件建议动作投递硬门槛全过匹配分75风险信号为0直接投并按报告建议调整简历侧重点观望匹配分60-75或有1-2个中等风险信号先补充材料找内推不要裸投不投硬门槛不过或匹配分60或出现高风险信号放弃不浪费简历机会这里要特别说一下“观望”档。很多人的问题是明明觉得一个岗位“还行”就直接投了。但其实匹配分在60-75之间的岗位投了大概率石沉大海因为竞争者里一定有比你更匹配的人。这个区间最合适的动作是先围绕这个JD去补一个能力短板或者找内部人了解真实情况再做决定。4.2 风险信号识别比打分更重要的“一票否决”清单打分解决的是“匹配度”问题风险信号解决的是“值不值得”问题。一个岗位可能匹配度很高但本身是个烂岗位投了就算拿到offer也是坑。我把风险信号做成了一个规则清单写进Agent提示词里JD中出现“薪资面议”且同时出现“抗压能力强”“弹性工作”这类高频组合大概率是加班文化严重但薪资竞争力不足。岗位职责列出五条以上且没有明显主次说明岗位职责边界混乱进去可能就是打杂。岗位名称和行业常规定位不符。比如“运营助理”却要求“带团队经验”要么是岗位挂羊头卖狗肉要么是公司自己都没想清楚要招什么人。公司突然大批量招聘同一个岗位且JD内容高度模板化可能是人员流失率过高在补血。这四条不是绝对的但它们是有效的提醒信号。碰到任何一个信号框架会把该岗位标记为“观望”或“不投”你要做的是去核实而不是盲目投。4.3 投递后跟踪与数据回流这套框架最容易被忽略但最重要的环节是投递后的数据回流。投了之后收到面试邀请没有、电面聊完什么感受、终面挂在哪一环这些结果都可以标记回数据库。框架会根据历史结果反向校准匹配权重。比如你连续投了二十个“匹配分80以上”的岗位一个面试邀请都没有那说明你的打分公式里某个维度的权重和实际市场不匹配。可能是你高估了“项目场景相似度”的权重在HR眼里行业背景之外更看重的是硬技能的直接匹配。把这些反馈喂回去一两个月后框架的胜率会明显改善。5. 跑了一个月的实测数据与踩坑复盘框架搭建完成后我自己跑了整整一个月。这个章节包括我测出来的数据变化、踩过的具体坑以及针对每个坑的调整方案。5.1 一个月的真实变化对比我使用框架前后一个月的数据指标使用前使用后月投递量11048面试邀请36面试转化率2.7%12.5%无效面试占比80%20%我明确说一下这个数据样本量很小而且存在幸存者偏差不代表任何普适规律。但它至少证明了一件事少投一点、投得准一点大概率比海投有效。投递量降了一半以上面试邀请反而翻倍这背后的逻辑很简单——你花在分析上的时间最终体现在匹配的精度上。5.2 踩坑一本地小模型会把“加分项”当成“硬要求”这个坑前面提过实际影响很大。Qwen2.5-7B解析JD时会把“熟悉Docker、Redis者加分”这类内容划分到任职要求里导致匹配分数虚高。我第一次跑完一批JD发现所有岗位的分数都在85以上一看解析结果才知道模型把一大半的“优先”“加分”内容并进了硬性要求。解决方法是在提示词里强制区分先从JD原文里提取所有包含“优先”“加分”“更好”“了解即可”等词块的内容单独放到bonuses字段并且要求模型在打分阶段完全忽略bonuses字段。这一步做扎实之后分数分布立刻变得合理。5.3 踩坑二向量检索的语义偏移向量库有个经典问题你往里塞的内容越多检索出来的结果越“泛”。我一开始把半年内的所有JD都存了进去结果语义检索经常抓出一些看起来相关、实际方向完全不同的岗位。比如目标是后端开发向量库却返回了几个偏前端的岗位只因为都提到了“架构设计”。解决方式有三个一是给向量库里的每一条记录打上技能栈标签检索时先用标签粗筛再在粗筛结果里做语义匹配二是把top-k值调小我最后用5-8个召回结果就够了三是定期清理向量库里的旧数据三个月前的JD信息大概率已经失效留着只会增加噪音。5.4 踩坑三不要只信本地模型给的建议本地模型受限于参数量在总结能力和对长JD的语义理解上确实不如云端的大模型。我一开始让Qwen2.5-7B直接生成“面试追问方向”和“简历调整建议”结果发现它的建议非常空泛永远是“深入了解业务背景”“梳理自己的项目亮点”。后来我改成双层方案离线部分JD解析、打分、风险提示全部用本地模型保证敏感信息不出本机在线部分只做一件事——把脱敏后的结构化信息不含公司名、联系人、真实薪资交给云端模型让它生成更有深度的面试追问方向。生成结果再存回本地数据库。双层方案兼顾了隐私和效果。注意这里的“脱敏”很关键。技术栈、项目描述、行业方向这些信息可以脱敏后发到云端但公司名称、面试官信息、具体薪资数字这些绝对不能出去。隐私干系重大宁可不用云端也不要心存侥幸。6. 给想照抄这套思路的人几句实在话如果你也想搭一套类似的框架我有几个建议。第一不要一上来就搞全流程。我建议你先从最轻量的版本开始建一个Excel表竖列是JD里的核心需求横列是你过去的三段经历每拿一个JD就花十分钟手填一次。这个动作本身就能让你大幅减少乱投。等你发现表格流程已经不能满足你再上Agent和向量库不迟。第二框架的核心价值不在“AI”而在“流程可复盘”。很多人搭这类工具是为了炫技但真正让结果变好的是你在过程中建立起来的、对“岗位需求”和“个人能力”之间映射关系的敏感度。AI只是在帮你把这件事做得更快、更稳定。第三本地模型不是万能的。如果你的核心诉求是“文本生成质量”而不是“隐私和可控”那部署本地模型的意义不大直接用云端产品可能更省事。我的建议是所有涉及隐私判断的环节放本地所有不涉及隐私的创意生成环节放云端各用各的长处。最后说一点真实的体会。这套框架跑了一个月之后我最深刻的感受不是AI有多厉害而是我终于知道自己过去的简历为什么没人看。因为我从来没有把一个岗位“需要做什么”和自己“做过什么”真正对齐过。框架里的打分公式、风险清单、匹配报告本质上都是逼着我完成这个过程。用不用AI其实没那么重要重要性在于你是否真的开始认真对待每一次投递。
：让AI告别临场发挥，实现可复用的自动化工作流)
