为什么每一次卜辞都可复现?加密种子的伦理

传统卜筮的一个核心特质,是 不可重复:

• Fal-e Hafez:你翻到的那一页只属于那一刻。再翻一次,就是另一首诗
• 玛雅 Tzolkin:每一天有它独一无二的能量。你不能"重抽今天"
• Rune:抛出去的木片落下来,不能再抛同一次

这种不可重复,是卜筮神圣性的一部分。它强制你接受当下、不让你为不喜欢的结果"再试一次"。

但当卜筮搬到互联网,这个特质变成了一个需要重新审视的设计选择。

一个 reading_id 后面藏的东西

你每次在卜辞下单,服务端做的事:

1. 用 os.urandom() 生成一个 256-bit 加密随机种子
2. 用这个种子 + 系统类型(Hafez/Tzolkin/Rune)选择 artifact:
   • Hafez:从 244 首 ghazal 中确定性挑一首
   • Tzolkin:计算今日 Tzolkin(实际上不需要种子,因为是日历驱动)
   • Rune:确定性抽 1 / 3 / 5 个符文
3. 把 artifact + 你的问题送给 LLM 生成解读
4. 保存:种子、问题、LLM 模型版本、prompt 版本、生成的解读、时间戳

每份卜辞拿到一个 reading_id。给定 reading_id,我们能完整重放整个生成过程。

为什么这么设计?

四个原因:

1. 可分享 你和朋友讨论一份 Hafez 解读,对方点开你发的链接,看到的是同一首诗、同一份解读。卜辞变成了可流通的素材,而不是私人秘密。

2. 可审计 如果有人质疑:「这份解读是 AI 编的吗?能不能验证它真的对应 Hafez 第 X 首?」—— 我们可以拉出 reading_id 对应的种子,展示从种子到 artifact 的确定性映射,任何人都能独立复算。

3. 可改进 当我们升级 prompt 版本(比如从 v1 到 v2)、或者切换 LLM 模型(Sonnet 4.5 → 4.7),我们可以拿历史问题集回测新版本:同一个种子,同一个问题,新解读跟老解读哪里不同?这让卜辞的质量随时间提升,且有据可查。

4. 可重读 你三个月后回头看自己问过的那份 Hafez,它一字不变在那里。这跟传统 Yalda 之夜的家庭朗诵不同 —— 那时候没人写下来。我们写下来,因为我们认为某些个人时刻值得回放。

损失的部分

承认这个设计确实损失了一些东西:

• 传统的"一次性神圣感" —— 知道结果不能重来,赋予阅读那一刻以重量
• "随机"的真正含义 —— 当抽出的木片可以被精确重放,它还是真的随机吗?

我们的态度:这种损失是 可接受的代价。

因为:

• 加密随机种子在数学上仍然是不可预测的(在生成的瞬间)。可重放不等于可预测。
• 我们鼓励用户的态度,不是"重抽一次直到喜欢",而是 "先接受这一份,过几天回来再读它"。
• 我们故意没有提供 /divine 的 retry 按钮。同一问题、同一系统、在同一天再问一次,会返回同一份解读。

一个借鉴

这个设计灵感来自两个地方:

Git 的 commit hash:每次提交得到一个 SHA-1。这个 hash 让代码变更可追溯、可复现、可分叉。git 不破坏代码的"不可逆性"(commit 已经发生),而是给了它身份。

Wikipedia 的版本历史:每一条目都保留全部历史版本。这让 Wikipedia 既能持续改进,又能被审计。

我们认为占卜也值得这套基础设施。卜筮的神圣性不是依赖"无证据",而可以建立在"完整证据 + 诚实记录"之上。