上线前先试跑：安全地验证动作会改什么

上线前先试跑：安全地验证动作会改什么：test run（试跑）让你在正式发布前，用真实权限模拟一次动作，看清它"会改什么、怎么执行"，却不动真数据。

Test run 让你在 Ontology Manager 里模拟一个动作类型，在终端用户能应用它之前就验证逻辑。提交一次试跑时，Foundry 会用你提供的参数值去评估这个动作，并返回它本将产生的编辑，以及一份详细的执行分解（execution breakdown）。

试跑在动作类型编辑器里、动作表单预览（action form preview）的 Test run 标签下可用。它会以你的权限在当前本体分支上执行，并强制实施与普通动作提交相同的对象安全（object security）和提交条件（submission criteria）。只要你能查看该动作类型的配置，就能跑试跑。

试跑（test run）在哪种表单布局下可用？点我看推荐 →

一次完成的试跑，结果分布在两个标签里。先看 Proposed changes（提议的改动）：

• 列出动作会对本体做出的编辑，包括创建、修改、删除的对象与链接；
• 属性变更以"当前值 vs 提议值"的对比方式呈现；
• 如果动作不会产生任何编辑，该标签会显示 No proposed changes。

这一页回答的核心问题是："这个动作到底会动哪些数据？"

Details 标签说明动作是如何被评估的、在直接编辑之外还会发生什么：

• Execution log（执行日志）：分步记录这次运行——元数据加载、依赖校验、提交条件、参数校验、编辑计算。用它理解动作为何成功、或卡在哪一步。
• Side effects（副作用）：预览动作会触发的副作用，如通知（notification）。可展开通知预览，查看将生成的内容与接收人。
• Referred entities（引用的实体）：运行期间动作引用的对象类型、链接类型、接口类型与函数（functions）。

如果动作失败，Details 会把错误分成两类：Admin-facing errors（给管理员排查的技术细节）和 End-user-facing errors（展示给触发动作的用户的消息）。

试跑只执行"确定动作结果"所需的工作，那些在动作应用之后才生效的副作用会被跳过。若你的动作类型包含以下任何一项，表单预览会提示它们将被跳过：

• 副作用 webhook（side effect webhooks）不会被调用；
• 通知（notifications）不会被发送，但结果里会显示"本将被触发"的通知分解；
• 计划构建（schedule builds）不会被触发。

但要注意：为了得出准确结果，试跑会执行动作达成结果所需的函数与调用——包括规则里的函数、生成通知正文/接收人的函数、生成 webhook 载荷的函数、writeback webhooks，以及访问外部资源的函数。也就是说，只有"算出结果所必须"的调用才会发出。