KENSAI 产品更新：证据优先发布与提交流程纪律收紧了 same-day 表面

KENSAI 在 4 月 16 日进一步收紧了运营要求，强制加入接受概率判断、提交所需的视频证据，以及按语言拆分的博客索引，从而让 same-day 发布在所有要求语言中保持一致。

今天发布了什么

今天的工作同时收紧了两个系统：KENSAI 如何判断一个 bug bounty finding 已经可以提交，以及公开博客如何证明某一天的内容确实已经完整发布。结果是更少的表演成分。没有明确的接受概率和视频证据，一个 finding 就不能算真正 ready；而只要本地 HTML、本地 JSON 和 overview 页面没有讲同一个事实，当天文章也不能算真正 published。

这听起来很严格，但这是正确标准。薄弱的建议会浪费提交流程，部分发布则会制造无声漂移，直到用户或爬虫访问到陈旧页面时问题才暴露。

1）提交建议现在必须先给出接受概率，必要时直接建议不要发送

现在提交建议必须先说最难听但最有用的部分。如果接受概率偏低、scope 依据不稳，或者最可能的结果只是 informative 或 out of scope，那么建议就应该明确写成不要发送。这比继续打磨一份本来就不该离开队列的报告更好。

这让队列变得更诚实。在时间和信誉都有限的情况下，证据和接受概率应该比乐观情绪更重要，安全工作流本来就该这样运作。

2）视频证据现在属于“准备就绪”的定义之一

第二个收紧点是证据。现在仅靠文字 write-up 已经不足以把一个 finding 标成 submission-ready。如果利用路径本身很关键，提交包就必须包含可以清楚展示行为、也经得起审阅者怀疑的视频证据。

这会把团队从叙事膨胀拉回到可复现证据，也让“有趣信号”和“真正可以提交的报告”之间的边界更清晰。

3）只有本地 HTML、本地 JSON 和 overview 页面一起更新，same-day 发布才算诚实

在发布侧，同样的规则也成立：公开证据胜过内部意图。每种语言只能出现在自己的 JSON 索引里，英文索引不能吞进非英文条目，locale 文件落地后还必须重新生成 overview 页面。

这样 same-day 表面才是诚实的。只有当渲染后的 HTML 已经存在、正确的按语言 JSON 文件都指向这些文章、并且每个语言 overview 都展示与英文完全一致的 4 月 16 日文章集合时，这一天才算真正发布完成。

为什么这很重要

这才是值得保护的产品行为。系统获得信任的方式，是让强结论更难被伪造。Submission readiness 应该意味着证据，publication 应该意味着在公开表面上可见的一致性。

这比寄希望于内部状态迟早会和用户看到的状态一致，要强得多。