--- 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 需要明確區分既有技術與本篇提案 | 已存在的外部能力 | 本篇希望再補上的制度 | |---|---| | Godot PCK／ZIP 載入 | 穩定 MOD 合約與可驗證載入邊界 | | Steam Workshop 版本選擇 | 多軸相容與內容語義證據 | | Steam Beta／Branch | 版本前瞻、遷移窗口與回退程序 | | SemVer | SDK／資料／存檔各自版本紀律 | | JSON Schema | 跨版本遷移與世界規則驗證 | | SLSA／SSDF | MOD 包來源、AI 修改與權限控制 | | 玩家 MOD 社群 | 參與、相容性承諾、資訊回饋與後續合作 | 故 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 信任等級 | 層級 | 內容形式 | 權限與風險 | 建議預設 | |---|---|---|---| | T0 資料型 | 字串、表格、圖片、受限地圖描述 | 仍可能造成資源耗盡或內容風險，但原則上不包含任意程式碼 | 允許於受限解析器中啟用 | | T1 宣告式規則型 | 受控事件回應、規則 DSL、沙盒規則節點 | 可能改變遊戲經濟與世界狀態；應有配額與權限檢查 | 限制能力並留下操作日誌 | | T2 原生程式型 | GDScript、C#、DLL、原生動態函式庫等 | 視執行環境可能接觸檔案、網路或更多系統資源 | 明確告知高風險，不假裝已有安全沙盒 | 以上是**本研究建議的風險分類**，並非 Godot 或 Valve 官方的原生分級。若引擎腳本無可靠安全邊界，T1 就不能僅因被稱為腳本而宣稱受限；必須有真正的執行隔離與能力審查。 ### 2.5 MOD 生態不能只用「可安裝 MOD 數量」衡量 MOD 數量增加，可能代表創作成功，也可能代表官方缺乏基礎便利功能、版本碎裂、低品質重複包或大量無人維護內容。因此本研究重點衡量的是**跨版本有效可用的 MOD 及其玩家世界保存能力**，不是把 Workshop 物件數視為唯一績效。 --- ## 3．版本不是一條線：多軸相容關係（MACR） ### 3.1 版本向量 傳統使用者經常只看到「遊戲 v1.5」「MOD v2.1」兩個標籤，但實際相容性至少依賴： $$ V=(g,a,d,s,m,e,p,c) $$ 其中： - $g$：官方遊戲版本／實際執行 Build； - $a$：對外 SDK／API 契約版本； - $d$：遊戲資料 Schema 版本； - $s$：存檔與世界狀態格式版本； - $m$：MOD 套件本身版本； - $e$：引擎與 Runtime 版本； - $p$：平台與載入路徑； - $c$：外部 MOD 組合、配置與依賴集合。 **定義 3。** MACR 是判斷某組 $V$ 是否能在給定環境、任務集合與安全政策下，維持指定的載入、執行、世界語義與存檔正確性的關係。 $$ \mathcal{K}(V,T,\Gamma)\in\{\mathrm{PASS},\mathrm{FAIL},\mathrm{UNKNOWN}\} $$ $T$ 表示測試任務集合， $\Gamma$ 表示安全與權利限制。採三值邏輯的理由是：未測試的相容性應保持 **UNKNOWN**，不能默認 PASS。 ### 3.2 相容不等於一個布林值 本文區分至少六層相容： | 層級 | 要檢查的事項 | 典型錯誤 | |---|---|---| | L0 安裝相容 | 能下載、校驗、識別套件 | 漏檔或版本不符 | | L1 載入相容 | 能解析檔案、載入資源、建立擴充點 | 找不到資源、初始化例外 | | L2 介面相容 | API 呼叫、事件、欄位符合契約 | 函數簽名改變 | | L3 行為相容 | 指定玩法、規則、任務仍達預期 | 傷害或 NPC 決策異常 | | L4 狀態相容 | 已有存檔、世界因果與持久化狀態完整 | 某勢力消失、道具變成孤兒 | | L5 使用相容 | 玩家實際使用不產生不可接受的回退 | 遊戲可跑但舊作品玩法毀損 | L0 或 L1 PASS 不足以聲稱 L4 或 L5 PASS。同樣，一個 MOD 在全新遊戲存檔通過測試，也不足以證明舊存檔相容。 ### 3.3 版本相容具有方向性 由舊遊戲升級新版、由新 MOD 回退舊版、由舊存檔轉新版，是不同方向的操作： $$ \mathcal{K}(V_i\rightarrow V_j)\neq\mathcal{K}(V_j\rightarrow V_i) $$ 除非系統明確提供雙向且無資訊損失的轉換。對存檔 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 建議參考結構 ```text 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 不可缺席 最低要求可定義為： ```text 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$。以有向圖： $$ G_M=(M,E_D,E_L,E_X) $$ 表示必需依賴、次序約束與衝突關係。若必需依賴與順序約束形成不可解除的有向環，安裝管理器應顯示具體衝突，不應隨機選擇某個載入序列並宣稱成功。 ### 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 移除或世界規則變動而在下一個回合產生錯誤。 因此將玩家的有效世界定義為： $$ W_t=\Phi(B_t,D_t,M_t,C_t,S_t,O_t) $$ 其中 $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 存檔遷移必須是可審核的交易 建議遷移狀態機： ```text 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，直到使用者確認不再需要恢復。 $$ S_{t+1}=\mu(S_t,V_i,V_j) $$ 當 $\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$，可以將語義相容定義為： $$ K_{sem}(i,j,\mathcal{T},\Omega)=1 $$ 當且僅當版本 $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 提議的八階段遷移流程 ```text 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 將遷移難度分成六類 | 分類 | 範例 | AI 可期待的作用 | 必要外部判斷 | |---|---|---|---| | M0 純資料搬移 | 欄位改名、路徑改名 | 高度可自動化 | schema/資料回歸 | | M1 API 語法調整 | 函數參數新增預設值 | 常可生成候選 | 介面契約測試 | | M2 事件語義差異 | 事件觸發時機變動 | 比對文檔並提出方案 | 行為情境測試 | | M3 世界狀態遷移 | MOD 專有實體需重建引用 | 候選遷移與證據整理 | 存檔驗證、玩家同意 | | M4 設計變更 | 新戰鬥規則衝突舊 MOD 目的 | 提出多種保留意圖的方案 | 作者與玩家判斷 | | M5 權利或來源缺失 | MOD 源碼不可取得或不能改作 | 搜尋合法替代路徑 | 權利與合法性審查 | 「模型越強，所有遷移都可自動完成」並非本研究假設。尤其 M5 是授權問題，不能透過算力直接解除。 ### 11.5 遷移候選應保留原作者意圖 一個 MOD 是為了把原版生存難度提高兩倍，AI 不應只為了通過測試就把修改功能關掉、削弱到與原版相同、刪除玩家角色，或讓原本應觸發的事件不再發生。通過「無崩潰」測試但失去 MOD 主要功能，是一種偽成功。 因此候選方案應列出：保留的功能、不再保留的功能、因新版本而無法直接保留的原因、替代方案、預期行為差異及證據不足之處。當作者不可聯繫時，應避免把 AI 對作者原意的猜測包裝為本人授權。 ### 11.6 AI 遷移的最後一關是正式來源與發布權 AI 提交一個候選 Pull Request，可以是對開源專案的正常協作；但若 MOD 只以禁止再發布的形式提供、或遊戲整合涉及未授權素材，通過測試也不代表公司可以直接代為發布。涉及商業轉正與付費報酬的細節，留待 ANIE-06 處理。本文要求的是**遷移權限與產品發布權必須獨立確認**。 --- ## 12．MOD 相容性工程的測試閉環 ### 12.1 由「人工覺得能用」轉向持續的證據矩陣 最低應對每個 MOD 發行版和遊戲分支，產生下列測試證據： | 測試類型 | 所需輸入 | 可見輸出 | 無法獨立證明 | |---|---|---|---| | Package 驗證 | MOD、Manifest、摘要 | 安裝可解析與來源匹配 | 玩法合理 | | Static 檢查 | MOD 原始碼／資料 | 危險 API、Schema、版本問題 | 執行行為 | | Contract 檢查 | SDK 介面描述 | 事件、型別、授權符合 | 跨 MOD 衝突 | | Integration | 測試遊戲 Build | 啟動、載入、初始化與基本互動 | 長時間穩定 | | World Scenario | 固定種子與任務 | 語義不變量、任務／經濟結果 | 全部可能世界 | | Save Migration | 舊存檔＋MOD Lock | 遷移成敗與關鍵狀態差異 | 玩家完全滿意 | | Security | 安全限制與惡意樣本 | 已定義威脅是否受控 | 絕對無漏洞 | | Human Acceptance | 受試玩家／作者 | 體驗接受度、意圖保留 | 整體玩家代表性 | ### 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 建議版本發行流程 | 階段 | 對外資訊 | 核心驗收 | |---|---|---| | 提前預告 | 可能受影響的 API、資料 Schema、存檔規則與預計變更性質 | 變更紀錄有具體範圍 | | 測試分支 | 提供可供 MOD 作者測試的 Build（若適用） | 基本資安與發行品質閘門 | | 相容窗口 | 作者回報 PASS／FAIL／UNKNOWN、官方提供 migration guide | 有結構化相容性紀錄 | | 正式發布 | 發布簽署 Build、契約差異與已知風險 | 舊存檔與關鍵 MOD 組合驗證 | | 發布後追蹤 | 收集崩潰、存檔、平衡與相容性問題 | 能回退或採取緊急修復 | | 季度回顧 | 本季兼容成本、故障、修補、棄用與例外 | 記錄未完成事項與原因 | 這是研究建議，並非 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 數量與支援需求增加。 可以建立生態總成本的概念模型： $$ C_{eco}=C_{sdk}+C_{ci}+C_{migration}+C_{support}+C_{security}+C_{rights} $$ 各項均需附有實際人力／機器資源、觀察窗口與計量依據；不能僅因模型產生程式碼速度很快，就把成本設定為零。 ### 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$。一個可觀察的相容性函數為： $$ K(m,b,t)\in\{1,0,\bot\} $$ $1$ 為指定測試 PASS； $0$ 為 FAIL； $\bot$ 為 UNKNOWN。若缺少測試資料、合法授權或必要依賴，狀態不得自動視為通過。 ### 15.2 以測試人口和測試覆蓋共同構成分母 假設 $\mathcal{E}_q$ 為在當季、指定遊戲分支與目標平台上，有足夠測試資料且具合法處理條件的 MOD－版本－情境三元組。則： $$ CR_q=\frac{\sum_{x\in\mathcal{E}_q}\mathbf{1}[K(x)=1]}{|\mathcal{E}_q|} $$ 其前提是 $|\mathcal{E}_q|>0$ ；若分母為零應標示 N/A，不能填 100%。**此指標是測試樣本內的通過率**，不可誇稱為所有玩家 MOD 都相容。 同時公開測試覆蓋率： $$ TC_q=\frac{|\mathcal{E}_q|}{|\mathcal{P}_q|} $$ 其中 $\mathcal{P}_q$ 是預先定義且可計數的優先測試樣本框架。兩者應並列，防止官方只測三個容易成功的 MOD，便宣稱相容率極高。 ### 15.3 玩家權重與少數高風險事件不得互相取消 若以使用量加權，可以衡量已驗證相容在實際安裝配置中的涵蓋比例，但應保護隱私並說明資料來源。有一千名玩家使用的單一常見 MOD 值得關注；同時，只有一名玩家通報「升級會毀掉不可恢復的存檔」也可能需要高優先度。故玩家權重指標不得取代嚴重程度、安全與存檔破壞等硬性風險門檻。 ### 15.4 AI 遷移效率需要測量全部成本 定義每個遷移案例的完整投入成本： $$ C_{total}=C_{compute}+C_{human}+C_{validation}+C_{rework}+C_{release}+C_{incident} $$ 並以相同的驗收準則比較 AI 協助組與基準組。若 AI 生成速度提高 60%，但人工驗證與修正成本翻倍，仍可能使總成本上升。不能以 token 消耗或 PR 件數直接等同維護效率。 ### 15.5 成本不是唯一目標 可用概念上的多目標規劃描述： $$ \max(\mathrm{compatibility},\mathrm{world\ preservation},\mathrm{creator\ autonomy},\mathrm{player\ value}) $$ 在工程預算、資安、權利、可用性及官方產品承諾約束下，尋找非支配方案。此處不是主張所有目標能由一個客觀權重固定加總；不同作品和玩家群體的價值排序可能不同，應保留取捨的公開解釋。 --- ## 16．衡量 MOD 生態是否真正改善：指標體系 ### 16.1 不能把瀏覽、訂閱、安裝與實際使用混為一談 Workshop 頁面瀏覽量、訂閱數、下載數、實際啟用數、成功載入數，以及同一 MOD 在長期存檔中仍被使用的數量，都有不同意義。訂閱並不保證啟用，啟用也不保證玩家滿意。因此需要從**取得、啟動、驗證、持續使用、修復與退出**分別設計指標。 ### 16.2 核心指標分層 | 代碼 | 指標 | 定義與用途 | 反面風險 | |---|---|---|---| | MCT | MOD Compatibility Test Coverage | 已被測試的目標組合比例 | 只測容易的案例 | | MCR | MOD Compatibility Pass Rate | 指定條件下通過率 | 忽略 UNKNOWN | | SIR | Save Integrity Retention | 遷移後滿足存檔不變量比例 | 只驗證可載入 | | MMR | MOD Migration Resolution | 有結果的遷移案例比例 | 大量用停用 MOD 充數 | | TTR | Time to Repair | 已確認破壞到發布有效修復的時間 | 只看表面回報速度 | | BCR | Breaking Change Rate | 對外 SEC 被破壞的頻率／暴露量 | 隱藏更新的 API 變更 | | AVER | AI-Verified Effective Repair | AI 候選真正通過最終驗收比例 | 把 AI 自評當證據 | | CMB | Compatibility Maintenance Burden | 作者＋公司維護成本 | 外部無償勞動不可見 | | PRV | Player Recovery Viability | 發生破壞後可恢復有效世界的比例 | 只有舊備份卻無可執行環境 | | ICR | Intent Conservation Rate | 遷移是否保留 MOD 原設計意圖 | API 能跑、MOD 功能失真 | | SEC-I | Security Incident Rate | 與 MOD 相關且按嚴重度分類的安全事件 | 少通報被誤當更安全 | | CTR | Creator Trust and Retention | 作者是否願意維護／續作 | 留存偏誤與自願問卷偏誤 | 每項指標均應同時記錄觀察窗、分母、排除條件、資料缺漏、相容性階層與可追溯證據，不能單憑名稱宣稱有跨遊戲可比性。 ### 16.3 破壞率與修復率需要事件定義 例如一次遊戲更新令 400 個 MOD 產生載入錯誤，與更新後令一個關鍵 MOD 引發大量玩家存檔損毀，其嚴重程度不可直接按 MOD 數量排序。對於「官方造成的破壞」，還要區分： - 違反明確 SEC 的破壞； - 官方依法或基於安全必須移除的高風險接口； - MOD 使用未承諾私有 API 所造成的問題； - MOD 作者自行更新導致的錯誤； - 多 MOD 組合才會發生的交互作用。 若未做來源歸因，可能不公平地把全部事故算成官方或 MOD 作者單方責任。 ### 16.4 恢復能力比「沒有報錯」更重要 設 $R_i=1$ 當第 $i$ 件被確認的重大存檔或相容事故，在規定時間與可取得的工具／合法資產條件下，玩家能回到可接受的有效遊戲世界；否則 $R_i=0$。則在給定事件集合 $\mathcal{I}$ 下： $$ PRV=\frac{\sum_{i\in\mathcal{I}}R_i}{|\mathcal{I}|} $$ 若事件集合空白，回復能力不能以本式直接估計。可另設置人工注入的受控破壞測試，避免低事故數導致沒有足夠樣本。 ### 16.5 AI 生成候選補丁的實際貢獻 對於同級難度、相似修改幅度的任務，應測量： - 候選成功率； - 端到端合法可發布修復率； - 新引入的回歸錯誤； - 存檔／語義損壞； - 人類審查時間； - 總額度／算力與經費； - 初版修補後的再次修補率； - 作者是否認為核心意圖得到保留。 特別要觀察「AI 可以修好幾乎所有編譯錯誤，但對世界語義錯誤毫無改善」的結果；它仍是有價值的侷限性發現，而不是研究失敗。 --- ## 17．可重現的實證研究設計 ### 17.1 研究應分開比較「有沒有 SDK」與「有沒有 AI」 為避免把不同改善因素混在一起，建立最基本的四組： | 組別 | 官方外部擴充介面 | AI 遷移協助 | 預期可觀察差異 | |---|---|---|---| | A | 非正式／既有非公開介面 | 無 | 傳統基準維護成本 | | B | 非正式／既有非公開介面 | 有 | AI 對脆弱掛鉤的補救能力 | | C | 穩定版 SEC／SDK | 無 | 介面治理自身的效果 | | D | 穩定版 SEC／SDK | 有 | 兩者交互作用及額外效益 | 同一功能應設計在兩條可比較的獨立樣本線上，避免同一作者做完 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 需要的**最小穩定擴充面**，以及哪些功能可以延後，但不讓最初世界資料結構毫無邊界。 | 階段 | 對外可宣告能力 | 必須完成的驗證 | 不應宣稱 | |---|---|---|---| | NME-M0：邊界預備 | 規範資料 ID、擴充掛點與存檔命名空間 | 官方內容至少可透過資料配置載入 | 已全面支援 MOD | | NME-M1：資料型 MOD | 可安裝一種資料包，有 Manifest 與停用說明 | 範例包、錯誤報告、基本存檔回歸 | 任意第三方腳本安全可用 | | NME-M2：契約化 SDK | 公開事件／查詢／動作的穩定子集 | 兩個 SDK 版本的契約測試 | 對所有非公開內部掛鉤負責 | | NME-M3：版本維護 | 官方版本、MOD 依賴、相容測試與回退入口 | 版本差異、舊存檔、失敗恢復 | 不需任何人工就永遠相容 | | NME-M4：AI 遷移服務 | 在受權範圍內生成、驗證並提議升級候選 | 對照實驗、風險分級、作者授權 | AI 可代替作者取得所有權利 | 不要求 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 或驗證結果。 ```json { "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] ```json { "$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` 應被視為獨立而合理的狀態。 ```json { "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「建議」與真正的修改、測試與發布權。 ```json { "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 需加上環境隔離、輸入摘要校驗、憑證保護、權限政策、惡意套件防護與結果不可否認性。 ```yaml 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．破壞性變更公告範本 ```text 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 範例格式 | 類別 | 本季內容 | 證據要求 | |---|---|---| | 遊戲版本 | 發布、測試與保留的分支 | Build／發行紀錄 | | SDK | 新增、棄用與破壞介面 | 契約差異 | | MOD 兼容 | PASS／FAIL／UNKNOWN 與分母 | 測試矩陣與實測紀錄 | | 存檔 | 已知損壞與恢復成功率 | 匿名化事故統計 | | AI 遷移 | 候選、驗收、撤回與失敗 | PR／測試／授權紀錄 | | 安全 | 事件分類與適度揭露的改善措施 | 內部可稽核證據 | | 作者協作 | 官方回應、範例更新、SDK 建議 | Issue／公告鏈結 | | 下季方向 | 已承諾、暫定、研究中 | 變更類型與理由 | ### G.2 絕不應作為粉飾的五個數字 1. 只公布 `PASS/已測試`，卻隱藏測試範圍很小； 2. 只公布 AI 候選 PR 數，不公布真正採納與再次返工； 3. 只公布 MOD 增長數，卻隱藏大量舊 MOD 失效； 4. 只公布客服結案數，卻沒有追蹤修復有效性； 5. 只公布遊戲發行頻率，卻不統計長期玩家存檔損失。 本研究主張：**公開不足的證據，不等於建立信任；能公開尚未解決的邊界，才有可能讓制度獲得事後驗證。** --- ## 附錄 H．工程驗收矩陣：從第一個 MOD 到可用生態 | ID | 驗收情境 | 必要結果 | 不能接受的假通過 | |---|---|---|---| | NME-T01 | 安裝符合格式的 T0 MOD | 正常解析與顯示來源 | 不驗檔案完整性 | | NME-T02 | 安裝重複 `mod_id` 的套件 | 明確拒絕或要求解決衝突 | 靜默覆蓋 | | NME-T03 | 依賴缺失／形成環 | 顯示可辨識的依賴診斷 | 隨機次序繼續載入 | | NME-T04 | 同路徑內容覆蓋 | 遵循明示覆蓋政策 | 不可預期修改官方資產 | | NME-T05 | 發布新增 API 的 SDK 小版本 | 舊範例仍通過相容測試 | 只測最新版 | | NME-T06 | 事件前後條件改動 | 標記語義變更並要求新驗收 | 參數一致就標 PASS | | NME-T07 | 帶 MOD 的舊存檔升級 | 保留原始備份、驗證實體引用 | 直接改寫唯一存檔 | | NME-T08 | 升級後退回舊遊戲分支 | 提供可行的舊資料世代 | 強制新格式回寫舊檔 | | NME-T09 | 停用新增地圖的 MOD | 有風險提示或安全轉換 | 靜默刪除世界區域 | | NME-T10 | AI 生成 M0 修補 | 結構與行為證據一致 | 只提供 AI 自述完成 | | NME-T11 | AI 生成 M3 修補 | 多回合世界驗證及審查 | 關掉功能規避失敗 | | NME-T12 | 高權限腳本要求升級 | 權限提示和授權閘門 | 假稱 PCK 是沙盒 | | NME-T13 | 發行檔被替換 | 摘要或來源檢查揭露不符 | 只比對檔名 | | NME-T14 | 授權不清的 MOD 要求轉正 | 保留不批准狀態 | 技術 PASS 即收錄 | | NME-T15 | 低頻但重大存檔損壞 | 高優先級處理與恢復路徑 | 因票數少而忽略 | | NME-T16 | 作者申訴錯誤不相容標籤 | 可更正紀錄且保留歷史 | 無申訴與解釋 | 這份矩陣仍需按真正的遊戲引擎、作業系統、平台與產品玩法轉化成 executable tests。它們是研究驗收條件，而非已執行的測試報告。 --- ## 附錄 I．縮寫與概念對照 | 縮寫 | 中文 | 英文 | |---|---|---| | ANIE | AI 原生互動企業論 | AI-Native Interactive Enterprise | | NME | 原生 MOD 生態 | Native Mod Ecosystem | | SEC | 穩定擴充契約 | Stable Extension Contract | | MACR | 多軸相容關係 | Multi-Axis Compatibility Relation | | AAMC | AI 輔助 MOD 遷移閉環 | AI-Assisted Mod Migration Closure | | PDID | 玩家—開發者相交域 | Player–Developer Intersection Domain | | NSN | 非服從式協商 | Non-Subordinate Negotiation | | SDK | 軟體開發工具組 | Software Development Kit | | API | 應用程式介面 | Application Programming Interface | | CI | 持續整合 | Continuous Integration | | UGC | 使用者產生內容 | User-Generated Content | | SIR | 存檔完整性保留 | Save Integrity Retention | | PRV | 玩家世界恢復能力 | Player Recovery Viability | | UNKNOWN | 不足以作通過或失敗判定 | Unknown / Insufficient Evidence | --- # 參考文獻與前置研究 本篇外部來源以 **2026-10-16** 可取得之官方規格、平台文件及研究資料為界。官方功能和平台政策後續可能更動；部署時仍須以當時有效版本再核對。除特別標明外，公式、分類、假說、案例與附錄規格均屬本文的概念提案或推演，**不是外部文獻已證實之實驗結論**。 ## A．外部規格、官方文件與研究 - **[E01]** Valve／Steamworks Development. *New! Version Control For Steam Workshop Mods*. 2026-01-08. 官方公告，說明遊戲版本分支與 MOD 發行版本的新控制能力。 - **[E02]** Valve. *Steam Workshop Item Versioning*. Steamworks Documentation. 說明 Steamworks SDK 1.60 的 MOD 版本支持、遊戲分支、`GetSupportedGameVersionData`、`SetRequiredGameVersions` 等功能及開發者流程。 - **[E03]** Godot Engine. *Exporting packs, patches, and mods*. Stable Documentation. PCK／ZIP、資源載入、MOD 結構與安全注意事項。 - **[E04]** Preston-Werner, T. 與社群維護者. *Semantic Versioning 2.0.0*. 官方規格。 - **[E05]** JSON Schema. *Draft 2020-12*. JSON 結構、驗證與規格文件入口。 - **[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. 以玩家創作、著作權與社群實務為研究背景。 - **[E07]** NIST. *SP 800-218: Secure Software Development Framework (SSDF), Version 1.1*. 2022. - **[E08]** OpenSSF／SLSA. *Provenance*, SLSA v1.2 Specification. 軟體建置及來源追蹤的供應鏈完整性。 - **[E09]** OWASP Cheat Sheet Series. *CI/CD Security Cheat Sheet*. 外部插件與整合的審查、最小權限及供應鏈風險參照。 - **[E10]** Valve. *Branches (Betas)*. Steamworks Documentation. 說明遊戲分支的建立、測試與使用者選擇。 - **[E11]** Valve. *Steam Workshop Implementation Guide*. Steamworks Documentation. 說明 UGC 接入、上傳、Workshop 能力與法律協議流程。 - **[E12]** mod.io. *Get Mod Dependencies* and *Add Mod Dependencies*. 外部 MOD 平台的依賴描述設計參照；本文不將其作為 Steam Workshop 內建功能。； ## 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 概念，不宣稱本篇已實作該系統。 --- ## 文件版本紀錄 | 版本 | 日期 | 狀態 | 變更摘要 | |---|---|---|---| | v0.1 | 2026-10-16 | Public Working Paper | 首版總體定義、穩定擴充契約、版本向量、世界存檔與安全邊界、AI 遷移、12 項假說、對照實驗及附錄規格 | **Canonical Authoring Notice：** 本 UTF-8 Markdown 檔案為正式研究原始稿；聊天渲染畫面不是 canonical source。數學定界符僅使用 ` $...$ ` 與 `$$...$$`。本文尚未完成同行評審、產品環境部署或跨團隊實證。示意 JSON／YAML 可供後續工程設計與驗證，但不代表現成 SDK、測試執行結果或法律授權。