Hub 发布前检查表 / 发布规范
把 workflow / WorkPack 发布到 Hub 之前，按这页逐项检查结构、风险、审批、环境和版本记录。
功能状态：预览
这一页总结的是当前产品里 workflow / WorkPack 在发布前最稳定、最明确的一组检查门槛。Hub 供给、发布流和部分运行准备度提示仍可能继续细化，但这些基本检查已经足够作为官方发布前 SOP。
这页只回答一个问题：
这条 workflow / WorkPack 现在到底能不能发到 Hub。
不是问“能不能自己跑一下”。
也不是问“能不能给同事临时看一眼”。
而是问：
它现在是不是已经适合变成别人能拿来起步的模板来源。
先说结论
能跑，不等于能发 Hub。
能导出，不等于能发 Hub。
能给自己演示，不等于能发 Hub。
真正适合发到 Hub 的，至少要同时满足四件事：
- 结构稳定
- 输入清楚
- 风险边界明确
- 别人接手时不会误伤真实环境
什么时候该看这页
下面这些时刻，都建议先过一遍这张表：
- 你准备把 starter 放进 Cloud Hub
- 你准备把一条稳定 workflow 提升成团队模板
- 你准备把 WorkPack 给更多角色或项目复用
- 你准备给销售、客户 onboarding、内部培训提供统一模板入口
如果你还在频繁改节点、频繁改输入、频繁改交付目标，先别发。
先继续在本地和测试项目里打磨。
发布前最重要的 3 个硬门槛
当前产品里，至少有三类门槛已经很明确：
1. 草稿不应该被当成正式基线
当前发布流里，draft 需要先 publish，才适合作为正式运行或定时的基线。
用户视角里可以把这条理解成：
别把“我正在改的草稿”直接当成 Hub 正式入口。
2. 发布变更单要填完整
当前发布流明确要求至少补齐三项：
- 发布理由
- 审批意见
- 审批人签名
如果这三项缺任何一个，发布流本身就不完整。
3. 对外可用前，更适合有 publish / deploy approval
当前产品里，发布流已经把 publish approval 和 deploy approval 放进最后一步的语义里。
尤其是下面这些情况，更不建议跳过：
- 要给外部团队或客户使用
- 涉及浏览器提交、消息外发、目录写入
- 依赖外部连接和权限
- 会被当成正式 starter 长期复用
一页通关表
下面这张表可以直接当发布前 checklist 来用。
全部满足，才建议发 Hub。
A. 结构通关
- 这条 workflow / WorkPack 的目标一句话能讲清楚
- 输入字段已经基本稳定，不会今天叫
topic，明天改成subject - 输出结果明确，别人知道最终会得到什么
- 主干步骤稳定，不依赖你口头补充“这里其实还要手动判断一下”
- 不是临时试验图，不是半成品画布
B. 运行准备度通关
- 在测试项目里至少完整跑通过一轮
- 没有明显的
阻塞发布 / Publish Blocked状态 - 没有还没处理完的
待连接授权 - 没有还没处理完的
待复审 - 没有关键节点还停留在
能力缺口 - 没有关键步骤只是
惰性保留 / inert
这里最重要的一条：
如果主干节点还处在“能看、不能真跑”的状态，这条就不适合发 Hub。
C. 输入与可用性通关
- 第一次使用的人知道该填什么
- 字段名能看懂，不需要你在旁边翻译
- 示例值不会误触真实环境
- 必填项和可选项区分清楚
- 输入模板已经用真实测试数据验证过
更实用的标准是：
把这条交给一个知道业务、但没参与设计的人，他能不能在不问你的前提下跑出第一轮。
如果不能，先别发。
D. 风险与审批通关
- 所有高影响动作前都已经放了审批或人工收口
- 外部提交、公开发布、消息外发前没有默认直通
- 审批节点里已经带上足够的上下文、摘要或证据
- 不会因为别人点错一次，就直接打到真实生产目标
下面这些动作最应该谨慎：
- 浏览器提交
- 外部系统录入
- 发邮件、发消息、发渠道内容
- 写共享目录
- 调真实 API 改状态
Hub 里的模板更应该保守，不应该激进。
E. 环境与脱敏通关
- 没有写死你的本地目录
- 没有写死你的个人连接实例
- 没有暴露真实生产 URL
- 没有残留客户名、邮箱、手机号、订单号
- 没有把真实 token、secret、api key、签名串写进字段或说明
- 演示值都已经换成测试值或占位值
推荐保留的演示占位值：
example.comdemo@example.comtest-projectsample-folderapprovalRequired=true
如果一个模板必须靠你个人环境才能跑，它就还不是 Hub 模板。
F. 连接与权限通关
- 需要的连接已经重新核对，不依赖“同品牌差不多”
- 权限范围符合这条流程的真实用途
- 资源目标是模板该指向的目标，不是你个人临时资源
- 缺连接时，使用者能清楚知道去哪里补
如果模板导入后还要靠猜“到底应该绑哪一个连接”，它会把使用者带进坑里。
G. 版本与发布记录通关
- 这次发布为什么发，你能写清楚
- 这次发布的风险决策，你能写清楚
- 这次发布是谁批准的，你能写清楚
- 当前版本和上一个 active 版本的差异，你已经看过
- 需要回滚时，团队知道以哪个版本为基线
当前发布流里，版本历史和发布记录不是装饰。
它们是为了回答三件事：
- 这次改了什么
- 为什么可以发
- 出问题时退回哪一版
H. 团队复用通关
- 这条模板不靠作者本人盯着也能被理解
- 角色、用途、适用场景都说得清楚
- 不适合谁用，也说得清楚
- 最小使用说明已经写出来
很简单的判断题：
如果别人导入后第一句话一定是“这个到底怎么用”，说明它还没准备好进 Hub。
发布前推荐顺序
真正发布前，建议按这个顺序做：
哪些情况建议直接延期发布
下面这些情况，不建议“先发了再说”：
- 流程还在高频改结构
- 关键节点还处在
待复审 - 主干里还有
惰性保留节点 - 连接和权限还没绑定清楚
- 还没跑过测试项目
- 高风险动作前没有审批
- 你自己都不敢让别人直接用
Wild, 这类模板一旦进 Hub，后面不是省时间，是放大返工。
最常见的 6 个误判
| 常见误判 | 实际问题 |
|---|---|
| 我自己能跑，所以可以发 | 你可能只是靠自己的环境在跑 |
| 能导出 package，所以可以发 | 导出只说明能搬，不说明适合复用 |
| 只有一个节点，不会出事 | 单节点照样可能直连真实外部动作 |
| 只是 demo，不用那么严 | demo 最容易被复制成正式 starter |
| 后面再补审批 | 别人拿到模板时，已经可能先点了 |
| 连不上让用户自己处理 | 用户会觉得模板本身就是坏的 |
一句话发布标准
如果你想快速判断一条流程能不能发 Hub，可以只问这一句：
把这条模板交给一个合适的同事，他能不能在测试环境安全起步，而且不会因为默认值或缺说明误伤真实环境。
能，才值得发。