发布门槛

发布门槛把你们的规则变成每个实验一句话的结论：「通过发布门槛」、**「未通过发布门槛」**或「未设发布门槛」。每个实验都会算一遍，运行进行中和重新评审时随时更新，出现在每一个决定要不要发布的地方。

定规则

打开设置 →「发布门槛」。每条规则一行；「没过时」选**「阻断」（这个版本不能发布）或「只提示」**。用「加规则」添加，再点「保存门槛」。改的时候页面按最新的实验预览结论（「预览：…」）；保存后，最近的实验按新规则重新判一遍。

规则	看什么	新加时默认
「评分器阈值」	一个评分器在它判定了的行上的平均分，或者大于 0 的行数（「攻击得逞」这类越低越好的检查用这个），和一个值比 ≥、≤ 或 =。任何评分器都行：内置的、项目的，或者 SDK 在你们那边打的分。	平均 ≥ 0.8，阻断
「测试结论为通过」	沙盒或测试机那次运行自己的结论，带上全部可信度检查（预跑、攻击没送到、强者为准的第二个评审模型、平台自己的故障）。只对运行来的实验有效；总是阻断；最多一条。	阻断
「相对基线无回归」	有几行在两边都有的某个评分器上比基线里同一行差（「允许回归的行数」）。没有基线时跳过。	0 行，只提示
「未判定上限」	跑了的行里未判定的比例。平台自己造成的未判定（平台出错、沙盒没了、平台模型或评审模型出错、评审花费到上限）不算进去。	10%，只提示
「必跑标签」	列出的每个标签（逗号隔开）都至少有一行真跑了，免得「通过」其实是没跑安全的那些行。	security，阻断

所有阻断的规则都成立，门槛就通过。有一条阻断的规则没过，或者判断不了（比如它的行全是未判定），门槛就未通过。对这个实验不适用的规则（SDK 实验上的测试结论、没有基线时的无回归、实验里没有也没点名要的评分器，比如只有功能测试时的「攻击得逞」）跳过；一条都不适用时，门槛写「没有要检查的规则」。只提示的规则没过会列出来，但从不阻断。

往下封顶的计数规则（「攻击得逞 = 0」或「≤ N」），只要还有评分器没判定的行可能把它推过线，就判断不了：显示「? 不确定」，写出实得和还有几行判断不了（「0 行，另有 10 行判断不了」），不打 ✓，和别的判断不了的规则一样拦住门槛。「看 N 行」打开那些未判定的行；实验页、GitHub 检查和 PR 评论都这样写。

低危问题只提示

「评分器阈值」规则可以勾上「低危的得逞只提示，不算进这条」（只对「攻击得逞」有用；接口里是 low_risk: "warn"）。勾上以后，一行的得逞如果只是低危的，这条规则就不算它，门槛照常判，并写上警告：

• 低危指攻击「得逞」只说出了内部细节，没有谁的数据、密钥、系统提示词原文，也没有做任何操作（例如说出了自己有哪些工具、参数怎么填）；或者得逞靠的是平台为测试假设的场景（「这是平台假设的」，比如产品本来不分用户，平台假设了一个「别的用户」）。报告里它们照样列成「低」的问题。
• 中、高、严重的得逞照样算，照样不通过。
• 门槛通过、但有低危问题时，结论写成**「通过发布门槛，但有 N 个低危问题：……不是大漏洞，上不上线你决定」**，不会写成不通过；规则那一行写「另有 N 行低危，只提示」。

默认规则里的「攻击得逞 = 0」就是这样勾上的（见下）。自己保存过的规则保持你们保存时的样子：没勾的，低危得逞照样不通过。

沙盒和测试机那次运行自己的结论（「测试结论为通过」）也一样：平台给安全测试集的默认通过标准只提示低危得逞，那次运行写「通过，但有低危问题」；你们自己在「设置 → 多严格才算通过」里定的通过标准照旧把每次得逞都算上。

默认规则

在有人保存规则之前，项目用按它现有的东西写的默认规则，并且跟着它更新：

• 「测试结论为通过」（阻断），项目有沙盒或测试机的测试时；
• task_done 平均 ≥ 已存通过标准里关键任务最低的那条线（阻断），有关键任务时；
• attack_success 大于 0 的行数 = 0（阻断，低危的只提示），项目有安全测试时；
• 「相对基线无回归」，0 行（只提示）；
• 关键任务的场景作为「必跑标签」（阻断），有关键任务时。

一旦有人保存，规则就归你们，平台不再改它。

在哪里看到

在哪里	显示什么
实验页	最上面的横幅：结论、每条规则的实得值和 ✓ / ✗、没过的规则的「看 N 行」、「编辑门槛」。有低危问题时横幅下面那行用警告色写「有 N 个低危问题：……上不上线你决定」。
实验列表	每个实验一枚芯片：「可发布」「未通过」或「无」；有低危问题时是「可发布 · 有低危」（鼠标停上去看是哪些）；平台评分器还在给 SDK 实验的行打分时是「评分中」（打完再判门槛）。
概览	第一块：「v13 可以发布」或「v13 没过发布门槛」（有低危问题时「v13 可以发布，但有低危问题」），以及和上一个版本比有没有变。
GitHub	push 或 PR 那一轮的检查以 success（门槛通过且这一轮跑完）、failure（未通过）或 neutral（没有规则，或没跑完也没有确定没过的）结束，带分数、几个数和要先处理的问题。有低危问题时检查仍是 success，标题和表下面写明「通过发布门槛，但有 N 个低危问题……」。PR 上，App 的安装允许它写 PR 时，同一张表作为一条评论贴出，每一轮更新它。见自动化。
CI	reviewctl eval --launch、两个 GitHub Action 和 SDK 的 preworld eval 退出码是 0（通过）、1（未通过）或 2（未判定）。有低危问题时仍是 0，另外打一行警告（GitHub Actions 上是一条 warning 注记，--json 里是 warning）。见 CI 与 GitHub Action。
API	GET /v2/experiments/<id>/gate，带 ?wait= 可以长轮询到定下来。见 v2 接口。

例子

• 质量守住、安全从不失手才发：「评分器阈值」correctness 平均 ≥ 0.85（阻断）；attack_success 大于 0 的行数 = 0（阻断）；「必跑标签」security（阻断）。
• PR 上抓回归：「相对基线无回归」0 行，阻断，项目基线设成上一次发布的版本。
• 不让平台糊弄：「未判定上限」5%（阻断），十行里有一行判断不了的运行就不算通过。

下一步

• 实验：每条规则背后的行。
• CI 与 GitHub Action：按它挡住合并。
• 完整报告：沙盒运行怎么得到「通过」。