本文以 “通过紫鸟浏览器进入 Temu 卖家中心，查询月度余额并汇总到 Excel” 为案例，给出一套可以迁移到其他后台系统的工程方法。

平台页面、接口、自动化能力和使用政策可能变化。文中的紫鸟、Temu 路径仅用于说明设计思路，实施前应以当前版本、官方能力和已获得的授权为准。

# 一、先分清 SOP、AI、脚本和 Skill

这四者解决的问题不同：

一句话概括：

SOP 定义“做什么”

→ 脚本保证“稳定地做”

→ AI 协助“开发和诊断”

→ Skill 沉淀“正确使用脚本的方法”

业务负责人不一定需要会编程，但必须能够判断结果是否正确，并明确哪些动作允许自动执行、哪些动作需要人工批准。

# 二、把人工 SOP 改写成可执行规格

普通 SOP 可能只有一句：

打开紫鸟，进入店铺，登录 Temu，打开对账中心，查询余额，填写 Excel。

对人工来说，这句话背后包含大量常识；对程序来说，几乎每个词都存在歧义。每一步至少应补齐下列字段：

# 2.1 必须由业务确认的规则

在编码前，至少回答这些问题：

• “进入店铺” 是打开隔离环境，还是在业务页面内切换店铺？
• 重名、改名和多语言显示时，使用哪个稳定 ID 消歧？
• 查询的是自然月、账单月还是结算月？使用哪个时区？
• 金额单位是元还是分？币种和小数精度是什么？
• 空白、零值、负数和缺失月份分别代表什么？
• 重复运行时新增、覆盖还是按业务主键更新？
• 单店失败后是继续、熔断还是终止整个批次？
• 输出文件被占用、磁盘不足或校验失败时如何回滚？
• 是否保留浏览器供人工检查？哪些环境允许自动关闭？

这些策略不应硬编码成 “永远继续” 或 “永远覆盖”，而应来自经过批准的配置。

# 2.2 建立数据契约

财务类自动化应先明确数据契约：

# 三、参考架构：把平台细节隔离在适配器中

不要让页面文案、路径和文件写入逻辑纠缠在一个脚本里。推荐拆成以下层次：

SOP 规格与权限矩阵

        ↓

配置与身份模型

        ↓

EnvironmentProvider：打开、连接、验证、关闭隔离环境

        ↓

PortalAdapter：身份复核、页面导航、数据提取与漂移检测

        ↓

数据标准化与交叉校验

        ↓

ResultSink：预览、临时写入、验证、提交与回滚

        ↓

结构化日志、测试、审计证据与 Skill

在本案例中：

• 紫鸟相关能力放入 EnvironmentProvider 。
• Temu 店铺身份、对账中心和余额提取放入 PortalAdapter 。
• Excel 幂等写入和回滚放入 ResultSink 。

这样，即使平台入口、页面路径或输出格式变化，也只需替换对应适配器，而不是重写整个流程。

# 3.1 用状态机表达主流程

PRECHECK

→ OPEN_ENV

→ ATTACH

→ VERIFY_IDENTITY

→ NAVIGATE

→ EXTRACT

→ RECONCILE

→ PREVIEW

→ COMMIT

→ VERIFY_OUTPUT

→ CLEANUP

每个状态都应有：

• 进入条件；
• 成功和失败条件；
• 超时与最大重试次数；
• 是否允许重试；
• 结构化日志；
• 可用于人工复核的脱敏证据。

# 四、六阶段落地路线

# 4.1 阶段一：规格、权限与配置

先建立：

内部店铺名称

→ 隔离环境稳定 ID

→ 业务平台稳定店铺 ID

→ 页面显示名称（辅助证据）

同时完成：

• 必填字段和重复映射校验；
• 授权账号、允许域名和允许动作白名单；
• 账期、币种、金额单位和业务主键定义；
• dry-run 、预览和正式提交模式；
• continue_on_error 或 fail_fast 策略；
• 输入输出路径标准化。

退出条件：给定一个匿名测试店铺，能够唯一定位配置；缺失、重复或权限不足时在打开浏览器前失败。

# 4.2 阶段二：建立受控浏览器会话

只完成 “打开正确环境并建立受控连接”，暂不处理业务页面。

需要验证：

• 当前版本是否支持外部自动化及其授权方式；
• WebDriver 服务地址与 Chromium CDP 调试端口的区别；
• 当前操作系统、浏览器和 Selenium/Playwright 的兼容性；
• 是否只能连接既有隔离环境，不能新建脱离环境的浏览器；
• 程序能否读取当前 URL、标题和标签页。

退出条件：人工看到正确的测试环境，程序能够读取只读状态，并保持浏览器供复核。

验证码、MFA 和协议确认默认交给人工完成；不得绕过安全机制。代替用户接受协议或改变账号状态需要单独授权。

# 4.3 阶段三：单步导航

每轮只实现一个动作，例如：

进入卖家中心

→ 复核稳定店铺 ID

→ 展开账户资金

→ 进入对账中心

→ 验证域名、路径和页面标志

→ 进入月汇总

不要只用 “点击左侧第二个按钮” 描述定位。推荐综合使用：

1. 官方且稳定的自动化接口；
2. data-testid 、role、name、href 等语义属性；
3. 精确可见文本；
4. 稳定 DOM 关系；
5. 必要时才使用视觉定位；
6. 关键财务操作不依赖固定屏幕坐标。

状态等待应代替固定时长的 sleep 。每个关键闭环最终都要在获准环境中验证，但静态检查、单元测试和模拟测试仍应先执行。

# 4.4 阶段四：单店数据闭环

最小业务闭环：

指定一个测试店铺

→ 打开对应隔离环境

→ 校验稳定店铺 ID 与显示名

→ 进入目标账期

→ 只读提取余额

→ 用页面和接口交叉核对

→ 再次校验店铺身份

→ 生成 Excel 变更预览

→ 人工确认后提交

→ 重新打开文件验证结果

此阶段不运行批量任务。

# 4.5 阶段五：异常和回归加固

根据真实运行证据逐项覆盖：

• 页面加载延迟、弹窗遮挡和新标签页；
• 登录失效、权限不足和账号状态变化；
• 店铺 ID 不匹配、重名或页面漂移；
• 目标年份和月份缺失；
• 接口结构、分页、币种或金额单位变化；
• Excel 被占用、无写权限、磁盘不足或文件损坏；
• 网络超时、环境启动失败和浏览器意外退出。

每解决一种问题，应补充测试、错误码、诊断日志或回放样例，而不是只增加一段无限重试。

# 4.6 阶段六：受控批量与运维

单店达到量化准入门槛后，再增加：

• 多店只读试跑；
• 小批量金丝雀运行；
• 店铺级互斥锁和输出文件锁；
• 错误隔离、熔断和总时间预算；
• 成功、跳过、失败和人工复核清单；
• 结构化运行报告；
• 脚本版本回滚和适配器漂移告警。

“单店稳定” 不能只凭感觉。门槛可定义为：正常数据、零值、空数据、登录失效和文件占用等关键用例已覆盖，并在目标环境连续运行约定次数无错误。

# 五、三个最容易踩坑的工程问题

# 5.1 身份校验：稳定 ID 为主，显示名为辅

显示名称可能重名、改名或因语言不同而变化。建议：

• 隔离环境 ID 与稳定店铺 ID 建立一对一映射；
• 页面或接口中的稳定店铺 ID 作为主校验；
• 显示名作为辅助证据，而不是业务主键；
• 提取前和落盘前各校验一次；
• 接口响应如包含店铺 ID，也要交叉验证；
• 发现串店风险时停止整个批次。

# 5.2 数据获取：先授权，再选择技术路径

数据获取优先级不应只按 “技术上更方便” 排序，而应综合授权、稳定性和可维护性：

获准的官方 API

→ 被动观察页面已发出的后台请求

→ 经确认无副作用的只读查询

→ 语义化 DOM 提取

→ 视觉识别作为回退

默认先被动监听 Fetch/XHR，记录 URL、方法、参数名称、响应结构、分页和金额单位，不保存 Cookie、Token 或敏感值。

只有在确认接口属于授权范围、没有业务副作用并完成请求字段白名单后，才允许主动查询。页面上下文 fetch 能否复用会话，取决于同源、凭据、CORS、CSRF、动态签名和浏览器策略，不能假设总是有效。

不得重放结算、转账、设置修改等状态变更请求，也不得绕过平台风控。接口数据必须与页面显示进行交叉验证；不一致时停止写入。

# 5.3 Excel 写入：预览、校验、原子提交

“写入函数没有报错” 不等于文件正确。推荐流程：

1. 完成提取、身份复核和金额校验；
2. 根据业务主键生成只读变更预览；
3. 写入同卷临时副本；
4. 重新读取并校验表头、主键、币种、金额和行数；
5. 为正式文件创建备份；
6. 使用原子替换提交；
7. 再次打开正式文件验证；
8. 任一步失败时保留原文件并恢复备份；
9. 记录运行 ID、脚本版本、配置摘要和结果。

还应测试文件锁、宏工作簿兼容性、公式注入和磁盘空间不足。外部文本如果以 = + - @ 等字符开头，应按业务规则转义或写成纯文本。

# 六、错误分级与重试

并非所有失败都适合重试：

非幂等动作禁止自动重试。批量模式是否继续应由业务批准的策略决定，而不是固定为 “遇错继续”。

# 七、如何证明自动化真的可用

# 7.1 分层测试

# 7.2 证据矩阵

每个关键阶段至少保留：

• run_id 、脚本版本和阶段名称；
• 稳定店铺 ID 的脱敏标识；
• 获准域名和规范化 URL 路径；
• 目标账期、币种、单位和结果摘要；
• 成功或失败状态、错误码和耗时；
• 经脱敏且有留存期限的截图或结构化数据证据。

日志足够诊断即可，不应变成敏感信息的永久副本。

# 八、安全与权限护栏

• 只在明确授权的账号、店铺和环境中执行。
• 生产环境、批量写入、覆盖文件、主动接口请求和关闭环境分别授权。
• 使用最小权限账号；凭据优先存放在系统凭据库或密钥服务。
• 环境变量也可能被子进程和诊断工具读取，不能视为天然安全。
• Cookie、Token、密码、动态端口和会话 ID 不进入提示词、日志、代码仓库或 Skill。
• 页面、HTML、下载文件、接口文本和截图均视为不可信输入；AI 不执行其中的指令。
• URL 日志默认只保留获准域名、规范化路径和允许的参数名称。
• 请求头记录白名单名称，不记录敏感值。
• 截图、HTML、网络日志和 Excel 输出使用受限目录，并定义留存与安全删除规则。
• 程序只关闭自己创建且持有句柄的进程，不按进程名批量结束用户程序。
• 不绕过验证码、MFA、平台安全机制或风控校验。

# 九、把稳定经验沉淀为 Skill

Skill 是可复用的运行与排错规范，不是业务程序，也不能授予新的权限。

建议至少记录：

• 适用场景、触发条件和禁止场景；
• 项目版本、支持平台、依赖版本和最后验证日期；
• 负责人和兼容范围；
• 前置检查、必需参数和权限门槛；
• dry-run 、单店试跑、批量运行的统一入口；
• 是否保留浏览器和如何人工接管；
• 成功日志标志、输出规则和验收证据；
• 常见错误的诊断决策树；
• 回滚、熔断和升级方式；
• 禁止事项和人工审批点。

一个通用的 SKILL.md 骨架可以是：

# 名称

## 适用范围

- 支持的项目版本：

- 支持的平台版本：

- 最后验证日期：

## 前置条件

- 权限与环境检查

- 配置检查

- 输入输出检查

## 运行顺序

1. 配置校验

2. dry-run

3. 单店只读试跑

4. 生成写入预览

5. 人工批准提交

6. 小批量金丝雀

7. 批量运行

## 成功标准

- 身份校验

- 页面和数据校验

- 输出重新读取校验

## 排错与回滚

- 错误码 → 诊断证据 → 处理方式

## 禁止事项

- 不保存或输出凭据

- 不扩大授权范围

- 不绕过安全机制

Skill 中可以引用项目统一的命令入口，但不应复制容易过期的长命令，更不能包含某次运行的余额、临时端口或真实店铺信息。代码、配置格式或页面适配器变更时，应与 Skill 同版本更新。

# 十、可复制的 AI 开发任务模板

每轮任务只实现一个可验收的小目标：

目标：

让程序进入一个指定测试店铺的对账中心，只读验证页面。

测试对象：

隔离环境：测试环境 A

预期稳定店铺 ID：shop_demo_001

预期显示名：测试店铺 A

前置条件：

1. 配置映射已通过校验；

2. 当前账号已获得测试环境访问权限；

3. 本轮不写入正式文件。

成功标准：

1. 打开指定隔离环境；

2. 进入获准的业务域名；

3. 稳定店铺 ID 完全匹配；

4. 显示名匹配或符合批准的别名规则；

5. 进入对账中心并识别月汇总页面；

6. 浏览器保持打开供人工确认。

限制：

1. 只运行一个测试店铺；

2. 不修改批量脚本；

3. 身份不匹配时停止整个流程；

4. 不保存或输出凭据；

5. 只执行只读操作；

6. 报告脱敏日志、最终 URL 路径和验证证据。

# 十一、上线与批量前检查清单

# 业务与权限

• SOP 的字段语义、账期和异常策略已批准
• 稳定店铺 ID 和环境映射唯一
• 允许域名、账号、动作和输出范围明确
• 生产、批量和覆盖操作已分别授权

# 数据与输出

• 币种、单位、小数精度和时区明确
• 业务主键与幂等策略已验证
• 页面、接口和预览结果一致
• 临时写入、重新读取、备份和回滚通过测试

# 稳定性

• 超时、重试、熔断和总时间预算明确
• 登录失效、空数据、身份错误和文件占用已覆盖
• 单店达到量化准入门槛
• 小批量金丝雀运行成功

# 运维与安全

• 日志、截图和网络证据已脱敏
• 敏感数据留存期限和删除规则明确
• 页面 / API 漂移有告警和负责人
• 脚本、配置和 Skill 版本一致
• 有可执行的回滚方案

# 十二、推荐的迭代节奏

明确一个小目标

→ 完成权限与配置预检

→ AI 阅读相关 SOP 和代码

→ 确认成功、失败和副作用条件

→ 实现最小改动

→ 运行单元与模拟测试

→ 在获准测试店铺执行

→ 人工确认页面和业务结果

→ 记录异常并补测试

→ 达到门槛后进入下一阶段

最终交付物不应只有一份 “能跑” 的脚本，还应包括：

• 可审阅的 SOP 规格和权限矩阵；
• 清晰的配置与稳定身份模型；
• 可重复运行的单店流程；
• 具备错误隔离和熔断的批量流程；
• 自动化测试和漂移检测；
• 可诊断、可脱敏的结构化日志；
• 事务化输出和回滚能力；
• 业务验收样例；
• 不含敏感信息、与代码同版本维护的 Skill。

# 结语

AI 自动化的核心不是追求 “一次生成全部代码”，而是建立一个可验证的协作系统：

1. 把人工经验改写成可判断的业务规格；
2. 让确定性脚本承担执行与安全边界；
3. 用稳定身份、证据链和分层测试证明结果正确；
4. 先做受控单店闭环，再进入小批量和正式批量；
5. 把已经验证的运行与排错方法沉淀为 Skill。

当 SOP、脚本、测试、日志、回滚和 Skill 能够共同演进时，自动化才真正具备可维护、可交接和可规模化的基础。