Cloud Hub、导入导出与分享

这一页最重要的目的只有一个：

帮你把几种很像、但完全不是一回事的动作分开。

很多团队在第一次用 workflow / WorkPack 时，最容易混淆的是：

• 导出草稿
• 导出可复用包
• 导出一次运行证据
• 发布到 Hub
• 节点里的云端交付

如果你先把这几件事分清楚，后面的分享、复用、培训和排错会轻松很多。

先分清 5 个对象

如果你只记一句话：

Hub 解决“从哪里拿模板”，导入导出解决“怎么搬流程”，dossier 解决“这次到底跑了什么”，cloud publish 解决“结果往哪里送”。

Cloud Hub 应该怎么理解

在当前产品结构里，你可能会同时看到 Hub package、publish / release、cloud publish 这几个词。

它们不是一层概念：

• Hub / Cloud Hub 更偏“复用来源”
• publish / release 更偏“当前流程版本是否准备好对外提供”
• cloud publish 更偏“某个交付节点把产物送去云端”

更稳妥的理解方式是：

Cloud Hub 不是你随手把半成品扔上去的地方，而是更接近“别人可以从这里拿一个可复用起点”。

所以在发布到 Hub 之前，至少先确认下面几件事：

• 主干流程已经跑通过
• 输入字段已经基本稳定
• 高风险动作前已经放了审批或人工收口
• 输出结果清楚，别人知道最终会拿到什么
• 连接器、模型、浏览器或外部依赖没有写死成你个人环境

什么时候适合发到 Cloud Hub

比较适合发到 Hub 的，通常是这几类：

• 团队反复会用到的 starter
• onboarding 或销售 demo 需要稳定复现的流程
• 某类工作已经有比较清楚的输入、输出和 review 边界
• 你希望别人从模板起步，而不是从空白画布重搭

不适合现在就发到 Hub 的，通常是：

• 还在频繁改结构的试验流程
• 依赖你个人本地路径、个人账号、个人素材目录的流程
• 还没有想清楚审批边界的外部提交流程
• 导入后仍大量需要口头解释才能用的流程

导出、导入、分享，分别怎么用

1. 导出草稿 JSON

更适合：

• 保存当前编辑状态
• 给同事继续改
• 在另一个环境里继续调流程

使用时要注意：

• 它更偏“编辑中的流程结构”
• 带过去之后，通常还要重新核对连接、路径、审批和交付目标
• 不要把草稿 JSON 直接当成“已经完成治理的正式模板”

2. 导出 workflow / WorkPack package

更适合：

• 做 starter
• 做团队内可复用模板
• 作为 Hub 供给或其他环境导入来源

使用时要注意：

• package 适合讲“这套做法是什么”
• 它不等于“接收方环境已经就绪”
• 接收方导入后，仍然可能要补连接绑定、能力检查、审批设置和目标路径

3. 导出 run dossier

run dossier 更像“这次执行的归档证据包”。

它适合：

• 给客户或内部留执行记录
• 做复盘
• 做问题排查
• 对外提交前后做审计留痕

它不适合：

• 当模板回收再导入
• 代替 workflow / WorkPack 本体

如果你的场景涉及浏览器提交、审批、proof、桌面取证，这个导出尤其有价值。

4. 分享到 Hub

适合把已经较稳定的流程变成别人可直接起步的来源。

更推荐的顺序是：

1. 先在本地测试项目跑通
2. 再确认输入字段、审批点、交付结果
3. 再清理敏感信息
4. 最后再考虑发布到 Hub

5. 节点里的云端交付

这是 workflow 某些交付节点的目标类型，不是“把整个流程上传到 Hub”。

所以如果用户问：

“我已经选了 cloud publish，为什么别人还不能从 Hub 里找到这条流程？”

答案通常是：

因为你配置的是交付去向，不是模板分发来源。

分享前一定要做的信息脱敏

可以把这一步理解成：

把“能跑”变成“能安全给别人看 / 给别人用”。

当前产品里已经有一些受控保护，比如：

• 对受控代码说明会做截断和脱敏显示
• 原始 token / secret / password / api key 会尽量被摘要化或替换
• 某些导入的自定义代码 metadata 只允许保留 summary-only 摘要

但这些保护不能代替你自己的分享前检查。

正式分享前，建议逐项检查：

• 是否写死了本地目录路径
• 是否暴露了测试或生产 URL
• 是否带上了个人邮箱、手机号、客户名、订单号
• 是否把真实连接实例、资源 ID、账号名直接写进说明
• 是否把浏览器提交目标写成真实生产地址
• 是否包含不该外发的截图、附件、表格内容
• 是否把 prompt、代码片段、参数样例里残留了密钥或签名串

最实用的脱敏原则

• 模板里保留字段，不保留真人真数据
• 保留结构，不保留真实凭据
• 保留示例，不保留客户内容
• 保留审批位置，不默认帮别人跳过审批

如果你要做对外演示版，推荐把字段值都换成：

• example.com
• test-project
• demo@example.com
• sample-folder
• approvalRequired=true

这种不会误触真实环境的占位值。

导入其他 workflow，特别是 n8n，要怎么理解

先说最关键的一句：

导入不等于原样执行。

当前产品把 n8n JSON 视为重要导入入口，但导入后仍然会经过一套显式审查流程，而不是把外部 workflow 当成完全可信、完全可直接运行的东西。

更适合用户的理解方式是：

1. 先把外部 workflow 读进来
2. 再把它翻译成 Raydo 可理解的结构
3. 再检查哪些能跑、哪些要改、哪些必须人工确认
4. 再做本地连接绑定
5. 条件满足后才保存或运行

如果你现在要的是一份可以直接照着迁、照着切的操作手册，建议继续看：

• 外部 workflow 迁移指南

n8n 导入时，最需要注意什么

1. n8n JSON 是主入口，但不是免审入口

当前设计里，n8n JSON 导入会经过五步：

1. 导入文件
2. 理解 workflow
3. 检查准备度
4. 绑定连接
5. 保存并运行

这意味着它强调的是“低噪音理解 + 显式复核”，不是“贴进 JSON 马上开跑”。

2. 节点会被分类，不是全部照搬

导入后，你应该预期会看到类似几类状态：

• 已识别
• 已转换
• 需要复核
• 暂不支持

也就是说，Raydo 更像是在做“规范化导入”，不是保证外部节点 1:1 原样落地。

3. 外部连接不会按品牌名自动乱匹配

连接绑定强调的是“精确绑定”，不是因为你本地也有一个同品牌连接，就自动替你接上。

所以导入后要特别检查：

• 连接器实例是不是对的
• 资源目标是不是对的
• grant / 权限是不是对的
• 当前项目是不是该用这个绑定

4. 导入的自定义代码可能会被阻断

如果外部 workflow 里包含自定义代码，你不要默认它能直接运行。

当前产品边界更偏向：

• 这类步骤会被当成受控代码或自定义代码处理
• 没有完成受控 runner 审查、沙箱策略和资源限制前，可能会保持阻断
• 如果只是做过滤、拆分、映射、去重、CSV / JSONL 解析，往往更建议改成 Data transform

5. 导入的数据处理步骤可能被降级成 Data transform

有些外部数据节点导入后，会被转成 Raydo 的 Data transform 语义。

这时上线前一定要复查：

• 处理方法对不对
• 输入来源对不对
• 输出字段名对不对
• 下游节点是否仍然能接住这个输出

6. 缺 provider、缺能力、缺审批，不会自动补齐

导入只能帮你带来结构，不会替你补完治理。

典型还需要你手动补的包括：

• provider / 模型能力
• 连接实例
• 审批节点
• 交付目标
• 本地路径或项目目录
• 风险更高动作前的人工作出决定

导入其他 workflow 的推荐顺序

如果你准备从 n8n 或其他外部系统迁入，建议按这个顺序做：

最常见的误区

• 把 cloud publish 当成 Hub 发布
• 把导出草稿当成团队正式模板
• 把 run dossier 当成流程本体
• 把“导入成功”误以为“可直接生产运行”
• 把别人给你的 starter 误以为已经适配你的连接和权限

推荐搭配阅读

• 工作流
• WorkPack 与复用
• 外部 workflow 迁移指南
• 运行、审批与排错
• workflow 常见报错总表

常见问题