ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

RPA开发实战:用GitHub Copilot提效50%的真相与踩坑记录

RPA开发实战:用GitHub Copilot提效50%的真相与踩坑记录 1. 立项复盘这个RPA项目到底要解决什么问题1.1 项目最初的需求一个没人想干的重复活这个项目去年底启动背景很朴素团队里有个运营助理每天要花大概3个小时做一件事——去电商后台导当天的订单报表然后打开物流平台批量查询物流状态再把结果按订单号回填到内部共享表格里。这事不难纯机械操作但它有个致命问题容易出错。复制错行、漏查单号、格式粘错列一个月里总有几次因为这种低级错误导致客服那边拿到的物流信息对不上客户来催单时一头雾水。那时候我们其实已经在接触RPA的概念了。市面上主流的RPA工具像影刀、UiBot、金智维这些宣传口径都差不多——让机器人帮你干活替代重复劳动。老板看了这些宣传第一反应是能不能用RPA把这个助理的活全干了省下这3个小时甚至考虑后面人员调整的事情。这里我得插一句我在项目启动前就跟老板把话说明了RPA能替代的是操作不是岗位。运营助理除了这三小时机械活还有跟客服对接、处理异常订单、跟仓库确认库存这些需要判断和沟通的事。RPA能把机械部分拿掉让人把省下来的时间用到判断和沟通上这才是有意义的画面。老板嘴上说明白明白但我知道他心里想的还是能不能少招个人。这个心态在后面项目上线时给我们埋了不少雷后面细说。1.2 为什么选了影刀而不是纯Python硬写团队里没人系统学过RPA但有人会一点Python。一开始有人提议这活不就是读Excel→调接口→写Excel吗直接写个Python脚本跑不就完了为什么要用RPA我当时的判断是这样的如果这是一个一次性的事Python脚本没毛病。但这是一个要长期每天跑、且由非技术同事参与维护的流程情况就不同了。影刀这类RPA工具的核心价值在于它把跟浏览器打交道这件事封装成了可视化组件你不需要理解DOM结构、不需要处理异步加载、不需要写一堆selenium或者playwright的代码就能完成网页元素的点击、输入、抓取。而且影刀的企业版支持应用迁移、集中管理、异常告警这些配套能力这些是裸写Python时得自己造轮子的地方。实际开发中我们也是混编的界面操作部分用影刀的可视化组件数据处理部分比如解析订单号、清洗金额字段、按日期分组统计用影刀的Python扩展写。这个组合在后面配合GitHub Copilot的时候效率提升特别明显后面专门讲。1.3 Copilot加入的契机为什么敢在RPA项目里用它项目开始开发那阵正好赶上GitHub Copilot在团队里开放了名额。我们用的是VS Code GitHub Copilot的订阅方案个人版每月10美元的档位学生有认证优惠团队里几个开发都配上了。说实话最开始我没指望Copilot能在RPA项目里发挥多大作用。影刀是中文界面的可视化工具跟VS Code的联动也不是天然无缝的Copilot再强也不可能帮你拖组件。但实际用下来Copilot帮了大忙而且省出来的时间比我预想的多得多这就是标题里省了一半开发时间的来源。不过我也得诚实说省一半时间不是指整个项目周期从两个月变成一个月而是指纯编码和调试这个环节耗时大概少了50%到60%。项目里真正占时间的从来不是写代码而是后面会讲到的流程梳理、稳定性测试和上线运维。这个认知如果一开始没建立好很容易对Copilot产生不切实际的期待然后失望。2. Copilot真正帮我省时间的地方不是你想的那种自动写代码2.1 需求梳理阶段的提效把模糊需求变成可执行的清单很多人用Copilot的姿势是打开编辑器开始敲代码让AI补全。但我发现它还有一个更值钱的用法——在写代码之前先让它帮你把需求理清楚。有个例子印象很深。当时有个子需求把订单表中的金额列做个校验看看有没有负数或者异常值。听起来简单但异常值到底指什么是格式异常还是数值异常是金额为0还是金额超过某个阈值如果我去问运营同事她们会说就是不正常的数据呗这种对话效率极低。我把这个问题丢给Copilot提示词大概是我们有个订单金额列需要清洗后写入新表请帮我列举在电商订单场景下金额列可能出现的所有异常情况并给出对应的Python校验逻辑。结果Copilot列了十几种情况空值、非数字文本比如120.5带了货币符号、千分位逗号、负数、异常大的数值可能来自测试订单或退款、尾数精度问题三位小数、科学计数法……每一种还给了示例代码。这个清单的价值不在于代码写得有多好而在于它逼着我去跟业务方确认你们说的异常到底覆盖不覆盖退款负金额千分位格式要不要处理确认完这些后面的开发方向一下子就清晰了。这一步至少省了两到三天的来回沟通时间还避免了我把需求想当然地做错。2.2 代码生成阶段的提效从零到一最快从一到九也还行影刀的Python扩展里数据清洗类代码是Copilot发挥最稳定的场景。比如用openpyxl读取Excel、用pandas做分组汇总、把日期字符串统一成标准格式、按订单号关联两个Sheet——这类任务在GitHub上有海量样本Copilot训练的时候见过无数遍生成的代码质量相当能打。举一个具体例子。运营要的报表每天需要从原始订单表里筛选出已支付且未发货的订单同时把收货人手机号脱敏只显示前三位和后四位再按省份统计订单量分布。这个逻辑如果用传统方式写我先得想清楚pandas的布尔索引怎么写、字符串切片脱敏怎么处理、groupby之后怎么重置索引……大概要花20到30分钟。用Copilot的话我把需求和示例输入数据几行脱敏后的样例贴在注释里它一次就能给出能跑的代码我再花两三分钟做边界检查搞定。还有一个高频场景是正则表达式。RPA抓网页数据经常碰到一堆乱七八糟的文本比如从物流详情页里抓出的2024-03-15 14:32:00 已签收签收人前台要提取时间、状态、签收人三个字段。手写正则那段我估计得折腾十几分钟Copilot基本上输入样例就返回几组候选选一个测试通过就能用。这种小而杂的文本处理任务恰恰是RPA开发里出现频率最高、最磨人的部分Copilot在这里的价值怎么夸都不过分。2.3 调试对话的提效把报错信息直接丢给它写代码最烦的不是写是调。RPA脚本里调得最多的不是语法错误而是数据跟预期不符。比如说明明筛选状态已发货结果返回的行数跟Excel里数出来对不上。我以前的做法是打印中间结果一行一行看。现在我的做法是把代码块、输入数据样例、预期输出三样东西一起贴给Copilot让它分析哪里出了问题。有一次它一眼看出来我的筛选条件写成了字符串已发货但原始数据里存的是已发货 带空格不匹配导致漏行。这种问题靠肉眼盯盯十分钟不一定能发现AI看两眼就明白了。还有一次是日期过滤的问题。我要筛选最近7天的订单自己写的逻辑是pd.Timestamp.now() - pd.Timedelta(days7)但跑出来的结果总差一些。Copilot提醒我订单表里的日期是字符串比较时应该先转成datetime64而我用的是pd.to_datetime之后忘了赋值回去直接用没转的那个Series做比较了。这种细节卡住的时候真是想破头也想不出来。2.4 文档与注释生成给交付文档省下的时间这个属于意外收获。项目上线前要写操作手册给运营同事看的那种。我本来打算自己写结果花了半小时写了开头两页就写不下去了——操作手册有个特点要写得像个傻子都能看懂而程序员最不擅长的就是这个。我换了思路先把影刀流程里每个模块的操作说明用一句话列出来丢给Copilot让它用给完全没有技术背景的运营同事看的语气扩写成一步步的操作手册。它生成的结构是打开软件→找到对应的流程应用→点击运行→输入账号密码→等待完成→查看结果文件每一步配一句如果遇到XX情况请截图联系IT的兜底说明。比我写的强多了。后来我还让它根据项目实际的数据字段生成了一份异常数据对照表什么样的数据会导致流程中断、大概是什么原因、怎么找IT处理。这份文档后来运营同事反馈很实用其实就是Copilot的功劳我只是做了最后审核。3. 被Copilot坑过的三类场景效率提升的天花板在哪3.1 影刀组件与Python混编时的上下文断裂前面夸了Copilot在数据清洗方面的表现但它有一个明显的盲区影刀可视化组件生成的操作步骤它完全看不到。影刀里的组件比如点击网页元素填写输入框读取表格数据保存为流程应用后核心逻辑是跑在影刀自己的运行时上的。我用VS Code写Python扩展时Copilot能看到的只有我这个py文件并不知道上游这一步是从哪个网页抓的数据、抓下来存在哪个变量里、变量名是业务方起的还是影刀自动生成的。这就导致一个很尴尬的情况Copilot生成的Python函数逻辑没问题但跟影刀流程对接时经常会遇到变量对不上、参数类型不匹配的问题。举个真实例子。影刀从网页上抓取了一个表格存储为二维列表然后丢给Python扩展处理。我在Python里写好了一个函数入参是订单号列表但影刀实际传进来的数据结构顶层是列表里面每个元素是字典还是列表取决于影刀版本和抓取方式。Copilot生成代码时假设的是标准JSON结构跑到一半报TypeError: string indices must be integers一查原来是元素结构跟预期不一样。这种问题Copilot帮不上什么忙因为它的上下文里没有影刀那边的代码和数据结构定义。解决方式只能是我自己在Python文件开头用注释把影刀传入的数据结构样例写清楚再让Copilot在写代码时参考这个样例。这算是个小技巧但本质上还是得靠人来做翻译和对齐。3.2 流程编排逻辑Copilot给不出全局最优解Copilot在单点任务上很强但在整个流程怎么编排这种全局问题上基本帮不上忙。RPA流程设计其实很像设计一条流水线先打开后台页面然后判断是否弹出登录框如果弹了就先登录登录完要做滑块验证怎么办验证码识别失败重试几次数据读取完之后先做清洗再做汇总汇总结果怎么写入Excel写完之后要不要发邮件通知邮件发失败了怎么处理……这些步骤之间的依赖关系、异常分支、超时策略需要的是对整个业务流转的理解而不是一段代码。我试过把整个流程的描述贴在Copilot里问它这样设计流程合不合理它给出来的建议基本停留在建议增加异常处理建议增加日志记录这种通用层面给不出登录后可以先做一个元素存在性检查再继续不然下一步点击会不稳定这种有业务深度的建议。原因也简单Copilot是基于海量代码样本训练的而一个具体公司的RPA流程编排90%的业务上下文它都不知道。它能给你一堆模式化的建议但不能替你决策。3.3 业务规则与账号权限AI理解不了人的规矩这个是Copilot最无能为力的领域业务规则。我们的流程里有一条规则当天下午三点前支付的订单要在当天下午六点前把物流状态查询结果同步到共享表三点后的订单延迟到次日处理。这个规则实现起来就是一行判断if order_time.time() datetime.time(15, 0): process_today() else: process_tomorrow()。代码不难难的是这个规则本身。问题在于Copilot不知道这个规则的业务背景它生成的代码往往直接按当前时间是否超过15点来判断而不是读取订单的支付时间。我第一次跑测试的时候就发现了这个问题一查完全是我在提示词里没说清楚。你要是把业务规则原样写进注释里它倒是能理解但问题是非技术同事脑子里那些默认的潜规则——比如A客户特殊周六不要自动查物流退款单不查物流只处理标准订单赠品订单忽略——这些没人写在文档里的东西你自己不梳理出来Copilot永远不知道。这也是我在这个项目里最大的教训之一Copilot更像是代码加速器不是一个需求探测器。需求搞错了它帮你写出来的代码越快你后面返工的时间就越长。4. 从写完脚本到上线可用时间都花在哪了4.1 流程稳定性的坎从demo到可上线的距离代码写完了逻辑也通了demo演示给运营看大家都很兴奋哇真的自动跑起来了但demo能跑和每天能稳定跑是两码事。第一关是页面元素选择的稳定性。影刀获取网页元素时我们最开始用的选择器是基于固定ID的测试环境下一切正常。但电商后台的页面结构一到正式环境就变了可能因为权限不同页面上多了几个隐藏模块元素的顺序变了或者某个字段的class名带了动态参数。最典型的表现就是明明测试的时候各种正常一跑到正式环境第一步点击就失效了或者找到了元素但点不动。解决办法是用更鲁棒的选择方式优先用文本内容定位比如点击页面上文本为导出报表的按钮而不是点击id为btn_export_123的按钮。同时给关键步骤加上元素等待逻辑页面没加载完就不往下走最多等30秒。这种调优过程看着不起眼但反反复复测试了大概一周才把整个流程从十次能成九次推到连续跑两周不出错。这里必须多说一句网页自动化稳定的核心不在于RPA工具本身而在于你对目标网页的了解程度。不同页面加载方式是异步渲染还是同步渲染按钮点击后是立即跳转还是先弹确认框表格数据是一次性加载还是滚动懒加载……这些都得在测试阶段摸清楚。Copilot在这块完全没有用武之地因为它根本没法帮你看网页的实际行为。真正有效的方式就是在影刀里跑一个模块、观察一个模块把页面响应时间、元素变化规律记录下来一天一天地攒经验。4.2 数据异常的边界10万行Excel里的脏数据上线前我们做了一个压力测试拿过去半年约10万行的真实订单数据跑一遍完整流程。这一跑各种意想不到的数据问题全冒出来了。金额字段有带符号的有带千分位逗号的有存成文本格式的Excel里左上角有个绿色小三角还有把退款金额录成负数的日期字段有2024/3/15这种斜杠格式有2024年3月15日这种中文格式还有干脆是时间戳的一串数字收货地址里有大量备注放快递柜这种尾巴脱敏逻辑如果不做文本清理会把手机号附近的括号内容也一起处理掉。这些数据的清洗规则Copilot帮了很大一部分忙但也只是帮忙写清洗函数。真正的难点不是清洗代码本身而是发现原来数据有这么多脏的类型。这个发现过程靠的是什么靠的是把真实数据跑一遍把报错的地方一个个拎出来看再回头跟业务方确认这个数据你们从来没见过吗哦这是去年双十一期间的老系统导出的格式不一样可以忽略。这种确认工作AI替不了。做完清洗和容错处理后我们额外加了一个数据质量报告模块每次跑完把处理了多少行、清洗了多少个异常字段、有多少行因为数据不合法被跳过汇总成一张表发给运营同事。这一步特别有价值因为运营能清楚地看到流程处理了多少数据、有没有偷偷丢掉什么东西信任感就是这么建立起来的。4.3 上线后的运维与监控RPA项目真正的成本项目上线只是开始真正的成本在运维。我们上线后的前两周几乎每天都有小状况后台页面改版导致选择器失效、网络慢导致超时、登录态过期需要重新扫码、共享表被同事手动改动数据导致写入冲突……最频繁的问题集中在两个点一是页面元素失效二是登录态过期。这两个问题如果你不做监控它们是静默失败的——流程跑完了但实际什么都没做对数据没更新而你不看日志根本不知道。我们最终搭了一套简单的监控机制每天流程跑完后往钉钉群里推送一条消息内容包括今天处理了X行数据、成功Y行、失败Z行、耗时M分钟。如果流程中途异常退出也会推送一条包含错误截图和日志摘要的告警。这样运营同事每天早上看一眼群消息就知道昨天有没有出问题不用每天手动去核查数据有没有更新。再往深一层说RPA项目的长期成本测算不能只算省了几个小时要把维护成本算进去。我见过不少团队项目上线时兴高采烈三个月后因为页面改版没人维护机器人跑不了了又没有人愿意接这个脏活项目就废了。所以我的建议是项目上线前就要确定谁负责后续维护、维护周期怎么安排、每季度要预留多少工时做兼容性检查。不然再好的自动化流程也会慢慢烂掉。5. RPA替代人力的真实剧本省人的前提是先学会用人5.1 替代人力的前提是流程先标准化这个项目做到一半我对替代人力这件事有了更清醒的认知。RPA能替代的只有已经标准化了的操作。如果这个操作本身每天都在变RPA去追着变成本极高还追不上人。什么是标准化操作就是有明确输入、明确输出、明确处理规则的动作。比如读订单表→查询物流→回填状态输入是订单号列表输出是物流状态列表处理规则是从物流平台抓取最新一条物流轨迹——这种就适合RPA。什么不适合看这个订单的问题联系一下客户确认下情况这个客户语气不太好注意一下态度这批货有问题手动处理一下——这种带判断、带情绪理解、带主观决策的操作RPA完全做不了至少现阶段做不了。所以想用RPA省人力第一步不是选工具而是把业务流程梳理到每一环节的输入和输出都很明确的程度。这一步梳理不到位RPA项目往往做到一半就发现这里那里都变成异常分支代码量翻倍稳定性反而下去。我在项目里最大的感受就是那个运营助理能从容应对的流程在我眼里全都是如果这样怎么办如果那样怎么办的异常处理人类在异常处理上的灵活性远比我们想象的高。5.2 人机协作才是正解解放的不是岗位是时间项目上线稳定运行了两个月后我们回了趟现场去看了那个运营助理的工作状态想量化一下节省了多少时间。结果挺有意思的她每天省下的3个小时并没有真的空出来——她拿这些时间去处理了一些以前来不及做的客户回访还主动把每周的运营数据周报从前一天下午做改成了每天早晨自动生成。换句话说省下的时间被重新分配到了更值得做的事上而不是她的岗位被取消、人力被裁掉。我跟团队复盘的时候说了一句话RPA项目的验收标准不应该是裁掉了多少人而应该是省下来的时间有没有被用在更重要的事上。如果省下来的时间只是让员工从每天机械地填表变成每天机械地刷手机那这个项目是失败的但如果省下来的时间让他们去做更有判断力、更有创造力的工作那这个项目才是真正产生了价值。5.3 给RPA新手/团队的几点实操建议项目做完我总结了几条比较实在的建议给想上RPA的团队参考从小而确定的场景切入。尽量不要一上来就做一个十几个步骤、横跨多个系统的超级流程。挑一个痛点明显、规则清晰、频率高、涉及系统少的场景先试点比如每天从A系统下载报表处理后上传到B系统。跑通一个建立信任再复制到别的场景。人机分工要提前设计。让RPA做重复度高、出错代价低、规则稳定的部分让人做例外处理、应急响应、经验决策的部分。这个分工边界要写进流程文档不能靠默契。Copilot这类AI工具能用但别神化。它擅长的是把你已经想清楚的需求快速变成代码不是帮你把没想清楚的需求想清楚。需求梳理和时间验证永远是RPA项目里最不可压缩的部分。给AI工具喂好上下文。用Copilot之前先花10分钟把数据样例、字段说明、期望输出写清楚写在注释里让它基于这些信息生成代码比直接甩一句帮我写个函数效果好得多。运维人力要提前估算。RPA不是一次开发永久使用的它需要人维护。建议给每个上线流程至少预留每月半天到一天的运维工时用于处理页面变化、数据格式变更、账号权限调整等问题。5.4 关于急不得这件事的一点个人思考最后聊聊标题里那句替代人力这事真急不得。我们这个项目中间有一段时间老板比较着急想加快节奏想让我把流程里退款订单人工复核这个环节也交给RPA自动处理。我坚持没做原因是退款订单涉及资金一旦判断错误代价不仅是客服被客户投诉还可能影响公司现金流和对账。这种场景的容错率太低现阶段更适合RPA先自动完成90%的排查把剩下10%存疑的订单推给人工复核而不是全自动处理。后来事实证明这个决定是对的。上线两个月RPA自动处理的几万笔订单里有大概几十笔被判为存疑推给人工其中确实有几个人工复核后需要特别处理的特殊情况。如果当初强行全自动这几十笔订单里的任何一笔出了问题就够整个项目被叫停了。我觉得这也是RPA落地最常见的一个误区大家看了厂商的宣传视频觉得机器人什么都能干恨不得把所有流程一口气都自动化。但实际上RPA是一个需要信任积累的工具你只有先跑稳一个小流程让业务方看到它真的不会出乱子才有资格去谈自动化更多环节。别的都是一个道理——急不得。现在这个项目已经稳定跑了小半年每周一到周五自动执行周末休息。运营同事早就适应了每天早上看一眼机器人推送的汇总消息没人觉得这是什么神奇的事。我觉得这才是自动化最好的状态不是某个时刻惊艳所有人而是成为日常里一个安静、可靠的存在。
返回列表