世界引擎（愿望清单 #60 + #61）— 讨论记录

状态：🟡 规划 · 最后核对 2026-08-06

2026-08-02。讨论中，未实施。 三个问题待博士拍板（见文末）。

起点：博士对「#61 模拟系统和 #60 世界引擎是不是一件事」的回答 —— 「我倾向于有一个时间线和真实运作的世界，不过我们还得讨论一下。」

一、先把那句话拆成两件事

差一个量级。而且时间线是真实运作的前提 —— 没有事件记录， 「世界动过」这件事既无从证明，也无从被干员引用。 世界动了但没人记得，等于没动。

二、一个发现：#59 地点 就是 #61 的另一半

一条事件最小需要四样：谁 / 什么时候 / 发生了什么 / 在哪。

博士把 #59 定成「是个系统不是个显示」，正好补上唯一缺的那一维。 这不是巧合，是同一件事的两个面 —— 所以 #59 在 backlog 里被提成 B0，排在报纸前面。

三、地基：一张事件流

{ 时间, 类型, 参与者[], 地点, 摘要, 谁能知道 }

一张只增不改（append-only）的表。有了它：

⚠️ 谁能知道 那一列是整个系统的灵魂。

如果所有干员都能读全部事件，那不是世界，是全知广播。 信息必须有传播成本：同一个地方的人立刻知道，同组织的人隔一天知道， 其他人可能永远不知道。

而这正是为什么地点必须先做 —— 没有「哪儿」，就没有「传得到传不到」。

四、核心分岔：事件从哪来

推荐混合。理由是一句关于 LLM 的判断：它不擅长「保持一致」，擅长「把一件事说好」。 让它决定世界发生了什么，它会写出互相矛盾的东西； 让它把已经确定的事实叙述出来，它写得很好。

成本：335 个干员不可能每 tick 全跑。但只有你聊过的那几十个需要真的活着， 而且 tick 可以很慢（一天 2~4 次）。混合方案下每 tick 是 1~2 次批量叙述， 不是 N 次决策。

五、三个待拍板的问题

① 世界推进要不要等你？

• 不等 = 你会错过事情。那正是「真实」的代价，也是报纸存在的理由
• 等 = 它就不是运作，是「你上线时补演」

倾向不等，但要有上限 —— 离线 30 天不能生成 30 天的事件把你淹了。

② 世界事件要不要进干员的记忆？

她的 L1–L4 现在**全是「你和她之间」**的。世界事件是「她和别人之间」的。

• 进 → 挤占你们对话的记忆预算，而且她可能张口就聊别人的事
• 不进 → 世界发生了什么她完全不知道，那世界就白转了

倾向进，但走一条独立的、容量很小的通道，且只进和她直接相关的 （她在场 / 她的组织 / 她认识的人）。

⚠️ 这一条我拿不太准，它直接决定世界事件会不会污染你们的对话。

③ 一条世界事件的存在门槛是什么？

提案：一条事件如果不会改变任何干员对你说话的方式，它就不该被生成。

这是防噪音唯一的硬标准。每天 20 条「某某在食堂遇到某某」，读三天就再也不看了。

六、建议的第一步：只记账，不生成

第一步一个新事件都不生成，只把已经在发生的事写进事件流：

• 干员发了动态 → 一条
• 你和谁深聊了 → 一条
• 谁主动找了你 → 一条
• 谁的心情档位变了 → 一条

四个理由：

1. 零风险 —— 不生成内容就不会生成垃圾
2. 立刻有用 —— 报纸马上就有素材，一行生成逻辑都不用写
3. 可验证 —— 事件流里有没有东西一眼就知道（「世界在运作」没法验）
4. 它会告诉你世界有多空 —— 记一周之后看那张表，就知道该补什么

这和 #9 第 1 步是同一个思路：先把管道接通，再往里灌东西。

#9 的教训正是反着做的代价 —— record_residue 写了、wrap_oldest 写了， 而表达端根本不存在，于是写进去的东西两周内衰减干净，谁都没感觉到。 见 relationship-decay-design.md。

七、明确的边界（已定）

• 不抓明日方舟官方活动资讯。 那是「你在一个游戏里」的信息， 喂给泰拉世界的角色会破坏叙事前提 —— observer.html 就是因为这个被删的： 数据一个字没漏，但幻觉漏了。（#6 澄清时定的）