1. 当RPA CoE遇上GPT一场企业自动化的化学反应第一次听到RPA CoE x GPT这个组合的时候我正蹲在一个流程自动化的项目里焦头烂额。业务方丢过来三十多个流程需求每个都喊着急而团队里能写RPA脚本的就那么几个人排期已经排到了下个季度。那时候我就在想如果有一个东西能帮我把业务人员用大白话描述的需求直接翻译成可执行的自动化流程哪怕只完成百分之六七十剩下的我来补效率也能翻好几倍。后来GPT类大模型的能力爆发我意识到这件事真的可以干了。这篇文章想聊的就是RPA CoE机器人流程自动化卓越中心和GPT类大语言模型结合之后企业自动化到底会发生什么变化。RPA CoE你可能不陌生它是企业内部专门负责RPA能力建设、流程筛选、开发规范、运维治理的一套组织加技术体系。而GPT代表的是大语言模型带来的自然语言理解、代码生成、文档解析、对话交互能力。这两者撞在一起不是简单的11而是把自动化的门槛、速度、范围三个维度同时撬动了。我写这篇东西的目标读者很明确正在企业里搞RPA的中高级工程师、自动化团队的负责人、数字化转型的推动者以及那些被重复性工作折磨到想自己动手的业务骨干。如果你只是听说过RPA但没实操过也没关系我会把关键概念用生活化的方式讲清楚。全文会围绕架构设计、核心能力拆解、落地实操、踩坑排查四个大块展开每一块都尽量给到可以直接抄作业的细节。先说一个我自己的判断RPA CoE x GPT不是未来企业的一个可选项而是正在发生的现实。区别只在于有的团队已经用上了有的还在观望。观望的成本就是你的自动化交付速度比别人慢一个数量级。2. 为什么是CoE加GPT而不是单打独斗2.1 先搞清楚RPA CoE到底管什么很多人把RPA CoE理解成一个写脚本的部门这是最大的误解。CoE的全称是Center of Excellence卓越中心它的职责远不止开发。我把它拆成四层来看第一层是流程治理。企业里成百上千个流程哪些适合自动化、优先级怎么排、ROI怎么算这些决策需要一套标准。CoE就是制定这套标准的人。没有CoE各部门各自为政最后会出现一堆重复的、碎片化的机器人维护成本高得吓人。第二层是开发规范。命名规则、异常处理模板、日志格式、版本管理这些看起来琐碎的东西决定了你的机器人能不能规模化。我见过一个团队早期没有统一规范后来机器人数量过百之后改一个公共组件要动几十个流程那叫一个痛。第三层是运维与监控。机器人上线不是终点而是起点。它会不会半夜挂掉、会不会因为目标系统改版而失效、执行成功率是多少这些都需要集中监控。CoE负责搭建这套运维体系。第四层才是开发交付。也就是真正写流程的那部分工作。而这部分恰恰是GPT能大幅提效的地方。把这四层想清楚你就明白为什么单靠GPT不行。GPT再强它不知道你企业内部的流程优先级不知道你的开发规范不知道你的运维体系。它需要一个容器来承载而CoE就是这个容器。2.2 GPT补的到底是哪块短板传统RPA最大的痛点是什么我用一句话概括它只会照着做不会理解着做。传统RPA的本质是模拟人的鼠标键盘操作或者调用API。它擅长的是规则明确、结构化程度高的任务。但一旦遇到下面这些情况它就抓瞎了输入是一封格式不固定的邮件需要先读懂客户在说什么需要从一份PDF合同里提取关键条款而合同模板每次都不一样业务人员用自然语言描述需求帮我把上周所有超过五万的订单挑出来按地区汇总发给我流程跑挂了报错信息是一堆技术术语需要判断到底哪里出了问题这些恰恰是GPT的强项。自然语言理解、非结构化文档解析、代码生成、异常归因这四件事GPT类模型做得越来越好。把它接到RPA CoE的体系里等于给只会执行的手装上了会思考的大脑。我打个比方。传统RPA像是一个手脚麻利但只会按图纸施工的工人图纸画得越细他干得越好图纸一模糊他就停工。GPT像是一个能看懂草图、还能自己补全细节的工程师。两者配合才是完整的施工队。2.3 组合之后的能力矩阵我把RPA CoE x GPT的能力拆成一个矩阵方便你对照自己团队的现状能力维度传统RPA CoE加上GPT之后需求理解业务方写详细需求文档人工翻译成流程业务方自然语言描述模型辅助生成流程草稿流程开发手写脚本逐行调试模型生成代码骨架人工审核补全文档处理只能处理固定模板可处理多模板、非结构化文档异常处理预设规则命中才处理模型归因给出修复建议交互方式固定表单、固定入口对话式交互随问随答覆盖范围结构化、规则明确的任务半结构化、需要判断的任务这张表我建议你保存下来做团队规划的时候拿出来对照。你会发现加上GPT之后RPA能覆盖的流程范围至少扩大了一倍。3. 核心架构怎么搭从需求到执行的完整链路3.1 整体分层设计我在实际项目里用的架构大致分成五层。从下往上说第一层是执行层也就是传统RPA机器人本身。它负责真正去操作目标系统点击、输入、读取、写入。这一层基本不变还是用你熟悉的RPA工具。第二层是能力层这里放的是GPT相关的服务。包括自然语言理解、代码生成、文档解析、对话管理这些能力。它们以API的形式对外提供服务。第三层是编排层负责把执行层和能力层串起来。什么时候该调GPT什么时候该走传统规则由这一层决定。这是整个架构的大脑中枢。第四层是治理层对应CoE的治理职责。流程注册、版本管理、权限控制、审计日志都在这一层。第五层是交互层业务人员通过这一层提交需求、查看进度、处理异常。可以是聊天窗口也可以是工单系统。这个分层的好处是每一层可以独立演进。GPT模型升级了只动能力层RPA工具换了只动执行层。耦合度低维护起来轻松。3.2 关键组件选型思路选型这块我不给具体产品名因为每个企业的情况不一样给了反而误导。我说说选型的判断逻辑。RPA工具这块如果你团队已经有在用的别换。迁移成本太高。重点看它有没有开放的API能不能被外部程序调用。因为GPT生成的流程草稿最终要注入到RPA工具里执行这个注入通道必须通畅。大模型这块分两种情况。如果企业对数据安全要求极高流程里涉及敏感信息那就用私有化部署的模型。如果只是处理公开信息或者内部非敏感文档可以用云端API成本低、效果好。我个人的经验是先用云端API跑通原型验证价值之后再考虑私有化别一上来就搞重资产。编排引擎这块可以用现成的工作流引擎也可以自己写。如果流程数量不多自己写一个轻量的调度器就够了。如果流程上百个建议用成熟的工作流引擎省得自己造轮子。向量数据库这块如果你要做企业知识库增强让模型回答问题时能引用企业内部文档那就需要一个向量库。这个不是必须的看你的场景。3.3 数据流转的完整链路我拿一个真实场景走一遍你就明白数据怎么流了。业务人员在聊天窗口输入帮我处理一下这个月的报销单把发票信息提取出来填到系统里。第一步交互层把这句话传给编排层。编排层调用GPT做意图识别判断这是一个文档信息提取加系统录入的任务。第二步编排层检查治理层看这个流程有没有注册过。如果注册过直接调用对应的机器人如果没有进入新建流程。第三步如果是新建流程编排层调用GPT的代码生成能力根据意图生成一个流程草稿。草稿包括读取指定文件夹的发票文件、调用文档解析能力提取字段、打开报销系统、逐条录入。第四步草稿生成后推送给人工审核。审核通过后注册到治理层正式成为可执行的流程。第五步执行层的机器人开始跑。遇到发票格式不认识的调用GPT的文档解析能力现场处理。遇到系统报错调用GPT的异常归因能力给出修复建议。第六步执行结果回写到交互层业务人员看到处理进度和结果。这条链路里GPT出现在四个位置意图识别、代码生成、文档解析、异常归因。每一个位置都是传统RPA的痛点。4. 落地实操从零搭一个最小可用版本4.1 环境准备与依赖清单我假设你要从零搭一个原型验证这个组合的价值。下面是我建议的最小依赖清单一台能跑RPA的机器Windows环境居多因为大部分企业系统还是Windows客户端一个RPA工具社区版或者试用版都行先跑通再说一个大模型的API访问权限云端即可一个简单的Web服务框架用来做编排层Python的FastAPI或者Flask都够用一个文件夹放测试用的文档比如几份格式不同的发票或者合同这套东西加起来一个人一天就能搭起来。别追求完美先跑通。4.2 第一步让模型读懂业务需求这一步的核心是提示词设计。我踩过的坑是一开始提示词写得太随意模型返回的结果没法用。后来我总结了一个模板效果稳定很多prompt_template 你是一个RPA流程设计助手。用户会用自然语言描述一个自动化需求。 请你输出一个结构化的流程定义包含以下字段 - task_name: 任务名称 - trigger: 触发方式手动/定时/事件 - steps: 步骤列表每个步骤包含 action动作类型和 target操作对象 - inputs: 需要的输入 - outputs: 产生的输出 用户需求{user_input} 请只输出JSON格式不要有其他内容。 这个模板的关键在于约束输出格式。模型如果不加约束会给你写一大段散文你还得再解析。直接要求JSON后续处理省事很多。我实测下来对于读取文件夹里的发票提取金额和日期填到表格里这种需求模型生成的JSON结构基本可用准确率在八成以上。剩下的两成通常是步骤顺序有点问题人工调一下就行。4.3 第二步把需求翻译成可执行代码拿到结构化的流程定义之后下一步是生成可执行的RPA脚本。这里要注意不要让模型直接生成最终脚本而是生成一个中间层。为什么因为不同RPA工具的脚本语法不一样你让模型直接生成某个工具的脚本一旦换工具就全废了。更好的做法是定义一个中间指令集模型生成中间指令然后你写一个转换器把中间指令翻译成具体工具的脚本。中间指令集可以长这样{ actions: [ {type: read_folder, path: D:/invoices, filter: *.pdf}, {type: extract_fields, fields: [amount, date, vendor]}, {type: open_app, app: reimbursement_system}, {type: fill_form, mapping: {amount: amount_field, date: date_field}}, {type: submit} ] }这个中间层的好处是模型只需要理解业务逻辑不需要关心具体工具的语法。转换器由你来写一次写好终身受用。4.4 第三步文档解析能力的接入文档解析是GPT最能发挥价值的地方。传统RPA处理文档要么用固定坐标要么用正则表达式模板一变就失效。用GPT之后你可以直接把文档内容丢给模型让它提取字段。具体做法是先把PDF或者图片转成文本然后调用模型提取。提示词可以这样写extract_prompt 从下面的文本中提取以下字段以JSON格式返回 - 发票号码 - 开票日期 - 金额只保留数字 - 销售方名称 如果某个字段找不到值设为null。 文本内容 {document_text} 这里有个经验金额字段一定要在提示词里强调只保留数字否则模型会返回人民币伍万元整这种你还得再处理一遍。另外如果文档是扫描件需要先做OCR。OCR的质量直接影响提取效果。我建议OCR和提取分两步走先OCR成文本人工抽查一下质量再喂给模型。别指望一步到位。4.5 第四步异常归因与自愈这是我觉得最有想象空间的一块。传统RPA跑挂了报错信息往往是一堆技术术语业务人员看不懂得找开发。开发看了半天发现是目标系统弹了个没预料到的对话框。加上GPT之后可以这样做机器人捕获到异常时把报错信息、当前屏幕截图、最近几步操作日志一起打包发给模型让模型判断问题出在哪并给出处理建议。提示词示例diagnose_prompt 一个RPA流程执行失败了以下是相关信息 - 报错信息{error_message} - 当前步骤{current_step} - 最近操作日志{recent_logs} 请判断失败原因并给出修复建议。输出格式 - 原因... - 建议... - 是否可自动重试是/否 我实测下来对于元素找不到超时弹窗拦截这几类常见问题模型的判断准确率相当高。有些简单问题模型甚至能直接给出重试方案机器人自己就恢复了。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么办这是最常见的问题。同一个需求模型这次生成的流程能用下次生成的就不行。原因通常是提示词不够具体或者温度参数设得太高。解决办法有三个。第一把提示词写得更具体把输出格式约束死。第二把温度参数调低一般设成0到0.3之间输出会稳定很多。第三加一个校验层模型输出之后用规则检查一遍不符合格式的直接重试。我一般会设一个重试上限比如三次。三次都不行就转人工。别让机器人无限重试浪费资源。5.2 数据安全怎么保障这是企业最关心的问题。我的建议是分级处理。涉及核心敏感数据的流程模型必须私有化部署数据不出内网。涉及一般内部数据的可以用云端API但要脱敏之后再发。涉及公开数据的随便用。脱敏这块我通常会在调用模型之前加一个预处理步骤把身份证号、手机号、银行卡号这些用占位符替换掉模型处理完再替换回来。这个逻辑不复杂但能规避很多风险。5.3 成本怎么控制大模型API是按token计费的用多了成本不低。控制成本有几个技巧。第一能不用模型就不用。规则明确的任务走传统RPA就行别什么都往模型上套。第二缓存重复请求。同样的文档解析请求如果内容一样直接返回缓存结果。第三用小模型处理简单任务。意图识别这种简单任务用参数量小的模型就够了没必要上最大的。第四批量处理。把多个请求合并成一个减少调用次数。我算过一笔账一个中等规模的企业如果合理使用每月的模型成本可以控制在可接受范围内相比节省的人力ROI是正的。5.4 常见问题速查表问题现象可能原因排查方向解决建议模型返回格式不对提示词约束不够检查提示词是否明确要求JSON加强格式约束加校验层提取字段缺失文档质量差或提示词不清晰检查OCR结果和提示词优化OCR明确字段定义流程执行超时目标系统响应慢查看系统日志增加超时时间加重试机制机器人频繁挂掉目标系统改版对比新旧界面更新元素定位加容错成本超预期调用过于频繁统计调用量加缓存用小模型批量处理这张表我建议贴在工位上遇到问题先对照一遍能省不少排查时间。5.5 几个我踩过的坑第一个坑过早追求全自动。一开始我想让模型从需求到执行全自动结果发现中间环节太多任何一个环节出错整个链路就断了。后来改成人机协同模型生成草稿人工审核反而效率更高。别追求一步到位半自动也是进步。第二个坑忽视提示词的版本管理。提示词改来改去最后不知道哪个版本效果好。后来我把提示词也纳入版本管理每次改动都记录效果不好的可以回滚。这个习惯救了我好几次。第三个坑低估了数据准备的工作量。想让模型处理好文档得先有足够多的样本。我一开始只准备了十几份文档模型效果很差。后来收集了几百份效果明显提升。数据准备是脏活累活但绕不过去。6. 这套组合拳到底改变了什么6.1 交付速度的量级提升我拿自己团队的数据说话。以前一个中等复杂度的流程从需求到上线平均要两周。其中需求沟通三天开发五天测试三天上线一天。加上GPT之后需求沟通变成一天模型生成草稿半天人工补全两天测试两天上线一天。总共六天半差不多快了一倍。这还只是单个流程。如果算上需求理解的准确率提升、返工减少整体效率提升更明显。我粗略估算团队的人均交付能力提升了百分之六十到八十。6.2 覆盖范围的扩大以前很多流程我们是不敢接的因为规则太模糊开发成本太高。比如处理客户投诉邮件分类后转给对应部门这种传统RPA做起来很吃力。现在有了GPT做意图识别和分类这类流程也能自动化了。覆盖范围扩大意味着什么意味着CoE的价值被更多业务部门看到预算更好申请团队更有话语权。这是一个正向循环。6.3 对团队能力结构的影响这一点我想重点说。RPA CoE x GPT之后团队需要的能力结构变了。以前最吃香的是手速快、脚本写得溜的开发。现在最吃香的是懂业务、会写提示词、能设计人机协同流程的人。纯写脚本的活模型能干一大半。这不是说开发不重要了而是开发的角色从写代码转向设计架构、审核模型输出、处理复杂异常。对个人来说这是能力升级的机会。对团队来说需要重新规划培训和招聘方向。我建议团队里每个人都去学一学提示词工程不用学多深能写出稳定可用的提示词就行。这个技能在未来几年会越来越值钱。6.4 治理体系的新挑战GPT的引入也给CoE的治理带来了新问题。比如模型生成的流程知识产权归谁模型输出的内容如果出错责任怎么界定提示词算不算核心资产要不要纳入版本管理这些问题目前没有标准答案但每个团队都得有自己的说法。我的做法是把模型输出定位为草稿最终责任由审核人承担。提示词纳入版本管理作为团队资产。这样权责清晰也符合现有的管理框架。7. 我个人的一些实操体会搞了这么久我最大的体会是别把GPT当万能药也别当洪水猛兽。它就是一个工具用得好能放大你的能力用不好就是添乱。我见过一些团队一上来就想搞个大而全的平台结果半年过去了还在搭架子。也见过一些团队小步快跑先在一个流程上验证跑通了再推广三个月就见到了效果。后者才是正确的姿势。还有一个体会是人机协同的边界要动态调整。早期模型能力弱人工审核的比例高一些。随着模型能力提升人工审核的比例可以逐步降低。这个边界不是固定的要根据实际效果不断调整。最后分享一个小技巧。我在设计提示词的时候习惯在最后加一句如果你不确定请明确说明不确定不要编造。这句话能显著降低模型胡编乱造的概率。虽然不能完全避免但能好很多。这个方向后续还可以扩展的地方很多比如把多个模型组合起来用各取所长比如把流程执行的数据回流用来微调模型让它越来越懂你的业务。这些都是值得探索的方向。我现在正在试的是把执行日志结构化之后定期喂给模型做分析找出流程优化的点。初步效果还不错等跑一段时间再跟大家分享。
1. 当RPA CoE遇上GPT一场企业自动化的化学反应第一次听到RPA CoE x GPT这个组合的时候我正蹲在一个流程自动化的项目里焦头烂额。业务方丢过来三十多个流程需求每个都喊着急而团队里能写RPA脚本的就那么几个人排期已经排到了下个季度。那时候我就在想如果有一个东西能帮我把业务人员用大白话描述的需求直接翻译成可执行的自动化流程哪怕只完成百分之六七十剩下的我来补效率也能翻好几倍。后来GPT类大模型的能力爆发我意识到这件事真的可以干了。这篇文章想聊的就是RPA CoE机器人流程自动化卓越中心和GPT类大语言模型结合之后企业自动化到底会发生什么变化。RPA CoE你可能不陌生它是企业内部专门负责RPA能力建设、流程筛选、开发规范、运维治理的一套组织加技术体系。而GPT代表的是大语言模型带来的自然语言理解、代码生成、文档解析、对话交互能力。这两者撞在一起不是简单的11而是把自动化的门槛、速度、范围三个维度同时撬动了。我写这篇东西的目标读者很明确正在企业里搞RPA的中高级工程师、自动化团队的负责人、数字化转型的推动者以及那些被重复性工作折磨到想自己动手的业务骨干。如果你只是听说过RPA但没实操过也没关系我会把关键概念用生活化的方式讲清楚。全文会围绕架构设计、核心能力拆解、落地实操、踩坑排查四个大块展开每一块都尽量给到可以直接抄作业的细节。先说一个我自己的判断RPA CoE x GPT不是未来企业的一个可选项而是正在发生的现实。区别只在于有的团队已经用上了有的还在观望。观望的成本就是你的自动化交付速度比别人慢一个数量级。2. 为什么是CoE加GPT而不是单打独斗2.1 先搞清楚RPA CoE到底管什么很多人把RPA CoE理解成一个写脚本的部门这是最大的误解。CoE的全称是Center of Excellence卓越中心它的职责远不止开发。我把它拆成四层来看第一层是流程治理。企业里成百上千个流程哪些适合自动化、优先级怎么排、ROI怎么算这些决策需要一套标准。CoE就是制定这套标准的人。没有CoE各部门各自为政最后会出现一堆重复的、碎片化的机器人维护成本高得吓人。第二层是开发规范。命名规则、异常处理模板、日志格式、版本管理这些看起来琐碎的东西决定了你的机器人能不能规模化。我见过一个团队早期没有统一规范后来机器人数量过百之后改一个公共组件要动几十个流程那叫一个痛。第三层是运维与监控。机器人上线不是终点而是起点。它会不会半夜挂掉、会不会因为目标系统改版而失效、执行成功率是多少这些都需要集中监控。CoE负责搭建这套运维体系。第四层才是开发交付。也就是真正写流程的那部分工作。而这部分恰恰是GPT能大幅提效的地方。把这四层想清楚你就明白为什么单靠GPT不行。GPT再强它不知道你企业内部的流程优先级不知道你的开发规范不知道你的运维体系。它需要一个容器来承载而CoE就是这个容器。2.2 GPT补的到底是哪块短板传统RPA最大的痛点是什么我用一句话概括它只会照着做不会理解着做。传统RPA的本质是模拟人的鼠标键盘操作或者调用API。它擅长的是规则明确、结构化程度高的任务。但一旦遇到下面这些情况它就抓瞎了输入是一封格式不固定的邮件需要先读懂客户在说什么需要从一份PDF合同里提取关键条款而合同模板每次都不一样业务人员用自然语言描述需求帮我把上周所有超过五万的订单挑出来按地区汇总发给我流程跑挂了报错信息是一堆技术术语需要判断到底哪里出了问题这些恰恰是GPT的强项。自然语言理解、非结构化文档解析、代码生成、异常归因这四件事GPT类模型做得越来越好。把它接到RPA CoE的体系里等于给只会执行的手装上了会思考的大脑。我打个比方。传统RPA像是一个手脚麻利但只会按图纸施工的工人图纸画得越细他干得越好图纸一模糊他就停工。GPT像是一个能看懂草图、还能自己补全细节的工程师。两者配合才是完整的施工队。2.3 组合之后的能力矩阵我把RPA CoE x GPT的能力拆成一个矩阵方便你对照自己团队的现状能力维度传统RPA CoE加上GPT之后需求理解业务方写详细需求文档人工翻译成流程业务方自然语言描述模型辅助生成流程草稿流程开发手写脚本逐行调试模型生成代码骨架人工审核补全文档处理只能处理固定模板可处理多模板、非结构化文档异常处理预设规则命中才处理模型归因给出修复建议交互方式固定表单、固定入口对话式交互随问随答覆盖范围结构化、规则明确的任务半结构化、需要判断的任务这张表我建议你保存下来做团队规划的时候拿出来对照。你会发现加上GPT之后RPA能覆盖的流程范围至少扩大了一倍。3. 核心架构怎么搭从需求到执行的完整链路3.1 整体分层设计我在实际项目里用的架构大致分成五层。从下往上说第一层是执行层也就是传统RPA机器人本身。它负责真正去操作目标系统点击、输入、读取、写入。这一层基本不变还是用你熟悉的RPA工具。第二层是能力层这里放的是GPT相关的服务。包括自然语言理解、代码生成、文档解析、对话管理这些能力。它们以API的形式对外提供服务。第三层是编排层负责把执行层和能力层串起来。什么时候该调GPT什么时候该走传统规则由这一层决定。这是整个架构的大脑中枢。第四层是治理层对应CoE的治理职责。流程注册、版本管理、权限控制、审计日志都在这一层。第五层是交互层业务人员通过这一层提交需求、查看进度、处理异常。可以是聊天窗口也可以是工单系统。这个分层的好处是每一层可以独立演进。GPT模型升级了只动能力层RPA工具换了只动执行层。耦合度低维护起来轻松。3.2 关键组件选型思路选型这块我不给具体产品名因为每个企业的情况不一样给了反而误导。我说说选型的判断逻辑。RPA工具这块如果你团队已经有在用的别换。迁移成本太高。重点看它有没有开放的API能不能被外部程序调用。因为GPT生成的流程草稿最终要注入到RPA工具里执行这个注入通道必须通畅。大模型这块分两种情况。如果企业对数据安全要求极高流程里涉及敏感信息那就用私有化部署的模型。如果只是处理公开信息或者内部非敏感文档可以用云端API成本低、效果好。我个人的经验是先用云端API跑通原型验证价值之后再考虑私有化别一上来就搞重资产。编排引擎这块可以用现成的工作流引擎也可以自己写。如果流程数量不多自己写一个轻量的调度器就够了。如果流程上百个建议用成熟的工作流引擎省得自己造轮子。向量数据库这块如果你要做企业知识库增强让模型回答问题时能引用企业内部文档那就需要一个向量库。这个不是必须的看你的场景。3.3 数据流转的完整链路我拿一个真实场景走一遍你就明白数据怎么流了。业务人员在聊天窗口输入帮我处理一下这个月的报销单把发票信息提取出来填到系统里。第一步交互层把这句话传给编排层。编排层调用GPT做意图识别判断这是一个文档信息提取加系统录入的任务。第二步编排层检查治理层看这个流程有没有注册过。如果注册过直接调用对应的机器人如果没有进入新建流程。第三步如果是新建流程编排层调用GPT的代码生成能力根据意图生成一个流程草稿。草稿包括读取指定文件夹的发票文件、调用文档解析能力提取字段、打开报销系统、逐条录入。第四步草稿生成后推送给人工审核。审核通过后注册到治理层正式成为可执行的流程。第五步执行层的机器人开始跑。遇到发票格式不认识的调用GPT的文档解析能力现场处理。遇到系统报错调用GPT的异常归因能力给出修复建议。第六步执行结果回写到交互层业务人员看到处理进度和结果。这条链路里GPT出现在四个位置意图识别、代码生成、文档解析、异常归因。每一个位置都是传统RPA的痛点。4. 落地实操从零搭一个最小可用版本4.1 环境准备与依赖清单我假设你要从零搭一个原型验证这个组合的价值。下面是我建议的最小依赖清单一台能跑RPA的机器Windows环境居多因为大部分企业系统还是Windows客户端一个RPA工具社区版或者试用版都行先跑通再说一个大模型的API访问权限云端即可一个简单的Web服务框架用来做编排层Python的FastAPI或者Flask都够用一个文件夹放测试用的文档比如几份格式不同的发票或者合同这套东西加起来一个人一天就能搭起来。别追求完美先跑通。4.2 第一步让模型读懂业务需求这一步的核心是提示词设计。我踩过的坑是一开始提示词写得太随意模型返回的结果没法用。后来我总结了一个模板效果稳定很多prompt_template 你是一个RPA流程设计助手。用户会用自然语言描述一个自动化需求。 请你输出一个结构化的流程定义包含以下字段 - task_name: 任务名称 - trigger: 触发方式手动/定时/事件 - steps: 步骤列表每个步骤包含 action动作类型和 target操作对象 - inputs: 需要的输入 - outputs: 产生的输出 用户需求{user_input} 请只输出JSON格式不要有其他内容。 这个模板的关键在于约束输出格式。模型如果不加约束会给你写一大段散文你还得再解析。直接要求JSON后续处理省事很多。我实测下来对于读取文件夹里的发票提取金额和日期填到表格里这种需求模型生成的JSON结构基本可用准确率在八成以上。剩下的两成通常是步骤顺序有点问题人工调一下就行。4.3 第二步把需求翻译成可执行代码拿到结构化的流程定义之后下一步是生成可执行的RPA脚本。这里要注意不要让模型直接生成最终脚本而是生成一个中间层。为什么因为不同RPA工具的脚本语法不一样你让模型直接生成某个工具的脚本一旦换工具就全废了。更好的做法是定义一个中间指令集模型生成中间指令然后你写一个转换器把中间指令翻译成具体工具的脚本。中间指令集可以长这样{ actions: [ {type: read_folder, path: D:/invoices, filter: *.pdf}, {type: extract_fields, fields: [amount, date, vendor]}, {type: open_app, app: reimbursement_system}, {type: fill_form, mapping: {amount: amount_field, date: date_field}}, {type: submit} ] }这个中间层的好处是模型只需要理解业务逻辑不需要关心具体工具的语法。转换器由你来写一次写好终身受用。4.4 第三步文档解析能力的接入文档解析是GPT最能发挥价值的地方。传统RPA处理文档要么用固定坐标要么用正则表达式模板一变就失效。用GPT之后你可以直接把文档内容丢给模型让它提取字段。具体做法是先把PDF或者图片转成文本然后调用模型提取。提示词可以这样写extract_prompt 从下面的文本中提取以下字段以JSON格式返回 - 发票号码 - 开票日期 - 金额只保留数字 - 销售方名称 如果某个字段找不到值设为null。 文本内容 {document_text} 这里有个经验金额字段一定要在提示词里强调只保留数字否则模型会返回人民币伍万元整这种你还得再处理一遍。另外如果文档是扫描件需要先做OCR。OCR的质量直接影响提取效果。我建议OCR和提取分两步走先OCR成文本人工抽查一下质量再喂给模型。别指望一步到位。4.5 第四步异常归因与自愈这是我觉得最有想象空间的一块。传统RPA跑挂了报错信息往往是一堆技术术语业务人员看不懂得找开发。开发看了半天发现是目标系统弹了个没预料到的对话框。加上GPT之后可以这样做机器人捕获到异常时把报错信息、当前屏幕截图、最近几步操作日志一起打包发给模型让模型判断问题出在哪并给出处理建议。提示词示例diagnose_prompt 一个RPA流程执行失败了以下是相关信息 - 报错信息{error_message} - 当前步骤{current_step} - 最近操作日志{recent_logs} 请判断失败原因并给出修复建议。输出格式 - 原因... - 建议... - 是否可自动重试是/否 我实测下来对于元素找不到超时弹窗拦截这几类常见问题模型的判断准确率相当高。有些简单问题模型甚至能直接给出重试方案机器人自己就恢复了。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么办这是最常见的问题。同一个需求模型这次生成的流程能用下次生成的就不行。原因通常是提示词不够具体或者温度参数设得太高。解决办法有三个。第一把提示词写得更具体把输出格式约束死。第二把温度参数调低一般设成0到0.3之间输出会稳定很多。第三加一个校验层模型输出之后用规则检查一遍不符合格式的直接重试。我一般会设一个重试上限比如三次。三次都不行就转人工。别让机器人无限重试浪费资源。5.2 数据安全怎么保障这是企业最关心的问题。我的建议是分级处理。涉及核心敏感数据的流程模型必须私有化部署数据不出内网。涉及一般内部数据的可以用云端API但要脱敏之后再发。涉及公开数据的随便用。脱敏这块我通常会在调用模型之前加一个预处理步骤把身份证号、手机号、银行卡号这些用占位符替换掉模型处理完再替换回来。这个逻辑不复杂但能规避很多风险。5.3 成本怎么控制大模型API是按token计费的用多了成本不低。控制成本有几个技巧。第一能不用模型就不用。规则明确的任务走传统RPA就行别什么都往模型上套。第二缓存重复请求。同样的文档解析请求如果内容一样直接返回缓存结果。第三用小模型处理简单任务。意图识别这种简单任务用参数量小的模型就够了没必要上最大的。第四批量处理。把多个请求合并成一个减少调用次数。我算过一笔账一个中等规模的企业如果合理使用每月的模型成本可以控制在可接受范围内相比节省的人力ROI是正的。5.4 常见问题速查表问题现象可能原因排查方向解决建议模型返回格式不对提示词约束不够检查提示词是否明确要求JSON加强格式约束加校验层提取字段缺失文档质量差或提示词不清晰检查OCR结果和提示词优化OCR明确字段定义流程执行超时目标系统响应慢查看系统日志增加超时时间加重试机制机器人频繁挂掉目标系统改版对比新旧界面更新元素定位加容错成本超预期调用过于频繁统计调用量加缓存用小模型批量处理这张表我建议贴在工位上遇到问题先对照一遍能省不少排查时间。5.5 几个我踩过的坑第一个坑过早追求全自动。一开始我想让模型从需求到执行全自动结果发现中间环节太多任何一个环节出错整个链路就断了。后来改成人机协同模型生成草稿人工审核反而效率更高。别追求一步到位半自动也是进步。第二个坑忽视提示词的版本管理。提示词改来改去最后不知道哪个版本效果好。后来我把提示词也纳入版本管理每次改动都记录效果不好的可以回滚。这个习惯救了我好几次。第三个坑低估了数据准备的工作量。想让模型处理好文档得先有足够多的样本。我一开始只准备了十几份文档模型效果很差。后来收集了几百份效果明显提升。数据准备是脏活累活但绕不过去。6. 这套组合拳到底改变了什么6.1 交付速度的量级提升我拿自己团队的数据说话。以前一个中等复杂度的流程从需求到上线平均要两周。其中需求沟通三天开发五天测试三天上线一天。加上GPT之后需求沟通变成一天模型生成草稿半天人工补全两天测试两天上线一天。总共六天半差不多快了一倍。这还只是单个流程。如果算上需求理解的准确率提升、返工减少整体效率提升更明显。我粗略估算团队的人均交付能力提升了百分之六十到八十。6.2 覆盖范围的扩大以前很多流程我们是不敢接的因为规则太模糊开发成本太高。比如处理客户投诉邮件分类后转给对应部门这种传统RPA做起来很吃力。现在有了GPT做意图识别和分类这类流程也能自动化了。覆盖范围扩大意味着什么意味着CoE的价值被更多业务部门看到预算更好申请团队更有话语权。这是一个正向循环。6.3 对团队能力结构的影响这一点我想重点说。RPA CoE x GPT之后团队需要的能力结构变了。以前最吃香的是手速快、脚本写得溜的开发。现在最吃香的是懂业务、会写提示词、能设计人机协同流程的人。纯写脚本的活模型能干一大半。这不是说开发不重要了而是开发的角色从写代码转向设计架构、审核模型输出、处理复杂异常。对个人来说这是能力升级的机会。对团队来说需要重新规划培训和招聘方向。我建议团队里每个人都去学一学提示词工程不用学多深能写出稳定可用的提示词就行。这个技能在未来几年会越来越值钱。6.4 治理体系的新挑战GPT的引入也给CoE的治理带来了新问题。比如模型生成的流程知识产权归谁模型输出的内容如果出错责任怎么界定提示词算不算核心资产要不要纳入版本管理这些问题目前没有标准答案但每个团队都得有自己的说法。我的做法是把模型输出定位为草稿最终责任由审核人承担。提示词纳入版本管理作为团队资产。这样权责清晰也符合现有的管理框架。7. 我个人的一些实操体会搞了这么久我最大的体会是别把GPT当万能药也别当洪水猛兽。它就是一个工具用得好能放大你的能力用不好就是添乱。我见过一些团队一上来就想搞个大而全的平台结果半年过去了还在搭架子。也见过一些团队小步快跑先在一个流程上验证跑通了再推广三个月就见到了效果。后者才是正确的姿势。还有一个体会是人机协同的边界要动态调整。早期模型能力弱人工审核的比例高一些。随着模型能力提升人工审核的比例可以逐步降低。这个边界不是固定的要根据实际效果不断调整。最后分享一个小技巧。我在设计提示词的时候习惯在最后加一句如果你不确定请明确说明不确定不要编造。这句话能显著降低模型胡编乱造的概率。虽然不能完全避免但能好很多。这个方向后续还可以扩展的地方很多比如把多个模型组合起来用各取所长比如把流程执行的数据回流用来微调模型让它越来越懂你的业务。这些都是值得探索的方向。我现在正在试的是把执行日志结构化之后定期喂给模型做分析找出流程优化的点。初步效果还不错等跑一段时间再跟大家分享。
