让随机可解释：零号变种的概率预览与规则边界

On this page · 6 sections

不确定的结果，也需要确定的规则

项目现名为零号变种 VARIANT ZERO，前身是零号试剂／异芽 MUTABLOOM。它把基因组合、杂交与塔防决策连接起来。本文讨论的规则测试和界面记录来自早期 v0.3 原型；封面是为文章新作的概念插画。遗传机制是玩法抽象，不是生物学遗传模拟。

这里讨论一个很小但重要的约束：预览只解释可能结果，确认才提交变化。如果查看信息本身改变了未来的随机结果，玩家表面上获得了更多理解，实际上却在无意中影响规则。这会让“我只是看一眼”与系统真实行为发生冲突。

依据原型规则整理 · 查看不消耗随机状态，确认才进入验证与提交

现有测试先记录 hybrid 随机流状态，再连续调用十次 recipe 预览，要求状态保持相同。它随后检查确认杂交后的主系、代数、继承基因等变化，并检查无效操作不改变资源与随机状态。相关遗传测试在 2026 年 9 月 6 日的本地运行中全部通过。^[1]

TypeScript

const before = battle.rng.hybrid.state;
for (let i = 0; i < 10; i++) battle.recipe(a.id, b.id);
assert.equal(battle.rng.hybrid.state, before);

根据已核验测试精简的说明片段；保留预览无副作用的核心断言。

这条测试并没有证明整个系统都正确。它的价值是把一个容易遗漏的用户期待，变成每次修改后都可以重新检查的约束。测试报告比“随机系统公平可靠”这样的整体形容更窄，却也更可验证。

被核验的 weightedPhenotype 测试使用三个候选，检查 0、接近 0.6、0.6、接近 0.9、0.9 与接近 1 的输入，对应三段选择区间。这种边界检查用于防止临界值落入错误分支；它不是通过有限次抽样证明长期分布，也不表示游戏中的所有随机选择都采用同一组权重。^[1]

三种不同的检查

因此，规则正确与表达清楚需要分别验证。一个显示为 60% 的选项，可能被理解成每十次必定出现六次，也可能被理解成越久没出现就越该出现。界面如果没有这种机制，就不应该通过措辞暗示存在补偿。

把全部内部参数摊开，不一定让玩家更容易决定。面对一次操作，更重要的通常是：可选结果是什么、会消耗什么、失败或不利结果意味着什么，以及能否取消。更深的规则可以放在第二层说明中。

这里也存在取舍：完全可预测的系统可能失去探索感，而无法解释的系统又可能只剩挫败。本文不声称已经找到了最佳平衡。代码测试能回答规则是否按定义工作；节奏、惊喜与理解成本，仍需要实际游玩反馈。

下一步值得验证的不是再问一句“界面好不好看”，而是让首次接触的人完成一个具体任务，并用自己的话解释发生了什么。以下是待开展的测试方案，不是已经收集到的玩家反馈；测试材料也应明确是否存在保底、累积概率或状态相关机制。

待验证的理解任务

如果访客能读对百分比，却持续误判确认的代价，应先调整决策界面，而不是把概率说明写得更长。若只有熟悉原型的人能解释规则，则需要检查新人路径。真正会改变设计判断的，是这些具体的理解障碍；测试数量增加本身不等于已经找到最佳体验。

预览不改变状态、无效操作不消耗资源、重复结算不重复记账，这些都是关于“允许什么变化”的问题。它们可以启发其他软件设计，但不能把游戏原型的验证直接当成企业系统的可靠性证据。

我更愿意用这样的小问题解释自己的方法：先把人的预期写成规则，再让代码与测试共同守住它。随机性负责保留未知，清楚的边界负责让未知仍然值得探索。