我用 WorkBuddy 批量完成知识库文章自动打标签：业务工作者也能复制的 AI 提效实践

引言

最近我用 WorkBuddy 做了一个很典型的业务自动化实践：给第三方知识库里的法规文件批量打标签。

这件事听起来不复杂。我们已经有一份整理好的 Excel 文件，里面包含每篇法规文件对应的标签信息；知识库后台也已经上传好了相关文件。我要做的事情，就是把 Excel 中的标签逐条同步到知识库后台，让这些文件后续能够更好地参与分类、检索和智能问答。

如果只有十几条文件，手工处理当然没问题。但这次一共有近千条记录需要页面打标，还不能进入都后台程序批量处理，每条文件还涉及多个标签维度。整个过程需要不断查 Excel、找文件、点标签、输入内容、保存、翻页。它不是技术上有多难，而是非常典型的“重复、耗时、容易出错”的业务操作。

所以这次我没有选择手工硬做，而是尝试把它交给 WorkBuddy：让它读取 Excel，理解标签规则，连接浏览器页面，自动匹配文件，并完成批量打标。

这篇文章就来复盘这个过程。我不会把重点放在“写了多少代码”上，而是更关注一个业务工作者如何把自己的规则、流程和验收标准描述清楚，再借助 WorkBuddy 把它变成一条可执行、可调试、可复制的 AI 工作流。

第一章：构建企业知识库标签体系，为什么值得重做一遍？

在很多业务系统里，打标签看起来都是一件小事。

尤其是在知识库场景中，标签往往只是页面上的几个字段。它不像模型训练、系统开发、接口联调那样听起来复杂，也不像报表分析那样能立刻看到结果。很多时候，大家会把它当成一种后台维护动作：有空就补一补，缺了就手动加一下。

但真正做过知识库建设的人应该都知道，标签这件事并不只是“给文件贴几个名字”。

它本质上是在给知识内容建立一套更稳定的组织方式。

1.1标签不是装饰，而是知识库的索引

对于法规知识库来说，一篇文件属于什么层级，是国家政策、地方政策、部门规章，还是行政法规；适用于哪个地域，是全国、浙江省，还是某个特定区域；归属于什么业务体系，是政府采购、招标投标、信用管理，还是财政资金；文件类型是什么，是通知、办法、条例、规范，还是政策解读；这些信息都会影响后续知识库的使用效果。

如果标签足够清晰，后面做检索、筛选、问答召回、知识分类时，系统就更容易找到正确内容。

反过来，如果标签混乱、缺失或者打错，知识库看起来文件很多，但真正用起来就会变得不稳定。

比如用户问一个政府采购相关问题，系统却优先召回了招标投标领域的文件；或者用户想查江西省政策，结果混入了一批全国通用法规；再或者文件类型本来是“管理办法”，却被归到了“公告”下面。

单看某一条记录，好像只是一个标签问题；但放到知识库问答和检索链路里，它就会变成召回偏差、依据不准、回答质量下降的问题。

所以，标签不是一个可有可无的装饰字段，而是知识库后续可用性的基础设施。

这也是我觉得这件“小事”值得认真处理的原因。

1.2多文件打标，批量处理并不轻松

一般来说任务的具体背景都是：我需要根据一份 Excel 清单，为知识库中的法规文件批量补充标签。

Excel 里已经整理好了文件对应的标签字段，知识库后台也有对应文件。理论上，只要把两边对上，再把标签填进去就行。

听起来很简单。

但真正开始拆流程后，会发现它其实是一组连续动作：

先在 Excel 里找到文件对应的标签，再去知识库后台找到同名文件，点击标签入口，输入多个标签，保存，然后继续处理下一条。当前页处理完，还要继续翻页。

如果只有十几条，确实没必要自动化。

但这次是近千条记录。如果按每页 10 条计算，就是四十多页。每条文件哪怕只花几十秒，整体也会变成一个非常磨人的任务。

这类工作最消耗人的不是脑力，而是注意力。

刚开始处理时，人还比较清醒，能认真核对；但处理到几十条、一百条之后，注意力一定会下降。越往后，越容易出现漏打、错打、重复打的问题。

1.3真正麻烦的，是“看起来差不多”

这个任务里最容易被低估的地方，是文件名匹配。

业务数据经常不是理想状态。Excel 里的文件名可能带序号、带前缀、带特殊符号；页面上的文件名可能经过清洗，也可能因为展示宽度被截断。

也就是说，不能简单地假设：

Excel 里叫什么，页面上就一定完全叫什么。

如果人工处理，这会带来大量肉眼比对成本。

如果自动化处理，这又会带来匹配风险。特别是法规文件里有很多相似前缀，比如“国务院”“财政部”“政府采购”“招标投标”“管理办法”“实施条例”等。

如果只拿文件名前几个字去匹配，很容易把两个相似文件搞混。

这类错误比脚本报错更危险。

脚本报错至少会停下来，提醒你哪里没处理成功；但如果匹配错了，脚本可能仍然显示“处理成功”，实际上却把 A 文件的标签打到了 B 文件上。

对知识库来说，这种“静默错误”才是最需要防范的。

1.4 AI 工作流介入，快速提效

从这些痛点看，这个任务刚好符合 AI 工作流适合介入的几个特征。

它不是开放性创作任务，而是一个有明确输入、明确规则、明确操作路径、明确验收标准的业务流程。

输入很清楚：Excel 标签清单。

目标很清楚：把标签写入知识库后台。

规则很清楚：哪些列作为标签，哪些标签要跳过，哪些字符要清洗。

操作也很清楚：查找文件、点击标签、输入、保存、翻页。

这类任务如果交给传统开发，可能会显得有点“重”。因为它未必值得专门立项开发一个系统，也不一定值得后端开放接口。但如果完全靠人工，又会浪费大量时间，还容易出错。

这正是 WorkBuddy 这类 AI Agent 工具比较适合发挥作用的地方。

它可以把业务人员的自然语言要求，转成一套可执行流程。业务人员不用从零写完整脚本，但需要把规则说清楚；AI 不只是回答问题，而是可以帮助读取文件、分析页面、生成脚本、调试选择器、处理异常，最后把这件事真正跑起来。

所以，这次实践的重点不是“我让 AI 写了一段代码”。

更准确地说，是我把一个业务维护任务拆成了几个环节：Excel 数据读取→ 标签规则清洗→ 页面文件匹配→ 自动点击与输入→ 翻页处理→ 异常记录→ 结果校验。

然后让 WorkBuddy 协助我把这些环节串成一条工作流。

这个过程更像是一次小型业务流程自动化，而不是单纯的代码生成。

因为在真实业务里，很多提效机会并不来自特别宏大的系统建设，而是来自这些被反复忽略的小流程：批量录入、批量修改、批量审核、批量上传、批量打标签。

它们单个看都不大，但长期堆在一起，就会消耗大量人力。

如果业务工作者能够学会把这些任务拆解清楚，再借助 AI Agent 把它们自动化，就能把很多“重复点击型工作”，变成“规则驱动型工作流”。

而这次知识库文章自动打标签，就是这样一个很具体的例子。

第二章：直接开干，用 WorkBuddy 把流程跑起来

前面讲了为什么这件事值得自动化。到了真正执行时，我的思路很简单：先不要想着一步到位跑完，而是先让 WorkBuddy 帮我把最小闭环跑通。

这个最小闭环包括四件事：

只要第一页能跑通，后面再解决翻页、异常处理和批量执行的问题。

2.1. 先把任务说清楚

我在 WorkBuddy 里不是直接说“帮我自动打标签”，而是先把业务目标、数据来源和处理规则讲清楚。

可以这样描述：

 我现在需要根据 Excel 文件中的标签数据，
 给知识库中的法规文件批量打标签。
 ​
 Excel 路径是：
 /法规文件清单.xlsx
 ​
 需要读取的字段包括：
 - 文件名称
 - 文件层级
 - 适用地域
 - 业务体系
 - 文件类型
 - 主题标签
 ​
 请帮我读取 Excel，确认表头结构，
 然后根据这些字段生成自动化脚本，
 连接当前已经打开的浏览器页面，
 逐条匹配知识库文件并写入标签。

这里有一个小经验：不要一上来就让 AI 写最终脚本。

更稳的方式是先让它确认 Excel 的字段结构。因为很多业务 Excel 并不是标准表，字段位置、表头名称、空值情况都可能和我们想的不一样。

这一步 WorkBuddy 做得比较方便，它可以直接读取本地 Excel，并先帮我确认列结构。

在这次任务里，确认后的字段大致是：

 列2：目录 / 文件名
 列8：文件层级
 列9：适用地域
 列10：业务体系
 列11：文件类型
 列12：主题标签

也就是说，真正要写入知识库的标签，就来自第 8 到第 12 列。WorkBuddy 在执行过程中也是先检查 Excel 表头和样例数据，再生成后续批量处理脚本。

WorkBuddy 先读取 Excel 表头，确认文件名和标签字段所在列，避免后续脚本直接按错误列号读取数据。

2.2把标签规则提前写进 Prompt

确认字段之后，就要把标签处理规则说清楚。

这一步很重要。因为 AI 如果只知道“读取标签”，它默认会把 Excel 里的内容原样写进去。但业务上并不是所有字段都能直接作为正式标签。

这次我设置了两个规则：

 1. 如果标签是“待核验”，则跳过，不作为标签输入；
 2. 如果标签中包含 “/”，则去掉 “/” 后再输入。

比如：

 标准/规范 → 标准规范
 管理办法/规定 → 管理办法规定
 数据安全/电子化关联 → 数据安全电子化关联

这个规则一开始其实也经历过修正。

最开始只说了“标准/规范”要去掉斜杠，结果 WorkBuddy 很可能只针对这个例子处理。后来我补充说明：所有标签里的 “/” 都要去掉，这样规则才完整。

所以这里可以总结一个小技巧：

给 AI 写规则时，不要只给一个特例，要把规则抽象出来。 不是“标准/规范要改成标准规范”，而是“所有标签中的 / 都要去掉”。

对应 Prompt 可以这样写：

 标签处理规则如下：
 ​
 1. 从文件层级、适用地域、业务体系、文件类型、主题标签这几列中提取标签；
 2. 多个标签需要去重；
 3. 空标签跳过；
 4. 如果标签内容为“待核验”，则跳过；
 5. 如果标签中包含“/”，则删除“/”后再作为标签输入；
 6. 最终每个文件可能对应多个标签，需要依次输入到页面标签框中。

这里不是让 WorkBuddy 猜业务规则，而是直接把标签清洗逻辑写清楚。后续脚本会按这个规则统一处理所有标签。

2.3. 让 WorkBuddy 连接浏览器页面

数据准备好之后，下一步就是页面操作。

我当时已经打开了知识库后台页面，所以让 WorkBuddy 通过浏览器控制能力连接当前页面，然后读取文件列表。

这一步的体验比较直接：不需要我手动复制页面源码，也不需要自己一点点分析 DOM。WorkBuddy 可以连接浏览器，查看当前页面元素，然后根据页面结构生成 Playwright 操作脚本。

它大致会完成这些动作：

在实际调试时，WorkBuddy 先发现页面列表能读取到，但是标签按钮一开始没点到。

原因也很典型：页面上看起来是一个“标签”按钮，但它在 DOM 里不一定是标准的 button 或 a 标签，而可能只是一个 span 元素。

这时候 WorkBuddy 的好处就体现出来了。它不是停在“找不到按钮”，而是继续检查当前行里的元素结构，打印操作列的 HTML 和可点击元素，然后修正选择器。

页面上的按钮不一定是标准 button。WorkBuddy 通过读取 DOM 结构，逐步修正选择器，最终找到了真正可点击的“标签”入口。

2.4. 先跑第一页，不急着全量执行

我比较建议所有类似自动化任务都采用这个策略：先跑测试数据，确认效果，再跑全量。

因为批量操作最怕一上来就全量执行。一旦匹配错、规则错、页面点错，影响范围会很大。

所以我先让 WorkBuddy 只处理第一页的 10 个文件。

第一页跑通后，可以先检查三个点：

 1. 文件是否匹配正确；
 2. 标签是否清洗正确；
 3. 页面保存后是否生效。

当时第一页处理后，标签规则已经生效：

 “待核验”没有被写入；
 “标准/规范”被转换成“标准规范”；
 标签可以正常输入并保存。

这一阶段的目标不是追求速度，而是验证流程闭环。

2.5. WorkBuddy 的方便之处：边执行边修

这次实践里，我觉得 WorkBuddy 最方便的地方，不是“它一开始就写出了完美脚本”。

真实情况是，它也会遇到问题。

比如：

 页面列表能读取，但标签按钮没找到；
 第一页能处理，但翻页按钮没识别出来；
 文件名能匹配，但一开始匹配算法太宽泛；
 标签规则能处理，但最初只处理了部分斜杠场景。

但它的优势在于：这些问题可以在一个连续对话里边发现、边修复。

我不需要重新从零描述需求，也不需要自己完整接管脚本。发现问题后，只要继续补充业务反馈：

 这个标签规则不对，所有 “/” 都要去掉；
 现在只跑了第一页，翻页逻辑需要修复；
 文件匹配错了，不能只按前几个字符匹配；
 请先做匹配自检，再正式执行。

WorkBuddy 就可以基于前面的上下文继续修改脚本。

这种体验和传统写脚本不太一样。传统方式里，业务人员发现问题后，往往要重新找开发解释一遍；但在 WorkBuddy 里，问题、上下文、脚本、页面状态都在同一个工作流里，修复速度会快很多。

第三章：从一次打标签任务，看业务工作流的可复制价值

这次用 WorkBuddy 批量完成知识库文章打标签，表面上看只是解决了一个后台维护问题，但它真正验证的是一种更轻量的 AI 提效方式：业务人员先把目标、数据来源、处理规则和验收标准讲清楚，再让 AI Agent 帮忙把重复操作转成可执行流程。过去遇到这类任务，要么手工慢慢处理，要么找开发写脚本；前者容易累、容易错，后者又有沟通和排期成本。而 WorkBuddy 这种方式刚好补上了中间地带：它不要求业务人员从零开发系统，但要求我们把规则说得足够明确，比如标签来自哪些 Excel 列、哪些标签要跳过、特殊符号怎么清洗、页面如何匹配文件、处理完成后如何统计结果。只要这些规则讲清楚，AI 就不只是“回答问题”，而是能帮我们把业务动作真正执行起来。

这次实践里我最大的感受是，自动化真正要防的不是“跑不起来”，而是“看起来跑成功了，但结果其实错了”。比如一开始文件名匹配逻辑过于宽泛，只靠前几个字符匹配，就可能把相似标题的法规文件搞混。对于知识库来说，这种错配比脚本报错更危险，因为它不会马上暴露，却会影响后续检索、分类和智能问答召回。所以类似工作流不能只追求一键全量执行，而要先跑小样本、再修规则、再全量处理。执行前要检查数据结构和匹配关系，执行中要记录成功、失败、未匹配数据，执行后还要抽样复核页面结果。简单说，业务自动化不是越快越好，而是先准，再快。

从这个角度看，知识库打标签只是一个入口。凡是“数据在 Excel 里、操作在网页后台里、规则由业务人员掌握、过程重复但又不能随便出错”的任务，都可以借鉴这套方法。比如批量补充知识库元数据、批量录入供应商信息、批量修改后台字段、批量检查页面数据、批量上传下载资料，本质上都是同一类问题。以后再遇到类似任务，我会优先按这个顺序拆解：先确认数据来源，再确认匹配字段，然后明确处理规则和页面动作，最后先跑一页验证，再全量执行。AI 提效不一定非要从大系统开始，也可以从一次批量打标签开始。真正重要的是，把业务经验沉淀成规则，把重复点击变成流程，把人的时间从机械操作里释放出来。