title

原生 MOD 生態：穩定 API、版本相容與 AI 輔助遷移

english_title

Native Mod Ecosystems: Stable APIs, Version Compatibility, and AI-Assisted Migration

series

AI 原生互動企業論

series_en

AI-Native Interactive Enterprise

series_id

ANIE

paper

05

part

第二部：玩家與外部開發者共創

author

Neo.K

institution

一言諾科技有限公司（EveMissLab）

research_assistance

GPT-6（資料核對、理論建模、反例分析、工程契約、研究協議與原始碼驗證）

version

v0.1

date

2026-10-16

language

zh-TW

status

Public Working Paper / Conceptual and Methodological Study / Not Peer-Reviewed

canonical_source

UTF-8 Markdown

math_delimiters

$...$ and $$...$$ only

research_status

Conceptual model, technical proposal and test protocols; no production deployment or controlled experiment claimed

external_sources_checked

2026-10-16

related_papers

ANIE-00 — 從產品黑盒到 AI 原生互動企業 · ANIE-01 — 從 EA 到持續交付 · ANIE-02 — 季度單機產品制 · ANIE-03 — 可繼承的遊戲產品 · ANIE-04 — 玩家—開發者相交域 · ANIE-06 — 商業遊戲也可以 PR（後續研究） · ANIE-07 — 跨平台產品公開資訊樞紐（後續研究） · ANIE-09 — 公開決策帳本（後續研究）

原生 MOD 生態：穩定 API、版本相容與 AI 輔助遷移

Native Mod Ecosystems: Stable APIs, Version Compatibility, and AI-Assisted Migration

《AI 原生互動企業論》ANIE-05｜第二部第二篇｜工作論文 v0.1
作者：Neo.K｜機構：一言諾科技有限公司（EveMissLab）
研究協作：GPT-6｜日期：2026-10-16

機構： 一言諾科技有限公司（EveMissLab）
日期： 2026-10-16
版本： v0.1

摘要

商業單機遊戲的 MOD（modification）長期面臨一種矛盾：官方更新提高作品品質，卻可能破壞第三方擴充；玩家已投入的存檔、規則調整、語言包、內容包與多年社群創作，會因隱藏 API、反射掛鉤、資料格式變更、載入順序或遊戲引擎更新而失去效用。遊戲公司若單純要求 MOD 作者自行跟進更新，便把官方產品演化的一部分成本外部化；然而若反過來要求官方永遠保持任意非官方掛鉤可用，也可能使遊戲難以修正錯誤、重構系統或維持安全。本研究拒絕兩種極端，轉向「把 MOD 從事後容忍的修改行為，提升為產品初始架構中可預先定義、可驗證、可演化的擴充關係」。

本文提出「原生 MOD 生態」（Native Mod Ecosystem，NME）、「穩定擴充契約」（Stable Extension Contract，SEC）、「多軸相容關係」（Multi-Axis Compatibility Relation，MACR）與「AI 輔助 MOD 遷移閉環」（AI-Assisted Mod Migration Closure，AAMC）。核心主張是：MOD 可持續維護性並不是單一遊戲版本號、資源載入器或自動改寫工具的屬性，而是公開擴充介面、資料語義、依賴解析、世界狀態、存檔格式、資安信任、發行渠道、法律授權與社群決策共同作用的結果。遊戲核心可以保有私有商業授權，仍能提供具有明確版本、權限與測試工具的外部 SDK；同時，官方應盡可能先使用這些對外契約來開發自家的資料驅動模組，避免官方與玩家實際使用兩套互不相容的擴充路徑。

2026 年 1 月，Valve 公布 Steam Workshop 的新版版本控制能力；官方文件描述，開發者可維護有序的遊戲分支，MOD 作者可標示其版本支援的遊戲分支區間，玩家在特定版本上可取得相應 MOD 版本。[E01][E02] 此能力實際改善發行與版本選擇，卻不構成「載入成功就是行為正確」的保證。Godot 官方則提供 PCK／ZIP 資源包、執行期載入與增量修補，並明確提醒任意程式碼、檔案覆蓋、載入順序及不可信來源的安全風險。[E03] 本研究利用這些現有技術作為可實作基礎，但不將其功能宣傳成遊戲引擎已內建完整的安全 MOD 平台。

對 AI 的定位亦採取嚴格限制：AI 可擷取合約差異、理解授權允許範圍內的 MOD 程式、生成候選補丁、編排遷移計畫、補寫回歸測試與協助更新文件；但模型聲稱已相容、靜態分析通過、遊戲可啟動、內容未報錯、真人實際接受是互不等價的證據層。涉及刪除世界物件、覆寫存檔、提升腳本權限或改變遊戲經濟的修改，必須接受更嚴格的證據與授權門檻。

全文將建立相容性分層、不變量、版本多維向量、資料格式與 SDK 契約、MOD 依賴圖、存檔遷移流程、AI 遷移管線、供應鏈風險控制、公開更新制度及經濟與社群治理指標。另提出十二項可反駁假說、對照組實驗、失敗案例、分階段 MVP 與可供後續專案使用的 Manifest／Schema／CI 規格草案。本篇屬概念與方法論工作論文，不宣稱 EveMissLab 已完成正式 MOD SDK、Steam Workshop 生產整合或跨版本遷移實測。既有的 SEDB-GAME × ModWorld 研究提供遊戲語義與 MOD 生成背景；本文聚焦官方遊戲與第三方創作的長期相容契約，而非重新提出 MOD 生成引擎。[I05]

關鍵詞： 原生 MOD、生態維護、穩定 API、SDK、語義相容、資料格式、版本分支、存檔遷移、AI Agent、可驗證修補、依賴圖、插件安全、Steam Workshop、Godot、社群協作、商業遊戲、可繼承產品。

0．問題重定義：為什麼官方更新會成為 MOD 作者的災難？

0.1 從玩家創作到產品維護共同體

MOD 的外部價值不只是讓遊戲新增衣服、立繪、翻譯或任務。對於複雜的模擬、策略與角色扮演遊戲，玩家可能透過 MOD 建立新的建築系統、戰鬥規則、經濟模組、AI 行為、地圖算法與使用者介面。當這些內容累積，玩家實際遊玩的世界便不再等於「官方原版」，而是官方資產、更新、DLC、配置、MOD 及個別存檔的組合狀態。這一點已在 SEDB-GAME × ModWorld 的「有效遊戲世界」模型中有明確前置研究。[I05]

但是許多擴充仰賴並未承諾穩定的檔名、內部類別、遊戲物件生命週期、序列化路徑或非公開函數。官方更新只要改動一個依賴點，外部創作者就必須重新排查。修正成本高時，作者可能停止維護；若玩家又缺乏版本保留選項，就可能在遊戲本身持續改進時失去原本的遊玩世界。

此處至少有三個不同的產品：

1. 官方遊戲本體： 公司承諾支援的基本功能與核心內容。
2. 外部 MOD 產品： 社群創作者自主提供、具有不同權利與品質條件的擴充。
3. 組合後的玩家遊戲世界： 在特定遊戲版本、MOD 集合、載入順序、設定與存檔共同作用下形成的有效執行狀態。

前兩者可各自通過測試，但第三者仍可能失敗。這是原生 MOD 生態必須處理的首個因果缺口。

0.2 初始架構決策會決定未來的維護債務

若遊戲在製作後期才加入 MOD 功能，內部物件可能早已彼此緊密耦合。此時才公開外掛入口，往往只是在已有龐大耦合面的系統上增加一層臨時轉接；所謂 MOD SDK 可能僅是將部分不穩定內部結構交給玩家直接使用。

如果從 MVP 就先分出資料表、事件契約、狀態查詢與受控動作介面，遊戲即使只有少量可玩內容，也已擁有可以逐步擴充的技術邊界。這不代表第一天必須完成 Workshop、視覺編輯器或全面腳本權限；先建立邊界，後完善工具，是本篇對短週期產品的實際建議。

0.3 主要命題與對立命題

主命題 P0： 對持續更新且具有實際 MOD 需求的商業遊戲，若在初始開發期建立明確的擴充契約、版本適配、相容性測試與安全的資料／程式隔離，則相較於直接依賴未公開內部結構的 MOD 生態，可在不必公開商業核心原始碼的前提下，降低跨版本重工率與玩家有效世界損失風險。

反命題 C0： 若穩定 API 的維護成本超過節省的外部相容成本，或公開介面限制核心重構、惡化效能、安全與遊戲完整性；又或 AI 遷移引入新的難以偵測語義錯誤，使跨版本失敗率上升，則應收斂 NME 的適用情境。沒有明確 MOD 需求的極小型作品，可能只需要資料包或不需要外部腳本擴充。

0.4 本篇與相鄰研究的分工

• ANIE-03 討論原開發者離開後，遊戲產品如何由合法受權的接手者繼續維護。本篇研究第三方 MOD 與官方核心持續相容的條件。
• ANIE-04 討論玩家與開發者的需求相交域；本篇使「由玩家自己實作另一種解法」成為具有技術與治理邊界的選項。
• ANIE-06 將深入外部 PR、收費合作、MOD 正式收錄、權利與報酬；本篇只建立 MOD 在技術上可以被驗證並合法使用的最低條件。
• ANIE-07／09 將研究外部資訊平台與公開決策帳本；本篇只定義它們應揭露的相容性、修復、遷移與版本事件。
• SEDB-GAME × ModWorld 處理跨遊戲語義、有效世界與 MOD 生成；本篇的問題是官方如何在產品變動時仍履行對外擴充契約。[I05]

1．既有研究、產業機制與本研究的新增範圍

1.1 Godot 提供資源包，卻不替遊戲設計擴充治理

Godot 官方的「Exporting packs, patches, and mods」文件確認：PCK／ZIP 可載入腳本、場景、著色器、模型、音訊及其他資產，也可在不公開整個商業遊戲原始碼的條件下提供 MOD；但遊戲開發者必須自行規範外部內容的檔案結構與所需介面。[E03] Godot 的 ProjectSettings.load_resource_pack() 可載入外部資源包；若路徑與既有資源相同，預設可能覆蓋原資源，因此載入順序與命名空間特別重要。官方也明白指出下載惡意 MOD 或被替換的 PCK 具有安全風險。[E03]

不能推論： 選用 Godot 就自然得到 MOD 沙盒、保證版本相容、完整圖形化 MOD 工具或自動遷移功能。這些仍是遊戲自身的架構與產品責任。

1.2 Steam Workshop 的 2026 年版本控制是重要基礎設施

Valve 於 2026 年 1 月 8 日宣布 Workshop 新版 MOD 版本控制功能。Steamworks 官方文件記載，搭配 Steamworks SDK 1.60 相關能力，遊戲可建立有序的舊版本與測試分支，工作坊物件可為不同 MOD 版本指定支援的遊戲版本區間；玩家留在舊遊戲版本時，系統可選擇相對應的 MOD 內容。[E01][E02]

這解決一個重要的發行選擇問題，但仍不表示系統已知道 MOD 是否真的能完成任務。例如版本相容區間由作者或上傳器設定，可能尚未充分測試；兩個 MOD 都各自支援同一分支，也不代表兩者合用時沒有衝突。若未指定區間，Steam 文件指出系統會假定該版本支援所有遊戲分支；這是發布上的預設假設，而不是科學上的相容證明。[E02]

因此 NME 必須建立比「可下載」更高階的執行、語義、存檔及使用者接受證據。

1.3 SemVer 提供穩定 API 的溝通慣例

Semantic Versioning 2.0.0 以 MAJOR.MINOR.PATCH 區分破壞相容、向後相容新增與向後相容修補，其基礎前提是軟體先定義了公開 API。[E04] 這對 MOD SDK 特別重要：沒有明確的外部介面，就無法一致判斷何謂破壞性變更。

不過 SemVer 是版本宣告慣例，不是自動化證明系統；更不能把遊戲本體版本、世界存檔格式、Steam 分支、SDK 契約和 MOD 發行版全部視為相同的版本號。

1.4 JSON Schema 等格式可構成可機器檢查的契約

JSON Schema Draft 2020-12 提供 JSON 結構與驗證的規範，可用於模組 Manifest、資料資產及欄位要求。[E05] 但資料符合 Schema 只意味著形式上通過相關約束，不意味著世界規則必然正確。例如傷害倍率是有效數值，不代表它不會讓戰鬥平衡崩潰。

因此本文至少區分：結構合法性、跨版本相容性、遊戲語義有效性、使用者體驗可接受性四個不同層級。

1.5 MOD 創作涉及著作權與社群制度，而非只有技術

關於玩家對遊戲 MOD 的權利，2021 年《Computer Law & Security Review》的研究已從玩家創作與著作權的張力討論 MOD 社群，指出廠商對不同種類變更的容忍與支持，受到法律以外的社會經濟因素影響。[E06] 本文不主張特定國家對所有 MOD 擁有同一種法律結論；也不以「MOD 作者免費發布」推論公司取得商業收錄權。

1.6 安全、供應鏈與資料來源證據已是成熟議題

NIST SP 800-218 的 SSDF 描述可融入軟體生命週期的安全開發實務。[E07] OpenSSF SLSA 進一步提供建置來源（provenance）等供應鏈完整性設計。[E08] OWASP 的 CI/CD 安全指引亦提醒外部插件與整合會擴大攻擊面，須進行審查、限制權限與持續管理。[E09] NME 可以借用此類安全治理原則，卻不把商業遊戲安裝 MOD 的場景，誤稱為等同於企業 CI/CD 環境。

1.7 需要明確區分既有技術與本篇提案

故 NME 的新意是整合與可驗證的營運制度，不是聲稱發明資源包、套件管理、版本控制或 MOD 本身。

2．核心術語與原生 MOD 生態的定義

2.1 原生 MOD 生態（NME）

定義 1。 原生 MOD 生態是一套在官方產品的設計、發行、更新和維護過程中，將外部擴充視為可預期產品使用情境的技術及制度安排。其最低要求包含：

1. 有清楚描述且可版本化的外部擴充入口；
2. 有可以獨立創作、載入、停用與移除 MOD 的程序；
3. 有版本支援宣告與基本驗證方法；
4. 有處理相依、衝突與載入順序的規則；
5. 有存檔與世界狀態風險管理；
6. 有可說明的安全、授權及外部責任界線；
7. 有官方更新與社群作者事前溝通、事後修復的渠道。

這個定義不要求每一款遊戲都開放任意程式碼執行，也不要求遊戲本體完全開源。

2.2 穩定擴充契約（SEC）

定義 2。 SEC 是官方在指定支援期限、SDK 版本、功能範圍、權限及平台條件下，對外提供的可觀察介面與相容性承諾。

它不只是一份 API 清單，至少應明確說明：輸入／輸出、事件時機、錯誤回報、資料格式、行為不變量、權限要求、棄用期限、測試方式、已知限制、何時不承諾相容，以及契約違反的申報程序。

原則： 「穩定」表示變更具有受控的契約與遷移政策，不等於所有 API 永不變動。

2.3 擴充權限與創作權並非同一層

• 技術擴充權限： 插件能夠查詢哪些資料、註冊哪些事件、要求哪些世界變更。
• 智慧財產授權： MOD 作者是否能合法使用官方素材、第三方模型或其他創作。
• 公司整合權限： 官方可否把 MOD 納入正式遊戲、DLC 或其他商業產品。
• 玩家選擇權： 玩家可否停用某個 MOD、保持舊版本、撤回某次存檔遷移。

四者有關但不相等。即使某 MOD 通過 CI，也不能因此獲得正式收錄、銷售或重新授權的法律資格。

2.4 三種典型 MOD 信任等級

以上是本研究建議的風險分類，並非 Godot 或 Valve 官方的原生分級。若引擎腳本無可靠安全邊界，T1 就不能僅因被稱為腳本而宣稱受限；必須有真正的執行隔離與能力審查。

2.5 MOD 生態不能只用「可安裝 MOD 數量」衡量

MOD 數量增加，可能代表創作成功，也可能代表官方缺乏基礎便利功能、版本碎裂、低品質重複包或大量無人維護內容。因此本研究重點衡量的是跨版本有效可用的 MOD 及其玩家世界保存能力，不是把 Workshop 物件數視為唯一績效。

3．版本不是一條線：多軸相容關係（MACR）

3.1 版本向量

傳統使用者經常只看到「遊戲 v1.5」「MOD v2.1」兩個標籤，但實際相容性至少依賴：

其中：

• $g$：官方遊戲版本／實際執行 Build；
• $a$：對外 SDK／API 契約版本；
• $d$：遊戲資料 Schema 版本；
• $s$：存檔與世界狀態格式版本；
• $m$：MOD 套件本身版本；
• $e$：引擎與 Runtime 版本；
• $p$：平台與載入路徑；
• $c$：外部 MOD 組合、配置與依賴集合。

定義 3。 MACR 是判斷某組 $V$ 是否能在給定環境、任務集合與安全政策下，維持指定的載入、執行、世界語義與存檔正確性的關係。

$T$ 表示測試任務集合， $\Gamma$ 表示安全與權利限制。採三值邏輯的理由是：未測試的相容性應保持 UNKNOWN，不能默認 PASS。

3.2 相容不等於一個布林值

本文區分至少六層相容：

L0 或 L1 PASS 不足以聲稱 L4 或 L5 PASS。同樣，一個 MOD 在全新遊戲存檔通過測試，也不足以證明舊存檔相容。

3.3 版本相容具有方向性

由舊遊戲升級新版、由新 MOD 回退舊版、由舊存檔轉新版，是不同方向的操作：

除非系統明確提供雙向且無資訊損失的轉換。對存檔 Schema 而言，某些欄位一旦合併、刪除或重新解釋，回退可能根本無法完整還原。因此需要備份及單獨的不可逆操作警告，而不能只依靠「我可以切換舊版遊戲」的選單。

3.4 支援區間是宣告，不是充分證明

假設一個 MOD 發布為 2.3.0，宣告支援 sdk >=1.3,<2.0、game >=1.4,<1.7；它仍可能在某些 DLC、存檔或其他 MOD 組合下出現衝突。應將「宣告支援區間」與「已實測的 Build 雜湊與案例證據」分別記錄。

本篇不要求枚舉所有理論上的 MOD 組合，因為對幾十個以上 MOD 進行全排列通常不可行；可以改以使用量、衝突結構、關鍵依賴及風險分級選擇測試樣本。

3.5 拆分版本號所增加的複雜性

版本向量並非免費：玩家若被迫讀取八個版本號，反而無法理解。對外 UI 應提供一個可讀摘要：「已驗證相容」「未驗證」「已知不相容」「需要轉換存檔」「請先備份」，詳細向量留在診斷與開發者工具中。

4．穩定擴充契約的最小組合

4.1 七類外部契約

一套可以長期維持的 MOD SDK，至少值得拆成以下七類：

1. 資料契約 Data Contract： 遊戲資料如何描述、擴充、驗證與命名。
2. 查詢契約 Query Contract： MOD 可以讀取哪些世界資訊，哪些欄位可保證穩定。
3. 事件契約 Event Contract： 哪些狀態轉換會通知 MOD、順序與重入規則為何。
4. 動作契約 Action Contract： MOD 如何提出變更，以及由誰檢查條件與權限。
5. 狀態契約 Persistence Contract： MOD 專有資料如何存儲、版本化、清除和遷移。
6. 資源契約 Asset Contract： 圖像、音效、模型、UI 版面與載入順序如何處理。
7. 能力契約 Capability Contract： 對檔案、網路、運算時間與世界改動的授權及限制。

這些契約可以用不同技術實現，不應全部硬塞進單一腳本基底類別。尤其對高度數據驅動的單機作品，先把 Data／Event／Persistence 做好，可能比急著公開原生腳本擴充更有價值。

4.2 事件與動作必須分離

MOD 可以觀察到 OnTurnStarted，不代表它能任意改寫整個回合狀態。事件介面宜提供不變量保護的資料快照或受限查詢；狀態寫入則使用可驗證命令，例如 ProposeItemGrant、RequestSceneTransition 或 ProposeWorldRuleChange，由核心統一檢查。

這能降低「外掛直接寫資料結構」造成世界狀態破壞的可能，但不能保證所有受控命令組合都安全。核心仍需要交易式提交、配額、重放與長期測試。

4.3 契約同時描述負向承諾

穩定 API 不應只寫「本介面保證什麼」，也應寫「本介面不保證什麼」：

• 是否保證單一事件只觸發一次？
• 是否保證相同事件在同一個版本中順序一致？
• 是否允許 MOD 在回呼中遞迴請求狀態變更？
• 是否保證數值計算跨平台相同？
• 是否保證存檔中永久保留某種引用？
• 是否允許同時掛載多個覆蓋同一實體的擴充？

不寫出這些邊界，玩家就可能把當下實作細節誤認為官方承諾。

4.4 公開契約與私有實作可以共存

設計一個公開 SDK，不等於需要公布尋路演算法、生成世界模型、原始 NPC 決策系統或公司的內部 Agent 工具。公司可以公開 WorldReadModel、資料 Schema、事件合約及經審查的狀態變更命令，核心內部仍可持續重構。對外保證的是接口語義，不是所有內部實作。

然而保留核心私有也不是逃避授權義務。若使用第三方開源元件、引擎或 SDK，仍必須遵守其具體授權；不應把「商業核心私有」等同「所有外部資料與二次創作自動屬於公司」。

4.5 公開前先驗證 SDK 本身

至少提供：

• 一個可安裝的空白 MOD 範例；
• 一個資料型 MOD 範例；
• 一個受控事件型 MOD 範例；
• 至少兩個不同 SDK 小版本的相容性回歸；
• 清楚的錯誤輸出與文件連結；
• 第三方獨立作者在沒有內部知識的情況下完成一個小功能的測試。

若 SDK 只有公司自己的工程師知道如何使用，便不能僅因公開了函數名稱就稱為成熟擴充介面。

5．原生擴充的架構選擇：先分離，再授權

5.1 建議參考結構

Commercial Game Runtime                  [Private]
  ├─ World Simulation / Scheduler         [Private]
  ├─ Transaction & Save Core              [Private]
  ├─ Internal Rendering/AI Systems        [Private]
  ├─ Public Extension Gateway             [Stable Boundary]
  │    ├─ Data Contract & Validators      [Documented]
  │    ├─ Query / Event / Action APIs      [Documented]
  │    ├─ Mod Identity & Permissions      [Documented]
  │    ├─ Version Adapter Registry        [Versioned]
  │    └─ Save Extension Registry         [Versioned]
  └─ Mod Runtime
       ├─ T0 Data Packs                   [Constrained Parser]
       ├─ T1 Restricted Rules             [Constrained Runtime if implemented]
       └─ T2 Native Code Plugins          [Elevated Risk / Explicit Consent]

Authoring Toolchain                         [May Be Public]
  ├─ Template / SDK / Validator
  ├─ Package Builder / Manifest Generator
  ├─ Compatibility Test Harness
  ├─ AI Migration Candidate Workspace
  └─ Publishing Adapters: Workshop / Other

此架構為本研究的建議方案，並非聲稱上述工具目前已由 EveMissLab 全部建成。

5.2 「官方自己也使用 SDK」的槓桿

較強的相容策略是：讓部分官方新增角色、地圖、道具與任務，也走同一套 Data Contract 與事件介面。如此官方更新就能與第三方 MOD 共享核心測試。這是「eat your own API」的工程原則。

但核心安全修復與內部不可替代能力無須強迫都從 SDK 走；若對外路徑過度限制核心，仍可能造成不必要的效能與架構負擔。因此應以模組類型選擇公開邊界，而非規定整個核心都必須使用外掛 API。

5.3 三個必要的工程隔離

• 識別隔離： 每個 MOD 有穩定的 ID、命名空間與資料所有者，避免互相覆蓋。
• 執行隔離： 低權限資料與高權限程式碼不能只靠副檔名或 UI 提示就宣稱安全隔離。
• 故障隔離： 單一 MOD 出錯時，應盡可能保存診斷、停用問題模組並讓遊戲回到可恢復狀態，而不是直接破壞主要存檔。

對於 Godot PCK，必須特別注意同路徑資源預設覆蓋行為與腳本可執行問題；若需要真正的權限限制，可能要自行設計受限 DSL、外部隔離程序或其他經驗證的安全邊界，而不是把 PCK 本身當作沙盒。[E03]

5.4 模組身分：內容指紋不等於作者身分

mod_id、版本、檔案摘要、簽章者與官方認證狀態，應分開保存。SHA-256 可以辨識下載檔是否與預期內容一致，但不自動證明該內容由可信作者製作；簽章可以幫助確認簽署者與檔案完整性，亦不自動證明程式無惡意。官方驗證應標示驗證範圍與時間，避免把「受驗證版本」無限外推到未來改版。

6．MOD 套件資料模型與可追溯身分

6.1 Manifest 不可缺席

最低要求可定義為：

identity:           mod_id, mod_version, publisher
compatibility:      sdk, game_builds, data_schema, save_schema
relationships:      requires, optional, conflicts, before, after
capabilities:       requested_permissions, runtime_level
artifacts:          entrypoints, hashes, asset_namespace
provenance:         source_revision, build_id, build_tool
rights:             license_reference, asset_rights, author_contact_route
verification:       test_profile, last_tested_build, evidence_links

這不是規定所有欄位對玩家可見。玩家應看到對安裝決策有用的摘要，工具、官方與作者則可讀取完整機器格式。

6.2 三種身分不得混同

1. mod_id：長期不變的作品或模組身分，適用於依賴與存檔引用。
2. release_id：某次發行物的特定封存版本，可對應摘要與建置紀錄。
3. publisher_identity：上傳者或簽署者的身分，可能與原作者、維護者、權利人不相同。

MOD 作者將維護權交由其他人，不應被系統誤解為 MOD 身分完全消失。反過來，新的維護者也不能僅透過修改 ID 冒認舊作者授權。

6.3 權限需要逐項申請而不是一次全部給予

T0 資料包通常不應請求本機檔案任意存取或網路連線。T1 受限規則亦應按照操作範圍限制權限。T2 程式型 MOD 若進入與遊戲相同的系統程序，則必須誠實標記其可能具有廣泛權限，並視風險設計不同的使用者提示與審查流程。

6.4 遺失原始碼與停維維護者

若原 MOD 只有二進位擴充、缺少合法可取得的原始碼、測試或授權，AI 並不能憑空賦予修改權利。合法的維護選項可能包括：保留舊遊戲分支、官方擴充接口的替代方案、經許可的兼容層、聯繫權利人或新寫可替代功能。對逆向工程的允許範圍應另依適用法律、授權及技術保護措施情形判斷，不能把「AI 能逆向」當成「可以任意再發布」的充分條件。

7．多 MOD 依賴、載入順序與衝突解析

7.1 依賴圖不是清單

對每個模組 $m_i$，定義必需依賴集合 $D_i$ 、可選依賴集合 $O_i$ 、排斥集合 $X_i$ 、載入次序約束 $L_i$。以有向圖：

表示必需依賴、次序約束與衝突關係。若必需依賴與順序約束形成不可解除的有向環，安裝管理器應顯示具體衝突，不應隨機選擇某個載入序列並宣稱成功。

7.2 需支援哪幾種關係？

• requires：必須安裝，且需符合版本條件；
• optional：存在時可啟用增強功能；
• conflicts：與指定 MOD 或版本不能安全並存；
• load_before／load_after：載入順序需求；
• provides：某些介面或資源的替代提供者；
• replaces：明確聲明替代或遷移舊 MOD 的語義；
• patches：為另一 MOD 的指定版本提供相容修補。

requires 不可只靠 MOD 名稱模糊查找，應以穩定 ID 和版本限制解析。兩個 MOD 即使不報錯，若同時改寫同一資產，也可能產生最後覆蓋者勝出的隱藏衝突，應盡可能報告。

7.3 順序解決不了所有語義衝突

假設 A 提高敵人血量兩倍、B 將敵人血量設定為固定值。先 A 後 B 與先 B 後 A 可能產生不同結果；即使兩個修改都是合法操作，也不等於任何一種順序都符合兩名作者或玩家的意圖。

因此衝突分成：

1. 結構衝突：重複 ID、資料欄位型別不符、缺少依賴；
2. 順序衝突：資源覆蓋、事件優先級、初始化時序；
3. 語義衝突：玩法含義、世界規則或狀態因果不相容；
4. 體驗衝突：玩家對合併後的難度、UI、風格與節奏不接受。

只有前兩類常能直接以靜態規則可靠處理；後兩類通常需要動態測試、設計判斷或玩家確認。

7.4 對依賴圖施加可計算限制

可要求每個安裝工作階段記錄 resolved dependency lock，使用確切的 MOD 發行物雜湊，而不是重新啟動時隨意拉取最新版。如果允許自動更新，應先評估是否與既有存檔的相容約束衝突。對於有保存價值的世界模擬，「鎖定舊版組合」本身應是一個正常的產品功能，不該僅被視為玩家不願更新。

8．存檔相容：玩家真正需要保存的不是一個檔案

8.1 存檔、版本與 MOD 組合構成一個狀態承諾

遊戲存檔不是單純把 JSON 或二進位資料成功讀取就算完成。對世界模擬型遊戲，存檔包含角色、人際關係、派系、經濟、任務、事件歷史、地圖結構、回合規則與外部 MOD 定義的實體；某些欄位雖能被載入，卻可能因 MOD 移除或世界規則變動而在下一個回合產生錯誤。

因此將玩家的有效世界定義為：

其中 $B_t$ 為基礎遊戲版本， $D_t$ 為 DLC／官方擴充， $M_t$ 為 MOD 版本集合， $C_t$ 為配置， $S_t$ 為存檔狀態， $O_t$ 為決定性的載入順序及覆蓋關係。 $\Phi$ 是將這些條件解析為可執行世界的建構函數；它是研究記號，並非宣稱所有遊戲實際採用同一執行演算法。

若單獨更換 $B_t$，結果也未必只是官方遊戲更新，因為 $\Phi$ 可能同時改變外部 MOD 與存檔的含義。[I05]

8.2 保存玩家世界的五種不同承諾

1. 位元層保存： 原始存檔與 MOD 安裝包沒有遺失或損毀。
2. 結構層保存： 可被新 Runtime 解析，關鍵欄位映射明確。
3. 實體層保存： 角色、物件、關係、地圖與引用沒有無故消失。
4. 行為層保存： 核心事件、任務前提、經濟關係仍依合理規則演化。
5. 玩家價值保存： 玩家長期遊玩所形成的有效成果與選擇沒有受到不可接受的破壞。

其中前四項可以不同程度自動檢驗；第五項需要玩家判斷，且可能因作品特性而異。例如硬核 Roguelike 的某些永久損失是玩法設計，但「因 MOD 自動更新造成未告知的存檔不可恢復」則是不同事件。

8.3 建議使用 Save Extension Namespace

每個 MOD 的持久化資料應置於明確命名空間，例如 mods.com.example.guild，包含來源 ID、MOD 版本、資料 Schema 版本與最後寫入版本。遊戲核心不應把每一份 MOD 私有資料直接混入未受控的根節點，使未來刪除 MOD 時無法判斷哪些欄位屬於誰。

但命名空間隔離不能孤立跨 MOD 的世界關係。例如 MOD-A 新增某種建築類型，MOD-B 的任務可能引用這棟建築。移除 MOD-A 時，不應單純把其命名空間全刪，還要檢查外部引用與世界條件是否遭到破壞。

8.4 存檔遷移必須是可審核的交易

建議遷移狀態機：

Detect Version Change
  -> Snapshot / Backup
  -> Parse Old Save & Mod Lock
  -> Resolve Required Packages
  -> Build Candidate Migration Plan
  -> Dry-Run in Copy / Isolated Workspace
  -> Validate Structural Invariants
  -> Validate World and Mod Invariants
  -> Present Risks + Obtain Required Consent
  -> Commit as New Save Generation
  -> Verify Post-Commit and Keep Recovery Path

此流程強調：不要在唯一的原始存檔上直接試驗未知遷移。

8.5 不可逆遷移與舊版保留

某些變更沒有合理逆函數。例如「將三個人物關係欄位合併為一個聚合值」可能失去原始資訊。應允許遷移成新存檔世代，同時保留舊存檔及原 MOD Lockfile，直到使用者確認不再需要恢復。

當 $\mu$ 不可逆時，不可聲稱存在安全的 $\mu^{-1}$。所謂回滾應解釋為「恢復備份或舊世代」，而不是假裝所有更新都可無損還原。

Steam Workshop 的版本支援與遊戲分支保留可協助使用者取得舊 MOD 和舊遊戲版本，但前提是遊戲本身真的維護這些分支、作品的授權與下載權仍然有效，並保存必要的 MOD 組合與存檔。[E02]

8.6 MOD 移除並非單純關閉開關

對於只更換 UI 或貼圖的 MOD，停用可能近似即時；對於新增種族、建築、物品、地形、外交系統或任務的 MOD，安全停用則可能涉及：

• 原有物件由誰接管、保留、轉換或封存；
• 既存任務如何終止或改寫；
• 其他 MOD 的引用怎麼處理；
• 是否應提示玩家先載入無該 MOD 的過渡版本；
• 是否只允許在新遊戲中停用。

本研究不強迫所有 MOD 都具備無痛解除安裝能力，而要求未支援解除時必須明確揭露。不可靠的「無痛卸載」宣傳比清楚告知限制更危險。

9．世界語義相容：從能執行到仍是原本想玩的世界

9.1 語義錯誤通常晚於編譯錯誤出現

假設舊版遊戲的 OnDeath 事件於角色生命值歸零後、戰利品分配前發生；新版把同名事件移到結算之後。MOD 可繼續收到事件，也能正常執行，但其「死亡前保存特殊道具」的邏輯已被改寫。這種情況是典型的介面形式相容、事件語義不相容。

為防止此種隱藏破壞，SEC 必須文件化事件前後條件，而不只列出參數名稱。

9.2 跨版本行為相容需要有界定的觀察範圍

對一組特定情境集合 $\mathcal{T}$ 、關鍵觀察量 $\Omega$，可以將語義相容定義為：

當且僅當版本 $i$ 與 $j$ 在約定觀察量及允許偏差範圍內，符合先前明示的契約。這裡的相容是測試範圍內的證據結論，不是聲稱兩個版本在所有可能世界完全等價。

9.3 對世界模擬遊戲，應優先檢查的不變量

• 實體唯一性： 物件 ID 不因多個 MOD 生成重複主鍵；
• 參照完整性： 任務、關係、庫存、建築與派系引用不指向已刪除實體；
• 守恆或限制規則： 遊戲經濟、物資及能量系統有一致性檢查（依遊戲規則，不預設物理守恆）；
• 任務可完成性： 關鍵任務不因事件順序調整而永久無解；
• 回合終止性： 可控的單回合更新時間與防止無限事件遞迴；
• 存檔可延續性： 經過多個回合與重新載入後，關鍵狀態仍存在；
• MOD 停用策略： 知道缺失模組時，應提示保留、退回或部分降級，而非靜默刪除資料。

9.4 不應把「沒有差異」當成唯一正確結果

修改戰鬥、經濟、NPC 決策或世界生成的 MOD，本來就是為了改變行為。合理的測試不是新世界與舊世界逐位元相等，而是變更後仍滿足新規則與既有硬性限制。應將「預期差異」列入測試 Oracle，避免系統把合法玩法變化誤判為錯誤。

9.5 大量世界狀態測試需要場景分層

建議使用三種場景：

1. 微觀固定用例： 角色、道具、事件、戰鬥規則等小型可重現案例。
2. 中觀整合用例： 三至五個 MOD、完整任務鏈、商店與 NPC 關係的長回合模擬。
3. 宏觀壓力用例： 多 MOD、大型地圖、長時間存檔、極端資料量、非典型載入順序。

若以 AI 生成測試世界，應保留種子、生成器版本、測試資料權利與驗證 Oracle；只有 AI 自己判斷自己產生的世界「沒問題」，不足以構成獨立測試。

10．MOD 的安全與信任模型

10.1 讓玩家能創作不等於取消安全責任

MOD 生態的安全風險不止惡意程式碼。即使是合法創作者，也可能因無意的資源消耗、無限事件回呼、未授權資料覆寫或引用錯誤造成遊戲故障。外部下載與更新渠道還可能遭遇帳號盜用、檔案替換、遭污染的依賴套件及釣魚連結。

Godot 官方明確警告，PCK 中可能包含惡意腳本，並說明相同資源路徑的覆蓋問題。[E03] 因此本文不將 load_resource_pack() 當成可信隔離邊界。

10.2 風險分級不只是評分高低

至少分為：

• 資料完整性風險： 導致存檔無法使用或悄悄刪除物件；
• 本機執行風險： 原生程式取得超出玩家預期的檔案、程序或網路權限；
• 內容安全風險： 含惡意內容、非法素材、騷擾或未經同意的私人資料；
• 供應鏈風險： MOD 更新、下載器、依賴包或發布憑證遭入侵；
• 資源耗盡風險： MOD 非惡意但導致 CPU、GPU、記憶體、磁碟或遊戲回合時間失控；
• 生態治理風險： 官方認證被誤認為商業背書，或單一作者被不成比例地賦予市場控制力。

各類風險需要不同測量方法，不能只用單一「可信分數」自動解除所有限制。

10.3 官方下載、安全告知與驗證關係

建議分開標記：

1. origin_verified：能確認檔案與聲稱的發布者或來源關係；
2. integrity_verified：檔案摘要與官方記錄一致；
3. interface_tested：曾通過指定版本的契約測試；
4. behavior_tested：曾通過特定行為或存檔案例；
5. officially_curated：官方有條件地推薦或展示；
6. official_content：公司已取得相關權利並正式整合進產品。

以上六項不會自動相互推出。例如官方推薦一個 MOD，仍不表示其原始碼已接受完整安全審查；下載來源被驗證，也不表示其遊戲設計符合平衡要求。

10.4 有能力界線的隔離與降級

T0 資料包可使用嚴格大小上限、欄位驗證、路徑正規化、圖像音訊處理安全、解壓縮上限及資源配額。T1 規則型 MOD 只有在真正實作受限執行環境時才能稱為沙盒。T2 程式型 MOD 若與遊戲同權限執行，必須明確警示其風險；必要時採用獨立程序與有限 IPC，或限制允許發布此類 MOD 的渠道。

同時避免不實保證：程序隔離可降低部分系統存取風險，但不等於能證明 MOD 不會破壞玩法、存檔或使用者體驗。

10.5 AI 不得因為可以讀取程式而取得部署權限

AI Agent 可以分析一個上傳的 MOD，但不能因此自行把不可信檔案裝入公司的 CI 主機、訪問營運資料、取得簽署金鑰或使用者存檔。理想做法是將候選 MOD 放在權限受限的隔離工作場，只提供必需的資料和驗證工具，任何正式版簽署與發布都通過更高階的授權關卡。[E07][E08][E09]

10.6 安全控制本身應驗證失敗與恢復

只測試「合法 MOD 可以載入」不足以檢驗風險模型。還要測試惡意或不正確的 Manifest、路徑穿越、巨量遞迴解壓、重複 ID、失效簽章、被替換的依賴包、無限事件回呼，以及高權限 MOD 被標記為 T0 的情境。測試應使用受控資料，不發布會對真實玩家或第三方造成危害的可利用細節。

11．AI 輔助 MOD 遷移閉環（AAMC）

11.1 AI 的角色是提出可測試變更，而不是宣稱魔法式相容

當官方從 v1.4 更新 v1.5，舊 MOD 可能因事件名稱、資產位置、資料欄位、技能規則或引擎更新而需要修改。傳統上，MOD 作者須逐個查看變更日誌、搜尋程式碼、修補、執行遊戲並觀察錯誤。

AI 可以降低部分對比、搜尋和候選修補成本，但要區分：生成補丁、補丁編譯、完整行為一致、既有存檔可繼續遊玩、作者授權發布。它們是不同階段。

11.2 提議的八階段遷移流程

AAMC-0  Intake & Authorization
        Identify MOD, source availability, license and allowed scope
AAMC-1  Contract Delta Discovery
        Compare old/new API, events, schemas, assets and permissions
AAMC-2  Dependency & Save Impact Graph
        Map affected modules, cross-mod links and persistent state
AAMC-3  Candidate Migration Plan
        Propose reversible mechanical edits and semantic changes separately
AAMC-4  Isolated Patch Generation
        Generate candidate changes only in a restricted workspace
AAMC-5  Multi-Layer Validation
        Static -> schema -> integration -> scenario -> save -> security
AAMC-6  Maintainer / Authorized Review
        Require appropriate human or delegated authorization
AAMC-7  Release, Evidence & Monitoring
        Publish version-specific artifacts, rollback path and provenance

任何一步有重大不確定性，狀態應轉為 BLOCKED 或 NEEDS_REVIEW，而非在報表中自動標記 PASS。

11.3 AI 遷移工作不可以只有一個成功／失敗旗標

應分別記錄：

• migration_candidate_created：AI 是否生成候選；
• syntactic_validation_passed：是否通過語法及格式檢查；
• contract_validation_passed：是否符合 SEC；
• behavior_tests_passed：是否通過具體遊戲情境；
• save_tests_passed：既有世界是否保留關鍵不變量；
• maintainer_approved：權利與維護者是否授權該修補；
• released：是否真的完成有來源紀錄的發布；
• post_release_incident_free：在限定觀察窗口內是否無重大事故。

這些證據不能任意相互替代。對不存在足夠測試 Oracle 的情境，應標記 UNKNOWN，而不是由 AI 充當自己的唯一驗證者。

11.4 將遷移難度分成六類

「模型越強，所有遷移都可自動完成」並非本研究假設。尤其 M5 是授權問題，不能透過算力直接解除。

11.5 遷移候選應保留原作者意圖

一個 MOD 是為了把原版生存難度提高兩倍，AI 不應只為了通過測試就把修改功能關掉、削弱到與原版相同、刪除玩家角色，或讓原本應觸發的事件不再發生。通過「無崩潰」測試但失去 MOD 主要功能，是一種偽成功。

因此候選方案應列出：保留的功能、不再保留的功能、因新版本而無法直接保留的原因、替代方案、預期行為差異及證據不足之處。當作者不可聯繫時，應避免把 AI 對作者原意的猜測包裝為本人授權。

11.6 AI 遷移的最後一關是正式來源與發布權

AI 提交一個候選 Pull Request，可以是對開源專案的正常協作；但若 MOD 只以禁止再發布的形式提供、或遊戲整合涉及未授權素材，通過測試也不代表公司可以直接代為發布。涉及商業轉正與付費報酬的細節，留待 ANIE-06 處理。本文要求的是遷移權限與產品發布權必須獨立確認。

12．MOD 相容性工程的測試閉環

12.1 由「人工覺得能用」轉向持續的證據矩陣

最低應對每個 MOD 發行版和遊戲分支，產生下列測試證據：

12.2 應對 MOD 組合爆炸

對 $n$ 個可以同時啟用或停用的 MOD，理論上就有 $2^n$ 種基本組合（尚未計算版本、參數、順序、平台與存檔）。不應承諾官方可以完整測試所有組合，而應做：

1. 高使用率組合與高失敗風險組合優先；
2. 強依賴圖與共享資產修改者優先；
3. Pairwise 或其他覆蓋陣列，用有限組合提高交互作用覆蓋；
4. 已知相容清單與已知不相容清單；
5. 未測試組合維持 UNKNOWN 並提供安全開啟方式。

12.3 測試資料不能只來自人工設計的乾淨案例

乾淨的全新存檔最容易通過，也最容易掩蓋真實玩家的複雜狀態。應允許玩家在知情且明確同意的情況下提供匿名化、最小化的故障資料，或由本地診斷工具產生能重現問題的去識別摘要。不能為了改善 MOD 相容而要求玩家上傳所有私人存檔、裝置資訊或帳號資料。

12.4 失敗必須提供可行的操作

測試失敗後，系統不應只顯示 MOD BROKEN。至少應指明：哪個模組及版本、哪個契約或存檔關係、可否停用／降級、是否存在更新版、有無安全舊版分支、是否需要先備份、官方或作者的處理狀態。這些都是讓遊戲社群能自行維護的重要資訊。

13．以季度單機產品制支援 MOD 預先相容

13.1 更新速度越快，越需要對外相容窗口

ANIE-02 提出的 AI 原生季度交付制度若真的使官方版本增速提高，MOD 維護壓力也可能同步增加。換言之，AI 提高官方產能，不必然提高整個玩家生態的淨效益。若核心每週都破壞事件語義，外部作者即使能使用 AI，也可能持續疲於修補。

因此每季應有與技術風險匹配的對外版本流程，而不是每季固定要求所有作品同日推出重大破壞性變更。

13.2 建議版本發行流程

這是研究建議，並非 Steam 平台強制要求的固定週期。Steamworks 已提供可用於測試、回滾與版本相容描述的分支和 Workshop 工具。[E02][E10]

13.3 SDK 棄用不是一句 deprecated

若要廢除一個對外介面，應說明：

• 最後支援的 SDK 版本；
• 替代 API 的具體語義差異；
• 已知受影響的 MOD 類型；
• 官方維持適配層的期限或條件；
• 哪些遊戲分支繼續支援舊契約；
• 進度變更如何通知作者；
• 若破壞性更動被迫提前，如何提供例外與恢復路徑。

這可以是定義於版本或事件的條件承諾，不一定每次都要提供絕對日期；但無法執行或違反約定時應留下公開修正紀錄。[I01][I02]

13.4 優先避免破壞比事後用 AI 修補更經濟

自動遷移是一種救援工具，而不是鼓勵官方隨意改 API 的理由。若一個介面能以低成本保持向後相容，增加適配層常比強迫數千個外部 MOD 重新發布更有利。相反地，如果維持舊介面造成重大安全漏洞、永續維護成本或無法滿足核心產品需求，也不應將舊相容視為絕對不可改變的義務。

13.5 與 Steam／自有網站的分工

Steam 最適合讓玩家購買、管理版本、安裝與訂閱 Workshop 項目；自有網站可以更完整地公布 SDK 文檔、測試證據、跨平台 MOD 對照表、已知衝突、作者協作、遷移指南與政策討論。官方公告負責讓玩家知道應到何處查看資訊；網站不應假稱可取代 Steam 的商店發行與權利機制。[E02][E11]

14．MOD 生態的經濟與治理成本

14.1 原生 MOD 並非免費功能

發布 SDK 後，官方需要維護文檔、版本適配、CI、相容性案例、安全更新、社群爭議、授權審查及外部作者支援。AI 可以分擔其中某些成本，卻可能同時使 MOD 數量與支援需求增加。

可以建立生態總成本的概念模型：

各項均需附有實際人力／機器資源、觀察窗口與計量依據；不能僅因模型產生程式碼速度很快，就把成本設定為零。

14.2 兩種外部成本轉移

失敗形式 A： 官方快速更新，但大量 MOD 作者必須無償跟進，企業把維護負擔轉嫁給創作者。

失敗形式 B： 官方為了避免任何 MOD 壞掉而拒絕修復核心架構，使玩家、公司與未來開發者承擔長期技術債務。

合理制度不是把所有成本單向交給公司或作者，而是透過明確支援範圍、預告、回退、穩定接口、授權合作及必要的報酬機制，降低無效重工並協商責任。[I04]

14.3 生態利益與官方競爭優勢可以並存

開放 MOD SDK 並不必然公開引擎全部演算法、內部美術資產、未上市內容或營運決策。公司保有對正式產品的集成權與品質責任；外部 MOD 作者保有自己的合法創作權與發布選擇。雙方可藉由穩定接口降低創作成本，但彼此仍可以對是否合併、付費、分潤或保持獨立持不同看法。

14.4 授權與商業轉正：本篇的必要邊界

正式收錄玩家 MOD 可能涉及素材、音樂、字體、第三方程式庫、著作財產權、署名、地區授權與再授權。可安裝、可測試、可在 Workshop 公開，不等於公司已取得買斷或商業再利用權。 Steam Workshop 有其投稿與法律協議流程，但每個具體商業整合仍需理解相應條款及實際權利鏈。[E11]

本篇只提出技術建議：Manifest 應保留來源、作者、權利狀態、授權文件參照與第三方素材標註，避免在準備正式收錄時才發現來源不可追溯。具體合約與報酬模型屬 ANIE-06。

14.5 與平台依賴的關係

若全部 MOD 識別、測試資料、作者聯絡與版本歷史只存在單一第三方平台，未來平台規則或 API 調整將增加生態接續風險。但建立自有網站不應變成擅自複製其他平台的私人資料、授權內容或建立未被許可的鏡像。建議維持自己合法產生的 SDK 契約、測試證據、相容性資訊與作者自願提供的連結，並使用平台支持的正式 API 與政策。

15．形式化：在有限資源下管理相容、成本與創作自由

15.1 從單一相容率走向多目標約束

定義在一個季度 $q$，考慮已登錄的 MOD 集合 $\mathcal{M}_q$ 、官方版本集合 $\mathcal{B}_q$ 與情境集合 $\mathcal{T}_q$。一個可觀察的相容性函數為：

$1$ 為指定測試 PASS； $0$ 為 FAIL； $\bot$ 為 UNKNOWN。若缺少測試資料、合法授權或必要依賴，狀態不得自動視為通過。

15.2 以測試人口和測試覆蓋共同構成分母

假設 $\mathcal{E}_q$ 為在當季、指定遊戲分支與目標平台上，有足夠測試資料且具合法處理條件的 MOD－版本－情境三元組。則：

其前提是 $|\mathcal{E}_q|>0$ ；若分母為零應標示 N/A，不能填 100%。此指標是測試樣本內的通過率，不可誇稱為所有玩家 MOD 都相容。

同時公開測試覆蓋率：

其中 $\mathcal{P}_q$ 是預先定義且可計數的優先測試樣本框架。兩者應並列，防止官方只測三個容易成功的 MOD，便宣稱相容率極高。

15.3 玩家權重與少數高風險事件不得互相取消

若以使用量加權，可以衡量已驗證相容在實際安裝配置中的涵蓋比例，但應保護隱私並說明資料來源。有一千名玩家使用的單一常見 MOD 值得關注；同時，只有一名玩家通報「升級會毀掉不可恢復的存檔」也可能需要高優先度。故玩家權重指標不得取代嚴重程度、安全與存檔破壞等硬性風險門檻。

15.4 AI 遷移效率需要測量全部成本

定義每個遷移案例的完整投入成本：

並以相同的驗收準則比較 AI 協助組與基準組。若 AI 生成速度提高 60%，但人工驗證與修正成本翻倍，仍可能使總成本上升。不能以 token 消耗或 PR 件數直接等同維護效率。

15.5 成本不是唯一目標

可用概念上的多目標規劃描述：

在工程預算、資安、權利、可用性及官方產品承諾約束下，尋找非支配方案。此處不是主張所有目標能由一個客觀權重固定加總；不同作品和玩家群體的價值排序可能不同，應保留取捨的公開解釋。

16．衡量 MOD 生態是否真正改善：指標體系

16.1 不能把瀏覽、訂閱、安裝與實際使用混為一談

Workshop 頁面瀏覽量、訂閱數、下載數、實際啟用數、成功載入數，以及同一 MOD 在長期存檔中仍被使用的數量，都有不同意義。訂閱並不保證啟用，啟用也不保證玩家滿意。因此需要從取得、啟動、驗證、持續使用、修復與退出分別設計指標。

16.2 核心指標分層

每項指標均應同時記錄觀察窗、分母、排除條件、資料缺漏、相容性階層與可追溯證據，不能單憑名稱宣稱有跨遊戲可比性。

16.3 破壞率與修復率需要事件定義

例如一次遊戲更新令 400 個 MOD 產生載入錯誤，與更新後令一個關鍵 MOD 引發大量玩家存檔損毀，其嚴重程度不可直接按 MOD 數量排序。對於「官方造成的破壞」，還要區分：

• 違反明確 SEC 的破壞；
• 官方依法或基於安全必須移除的高風險接口；
• MOD 使用未承諾私有 API 所造成的問題；
• MOD 作者自行更新導致的錯誤；
• 多 MOD 組合才會發生的交互作用。

若未做來源歸因，可能不公平地把全部事故算成官方或 MOD 作者單方責任。

16.4 恢復能力比「沒有報錯」更重要

設 $R_i=1$ 當第 $i$ 件被確認的重大存檔或相容事故，在規定時間與可取得的工具／合法資產條件下，玩家能回到可接受的有效遊戲世界；否則 $R_i=0$。則在給定事件集合 $\mathcal{I}$ 下：

若事件集合空白，回復能力不能以本式直接估計。可另設置人工注入的受控破壞測試，避免低事故數導致沒有足夠樣本。

16.5 AI 生成候選補丁的實際貢獻

對於同級難度、相似修改幅度的任務，應測量：

• 候選成功率；
• 端到端合法可發布修復率；
• 新引入的回歸錯誤；
• 存檔／語義損壞；
• 人類審查時間；
• 總額度／算力與經費；
• 初版修補後的再次修補率；
• 作者是否認為核心意圖得到保留。

特別要觀察「AI 可以修好幾乎所有編譯錯誤，但對世界語義錯誤毫無改善」的結果；它仍是有價值的侷限性發現，而不是研究失敗。

17．可重現的實證研究設計

17.1 研究應分開比較「有沒有 SDK」與「有沒有 AI」

為避免把不同改善因素混在一起，建立最基本的四組：

同一功能應設計在兩條可比較的獨立樣本線上，避免同一作者做完 A 組後帶著知識優勢直接做 D 組。受試開發者、任務序列與遊戲 Build 的配置需隨機化或至少平衡；若只能做非隨機案例研究，就須降低因果主張的強度。

17.2 第二因子：破壞類型不同，結果可能反轉

至少交叉比較 M0／M1 這類語法資料變更與 M2／M3／M4 這類語義或存檔變更。AI 或 SDK 可能在機械類任務改善顯著，在語義類沒有改善，甚至因虛假自信而惡化。

可預註冊的主要交互作用是：SEC 提供正式語義上下文後，AI 是否能更容易產生可驗收的候選，而不是只學會針對特定程式碼庫自動補丁。

17.3 難度與參與者能力如何控制

實驗任務應按事前定義的尺度分級，包含變更觸及模組數、依賴深度、世界狀態影響、是否涉及存檔、是否有完整原始碼、是否有測試 Oracle 及所需合法權限。參與者記錄先前 MOD 經驗、程式語言經驗與對該遊戲的理解；不應把新手＋AI 與資深作者無 AI 的結果直接視為相同條件。

17.4 真正的驗收要與補丁生成者分離

若 AI 負責產生候選，同一個模型不能僅藉由自評語句決定已通過全部測試。驗收證據應包含可重現建置、獨立測試、固定存檔、動態情境和不知組別的評估者；在無法盲測的情況下應記錄可能偏誤。

需要區分「模型知道該修什麼」與「模型知道評分者會檢查什麼」。若 AI 專門對測試樣例過度最佳化，可能產生測試通過卻非泛用相容的修補。

17.5 誤報與漏報亦是效能指標

相容性檢查可能產生：

• 誤報：標記不相容，實際可用；
• 漏報：標記相容，實際損壞；
• 不確定：欠缺足夠資訊。

對保存型世界遊戲，漏報的代價可能比誤報高得多，尤其涉及不可逆存檔損失。但若系統永遠把所有 MOD 判成 UNKNOWN，也沒有實用性。應依不同風險選擇警告閾值，並公開錯誤率與覆蓋。

17.6 玩家實測不等於純技術測試

玩家可被邀請比較遷移前後的任務、戰鬥、世界關係與 UI；但玩家原本偏好可能不同，且參與者有自選偏誤。高級 MOD 作者認為完美的改版，不一定適用所有一般玩家。[I04] 因此玩家體驗評估可用分層樣本，且嚴重的存檔缺陷不得因一般玩家未注意就被忽略。

17.7 研究資料、倫理與公開界線

實驗應盡量使用自製的測試 MOD、具有明確授權的示例資料或已取得同意的創作者作品；不應為了研究而散布未授權的逆向檔案、私人存檔或尚未修補的安全漏洞。公開論文可提供匿名化彙總指標、Schema 與方法，但必要的商業機密、第三方著作權與安全細節應保留在適當權限內。[I00][I03]

18．十二項可反駁假說

以下皆為待測研究假說，不是已觀察的因果事實。

H1：原生 SDK 降低一般跨版本重工

在相似更新幅度、MOD 複雜度與支援人力下，使用明確 SEC 的 MOD，其每次官方更新後需要的人工維護工時，低於依賴非公開內部 API 的 MOD。

反例／否證條件： SEC 實作與維持成本顯著增加，且無法降低外部修復工時，或開發者因適配層反而被更多技術債務拖累。

H2：資料型 MOD 的生存率高於直接核心掛鉤

其他因素控制後，T0 資料型 MOD 在常規更新後繼續正常工作的比例高於任意修改內部程式結構的 T2 MOD。

反例： 遊戲將所有內容都綁定在經常改變的資料 Schema，導致 T0 仍大量崩壞；或成熟的 T2 API 反而更穩定。

H3：多軸版本宣告改善問題定位

相較於只有「Game Version」的 MOD，帶有 SDK、資料 Schema、存檔版本與已測 Build 標籤的 MOD，失敗原因定位所需時間較短。

反例： 額外維度增加作者填寫錯誤，讓診斷時間不降反增。

H4：兼容性預告窗口減少官方更新衝擊

在控制更新幅度後，具有預先測試分支與作者回饋窗口的重大更新，其正式版第一週重大相容事故比例，低於沒有窗口的更新。

反例： 創作者很少使用預告分支，或預告構建與正式版差異過大而無實際改善。

H5：有版本鎖定與回退機制者更能保存長期世界

具有遊戲／MOD 版本鎖定、可靠備份與舊分支保留的配置，在受控故障演練中的 PRV 高於只接受最新版本的配置。

反例： 舊版依賴、授權或外部服務消失，使保留分支未能提供實際恢復能力。

H6：AI 對機械式遷移有正向邊際效益

在 M0／M1 任務中，AI 輔助將降低每項合格修補的總時間或成本，且不增加最終驗收後回歸錯誤。

反例： AI 的審查、提示調整、除錯與生成錯誤超過節省的時間。

H7：AI 在語義遷移中的效益有較大不確定性

AI 在 M2～M4 的改進幅度與穩定性低於 M0／M1，且不同模型、作品及情境間差異更大。

反例： 具完整世界模型、契約與驗證環境的 AI 在複雜語義任務中表現同樣穩定，甚至更佳。

H8：SEC 與 AI 可能具有正向交互作用

具有明確事件與狀態契約的 MOD，比起只有原始程式碼的 MOD，更容易被 AI 產生高品質、可解釋的遷移候選。

反例： 模型直接處理原始碼更有效；或契約限制了它可使用的最佳修補方法。

H9：高頻更新可能降低整個生態淨效益

在外部維護者數量和工具成熟度固定時，官方更新頻率增加若伴隨高破壞率，MOD 生態總修復成本可能成長得比新增玩法價值更快。

反例： 更新全為向後相容、小步增量並有高效工具，總成本沒有上升甚至下降。

H10：高風險 MOD 的權限告知可降低部分事故

清楚區分資料型與原生程式型 MOD、提供來源與驗證狀態的安裝提示，可降低玩家在未知條件下啟用高權限 MOD 的比例。

反例： 玩家習慣性忽略警示或有意承擔高風險，且事故並未減少。

H11：相容證據透明有助於提高作者留存

對外公布契約差異、已知破壞、修復狀態與測試證據的遊戲，比起只有簡短更新日誌者，MOD 作者更可能長期維護作品並信任開發團隊。

反例： 資訊過載與公開排名壓力使作者退場，或實際技術支持不足以支撐透明承諾。

H12：MOD 兼容治理改善玩家對正式更新的接受度

當玩家明確知道新版本對其 MOD 組合的影響，且能選擇安全更新、回退或暫緩升級，重大更新後的實質世界損失與不可控感將下降。

反例： 玩家無法理解複雜選項或系統預測不準，導致錯誤決策與信任下降。

19．案例推演：成功、衝突與失敗的界線

本節案例皆為構造型情境，不是 EveMissLab 的實測報告。

案例 A：新字串翻譯 MOD 與資料包

某玩家提供繁體中文介面修正包，只有本地化字串，沒有改變遊戲狀態。若核心語系鍵維持穩定，更新通常只需補充新增欄位。此案例適合以 T0、Schema、差異比對與自動補齊候選進行測試。

問題： AI 可能把翻譯風格自動改變、刪除原作者刻意保留的術語，或以看似合理的文字翻譯錯世界觀設定。語法通過不表示符合作者意圖，仍需人類語言審查。

案例 B：戰鬥規則 MOD 遭遇公式重構

官方將傷害流程從「攻擊／防禦直接計算」轉成「物理、魔法、環境、姿態多階段結算」，原 MOD 原本讓近戰暴擊增加 15%。AI 很容易把舊數值欄位映射到新欄位，但可能讓加成套用兩次，或套用到非近戰傷害。

正確處理： 保留原 MOD 的設計意圖，寫出新的事件與計算語義對照，運用固定戰鬥用例檢查各種攻擊類型，而不是只確認程式可執行。

案例 C：派系 MOD 與百小時世界存檔

某 MOD 生成新派系、地理區域和外交條約。官方更新後，舊版 MOD 的建築類型被更名；單純停用 MOD 會讓派系引用失效。

正確處理： 保存舊 MOD Lockfile、在副本上遷移、重建或隔離孤兒引用、驗證多回合狀態，並讓玩家確認新世界是否可接受。若條件不成立，保留舊版組合可能比強制轉換更合理。

案例 D：MOD 與 MOD 的競合

A 增加新的食物資源，B 修改所有食物的營養分配，C 則針對 A 的食物追加過敏系統。三者單獨可以運行，組合後卻可能造成食物成本無限下降。

正確處理： 檢查依賴、覆蓋與語義規則，將已知問題公布為特定組合條件的 FAIL，而不是直接宣布 A、B、C 各自不相容。

案例 E：失去維護者的舊 MOD

玩家持有合法下載的舊版 MOD，但作者停止更新且無法取得可合法修改的源碼。AI 可對可用文件提出替代介面設計或幫助玩家保留安全舊版環境，但不能自動代表作者同意重編、轉售或正式收錄。

正確處理： 將修改權利與技術可行性分離。具合法來源的替代作品或受許可維護者接手，才可能形成長期方案。

案例 F：Steam 可選舊分支卻無法真正回到舊世界

玩家在 Steam 切回遊戲 1.4 並取得相容 MOD 版本，但存檔已被 1.5 寫入新格式且沒有備份。

教訓： 平台版本功能只提供取回軟體版本的條件，存檔恢復仍需要產品自己管理備份與不可逆遷移。不能把下載舊 MOD 視為已具備世界回滾能力。

案例 G：惡意 MOD 偽裝成修復補丁

攻擊者取得某 MOD 作者的上傳帳號，將惡意腳本打包為「支援最新版本」並發布。若玩家只看版本標籤和下載數，可能誤啟用高權限程式。

正確處理： 來源身分、發行物摘要、異常更新、權限變更警告與可撤回的認證狀態分開檢查。版本相容聲明不是安全證明。

案例 H：玩家不喜歡官方改版，但 MOD 可以保留舊風格

官方將戰鬥速度調快，部分玩家認為失去策略深度。雙方不必強迫彼此接受同一設計；官方可保留自己認定的正式方向，玩家則透過合法穩定 SDK 修改回舊風格。若該 MOD 創作者提出更有說服力的數據，官方也可重新評估，這是 ANIE-04 相交域在實作上的延伸。[I04]

案例 I：AI 修補通過測試，但破壞 MOD 的存在理由

某大型 MOD 以完整城鎮模擬為目標。AI 為消除 CPU 過載，簡化所有居民狀態更新，使遊戲不再掉幀，測試也 PASS；但居民已不再具有原作者要求的長期自主行為。

判定： 這是效能測試通過、語義與創作意圖驗收失敗。應列入失敗樣本，而不是宣稱 AI 完成兼容修復。

20．第一款遊戲如何逐步導入：不需要一次做完所有功能

20.1 用成熟度階梯處理三個月短週期產品

若作品只有三個月開發期，最不合理的做法是要求團隊先寫出比遊戲本體還龐大的 MOD 市集。合理做法是定義 MVP 需要的最小穩定擴充面，以及哪些功能可以延後，但不讓最初世界資料結構毫無邊界。

不要求 M0～M4 各自對應固定月份；它們是能力與品質里程碑，完成順序可依遊戲類型調整。

20.2 若短期只能做一件事

應先做 Manifest + Data Contract + Stable ID + Save Namespace + 最小相容測試。這幾個決策能最大程度保留未來擴張空間；完整 Workshop 工具或高階視覺化 MOD 編輯器可放在後續版本。

20.3 小品與長期模擬遊戲的差異

對以短劇情、解謎、動作挑戰為主的小品，T0 資料包、語言與視覺素材替換可能已足夠。對策略、經營、世界狀態機與長期模擬遊戲，關鍵在於持久化狀態、關聯資料與可解釋規則擴充，可能較早需要事件與動作契約。不能把一套單一 SDK 開放程度當成所有遊戲應遵循的硬性標準。

20.4 與公司內部軟體中樞的關係

行界遊戲若以統一的產品線長期開發多款單機作品，部分工具可以跨遊戲共用，例如套件格式校驗、權利標註、CI 報告格式、版本變更摘要、玩家回饋鏈結，以及 AI 修補工作區。但每款遊戲的世界規則與資料模型仍應保有獨立契約，避免讓一款遊戲的內部概念侵入另一款遊戲，導致所謂「通用」反而造成全面耦合。

20.5 長期不變的是治理邊界，不必是不變的技術實作

SDK 語言、套件格式、渲染器、遊戲引擎甚至發行渠道都可能改變。真正應維持的是：公開了什麼契約、誰擁有權限、哪些變更需要相容遷移、什麼證據能判定完成、玩家如何保留已投入的世界。這些安排能提升技術替換的可能性，而不是把公司永久綁死在某一套模組框架上。

21．產品公開與社群合作的制度介面

21.1 官方公告應能連結到真實工程證據

遊戲更新公告可區分三個讀者層：

1. 一般玩家摘要： 新增內容、已修復問題、是否可能影響 MOD 和存檔；
2. MOD 作者變更說明： SDK 差異、變更 Schema、風險 API、測試分支、舊版維持政策；
3. 可機器讀取契約差異： 包含版本號、事件 ID、棄用欄位、修改類型、測試證據與遷移建議。

這能使玩家與作者各取所需，避免所有資訊只能靠冗長新聞公告人工閱讀。[I00][I01]

21.2 讓玩家知道哪些問題「官方會處理」，哪些需要作者處理

公開 MOD 問題單應至少有以下歸因：

• 官方違反公開 SDK 契約；
• MOD 使用未保證穩定的私有行為；
• MOD 互相衝突；
• MOD 與新增官方功能語義衝突；
• 權利與安全導致該方案不能直接提供；
• 尚無法判定。

在問題尚未確認時，不應為公關便利而把所有責任推給 MOD 作者，也不應因玩家抱怨便宣布官方必然有錯。這是 ANIE-04「非服從式協商」在故障管理上的延續。[I04]

21.3 MOD 作者可以參與，但不等於員工

官方可以提供 RFC、Issue、SDK PR、範例 MOD、測試資格和安全回報機制。當作者擁有特殊技能或提出有商業價值的修改，還可進一步談委託、授權或 MOD 正式整合；但這些安排需要獨立的權利與報酬制度，不能默認只要有人回報或提交 PR，公司就可以取得無限制商業使用權。詳見 ANIE-06 預定研究。

21.4 讓 AI 成為社群技術翻譯層，而不是決策權來源

可由 AI 把「新版本把我百小時存檔弄壞」轉譯為需調查的版本向量、MOD 集合和狀態不變量，並把複雜工程結果解釋給玩家。AI 也可以連結歷史問題、提示已知可用分支、提出重現步驟。但 AI 應保留原始證據與不確定狀態，不得擅自宣布「官方已保證修好」「這個 MOD 已認證安全」或假裝已代表作者批准修改。

21.5 公開維護並非公開所有資訊

官方可以公開版本範圍、測試結果、修復理由、API 差異和恢復路徑，同時保留內部風險評估、未公開營運資料、第三方授權條款、漏洞細節、個資與其他保密資訊。這種資訊投影恰好符合 ANIE-00 所述的選擇性揭露，而不是全透明主張。[I00]

22．失敗模式與反向檢驗

22.1 用「安全」作理由，把所有 MOD 禁止

當第三方 MOD 出現安全風險，完全關閉擴充是一種政策選項，但不必然是唯一方法。可先考慮允許低風險資料包、限制執行能力、提高來源驗證、修補載入器與讓玩家清楚知道風險。若確有無法接受的攻擊面，應坦承技術限制並暫時限制功能，而不是假裝能提供無條件安全。

22.2 為了相容，維持所有錯誤 API

若某個 API 原本會暴露敏感資料或允許越權修改存檔，安全修復可能需要破壞舊版行為。SEC 應提供緊急安全例外、替代路徑與合理遷移協助，但不能賦予外部創作者要求官方永久維持危險接口的絕對權力。

22.3 為了顯示 AI 成功，關掉無法修復的 MOD 功能

一個錯誤的 KPI 會鼓勵模型把有問題的功能註解掉、跳過測試、修改驗收條件或將所有待驗證項目判成 PASS。因此 CI 和驗收應把原作者關鍵需求、語義不變量、測試修改紀錄與簽署權限分開，避免修補者同時控制全部評分規則。

22.4 相容清單讓玩家有虛假的安全感

若清單只根據 MOD 作者自填版本範圍，卻以「相容」作為強烈信任標籤，可能增加玩家受害。因此最好依證據等級顯示：作者聲明、靜態分析、啟動測試、場景測試、存檔測試、實地觀察。尤其對不可逆的舊世界，應優先要求備份。

22.5 網站公布的相容統計缺乏代表性

假設一款遊戲只有 20 個官方測試 MOD，但社群存在 8,000 個 MOD。即使 20 個全部 PASS，也不能聲稱「相容率 100%」而不說明分母。這與 ANIE-04 討論的社群代表性問題相似：取樣偏誤可讓看似漂亮的數字掩蓋真正的產品風險。[I04]

22.6 社群大量產出，官方審核能力被淹沒

AI 降低創作門檻，可能使低品質 MOD、重複包、抄襲、版本不符與安全事件同步增多。此時應提升自助文件、機器驗證、作者信任與多層發布制度，而非期待公司可以人工審核每個檔案。反過來，若自動審查產生錯誤封鎖，也必須有申訴與更正流程。

22.7 過度標準化使創作失去自由

若官方只允許極少數美術素材與固定數值修改，可能無法滿足創作型社群需求。可將穩定受支援的 T0／T1 路徑與較高風險、較低相容保證的 T2 路徑區分，讓玩家在知情條件下承擔不同風險。官方沒有義務為一切任意原生掛鉤提供永久相容承諾，但可以清楚標示其地位。

22.8 正式整合 MOD 反而傷害作者

若公司以「你的 MOD 已被收錄」作為理由，未談授權、付款、署名或後續維護責任，可能傷害社群信任。技術整合可行不代表合作制度合理；同意為 Workshop 提供 MOD，也不能自動等同同意被商業買斷。這不是工程測試能代替的倫理與契約問題。[I04]

23．本研究的限制與必要的未來證據

23.1 概念完整不等於產品有效

本篇主要提出定義、架構、流程和實驗規格，並未提交任何 EveMissLab 已完成 Steam Workshop 正式接入、跨版本存檔恢復、AI MOD 自動遷移或作者實證調查的紀錄。不能將附錄規格視為經過正式產品場景驗證的 SDK。

23.2 不同遊戲生態的權衡無法以單一標準統治

大型長期模擬遊戲可能非常需要 API 相容與舊存檔保存；純敘事短篇、競技性遊戲或具有多人反作弊的產品，可能有更大的設計與安全限制。本研究主要以可持續更新的商業單機遊戲，特別是世界狀態與模組化內容密集的作品作為優先研究對象。

23.3 無法推論 AI 發展必然讓所有相容問題消失

AI 能幫助分析與改寫，但推論成本、模型品質、訓練資料分布、合法程式取得、可驗證 Oracle、硬體平台差異和安全政策都會變動。AI 對不同遊戲語義的理解能力也不一樣。若未來模型顯著進步，應更新各類任務的實證結果，而不是將本篇的保守邊界當成永久能力上限。

23.4 尚未解決的跨遊戲與跨平台問題

本篇尚未完整處理：不同遊戲之間的通用語義、專有引擎與 Godot 等多 Runtime 相容、主機平台 MOD 政策、跨平台第三方市集的同步、商業 MOD 市場的稅務與分潤，以及 AI 生成素材的多法域著作權問題。它們應進入後續個別研究，不宜在本篇未取得證據就做統一結論。

23.5 最小實證閉合條件

要從提案進入更強的研究結論，至少需要：

• 具有明確授權的真實或測試 MOD 集合；
• 至少兩次具實質變更的遊戲版本更新；
• 兩種 SDK／非正式掛鉤條件；
• AI／非 AI 維護對照；
• 保留原始存檔及固定情境；
• 獨立的測試 Oracle 與錯誤分類；
• 真實維護時間、完整成本及作者接受度；
• 安全與授權界線的人工稽核；
• 所有負面結果與 UNKNOWN 的公開紀錄。

若沒有這些證據，本研究應保持在「有明確工程可行路徑的可檢驗假說」地位。

24．結論：把第三方創作視為可以持續存在的產品關係

原生 MOD 生態的核心，不是對外發布一個資源載入器，也不是承諾 AI 未來能修復一切。真正的轉變是：官方遊戲從第一版起，就承認玩家可能將作品帶向與作者不同、但合法且可維護的方向；官方可以保持商業核心與創作決策權，外部創作者亦能擁有自己的創作主體性、擴充路徑與合作選擇。

當更新不再只是公司單方向市場交付新檔案，而涉及玩家已投入的世界、其他作者的程式與第三方依賴時，相容性就成為一種跨主體的產品責任分配問題。這種責任不是要官方替所有不受支援的 MOD 買單，也不是要求玩家接受任何被描述為技術必要的破壞，而是透過公開契約、授權範圍、風險證據、版本選擇與可審核的遷移程序，把衝突和損失降到可以辨識、修正與協商的程度。

AI 在這個體系的作用，是降低理解陌生 MOD、轉換介面、產生候選、擴張測試與長期接手的成本；其價值必須以最後有效交付衡量，不能讓生成速度取代功能品質、存檔安全或合法授權。若 AI 遷移真的能在明確契約與測試支持下持續減少無效重工，未來外部創作者與商業遊戲公司就可能形成比傳統「官方更新、MOD 作者被迫修補」更可持續的合作分工。

本篇最精簡的命題是：

MOD 不應只是遊戲完成後可以被容忍的外掛；它可以從產品初期就成為有明確邊界、可驗證相容、能隨版本演化的外部創作制度。

而最重要的限制同樣清楚：

公開擴充不等於公開所有原始碼，支援協作不等於交出公司決策權，AI 能修補不等於 AI 能授權；技術可執行不等於世界仍被保存。

這些分離，正是 ANIE-04 的「非服從式協商」轉化為軟體工程契約的結果，也將成為 ANIE-06「商業遊戲也可以 PR」討論外部貢獻與公平報酬的前提。

附錄

附錄 A．NME MOD Manifest v0.1 參考格式

下列 JSON 為研究規格的示範資料，非已發布的官方 NME SDK；sdk 等版本區間的字串語法、解析器與安全政策仍需在工程實作時正式定義。它示範不同版本、身分、依賴、能力與證據如何分開紀錄。所有 ID、名稱、檔案摘要與測試標籤均為示例，不代表真實 MOD 或驗證結果。

{
  "schema_version": "1.0.0",
  "mod_id": "org.example.longwinter",
  "mod_version": "0.3.2",
  "display_name": "Long Winter Example",
  "publisher": {
    "id": "creator.example",
    "display_name": "Example Creator"
  },
  "entrypoint": {
    "kind": "data",
    "path": "content/root.json"
  },
  "compatibility": {
    "sdk": ">=1.1.0 <2.0.0",
    "game_branches": ["version_1.4", "version_1.5"],
    "data_schema": "2.0.0",
    "save_schema": "1.2.0"
  },
  "relationships": {
    "requires": [
      {
        "mod_id": "org.example.sharedlibrary",
        "version_range": ">=1.0.0 <2.0.0"
      }
    ],
    "optional": [],
    "conflicts": [],
    "load_after": []
  },
  "capabilities": ["content.read", "world.query"],
  "artifacts": [
    {
      "path": "content/root.json",
      "sha256": "0000000000000000000000000000000000000000000000000000000000000000"
    }
  ],
  "rights": {
    "license_reference": "licenses/MOD-LICENSE.txt",
    "third_party_assets": []
  },
  "verification": {
    "status": "author_declaration",
    "last_tested_game_branch": "version_1.4",
    "evidence": []
  }
}

特別說明：範例 sha256 的 64 個零只是結構佔位，不代表該檔案經過雜湊驗證；實際系統必須從建置產物計算摘要、確認發行檔案與紀錄一致，並且拒絕把占位值視為通過驗證。author_declaration 表示作者聲明，不能自動顯示為官方認證。版本字串類似 SemVer 範圍，但與 Steam Workshop 的遊戲分支區間不是同一套資料模型。

A.1 契約強制性與選填性

• schema_version、mod_id、mod_version、entrypoint、compatibility：最低必要欄位。
• publisher：對正式公開發行建議必要；作者仍可使用筆名，但應符合平台身分政策。
• rights：對需要授權分發的資產必要，缺失時不得被視為商業再利用已獲許可。
• verification：可為待檢查，但不可自動填成 PASS。
• capabilities：以最少授權為原則，不能由 MOD 宣告就直接取得所有權限；Runtime 必須實際執行審查。

A.2 本範例故意不處理的事

本檔案本身不保證外部程式碼隔離，也沒有約束所有世界語義，更不包含真正的 Steamworkshop 發布憑證。Manifest 是其他驗證的入口，而不是驗證的替代品。

附錄 B．Manifest 結構檢查用 JSON Schema 草案

下列 Schema 使用 JSON Schema Draft 2020-12 常見語法，主要示範格式檢查。其包含研究設計選擇，並非現有 Steam 或 Godot 的官方 Manifest 格式；對於版本範圍、檔案存在性、所有權及權限授予仍必須另做語義驗證。[E05]

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.invalid/schemas/nme-mod-manifest-v0.1.json",
  "title": "NME Mod Manifest Research Schema",
  "type": "object",
  "required": [
    "schema_version", "mod_id", "mod_version",
    "entrypoint", "compatibility", "capabilities", "artifacts"
  ],
  "additionalProperties": false,
  "properties": {
    "schema_version": {"type": "string", "minLength": 1},
    "mod_id": {
      "type": "string",
      "pattern": "^[a-z][a-z0-9]*(\\.[a-z][a-z0-9]*)+$"
    },
    "mod_version": {"type": "string", "minLength": 1},
    "display_name": {"type": "string", "minLength": 1},
    "publisher": {
      "type": "object",
      "required": ["id", "display_name"],
      "additionalProperties": false,
      "properties": {
        "id": {"type": "string", "minLength": 1},
        "display_name": {"type": "string", "minLength": 1}
      }
    },
    "entrypoint": {
      "type": "object",
      "required": ["kind", "path"],
      "additionalProperties": false,
      "properties": {
        "kind": {"enum": ["data", "restricted_rules", "native_code"]},
        "path": {"type": "string", "minLength": 1}
      }
    },
    "compatibility": {
      "type": "object",
      "required": ["sdk", "game_branches", "data_schema", "save_schema"],
      "additionalProperties": false,
      "properties": {
        "sdk": {"type": "string", "minLength": 1},
        "game_branches": {
          "type": "array", "items": {"type": "string", "minLength": 1},
          "uniqueItems": true
        },
        "data_schema": {"type": "string", "minLength": 1},
        "save_schema": {"type": "string", "minLength": 1}
      }
    },
    "relationships": {
      "type": "object",
      "additionalProperties": false,
      "properties": {
        "requires": {" $ref": "#/$ defs/dependencyList"},
        "optional": {" $ref": "#/$ defs/dependencyList"},
        "conflicts": {" $ref": "#/$ defs/dependencyList"},
        "load_after": {"type": "array", "items": {"type": "string"}}
      }
    },
    "capabilities": {
      "type": "array", "uniqueItems": true,
      "items": {"type": "string", "minLength": 1}
    },
    "artifacts": {
      "type": "array", "minItems": 1,
      "items": {
        "type": "object",
        "required": ["path", "sha256"],
        "additionalProperties": false,
        "properties": {
          "path": {"type": "string", "minLength": 1},
          "sha256": {"type": "string", "pattern": "^[a-fA-F0-9]{64}$"}
        }
      }
    },
    "rights": {
      "type": "object",
      "required": ["license_reference", "third_party_assets"],
      "additionalProperties": false,
      "properties": {
        "license_reference": {"type": "string"},
        "third_party_assets": {"type": "array", "items": {"type": "string"}}
      }
    },
    "verification": {
      "type": "object",
      "required": ["status", "last_tested_game_branch", "evidence"],
      "additionalProperties": false,
      "properties": {
        "status": {
          "enum": ["author_declaration", "unknown", "automated_tested", "official_reviewed"]
        },
        "last_tested_game_branch": {"type": "string"},
        "evidence": {"type": "array", "items": {"type": "string"}}
      }
    }
  },
  "$defs": {
    "dependencyList": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["mod_id", "version_range"],
        "additionalProperties": false,
        "properties": {
          "mod_id": {"type": "string", "minLength": 1},
          "version_range": {"type": "string", "minLength": 1}
        }
      }
    }
  }
}

example.invalid 是明確不應作為正式服務使用的占位域名。實際發布時要替換為受公司控制的穩定 Schema URI，並維持歷史版本可取得。以上驗證器也尚未解決路徑穿越、符號連結、檔案大小、腳本沙盒、惡意多媒體解析、版本表達式解析、MOD 載入授權和 Schema 內跨欄位的所有語義約束；應另由安全的驗證及執行流程處理。

附錄 C．相容性證據紀錄範本

以下是本篇建議的機器資料記錄樣式。UNKNOWN 應被視為獨立而合理的狀態。

{
  "record_id": "nme-compat-example-001",
  "record_kind": "compatibility_evidence",
  "game_build": "version_1.5",
  "sdk_version": "1.3.0",
  "mod_id": "org.example.longwinter",
  "mod_version": "0.3.2",
  "mod_artifact_digest": null,
  "configuration_id": "example-lockfile-01",
  "scenario": "load_existing_save_then_advance_100_turns",
  "environment": {
    "platform": "windows-x64",
    "engine_version": "not_recorded",
    "test_seed": 12345
  },
  "evidence_levels": {
    "installed": "UNKNOWN",
    "loaded": "UNKNOWN",
    "contract": "UNKNOWN",
    "behavior": "UNKNOWN",
    "save_integrity": "UNKNOWN",
    "human_acceptance": "UNKNOWN"
  },
  "evidence_links": [],
  "test_provenance": "not_executed",
  "reviewed_by": null,
  "last_updated": "not_applicable"
}

範例刻意將所有結果保留 UNKNOWN，以避免有人把文件中的示意記錄誤認為真實實測。完整實作應加入資料庫主鍵、版本、指標定義、存取權限和事件歷史；若更新檢查結果，應保留舊版本證據及更正原因，不要靜默覆蓋。

附錄 D．AI 遷移候選計畫與批准契約

這份計畫示意如何區分 AI「建議」與真正的修改、測試與發布權。

{
  "plan_id": "nme-migration-example-01",
  "status": "PROPOSED_ONLY",
  "source_build": "version_1.4",
  "target_build": "version_1.5",
  "target_mod_id": "org.example.longwinter",
  "source_mod_version": "0.3.2",
  "source_rights_status": "REQUIRES_REVIEW",
  "planned_actions": [
    {
      "action": "rename_data_field",
      "old_path": "content.weather.severity",
      "new_path": "content.weather.intensity",
      "classification": "M0",
      "reversibility": "EXPECTED_REVERSIBLE",
      "evidence_required": ["schema_check", "behavior_scenario"]
    }
  ],
  "protected_assets": ["original_mod_release", "original_saves"],
  "tests_required": [
    "manifest_validation",
    "sdk_contract",
    "mod_dependency_resolution",
    "world_behavior_scenario",
    "existing_save_integrity"
  ],
  "unknowns": [
    "author_intent_confirmation",
    "rights_to_publish_modified_version"
  ],
  "permissions": {
    "read_source": false,
    "write_candidate_workspace": false,
    "publish_release": false
  },
  "approval_state": "NOT_APPROVED"
}

此檔案沒有暗示 AI 真正取得任何系統權限，示範中的 false 代表未核發。正式實作時，即便計畫中寫了 true，仍需要外部權限控制系統實際檢查，不能信任模型自行設定的欄位作為授權證明。

D.1 不可直接自動批准的情況

• 修改涉及玩家唯一存檔、未保留備份或不可逆世界變更；
• 新增本機檔案、網路或其他高權限執行能力；
• MOD 包含未知第三方授權素材；
• 更新後的原設計意圖不明或受到實質改變；
• 修補候選需要修改驗證器以便通過測試；
• 變更與正式版產品的簽署、商店發布或付款系統有關。

D.2 建議建立「停止與回復」權限

AI 可以在經授權的工作區自行重試低風險候選，但即使長期測試通過，也不能因此無視人工維護者或公司保留的停止權。若外部權利人要求撤回使用授權，應依適用契約及法律處理，不能由模型判斷「技術上很有價值」就跳過。

附錄 E．CI 驗收契約與範本流程

以下為流程級 YAML 提案，其中 nme-validate、nme-test 等命令僅代表未來需實作的 CLI 介面；不是可直接執行的現成軟體。實際 CI 需加上環境隔離、輸入摘要校驗、憑證保護、權限政策、惡意套件防護與結果不可否認性。

name: NME Mod Compatibility Research Pipeline
version: '0.1-proposal'
source:
  game_build: version_1.5
  sdk: '1.3.0'
  mod_manifest: mod.json
stages:
  - id: ingest
    command: nme-validate manifest mod.json
    output: artifacts/manifest-report.json
  - id: dependencies
    command: nme-validate dependency-lock mod-lock.json
    output: artifacts/dependency-report.json
  - id: contract
    command: nme-test contract --sdk 1.3.0
    output: artifacts/contract-report.json
  - id: scenarios
    command: nme-test scenarios --suite world-core
    output: artifacts/scenario-report.json
  - id: saves
    command: nme-test saves --readonly-original
    output: artifacts/save-report.json
  - id: publish-evidence
    requires_approval: true
    command: nme-report aggregate --out artifacts/compatibility-evidence.json

E.1 不應省略的發行閘門

ingest PASS 不等於 contract PASS；contract PASS 不等於 save PASS；所有 CI PASS 也不等於已取得合法發布權。正式版的發行流程應確認版本、批准者、遊戲分支、依賴、檔案摘要、測試結果與授權狀態皆與最終產物一致。

E.2 變更造成安全疑慮時的處理

若有人用 AI 生成一個建議修改 CI 的 PR，驗證器與受測者不應被同一個無限制工作區控制；否則 AI 可能無意或有意使測試變得過度寬鬆。對照實驗更應凍結評分集與核心品質門檻，減少對測試集的過擬合。

附錄 F．破壞性變更公告範本

Title: MOD SDK v1.4.0 — Compatibility Notice
Status: Proposed / Beta Available / Released / Corrected
Game Builds Affected: version_1.5 and newer
SDK Change Type: Deprecated / Added / Breaking / Security Emergency
Affected Contract IDs: event.combat.on_damage.v1
Old Semantics: [describe observed before/after conditions]
New Semantics: [describe observed before/after conditions]
Known Affected Mods: [identified list, with evidence level]
Unknown Coverage: [what was not tested]
Safe Migration Route: [SDK adapter or documented code change]
Save Integrity Impact: [none / tested / unknown / known risk]
Availability of Old Game Branch: [available / unavailable / limited]
How to Test: [branch, test suite, instructions]
Author Feedback Channel: [official page or issue tracker]
Owner / Decision Authority: [team role]
Publication Evidence: [build and test references]
Correction and Retraction Policy: [how erroneous claims are fixed]

範本刻意保留 UNKNOWN。對外承諾應由有權限的人員批准，不能因 AI 撰寫公告或自動計算了「預計相容」就轉變成法律或產品上的無條件擔保。

附錄 G．季度公開 MOD 生態報告模板

G.1 範例格式

G.2 絕不應作為粉飾的五個數字

1. 只公布 PASS/已測試，卻隱藏測試範圍很小；
2. 只公布 AI 候選 PR 數，不公布真正採納與再次返工；
3. 只公布 MOD 增長數，卻隱藏大量舊 MOD 失效；
4. 只公布客服結案數，卻沒有追蹤修復有效性；
5. 只公布遊戲發行頻率，卻不統計長期玩家存檔損失。

本研究主張：公開不足的證據，不等於建立信任；能公開尚未解決的邊界，才有可能讓制度獲得事後驗證。

附錄 H．工程驗收矩陣：從第一個 MOD 到可用生態

這份矩陣仍需按真正的遊戲引擎、作業系統、平台與產品玩法轉化成 executable tests。它們是研究驗收條件，而非已執行的測試報告。

附錄 I．縮寫與概念對照

參考文獻與前置研究

本篇外部來源以 2026-10-16 可取得之官方規格、平台文件及研究資料為界。官方功能和平台政策後續可能更動；部署時仍須以當時有效版本再核對。除特別標明外，公式、分類、假說、案例與附錄規格均屬本文的概念提案或推演，不是外部文獻已證實之實驗結論。

A．外部規格、官方文件與研究

• [E01] Valve／Steamworks Development. New! Version Control For Steam Workshop Mods. 2026-01-08. 官方公告，說明遊戲版本分支與 MOD 發行版本的新控制能力。https://steamcommunity.com/groups/steamworks/announcements/detail/497183817277113901
• [E02] Valve. Steam Workshop Item Versioning. Steamworks Documentation. 說明 Steamworks SDK 1.60 的 MOD 版本支持、遊戲分支、GetSupportedGameVersionData、SetRequiredGameVersions 等功能及開發者流程。https://partner.steamgames.com/doc/features/workshop/itemversioning
• [E03] Godot Engine. Exporting packs, patches, and mods. Stable Documentation. PCK／ZIP、資源載入、MOD 結構與安全注意事項。https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html
• [E04] Preston-Werner, T. 與社群維護者. Semantic Versioning 2.0.0. 官方規格。https://semver.org/spec/v2.0.0.html
• [E05] JSON Schema. Draft 2020-12. JSON 結構、驗證與規格文件入口。https://json-schema.org/draft/2020-12/
• [E06] Players’ rights to game mods: Towards a more balanced copyright regime. Computer Law & Security Review, 43 (2021), 105634. DOI: 10.1016/j.clsr.2021.105634. 以玩家創作、著作權與社群實務為研究背景。https://doi.org/10.1016/j.clsr.2021.105634
• [E07] NIST. SP 800-218: Secure Software Development Framework (SSDF), Version 1.1. 2022. https://csrc.nist.gov/pubs/sp/800/218/final
• [E08] OpenSSF／SLSA. Provenance, SLSA v1.2 Specification. 軟體建置及來源追蹤的供應鏈完整性。https://slsa.dev/spec/v1.2/provenance
• [E09] OWASP Cheat Sheet Series. CI/CD Security Cheat Sheet. 外部插件與整合的審查、最小權限及供應鏈風險參照。https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html
• [E10] Valve. Branches (Betas). Steamworks Documentation. 說明遊戲分支的建立、測試與使用者選擇。https://partner.steamgames.com/doc/store/application/branches
• [E11] Valve. Steam Workshop Implementation Guide. Steamworks Documentation. 說明 UGC 接入、上傳、Workshop 能力與法律協議流程。https://partner.steamgames.com/doc/features/workshop/implementation
• [E12] mod.io. Get Mod Dependencies and Add Mod Dependencies. 外部 MOD 平台的依賴描述設計參照；本文不將其作為 Steam Workshop 內建功能。https://docs.mod.io/restapi/docs/get-mod-dependencies；https://docs.mod.io/restapi/docs/add-mod-dependencies

B．本系列內部前置研究

• [I00] Neo.K × GPT-6. ANIE-00：從產品黑盒到 AI 原生互動企業. 2026-10-16，UTF-8 Markdown 工作論文。
• [I01] Neo.K × GPT-6. ANIE-01：從 EA 到持續交付. 2026-10-16，UTF-8 Markdown 工作論文。
• [I02] Neo.K × GPT-6. ANIE-02：季度單機產品制：AI 工業化、算力額度與品質交付率. 2026-10-16，UTF-8 Markdown 工作論文。
• [I03] Neo.K × GPT-6. ANIE-03：可繼承的遊戲產品：資產移轉、AI 接手與長期可維護性. 2026-10-16，UTF-8 Markdown 工作論文。
• [I04] Neo.K × GPT-6. ANIE-04：玩家—開發者相交域：需求、設計主權與可行性的非服從式協商. 2026-10-16，UTF-8 Markdown 工作論文。
• [I05] EveMissLab. SEDB-GAME × ModWorld：AI 原生遊戲理解與 MOD 共創 Runtime 技術白皮書 v0.1. 2026-09-01，內部／研究文件。研究使用既有有效世界、遊戲語義、MOD 關係與驗證 Runtime 概念，不宣稱本篇已實作該系統。

文件版本紀錄

Canonical Authoring Notice： 本 UTF-8 Markdown 檔案為正式研究原始稿；聊天渲染畫面不是 canonical source。數學定界符僅使用 $...$ 與 $$...$$。本文尚未完成同行評審、產品環境部署或跨團隊實證。示意 JSON／YAML 可供後續工程設計與驗證，但不代表現成 SDK、測試執行結果或法律授權。