用WorkBuddy搭建简历筛选工作流：50份简历30分钟输出评估报告

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_张三_简历.pdf02_李四_简历.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, encodingutf-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(综合得分, ascendingFalse) df.to_excel(简历筛选评估报告.xlsx, indexFalse)这段脚本不复杂但它能做三件人工做起来很烦的事把 50 份结果合并、按综合得分排序、统一输出格式。最终生成的 Excel 里每一行是一个候选人列从候选人 ID 到推荐理由按分数从高到低排好。HR 拿到这个表筛 A 类候选人就是 Excel 里点一下筛选按钮的事情。5.2 报告的分层设计A/B/C/D 四档的意义做完表格之后我没有直接把它发给 HR因为 50 行数据对决策者来说还是太多了。我把表格按推荐等级分成了四个 SheetSheet1 是 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 这类工具最值得投资的地方。