# 可執行參考世界：以遊戲世界狀態機作為通用系統的虛擬錨點

**系列：** 動態通用世界狀態機：內部架構與演化規格  
**篇次：** 02 / 07  
**版本：** v0.1  
**日期：** 2026-08-01  
**性質：** 內部技術白皮書／參考原型規格  
**基準 Repository：** `kakon77777-commits/compilableworld-runtime-mvp`

---

# 摘要

第 1 篇已確認：目前 CompilableWorld Runtime 應被視為 **Game World-State Runtime Prototype**，其中部分 Kernel／IR／Contract 已經具有高度可泛化性，但整體仍然是遊戲世界執行系統，而不是已完成的通用世界狀態 Runtime。

本篇進一步處理一個關鍵架構問題：

> 當未來 General World-State Runtime 出現後，現在的 Game World-State Machine 是不是就完成歷史任務、被抽象掉、甚至被淘汰？

答案是否定的。

本系列正式定義：現有非通用 Game Runtime 不只是「早期原型」，而應保留為：

$$
\boxed{
\text{Executable Reference World}
}
$$

亦即一個可執行、可重播、可測試、可比較、可產生反例的虛擬錨點。

這個錨點的作用不是教 AI 模仿某一款遊戲，而是提供一組被實際 Runtime 驗證過的世界結構、狀態轉移、權限邊界、事件因果、場景測試與失敗案例。未來的新 Domain 不應從空白 Prompt 重新發明世界，而應優先檢索既有 Reference World 與 Prototype Library，判斷哪些結構可以直接重用、哪些可參數化適配、哪些只能類比、哪些確實必須新生。

因此，本系列確定以下工程優先級：

$$
\boxed{
\text{Reuse}
>
\text{Adapt}
>
\text{Constrained Synthesis}
>
\text{From-Scratch Generation}
}
$$

這不是禁止生成，而是把生成縮到「既有已驗證結構覆蓋不到的剩餘部分」。

本篇的核心產物是 Reference World Anchor、Prototype Unit、Reuse Evidence、Regression Anchor 與 Promotion Candidate 五個概念，並確定 Game Runtime 與未來 General Runtime 之間不是單向取代，而是雙向共演化。

---

# 1. 現況：現有 Game Runtime 已經是可執行知識，而不只是程式碼

目前 Repository 不只是保存一些 Python 類別。

它已經同時具有：

- Authoring Layer；
- Runtime Package；
- StateStore；
- ActionIR；
- StateDelta；
- EventIR；
- ModuleContract；
- Snapshot；
- Replay；
- ScenarioIR；
- FunctionIR；
- Studio World IR；
- diagnostics；
- read-only MCP projection；
- AMK evidence boundary。

因此目前 Game Runtime 實際上已經保存了三種不同層級的知識：

$$
\boxed{
K_{\mathrm{structural}}
+
K_{\mathrm{behavioral}}
+
K_{\mathrm{empirical}}
}
$$

其中：

## 1.1 Structural Knowledge

例如：

- Action 不能直接變成 state write；
- Module 只能產生 Delta；
- Delta 由 Kernel commit；
- Event 有 causation／correlation；
- Projection 只讀；
- Memory 不得覆蓋 Runtime Truth；
- Authoring／Compiled／Runtime 分離。

這些是架構知識。

## 1.2 Behavioral Knowledge

例如：

- door 如何被 unlock；
- quest 如何因 EventIR transition；
- dialogue 如何讀 state、但不能偷偷修改 quest；
- combat 如何產生傷害 Delta 與事件；
- timed status 如何衰減；
- scheduler 如何延遲 Action。

這些是可執行行為知識。

## 1.3 Empirical Knowledge

例如 Repository 中已經出現的實際修復：

- 顯示名稱解析避免強迫使用 internal ID；
- key item 在門尚未打開前不得隨意送出；
- `unlock` 對非門實體給正確錯誤；
- combat 增加反擊與獨立擊殺訊息；
- 非 UTF-8 locale 的 CLI 輸入問題；
- invalid Studio mapping 不得被偷偷編譯；
- read-only MCP 必須以測試證明不改 state/event/tick/action registry。

這些不是抽象設計，而是：

$$
\boxed{
\text{已經被失敗逼出來的工程知識}
}
$$

這類知識尤其不應在「重做通用版」時被丟掉。

---

# 2. 為什麼「只抽 Core」還不夠？

如果未來只做：

```text
Game Runtime
    ↓
抽出 State / Event / Action
    ↓
General Core
```

然後把舊 Game Runtime 當成歷史遺留，會失去大量資訊。

因為 General Core 只能保存：

> **什麼是允許的最小結構。**

但它不一定保存：

> **哪些結構曾經在真實長流程中一起工作過。**

例如：

```text
State
Event
Action
Authority
```

這四個詞非常通用。

但實際上：

- 哪些 Event 應該觸發哪些 Module；
- 哪些 write scope 容易互相衝突；
- 哪些轉移會形成 cycle；
- 哪些 state 應該 snapshot；
- 哪些 state 是 projection；
- 哪些東西不應被記憶層升格成 truth；

都需要 concrete world 才能測。

所以：

$$
\boxed{
\text{Abstract Core}
\neq
\text{Executable Evidence}
}
$$

General Runtime 需要 Core，也需要 Reference Worlds。

---

# 3. 正式定義：Reference World Anchor

本系列定義一個 Reference World Anchor：

$$
A_r
=
(
O,
S,
R,
T,
E,
C,
Q,
H
)
$$

其中：

- $O$ ：Ontology / Entity structure；
- $S$ ：State schemas / state patterns；
- $R$ ：Relations；
- $T$ ：Transitions / temporal behavior；
- $E$ ：Event patterns；
- $C$ ：Contracts / constraints；
- $Q$ ：Scenarios / tests；
- $H$ ：Known failures / history。

這個 Anchor 不是文件摘要。

它必須對應到：

$$
\boxed{
\text{可執行 Runtime}
}
$$

因此它至少要能回答：

1. 這個世界能不能 compile？
2. 能不能 load？
3. 能不能 run？
4. 能不能 snapshot？
5. 能不能 replay？
6. Scenario 能不能重跑？
7. 某個修改會不會破壞 regression？
8. 某個新 Domain pattern 和它到底相似在哪裡？

如果只能回答「概念很像」，就不算 Reference World Anchor。

---

# 4. Reference World 與 Example 的差別

普通 example：

```text
door:
  open: false
```

只是示例。

Reference World 則需要包含：

```text
door entity
door state
unlock action
key requirement
authority
state delta
unlock event
scenario
failure case
replay behavior
projection behavior
```

所以：

$$
\boxed{
\text{Example}
\subset
\text{Reference World}
}
$$

Reference World 是可驗證結構，不是幾段 JSON 範例。

---

# 5. Game Runtime 為什麼特別適合當第一個 Reference World？

因為遊戲世界具有封閉世界優勢。

在目前 Game Runtime 中：

$$
\text{Runtime State}
\approx
\text{Authoritative World Truth}
$$

例如：

- door 是否開啟；
- actor 在哪個 room；
- quest 是哪個階段；
- HP 是多少；
- item 被誰持有；
- scheduler 在第幾 tick。

這些都由 Runtime 決定。

因此可以非常精確地驗證：

$$
\text{Action}
\rightarrow
\text{Transition}
\rightarrow
\text{Delta}
\rightarrow
\text{Event}
\rightarrow
\text{Expected State}
$$

而不需要先解決現實世界的：

- sensor error；
- delayed acknowledgement；
- network partition；
- confidence；
- belief fusion；
- physical reconciliation。

所以 Game World 不是「太簡單所以沒價值」。

恰恰相反：

$$
\boxed{
\text{Game World}
=
\text{Closed-World Laboratory}
}
$$

它讓世界狀態機的核心結構先在可控環境中成熟。

---

# 6. Reference World 應該保留哪些東西？

Reference World 不應只保存 final code。

至少要保存五類產物。

## 6.1 World Definition

包含：

- Authoring source；
- Schema；
- World IR；
- Runtime Package；
- mapping。

## 6.2 Runtime Contracts

包含：

- ActionIR version；
- EventIR version；
- State semantics；
- ModuleContract；
- Projection contract；
- Snapshot format。

## 6.3 Scenario Corpus

包含：

- happy path；
- failure path；
- boundary cases；
- conflict cases；
- replay cases；
- migration cases；
- permission-denied cases。

## 6.4 Trace Corpus

包含：

$$
\text{Action}
\rightarrow
\text{Module}
\rightarrow
\text{Delta}
\rightarrow
\text{Commit}
\rightarrow
\text{Event}
$$

的可觀測軌跡。

## 6.5 Known Failure Corpus

不只保存「成功測試」。

還要保存：

- 曾經錯在哪；
- 為什麼錯；
- 最後加了什麼 invariant；
- 哪個 regression test 防止復發。

這是未來 Prototype Retrieval 很重要的負面知識。

---

# 7. Prototype Library 不是程式碼 Snippet Library

Reference World 之後可以拆成 Prototype Units。

形式化：

$$
P_i
=
(
I_i,
S_i,
A_i,
E_i,
C_i,
Q_i,
D_i
)
$$

其中：

- $I_i$ ：prototype identity；
- $S_i$ ：所需 state pattern；
- $A_i$ ：actions；
- $E_i$ ：events；
- $C_i$ ：constraints；
- $Q_i$ ：scenarios；
- $D_i$ ：dependencies。

例如可以逐步形成：

```text
prototype.entity.lifecycle
prototype.location.occupancy
prototype.door.lockable
prototype.inventory.ownership
prototype.task.transition
prototype.resource.depletion
prototype.status.timed_effect
prototype.dialogue.readonly_projection
prototype.action.authorized_write
```

這些不是單純 copy-paste code。

它們應該帶著：

$$
\boxed{
\text{Contract}
+
\text{Behavior}
+
\text{Validation Evidence}
}
$$

---

# 8. 「可以抄的就抄」應變成正式工程策略

未來有新需求時，系統先計算或估計：

$$
R(P_i,D)
=
\text{Reuse Score}
$$

其中 $D$ 是新 Domain requirement。

依重用程度分成四類。

## A. Direct Reuse

$$
R>\theta_1
$$

例如：

- stable ID；
- state version；
- event envelope；
- scheduler；
- snapshot；
- causation chain。

可以直接共用。

## B. Parameterized Adaptation

$$
\theta_2<R\le\theta_1
$$

例如：

```text
game.position.room
→ robot.position.zone
```

或：

```text
quest.current_state
→ workflow.current_state
```

結構相同，語義需要參數化。

## C. Structural Analogy

$$
\theta_3<R\le\theta_2
$$

例如：

```text
inventory ownership
→ device custody
```

或：

```text
quest dependency
→ business workflow dependency
```

不能直接抄資料模型，但可以抄 transition／authority pattern。

## D. Residual Novelty

$$
R\le\theta_3
$$

例如現實世界才需要的：

- sensor confidence；
- observation provenance；
- external acknowledgement；
- physical effect reconciliation。

這些才進入真正新生成或客製。

因此：

$$
\boxed{
\text{Generate Only the Residual}
}
$$

---

# 9. 生成預算：Reference Coverage 越高，自由生成越少

可以定義：

$$
B_g
=
1-R_{\mathrm{coverage}}
$$

其中：

- $R_{\mathrm{coverage}}$ ：Reference / Prototype 對需求的覆蓋率；
- $B_g$ ：generation budget。

若：

$$
R_{\mathrm{coverage}}=0.85
$$

則理論上：

$$
B_g=0.15
$$

代表新結構的自由生成只應集中於剩餘 $15\%$ 。

這不是嚴格數學保證，而是一個工程治理指標。

其意義是：

> 已經存在且驗證過的結構，不應被模型任意重新發明。

---

# 10. AI workflow：先檢索，再生成

未來 AI 在看到新 Domain 時，不應立刻生成整套架構，而應先回答：

1. 有沒有對應 Reference World？
2. 有沒有 Prototype Unit？
3. 可以直接 reuse 哪些？
4. 哪些可以 parameterize？
5. 哪些只可 structural analogy？
6. 真正沒有 precedent 的是哪些？
7. 新生成是否違反既有 invariant？

因此：

$$
\boxed{
\text{Retrieve}
\rightarrow
\text{Compare}
\rightarrow
\text{Reuse}
\rightarrow
\text{Adapt}
\rightarrow
\text{Detect Gap}
\rightarrow
\text{Generate Residual}
\rightarrow
\text{Validate}
}
$$

而不是：

$$
\text{Prompt}
\rightarrow
\text{Generate Everything}
$$

---

# 11. Reference Anchor 必須提供反例

只保存成功 pattern 會讓 Prototype Library 過度樂觀。

Repository 裡「key item 可以被錯誤交付」這類 bug 的價值，不只是已修復，而是可以形成：

$$
\boxed{
\text{Negative Prototype Evidence}
}
$$

例如：

```text
ownership transfer
requires:
  no_active_world_dependency
```

或者至少形成 Scenario：

```text
Given door locked and key still required
When player gives key away
Then reject
```

這樣未來新的 asset／device custody 模型，可以避免重犯同類錯誤。

---

# 12. Regression Anchor：Reference World 的第二個身份

每一次 General Runtime 抽象化，都可能破壞 Game World。

因此 Game Reference World 同時必須是：

$$
\boxed{
\text{Regression Anchor}
}
$$

假設未來把 `StateStore` 抽成 General State Substrate，修改後必須重新跑：

- movement；
- inventory；
- quest；
- combat；
- magic；
- dialogue；
- snapshot；
- replay；
- MCP read-only；
- Studio projection。

如果 Game Reference World 失敗：

$$
\text{Generalization Candidate}
\rightarrow
\text{Reject / Revise}
$$

通用化不能靠「設計上看起來更漂亮」通過。

---

# 13. Reference Anchor 應版本化

Reference World 不是固定不動。

可以表示：

$$
A_r^{(v)}
$$

例如：

```text
game-reference/v0.1
game-reference/v0.2
game-reference/v1.0
```

每個版本記錄：

- Runtime version；
- World package version；
- contract versions；
- schema versions；
- scenario corpus version；
- known failure corpus version。

這樣未來可以比較：

$$
A_r^{(v1)}
\rightarrow
A_r^{(v2)}
$$

到底增加了哪些被驗證的 pattern。

---

# 14. Game Reference 與 General Runtime 是雙向共演化

錯誤模型：

```text
Game Reference
    ↓ 抽象
General Runtime
    ↓
Game Reference 結束
```

正確模型：

```text
Game Reference
      ↓
發現可泛化 pattern
      ↓
General Runtime
      ↓
回灌更好的 contract / tooling
      ↓
Game Reference vNext
```

形式上：

$$
\boxed{
W_{\mathrm{game}}
\leftrightarrow
R_{\mathrm{general}}
}
$$

General Runtime 可以反向提供：

- 更好的 authority；
- migration；
- trace；
- schema；
- Prototype tooling；
- compiler diagnostics。

Game Runtime 再用實際遊戲負載驗證。

---

# 15. 但雙向共演化不等於自動覆寫

General Runtime 更新後，不應自動把 Game World 全部升級。

任何回灌仍應走：

$$
\text{Proposal}
\rightarrow
\text{Diff}
\rightarrow
\text{Compile}
\rightarrow
\text{Scenario}
\rightarrow
\text{Regression}
\rightarrow
\text{Promotion}
$$

也就是：

$$
\boxed{
\text{Reference World 是錨點，不是自動同步鏡像。}
}
$$

---

# 16. Prototype Promotion：客製 pattern 如何升格？

一個 pattern 第一次出現時可能是：

$$
D_{\mathrm{specific}}
$$

若之後：

- Game 使用；
- Robot 使用；
- Smart Room 使用；

並且只需少量參數化，就可能升格為：

$$
D_{\mathrm{adaptable}}
$$

再經更多 Domain 驗證後，才可能升為：

$$
D_{\mathrm{universal}}
$$

因此：

$$
\boxed{
D_{\mathrm{specific}}
\rightarrow
D_{\mathrm{adaptable}}
\rightarrow
D_{\mathrm{universal}}
}
$$

通用性不是先驗宣告，而是：

$$
\boxed{
\text{Generalization by Repeated Successful Reuse}
}
$$

---

# 17. 升格不能只看「用了幾次」

同一 pattern 被複製五次，不代表真的通用。

Promotion 至少需要考慮：

$$
P_{\mathrm{promotion}}
=
f(
N_d,
V_b,
S_c,
R_f,
B_c
)
$$

其中：

- $N_d$ ：使用過的 Domain 數；
- $V_b$ ：behavioral validation；
- $S_c$ ：semantic consistency；
- $R_f$ ：regression-free record；
- $B_c$ ：boundary cleanliness。

真正重要的是：

> 重用後是否仍然保持同一組 invariants。

---

# 18. Reference World 也應成為 Benchmark World

未來 AI 要修改：

- transition；
- module；
- schema；
- prototype；

可以先在 Reference World 上 benchmark。

例如：

```text
100-turn persistence
1000-event replay
cross-layer transition
invalid authority
duplicate request
snapshot restore
state conflict
```

因此 Reference World 可以提供：

$$
\boxed{
\text{Benchmark Scenario Pack}
}
$$

這比單純 unit test 更接近完整世界行為。

---

# 19. 與目前 Repository 的直接對應

目前 repo 已經具備建立第一個 Reference World 所需的大部分基礎。

## 已有

- Runtime Package；
- Snapshot；
- Replay；
- ScenarioIR；
- FunctionIR；
- Studio World IR；
- EventLog；
- diagnostics；
- Schema contracts；
- ModuleContract；
- AMK raw/clean evidence；
- MCP read-only projection。

## 尚未正式建立

- Reference World Manifest；
- Prototype Unit Registry；
- reuse metadata；
- negative example registry；
- promotion record；
- cross-domain matching；
- generation budget；
- prototype lineage。

換句話說：

> Reference World 的「世界」已經有了很多，缺的是把它正式升格成可檢索、可比較、可升格的工程資產層。

---

# 20. 建議的最小 Reference Manifest

未來可以考慮：

```yaml
reference_world:
  id: game.gray_crown
  version: 0.1
  runtime_version: 0.1.1

contracts:
  action_ir: v0.1
  event_ir: v0.1
  runtime_package: v0.1

capabilities:
  - location
  - inventory
  - quest_transition
  - dialogue_projection
  - combat
  - timed_status

prototypes:
  - prototype.location.room
  - prototype.inventory.ownership
  - prototype.quest.event_transition
  - prototype.status.timed_effect

scenarios:
  - movement.basic
  - inventory.transfer
  - quest.branch
  - snapshot.restore

known_failures:
  - key_item_irrecoverable_transfer
  - ambiguous_display_name
```

本篇只定義概念。

**不要求現在立刻實作這個 YAML。**

---

# 21. 核心不變量

## R-1：Reference World 必須可執行

$$
\boxed{
\text{Reference}
\Rightarrow
\text{Executable}
}
$$

## R-2：Prototype 必須帶 Validation Evidence

$$
P_i
=
\text{Structure}
+
\text{Contract}
+
\text{Scenario}
+
\text{Evidence}
$$

## R-3：Generalization 不得破壞 Reference Regression

$$
\text{New Core}
\Rightarrow
\text{Old Reference Still Passes}
$$

## R-4：Prototype Reuse 優先於 Generation

$$
\text{Reuse}
>
\text{Generate}
$$

## R-5：Reference World 可以演化，但不可被自動改寫

所有回灌都必須經 review／validation。

---

# 22. 風險與禁止事項

## 禁止 A：把 Reference World 變成唯一世界模板

Game Reference 只是第一個 Anchor。

未來不能因為第一個世界是 RPG，就要求所有 Domain 都像 RPG。

## 禁止 B：把「相似」誤認為「可直接重用」

`quest` 與 `workflow` 可能高度相似，但不保證 failure semantics 相同。

## 禁止 C：Prototype Library 只收成功案例

失敗與 rejected pattern 也要保存。

## 禁止 D：為提高 reuse score 強迫 Domain 扭曲語義

如果某個 Domain 真的不同：

$$
\boxed{
\text{Custom}
>
\text{Fake Generalization}
}
$$

---

# 23. 尚未實作

以下能力目前應視為 Proposal，而不是 Repository 現況：

- Reference World Manifest；
- Prototype Registry；
- automated prototype retrieval；
- reuse score；
- generation budget；
- prototype promotion；
- cross-domain lineage；
- negative prototype catalog；
- adaptive composition engine。

---

# 24. 驗證條件

未來要稱某個 Game World 已成為 Reference World Anchor，至少需要：

1. 可 compile / load / run；
2. 有固定 Scenario corpus；
3. Snapshot / replay 可驗證；
4. Known failure 有 regression test 或明確 failure record；
5. 每個 Prototype 可追溯到來源 contract / scenario；
6. General Core 修改後可重跑完整 Reference regression；
7. 至少有一個新 Domain 能從它成功重用某個 Prototype，而不只是複製名稱。

最後一條尤其重要。

沒有第二 Domain 的 reuse evidence，就只能稱：

$$
\text{Reference Candidate}
$$

不能直接稱某 pattern 已經通用。

---

# 25. 本篇結論

本系列正式把目前的 Game World-State Runtime 定義為：

$$
\boxed{
\text{Executable Reference World}
}
$$

它未來同時具有五個角色：

$$
\boxed{
\text{Virtual Anchor}
+
\text{Prototype Source}
+
\text{Regression Anchor}
+
\text{Failure Corpus}
+
\text{Generation Constraint Anchor}
}
$$

因此未來 General World-State Runtime 的生成與適配流程，不應從空白 Prompt 開始，而應從：

$$
\boxed{
\text{Existing Executable Worlds}
}
$$

開始。

最終策略為：

$$
\boxed{
\text{Retrieve}
\rightarrow
\text{Reuse}
\rightarrow
\text{Adapt}
\rightarrow
\text{Generate Residual}
\rightarrow
\text{Validate}
}
$$

這就是「可以抄的就抄、通用的就通用、不通用的就客製」的正式工程版本。

下一篇將進一步處理：

# 《通用核心、參數化原型與領域客製：世界狀態語義的三層分解》

核心問題會從：

> 哪個世界拿來當 Anchor？

轉向：

> Anchor 裡的哪些東西應該留在 Universal Core，哪些應做成 Parameterized Prototype，哪些必須留在 Domain-Specific Layer？

---

# Appendix A：來源與提案邊界

## Repository 已支持的現況

本篇對以下能力的描述來自目前 `compilableworld-runtime-mvp`：

- Authoring／Compiled／Runtime 分離；
- ActionIR／StateDelta／EventIR；
- ModuleContract；
- Scheduler；
- Snapshot；
- Replay；
- ScenarioIR；
- FunctionIR；
- Studio World IR；
- AMK evidence boundary；
- read-only MCP boundary；
- 已修復的若干 gameplay / CLI / mapping 問題。

## 本篇新增的架構提案

以下概念目前不是 repo 既有正式實作：

- Executable Reference World；
- Reference World Anchor；
- Prototype Unit；
- Reuse Score；
- Generation Budget；
- Promotion Candidate；
- Negative Prototype Evidence；
- Prototype Registry。

它們是本系列為後續通用化新增的內部架構層。