影刀RPA 团队协作开发：多人维护同一个流程的最佳实践

影刀RPA 团队协作开发：多人维护同一个流程的最佳实践

作者：林焱

什么情况用

一个人写RPA流程，想怎么来就怎么来。但当你开始带人，或者公司有多个RPA开发者时，问题就来了：

• 张三改了流程的一部分，李四不知道，结果李四的改动和张三冲突
• 流程跑着跑着突然行为变了，排查半天发现是被人手动改了一个变量
• 一个复杂的流程有50个节点，没人敢改——怕改了一个地方其他地方炸了

这些问题和软件开发遇到的问题一模一样。解决方案也一样：版本控制、代码规范、分工协作。

核心场景：2人以上共同开发和维护RPA流程。

怎么做

第一步：版本控制——用Git管理影刀流程

影刀的流程文件本质上是JSON格式，完全可以用Git管理。

流程目录结构： D:/RPA_Projects/ ├── 订单同步流程/ │ ├── 订单同步.flow ← 影刀导出文件 │ ├── config.json ← 配置文件（变量、环境） │ ├── test_data/ ← 测试数据 │ ├── docs/ ← 文档 │ └── README.md ← 流程说明、变更记录 ├── 报表生成流程/ │ └── ... └── shared/ ← 共享模块 ├── common_utils.py ← 通用Python函数 └── credential_manager.py

.gitignore模板：

# 敏感信息 credentials.enc *.key config_local.json *.pem # 临时文件 *.tmp checkpoints/ *.pyc __pycache__/ # 运行日志 *.log audit_log.db # 测试输出 test_output/

变更记录规范：

# 变更记录 ## v2.1.3 - 2024-06-26 - 修改人：林焱 - 修改原因：新增「自动跳过已处理订单」逻辑 - 修改节点：节点12（Python处理）、节点15（条件分支） - 测试情况：用100条测试数据跑完，99条正确处理，1条因数据格式异常跳过（符合预期） - 回滚方案：切回v2.1.2分支即可

第二步：流程模块化——拆分可复用的子流程

一个大流程不要写成一个大文件，拆成若干子流程。

# 主流程只负责编排# main_flow.py —— 在影刀的Python节点中调用子流程defmain():"""主流程——每天运行业务流程"""logger=AuditLogger()run_id=logger.start_run("每日业务处理")try:# 步骤1：数据采集data=sub_collect_data(source="ERP")logger.log_step(run_id,"数据采集",output_data={"rows":len(data)})# 步骤2：数据清洗clean_data=sub_clean_data(data)logger.log_step(run_id,"数据清洗",output_data={"valid_rows":len(clean_data)})# 步骤3：业务处理results=sub_process_orders(clean_data)logger.log_step(run_id,"业务处理",output_data={"processed":len(results)})# 步骤4：推送结果sub_send_report(results)logger.log_step(run_id,"推送结果")logger.end_run(run_id,status="success")exceptExceptionase:logger.end_run(run_id,status="failed",error_message=str(e))send_alert(f"流程异常：{e}")raisedefsub_collect_data(source):"""子模块1：数据采集（可单独测试）"""# 从不同数据源采集数据的逻辑ifsource=="ERP":returnfetch_from_erp()elifsource=="Excel":returnload_from_excel()else:raiseValueError(f"未知数据源：{source}")defsub_clean_data(raw_data):"""子模块2：数据清洗（纯函数，容易测试）"""df=pd.DataFrame(raw_data)df=df.dropna(subset=["订单号"])# 去掉订单号为空的行df["金额"]=pd.to_numeric(df["金额"],errors="coerce")df=df[df["金额"]>0]# 过滤异常金额df=df.drop_duplicates(subset=["订单号"])# 去重returndf.to_dict("records")defsub_process_orders(clean_data):"""子模块3：业务处理"""results=[]fororderinclean_data:# 处理逻辑...results.append(order)returnresultsdefsub_send_report(results):"""子模块4：生成和发送报告"""report=generate_report(results)send_to_wecom(report)

模块化带来的好处：

• 张三可以改「数据清洗」模块，李四同时改「报告生成」模块，互不影响
• 每个模块单独测试，不需要跑整个流程
• 复用在其他流程中（数据清洗模块可以被多个流程引用）

第三步：配置与代码分离

# ❌ 配置和逻辑混在一起defprocess():connect_db(host="192.168.1.100",port=3306,user="admin",password="pass123")send_email(smtp="smtp.qq.com",port=587,user="xxx@qq.com",password="xxx")output_path="D:/Reports/monthly_report.xlsx"# ✅ 配置独立管理# config.json""" { "database": { "host": "192.168.1.100", "port": 3306, "database": "erp_prod" }, "email": { "smtp_server": "smtp.qq.com", "port": 587 }, "output": { "report_dir": "D:/Reports/", "report_prefix": "monthly_report" }, "business": { "min_order_amount": 100, "max_retry_times": 3 } } """importjsondefload_config(env="prod"):"""按环境加载不同配置"""config_file=f"config_{env}.json"withopen(config_file,"r",encoding="utf-8")asf:config=json.load(f)returnconfigdefprocess():config=load_config(env="prod")# 所有参数从config对象读取，不从代码里写死db=config["database"]connect_db(host=db["host"],port=db["port"],database=db["database"])

三套环境配置：

• config_dev.json：开发环境（测试数据库、测试邮箱）
• config_test.json：测试环境（模拟数据）
• config_prod.json：生产环境（真实数据）——这个文件加入.gitignore

第四步：代码审查清单

多人协作时，每次提交前要过审查。审查不追求完美，关注这几点：

□ 是否改了核心逻辑？（如果不熟悉，请原开发者审查） □ 是否有硬编码的凭证？（密码、Token、API Key） □ 是否有可能的无限循环？（while True 有没有退出条件） □ 异常处理是否合理？（try/except 是否正确处理了） □ 日志是否完整？（关键步骤有无记录） □ 是否有破坏性操作？（DELETE、UPDATE 是否安全） □ 变更记录是否更新了？

第五步：建立流程版本策略

分支策略： main ← 生产环境运行的版本（只有经过测试的才合并进来） ↑ develop ← 开发中的版本 ↑ feature/xxx ← 个人开发的特性分支 ↑ hotfix/xxx ← 紧急修复分支 版本命名： v主版本.次版本.修订号 v1.0.0 → 初始版本 v1.1.0 → 新增功能 v1.1.1 → 修复bug v2.0.0 → 大改版（不兼容旧版本）

有什么坑

坑1：影刀流程文件是二进制+JSON混合

影刀的流程导出文件不是纯文本，直接Git diff看不懂改了什么。两个人同时改了同一个流程文件，Git无法自动合并。

解决方法：尽量把复杂逻辑放在Python节点里（纯文本，Git友好），影刀的可视化节点只做简单的编排和判断。流程文件本身锁机制——一个人改了要群里说一声「我在改XX流程」。

坑2：环境和依赖不同导致「我这能跑，你那不行」

开发者A的电脑装了pandas 2.0，开发者B还在用1.5。A写的代码在B的电脑上报错。

解决方法：维护一个requirements.txt，所有人用同一版本。或者用影刀的Python环境管理功能，确保运行环境一致。

坑3：没有文档——只有开发者自己能维护

流程写得再模块化，没有文档，别人接手还是看不懂。

解决方法：每个子流程至少写清楚三行：这个模块做什么、输入是什么、输出是什么。别写长篇大论，没人看。

坑4：测试数据和真实数据混用

开发者用测试数据调好了流程，上线后发现真实数据格式不一样。

解决方法：测试数据集要包含：正常数据、边界数据（空值、极大值）、异常数据（格式错误、乱码）。而且要定期从生产环境采样更新测试数据。

总结：RPA团队协作的本质是把软件开发的最佳实践搬到流程开发中：版本控制（Git）、模块化（子流程）、配置分离（环境变量）、代码审查、文档。初期可能觉得麻烦，但一旦流程超过10个、开发者超过2人，这些规范就是救命稻草。