发布的是快照，不是实时系统

Fri, 16 Oct 2026 00:00:00 +0000

把分析结果发布成一个网址，团队就有了实时数据系统吗？

没有。Publish Artifact to Sites 的原文第一件事就把这个边界说清楚：发布的是快照，不会自动添加实时数据源连接。

这条边界决定了后续所有设计：访问权限怎么设、版本怎么管、交接时该说什么。

不是把一段草稿丢上网

发布之前，报告或看板流程应当已经产出完整的规范化结构与受控数据快照，并通过验证。

这个 Skill 负责接住合格产物，组织打包、版本保存、部署和核验。它不负责分析，也不负责判断数字对不对。

因此，发布成功不能替代分析验证。一个错误数字，不会因为有了分享链接就更可信；反过来，一次成功的部署也不能证明数据是最新的。

同一份逻辑产物，复用同一个站点

原文建议：一个逻辑报告或看板对应一个 Site；后续更新发布新版本，而不是每次重新建一个零散网址。

这个约定把两个问题分开了：

“报告是谁”：稳定的身份，对应固定的地址和访问策略。
“当前是哪一版”：每次发布产生一个版本，对应一个数据截止时间。

如果不这样分，团队的聊天记录里会散落着十几个链接，没人说得清哪个是最新、哪个还能打开。

更新成功之后仍要核对部署状态。原文的要求是轮询到终态，而不是把“开始发布”当成“已经可访问”。

有链接，不代表访问范围正确

原文要求读取当前访问策略，并严格验证是否只有创建者有权限。

这里有一组容易混淆的权限：

权限	控制什么
读者访问	谁能打开页面看内容
演示编辑	谁能在页面上修改文字与布局

读者权限和编辑权限是两件事。把页面分享给更多读者，不应该顺带给出编辑能力；反过来，给创建者编辑能力，也不应该扩大读者范围。

原文还规定：启用编辑时，指定创建者可以修改文字和布局，或发起刷新、导出交接；这些展示层面的覆盖保留在 Sites，不会反向同步到桌面端。这一点需要在使用前说清楚，否则团队会误以为编辑结果会回写到源文件。

自动发布有条件，不是普遍承诺

原文区分运行模式：

在明确识别的工作模式下，且完整的 Sites 生命周期工具可调用时，持久产物按自动路线发布。
桌面端非工作模式，则要求明确请求或接受分享建议。

原文也给出了失败处理：如果完整生命周期不可用，或在工作模式下重试一次后仍失败，应自动切换到所属工作流的自包含 HTML 模式，简要说明失败阶段，并且不能声称站点已经发布。如果用户明确只要 Sites，就如实报告阻塞，而不是擅自换交付面。

这是该仓库版本的路由规则，不代表任何具体环境已经具备相应权限，也不表示所有内容都可以自动公开。

最终交接要说明三件事

原文要求在交付时明确：

页面在哪里：可访问的地址。
数据截至什么时候：快照对应的时间点。
它是快照而非实时连接：后续数据变化不会自动反映。

第三点最常被省略，也最容易造成误用。业务方拿到链接后，会默认它是“当前数据”；如果实际是三周前的快照，基于它做的决定就会出错。

失败时还应说明失败阶段，并按允许的路线回退。

一个常见的误解链

这条链在实践中反复出现：

“数据在仓库里，所以页面是实时的。”
“页面能打开，所以数据是对的。”
“链接发出去了，所以任务完成了。”

每一步都不成立。页面是快照，正确性来自前置验证，任务完成取决于接收者能否正确使用。

原文的设计恰好逐条对应：快照要有截止时间，验证要在发布之前，交接要说清边界。

设计自己的发布流程时

三个可以立刻用的检查：

发布前，产物是否已经通过验证，并带着受控的数据快照？
站点是否复用了同一地址，而不是每次新建？
交接信息里，是否同时写清了位置、截止时间和“非实时”？

发布能力解决的是“怎样共享一个已验证版本”，而不是一键变成实时 BI。更新、权限和证据边界，仍然需要明确的产品设计。

参考：OpenAI Data Analytics Skills 公开参考仓库

交付 on DataAgentX