RPA 差评监控与飞书连接器自动化：
不怕 API 断供，只怕没有备用方案

1. 项目背景：API 停服，业务不能停

跨境电商的差评监控是一件"刚需中的刚需"——一条差评如果在 24 小时内没有被回复处理，不仅会影响 listing 评分，更可能触发亚马逊的负面反馈机制，直接导致产品权重下滑。因此，差评监控任何一刻的中断，都是在直接损失真金白银。

公司使用积加 ERP 管理差评数据。最初通过积加官方 API 接口每天定时拉取差评列表，然后清洗、去重、翻译、推送飞书卡片给客服团队。这套架构稳定运行了数月。然后，积加 API 突然停服了——没有提前通知，没有任何替代方案的说明。

对于大多数运营团队来说，这意味着：要么等官方修复（天知道要等多久），要么手动每天登录 ERP 截图核对。但全栈工程师的日常工作教会我一个原则：永远不要把自己的核心业务流程建立在你无法控制的 API 之上。

2. 方案一：积加 ERP 差评 RPA 监控（jijia_review_skills.py）

核心思路很简单：只替换数据获取层，上面所有的业务逻辑——去重、翻译、推送、飞书卡片渲染——全部不动。

2.1 RPA 抓取流程

使用 Playwright 替代积加 API：

• 无头浏览器启动： 运行在服务器上的 headless Chromium 实例，通过 Playwright 启动并控制。
• 凭证注入： 使用预先存储的积加 ERP 登录 Cookie（定期刷新），跳转到差评管理页面。
• DOM 解析： 在页面完全渲染后，抓取差评列表中的关键字段——订单号、评分、评论内容、评论时间、ASIN。
• 结构化输出： 将抓取到的数据清洗为标准 JSON，输出格式与原来 API 接口的返回值结构完全一致。

2.2 上层逻辑零修改

这是最核心的设计原则。原来的处理流程是：

API 接口 → 数据清洗 → 翻译 → 去重 → 飞书卡片推送

切换到 RPA 后：

Playwright 抓取 → 数据清洗 → 翻译 → 去重 → 飞书卡片推送

从第二个步骤开始，代码一行都没改。数据清洗函数接收的输入格式完全相同——都是 [{order_id, rating, content, asin, time}, ...] 的结构化数组。飞书卡片推送模块甚至根本不知道数据是从 API 抓来的还是从 RPA 抓来的。

图：RPA 抓取差评数据后自动推送飞书卡片，客服直接回复处理

3. 方案二：飞书多维表连接器 RPA 自动化（update_sales_analysis.py）

在同一个项目中，还遇到了另一个"API 不给力"的经典场景。

飞书多维表的连接器功能允许用户配置定期数据同步（比如每天从 MySQL 拉取销售数据到多维表）。但飞书官方没有开放连接器的 API——你要修改连接器的数据源日期或查询参数，只能手动登录飞书 Web 界面去点。

业务需要每周更新销售分析数据源的查询日期范围。手动操作只需要 2 分钟，但如果 15 张多维表都要手动更新，每周就是 30 分钟纯机械劳动，而且极容易忘。

3.1 Playwright 操作 Web 界面改日期

解决方案同样是用 Playwright：

• 登录飞书 Web 版： 使用预先配置的 Cookies 或用户名密码登录飞书管理后台。
• 导航到连接器配置页： 根据多维表 ID 自动跳转到对应的连接器配置页面。
• 自动填入新日期： 脚本解析页面上的日期选择器 DOM 元素，自动填入新的开始日期和结束日期。
• 保存并验证： 点击保存按钮后，检查页面是否有保存成功的提示元素，确保配置生效。

3.2 复用架构

这个脚本和差评监控脚本共享了相同的底层架构——Playwright 浏览器上下文管理 + 凭证自动刷新 + 超时重试 + 日志记录。实际上，它们在代码层面共享了同一个 browser_manager.py 基础模块，只是 page 导航和 DOM 操作不同。

4. 工程实现的技术细节

这套 RPA 方案在工程上有几个值得关注的设计点：

• 数据获取层与业务逻辑的彻底解耦： 两个脚本都严格遵循"抓取 → 结构化 → 推送"三段式解耦。数据抓取函数返回统一的 JSON 格式，业务逻辑函数不关心数据来源。这意味着未来积加 ERP 如果重新开放 API，只需写一个新的 jijia_api_fetcher.py 替代 jijia_rpa_fetcher.py，其余代码一行不改即可切回去。
• 共享浏览器上下文管理： Playwright 的浏览器实例是昂贵的资源。基础模块 browser_manager.py 统一管理浏览器启动、页面创建、Cookie 注入和进程清理。当一个脚本运行完毕，浏览器实例不会立刻销毁，而是在 60 秒内保持闲置复用状态，减少了频繁启动浏览器的开销。
• Cookie 刷新兜底： 积加 ERP 和飞书的登录凭证都有有效期。如果 RPA 运行时发现 Cookie 已过期（通过请求响应状态码判断），脚本会自动跳转登录页，重新填写账号密码并保存新 Cookie，保证下次运行仍然有效。
• 稳定的 CSS Selector 选择： Web 界面最容易出问题的就是 DOM 结构变更。脚本优先使用 data-testid 或 data-row-id 等稳定属性定位元素，只有在没有稳定属性时才使用 xpath 路径，并在代码中刻意注释了每个 CSS Selector 的用途和预期 DOM 结构，方便后续维护调整。

5. 一个更大的启示

这两个项目单独看都很"小"——一个是替换掉一个失败 API 的抓取层，一个是自动化一个本来只需要 2 分钟的 Web 操作。但它们的共同价值在于展示了面对外部依赖失效时的工程应变能力。

在跨境电商这个领域，第三方平台 API 停服、接口版本变更、数据格式调整几乎是常态。如果业务流程的每个环节都深度绑定在一个不可控的 API 之上，那这个业务流程本身就是脆弱的。RPA 不是一个"最后的备选方案"，而应该是一个随时可以激活的 B 方案——它的存在不是为了替代 API，而是为了让你在面对外部依赖崩塌时，核心业务仍然可以正常运行。

6. 数字化转型背书