Daily Puzzle 自动验证系统是一套在「题目发布之前」与「玩家游玩过程中」持续运行的校验机制，目标只有三个：

1. 保证每天的题是“对的”（可解、唯一解、规则一致）

2. 保证所有玩家面对的是“同一题”（公平性）

3. 保证失败是因为玩家，而不是题目或系统

它不是风控，也不是反作弊，而是内容可靠性基础设施。

---

核心设计目标

1️⃣ 公平性（Fairness）

• 全球同一天 → 同一道题

• 不因地区、设备、刷新次数改变题目

• 失败次数、提示规则统一

2️⃣ 可解性（Solvable）

• 题目 至少存在一个解

• Daily 模式通常要求 唯一解

3️⃣ 可验证性（Verifiable）

• 不依赖人工抽查

• 发布前 100% 自动校验

• 发布后可回放验证

---

系统整体架构（抽象）

Puzzle Generator ↓ Content Validator（核心） ↓ Daily Seed Binder ↓ Production Release ↓ Runtime Validator（游玩时）

---

一、发布前验证（Pre-Publish Validation）

这是最关键的一层。

✅ 1. 结构合法性校验

确保题目满足基础规则约束：

• 网格尺寸正确（如 5×5、9×9）

• 字符 / 数字 / 单元格合法

• 线索数量、位置在允许范围内

失败即丢弃，不进入候选池

---

✅ 2. 可解性验证（Solver Check）

系统内置 Deterministic Solver：

• 对题目执行完整求解

• 验证：

  • 是否存在解

  • 是否能在有限步数内完成

  • 是否无死循环状态

if solve(puzzle) == null: reject()

---

✅ 3. 唯一解验证（Daily 必须）

Daily Puzzle 的关键要求：

只能有一个合法解

实现方式：

• 正向求解得到解 A

• 在关键节点施加反约束

• 尝试搜索第二条路径

if solution_count > 1: reject()

---

✅ 4. 难度落点校验（Optional 但强烈推荐）

不是所有题都适合 Daily。

常见策略：

• 控制平均推理深度

• 限制回溯次数

• 控制“猜测概率”

目的：
👉 Daily = 可完成 + 有挑战，但不折磨

---

二、Daily Seed 绑定机制（公平性核心）

为什么要用 Seed？

不用 seed 的 Daily Puzzle 会出现：

• 不同用户看到不同题

• 刷新可换题

• 被怀疑“操控结果”

标准做法

seed = hash(UTC_date + puzzle_type)

• 所有用户当天用同一个 seed

• seed 决定题目索引 / 变体

• 前端无法更改

这一步保证：

“Everyone plays the same puzzle today.”

---

三、运行时验证（Runtime Validation）

玩家游玩过程中，系统仍在持续校验。

✅ 1. 输入合法性验证

• 操作是否符合规则

• 是否出现非法状态（越界、重复、冲突）

✅ 2. 状态机校验

典型状态：

PLAYING → COMPLETED PLAYING → FAILED（超过错误上限）

禁止出现：

• COMPLETED → PLAYING

• FAILED → COMPLETED

---

✅ 3. 错误上限与软失败机制

以 Sudoku / Daily Puzzle 为例：

• 固定错误次数（如 3 次）

• 达到上限 → 标记失败

• 允许继续练习（非计分）

这是体验层面的“温和失败”。

---

四、发布后回放与审计（Post-Release）

成熟系统必须能：

• 用 seed 重建当日题目

• 用 solver 重放玩家路径

• 定位争议（“这题是不是有问题？”）

这一步是信任的最后防线。

---

为什么这套系统很重要？

没有自动验证系统的 Daily Puzzle 会：

• 偶发无解 / 多解

• 玩家误以为自己“菜”

• 信任快速崩塌

• 日活不可持续

Daily Puzzle 不是内容问题，而是系统工程问题。

---

总结一句话

Daily Puzzle 的核心不是“每天出题”，
而是 每天稳定地出一题“不会背叛玩家”的题。

自动验证系统，就是那条看不见、但决定生死的底层逻辑。