生成式約束：動態世界結構如何生成而不退化成 AI 亂寫

系列： 動態通用世界狀態機：內部架構與演化規格
篇次： 05 / 07
版本： v0.1
日期： 2026-08-01
性質： 內部技術白皮書／生成治理與驗證規格
基準 Repository： kakon77777-commits/compilableworld-runtime-mvp

摘要

第 4 篇已將動態通用世界狀態機的第一階段定義為：

\boxed{ \text{Requirement-Driven Adaptive Composition} }

也就是先以 Reference World 與 Prototype Library 為錨點，完成 Retrieval、Compatibility Analysis、Composition、Adaptation 與 Gap Detection，最後才允許 AI 對真正無法覆蓋的剩餘部分進行：

G_{\mathrm{residual}}

但「只生成 Residual」本身仍不夠。

即使 AI 只生成世界的 $5\%$ ，如果這 $5\%$ 恰好涉及：

新 authority path；
新 state write scope；
新 transition；
新 event contract；
新 structural mutation；
新 external actuator；

它仍可能破壞整個世界的可重播性、安全邊界與因果一致性。

因此，本篇正式建立 Generative Constraint Stack。任何由 AI 生成、適配或補全的世界結構，都必須依序通過：

\boxed{ C_{\mathrm{syntax}} \cap C_{\mathrm{schema}} \cap C_{\mathrm{semantic}} \cap C_{\mathrm{authority}} \cap C_{\mathrm{behavioral}} }

並額外接受：

provenance / lineage；
risk tier；
generated diff review；
shadow validation；
regression gate；
promotion；
rollback。

本篇最重要的主張是：

\boxed{ \text{Generated} \neq \text{Executable} }

以及：

\boxed{ \text{Executable} \neq \text{Promoted to Live World} }

AI 可以生成世界結構，但它的輸出首先只是 Candidate World Patch。真正的世界真相仍然只能經過既有 Compiler、Contract、Scenario、Regression、Authority 與 Promotion 流程後才成立。

1. 現況：CompilableWorld 已有很多「約束元件」，但尚未形成完整生成治理鏈

目前 Repository 已經存在的關鍵設計包括：

Authoring Layer、Compiled Package、Runtime State 分離；
AI Adapter／UI 不得直接修改 StateStore；
Module 只能提出 StateDelta + EventIR；
Kernel 強制 Module write scope；
FunctionIR 只允許受限純數值 AST；
ScenarioIR 必須走正常 Runtime 管線；
Studio import／mapping／preview 不能繞過 Compiler；
MCP read-only adapter 不得取得 StateStore 直接寫入權；
Snapshot restore 在碰 live Runtime 前先驗證 replacement structures；
event visibility 採 fail-closed；
Quest ambiguous transition 在編譯期拒絕；
Core schema 已外化並由 Compiler 補跨檔案語意驗證。

這些不是零散規則。

它們其實已經共同指向一個思想：

\boxed{ \text{World Change Must Cross Explicit Contracts} }

本篇不重新發明這些邊界，而是把它們組成未來 AI-generated world structure 的正式治理鏈。

2. 第一條總原則：生成結果不是世界真相

未來 AI 可能生成：

Authoring data；
mapping；
FunctionIR；
State schema；
Transition；
Scenario；
ModuleContract；
Module implementation；
Projection；
Domain-specific rule。

但無論生成內容多合理，都必須先被定義為：

\boxed{ P_g= \text{Generated Candidate Patch} }

而不是：

P_g= \text{World Truth}

正確流程：

\boxed{ \text{AI Output} \rightarrow \text{Candidate Patch} \rightarrow \text{Validation Pipeline} \rightarrow \text{Candidate Package} \rightarrow \text{Promotion} }

因此必須保留：

\boxed{ W_{\mathrm{author}} \neq W_{\mathrm{compiled}} \neq W_{\mathrm{runtime}} }

AI 只能先改第一層，不能直接跳到第三層。

3. 第二條總原則：Generated 不等於 Executable

假設 AI 生成：

module:
  id: smartdoor
  writes:
    - door.locked

語法正確，不代表：

door.locked 是合法 state；
Module 有權寫；
event payload 完整；
transition 不衝突；
Scenario 能通過；
舊 Reference World 不受影響。

所以：

\boxed{ \text{Syntactic Validity} \ll \text{World Validity} }

生成式約束必須至少分五層。

4. Constraint Layer 1：Syntax Constraint

第一層：

C_{\mathrm{syntax}}

只回答：

生成內容是否能被 parser 正確讀取？

例如：

JSON 可 parse；
YAML subset 合法；
CSV column 格式正確；
FunctionIR AST node 格式正確；
expression token 合法。

這是最低門檻。

可以表示：

C_{\mathrm{syntax}}(x) \in \{0,1\}

若：

C_{\mathrm{syntax}}=0

直接拒絕。

不進後續階段。

5. Constraint Layer 2：Schema Constraint

第二層：

C_{\mathrm{schema}}

回答：

欄位、型別、版本、必要值與 contract 是否符合正式 Schema？

現有 repo 已有多個 versioned schemas，例如：

FunctionIR；
ScenarioIR；
Runtime Package；
rooms / exits；
entities / items；
Studio World IR；
Studio mapping。

Schema Constraint 應檢查：

required field；
enum；
type；
version；
unknown field policy；
ID format；
array/cardinality；
schema $id。

所以：

\boxed{ C_{\mathrm{schema}} > C_{\mathrm{syntax}} }

一份 JSON 可以合法 parse，但仍可能違反 schema。

6. Constraint Layer 3：Semantic Constraint

第三層：

C_{\mathrm{semantic}}

這是 Compiler 真正重要的地方。

它回答：

結構雖然符合 Schema，但是否在世界語義上自洽？

例如：

entity reference 是否存在；
item owner 是否合法；
room graph 是否可達；
Quest transition 是否指向合法 state；
同一 transition 是否 ambiguous；
terminal state 是否又被轉移；
Event payload 是否符合已知規則；
Function input 是否完整；
Prototype dependency 是否滿足；
namespace 是否衝突。

因此：

\boxed{ \text{Schema-valid} \not\Rightarrow \text{Semantically valid} }

這也是為什麼未來不能只讓 AI 產 JSON Schema 便自稱「生成已受約束」。

7. Semantic Constraint 應該能回答「世界是否自洽」

未來可以把 Semantic Constraint 拆成：

C_{\mathrm{semantic}} = C_{\mathrm{reference}} \cap C_{\mathrm{graph}} \cap C_{\mathrm{transition}} \cap C_{\mathrm{dependency}} \cap C_{\mathrm{invariant}}

例如：

Reference

所有 ID reference 存在。

Graph

World / task / dependency graph 合法。

Transition

不存在未定義或不允許 transition。

Dependency

Prototype / Module 所需能力已提供。

Invariant

沒有破壞核心世界不變量。

8. Constraint Layer 4：Authority Constraint

第四層：

C_{\mathrm{authority}}

這是最不能被 AI 相似度取代的一層。

它回答：

即使行為語義合理，這個生成結構有沒有資格讀、寫、執行、訂閱、控制？

目前 ModuleContract 已經具備：

actions；
events；
read；
write；
layer；
version。

而 Kernel 已經實際 enforce write scope。

未來生成治理至少需要：

C_{\mathrm{authority}} = C_{\mathrm{read}} \cap C_{\mathrm{write}} \cap C_{\mathrm{action}} \cap C_{\mathrm{event}} \cap C_{\mathrm{structure}}

其中最後一個：

C_{\mathrm{structure}}

代表誰可以新增／修改：

Schema；
ModuleContract；
authority policy；
Prototype；
Event contract。

這個權限應明顯高於普通 State mutation。

9. State Mutation Authority 與 Structure Mutation Authority 必須徹底分離

目前一般 Runtime 行為：

\text{Action} \rightarrow \text{StateDelta}

屬於：

\boxed{ A_{\mathrm{state}} }

但新增：

combat.status_effects 這種新 write path；
新 Module；
新 event type；
新 Schema；

屬於：

\boxed{ A_{\mathrm{structure}} }

必須滿足：

A_{\mathrm{structure}} > A_{\mathrm{state}}

這裡的 $>$ 表示更高治理門檻，不是數值大小。

Repository 中已有一個很好的真實案例：新增 generic status-effect duration 時，CombatModule 原本沒有宣告 combat.status_effects write scope，導致整個 atomic commit 被 PermissionDenied 擋下。最後修正 ModuleContract 並補 live Kernel regression test。

這個 bug 反而證明：

新增世界能力時，Contract 同步更新不是文件工作，而是實際執行必要條件。

10. Constraint Layer 5：Behavioral Constraint

第五層：

C_{\mathrm{behavioral}}

回答：

即使結構合法、語義自洽、權限正確，實際跑起來是否真的符合預期？

這就是 ScenarioIR 與 Regression 的角色。

基本形式：

\text{Given} \rightarrow \text{When} \rightarrow \text{Then}

未來生成任何 transition／module／prototype，都至少應附帶：

happy path；
denial path；
boundary path；
conflict path。

所以 AI 不應只生成：

new transition

而應同時生成：

new transition
+ scenario evidence

即：

\boxed{ \text{Generated Behavior} \Rightarrow \text{Generated Test Obligation} }

11. 五層 Constraint Stack

完整表示：

\boxed{ C(x) = C_{\mathrm{syntax}} \cap C_{\mathrm{schema}} \cap C_{\mathrm{semantic}} \cap C_{\mathrm{authority}} \cap C_{\mathrm{behavioral}} }

只有：

C(x)=1

才表示：

這個 candidate patch 通過第一階段執行資格。

但仍不代表可以直接進 live world。

12. 通過 Constraint 仍不等於可以 Promotion

因為還有一個更大的問題：

它是否破壞既有世界？

所以需要：

\boxed{ C_{\mathrm{regression}} }

如果新 Patch 通過自己新增的 Scenario，但讓：

combat；
quest；
snapshot；
replay；
MCP projection；
Studio import；

其中任何已驗證能力失敗，仍然不能 Promote。

因此真正 gate 是：

\boxed{ G_{\mathrm{candidate}} = C(x) \cap C_{\mathrm{regression}} }

13. Reference World 的真正價值在這裡出現

第 2 篇將 Game Runtime 定義為：

\text{Regression Anchor}

在生成治理裡，它的作用正式落地。

任何 Generalization / Prototype / Generated Patch 都要回答：

舊 Reference World 還能不能跑？

因此：

\text{New Feature} \not\Rightarrow \text{Old World Broken}

應成為 Promotion gate。

14. Risk Tier：不是所有生成內容都值得同樣審查

本篇正式提出生成風險分級。

Tier 0：Projection-only

例如：

新 View；
UI field；
read-only report；
diagnostic projection。

不能改 State。

風險最低。

Tier 1：Pure Computation

例如：

新 FunctionIR；
derived score；
deterministic projection formula。

仍不能直接改 State。

Tier 2：Scenario / Authoring Content

例如：

新 dialogue；
新 narrative；
新 non-authoritative content；
新 Scenario。

可以影響內容，但不改 Core authority。

Tier 3：State / Transition Extension

例如：

新 state path；
新 transition；
新 status；
新 task state。

需要更嚴格 Scenario 與 regression。

Tier 4：Module / Event / Authority Extension

例如：

新 Module；
新 write scope；
新 action；
新 Event contract；
新 read scope；
新 authority rule。

屬高風險。

Tier 5：External Effect / Structural Runtime Mutation

例如：

真實設備控制；
live structure mutation；
自動安裝新 Module；
修改 security policy；
runtime schema hot migration。

最高風險。

15. Risk Tier 應影響 Promotion Policy

可以定義：

\operatorname{ReviewDepth}(x) = f(\operatorname{RiskTier}(x))

例如：

Tier 0–1

可允許：

automatic validation；
automatic promotion under strict constraints。

Tier 2–3

需要：

generated diff；
Scenario；
regression；
possibly reviewer approval。

Tier 4

需要：

explicit authority review；
contract review；
sandbox；
human/independent-agent approval。

Tier 5

預設：

\boxed{ \text{No Automatic Live Promotion} }

16. Generated Diff Review 必須是第一級資產

AI 不應只輸出「新的完整檔案」。

最好輸出：

\boxed{ \Delta W_{\mathrm{author}} }

即 Authoring Diff。

Diff 至少要標記：

added
removed
changed
derived_from
risk_tier
new_authority
new_state_paths
new_events
new_transitions
new_dependencies
generated_fields

這讓 reviewer 不需要重新讀完整世界。

17. Diff 應分「語法 Diff」與「語義 Diff」

普通 Git diff 只能看到：

+ writes: combat.status_effects

但世界狀態 Runtime 更需要：

Semantic Diff:
  module combat.core
  gains write authority:
    combat.status_effects

  new state path:
    owner=character
    namespace=combat
    key=status_effects

  behavior impact:
    status can now persist across exchanges

所以未來 Studio 很適合提供：

\boxed{ \text{Semantic World Diff} }

而不是只顯示文字行差異。

18. AI 生成 Patch 必須附「理由」，但理由不是權威

可以要求：

rationale:
  reused:
    - prototype.status.timed_effect
  residual:
    - combat-specific refresh policy
  new_authority:
    - combat.status_effects
  scenarios_added:
    - shield_expiry
    - haste_decay

這有助於 review。

但：

\boxed{ \text{AI Rationale} \neq \text{Validation Evidence} }

真正 evidence 仍然是：

Compiler；
Scenario；
tests；
trace；
regression。

19. Shadow Validation：高風險生成應先存在於候選世界

未來可以建立：

live package
candidate package

高風險 Patch 不直接取代 live。

而是：

W_{\mathrm{live}} + \Delta W \rightarrow W_{\mathrm{candidate}}

然後在 Candidate 上跑：

compile；
scenario；
replay；
benchmark；
trace；
migration dry-run。

直到：

\operatorname{Promotable}(W_{\mathrm{candidate}})=1

才切換。

20. Promotion 應該是一個顯式事件，而不是檔案「剛好被改了」

可以定義：

\text{Candidate} \xrightarrow{\text{Promote}} \text{Active}

Promotion metadata 至少包含：

patch ID；
source；
reviewer；
validation report；
risk tier；
target runtime version；
migration ID；
rollback target。

這讓世界結構演化本身也可稽核。

21. Rollback：生成治理沒有 rollback 就不完整

如果新 Candidate 在 live 後出現問題，需要能：

W_{v+1} \rightarrow W_v

但 Rollback 不只是 Git checkout。

因為 Runtime State 可能已經經歷：

S_v \rightarrow S_{v+1}

所以要區分：

Code / Package Rollback

回到舊 Runtime Package。

State Migration Rollback

把新 schema/state 轉回舊格式。

Event Compatibility Rollback

確保新版本 event 不讓舊版本 replay 崩潰。

所以：

\boxed{ \text{Rollback} = \text{Package} + \text{State} + \text{Event Compatibility} }

22. 如果 Rollback 不可能，必須在 Promotion 前明確標記

某些 migration 是 destructive。

例如：

合併 state；
刪除資料；
one-way schema migration。

則 promotion report 應標：

rollback_class:
  reversible
  forward-only
  snapshot-required

高風險 irreversible Patch 不應被 AI 默默升級。

23. AI 生成 Module 的最低要求

若 AI 真的生成新 Module，至少需要同時生成：

ModuleContract
action list
event list
read scope
write scope
dependency
failure semantics
Scenario
trace expectation
risk tier

也就是：

\boxed{ \text{Module Code Alone Is Invalid Output} }

這是非常重要的工程規則。

24. AI 生成 State Schema 的最低要求

新 State path 不只是：

weather.alert_level

還至少需要：

owner type；
namespace owner；
value type；
initial state；
mutation policy；
writer；
reader；
snapshot policy；
migration policy；
projection visibility。

所以：

\boxed{ \text{State Field} = \text{Value} + \text{Governance} }

25. AI 生成 Event 的最低要求

新 Event type 至少要有：

E_c= ( type, source, payload\ schema, visibility, authority, version )

並回答：

誰產生；
誰訂閱；
是否可公開；
是否可 replay；
是否可作為 transition trigger；
payload version 如何 migration。

不能只是：

emit "something_happened"

26. AI 生成 Authority 的最低要求

新增權限是最高風險類別之一。

任何 authority extension 都要回答：

\operatorname{Grant} ( subject, action, resource, scope, condition, expiry )

並且預設：

\boxed{ \text{Fail Closed} }

如果新 role／capability 無法判斷，應拒絕，而不是「大概可以」。

27. Constraint Failure 必須是可解釋的

生成系統不能只回：

INVALID

應回：

schema:
  missing: event.version

semantic:
  unknown_ref: entity.door.front

authority:
  write_not_allowed:
    module: room.light
    path: door.locked

behavioral:
  failed_scenario:
    visitor_must_not_unlock

這使 AI 可以：

\text{Generate} \rightarrow \text{Fail} \rightarrow \text{Repair}

而不是整份重生。

28. Repair 應優先局部修補，不重新生成整個 Patch

本篇延伸 Minimum Novelty Principle：

\boxed{ \text{Minimum Repair Principle} }

如果只有：

missing write scope

不要重新生成整個 Module。

只產：

\Delta P_{\mathrm{repair}}

並保留原 lineage。

29. 生成式驗證應保存 Failure Corpus

每次 AI 生成被拒絕，都可以留下：

candidate
failure reason
repair
final outcome

形成：

\boxed{ \text{Generation Failure Corpus} }

這會讓 Reference World 不只知道：

遊戲曾經怎麼壞。

還知道：

AI 曾經怎麼把世界結構寫壞。

未來 Prototype Retrieval／Composer 可以用它避免重犯。

30. Auto-Promotion 應該極度保守

未來即使希望更自治，也應滿足：

\text{AutoPromote}(x)=1

只有在：

Risk(x)\le\theta_r

且：

C(x)=1

且：

C_{\mathrm{regression}}=1

且：

Rollback(x)=\text{safe}

且：

AuthorityDelta(x)=0

這類條件下。

因此自動 Promotion 最初只適合：

projection；
pure function；
non-authoritative content；

而不是新的 authority 或 physical effect。

31. 生成治理與 MSSP 的關係

MSSP 的核心價值之一是：

世界能力以 Module 邊界被組合。

生成治理的目的不是取消 MSSP。

而是確保 AI 新增 Module 時：

\boxed{ \text{Generated Module} \subset \text{Governed MSSP Runtime} }

也就是模型可以寫得非常複雜，但仍然被：

ModuleContract；
Kernel；
Event；
StateDelta；
Scenario；

包住。

32. 生成治理與 RDR 的關係

RDR 未來可能讓大量 AI-generated rule 更有效地：

dispatch；
cache；
break cycle；
trace。

但 RDR 不能取代：

\text{Generation Validation}

RDR 回答：

已存在的規則如何有效執行？

本篇回答：

哪些生成規則有資格成為「已存在的規則」？

所以：

\boxed{ \text{Validation} \rightarrow \text{Promotion} \rightarrow \text{Dispatch Optimization} }

順序不能倒過來。

33. 生成約束的第一版不需要複雜 AI Judge

v0.1 完全可以先用：

schema validator；
compiler；
module contract validator；
scenario；
regression；
static risk classifier；
semantic diff report。

AI Judge 可以作為額外 reviewer，但不能是唯一 gate。

這使第一版非常務實。

34. 建議的 Candidate Patch Manifest

未來可以概念上輸出：

candidate_patch:
  id: patch.smartroom.001
  generated_by: agent_x
  based_on:
    - reference.game.v0.5
    - prototype.timed_state.v0.2

  risk_tier: 4

  changes:
    state:
      add:
        - occupancy.present
    actions:
      add:
        - unlock_remote
    authority:
      add:
        - homeowner.remote_unlock

  lineage:
    reused:
      - prototype.action.authorized_write
    adapted:
      - prototype.door.lockable
    generated:
      - physical_ack_placeholder

  validation:
    syntax: pass
    schema: pass
    semantic: pass
    authority: pending
    behavioral: pending
    regression: pending

  rollback:
    class: reversible

這類 manifest 可以成為 Studio／Agent Review 的核心輸出。

35. 完整生成治理管線

本篇最後將流程正式收斂為：

\boxed{ \begin{aligned} &\text{RequirementIR}\\ \rightarrow\;&\text{Prototype Composition}\\ \rightarrow\;&\text{Residual Spec}\\ \rightarrow\;&\text{Generated Candidate Patch}\\ \rightarrow\;&C_{\mathrm{syntax}}\\ \rightarrow\;&C_{\mathrm{schema}}\\ \rightarrow\;&C_{\mathrm{semantic}}\\ \rightarrow\;&C_{\mathrm{authority}}\\ \rightarrow\;&C_{\mathrm{behavioral}}\\ \rightarrow\;&C_{\mathrm{regression}}\\ \rightarrow\;&\text{Risk Review}\\ \rightarrow\;&\text{Candidate Package}\\ \rightarrow\;&\text{Promotion}\\ \rightarrow\;&\text{Live Runtime} \end{aligned} }

其中任一 Gate 失敗：

\rightarrow \text{Reject / Repair / Recompose}

而不是：

\rightarrow \text{Force Deploy}

36. 核心不變量

G-1：Generated 不等於 Executable

生成輸出只能先成為 Candidate。

G-2：Executable 不等於 Live

通過 Compiler 仍需要 Regression / Promotion。

G-3：AI 不得直接寫 StateStore

既有 invariant 長期保留。

G-4：Structure Mutation Authority 高於 State Mutation Authority

新增 Schema／Module／Authority 必須更嚴格。

G-5：每個 Generated Behavior 都有 Test Obligation

不能只有 code。

G-6：Authority Extension 預設 Fail Closed

不確定就拒絕。

G-7：所有生成必須保存 lineage

可以追溯 Reference／Prototype／AI Generated 部分。

G-8：高風險變更預設不可 Auto-Promote

尤其 Tier 4–5。

37. 禁止事項

禁止 A：Schema-valid 就直接執行

Schema 只是第二層。

禁止 B：AI Rationale 當 Evidence

模型解釋不是測試。

禁止 C：用 AI Judge 取代 Compiler

LLM reviewer 只能輔助。

禁止 D：生成 Module 不生成 Contract

無 Contract 的 Module 視為 invalid artifact。

禁止 E：生成 State 不定義 Governance

新 state field 必須知道誰能寫、怎麼 migration。

禁止 F：高風險 Patch 自動 Live Promotion

尤其 authority／external effect。

禁止 G：修一個錯誤時重生整個世界

優先 Minimum Repair。

38. 尚未實作

本篇以下結構目前都屬於未來提案：

Generated Candidate Patch contract；
risk tier metadata；
semantic diff；
shadow candidate package；
promotion service；
rollback manifest；
generation failure corpus；
auto-promotion policy；
structure mutation authority；
generated test obligation enforcement。

目前 repo 已經提供的是：

未來可以拿來實作這條治理管線的 Compiler、Schema、ModuleContract、Scenario、Snapshot、Replay 與 Regression 基底。

39. 驗證條件

未來要稱「生成式約束 v0.1」成立，至少要驗證：

V-1

故意生成 syntax-invalid patch，第一層拒絕。

V-2

syntax-valid 但 schema-invalid patch，第二層拒絕。

V-3

schema-valid 但 reference 不存在／transition ambiguous，Semantic Gate 拒絕。

V-4

semantic-valid 但 write scope 不合法，Authority Gate 拒絕。

V-5

前四層合法但 Scenario 行為不符，Behavioral Gate 拒絕。

V-6

新 Scenario 全過但破壞 Reference regression，不允許 Promotion。

V-7

Tier 4 authority change 不能 Auto-Promote。

V-8

被拒絕 patch 能產生結構化 failure report。

V-9

局部 repair 不丟失 lineage。

V-10

Rollback metadata 在 Promotion 前已存在。

40. 本篇結論

動態生成不是問題。

沒有治理邊界的動態生成才是問題。

因此未來 Dynamic General World-State Runtime 不應把 AI 定義為：

可以直接改世界的作者。

更準確的定位是：

\boxed{ \text{AI} = \text{Candidate Structure Generator} + \text{Adapter} + \text{Repairer} }

而世界真正接受變化的方式仍然是：

\boxed{ \text{Contract} + \text{Compiler} + \text{Authority} + \text{Scenario} + \text{Regression} + \text{Promotion} }

整個生成治理可以用一句話總結：

\boxed{ \text{Generate Freely Inside a Strict Promotion Boundary.} }