企业官网建设流程全解析

1. 为什么我会用 WorkBuddy 来筛简历

先交代一下背景。团队扩编，HR 一次性甩给我 50 份简历，要求当天给出评估意见。传统做法是一份份打开 PDF、扫一眼工作经历、看看项目描述、搜一下学历背景，再凭印象打个分——熟练的话，一份简历看三到五分钟，50 份就得三四个小时。而且说实话，看到第 30 份的时候，前面那份到底什么水平，记忆已经模糊了，评分标准基本靠感觉。

我平时已经在用 WorkBuddy 处理一些重复性的文本任务，比如自动汇总日报、整理周报素材、批量提取合同关键字段。它本质上是一个可以自定义工作流的 AI 工作台，你可以给 AI 设定角色、规则、输出格式，然后把任务批量丢给它，它会按你的要求逐条处理并汇总结果。既然它能处理合同和日报，那简历筛选逻辑上也没有问题——简历无非是结构化的文本信息，加上一些需要主观判断的匹配度评估。

这次实战的核心目标是：把 50 份简历丢给 WorkBuddy，让它 30 分钟内完成三件事。第一，逐份提取候选人的关键信息，包括教育背景、工作年限、技能栈、项目经历、离职状态等；第二，根据我预先设定的岗位要求，对每份简历做匹配度评分和优缺点分析；第三，自动生成一份总体的评估报告，按推荐优先级排序，方便我和 HR 快速决策。

实际跑下来，50 份简历从投喂到拿到完整报告，大约用了 28 分钟。这中间还包括我调整指令、试错、优化输出格式的时间。如果只算纯执行时间，可能不到 20 分钟。更重要的是，评估标准是统一的，不会出现"前面严格后面宽松"这种人为漂移。

需要说明的是，WorkBuddy 本身不是专门的 HR 工具，它能做这件事，靠的是自定义指令和批量处理能力。换句话说，这是一套可复用的工作流设计思路，你把它换成合同审核、论文摘要、竞品信息收集，逻辑完全一样。下面我把这次实战的完整过程拆开讲，包括指令怎么写、为什么这么写、跑的时候踩了哪些坑、报告长什么样，以及如何把准确率提到能用的水平。

这篇内容适合三类人：正在批量看简历的招聘负责人和用人经理；想用 WorkBuddy 但不知道从哪下手的新手；以及遇到"AI 输出太泛、格式不稳定、结果不敢信"这类问题的人。我会尽量把原理和步骤都讲透，看完你直接抄作业就行。

2. 简历筛选工作流的核心设计：先把"人怎么筛"翻译成"机器怎么筛"

很多人用 AI 工具做简历筛选，效果不好，原因不在工具，而在指令。人看简历的时候，"这个候选人不错"是一种综合感觉，里面包含岗位匹配度、经验深度、项目含金量、稳定性、薪资预期等等因素。但 AI 不理解"不错"是什么意思，你必须把这些模糊的判断拆成明确的、可量化的规则，它才能稳定输出。

2.1 把岗位要求拆成可量化的评估维度

我这次招聘的岗位是"高级 Python 后端工程师"，所以我先列了一份筛选标准，分为硬性门槛和加分项。

硬性门槛是：统招本科及以上学历，计算机相关专业；3 年以上 Python 后端开发经验；至少有一个完整的、上线运行的项目经历；熟悉 Web 框架（Django 或 FastAPI）；对数据库和缓存机制有基本认知。加分项是：有高并发系统的处理经验；用过消息队列；熟悉 Docker/K8s；有团队管理或带人经验；有大厂背景；有开源项目贡献。

这些条件本身不复杂，但要让 WorkBuddy 准确判断，还要解决两个问题：一个是简历里写的经验年限和技能栈是分散的，需要 AI 自己提取和归纳，它得知道"Django"属于"Web 框架"、"Redis"属于"缓存"；另一个是有些简历会夸大或含糊其辞，比如写了"熟悉多种语言"但没列出具体项目，AI 需要根据整体内容判断可信度。

所以在设计指令时，我把每个评分维度都明确列出，并给每个维度定义了得分标准。注意，不要让 AI 直接打分，先让它提取事实，再基于事实做判断。这是这次工作流里最关键的一个设计决策，后面我会专门解释为什么。

2.2 两步走：先让 AI 做信息提取，再做匹配评分

我最初的想法是让 WorkBuddy 一步到位，读简历后直接给出综合评分和推荐意见。试跑了几份之后发现不行，问题在于：AI 在信息不足时会自己脑补。比如一份简历没写教育经历，它可能会默认是本科；项目描述模糊的时候，它倾向于给出偏高的评价。这对招聘决策是致命的。

所以我把工作流拆成了两个阶段。

第一阶段名叫"简历结构化提取"。指令要求 AI 从简历中提取以下字段：姓名、年龄、工作年限、教育背景（学校、学历、专业、毕业时间）、技能栈（列出所有提到的技术名词）、项目经历（每个项目的名称、时间、角色、用到的技术、项目成果）、当前状态（在职/离职/观望）、期望薪资（如果写了）。输出格式要求是纯 JSON，不允许出现任何额外文字。

第二阶段才是"匹配度评估"。这个阶段不再读取原始简历，而是读取上一阶段生成的 JSON 数据。指令里写明岗位要求、每个评分项的权重、打分规则（1 到 5 分），以及推荐等级的判定标准（比如综合得分 4.5 以上为 A 类推荐，3.5 到 4.4 为 B 类备选，3.5 以下为 C 类暂不考虑）。

为什么要拆成两步？因为提取阶段的任务是"忠实还原"，评估阶段的任务才是"主观判断"。两个任务混在一起，AI 很容易为了得到好的评估结果而篡改提取的事实。分开之后，第一阶段的结果是客观的，第二阶段基于客观数据做推理，这样即使评分有偏差，你也可以通过检查 JSON 数据反过来定位是哪条信息导致的误判。

2.3 自定义指令的写法：角色、规则、输出格式一个都不能少

WorkBuddy 的自定义指令本质上是一段系统提示词，但它和普通对话式提示词有一个重要区别：它是长期挂载在工作流上的，每次执行都会生效，所以必须写得严谨。

我用的指令模板大致是：

你是一名资深技术招聘顾问，拥有 10 年以上的后端工程师招聘经验。 你的任务是对候选人简历进行结构化信息提取和岗位匹配度评估。 【提取规则】 1. 从简历中提取所有关键事实信息，不得推测、不得补充简历中不存在的信息。 2. 如果某个字段在简历中未提及，输出 null，不得猜测默认值。 3. 技能栈字段需要提取简历中出现的所有技术名词，包括编程语言、框架、数据库、中间件、云服务等。 4. 项目经历必须逐个列出，每个项目包含：项目名称、起止时间、担任角色、技术栈、项目描述、量化成果（如有）。 【评估规则】 1. 根据岗位要求逐项打分，每项 1-5 分，并给出打分理由。 2. 综合得分 = 硬性条件得分 * 0.6 + 加分项得分 * 0.4。 3. 硬性条件包括：学历（本科及以上为 5 分，专科为 3 分，以下为 1 分）、Python 经验年限（3 年以上为 5 分，1-3 年为 3 分，1 年以下为 1 分）、项目完整度（有完整上线项目为 5 分，仅有练习项目为 2 分）、技术栈匹配度（按匹配技能数量占比折算）。 4. 加分项每命中一项增加 0.2 分，上限 1 分。 5. 推荐等级：综合得分 >= 4.5 为 A（强烈推荐），3.5-4.4 为 B（可进入面试），2.5-3.4 为 C（暂不推荐），< 2.5 为 D（明显不匹配）。 【输出格式】 严格按照以下 JSON 格式输出，不得添加任何额外文字或 Markdown 标记。 { "candidate_id": "文件名", "basic_info": {...}, "skills": [...], "projects": [...], "evaluation": {...}, "recommendation_level": "A/B/C/D", "recommendation_reason": "一句话总结" }

这里有几个细节值得注意。

第一，角色设定不能太泛。只说"你是 HR 专家"不够，要让 AI 知道它面对的是"后端工程师"这个具体岗位，这样它提取技能栈的时候才会对 Django、FastAPI、Celery、Redis 这类词敏感。

第二，输出格式的描述必须精确到不能再精确。"严格按照 JSON 格式输出，不得添加任何额外文字"这句话很重要，否则它会给你来一段"好的，以下是我的分析结果"之类的废话，批量处理 50 份简历时，每份多一句话，后面的解析和汇总就全乱了。

第三，评分规则要写成可执行的算式，而不是模糊的方向。综合得分怎么算、每项怎么打分、等级怎么划分，都要明确写出来。AI 不是按公式计算，它是模拟按公式计算的过程，但你写得越具体，它的输出就越稳定。

2.4 为什么输出格式用 JSON 而不是自然语言

这个问题我专门说一下，因为它是决定整个工作流能不能自动化的关键。

如果你让 AI 用自然语言输出评估结果，比如"张三的简历整体不错，Python 经验丰富，项目很完整，推荐进入面试"，你确实能看懂，但后续没法处理。50 份简历就是 50 段风格各异的文字，你想汇总、排序、批量筛选 A 类候选人，还得肉眼去看每段文字，那就失去了自动化的意义。

用 JSON 格式输出，等于给 AI 的回复套了一层锚点。每个候选人的评估结果都变成结构化数据：candidate_id 是文件名，evaluation 里有各项得分，recommendation_level 是等级。这样我可以把 50 份结果拼接成一个 JSON 数组，直接写脚本排序、筛选、统计。甚至可以做成 Excel 表格，每行一个候选人，列是各项指标，HR 拿到手直接就能按分数排序。

这次实战到最后，我生成的总报告就是一个表格，按推荐等级和综合得分排序，候选人姓名、工作年限、匹配技能、推荐等级、推荐理由一目了然。这套东西之所以能跑通，根子就在于提取和评估阶段都用了 JSON 输出，机器可读性决定了后续的汇总和处理效率。

3. 50 份简历 30 分钟跑通的完整实操过程

理论讲完了，说说实际操作。我不建议你直接照着某个现成教程一键安装就立刻跑大批量任务，因为 WorkBuddy 的配置、Skill 安装、指令调试都有一些隐性步骤。下面是我这次完整的操作链路，按顺序来能帮你少踩一半坑。

3.1 环境准备：文件格式处理与批量导入

先说一个很多人会忽略的问题：简历的文件格式五花八门，有 PDF、Word、图片扫描件。WorkBuddy 本身可以读取这些文件，但对图片扫描件的解析准确率会明显下降。我拿到的 50 份简历里，有 6 份是图片格式，实测下来这 6 份的文本提取准确率大约只有八成，里面有两份甚至出现了乱码。所以我的建议是，在批量处理之前，先把非文本类简历做一次预处理，用 OCR 工具转成文本或 Markdown。这一步虽然多花十分钟，但能避免后面评估阶段因为乱码产生完全错误的判断。

文件整理方面，我建了一个专门的文件夹，把所有简历统一命名为"01_张三_简历.pdf""02_李四_简历.pdf"这种格式。为什么这么做？因为后面生成报告时，每个候选人的 candidate_id 会直接取文件名，统一的命名格式可以让最终的汇总表格更整齐。另外，当你需要回溯"这个 A 类候选人是哪份简历"的时候，按编号找文件比按"简历_final_最终版_v3.pdf"这种文件名去找省力得多。

3.2 Skill 安装与自定义指令调试：先用 3 份简历试跑

WorkBuddy 的 Skill 机制相当于给它加载"专业能力包"，比如安装一个"文档解析"Skill 能提升 PDF 提取效果，安装"数据分析"Skill 可能对后续汇总有用。但我不建议一上来就装一堆 Skill，因为 Skill 越多，输出格式被干扰的可能性越大。我这次只保留了文件解析相关的 Skill，其他的先禁用。

安装好 Skill 之后，把自定义指令写进去，先别急着跑全部 50 份。我的习惯是：先随机挑 3 份简历试跑——一份优秀的、一份中等的、一份明显不匹配的。为什么要挑三个极端？因为这样能最快检验指令的区分度。优秀的能不能打出高分，不匹配的能不能准确识别出来，中等的是不是模棱两可，这三种情况都能通过，指令才算基本合格。

我第一轮试跑时就发现问题了。指令里写的是"如果某个字段在简历中未提及，输出 null，不得猜测默认值"，但 AI 仍然对一份没写教育经历的简历输出了"本科"。原因在于它可能在某个技能描述或项目经历里推断出了学历信息，或者干脆就是按行业默认值脑补了。我改正的办法是在指令里加了一句强约束："‘教育经历未提及’是常见情况，请接受这是事实，不要推测候选人学历。"加了这句话之后，同样一份简历，教育背景字段就老实输出 null 了。

试跑调试的整个过程大概花了 20 分钟。三份简历，跑完看结果，不对就改指令，再跑，再改。20 分钟后指令稳定了，才开始处理全部 50 份。这一步的回报率极高，因为如果从头到尾直接跑 50 份，出了问题你要排查的就是 50 份的结果，而不是 3 份的。

3.3 批量执行与中途异常处理

指令稳定后，我把全部 50 份简历加入任务队列，点批量执行。WorkBuddy 会逐份读取文件、按指令提取信息、生成 JSON 结果。执行过程中需要留意一个常见问题：Token 限制。如果一份简历特别长，或者你挂载的指令和 Skill 过多，单次输出可能被截断，导致 JSON 不完整。我这次就遇到了一份写了 8 页的简历，JSON 输出到一半被截断，结果是无效的。

解决办法有两个。一是把大任务拆分，让 WorkBuddy 一份份处理而不是一次性塞 50 份，这样单次任务的 Token 压力小；二是修改指令，让提取阶段只输出 basic_info 和 skills，项目经历单独作为第二次任务处理。实际跑的时候我选择了一，因为拆得太细会增加管理和拼接成本。

批量执行过程中，我还发现一个问题：任务队列里的顺序会影响中间计时。WorkBuddy 是按队列顺序逐条处理的，如果你把某些特殊格式的大文件排在最前面，整体耗时会被拖长。比较好的做法是先处理普通 PDF，把扫描件和超长简历放在后面单独处理，这样即使某个文件解析失败，也不影响整体进度。

3.4 30 分钟的时间花在哪了

跑完全程后我统计了一下时间分布。指令调试和试跑大约 20 分钟，这部分是一次性成本，以后跑下一批简历直接复用就行。批量执行 50 份大概花了 18 分钟，这是 WorkBuddy 的纯处理时间，平均每份简历约 20 秒出头。失败重跑 3 份，花了约 2 分钟。生成汇总报告和初步复核，约 5 分钟。合计下来，从拿到 50 份简历到产出可用的评估报告，45 分钟左右。

如果我只算"投喂文件到拿到报告"的纯执行时间，确实在 30 分钟以内。但作为一个老实的实践者，我更愿意把调试时间也算进去，因为第一次跑一个流程，调试是绕不开的。好消息是，我已经把调试好的指令保存为自定义 Skill 了，下一次再筛简历，我可以直接复用，预热成本几乎为零。

4. 影响筛选质量的三个关键环节：解析、评分一致性与格式稳定

30 分钟跑完 50 份简历，听起来很快，但如果不是亲眼见过 AI 把一份优质简历评成 C 级，我也不会知道这 30 分钟里藏着多少坑。下面这几个环节是决定结果能不能直接用的关键，每一个我都踩过。

4.1 文件解析的准确率直接决定后续所有判断

WorkBuddy 处理文本类 PDF 和 Word 的准确率相当不错，但遇到格式复杂的简历——多栏排版、表格、图片混排——提取效果会打折。多栏简历尤其严重，AI 有可能把左边一栏的"工作经历"和右边一栏的"自我评价"混在一起，导致项目经历提取出来完全对不上。

我测试下来，普通单栏简历的解析准确率在 95% 以上，多栏和表格混排的简历准确率会掉到 80% 左右。这个差距在单份简历上不太明显，但批量处理 50 份时，只要有 10 份是多栏排版，里面就会有 2 份左右的信息是错的，而 AI 自己很难发现错了。

应对办法是在 Skill 里加上一行规则："如果简历是分栏或复杂表格排版，按从左到右、从上到下的阅读顺序重新组织内容，确保项目经历和时间线的对应关系正确。"这句话能让误读率降低不少，但依然不能完全避免。所以我在最终报告复核时，只重点看了评为 A 类和 D 类的极端结果——这两类对信息准确性最敏感，如果它们没错，中间档次的偏差对决策影响就不大。

4.2 评分一致性：同样的资历，前面和后面不能两种标准

人工筛选简历最常见的毛病是标准漂移：第一份简历看得很认真，觉得很不错；看到第三十份时，要求不知不觉提高了，同样水平的人可能只给 B。AI 没有这个问题，但它有另一个毛病——指令里的规则理解偏差。

比如我规定"Python 经验年限 1-3 年为 3 分，3 年以上为 5 分"。理论上很清晰，但 AI 在判断"3 年以上"时，可能会把"精通 Python，使用 2 年，外加 1 年 Django 开发经验"算成 3 年，也可能会把"熟悉 Python 和多种语言"模糊处理为 2 年。这种偏差不是每次都发生，但一旦发生，不同简历之间的评分就缺乏可比性。

我的解决办法是两层：第一层，在指令里明确要求，"经验年限判断依据：如果简历明确写了起始时间和岗位年限，以明确信息为准；如果写的是‘精通’‘熟练’这类程度词但没有具体年限，按 1-2 年保守估计；严禁自行从项目描述中推算年限。"第二层，在最终复核时，把所有被评为 A 级和 D 级的简历人工扫一遍，重点看年限判断有没有明显错误。这两层叠加，基本能保证评分的一致性在一个可接受的范围。

4.3 输出格式不稳定：JSON 截断、字段缺失、多余文字

用 WorkBuddy 做批量任务，最大的敌人是输出格式不稳定。指令里写了"严格输出 JSON，不得输出多余文字"，但它偶尔还是会给你来一句"这是结果："，或者在 JSON 末尾加一句"希望这个分析对你有帮助"。这句话单独看没问题，但它会破坏你后续用脚本解析的效果。

更常见的问题是 JSON 截断。当简历内容较长或 Token 接近上限时，输出的 JSON 可能只写了一部分就停了，没有结束花括号，导致整段 JSON 无法解析。我这次 50 份里大概有 3 份出现了这种情况。

应对办法有三个。第一，在指令末尾加"只输出 JSON，不要解释、不要寒暄、不要 Markdown 代码块标记"，能减少非结构化输出；第二，把任务按份拆分，降低单次输出长度，能减少截断概率；第三，也是最重要的，不要试图让脚本自动处理所有失败情况，预留一个人工复核通道。我这次的做法是把失败项单独标记出来，脚本自动重试一次，重试仍失败的就手动看是哪份简历出了问题，再针对性处理。

5. 自动评估报告长什么样：从 JSON 到可直接决策的表格

评估报告是这次实战的最终产物，也是整个流程价值的体现。WorkBuddy 本身不会自动把 50 份 JSON 变成一个漂亮的 Excel，你需要自己做一个轻量级的汇总和可视化。这一步不算复杂，但做得好不好，直接决定你拿出来的东西是"AI 输出的一堆代码片段"还是"HR 能直接用的决策文档"。

5.1 汇总脚本：把 50 份 JSON 合并成一张表

我的做法是写了一个简短的 Python 脚本，遍历 WorkBuddy 输出的结果目录，读取每份 JSON，提取 candidate_id、basic_info、skills、evaluation、recommendation_level、recommendation_reason 这些关键字段，按照预设的列顺序写入一个 pandas DataFrame，最后导出为 Excel。

脚本核心逻辑大概是这样：

import json import glob import pandas as pd rows = [] for path in glob.glob("./workbuddy_results/*.json"): with open(path, "r", encoding="utf-8") as f: data = json.load(f) info = data.get("basic_info", {}) eval_data = data.get("evaluation", {}) rows.append({ "候选人ID": data.get("candidate_id", ""), "姓名": info.get("name", ""), "学历": info.get("education", ""), "工作年限": info.get("work_years", ""), "匹配技能": ", ".join(data.get("skills", [])[:8]), "综合得分": eval_data.get("total_score", ""), "推荐等级": data.get("recommendation_level", ""), "推荐理由": data.get("recommendation_reason", ""), }) df = pd.DataFrame(rows) df = df.sort_values("综合得分", ascending=False) df.to_excel("简历筛选评估报告.xlsx", index=False)

这段脚本不复杂，但它能做三件人工做起来很烦的事：把 50 份结果合并、按综合得分排序、统一输出格式。最终生成的 Excel 里，每一行是一个候选人，列从候选人 ID 到推荐理由，按分数从高到低排好。HR 拿到这个表，筛 A 类候选人就是 Excel 里点一下筛选按钮的事情。

5.2 报告的分层设计：A/B/C/D 四档的意义

做完表格之后，我没有直接把它发给 HR，因为 50 行数据对决策者来说还是太多了。我把表格按推荐等级分成了四个 Sheet：Sheet1 是 A 类候选人，Sheet2 是 B 类，Sheet3 是 C 类，Sheet4 是 D 类以及原因说明。

A 类和 B 类是真正需要进入面试流程的，C 类和 D 类是暂时不推荐的。这个分层最大的价值是让决策者可以把注意力放在少数人身上。比如这次 50 份简历里，A 类只有 3 人，B 类 12 人，C 类 25 人，D 类 10 人。HR 只需要先看 A 类的 3 份原简历，再结合 B 类的 12 份做筛选，工作量大减。

我也在报告里加了一个"推荐理由"列，里面是 AI 用一句话概括的推荐意见。这个设计一开始只是顺手加上去的，后来发现它意外地有用：HR 在决定给谁发面试邀请时，往往需要快速知道"为什么推荐这个人"，一句话理由比看完整份简历高效得多。对于 A 类候选人，这句话也能帮你快速回忆这个人到底强在哪。

5.3 复核：AI 筛完不等于可以直接用

看到 AI 生成的报告，第一反应是"好用"，但第二反应必须是"核对"。我的复核策略是抽样，重点看两头：A 类和 D 类。A 类是准备发面试邀请的，必须确认没有因为解析错误导致误判；D 类是准备直接淘汰的，也要确认没有因为 JSON 截断导致信息遗漏而误杀。

实际操作中，我挑出了评分最高和最低各 5 份，人工打开原始简历对照。结果发现 A 类里有一份其实是 D 类水平——原因是那份简历的"项目经历"部分用了大量图片截图，解析阶段只提取到了文字部分，项目描述的关键信息丢了，AI 只能根据有限的信息打了高分。我把这份从 A 类移到了 C 类。这个例子也印证了前面说的：解析质量决定一切，复核 AI 的极端判断是必须的步骤。

6. 实测踩坑与调整记录：这些坑你可能也会遇到

下面这部分是我觉得对读者最有价值的——不是成功的部分，而是失败的部分。我按时间顺序记录了这次实战里遇到的几个问题，以及我是怎么定位和解决的。

6.1 同一个候选人出现两次：文件名和内容不匹配

第一批跑完 50 份后，汇总表里出现了 49 行数据。排查后发现，两份内容一模一样的简历被记录成了两个文件，原因是 HR 给同一份简历存了两个不同的文件名。这两个文件的 JSON 里 candidate_id 不同，但 basic_info 和 skills 完全一样，导致汇总表里出现了一个"重复候选人"。

这个问题说大不大，但如果不处理，HR 可能会给同一个人发两次面试邀请，或者在做统计时把人数算错。我的解决方法是加了一个简易查重逻辑：在汇总脚本里按"姓名 + 手机号（如果有）"做去重。更稳妥的办法是在导入前就做文件查重，比如按文件内容哈希判断，但由于我这边简历是别人打包发的，预处理阶段没有做这一步，只能在结果里去重。

6.2 期望薪资字段：写了和不写，处理逻辑完全不同

50 份简历里，只有 12 份明确写了期望薪资，其余都没写。AI 在提取薪资字段时，对没写的简历会输出 null，这符合我的指令要求。但问题出在评分阶段：我最初设置的综合评分公式里，薪资匹配度占了一些权重，没写薪资的候选人这项一律为 0，导致评分偏低。

这里就出现了逻辑冲突：候选人没写薪资，不等于他不符合薪资预期，只是信息缺失而已。我的调整方案是在指令里增加了一条规则："如果简历中未提及期望薪资，该项按中性处理，不进入综合得分计算，但在报告备注中标注‘薪资未知，需面试确认’。"这样不会因为信息缺失而误杀候选人，同时也能提醒 HR 在面试环节补充这个信息。

6.3 大厂背景的误识别：项目经历中的公司名被当成技能

有个候选人简历里写了"曾就职于某大型电商平台"，AI 在提取技能栈时把这家公司的名字也当成了一项"技能"加进去了。这个问题技术栈提取时很容易遇到，因为简历里的专业名词和公司名词有时候很难区分。

我的应对办法是在指令里增加了一条黑白名单规则："技能栈提取仅限技术名词，包括编程语言、框架、数据库、中间件、云服务、开发工具等；公司名称、团队名称、项目名称不算技能，除非该名称本身是开源项目或技术术语。"这条规则加进去后，重新跑了一遍，技能提取就干净了很多。

踩过这些坑之后，我的整体感受是：AI 批量处理任务，真正难的不是让它"跑起来"，而是让它"稳定地跑对"。每一次需要人工修正的输出，要么是因为输入格式太复杂，要么是因为指令里的规则不够明确，要么是因为边界情况没有预先想到。这些都是可以通过迭代指令和预处理手段来改善的，但前提是你愿意在调试阶段多花一点时间。

7. 从简历筛选到更多批量任务：这套工作流的可复制性

简历筛选这个场景跑通之后，我很快发现 WorkBuddy 这套方法论——拆解任务、设计指令、结构化输出、批处理、结果复核——完全可以复用到其他批量处理场景。事实上，我已经用它处理过另外几类任务，效果都不错，这里列一下思路。

7.1 批量文档整理：把散落的信息变成表格

比如团队里的项目周报，每人提交的格式千差万别，有的是 PDF，有的是群聊里的文字粘贴，有的直接发的图片。以前整理周报要人肉把每份内容重新排版，现在我把所有周报丢给 WorkBuddy，指令里规定提取每个成员的"本周完成事项""下周计划""遇到的问题"三个字段，输出成 JSON，再写脚本合并成一张统一格式的周报汇总表。

和简历筛选不同的是，周报整理的输出结果不涉及主观评分，所以准确率要求可以稍微放宽。但它的频率比招聘高得多，每星期都要跑一次，所以指令的稳定性要求更高。我现在的做法是把这套指令做成了一个专用 Skill，每次新一周的任务直接复用，跑完只需要瞄一眼格式有没有异常。

7.2 竞品信息收集：多平台内容提取与结构化

另一个我用得比较多的场景是竞品信息收集。把几十篇竞品介绍、产品更新日志、用户评价丢给 WorkBuddy，指令让 AI 提取"产品名称""发布时间""核心功能变化""用户情绪倾向"这几个维度，最后生成一个竞品动态表。这个任务的难点在于信息来源复杂，可能是公众号文章、论坛帖、产品文档，格式和表达方式的差异比简历还大。

不过方法还是一样：先提取事实，再判断倾向。技术上就是让 AI 先输出产品的功能点、时间线等结构化字段，再单独作为一个评估步骤去判断用户情绪。和简历筛选的区别在于，竞品信息收集不完全依赖单一文件，同一份资料可能出现在不同地方，需要做一个全局去重。

7.3 把调试好的指令沉淀成自己的 Skill 库

每一次跑通一个场景，我都会把调试好的指令保存为一个独立的 Skill。这不是简单的复制粘贴，而是把这次踩坑的经验一并写进去。比如简历筛选的 Skill 里包含：识别多栏排版的规则、不猜测缺失字段的规则、区分技能和公司名的黑白名单、薪资未知的中性处理逻辑。这些规则单独拎出来看都很小，但组合在一起，就是一个稳定可复用的"简历筛选工作流"。

现在我的 WorkBuddy 里已经存了五六个属于自己的 Skill：简历筛选、周报汇总、竞品收集、会议纪要整理、合同关键字段提取。每新增一个 Skill，都是对之前经验的复用和沉淀。对一个重度使用者来说，WorkBuddy 的真正价值不在于它能跑多快的批量任务，而在于你能把自己的工作方法固化在工具里，下次遇到同样的任务，直接一键执行。

最后分享一个我自己形成的习惯：每次跑完一个场景，我会花几分钟把这次遇到的新问题和解决办法追加到对应 Skill 的指令里。WorkBuddy 的指令不是在第一次调试时就完美的，它是在一次次的真实任务中被打磨出来的。这个过程有点像给一个实习生写操作手册，第一版可能只有十条规则，但半年之后，这本手册会厚到任何一个新人都能按它做出和资深员工一样的判断。这大概也是 WorkBuddy 这类工具最值得投资的地方。