把"简历分析"做成一条 AI 工作流：从方案到 Skill 的完整实践
面向 TRAE 技术社区分享 · 2026-08 工具：TraeWork · Skill 机制
一、起因：简历分析为什么值得做成流程
做招聘的朋友大多经历过这个场景：几十份简历摊在桌上，看得眼花，最后拍板靠的却是"感觉"。老板问一句"为什么推他"，常常答不上来。问题不在人，在于这件事长期缺三样东西：
- 统一的标准——同样一份简历，今天看着行、明天看着不行，判断没有标尺
- 可复用的流程——每个岗位、每批候选人都从头再来，经验锁在个人脑子里，换个人就断档
- 可追溯的结论——推荐谁、淘汰谁没有证据链，出问题时回溯不到当初的依据
我的目标很直接：把"岗位 JD + 候选人简历"变成一份可以汇报的评估报告这件事，沉淀成一条 AI 工作流——标准先行、证据留档、人只在关键处把关。最终做成了一个可安装、可分享的 Skill：JDWorkFlow-LL。
二、整体设计：四环节流水线
整条流程拆成四个职责清晰的环节，每个环节有独立的输入、动作、产出：
岗位画像 → 简历抽取 → 简历评估 → 交叉比对
- 岗位画像：把 JD 转成一张评估标尺（硬性门槛、期望能力、加分项、程序检查四类要素）
- 简历抽取：把每份简历解析成岗位无关的结构化档案，每个字段带"值 + 置信度 + 句子级原文引用"
- 简历评估：套用标尺逐人打分，输出 100 分制评估卡，附一整套面试问题
- 交叉比对：同一标尺下对比、分群、排面试顺序，产出总经理汇报版与面试参考包
为什么是这四个环节？因为每个环节解决的问题不同：画像解决"评什么"，抽取解决"有什么证据"，评估解决"打多少分"，比对解决"谁优先"。职责切分清楚，才能各自独立打磨、独立审查。
三、几个关键设计决策
3.1 职责驱动，而不是 JD 形容词堆砌
评估维度（期望项）从岗位职责推导出的"产出成果"（KRA）来定，任职要求只做交叉验证。评的是这个岗位到底要产出什么，不是 JD 上那些无法验证的漂亮形容词。
3.2 标尺先行，权重在看简历前定稿
权重在评估开始前锁定，评估期间不得调整。这一步从机制上杜绝了"看了简历再调权重"的隐性偏袒——先定游戏规则，再开始比赛。
3.3 不猜，所有缺失显式标记
这是贯穿全程的第一原则：
- JD 含糊 → 标"待澄清"，不自行裁决
- 简历字段缺失 → 标"缺失"，停机请人事经理决策
- 证据不足 → 不打分，按 0 计并标注
所有"猜"都显式标记，绝不静默填充。宁可留白，不硬编。
3.4 事实与推断分离
简历明写的才算事实；推断值（行业属性、个人角色等）必须带"推断"标记与依据，且不能作为评分依据。评分只基于事实，杜绝了"我觉得他行"这类无依据判断。
3.5 证据可追溯
每个字段带"值 + 置信度 + 句子级原文引用"，每个评分标注依据来源（标尺项 / 档案字段 / 评分判据）。任何一个分数都能指回证据，禁止凭空新造证据。
3.6 文档流交付
每环节产出一份独立 Markdown 文档，四份齐备后合并渲染为一份 HTML 报告，作为最终交付物。按"岗位 + 日期"命名，每次运行不覆盖历史——过程可审查、可二次利用，交付即用。
四、评分模型：一张卡看清一个人
评估卡采用全维度 100 分制，节权重加权合成总总分：
节
权重
说明
硬筛
15%
学历、专业、证书等资格门槛，一票否决
期望项
50%
岗位要产出的能力，权重占比最高，是模型核心
加分项
10%
JD 中"优先/更好"信号词，有则更好
软性
15%
稳定性、成长性、求职动机
风险
10%
时间线矛盾、断档等事实疑点，分高=风险小
总分按档位机械映射出初步推荐（≥80 强推 / 60-79 可面 / 40-59 待定 / <40 不建议），最终分群由人事经理决策，可附理由偏离。
五、人在回路：三处点选式停机点
流程不会一路闷头跑完，该人拍板的地方一定停下来，用点选式询问（推荐默认 + 备选 + 其他可输入，每轮最多 3 题），不用打字：
- 权重初稿确认（环节一）：期望项权重定稿前请经理确认
- 字段缺失处理（环节二）：豁免-经理确认 / 指定默认值 / 退回补充 / 视为不合格
- 分群调整（环节四）：默认映射可附理由偏离
每次决策记录入档（决策人 / 时间 / 结果），全程可回溯。AI 负责执行与取证，人负责判断与把关——这是我认为人机协作最舒服的边界。
六、真实案例验证
流程不是拍脑袋写的。搭建过程中用真实岗位做了一次全流程实测：
- 岗位：DSP 开发工程师（真实 JD）
- 候选人：3 份真实简历
- 结果：标尺定稿（期望项权重 21/14/29/21/15）、7 项缺失决策全部正常触发、评估总分 84.8 / 79.8 / 68.4、分群 1 强推 2 可面、面试顺序产出
- “不猜"原则在实测中真实生效：证据不足的期望项按 0 分计并标注，动机信息不足时标"待面试”，没有一处硬编
最有价值的一步是外部专家验证：方法论本身存在"自己未必是领域专家"的风险，所以把草案交给一位专业招聘负责人评审，意见反馈后修改再定稿。如果方法论本身有盲区，技术再好也白搭。
七、从方案到 Skill：规则如何变成可执行流程
一个读者可能会问的关键问题：前面讲的是四份方案（JD01–JD04）——那是规则文档，怎么变成 AI 能实际执行的流程？载体是 Skill 里的 SKILL.md。它把方案翻译成三样东西：
- 输入输出定义：岗位详情 + 候选人简历 → 四份过程文档 + 一份最终 HTML
- 四环节执行规则：每个环节的步骤、产出物、失败信号与停机条件
- 停机点交互：三处点选式询问的具体触发时机与选项结构
方案负责"标准"，SKILL.md 负责"执行"，实测负责"证明规则成立"——三者缺一不可。
八、如何复用：安装即用
获取 Skill「JDWorkFlow-LL」（复制整个 JDWorkFlow-LL 文件夹，可向作者索取或自建），放到工作区即可使用：
你的工作区/.trae/skills/JDWorkFlow-LL/
重启 TraeWork（或新建会话）后，对 AI 说一句：
用 JDWorkFlow-LL 分析这份 JD 和这几份简历
输入只需要两样东西：岗位 JD（文字 / 截图 / PDF 均可）和候选人简历（1 份或多份，PDF / 图片 / 文字均可，扫描件自动 OCR）。接下来全自动执行，三处停机点点选决策即可。
跑完得到一个文件夹：
<岗位名>/
01-岗位画像.md 标尺（硬性/期望/加分/程序检查 + 权重）
02-结构化简历档案.md 全部候选人结构化档案
03-简历评估结果.md 全部候选人评估卡（100 分制 + 面试包）
04-交叉对比分析报告.md 对比矩阵、分群、面试顺序、汇报版、终审记录
05-简历分析AI工作流报告-<岗位名>-<日期>.html 最终交付
九、复盘：这条路最值得借鉴的地方
- 先想透业务再谈技术。搭建的第一步不是写代码，而是把每个环节拆成"干什么、怎么干、干成什么样"，方案先于实现。
- 用真实案例验证。方案初稿和最终定稿之间，隔着一轮完整实测——实测暴露的问题（缺失处理、证据不足的边界）反过来修正了方案。
- 请领域专家把关。自己不是招聘专家，就把草案交给专家评审，外部视角补上了内部盲区。
- 把"不猜"当第一原则。AI 最危险的行为是静默脑补，显式标记缺失与推断，是整套流程可信度的基石。
这套方法不只适用于简历：任何"多个输入、需要统一判断、结论要给别人看"的场景——供应商评估、方案比选、项目验收——都能套同一副骨架：先定标尺、再取证据、后做比对、全程留痕。骨架是通用的，变的只是要素。
这套工作流目前覆盖到"给出面试建议"为止。下一步的思考方向是：把面试结果反馈纳入标尺校准，让流程基于真实结果持续修正——这是当前方案刻意没有纳入的部分（依赖面试结果、属于招聘流程更下游），值得继续探索。
如果你也做过类似的"流程化 AI 工作流"，欢迎在评论区聊聊你的设计取舍：AI 自动执行到什么程度、人留在哪个环节把关，是你觉得最舒服的边界？
本文为社区技术分享，候选人信息均已匿名化处理。欢迎交流讨论。
简历分析工作流资料（欢迎交流）割不到韭菜的镰刀.zip (535.7 KB)