上周帮一个做招聘的朋友处理简历筛选，他在招聘平台挂了职位，三天收了80多份简历，各种格式混在一起，看完他差点崩溃。他花了一个下午硬读，最后只面了3个人，其中一个还不匹配。我当时就跟他讲，这种纯体力的初筛工作，就不该占用人的时间。我打开 WorkBuddy，花半小时搭了一套简历筛选工作流，把50份简历丢进去，30分钟不到全部筛完，还自动生成了每个人一份评估报告，按他要求的格式排好版。今天就把这套流程、指令模板、还有我踩过的坑完整记录下来。
这篇文章适合谁看？一类是HR、招聘负责人，手头简历量大、标准重复；另一类是技术负责人或者创业团队，需要快速过一遍候选人技术底子；还有一类是刚接触 WorkBuddy、想知道这东西除了写代码还能干嘛的人。我会从环境搭建、核心概念、指令编写、实操记录到问题排查一条龙讲清楚，让没摸过 WorkBuddy 的人也能照着重现。
1. 为什么是 WorkBuddy：简历筛选痛点的解药
1.1 批量筛选简历的三大痛点
先聊一下痛点。但凡经历过批量简历初筛的人，应该都懂这三件事有多折磨人。
第一是结构化信息抽取难。每份简历格式都不一样，有的用 Word，有的是 PDF，有的直接是 JPG 截图。你希望快速看到“学校、工作年限、技能栈、项目经历”，但实际看到的是一堆五颜六色的排版、各种花哨图标、模板自带的装饰性内容。人眼能快速定位关键信息，但看50份之后眼睛就花了，容易漏掉真正重要的细节。
第二是筛选标准不统一。同一个 HR 上午看简历和下午看简历，心情不一样，手松手紧也不一样。遇到一份中间水平的简历，今天觉得“可以约”，明天可能就觉得“算了再看看”。这种主观判断导致候选人在不同时间点被评估的结果不同，面试官收到推荐名单时也很难理解这个候选人到底强在哪。
第三是汇总报告费时间。就算你把50份简历全部看完，你还得把每个候选人的亮点、风险点、推荐意见整理成一份汇总文档。这个整理动作本身可能又要花两个小时。以前我朋友的做法是先把信息抄到 Excel 里，再手动标星，最后开会时逐个念——低效，但没有人觉得有什么不对。
有了这三个痛点，自动化筛选的需求就很明确了。我需要的不是“帮我写个脚本”的工具，而是一个能理解简历语义、能按我定义的规则批量执行、还能输出结构化结果的 AI 工作台。这就是我用 WorkBuddy 的原因。
1.2 WorkBuddy 的核心能力拆解
WorkBuddy 是一款 AI 工作台类工具，核心思路是把大模型能力和办公自动化场景结合到一起。它和我之前用过的 Claude Code、CodeBuddy 这类偏代码生成工具定位不太一样，更偏“日常工事自动化”。
它比较关键的能力有几个：
Skill 技能包机制。你可以把一套完整的工作流封装成一个 Skill，下次直接调用。比如我做的“简历筛选助手”就是一个 Skill，里面包含了筛选规则、评分权重、输出格式。以后再有简历进来，一键就能跑，不用重新写规则。
自定义指令（Instructions）。相当于全局规则，设置一次，后面所有任务都会遵守。比如我设置了一条“所有输出使用简体中文，不要我的称呼，不要客套话，直接给结果”。这个功能非常实用，等于把个人工作习惯固定下来，不用每条指令都重复说明。
可接入不同模型 API。WorkBuddy 默认有内置模型，但你也配置自己的 API Key，比如接入 DeepSeek 的 API。我自己测试下来，用 DeepSeek 做中文简历信息抽取，速度和准确率都不错，成本也比默认模型低不少。
批量文件处理能力。这是筛选简历最重要的一环。你给它一个文件夹路径，它能自动遍历文件夹下的所有简历文件，逐个读取、处理、输出，最后汇总成一份总报告。相当于一个小型批处理引擎。
这些能力组合在一起，简历筛选这类“重复阅读+固定规则+结构化输出”的任务，正好是它的强项。
1.3 它和同类工具的区别
有人可能会问，这类工具是不是和 Claude Code 差不多？我实际用下来，区别还挺明显。Claude Code 更注重代码仓库内的开发任务，比如读代码、改 bug、写测试。CodeBuddy 也偏开发场景。WorkBuddy 的重点在“办公室工作”而不是“编程工作”，它在处理文件、整理表格、汇总报告这些场景上更顺手。
我画一个简单对比参考：
| 维度 | WorkBuddy | Claude Code | CodeBuddy |
|---|---|---|---|
| 侧重点 | 办公自动化、批处理任务 | 代码开发 | 代码开发 |
| 批量文件处理 | 强 | 一般 | 一般 |
| 自定义 Skill 工作流 | 支持 | 有限 | 有限 |
| 自定义指令全局生效 | 支持 | 支持但偏系统角色 | 支持 |
| 适合场景 | 简历筛选、报表汇总、文本抽取 | 代码库维护、重构 | 代码生成、调试 |
当时我选择 WorkBuddy 就是看中它可以脱离代码仓库运行，直接操作普通文件夹里的文件。简历筛选这种任务，跟 Git 仓库一点关系都没有，用代码工具反而是杀鸡用牛刀。
2. 搭建 WorkBuddy 简历筛选工作流的前置准备
2.1 安装与初始配置
WorkBuddy 的安装不算复杂。官方提供了 Windows、macOS、Linux 的安装包。我自己主力机是 Windows，后面为了方便测试又在一台 Linux 服务器上也装了，两边跑同一套工作流没问题。
Windows 安装就是下载安装包一路下一步，装完打开客户端，用账号登录。Linux 版稍微特殊一点，官方提供的是压缩包，解压后直接运行里面的二进制文件就行。如果你在 Linux 上遇到权限相关的报错，多半是二进制文件没有执行权限，命令行加一下chmod +x workbuddy就能解决。
装完之后第一件事是检查版本，第二件事是登录账号。WorkBuddy 是按账号走的，登录后才能同步 Skill 和自定义指令。这里提醒一句，如果公司的网络环境比较特殊，登录可能会失败，这时候检查一下系统时间和代理设置。
然后就是模型配置。WorkBuddy 默认模型用着还行，但如果你要处理大量中文文本，建议配置 DeepSeek 的 API。操作路径是：设置 → 模型配置 → 自定义 API，填入你的 API Key 和模型名称。DeepSeek 的接口兼容多数场景，我用的模型在中文语义理解上表现很稳定，长文本处理也扛得住，关键是价格便宜，跑50份简历成本可以忽略不计。
配置完成后，建议先用一句话测试：“请回答：模型接入成功了吗？”如果正常回复，说明环境没问题。
2.2 核心概念：Skill 与自定义指令怎么用
刚开始用 WorkBuddy，最容易混淆的是两个概念：Skill 和自定义指令。我一开始也绕了一圈，这里直接讲清楚。
Skill是“打包好的工作流”。你可以理解为一份菜谱：菜谱里有原料清单（输入文件）、烹饪步骤（处理流程）、装盘方式（输出格式）。做一次简历筛选，如果你把所有规则、步骤、格式要求都写在一次对话里，那下次你还得重新写一遍。但是把它封装成 Skill 后，下次只要说一句“跑简历筛选 Skill”，设置好的整套流程会自动执行，不用重复输入。
WorkBuddy 有一个 SkillHub 市场，可以直接安装别人做好的 Skill。比如热词里提到的superpowers，就是一套增强型技能集合，装上之后会多出很多高级功能。第一次用的时候我装了 superpowers，里面自带了一些文本处理、批量归纳的技能，可以用作参考，后面我自己写专用 Skill 时也参考了它的写法。
自定义指令是“全局规则”。它不绑定某一个任务，而是对你所有的对话、所有的任务都生效。我在 WorkBuddy 里设置了几条规则：
始终使用简体中文回答。 不要输出安慰性或客套性的内容，直接给结论。 涉及列表输出的内容，用 Markdown 表格呈现。 遇到信息缺失，标注“待补充”，不要猜测填写。
这几条规则写在自定义指令里，之后无论跑什么任务，它都会遵守。把个人偏好沉淀成指令，省掉了每次重复交代的麻烦。
Skill 和自定义指令的关系可以这样理解：自定义指令是“宪法”，Skill 是“专项法律”。宪法管全局，专项法律管特定场景。
2.3 初装最容易踩的权限与路径问题
我第一次运行简历筛选任务的时候，直接就报了个权限错误，报错信息类似502 write EACCES。当时愣了一下，后来排查发现是工作目录权限不够。
WorkBuddy 在处理文件的时候，需要在工作目录下创建临时文件和输出文件。如果你把工作目录放在系统保护目录（比如 Windows 的C:\Program Files，或者 Linux 的/root下某个受限目录），程序没有写权限，就会报这个错。
解决办法很简单：第一，新建一个专门的工作目录，比如D:\WorkBuddy\ResumeFilter，权限全开；第二，在 WorkBuddy 的设置里把默认工作目录改到这个文件夹。Linux 环境下再用chmod给目录加写权限，问题就解决了。
还有一个路径问题容易被忽视。简历文件名一定不要带奇怪的字符，像括号、井号、百分号都有可能让文件读取失败。我把所有简历统一命名为“姓名-职位.pdf”这种格式，跑了30份没有一份失败。
3. 50 份简历 30 分钟筛完：从需求拆解到指令编写
3.1 先把筛选标准写成“给 AI 看的规则”
很多人用 AI 工具跑简历筛选，上来就说“帮我看看这些简历哪些合适”，效果往往不好。原因是筛选标准没有量化，AI 只能给一个模糊判断。想让 AI 输出可用的结果，你得先把筛选标准结构化成规则。
我在写规则之前，先问了自己三个问题：硬性门槛是什么？加分项是什么？一票否决项是什么？
以招聘一个“高级前端开发”为例，我当时的规则是这样的：
硬性门槛（只要不满足就直接不通过）：
- 本科及以上学历
- 有 3 年以上前端开发经验
- 简历中没有明显造假迹象
加分项（满足越多，候选人的评分越高）：
- React 或 Vue 实际项目经验
- 有性能优化实践案例
- GitHub 有高质量开源项目
- 有过带团队或者指导新人的经验
- 技术博客或者公开分享记录
一票否决项：
- 简历中出现主要技能与职位方向完全不符
- 工作经历有明显且无法解释的空档
- 学历信息与岗位硬性要求严重不匹配
把这些规则写成文字，放到 Skill 里，AI 就能按照统一标准去评估每一份简历。这也是自动化的核心意义：标准定了，结果才不会因人而异。
3.2 批量处理逻辑设计
规则写清楚之后，还要考虑 WorkBuddy 怎么批量处理文件。一开始我以为它可以自动扫描任意目录，后来发现它需要你先把目录结构规划好，数据越规整，处理越顺利。
我推荐这样组织目录：
D:\WorkBuddy\ResumeFilter\ ├── input\ # 存放待筛选简历，50份放这里 ├── output\ # 输出报告 │ ├── individual\ # 每个候选人单独一份评估报告 │ └── summary\ # 汇总报告 └── rules\ # 存放筛选标准配置简历都放进input文件夹后，在 WorkBuddy 对话里输入类似“读取 D:\WorkBuddy\ResumeFilter\input 目录下的所有简历文件，按筛选规则逐份评估”的指令，它就会自动遍历。遍历过程中遇到无法识别的文件（比如纯图片或者扫锚件）会单独标记，不至于因此中断整个流程。
这里有一个小技巧：尽量把 PDF 转成纯文本格式再放入 input 文件夹。WorkBuddy 虽然能直接读 PDF，但对排版复杂的 PDF 识别率会下降。我当时写了一个 Python 小批量脚本，把 PDF 转成 txt，再丢给 WorkBuddy，识别准确率立刻上来了。
3.3 自定义 Skill 的完整示例
下面给出我实际用的 Skill 配置。不需要完全照抄，重要的是理解结构：Skill = 输入声明 + 处理规则 + 输出格式。
Skill 的配置结构大概是这样的：
name: resume-filter description: 批量筛选简历并生成结构化评估报告 trigger: 跑简历筛选 input: resume_dir: D:\WorkBuddy\ResumeFilter\input rules: rules\filter_rules.md output_dir: D:\WorkBuddy\ResumeFilter\output processing: - read all files from resume_dir - for each file: - extract candidate info - screen by hard requirements - score by bonus items - check veto items - generate individual report - generate summary report rules: hard_requirements: - 学历: 本科及以上 - 经验: 3年以上前端 bonus_items: - React/Vue 经验 - 性能优化案例 - 开源项目 - 带团队经验 veto_items: - 技能方向与岗位完全不符 - 工作经历空白无法解释 output_format: individual_report: - 基本信息 - 评分明细 - 硬性门槛结果 - 加分项命中情况 - 一票否决项 - 推荐意见 summary_report: - 总人数 - 推荐面试人数 - 待定人数 - 不通过人数及原因统计实际配置里我会把这些规则写得更详细，比如学历要从哪个字段提取、工作年限怎么计算、加分项怎么判断命中不命中。WorkBuddy 支持自然语言描述规则，所以不需要写复杂的正则表达式，你说清楚“什么是什么”就行。
3.4 自动出评估报告的格式设计
WorkBuddy 跑完后自动生成的评估报告，我建议格式要固定下来。格式固定有好处：一是方便后续快速浏览，二是可以方便地导入 Excel 做二次分析。
我设计的个人评估报告长这样，Markdown 格式：
# 候选人：张三 ## 基本信息 - 学历：本科（软件工程） - 目标岗位：前端工程师 - 目前薪资：未填写 ## 硬性门槛 - 学历要求：通过 - 经验要求：通过（4年） ## 加分项命中 - React 实际项目经验：命中（3个项目） - 性能优化案例：命中（首屏时间从 3s 优化到 1.2s） - GitHub 开源项目：未命中 - 带团队经验：命中（2人小团队） ## 一票否决项 - 无（方向匹配，经历连贯） ## 评分 - 综合得分：82 / 100 - 推荐级别：推荐面试这种报告最大的价值是“可解释”。你不用重新翻简历就知道这个候选人为什么推荐、为什么淘汰。HR 拿着这种报告，开会时不用再口头解释半天，直接看报告就懂。
汇总报告我用表格输出，效果更直观：
| 候选人 | 学历 | 经验 | 硬性门槛 | 加分项 | 否决项 | 综合得分 | 推荐级别 |
|---|---|---|---|---|---|---|---|
| 张三 | 本科 | 4年 | 通过 | 3/5 | 无 | 82 | 推荐面试 |
| 李四 | 硕士 | 2年 | 不通过 | 1/5 | 无 | 55 | 不通过 |
| 王五 | 本科 | 5年 | 通过 | 2/5 | 有 | 45 | 不通过 |
整个筛选过程就像一个标准化的漏斗，从50个人里快速捞出来最有希望的几个。
4. 实操记录：30 分钟真实跑完 50 份简历
4.1 第一次跑：问题堆成山
理想很丰满，现实很骨感。第一次把50份简历丢进 WorkBuddy 跑，情况并不顺利，甚至有点狼狈。我总结了几类问题。
第一类是简历文件格式不统一。有的 PDF 是扫描件，WorkBuddy 无法直接提取文本；有的 Word 文档上有水印和页眉页脚，干扰了信息定位。结果就是一部分简历的信息抽取结果不完整，学历字段空着，工作年限没算出来。
第二类是输出内容不稳定。第一次跑出来的50份个人报告里，有十几份的评分规则尺度跟其他报告不一致。比如同样的“有 React 经验”，有的报告加了5分，有的只加了3分。原因是 Skill 里的加分项描述不够具体，WorkBuddy 在执行时有了“自由发挥”的空间。
第三类是报告格式乱。有的报告输出的是表格，有的是列表，有的直接在段落里混着写。放在一起看，风格很不统一。
这些问题说明一个道理：AI 自动化不是写一次规则就一劳永逸，需要根据真实输出不断迭代规则。
4.2 调优后的完整跑批流程
我花了小半天调整 Skill 规则，把每个加分项的“命中标准”写得更加具体。比如“React 实际项目经验”改成“在项目经历或技能标签中出现 React，且至少有一个项目以 React 为主技术栈”。把标准细化后，AI 对每份简历的判断口径就一致了。
调优之后再跑，整个流程顺利多了。下面是当时的实操记录：
- 把50份简历放进
D:\WorkBuddy\ResumeFilter\input文件夹，文件全改名为“姓名-职位.pdf”。 - 用脚本把 PDF 批量转成 txt 文本，存入
input_text目录。 - 在 WorkBuddy 对话中输入指令：“使用 resume-filter Skill，处理 input_text 目录下的所有文件，按规则逐份评估，输出到 output 目录。”
- 等待执行。50份简历，逐份处理，耗时大约 25 分钟。
- 检查
output\individual目录，生成50份个人评估报告；检查output\summary，生成1份汇总表。
整个跑批过程中我不需要盯着看，每处理完几份，它会自动向输出目录写入报告。25分钟跑完，我趁这个时间开了一个会，回来直接看结果。
最终从50人里筛选出7份推荐面试、9份待定、34份不通过。推荐面试的7人里，和朋友手动筛出来的结果对比，重合了6人，另外1人是他之前觉得一般、但系统认为值得聊一聊的。后来他抱着试一试的心态约了这个人面试，三面之后还真发了 offer。这也是一个意外收获：AI 筛选能帮你发现那些“第一眼不惊艳、但实际很扎实”的候选人。
4.3 手动筛选和 WorkBuddy 的效果对比
我把这个对比整理成一张表，方便大家直观感受差距：
| 维度 | 纯手动筛选 | WorkBuddy 自动筛选 |
|---|---|---|
| 耗时 | 3 到 4 小时 | 25 分钟 |
| 标准一致性 | 随状态波动 | 稳定统一 |
| 报告产出 | 无，靠记忆和笔记 | 每人一份完整报告 |
| 遗漏风险 | 高，易漏掉细节 | 低，规则覆盖所有维度 |
| 扩展复用地 | 每次重来 | Skill 一键复用 |
这个对比不是想说 AI 完全替代人，而是把人的精力从“阅读和体力活”里释放出来，让你只花精力在真正重要的环节，比如面试、沟通、判断软素质。
5. 常见问题与排查技巧实录
5.1 权限报错：502 write EACCES
这是我在 Windows 环境第一次跑 WorkBuddy 遇到的报错，热词里也有人问，解释一下。
502 write EACCES本质上是一个写权限错误。WorkBuddy 在向某个文件夹写入临时文件或输出文件时，没有权限。原因一般是工作目录设置在系统保护目录，或者目录被其他进程锁定。
排查步骤很清晰：
- 检查 WorkBuddy 的设置，确认当前工作目录是什么。
- 看工作目录是否在系统保护路径下，如果是，换到用户目录或数据盘。
- 确认目录没有被 OneDrive、坚果云之类的同步盘锁定，同步盘有时候会故意锁文件导致写入失败。
- 重启 WorkBuddy，重新设置工作目录。
Linux 环境则先检查目录权限，ls -la看一下，再用chmod -R u+w 目录授权，基本能解决。
5.2 API 接入与模型选择问题
配置 DeepSeek API 时，常见问题是连接失败或者授权失败。第一步确认 API Key 有没有复制完整；第二步确认模型名称是否和官方文档一致；第三步确认网络环境能不能正常访问 API 服务；第四步看是否超出请求频率限制。
我自己跑50份简历时，默认模型处理到第20份左右偶发超时，切换成 DeepSeek 的 API 后稳定了很多。同类模型相比之下，DeepSeek 在中文长文本抽取上准确率不低，而且积分的消耗速度明显慢不少。WorkBuddy 界面上能看到每次任务的积分消耗明细，方便控制成本。
5.3 内容输出慢的优化手段
热词里有人问“workbuddy内容输出慢”，这个我遇到过。同一个任务，有时候出结果很快，有时候等了半天没动静。排查下来有三类原因：
第一，单次输入的文本量太大。把50份简历塞进同一个任务，每份简历平均 2000 字，总量 10 万字，模型处理起来自然慢。解决办法是分批处理，比如每次处理 10 份，分5批执行。
第二，模型上下文长度不够导致频繁截断重试。这种时候要换一个上下文窗口更大的模型，或者在规则里强制要求“不要阅读与筛选无关的内容”，减少上下文占用。
第三，Skill 里的步骤太多，每步都在等待模型响应。我做过对比测试，把所有处理逻辑合并成“分三步完成”比“分十步完成”要快得多。能让 AI 一次性做的事，不要拆成多轮对话。
我最终的方案是：10 份一批，每批一个指令，批次之间间隔 1 分钟。事实证明这样跑完50份比一次性全量跑反而更快，最终稳定在 25 分钟左右。
5.4 输出质量不稳定的避坑经验
第一次跑批时输出格式混乱的问题，我也摸索出了一套避坑方法。关键是在 Skill 里明确输出模板，而不是简单说“输出一份报告”。让 AI 按模板填充信息，基本上每次格式都一致。
具体做法是：把输出模板直接写进 Skill 的规则里，连 Markdown 语法都给它。我还在规则里强调“不要修改模板结构，只填充对应字段”，这样即使处理的是完全不同的简历，报告结构也完全一致。如果你需要批量数据做二次分析，还可以要求同时输出一份 CSV 或 JSON 格式的数据文件。我自己就导出了一份全量 JSON，然后写了一段小脚本生成 Excel 版本，非常方便。
另外一个细节：如果发现某份简历的某个字段始终抽不出来，不要反复重试，直接在报告里标记“待补充”，然后继续。因为有些简历就是没写毕业院校或没写工作时间线，AI 怎么猜都没用。
6. 这套流程还能延伸到哪里
简历筛选只是 WorkBuddy 的一个场景。我在实际使用中发现，凡是“阅读大量文件 + 按固定规则提取 + 结构化解出结果”的任务，它都能处理得很好。分享一下我已经跑过的几个延伸场景，给你一些参考。
一是标书初筛。朋友在建筑行业，每次投标收到一堆标书，厚厚一本几百页，人力从头看太费时间。我帮他设定了一个 Skill，规则是提取营业执照有效期、资质证书编号、项目业绩数量、废标风险点，半小时能过完几本标准文件，把明显不合适的标书提前拦下来。
二是合同关键条款提取。把合同丢进去，自动提取付款条款、违约金比例、知识产权归属、保密协议期限等关键信息。以前法务要逐字审一遍才能回复，现在先让 WorkBuddy 抽一遍，法务直接看抽查结果，效率高不少。
三是客户信息清洗。销售团队从各个渠道收集的客户名片和联系人信息，格式五花八门，WorkBuddy 可以自动统一为固定结构，剔除重复项，再按区域或行业分组。这个也是直接用现成的能力就能跑。
所以我现在的习惯是：遇到重复性强的工作，第一反应不再是“忍一忍就干完了”，而是问自己一句“这个任务能不能封装成 Skill”。能的话，就花一点时间配置，后面就能持续复用。
最后分享一个小技巧。WorkBuddy 的自定义指令里，有一个很管用的设置：让它在生成结果时把每一步的处理依据写出来。比如筛选简历时，要求它不仅输出“推荐面试”这个结论，还要输出“为什么推荐”的理由。这样后面即使候选人有争议，你也可以倒回去看它的判断逻辑，进行调整和复盘。这套流程用了两三个月，我最大的感受是：AI 筛选简历的价值不是代替人做判断，而是让人把有限的注意力放在更值得投入的地方。
