企业官网建设流程全解析

我在招聘季的真实状态大概是这样的：岗位放出去，两三天邮箱就被简历塞满，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 不会像人一样看一眼就凭直觉判断，它需要明确的评估维度、权重和判断依据。

我按技术岗位的常规要求，把评估维度拆成四块：

这里要特别注意，评估维度里不设置年龄、性别、婚育等任何与岗位胜任力无关的字段。筛选的目标是“人和岗位匹配度”，不是给人贴标签。规则写得越干净，结果越经得起推敲。

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 分钟把所有简历统一命名，命名规则是“日期_姓名_应聘岗位_工作年限.后缀”。

再建一个工作目录，把岗位 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 拿到任务之后，大致会按这个流程工作：

1. 读取简历目录，罗列全部文件。
2. 逐份解析文件内容，PDF 转文本、DOCX 抽文字。
3. 结合岗位 JD，按自定义指令中的维度逐项打分。
4. 输出 JSON 格式评估结果，并汇总到总报告中。
5. 根据总分和 verdict 状态生成排名。

全程不需要我盯着，它会一边处理一边把中间结果写到 reports 目录。这也是我敢把 50 份直接交给它的原因。

3.4 自动评估报告的内容结构

跑完之后，WorkBuddy 生成的评估报告包含这些内容：

• 总览统计：简历总数、recommend 数量、pending 数量、reject 数量。
• 排名列表：按总分从高到低排列，包含姓名（文件名）、总分、核心亮点。
• 留存明细：每份简历的 score_detail 和 assessment。
• 风险提示：每份简历的 risk 字段，集中列出需要面试官重点确认的疑点。

我摘几条脱敏后的示例记录，大概长这样：

这个报告直接就可以放进招聘周报，不用我再额外整理。

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。

排查链路也很简单：

1. 先看报错日志，确认是在哪一步写入失败。
2. 用ls -ld检查目标目录的属主和权限。
3. 发现是权限问题后，要么chown改属主，要么直接把任务目录移到当前用户的家目录下。
4. 重新运行任务，确认写入正常。

最省心的做法就是我前面提到的：从一开始就在~/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” 被解析成了完全不可读的乱码，别说评估，连模板都给乱了。

这个问题不像权限问题那样有标准答案，更多是“熟练工经验”。我的处理顺序是：

1. 先判断简历是文本型 PDF 还是扫描件。
2. 文本型 PDF 用解析工具直接抽取文本，如果乱码就换一种抽取方式。
3. 扫描件直接走 OCR，把图片里的文字识别出来再交给 WorkBuddy。
4. 如果某份简历实在无法解析，就在指令里明确要求输出unreadable，不要强行打分。

这里有一个很容易被忽略的点：很多人在简历解析失败后，会让 AI “根据经验猜一下”。这绝对是大忌。评估报告一旦混入脑补内容，整个筛选结果的可信度都会被打折扣。宁可标记为 unreadable，也不要让模型凭空推理。

5. 筛选工作流沉淀成Skill，以后每次只用一条命令

5.1 把流程封装成Skill的步骤

跑通一遍之后，我想的很清楚的一件事是：这次流程如果只服务“这一批简历”，那价值有限。把它沉淀成 Skill，下次不管是谁来操作，直接一条命令调用，才是真正省时间的开始。

WorkBuddy 的 Skill 机制，本质上就是把前面写的自定义指令、流程步骤和参数定义打包成一个可复用单元。我在本地维护的 Skill 目录结构大致是这样的：

skills/ resume-screening/ SKILL.md params.json samples/ 优秀简历示例.pdf 淘汰简历示例.pdf

• SKILL.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_PROVIDER=deepseek export WB_MODEL_API_KEY=sk-xxxxxxxx export WB_MODEL_NAME=deepseek-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 筛完只是帮你把范围缩小，最后拍板这种事，还是得留在自己手里。