外部 workflow 迁移指南
从 n8n 和其他外部流程迁入 Raydo 时，如何导入、复核、绑定、试跑和切换。
功能状态：预览
这页重点覆盖外部 workflow 迁入 Raydo 的当前可用路径，尤其是 n8n JSON 导入。导入入口和复核流程已经存在，但兼容范围、节点映射和 Hub 供给仍会继续演进。
这页是给准备“把别处已经在跑的流程迁进 Raydo”的人看的。
不是给第一次学 workflow 的人。
如果你现在面对的是这些问题，这页会最有用：
- 我已经有一条 n8n workflow，怎么迁进来
- 导入后哪些节点能跑，哪些只是保留说明
- 连接、审批、交付、目录、浏览器动作要怎么重新接
- 什么时候可以从旧流程正式切到 Raydo
先记住迁移的总原则
迁移的是工作方法，不是盲信原样执行。
外部 workflow 导入到 Raydo 后，更像是经历一次“结构翻译 + 风险复核 + 环境重绑定”。
所以你不应该期待：
- 导入后所有节点 1:1 完整照搬
- 外部连接自动安全匹配
- 自定义代码直接放行
- 外部提交目标自动变成可生产运行
你应该期待的是：
- 先看懂这条流程想做什么
- 再判断哪些部分可执行
- 再把本地环境、连接和审批边界重新接好
- 最后在测试目标上试跑，再切生产
当前最值得优先用的迁移入口
如果你是从外部自动化系统迁入，当前最值得优先使用的是：
- n8n JSON 导入
在当前产品设计里，n8n JSON 已经是重点入口之一。
如果你迁的是其他来源，建议先按“同样需要结构复核、精确绑定、测试切换”的思路理解，不要假设兼容语义一定和 n8n 完全一样。
迁移前先准备什么
正式导入前，先把下面这些东西准备好：
- 一份可导出的源流程文件
- 这条流程的真实输入样例
- 这条流程的真实输出样例
- 用到的外部连接清单
- 高风险动作清单，比如发消息、提工单、提交表单、写数据库
- 旧流程里所有自定义代码或脚本节点清单
- 一套测试目标，而不是生产目标
如果你连“这条流程最终给谁交付什么”都说不清，先别迁。
先把输入、输出和成功标准说清楚，再迁，速度会更快。
最稳的迁移路径
Raydo 里更适合的迁移方式，不是“导入后马上点运行”，而是下面这五步：
按 Raydo 的 5 个步骤来迁
1. 导入文件
这一层只回答一个问题：
文件能不能被读进来。
对 n8n 来说，导入阶段通常会接受：
- 文件上传
- 文件选择
- 粘贴 JSON
这时别急着看节点细节，先确认：
- 文件确实是当前在用的版本
- 不是半年前的旧导出
- 没有手改坏 JSON 结构
2. 理解 workflow
这一层最重要。
你要确认的不是“节点名字对不对”，而是：
- 流程目的对不对
- 触发方式对不对
- 输入对不对
- 主干阶段顺序对不对
- 输出对不对
更实用的检查方式是：
把它讲成人话。
比如：
“收到一份选题，抓资料，整理摘要，等人 review，再发到测试频道。”
如果你讲不顺，说明你还没真的确认迁移语义。
3. 检查准备度
这里是迁移里最容易被跳过，也最容易出事故的一步。
你通常会在这一步遇到几类节点状态：
| 导入后的状态感受 | 更适合怎么理解 |
|---|---|
| 已识别 | 这类节点已经能被 Raydo 理解成对应能力 |
| 已转换 | 语义被翻译成 Raydo 内部更合适的结构 |
| 需要复核 | 结构保留了，但不能不看就直接信 |
| 暂不支持 / inert | 先保留说明，不作为可运行主干的一部分 |
这一步里，尤其要盯四类风险：
- 自定义代码
- 外部连接
- 浏览器或桌面动作
- 最终交付动作
4. 绑定连接
这一步不要偷懒。
外部 workflow 的连接迁入后，不应该靠“品牌一样差不多就是它”来猜。
更稳的做法是逐项核对：
- 这个连接实例是不是目标环境该用的
- 这个资源目标是不是测试资源
- 这个 grant / 权限是不是当前项目该拥有的
- 这个 workflow 节点是不是该绑定到这个连接
一句话：
导入后的连接，要重新认领，不要默认继承信任。
5. 保存并试跑
这一步建议永远先跑测试目标。
尤其是下面这些动作，第一轮不要直连生产：
- 发 Slack / Discord / 邮件
- 浏览器提交
- 上传附件
- 写共享目录
- 调用会改外部状态的 API
更稳的第一轮试跑方式：
- 把收件对象换成测试对象
- 把目录换成测试目录
- 把审批先保留
- 把真实提交停在 review 前
- 先验证 proof、receipt、artifact、run dossier
导入后，节点最可能发生的 6 种变化
1. 直接识别成 Raydo 能力节点
这是最省心的情况。
你主要要检查输入输出字段有没有接对。
2. 被转换成更适合 Raydo 的数据节点
有些外部数据处理节点导入后，会更接近 Raydo 的 Data transform。
这时别只看“看起来能跑”，要复核：
- 处理方法
- 输入来源
- 输出名
- 下游引用
3. 被标成 imported data operation，需要复核
这是典型的“结构带过来了，但生产前必须再看一眼”。
你至少要核对：
- 是不是同一个转换意图
- 有没有丢掉关键过滤条件
- 输出字段是不是还符合下游预期
4. 自定义代码被阻断
这类是迁移里最常见的误判来源。
如果旧流程里有 code 节点、自定义脚本、函数节点，不要默认它会直接跑。
当前边界更接近：
- 这类步骤会被当成受控代码
- 没有完成受控 runner 审查、沙箱策略和资源限制前，会保持阻断
- 原始源码、参数或连接器 payload 不应该被直接带进可运行 metadata
如果那段代码本质上只是做：
- filter
- map
- dedupe
- split
- CSV / JSONL 解析
通常更值得改写成 Data transform，而不是保留自定义代码。
5. 某些 imported 逻辑会变成 review-only
你可能会看到“review-only”或类似只做审查说明的节点。
它的意思通常不是“系统坏了”，而是：
这段逻辑当前先被保留下来供人审阅，不进入默认可执行主干。
6. 暂不支持的逻辑会保留成 inert step
有些外部节点即使被展示出来，也可能只是 inert，也就是保留说明、不直接可运行。
这反而是好事。
因为比起假装能跑，明确告诉你“这一步先别信”，更安全。
n8n 迁移时最该优先查什么
如果你从 n8n 迁进来，我最建议第一轮就看这 8 项：
- Trigger 有没有被理解对
- 输入字段是不是和旧流程同一层含义
- HTTP / App 节点对应的连接要不要重绑
- code 节点是不是被阻断或建议改写
- 数据变换节点是不是被降成 Data transform
- 浏览器提交或上传动作前有没有审批
- 最终 delivery 是不是还指向测试目录 / 测试目标
- 旧流程里依赖的环境变量、路径、文件是否仍然存在
迁移时最容易漏掉的 5 类东西
| 容易漏掉什么 | 为什么危险 |
|---|---|
| 旧流程里的真实 URL | 一试跑就可能打到生产 |
| 旧流程里的自定义代码 | 看起来像小改，实际最容易变成受控阻断 |
| 旧流程里的路径和目录 | 别人的本地路径对你根本不存在 |
| 旧流程里的权限和连接 | 同品牌不等于同实例，更不等于同 grant |
| 旧流程里的“人工默认知道” | 以前靠人脑补的步骤，迁移后最容易丢 |
什么时候可以正式切换
别因为“已经导入成功”就切。
更稳的切换标准是：
- 至少用真实测试样例跑通过一轮
- 高风险动作前的审批已经恢复
- 主要输入字段已经稳定
- 关键输出和旧流程结果能对得上
- 连接、目录、收件目标都已经从测试值切到正式值
- 团队里至少还有一个人能看懂这条迁移后的流程
推荐的切换方式，不要一刀切
更推荐：
阶段 1：并行观察
旧流程继续跑，Raydo 用同样输入在测试目标跑。
比对：
- 输出质量
- 丢字段情况
- 批准点位置
- 交付目录
- 执行证据
阶段 2：低风险生产试跑
先挑低风险、低频次、可回滚的任务，切到 Raydo。
阶段 3：正式接管
等结果稳定后，再停旧流程。
这个顺序不酷，但真能少踩坑。
迁移后的首轮排错顺序
如果导入后跑不起来，建议按这个顺序查：
如果你已经确定问题集中在运行失败、审批停住、外部目标没响应，也建议继续看：
迁移完成后，最值得立刻做的两件事
第一，把这条稳定后的流程整理成团队能看懂的 starter 或 WorkPack。
第二，把测试输入模板和切换注意事项一起写进去。
不然三周后连你自己都要重新猜一遍。