周日晚九点半书房台灯底下老周在群里甩过来两份 JD说明早十点截止问我哪个值得投。一份是大厂的 AI 应用工程师写得规规矩矩另一份是家中小公司的八条硬性要求没写加分项。我简历改到第三版实在不想再靠感觉拍板就把 tri-jobhunt 翻出来当裁判用。结果两份跑下来一份 70 分另一份也是 70 分。而我清清楚楚知道其中一份我八条硬性要求全中另一份缺了 onnx。我手上的判据其实有两套tri-jobhunt 是单入口分发的JD 匹配这块归它儿子tri-jd管。判据写在两处references/ats-compliance.md第四节给了两个公式children/tri-jd/SKILL.md给了五级档位。第一个公式叫 Match Score等于匹配到的关键词除以必需关键词总数目标 80 分以上。第二个叫 Overall是(Required% × 0.7) (Preferred% × 0.3)。档位分五档90-100 过度合格、75-89 优秀立即投、60-74 良好配强求职信、50-59 stretch、50 以下除非 dream job。我当时没多想直接按第一个算。大厂那份 JD 我数了数七条硬性要求命中六条85.71%过了 80 的线落在「75-89 优秀立即投」。我甚至已经开始想求职信开头怎么写。第一次反转85 分和 70 分说的是同一份 JD准备动手写求职信的时候我回头看了一眼tri-jd的步骤表发现它第 2 步写的是 Overall 那个加权公式。同一份 JD加分项三条我只中一条那 Overall 就是 85.71 乘 0.7 加 33.33 乘 0.3等于 70.00。70 分落在「60-74 良好配强求职信」。同一份 JD一个说优秀立即投一个说配强求职信。我把这套判据按字面敲成脚本拿六个真实形态的用例跑了一遍两个用例两套口径差了两个档位——像「硬性九中十、加分零中五」这种Match Score 给 90 分判过度合格Overall 给 63 分判良好。六分之二三分之一的概率会打架这已经不是我粗心的问题了。第二次反转全中也只能拿 70更让我愣住的是第二份。那家小公司 JD 只有八条硬性要求没有加分项我八条全中。我以为这至少得是满分。但按 Overall 公式Required% 是 100Preferred 那 0.3 的权重没有分母实现上只能按 0 算100 乘 0.7 加 0等于 70。八条全中70 分和第一份缺了 onnx 的那个岗位一模一样。我把这条单独拆出来看了会儿才反应过来加权公式里没写加分项不是「加分项为零分」是「这一项不适用」。把不适用的项当成零分等于硬性要求全中最多也只能拿七成分——「90-100 过度合格」这一档在 JD 没写加分项的形态下根本不可达。而现实里中小公司的 JD 不写加分项是常态。顺手量出来的另外四处既然已经把公式敲成脚本了我就顺手把整条判定链扫了一遍。分级区间写成了「90-100 / 75-89 / 60-74 / 50-59」这种整数闭合写法。加权之后分数是小数比如 Required 一中一、Preferred 七中十一算出来是 89.09。89.09 够不上 90又超出 89哪一档都落不进去。我穷举了 Required 一到十五项、Preferred 零到十五项的全部组合18360 组里有 528 组落在缝里占 2.88%缝隙集中在 (89,90)、(74,75)、(59,60)、(49,50) 这四个开区间。再往下是除零。JD 里如果没解析出 Required 关键词第一个公式就是零除零整包文档里没有任何一句说这时候该怎么办。还有否决和分级的顺序。tri-jd第 3 步分级、第 4 步否决可它没写谁覆盖谁。于是同一个岗位可以既「过度合格」又「否决」——硬性加分全中给 100 分同时因为缺必需执照被否决两条结论并排输出看的人自己挑。还有一处是术语没闭环。关键词分 Hard / Soft / Industry 三类进公式却按 Required / Preferred 二分两类之间没有任何映射密度目标写「Critical 2-4 次、Important 1-2 次」但 Critical 对应哪一类、超几次算堆砌全都没说。没去放宽公式我写了八条裁决这时候有两条路。省事那条是动数字把目标线从 80 调到 70或者把权重改成 0.8 和 0.2让全中的那份显得好看点。我没走那条。这分数是拿来回答「投不投」的动分母让它变好看等于把结论往我想要的方向推——那我还算它干什么。所以我把它敲成了脚本scripts/jd_match.py零第三方依赖八条规则Required 为空直接报 UNKNOWN 退出码 3绝不除零Preferred 没列出就把权重还给 Required显式标注weight_reallocated对外只给一个score旧的 Match Score 降级成分项指标不参与分级分级改成 ≥90、≥75、≥60、≥50 的连续区间无缝隙否决优先于分级命中就覆盖档位并标superseded_by_disqualifier写错的否决词不静默放过退出码 3 上报三分类只标注不进分密度超上限标stuffing_risk。$ python scripts/jd_match.py--requiredarkts,harmonyos,rag,python,prompt-engineering,agent,onnx\--preferredocr,vector-db,typescript--resumearkts,harmonyos,rag,python,prompt-engineering,agent,ocr Required 命中6/7(85.71%)Preferred 命中1/3(33.33%)score70.00-GOOD_APPLY[60-74 良好配强求职信]缺失必需项onnx核心那两行是这样的ifpre:# R2 权重重分配scorereq_cov*0.7(len(pre_hit)/len(pre))*100*0.3else:scorereq_cov# 没加分项不等于加分项零分# R4 连续区间90 / 75 / 60 / 50其余落 DREAM_ONLY第二份 JD 现在跑出来是 100 分档位「过度合格」并且会明确告诉你权重重分配过。第一份还是 70 分但这次它是唯一答案不会再有第二个公式跳出来说 85。顺便一提这套「没有精确数字就用保守估算」的问句我后来搬去写季度述职了雷达鸭自动生成的周报也照这个口径填省得每次被问「这个 40% 哪来的」。上图为示意左侧两份 JD 在旧口径下都挤进同一个「良好」档右侧经裁决后一份落到「良好配强求职信」、一份升到「过度合格」中间闸门口那几格代表连续区间格与格之间不留缝隙。方块与配色只表达结构不代表精确计数。前后差多少指标修之前修之后两份 JD 定级耗时手算约 25 分钟返工 3 遍单次裁决 101 毫秒我复核 6 分钟同一输入的档位结论2/6 用例两套口径打架1 个 score唯一档位匹配分口径2 套Match Score / Overall1 套旧口径降级为分项指标无加分项形态全中仅 70 分最高档不可达权重重分配全中 100 分分级漏档528/18360 组取值无档位2.88%连续区间0 组漏档空集行为Required 为 0 时零除零显式 UNKNOWN退出码 3否决与分级可同时输出「过度合格」与「否决」否决优先档位标 superseded判定块带置信三要素0/44/4顺带把上游依赖检测也敲成了脚本dep_check.py原来那句「检查 children 与 references 存在性」只是说明文字没有东西执行它。版本从 1.0.3 提到 1.1.0SKILL / CHANGELOG / _meta / tests 四处一致check_update.py跑出来 stateA 退出码 0。回归方面jd_match.py --selfcheck12 条全过dep_check.py --selfcheck2 条全过测试补了 T13-T21 九条。末了最具体的感受是我以前那种「数一数关键词、过没过 80」的判断跟抛硬币的区别只在于它看起来很认真。现在两份 JD 摆在一起一个 70 一个 100我五秒钟就知道该把求职信的时间花在哪份上——这不是因为它算得更准是因为它只剩下一种算法。下次拿到一份号称能替你做决策的判据我建议你先别问它有多全面先给它两份你已经知道答案的输入。一份你明显配得上一份明显够不着看它给不给得出不一样的分。给不出那它现在还是篇好文章不是个好工具。我是 老三十年软件开发软件设计师、注册人工智能工程师这两年在做 Web 前端和鸿蒙 ArkTS 北向应用顺手折腾 AI 自动化这套东西不定期在写点鸿蒙和 AI 的实战笔记。本文遵循 MIT 协议转载请注明出处。
