摘要：本文记录用影刀 RPA 6.3 新上线的「AI 流程助手」搭建"金蝶云星空 ERP → 飞书多维表"生产订单同步链路的完整过程。人工工作量：一句中文需求 + 8 个全局变量 + 一次确认；API 文档阅读、代码生成、报错修复、小样验证全部由 AI 完成。全量同步 10655 条订单，约 15 分钟跑通。
一、需求背景：一条我手动搭过的"硬骨头"链路
技术栈与业务背景：
- ERP：金蝶云星空（WebAPI 集成）
- 数据沉淀：飞书多维表格（Bitable）
- 自动化平台：影刀 RPA
需求：定时拉取金蝶PRD_MO（生产订单）列表，写入飞书多维表，按单据编号去重（存在则更新、不存在则新增）。
这条链路我手动搭过，踩过的坑可以先列给大家避雷：
- 金蝶 WebAPI 需要先调
Kingdee.BOS.WebApi.ServicesStub.AuthService.Login.common.kdsvc拿登录态，再调...ExecuteBillQuery,common.kdsvc查询，两步有会话依赖 ExecuteBillQuery的FieldKeys要传金蝶内部字段标识（如FBillNo、FWorkShopId.FName），和界面字段名对不上，要去 BOS 元数据逐个翻- 分页、日期格式清洗、去重逻辑、异常处理都要自己写
手动工期：一天左右。这次的目标是验证：影刀 6.3 的 AI 流程助手能不能把这个工期压到小时级。
二、人工介入第一步：一句中文需求
在影刀编辑器右侧打开 AI 流程助手，需求原文如下（建议直接抄这个结构）：
帮我创建一个流程：调用金蝶云星空 WebAPI 的 ExecuteBillQuery 接口， 查询 PRD_MO 生产订单列表，取字段：单据编号、生产车间、计划开工日期、 数量、单据状态。认证方式用登录接口获取的会话（地址、acctID、用户名、 密码我用变量传入）。查询结果写入飞书多维表， 按单据编号去重，已存在则更新、不存在则新增。 每步加上日志输出，失败时抛出异常并停止。几个要点划重点：
- 技术链路优先于业务描述：先说清"哪个接口、什么认证方式"，业务目标放后面
- 去重规则、日志、失败即停要主动写进需求：AI 默认只给"能跑"的流程，"能上生产"的习惯要你提
- 凭证声明用变量传入：别在需求里明文贴密码
三、AI 的第一反应：反要配置清单（好评设计）
需求发出后，AI 处理了5 分 23 秒——这期间它自己读完了金蝶和飞书两边的 API（我没有提供任何文档），然后停下来，列出了一张配置清单：
1. 8 个全局变量：
| 分组 | 变量 | 用途 |
|---|---|---|
| 金蝶 | K3_BASE_URL | 云星空站点地址（含 /k3cloud） |
| 金蝶 | K3_ACCT_ID | 数据中心（账套）ID |
| 金蝶 | K3_USERNAME/K3_PASSWORD | API 登录凭证（用户/密码） |
| 飞书 | FS_APP_ID/FS_APP_SECRET | 自建应用凭证（换取 tenant_access_token） |
| 飞书 | FS_APP_TOKEN | 多维表 app_token（URL 中 /base/ 后那串） |
| 飞书 | FS_TABLE_ID | 数据表 table_id（URL 中 table= 参数） |
2.field_config字段映射表：AI 已经预填了金蝶字段标识 ↔ 飞书列名的对应关系，人工只做两件事——填变量值、检查映射确认。
这里值得夸一下影刀的产品设计：凭证全部走全局变量，AI 主动拒绝把密钥写死在代码里。这个安全习惯比很多手写的流程都规范。
四、生成产物：一份真实可运行的代码流程
选"代码"格式生成（官方文档说明：复杂任务代码流程生成效果更稳定）。核心结构：
# 金蝶侧K3_FORMID="PRD_MO"K3_LOGIN_PATH="/Kingdee.BOS.WebApi.ServicesStub.AuthService.Login.common.kdsvc"K3_QUERY_PATH="/Kingdee.BOS.WebApi.ServicesStub.DynamicFormService.ExecuteBillQuery.common.kdsvc"K3_FETCH_BATCH_SIZE=500# 飞书侧FS_TOKEN_PATH="/auth/v3/tenant_access_token/internal"FS_BATCH_CREATE_PATH="/bitable/v1/apps/{app_token}/tables/{table_id}/records/batch_create"FS_BATCH_UPDATE_PATH="/bitable/v1/apps/{app_token}/tables/{table_id}/records/batch_update"FS_PAGE_SIZE=500链路：金蝶登录 → 分页查询（每批 500 条）→ 日期多格式清洗 → 飞书 token 获取 → 按单据编号查存量 → batch_update / batch_create 分流写入 → 全程日志。
两个接口路径细节它都写对了，包括飞书 batch 接口的 URL 模板和金蝶 WebAPI 的完整服务路径——这是全文我认为最能体现"AI 自己读文档"的实证。
五、踩坑实录：报了两个错，AI 自己修完了
5.1 报错一：金蝶登录返回非 JSON
[金蝶测试] 返回非 JSON，状态码 200，正常皮 200 号: response_error发生时排... RuntimeError: 返回非 JSON，状态码 200状态码 200 但响应不是 JSON——典型的登录态/端点问题。
5.2 报错二：缺少必填参数
RuntimeError: [参数校验] 缺少必填参数: k3_base_url第一轮调试时全局变量还未加载完整，代码校验逻辑直接拦截报错。
5.3 AI 的自愈过程（本文核心）
AI 流程助手的思考过程面板里，它自己列了排查路径：
- 检查全局变量是否真正加载（
are globals actually loaded） - 定位报错点 → 修改代码模块
- 构造小样验证参数：先只取 3 条真实数据试跑，确认真实写入飞书成功
- 通过后再放开全量
整个过程人工零介入。这个"小样验证 → 放量"的决策，是标准的工程化试错思路，AI 自己做出来了。
六、最终成绩：10655 条，15 分钟
[金蝶] 查询 10655 条，分页 22 批 [飞书] 新增 10652 条（batch 500/次） [飞书] 更新 3 条 执行结束从需求发出到全量落表，约 15 分钟。人工操作：一句话、填 8 个变量、回复一次"已配置"。
七、总结：手动搭建 vs AI 流程助手的分工变化
| 环节 | 手动搭建 | 影刀 AI 流程助手 |
|---|---|---|
| 读两套 API 文档 | 人工翻文档 | AI 自动读取 |
| 字段映射 | 翻 BOS 元数据对字段 | AI 预填，人工核对 |
| 请求/清洗/去重/日志 | 逐个指令拼装 | 直接生成代码流程 |
| 报错排查 | 翻论坛、逐行 debug | AI 自定位、自修复 |
| 小样验证 | 靠自觉 | AI 主动执行 |
| 人工工作量 | 一天 | 一句话 + 8 个变量 + 确认 |
三条可复用的经验：
- 需求里写明工程约束（去重规则、日志、异常即停），把"能上生产"的标准前置
- 复杂任务用代码格式生成，稳定性优于指令格式；简单流程用指令格式更好改
- 凭证走全局变量/凭据管理，永远不要明文硬编码
以前接需求要先掂量工期，现在：把两套系统的地址和账号填上，剩下的，让 AI 自己去读文档。
环境说明：影刀 RPA 6.3「AI 流程助手」（代码流程格式），金蝶云星空 WebAPI，飞书开放平台 Bitable API。
#影刀AWARDS##影刀RPA##金蝶云星空##AI自动化##RPA开发#
