AI自动化实战：用大模型+RPA告别重复劳动

这两年我最大的一个体会是“拒绝重复劳动”这句话光靠毅力和时间管理是做不到的真正能帮上忙的是把工具用起来。你可能已经听过很多“人工智能改变世界”的宏大叙事但落回日常工作最实际的用法就是让AI去填那些低价值、高重复的坑复制表格、查文档、整理字段、填系统、核对信息。我去年试过用一类通用大模型服务来批量处理供应商发来的订单确认单把PDF里的关键信息自动抽出来录进系统。那套流程稳定跑了大半年每周省下大概一个整工作日。这篇我就想把这套思路、选型过程和实操细节完整写出来给同样被重复基础工作拖住的人一个可直接落地的参考。1. 先看判断标准什么样的重复工作才值得交给AI1.1 重复劳动的共同特征先说一个很直接的观点不是所有“烦人”的工作都适合交给AI。我发现真正适合自动化处理的重复工作通常有四个共同特征。第一规则非常明确。输入和输出之间有一个基本固定的对应关系比如“从一张采购单里找出金额字段”“把某种格式的日期改成另一种格式”。这类事情一个熟手干十遍以后闭着眼也能干因为每个步骤都不需要临时判断。第二动作高度重复。你可能一天要重复同一个操作几十次甚至上百次比如打开邮件、下载附件、打开某个系统、复制信息、粘贴、点保存。每一遍单独拿出来都不难但连在一起就非常消耗注意力和耐心。第三产出可以预期。做这件事之前你就大概知道结果长什么样无非是几个字段、一行记录、一段固定模板的文本。如果一件事做完你还要反复想“这次结果到底对不对”那它就不是纯重复工作贸然自动化反而会放大错误。第四出错的代价是“高的”但出错本身是“低的”。这类工作通常出错后果要花时间返工但每单的认知难度又低。正因为单调人特别容易疲劳走神一走神就会漏填、填错于是形成恶性循环。我把身边的常见场景按这个标准捋了一遍批量把PDF发票或订单的关键字段录入Excel、把网页表格整理成固定模板、把一段产品描述改写成不同渠道的文案框架、每天汇总邮件里的报价信息、给大量图片做统一命名并归档。这些全都属于“规则清晰、高重复、产出确定”的典型情况。1.2 为什么AI特别适合接这类活很多人一听到“人工智能”就以为要训练模型、写复杂算法其实现在真正能落地的AI自动化核心只有两句话让模型去理解非结构化信息让程序去执行确定动作。以前我们用脚本解决重复工作但脚本最怕遇到“不规整”的输入。拿采购单来说有的供应商把金额写在右上角有的写在表格里有的连“金额”两个字都不写直接给个数字。传统脚本根本扛不住这种变化你必须为每种格式写一套解析规则。而大模型可以读完整张单子按语义把“供应商”“日期”“金额”这些概念对应到正确的位置上这就把过去靠人眼来做的“模式识别”部分解放出来了。还有一个原因是边际成本低。一次自动化流程建起来以后再接一万条新任务也只是增加一点机器运行时间不会像人那样越来越疲倦。而且AI不会因为做了五百遍就变得敷衍它的状态维持在同一个水平线上这对质量稳定是一件好事。不过也要泼盆冷水AI不是“人”的替代它更像一个“手脚麻利但需要盯一眼的新实习生”。你交代清楚规则它跑得又快又便宜但如果规则没说清或者输入质量太差它会犯一些我们觉得“低级”的错误。所以做AI自动化本质上是在做流程梳理你得先把自己脑子里的隐性规则全部变成显性规则机器才有办法替你执行。2. 动手前先选型三类AI自动化工具怎么选2.1 第一类通用大模型接口适合语义理解和抽取这类方案指的是通过调用云端大模型服务的API把文本或图片内容交给模型去处理。最常见的用法是“给一段非结构化文本让模型提取指定字段并按固定结构返回”。它在哪类场景下表现最好你把大量PDF、邮件、OCR识别出来的文字、用户评论、客服聊天记录丢进去让它抽关键信息、做摘要、打标签、改写成不同风格。可以说凡是需要“读一段东西→按规则输出一段东西”的活都适合交给大模型。选这类方案时我建议重点看三个参数支持上下文长度、是否支持结构化输出、单次调用价格。上下文长度决定了单次能处理多长的文档结构化输出则决定了你能否稳定拿到JSON而不是一段带解释的散文。这两个参数直接决定了你写解析代码时是轻松还是想骂人。个人经验是先跑一批真实样本比如20条把模型的输出拿去做严格校验别再只看一两条的效果就上线。模型在样本多样性不够时表现会虚高真实数据一上来错误率很容易反弹。2.2 第二类RPA界面自动化适合老旧系统操作大模型再强也改变不了很多企业还在用老旧的客户端程序、网页系统的事实。这些系统不提供接口数据根本没法直接从后端读出来。这时候要靠RPA机器人流程自动化这类工具模拟人工的鼠标键盘操作点开搜索框、输入条件、点击确定、读取页面信息、填到下一个系统里。RPA的优点是“万能”只要是人能在界面上做的操作理论上它都能模拟。但它的缺点也一样明显脆弱。页面只要改一个控件名、换一个按钮位置脚本可能就当场报废。我见过有人花两周搭的流程因为上游系统做了一次界面改版直接废掉一大半逻辑。所以RPA适合的场景是你确实拿不到接口而且界面相对稳定、变更频率低。使用时要给关键步骤增加“判断页面是否加载完成”的等待逻辑别用固定延时去傻等否则系统一慢就乱套。2.3 第三类轻量脚本加模板工具适合确定性的数据清洗有一些重复工作根本用不上大模型纯靠脚本就能处理。比如按规则批量重命名文件、把Excel多列合成标题、清洗掉字段里多余的空格和换行、拆分合并表格、把数据按模板灌进Word或PDF。这类工作我不建议用大模型去做因为大模型在处理精确格式时反而不如程序稳定。你让模型把几千行的表格按条件做分类它可能会在某个边界判断上突然发挥你的“想象力”但脚本会让每条数据处理逻辑完全相同可审计性也强。第三类方案的优点是成本极低、稳定性最高、适合大规模跑批。缺点是它需要一点编程基础至少得会读简单的Python或者掌握Excel高级功能。如果完全不想碰代码也可以考虑办公软件自带的自动化脚本功能它能把“打开文件→处理→保存”这类动作录制成宏再配合模板使用。2.4 选型判断的核心原则面对一个具体任务我建议按这个顺序做判断。先问自己这个任务的难点在“理解”还是在“操作”。如果难点在于把非结构化信息读懂比如要理解一段客服对话里的退款原因那优先考虑大模型如果难点在于执行一连串固定的界面点击和填写那优先考虑RPA如果只是数据按照确定规则变换位置和格式那纯脚本就够。再想一个组合拳很多真实流程是操作和理解混合的。比如要让RPA打开一个扫描件再用OCR转成文字丢给大模型抽取字段最后通过RPA把结果填回老系统。这个流程里RPA负责“动手”模型负责“读图认字”脚本负责“校验数据”各干各最擅长的事。我整理过一张对照表平时选型时可以直接参考方案最适合的场景上手难度单量成本稳定性大模型接口文档信息抽取、文本分类、改写、摘要中低按调用量计单量成本低依赖模型质量需加校验RPA界面自动化跨系统操作、老系统录入、网页抓取中高固定开发成本运行成本低易受界面变更影响脚本与模板Excel清洗、批量文件处理、格式转换中一次性开发成本最高完全确定实际上你大概率用不到特别高级的方案。一个几千行的表格、几百份PDF、几十个网页信息收集靠“脚本大模型接口”的组合就能覆盖八成需求反而比一上来就搭一个复杂的RPA工程更省心。3. 完整实操案例把三百份PDF订单变成系统数据3.1 业务场景与需求拆解拿我实际跑过的一个流程做示范合作方每天用邮件发来一批采购确认单每一份是PDF文件里面有供应商名称、采购单编号、日期、金额明细、经办人等信息。原本的做法是人工打开PDF、肉眼找字段、再手动录进企业内部系统。一天几十份遇到月底峰值能到上百份怎么都绕不开。这个流程拆开以后只有四步拿到PDF文件、读出里面的文字、从文字里抽字段、把字段写入目标系统。前两步是“设备和格式问题”后两步是“语义理解问题”。第一版方案先考虑用PDF解析库直接抽取文本。试了一下发现部分供应商发的是扫描件解析库只能拿到乱码于是引入OCR引擎让扫描件先变成可搜索的文本。这一步本身是典型的“非结构化转结构化”也是后面模型能稳定发挥的前提。3.2 关键技术参数与实现细节给模型设计提示词时我最看重的是输出稳定性。下面这段代码展示了核心流程import json import requests def llm_extract_order(text: str) - dict: prompt f 你是一个采购确认单信息抽取助手。请从以下单据文本中提取字段并以JSON返回。 必须包含字段purchase_no, supplier, date, total_amount, item_count 规则 1. 金额统一转为数字保留两位小数。 2. 日期统一转为YYYY-MM-DD格式。 3. 如果某个字段在原文中无法确定统一填null不要猜测。 4. 只输出JSON不要输出任何解释。 单据内容 {text} # 这里填入你自己的大模型服务地址和密钥 resp requests.post( YOUR_LLM_ENDPOINT, headers{Authorization: Bearer YOUR_LLM_KEY}, json{ model: your-llm-model, messages: [{role: user, content: prompt}], temperature: 0, response_format: {type: json} }, timeout30 ) data resp.json() return json.loads(data[choices][0][message][content]) pdf_text extract_pdf_text(sample_order.pdf) # 扫描件可先走OCR result llm_extract_order(pdf_text) print(result)有几个参数我特别想强调。第一个是temperature温度我这个设成了0。对大模型来说温度越低随机性越低。在信息抽取这种任务里我要的是“稳定复现”不是“每次都有小惊喜”所以必须调成0。第二个是response_format字段要求返回JSON。如果没有这个约束模型可能会给你返回“好的我找到了以下字段……”这种带着解释的段落后面解析代码就烧了。有了结构化输出约束结果永远是干净的一段JSON代码处理省太多事。第三个是在提示词里明确写“无法确定时填null”。这是很多人的真实需求宁可让流程知道“这个字段没抽出来”也不能让它硬编一个值进去。缺字段后进人工复核通道总比写一条错数据要好。3.3 校验环节不可少置信度与人工复核很多第一次做AI自动化的人会把全部希望压在模型输出上结果一跑真实数据就发现漏洞百出。我的经验是把模型当成“高效率初审员”它产出初稿后面必须跟一道规则校验。比如金额字段我就写了一个校验函数抽出来的一定是数字大于0且不超过某个合理上限。日期字段则要能被解析并且落在合理范围内。单号则用正则匹配既有前缀规则。这些校验一旦失败这条记录不阻塞整个流程而是单独放进“待人工复核”名单里。这个设计非常关键等于给流程留了“逃生门”。有一次某供应商突然改了下单格式模型把金额和数量弄混了规则校验立刻拦下了一大半异常数据而没有让错误直接写进业务系统。如果我把自动输出直接接到数据库里那天的错数据就真成事故了。我也算过这笔成本账按每天处理60份订单的规模每份文本大概1500个输入token加上输出每次调用按市面常见的单价算大概几分钱。一天下来几块钱一个月也就一百来块。但如果是人工做每单至少两分钟一天就是两小时以上而且人还会累、会瞟错行。这笔账怎么算都划算。实操时别急着全量上先拿最近20份历史单据测试统计准确率前把错误样例的失败原因归类。第一次跑下来我自己的版本大概有15%的字段错误后来把几类错误样例补充到提示词里改成“拒收包含大写金额与数字金额不一致的单据”这类规则准确率很快升到了98%左右。4. 坑很多一起排落地中的问题与排查技巧4.1 模型输出一会儿对一会儿错怎么办这是最让人火大的问题。明明拿20份样本测的时候好好的一到真实环境就偶尔抽风而且抽风还没有规律。排查时先确认几件事温度是不是设成0了输入文本是不是在某个环节被截断同一份样本换个时间调用结果是否一致。如果结果不稳定大多不是模型“想太多”就是输入变化太大。一个非常有效的办法是给提示词加“少样本示例”。我在提示词里附上两三条输入输出对明确告诉他“照着这个样式抽”。大模型对示例的遵从度很高加几个例子能把准确率拉高一大截。还有一招是“双模型投票”。对于关键字段用两个不同配置的模型各跑一遍结果一致才放过去不一致就交给人工。成本大概是翻倍但用在金额、账号这类高风险字段上完全值得。4.2 OCR识别不准怎么处理扫描件是很多自动化流程的噩梦。分辨率一低字迹一模糊OCR就会把“8”认成“0”把“张三”认成“张兰”。这种错非常隐蔽因为程序不会报错只会给你一个看起来合理的错误值。我踩过最深的坑是没有在OCR之前做图像增强直接拿200dpi的灰底扫描件去识别。后来先在图像处理阶段放大两倍、加强对比度再把图片转成黑白模式识别率提升非常明显。画质这个东西对OCR影响比模型选择还大。另一个实用技巧是对多个OCR引擎的结果做交叉校验。同一个区域让两个引擎都读一遍一致才采信。如果时间充裕还可以针对金额这种关键区域单独做一次局部识别只放大那一块区域再读效果比识别整页更好。4.3 数据安全合规顾虑如何应对把业务数据发给外部模型服务很多人都会担心敏感信息泄露。这个担心确实合理。处理时我建议先分类这种数据是否真的敏感是否包含个人隐私或客户核心资料。如果敏感最稳妥的方案是选择支持私有化部署的模型服务把数据留在内网。如果条件不允许至少要经过脱敏再调用接口比如把真实姓名替换成假名用完之后销毁调用记录。更狠一点的做法是自己本地起一个开源小模型专门只接这类信息抽取任务虽然效果可能略逊于云端大模型但数据不出内网这一条就已经值回票价。4.4 高频问题速查表我整理了实际项目中十条最常见的现场问题现象常见原因处理方式字段漏抽输入文本截断或提示词没有枚举该字段检查截断逻辑在提示词中明确枚举所有字段金额多一位少一位OCR把千分位分隔符认错对金额做规范化校验强制数字正则日期格式五花八门各供应商原始格式不一致提示词要求统一格式代码里再次parse模型偶尔输出空JSON网络超时或模型返回被截断增加重试机制失败后标记为人工处理跑批中途报错大模型API限流加退避重试控制并发数明明有值却抽成null提示词过度强调“不要猜”区分“原文没有”和“没识别出来”两种状态一段时间后错误率上升上游文档格式改变定期抽检最近批次的准确率更新示例到提示词界面自动化突然失灵页面元素名称或位置变更改用相对位置定位增加异常提醒结果重复写入了流程重跑或者脚本没有做幂等数据库加唯一键写之前查重人工复核名单太长校验规则过严分级校验按风险不同设置不同严苛程度这些大多数不是模型的问题而是工程化问题。素材清洗、边界处理、异常兜底这些环节做扎实了AI自动化才能真正从“能跑”进化到“稳跑”。5. 别光看回头上的爽还要收好尾上线后的管理与边界5.1 先算清ROI再动手见过不少团队听到AI自动化兴奋地召集人手搞了一个月最后上线一个只处理了某个边缘场景的复杂系统这个模式明显不健康。在动手之前我建议正式地算一笔账。把一件事自动化之后到底能省多少时间关键是频率乘单次耗时。比如一个动作需要三分钟每天做二十次一天就是一个小时一个月就是二十个小时。哪怕开发这个自动化要花两个整天第三周开始就已经回本了。但如果你只是每天做三次每次半分钟一个月也就半小时那真没必要大动干戈。算账时还要把维护成本算进去。自动化工具不是一劳永逸的上游系统一变、模型接口价格一变、业务流程一调整都可能需要你回来改代码。如果省下来的时间还不够你在维护上花的时间这个自动化其实就是负债。5.2 人机协作的边界哪些仍要人来做说到底工具是给人放大生产力的不是来替你做决策的。我自己的原则是让AI做“客观标准明确、出错了也能被规则拦下”的活不让AI做“责任重大或需要同理心”的活。比如自动群发催款邮件这种事哪怕让客户关系管理工具去做可能更高效我也会坚持加一道人工审批。因为一旦发错对象、措辞不当造成的影响不只是数据错误还是信任问题。同一道理合同条款审核、招聘初筛、涉及外部发文的任何内容AI都只能做初稿和候选排序最终落笔必须是人。反过来在内部数据整理、统一格式转换、非关键场景的信息检索这些领域AI完全可以放手多做一些。把人的时间尽量留在需要判断、沟通和创造价值的环节这才是“拒绝重复劳动”的正确姿势。5.3 从小处试点再逐步扩大最后分享一个小经验别一上来就搞那种横跨五个系统的全流程自动化。先挑一个最痛、最简单、风险最小的流程试点跑通之后再用这套经验复制到其他环节。这个思路能显著降低失败概率也更容易让其他同事接受“AI干活”这件事。我在实际操作中的体会是每次做这类自动化收获最大的往往不是省下来的那几个小时而是倒逼自己重新梳理了一遍业务逻辑哪些步骤其实毫无价值哪些步骤一直重复是因为没人敢改流程哪些信息其实早就可以从一个系统直接流转到另一个系统。AI自动化是一个很好的“流程体检工具”哪怕最后只跑通了一个小环节你对工作本身的理解也完全不一样了。最后再分享一个具体的小技巧如果你刚开始接触别直接上手写代码可以先从现成的办公插件或者低代码平台开始把“读取文件→调用模型→写入表格”的动作拖出来体验一遍。等你对中间各种坑有感觉了再换成代码实现也不迟。这个循序渐进的过程能让你少走很多弯路也更不容易因为一次失败就轻易放弃。