我在招聘季的真实状态大概是这样的岗位放出去两三天邮箱就被简历塞满PDF、DOCX、甚至图片版简历混在一起。上季度我们集中招 6 个技术岗收到 50 份简历我用 WorkBuddy 在 30 分钟左右全部筛完并且生成了一份带总分、带评分明细、带风险提示的评估报告。说实话最早我也就是拿它当个聊天助手用真正让我改变看法的是把它从“问答式聊天”变成“按规则批量执行”之后。这篇就完整记录一下我是怎么把 WorkBuddy 用成简历筛选助手的包括自定义指令怎么写、批量执行怎么做、踩过的坑比如 502 write EACCES怎么排查以及最后如何把整套流程封装成 Skill。如果你也在做招聘、HRBP或者日常需要批量处理文档、汇总表格这套思路可以直接抄走。1. 面对50份简历为什么我选了WorkBuddy而不是手动筛1.1 招聘场景里的重复劳动到底卡在哪很多人觉得筛简历不就是“看嘛”看一眼工作年限、看一眼技术栈、再瞄一眼公司背景合适就约面试。但实际批量操作过 50 份以上的人都知道最累的不是“看不懂”而是“标准漂移”。同样的简历上午看可能觉得“这个人还行”下午连续看到第 20 份时你的耐心和注意力已经开始下降打分标准会不自觉地变化。一个人手动筛 50 份简历按照每份 5 分钟算差不多要连续 4 个多小时大概率会腰酸眼涩而且最终给出的结论很难统一。如果中间掺杂着几份排版混乱、重点不突出的简历还会直接影响判断效率。所以我需要的不是“一个能聊天的 AI”而是一个能稳定执行固定流程、并且每次都按同一套标准打分的工具。WorkBuddy 在这件事上的优势在于它可以先把筛选规则定义好然后批量读文件、解析内容、生成结构化输出。换句话说它不是替我“看一眼”而是替我把整套筛选流程跑一遍。1.2 WorkBuddy 的定位不只是一个聊天助手我第一次安装 WorkBuddy 的时候说实话没抱太高期望以为又是一个聊天机器人外壳。但后来我发现它的定位和普通问答工具不太一样它更像一个自动化工作台能够读取本地文件、执行命令、调用外部模型、输出结构化报告。你可以把 WorkBuddy 理解成“一个能读懂操作手册的实习生”。你给它一份清清楚楚的规则它后续处理任务时就会严格按规则走你不给规则它就只能靠常识自由发挥结果自然不可控。这和很多人用 AI 工具“随便聊两句”的体验完全不同。在简历筛选这个场景里WorkBuddy 最核心的价值有三个批量处理能力一次读取目录下多份简历按流程逐份解析、评分、汇总。规则可复用自定义指令写好后后续所有任务都会带上这套规则不需要每次重复解释。输出可结构化评估结果可以用 JSON、Markdown 表格等形式输出方便二次处理也能直接放进周报或汇报文档。这也是为什么我最终没有用最简单的“把简历全文复制进聊天框”这种笨办法而是选择了完整跑一套 WorkBuddy 自动化流程。1.3 和 Claude Code、豆包这类工具放一起比有很多朋友问过我和其他工具怎么选。我这里不是要做全面对比只说我实际用下来最直接的感受。Claude Code 我很熟代码生成、项目级重构确实强但它的主场景偏开发多一点用来自定义一套“简历评估规则”并批量执行需要自己写不少胶水脚本。豆包这类工具日常问答、文案润色很轻快但要让它稳定地按同一套标准批量处理 50 份本地文件工作流上没 WorkBuddy 这么顺。选 WorkBuddy 还有一个很现实的原因它的 Skill 机制对“流程沉淀”特别友好。我这次做完简历筛选之后把整套流程封装成了 Skill下一次再来一批简历一条命令就能跑完哪怕换一个不懂规则的同事来操作结果也能保持一致。这个能力长期用下来省下的时间远超安装配置那会儿的投入。2. 动手前先定规则把“好简历”翻译成机器能懂的指令2.1 评估维度拆解硬性门槛和软性加分项在让 WorkBuddy 开始工作之前第一件事不是写代码而是把“什么是好简历”这件事想清楚。AI 不会像人一样看一眼就凭直觉判断它需要明确的评估维度、权重和判断依据。我按技术岗位的常规要求把评估维度拆成四块评估维度权重判断要点技能匹配度40%岗位 JD 中的核心技能是否在简历中出现是否有项目实战支撑项目经验匹配度30%项目方向是否贴近岗位技术深度如何有没有量化结果稳定性20%工作经历是否频繁跳槽平均在职时长是否过短亮点与成长性10%是否有带团队、开源项目、技术博客、专利、竞赛奖项等这里要特别注意评估维度里不设置年龄、性别、婚育等任何与岗位胜任力无关的字段。筛选的目标是“人和岗位匹配度”不是给人贴标签。规则写得越干净结果越经得起推敲。2.2 自定义指令的写法一次定义所有任务生效WorkBuddy 的自定义指令你可以理解为一段“常驻系统提示词”。它写在哪里决定了它在什么范围内生效。我的习惯是凡是涉及长期任务的判断规则都放进全局自定义指令里这样后续所有任务都会自动携带这套规则而每次任务独有的参数比如岗位 JD、简历目录路径则在任务启动时再指定。写自定义指令时我有一个固定的框架角色定义 任务范围 输入说明 评估维度 输出格式 约束条件看起来像废话但实际很多人写不好指令就是因为只写了“角色定义”和“任务范围”没有把输出格式和约束条件写清楚。结果 AI 输出了一段洋洋洒洒的散文没法直接汇总那跟你自己手动看有什么区别输出格式这块我强烈建议用 JSON 或固定 Markdown 表格。结构化输出不仅是给机器看的更是给后续汇总、排序、二次分析用的。没有结构的评估报告价值至少打五折。2.3 一个可复制的简历评估指令模板这是我实际在 WorkBuddy 自定义指令里使用的模板做了简化后贴出来你可以直接改成自己的规则# 角色 你是一位资深招聘顾问擅长技术岗位初筛。 # 任务 对指定目录下的简历进行逐份评估输出结构化评估报告。 # 输入说明 - 岗位JD文件job_description.md - 简历目录resumes/ - 输出目录reports/ # 评估维度与权重 1. 技能匹配度40分岗位JD要求的核心技能是否匹配必须有简历中的具体描述作为证据。 2. 项目经验匹配度30分项目方向与岗位的关联度技术深度是否包含量化结果。 3. 稳定性20分平均在职时间小于1年视为频繁跳槽酌情扣分。 4. 亮点与成长性10分带团队、开源项目、技术博客、专利等。 # 输出格式 每份简历输出以下JSON结构 { file_name: 简历文件名, total_score: 0, score_detail: { skill: 0, project: 0, stability: 0, highlight: 0 }, assessment: { summary: 一句话总结, evidence: [支持结论的简历原文片段], risk: [需要关注的疑点] }, verdict: recommend / pending / reject } # 约束条件 - 只依据简历中实际存在的内容进行判断不得脑补。 - 如果简历内容无法解析verdict标记为unreadable不要强行打分。 - 所有输出使用中文。 - 评分标准跨简历保持一致。写完这版指令之后我做的第一件事不是直接跑 50 份而是先拿 5 份简历试跑。这一招非常重要几乎能避免后面 90% 的返工。3. 30分钟筛完50份简历的完整执行流程3.1 环境准备安装WorkBuddy要注意的细节先说安装。我这边主力环境是 Linux直接用的命令行版本。Windows 上跑也是可以的但如果命令行工具比较吃系统环境我建议优先用 WSL能少踩很多坑。安装完之后先用一条命令确认版本能正常输出版本号再继续。wb --version接着要确认模型 API 的配置。WorkBuddy 本身是一个工作台模型调用的部分需要你有可用的模型服务。首次配置时把 API Key 和模型名称填对然后跑一个最简单的任务测试连通性。很多新手在这里卡住其实问题往往不是 Key 不对就是网络环境不对先用最小测试定位。还有一个我踩过的坑尽量不要用sudo去跑 WorkBuddy。用 root 权限跑任务生成的输出文件属主是 root后面你想用普通用户去改、去删都会遇到权限问题非常麻烦。3.2 文件整理简历目录的标准化命名50 份简历如果文件名五花八门比如“新建文档.pdf”“张三的简历最终版.pdf”后面报告生成之后你很难快速把评估结果对应回原始邮件。我的做法是先花 10 分钟把所有简历统一命名命名规则是“日期_姓名_应聘岗位_工作年限.后缀”。原始文件名整理后文件名新建文档.pdf20240510_张三_Java后端_5年.pdf李四-简历-2024.docx20240510_李四_Java后端_3年.docx王五的最新简历.PDF20240510_王五_Java后端_8年.PDF再建一个工作目录把岗位 JD 和简历目录分好~/work/screening/ ├── job_description.md ├── resumes/ └── reports/目录结构越简单越好。这样 WorkBuddy 在读取文件时路径清晰输出报告也容易归档。3.3 执行筛选从读取、解析到打分的全流程先跑 5 份试水确认输出格式没有任何问题再全量跑。我实际用的命令非常简单大概长这样cd ~/work/screening wb run resume-screening \ --input resumes \ --jd job_description.md \ --output reports \ --batch-size 10不同版本的 WorkBuddy 命令参数可能不完全一样我这里展示的是我自己的封装习惯核心思路是把“输入目录”“岗位 JD”“输出目录”“每批处理数量”四件事通过参数固定下来避免每次都要临时解释。WorkBuddy 拿到任务之后大致会按这个流程工作读取简历目录罗列全部文件。逐份解析文件内容PDF 转文本、DOCX 抽文字。结合岗位 JD按自定义指令中的维度逐项打分。输出 JSON 格式评估结果并汇总到总报告中。根据总分和 verdict 状态生成排名。全程不需要我盯着它会一边处理一边把中间结果写到 reports 目录。这也是我敢把 50 份直接交给它的原因。3.4 自动评估报告的内容结构跑完之后WorkBuddy 生成的评估报告包含这些内容总览统计简历总数、recommend 数量、pending 数量、reject 数量。排名列表按总分从高到低排列包含姓名文件名、总分、核心亮点。留存明细每份简历的 score_detail 和 assessment。风险提示每份简历的 risk 字段集中列出需要面试官重点确认的疑点。我摘几条脱敏后的示例记录大概长这样文件总分verdict一句话总结20240510_张三_Java后端_5年.pdf92recommend5年Java后端经验项目经历与岗位高度匹配有量化性能优化成果20240510_李四_Java后端_3年.docx58pending基础技能符合但项目集中在维护型需求缺少高并发场景经验20240510_王五_Java后端_8年.PDF41reject工作经历丰富但近两年方向偏向管理与后端开发岗位匹配度较低这个报告直接就可以放进招聘周报不用我再额外整理。4. 实战中踩过的坑权限报错、输出中断和解析乱码4.1 502 write EACCES写文件权限问题的排查链路第一次跑全量的时候我遇到过一个很典型的报错502 write EACCES。刚看到这个报错时我一度以为是 WorkBuddy 本身出了什么问题后来排查下来才发现问题出在操作系统权限上。EACCES是 Linux 系统里的权限不足错误write EACCES的意思是某个进程在尝试写文件时被系统拒绝了。我当时的目录结构和权限情况是这样的ls -ld /tmp/workbuddy-task # d-wx--x--x 2 root root 4096 ... /tmp/workbuddy-task问题很明显我把任务目录建在了/tmp下面并且目录的属主是 root而我是用普通用户运行 WorkBuddy 的普通用户对这个目录没有写权限。申请写权限时报错直接抛出了502 write EACCES。排查链路也很简单先看报错日志确认是在哪一步写入失败。用ls -ld检查目标目录的属主和权限。发现是权限问题后要么chown改属主要么直接把任务目录移到当前用户的家目录下。重新运行任务确认写入正常。最省心的做法就是我前面提到的从一开始就在~/work/screening/这类用户目录下运行任务而不是图方便放在/tmp或系统目录下。以后看到类似报错第一反应不应该是怀疑 AI 坏了而是先查文件系统权限。4.2 内容输出慢/中途卡住怎么兜底全量跑 50 份的时候我还遇到过一个更现实的场景任务进行到一半输出突然变慢甚至卡住不动。这个现象在批量任务里很常见原因通常是上下文太长、单次输出内容过多或者网络请求超时。我的兜底方案有三个分批处理不要一口气吞下所有简历。把 50 份简历拆成 5 批每批 10 份跑完一批再跑下一批。这样即使中间某一批失败也只是损失一小部分进度不会全部重来。cd ~/work/screening for i in 01 02 03 04 05; do wb run resume-screening \ --input resumes/batch_$i \ --output reports/part_$i.json \ --jd job_description.md done每份简历单独输出结果文件。我后来调整了指令要求对每份简历生成一个独立的 JSON 文件而不是所有结果挤在一个大文件里。这样后续合并时哪份失败了就只重跑哪份效率高得多。参数调低随机性。评分类任务不需要太多创意温度参数尽量调低让模型输出更稳定。如果 WorkBuddy 的任务参数里支持 temperature直接设为 0 就好。这个细节很多人忽略但对“多次结果一致”非常关键。4.3 PDF解析乱码简历里的“现代五项”变天书另一个高频问题是 PDF 简历解析乱码。文本型 PDF 在字符编码提取时偶尔会出现乱码扫描件更是直接变成一堆无意义的字符。最夸张的一次简历里的 “Java、Spring、MySQL” 被解析成了完全不可读的乱码别说评估连模板都给乱了。这个问题不像权限问题那样有标准答案更多是“熟练工经验”。我的处理顺序是先判断简历是文本型 PDF 还是扫描件。文本型 PDF 用解析工具直接抽取文本如果乱码就换一种抽取方式。扫描件直接走 OCR把图片里的文字识别出来再交给 WorkBuddy。如果某份简历实在无法解析就在指令里明确要求输出unreadable不要强行打分。这里有一个很容易被忽略的点很多人在简历解析失败后会让 AI “根据经验猜一下”。这绝对是大忌。评估报告一旦混入脑补内容整个筛选结果的可信度都会被打折扣。宁可标记为 unreadable也不要让模型凭空推理。5. 筛选工作流沉淀成Skill以后每次只用一条命令5.1 把流程封装成Skill的步骤跑通一遍之后我想的很清楚的一件事是这次流程如果只服务“这一批简历”那价值有限。把它沉淀成 Skill下次不管是谁来操作直接一条命令调用才是真正省时间的开始。WorkBuddy 的 Skill 机制本质上就是把前面写的自定义指令、流程步骤和参数定义打包成一个可复用单元。我在本地维护的 Skill 目录结构大致是这样的skills/ resume-screening/ SKILL.md params.json samples/ 优秀简历示例.pdf 淘汰简历示例.pdfSKILL.md里写的是完整任务定义包括角色、评估维度、输出格式、约束条件。params.json里定义的是输入参数比如input_dir、jd_file、output_dir。samples/里放的是历史典型简历作为 few-shot 示例帮助模型在切换模型后也能保持评分标准。封装好之后调用就变成了wb run resume-screening \ --input resumes \ --jd job_description.md \ --output reports和之前唯一的区别是不再需要每次把所有规则重新讲一遍因为 Skill 已经把规则固化下来了。团队里其他人使用的时候也不用担心他们不会写指令。5.2 接DeepSeek降成本模型切换的注意点跑完 50 份简历我也算了一笔账如果全用默认模型成本还是有点肉疼的。后来我把 WorkBuddy 接入了 DeepSeek用国产模型来跑这类批量评分任务成本降了一截整体效果也能接受。接入模型不复杂核心就是改配置export WB_MODEL_PROVIDERdeepseek export WB_MODEL_API_KEYsk-xxxxxxxx export WB_MODEL_NAMEdeepseek-chat但我要特别提醒三个切换模型后的坑第一输出格式可能会漂移。不同模型对 JSON 输出的遵循程度不一样。切换后一定要拿之前的旧简历重新跑一遍对比看看 JSON 结构是否还稳定。第二评分一致性需要验证。同一个 Skill在 A 模型上的打分逻辑和 B 模型上通常会有差异。我实际对比下来DeepSeek 在中文简历理解上并不吃亏但你需要和默认模型的结果做一次交叉校验再正式投入使用。第三few-shot 示例是保命符。如果切换模型后发现评分不稳定就在 Skill 的samples/里加入一份“绝对高分简历”和一份“绝对低分简历”的完整示例。模型有了参照物打分会稳很多。5.3 后续扩展定时任务、自动通知、多平台简历收集流程跑顺之后我开始琢磨怎么让它更省人力。目前已经在探索的两个方向定时扫描目录新简历自动触发筛选。把wb run命令挂到 cron 定时任务里每隔固定时间扫描简历收件目录有新文件进来就自动跑一次筛选。配合邮件或机器人通知报告生成后自动推送到群里。通知这一块最省事的方案就是 Webhook。报告生成之后让 WorkBuddy 调用一个 Webhook 地址往企业微信群、飞书群或者钉钉群推送一条“本次筛选完成共 X 份简历推荐 X 份”的消息。这样团队里所有人第一时间都能看到结果。多平台简历收集后的统一清洗。我日常收到的简历有一部分来自招聘平台导出文件名和格式乱七八糟。在进入筛选流程前先做一轮标准化清洗把文件重命名、格式统一然后再交给 WorkBuddy。这个过程也可以固化成另一个 Skill跟筛简历串成一条流水线。回看这次实战我最深的体会是WorkBuddy 这类工具真正的价值不在于“能聊天”而在于“能把规则固化下来并稳定地重复执行”。50 份简历 30 分钟筛完只是表面结果背后更值钱的是那套可以被反复调用的筛选流程。最后再说一句我个人的操作习惯每次跑完一批简历我都会手动抽看 5 份 WorkBuddy 给很高分和 5 份给很低分的简历确认没有明显的误判。AI 筛完只是帮你把范围缩小最后拍板这种事还是得留在自己手里。