原型錨定式自適應組合：Reuse → Adapt → Residual Generation

系列： 動態通用世界狀態機：內部架構與演化規格
篇次： 04 / 07
版本： v0.1
日期： 2026-08-01
性質： 內部技術白皮書／自適應組合規格
基準 Repository： kakon77777-commits/compilableworld-runtime-mvp

摘要

前三篇已經完成三個基礎判斷：

CompilableWorld 現有 Runtime 是 Game World-State Runtime Prototype，而非尚未存在的「通用完成版」；
Game Runtime 應保留為 Executable Reference World，而不是通用化後被淘汰；
未來世界狀態語義應拆成 Universal Core、Parameterized Prototype 與 Domain-Specific Semantics 三層。

本篇開始處理真正的「動態」問題：

當一個新的世界需求進來時，系統究竟要如何先找既有原型、判斷可重用程度、組合多個 Prototype、處理衝突，再只對剩餘缺口進行受約束生成？

核心原則是：

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

但本篇進一步修正一個容易過度簡化的概念：不能只依一個模糊的 reuse_score 決定「抄不抄」。真正的適配判斷至少需要同時比較：

structural fit；
semantic fit；
authority fit；
temporal fit；
evidence quality；
conflict risk；
adaptation cost。

因此 Prototype Matching 應是多維判斷，而不是單一相似度。

本篇提出一條未來自適應組合流程：

\boxed{ \text{RequirementIR} \rightarrow \text{Prototype Retrieval} \rightarrow \text{Compatibility Analysis} \rightarrow \text{Composition Plan} \rightarrow \text{Adaptation Map} \rightarrow \text{Residual Spec} \rightarrow \text{Generated Patch} \rightarrow \text{Compiler / Scenario / Regression} \rightarrow \text{Candidate World Package} }

其中 AI 可以參與檢索、語義對齊、adapter 生成與 residual synthesis，但不能直接把生成結果裝入 live StateStore。真正的世界修改仍必須回到 CompilableWorld 已建立的 Compiler、Contract、Scenario 與 Runtime 邊界。

1. 現況：目前 Repository 已有「驗證端」，但還沒有「自適應組合端」

現有 CompilableWorld 已經具備很多組合引擎未來需要依賴的下游能力：

Authoring Layer；
Runtime Package；
Schema contracts；
Studio World IR；
Studio mapping；
FunctionIR；
ScenarioIR；
ModuleContract；
Compiler semantic validation；
ActionIR；
StateDelta；
EventIR；
Snapshot / Replay；
Runtime diagnostics。

2026-07-15 的最新兩個主要提交仍維持這條方向：一個整合 Studio authoring contracts、AMK、snapshot restore 與 regression；另一個加入 read-only MCP、world projection、event visibility 與外部存取邊界。

因此目前系統已經比較擅長回答：

「這個世界定義是否合法、能不能編譯、能不能執行？」

但還不會回答：

「新需求應該優先重用哪一批既有世界結構？」

所以本篇提出的 Prototype Retrieval／Composition／Residual Generation 全部屬於後續架構提案，不是目前 repo 已實作能力。

2. 自適應組合的輸入不能只是 Prompt

如果輸入只有：

「幫我建立一個智慧房間世界。」

模型很容易直接從語言想像生成整套 architecture。

這正是本系列要避免的。

未來應先把自然語言需求正規化為：

R_q= ( E, S, A, V, T, P, C, N )

其中：

$E$ ：需要哪些 entity / entity category；
$S$ ：需要哪些 state capability；
$A$ ：需要哪些 actions；
$V$ ：需要哪些 events；
$T$ ：time / scheduling requirement；
$P$ ：authority / permission requirement；
$C$ ：semantic / operational constraints；
$N$ ：non-functional constraints，例如 latency、offline、safety。

這裡暫稱：

\boxed{ \text{RequirementIR} }

它的作用不是取代 World IR，而是成為：

Prototype Retrieval 與 Composition 的需求側中介表示。

3. RequirementIR 的第一個原則：描述能力，不預設實作

例如新需求：

智慧房間內有人進入時開燈，夜間離開三分鐘後關燈；門鎖只有屋主可遠端解鎖。

不要一開始寫：

use MQTT module
use FSM class X
use table Y

而應正規化成：

entities:
  - person
  - room
  - light
  - door

capabilities:
  - occupancy
  - timed_transition
  - binary_device_state
  - remote_action
  - authorization

constraints:
  - owner_only_remote_unlock
  - delayed_light_off

這樣 Retrieval 才有機會從既有 Prototype 找：

location / occupancy；
timed state；
authority；
lockable door；
action precondition。

4. Prototype Retrieval：找的是結構，不只是名稱

假設 Prototype Library 有：

prototype.location.occupancy
prototype.door.lockable
prototype.task.transition
prototype.status.timed_effect
prototype.action.authorized_write
prototype.resource.depletion

新 Requirement 寫的是：

presence
lock
delayed shutoff
owner authorization

若只做 keyword matching，很容易漏掉。

因此 Retrieval 至少需要兩條路。

4.1 Symbolic Retrieval

根據：

capability tags；
required state shape；
action signature；
event signature；
authority template；
dependency；
semantic layer；

直接查 registry。

4.2 Semantic Retrieval

模型或 embedding 可以協助理解：

timed_effect

與：

delayed occupancy timeout

可能有結構相似性。

但 AI 只負責：

\text{Candidate Discovery}

不是直接決定：

\text{Safe Reuse}

所以：

\boxed{ \text{Semantic Similarity} \neq \text{Compatibility} }

5. Matching 不應只有一個 Reuse Score

前一篇曾用：

R(P_i,D)

表示 reuse score。

本篇把它展開。

對 Prototype $P_i$ 與 Requirement $R_q$ ，應建立：

M_i= ( m_s, m_\sigma, m_a, m_t, m_e, m_c )

其中：

$m_s$ ：semantic fit；
$m_\sigma$ ：structural / schema fit；
$m_a$ ：authority fit；
$m_t$ ：temporal fit；
$m_e$ ：evidence strength；
$m_c$ ：composition compatibility。

這些維度不應簡單平均。

某些是 hard gate。

例如：

m_a=0

代表 authority model 完全不相容，即使語義很像也不能直接 reuse。

所以真正決策更像：

\operatorname{ReuseClass}(P_i,R_q) = F(M_i,\Gamma)

其中 $\Gamma$ 是 hard constraints。

6. 四級適配分類

經過 Compatibility Analysis 後，每個候選 Prototype 可分類為四級。

L0：Direct Reuse

不改變核心 contract 與 invariants 即可使用。

例如：

event identity；
versioned state；
scheduler ordering；
causation chain；
snapshot metadata。

形式上：

P_i' = P_i

L1：Parameterized Adaptation

結構與 invariants 可直接保留，只替換參數。

例如：

game.location.room
→ smartroom.occupancy.zone

可以寫成：

P_i' = P_i(\theta_D)

其中 $\theta_D$ 是 Domain parameter set。

L2：Structural Adaptation

只能保留：

transition skeleton；
authority pattern；
scenario skeleton；
trace shape；

但 state schema 或 semantics 需要重構。

例如：

quest dependency
→ maintenance workflow dependency

此時：

P_i' = \operatorname{Transform}(P_i,\mu_D)

其中 $\mu_D$ 是 mapping / transformation。

L3：Residual Novelty

既有 Prototype 無法合理承載。

例如從 Game 走向 Physical World 時第一次需要：

sensor provenance；
uncertain observation；
external acknowledgement；
reconciliation。

這才產生：

G_{\mathrm{residual}}

7. Composition Plan：不是選一個 Prototype，而是組一張圖

真實需求通常需要多個 Prototype。

例如智慧門可能需要：

P_{\mathrm{lifecycle}} \oplus P_{\mathrm{location}} \oplus P_{\mathrm{authority}} \oplus P_{\mathrm{timed}}

因此 Composition 應建成圖：

G_P=(V_P,E_P)

其中：

$V_P$ ：selected prototypes；
$E_P$ ：dependency / conflict / precedence relations。

edge type 至少可以有：

requires
provides
conflicts
overrides
observes
writes
emits
subscribes

這比簡單 list 更適合世界狀態機。

8. Composition 前必須做 Namespace Collision 檢查

如果：

prototype.lifecycle

想寫：

status.current

而：

prototype.device_availability

也想寫：

status.current

可能產生模糊 ownership。

因此在產生 Runtime Package 之前，要檢查：

W(P_i)\cap W(P_j)

若交集非空，必須判斷：

是否允許共同寫；
是否有明確 owner；
是否需要 merge function；
是否需要 precedence；
是否應直接拒絕。

未來應優先：

\boxed{ \text{Compile-Time Conflict Detection} }

而不是讓兩個 Module 在 live Runtime 裡搶 state。

9. Action Collision 也必須檢查

現有 WorldRuntime.module_for() 已要求：

同一 verb 必須恰好有一個 Module provider。

這本身就是非常好的 Composition invariant。

所以 Prototype Composition 必須保留：

\left| \operatorname{Provider}(verb) \right|=1

除非未來明確設計：

router action；
namespaced verb；
dispatch policy。

否則兩個 Prototype 都宣告：

open

不能靠來源順序決定誰贏。

10. Event Collision 與 Event Semantics

Event 名稱相同，也不代表語義相同。

例如：

state.changed

如果不同 Prototype payload 不一致，會形成隱性錯誤。

所以 Prototype 應描述：

E_i= ( type, payload\ schema, visibility, authority, version )

Composition 必須檢查：

event type duplicate；
payload compatibility；
event ownership；
subscriber expectation；
visibility policy。

現有 EventIR 已有 version，未來可以利用它建立更正式的 Event Contract。

11. Authority Compatibility 應該是 Hard Gate

如果某個 Prototype 原本允許：

player → unlock door

而新 Domain 是：

remote guest → physical front door

即使 action 結構完全一樣，也不能因為 reuse score 高就直接套用。

所以：

\boxed{ \text{Authority Fit} }

必須是硬限制之一。

可以定義：

\operatorname{CompatibleAuthority}(P,R_q) \in \{0,1\}

若為 0：

\text{Direct Reuse} \rightarrow \text{Forbidden}

只能進入重新適配或客製。

12. Temporal Compatibility 不能忽略

Game 中：

3 exchanges

與智慧房間：

180 seconds

都可以叫「duration」。

但兩者的 clock semantics 不同。

所以 Prototype 要聲明：

clock_domain
duration_unit
pause_policy
resume_policy
expiry_policy

否則 timed_status 很容易被錯誤通用化。

本篇因此新增一條判斷：

\boxed{ \text{Temporal Similarity} \neq \text{Temporal Compatibility} }

13. Gap Detection：真正要生成的是覆蓋不到的集合

若 Requirement capability set 為：

C_R

已選 Prototype 覆蓋：

C_P = \bigcup_i C(P_i)

則 Residual：

\boxed{ C_G = C_R-C_P }

但還要扣除：

被 adaptation 補足的；
被 policy 解決的；
被 existing domain module 提供的。

最後才得到：

G_{\mathrm{residual}}

這才是 AI 可以生成的主要範圍。

14. Generation Budget 應加入風險，而不只是覆蓋率

前一篇提出：

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

本篇保留這個直覺，但加入 risk weight。

更合理可以寫成：

B_g = \sum_{c\in C_G} w(c)

其中：

projection gap：低權重；
pure function gap：較低；
new state schema：中；
new transition：中高；
new authority path：高；
external physical effect：非常高。

所以同樣只有 $10\%$ residual：

少一個顯示 projection

和：

少一條 physical actuator authority path

完全不是同樣的 generation risk。

15. Minimum Novelty Principle

本篇正式提出：

\boxed{ \text{Minimum Novelty Principle} }

在滿足 Requirement 的前提下，Composition Planner 應盡量最小化：

J_{\mathrm{novel}} = \alpha N_{\mathrm{schema}} + \beta N_{\mathrm{module}} + \gamma N_{\mathrm{transition}} + \delta N_{\mathrm{authority}} + \epsilon N_{\mathrm{event}}

也就是不要因為 AI 能生成，就創造：

更多 namespace；
更多 module；
更多 transition；
更多 authority；
更多 event type。

越少的新語義面積，越容易驗證。

16. Generated Output 不應是 Live Runtime Mutation

這是整篇最重要的安全邊界之一。

AI 產出的結果應該是：

\boxed{ \text{Proposed World Patch} }

例如：

new Authoring diff；
Prototype parameter set；
mapping；
FunctionIR；
ScenarioIR；
Module contract proposal。

而不是：

\text{AI} \rightarrow \text{StateStore.commit()}

也不是：

\text{AI} \rightarrow \text{直接修改 live module code}

因此完整流程：

\boxed{ \text{Generated Patch} \rightarrow \text{Compiler} \rightarrow \text{Validation} \rightarrow \text{Scenario} \rightarrow \text{Regression} \rightarrow \text{Candidate Package} }

17. 「動態生成」需要分三種，不應混為一談

未來提到 Dynamic World State Runtime 時，至少要分：

Mode A：Authoring-Time Dynamic Composition

AI／Composer 動態組合新世界，但完成後仍：

\text{Compile} \rightarrow \text{Deploy}

這應是第一階段主要模式。

Mode B：Staged Runtime Extension

Runtime 運行中產生新候選內容，但先進：

shadow package
candidate module
sandbox scenario

驗證後才切換。

這是較後期能力。

Mode C：Live Structural Mutation

直接在 live world 中新增：

schema；
module；
transition；
authority contract。

這是最高風險模式。

第一批 General Runtime 不應把它當預設能力。

所以：

\boxed{ A \rightarrow B \rightarrow C }

應該是成熟順序。

18. Runtime State 的動態變化與 Runtime Structure 的動態生成必須分開

現在 Game Runtime 已允許：

state change；
dynamic player entity；
scheduler；
action；
quest transition。

這些是：

\boxed{ \text{Dynamic State} }

但未來自適應組合談的是：

新 Prototype；
新 Schema；
新 Module；
新 Contract。

這是：

\boxed{ \text{Dynamic Structure} }

兩者不能混用同一權限。

可以表示：

\text{State Mutation Authority} \neq \text{Structure Mutation Authority}

這一條應成為未來 General Runtime 的核心治理原則。

19. AI 應該是 Planner / Adapter，不是唯一 Matching Oracle

Prototype Retrieval 可以使用 LLM。

但最終 Composition 不應只相信：

「我覺得這兩個東西很像。」

應該混合：

\boxed{ \text{Symbolic Contract Matching} + \text{Schema Comparison} + \text{Scenario Evidence} + \text{Semantic Model Assistance} }

也就是：

模型幫忙找到候選，Contract 幫忙決定能不能用。

20. Provenance：每一個 Adaptation 都要知道自己從哪裡來

未來生成的新 World IR 或 Module 應保存：

derived_from:
  - prototype.task.transition@0.2
  - reference_world.game@0.5

adaptation:
  mapping: ...
  generated_fields: ...
  overridden_invariants: ...

可以抽象成：

L(P') = ( source, version, mapping, generated, validated )

這就是 Prototype Lineage。

沒有 lineage，未來出 bug 時會不知道：

是原 Prototype 有問題，還是 adaptation 時引入的？

21. Example：智慧房間如何「抄」Game Reference World

假設需求：

人進入房間後自動開燈；離開三分鐘後關燈；屋主可以遠端解鎖門；訪客不能。

先抽 RequirementIR。

21.1 可直接重用

Universal Core：

Entity；
State version；
ActionIR；
EventIR；
Scheduler；
ModuleContract；
Snapshot；
Projection。

21.2 可參數化原型

從 Game Reference 抽：

Location / Occupancy

room membership
→ physical room occupancy

Timed Status

effect duration
→ occupancy timeout

Lockable Door

locked/unlocked
→ physical lock state

Authorized Action

actor authority
→ homeowner / visitor role

21.3 結構類比但不能直接抄

Game 中：

unlock action commits state

Physical world 不行。

因為：

\text{Command Sent} \neq \text{Door Actually Unlocked}

這一段就形成：

G_{\mathrm{residual}}

需要未來 Open-World Layer 的：

effect dispatch；
acknowledgement；
observation；
reconciliation。

所以不是：

遊戲 Door Prototype 沒用。

而是：

它覆蓋了狀態、authority、transition 的一部分；只剩 physical effect semantics 需要新生。

這正是 Residual Generation 的意義。

22. Example：Robot Task 也不是從零開始

假設：

家用機器人接到「把水拿來」任務。

可以從 Game Reference 重用／適配：

Entity；
location；
item ownership/custody；
task transition；
scheduler；
resource；
authority；
action precondition。

真正新增的可能是：

perception uncertainty；
navigation confidence；
actuator acknowledgement；
physical grasp verification。

所以：

\boxed{ \text{Robot Domain} \neq \text{Game Domain} }

但：

\boxed{ \text{Robot Domain} \not\Rightarrow \text{From Scratch} }

23. Composition Failure Modes

本篇列出第一批需要防止的失敗模式。

F-1：Semantic Overfit

因為名字相似就硬套 Prototype。

F-2：Namespace Collision

多 Prototype 搶同一 state path。

F-3：Verb Collision

兩個 Module 提供同一 action。

F-4：Event Drift

同 event type 但 payload semantics 不同。

F-5：Authority Escalation

Adaptation 後意外擴大權限。

F-6：Temporal Mismatch

把 turn／tick／wall-clock 混在一起。

F-7：Hidden Novelty

表面 reuse，實際上大量行為已被偷偷生成。

F-8：Prototype Cascade

為了解決一個需求自動拉入大量 Prototype，最後變成巨大依賴圖。

F-9：False Generalization

為了提高 reuse 強迫 Domain 改變自己的真實語義。

24. Composition Planner 應能選擇「不要重用」

這點非常重要。

最好的 Adaptation Planner 不一定永遠選 reuse。

若：

C_{\mathrm{adapt}} > C_{\mathrm{custom}}

或者 adaptation 會造成：

semantic distortion；
authority confusion；
excessive dependencies；
hard-to-test behavior；

那應該選：

\boxed{ \text{Custom Domain Module} }

因此：

「可以抄的就抄」的前提是「抄了仍然是對的」。

25. 與 RDR 的關係

Prototype Composition 與 RDR 不應混成同一層。

Prototype Composition 主要處理：

\text{世界結構如何被建立}

RDR 未來主要處理：

\text{大量規則在 Runtime 中如何有效派發}

因此：

\boxed{ \text{Composition Time} \neq \text{Dispatch Time} }

當 AI 生成的宏／中／微規則量真的膨脹後，RDR 的 memoization、reified dispatch、SCC diagnostics 才會進入 Runtime execution optimization。

26. 第一版 Composer 不需要「全自動」

如果未來真的實作 v0.1，我會建議先做：

RequirementIR
→ retrieve candidates
→ produce Composition Report
→ human/agent review
→ generate mapping draft
→ compile

先不要做：

Prompt
→ auto-compose
→ auto-deploy

原因是目前 Game World-State Runtime v0.2 本身都還沒有完成。

所以 Composer 第一版應是：

\boxed{ \text{Decision Support Tool} }

而不是 autonomous deployment system。

27. 建議的 Composition Report

未來可輸出：

requirement_id: smart_room.v1

selected:
  - prototype.location.occupancy
  - prototype.status.timed_effect
  - prototype.action.authorized_write

direct_reuse:
  - event.identity
  - state.version

adapt:
  - from: prototype.door.lockable
    mapping: ...

residual:
  - physical_effect_ack
  - sensor_observation

conflicts: []

risk:
  authority: high
  state: medium
  projection: low

generation_budget:
  weighted_residual: 0.31

這比直接生成 code 更適合作為內部審查資產。

28. 核心不變量

A-1：Reuse 不得跳過 Validation

\text{Reused} \neq \text{Automatically Trusted}

A-2：Semantic Similarity 不等於 Compatibility

AI 相似度只能產生候選。

A-3：Structure Mutation Authority 高於 State Mutation Authority

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

A-4：Residual Generation 必須最小化新語義面積

遵守 Minimum Novelty Principle。

A-5：所有生成結果必須可追溯

Prototype lineage 不可丟失。

A-6：Composer 不能成為第二個 Runtime

它只能輸出 authoring / mapping / candidate package，不可直接擁有 live StateStore mutation path。

29. 尚未實作

本篇以下內容全部屬於未來設計：

RequirementIR；
Prototype Registry；
Prototype Retrieval；
multidimensional compatibility analysis；
Composition Graph；
Generation Budget；
Minimum Novelty objective；
Prototype Lineage；
Composition Report；
staged runtime extension；
structural mutation authority。

目前 repo 仍主要提供：

可供這些能力未來驗證的 Compiler／Runtime／Scenario／Contract 基底。

30. 驗證條件

未來若實作第一版自適應組合器，至少應通過：

V-1

同一 Requirement 在固定 Prototype Registry 下可產生可重現的 candidate set。

V-2

存在 hard authority conflict 時不得進 Direct Reuse。

V-3

Prototype namespace / verb / event collision 能在 compile 前被偵測。

V-4

Residual Spec 能明確區分「已覆蓋」與「真正新需求」。

V-5

Generated Patch 不直接修改 live StateStore。

V-6

所有 adaptation 保留 lineage。

V-7

Candidate Package 必須通過原 Reference World regression 與新 Domain Scenario。

V-8

當 Custom Module 比 adaptation 更乾淨時，Planner 能合法選擇不 reuse。

31. 本篇結論

動態通用世界狀態機的「動態」不應被理解為：

AI 隨時在 live Runtime 裡自由生成新規則。

第一階段更合理的定義是：

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

也就是根據新世界需求，動態決定：

哪些 Core 直接重用；
哪些 Prototype 參數化；
哪些結構需要轉換；
哪些衝突必須解決；
哪些剩餘部分才允許新生成。

完整流程收斂為：

\boxed{ \text{RequirementIR} \rightarrow \text{Retrieve} \rightarrow \text{Match} \rightarrow \text{Compose} \rightarrow \text{Adapt} \rightarrow \text{Gap Detect} \rightarrow \text{Residual Generate} \rightarrow \text{Validate} }

其中最重要的兩條原則是：

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

與：

\boxed{ \text{Minimum Novelty Principle} }

這使 AI 的生成能力不再被取消，而是從「世界的自由作者」改成：

Reference-Anchored Adapter、Planner 與 Residual Synthesizer。

下一篇將進一步把「Validate」展開：

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

下一篇會正式定義：

Syntax Constraint；
Schema Constraint；
Semantic Constraint；
Authority Constraint；
Behavioral Constraint；
Risk Tier；
Generated Diff Review；
Scenario Gate；
Promotion / Rollback；

也就是回答：

即使只生成 Residual，我們還要如何保證 AI 生成出來的世界結構不能直接越過系統邊界？

Appendix A：Repository Grounding

本篇重新檢查 2026-08-01 時該 repository 的最近提交；最新仍為：

72334d7881749c78d323684e3ddbbc2b8aab86da — read-only MCP / world projection / event visibility；
c9a33185ac7df5863e76995b0ebb097578e6be7e — Studio runtime authoring contracts / AMK / atomic snapshot restore / regression。

因此本篇沒有假設七月中之後已經出現新的 Prototype Composer 實作。

本篇沿用 repo 已存在的幾項關鍵 invariant：

同 verb 不應存在模糊多 provider；
Module write scope 由 Kernel 強制；
AI / UI 不直接修改 StateStore；
Authoring / Compiled / Runtime 分離；
Scenario 走正常 ActionIR / Kernel / EventIR；
Studio mapping / preview 不直接改 Runtime State。

本篇新增的 RequirementIR、Prototype Retrieval、Composition Graph、Residual Spec 與 Generation Budget 均屬後續架構提案。

04_原型錨定式自適應組合_Reuse_Adapt_Residual_Generation