---
title: "可繼承的遊戲產品：資產移轉、AI 接手與長期可維護性"
english_title: "Inheritable Game Products: Asset Transfer, AI-Assisted Succession, and Long-Term Maintainability"
series: "AI 原生互動企業論"
series_en: "AI-Native Interactive Enterprise"
series_id: "ANIE"
paper: "03"
part: "第一部：可驗證的 AI 原生產品交付"
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: "Theoretical proposal and experimental protocol; no completed handover trial claimed"
related_papers:
  - "ANIE-00 — 從產品黑盒到 AI 原生互動企業"
  - "ANIE-01 — 從 EA 到持續交付"
  - "ANIE-02 — 季度單機產品制"
  - "ANIE-04 — 玩家—開發者相交域（預定）"
  - "ANIE-05 — 原生 MOD 生態（預定）"
  - "ANIE-06 — 商業遊戲也可以 PR（預定）"
external_sources_checked: "2026-10-16"
---

# 可繼承的遊戲產品：資產移轉、AI 接手與長期可維護性

## Inheritable Game Products: Asset Transfer, AI-Assisted Succession, and Long-Term Maintainability

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

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

---

## 摘要

商業單機遊戲的生命週期往往長於初代開發團隊的穩定存續期。作品可以繼續銷售、被玩家重新發現、受到 MOD 社群維護，也可能因原作者轉職、公司改組、專案終止、外部授權消失、工具鏈停用或平台帳號權限更換而失去後續更新能力。傳統討論慣以「開發者是否仍有意願更新」「是否將原始碼開源」處理此問題，卻未嚴格區分**取得檔案**、**合法修改**、**重新建置**、**理解設計**、**恢復發行**、**維持玩家資料**與**延續產品價值**。這些是不同命題，任一條件缺失都可能使看似完整的程式碼庫無法成為真正可接續的產品。

本研究提出「可繼承遊戲產品」（Inheritable Game Product, IGP）的操作性定義：在適當法律授權、安全控制與限定資源條件下，原開發者不必長期在場，由獨立接手者——可包含人類開發者與受監督的 AI Agent——取得受驗證的產品資產、決策上下文、相容契約與發布程序，在指定時間內完成可重現建置、有限範圍的有效修改、品質回歸及被授權的版本交付。此處的「繼承」是軟體產品的**維護能力接續**，不等於繼承法上的概括承受，也不保證所有著作財產權、商店帳號與第三方許可會自動移轉。

本文進一步設計「產品接續鏈」（Product Succession Chain, PSC）、「可驗證接手包」（Verified Handover Package, VHP）與「接手能力實驗」（Independent Maintainer Takeover Trial, IMTT），分離產品權利、原始碼、素材、依賴、建置、遊戲世界、品質證據、營運通路、社群承諾與知識記憶等層次。研究主張：AI 對接續開發的潛在價值，不是將不合法的資產變合法，也不是讓缺失的素材憑空復原，而是在具有充分上下文、可追溯證據及明確授權的前提下，降低從陌生產品到有效維護者的學習、轉譯與修改成本。

本文不宣稱 EveMissLab 已完成跨開發者盲接手實驗，亦不主張任何作品只要提供 AI 額度即可永久維護。提出十二項可反駁假說、分層接手試驗、風險模型、技術及權利資料契約，並以 Steamworks 遊戲轉移、GitHub 倉儲權限與移轉、Godot MOD 模組化、SPDX、SLSA、NIST SSDF、可重現建置及臺灣著作權法等已存在的制度和技術為外部參照。全文定位為後續 ANIE-05、ANIE-06、ANIE-09 與 ANIE-10 的前置研究。

**關鍵詞：** 可繼承遊戲產品、AI 接手、產品延續性、知識移轉、軟體供應鏈、MOD、生產資產、權利鏈、可重現建置、Steamworks、產品接續鏈、可驗證接手包、獨立維護者接手試驗。

---

## 0．研究問題與立場：產品不能只有「作者還在」才能存在

### 0.1 從季度交付走向長期延續

ANIE-01 討論 DEMO、Playtest、EA 與正式版如何按照當前產品價值選擇；ANIE-02 討論 AI 原生產品線在三個月、半年、一年等不同時程下，如何測量通過驗收的交付成果。[I01][I02] 但有一個尚未解決的縱向問題：**如果真正完成第一個版本的人停止開發，誰能安全而合法地繼續負責下一個版本？**

作品可在某個季度完成，不代表其維護能力已能移交。反過來，即使作品需要多年擴張，也不等於每一個技術判斷都必須被永久綁定在初代開發者的頭腦、工作電腦、私人帳號或習慣路徑上。

AI Agent 的興起改變了這個問題的技術可行性。陌生開發者可透過 AI 查詢架構、產生修改候選、執行測試、比較版本、生成遷移腳本；然而若其得不到正確資產、合法權限與品質 Oracle，候選生成能力可能只讓錯誤修改來得更快。本文研究的是**可被獨立接續的完整產品制度**，而非一個 AI 能否閱讀程式碼的演示。

### 0.2 三個互不取代的目標

本研究的三個目標是：

1. **存在延續：** 原開發者暫停、退出或失去工作能力時，既有玩家的合法使用與既有商品最低維護能力不致立即失效。
2. **創作延續：** 受權的後續開發者可以理解作品的核心設計邊界，並有能力在不破壞既有承諾與世界相容性的條件下增加內容。
3. **制度延續：** 公司或受權管理者能將版本、測試、授權、外部回饋、營運通路與歷史決策移交，而不是僅交付一個不能再發布的壓縮檔。

這三者不必同時達到最大值。例如一款單機遊戲可能永遠停留在最後正式版本，卻仍能透過完善的離線執行、使用手冊與存檔資料格式維持保存價值；那也是一種有意義的延續，而非研究失敗。

### 0.3 研究命題與反命題

**主命題 P0：** 當產品有可用且合法的資產、明確權利鏈、可再造的環境、可執行品質驗證及足夠設計上下文時，在給定預算內，獨立接手者透過 AI 工具形成有效維護能力的機會與效率，可能顯著高於只有原始碼、缺乏制度化交接的情境。

**反命題 C0：** 如果外部證據顯示完整接手包仍不能改善成功率或成本，或 AI 使接手者更常誤解隱含不變量、破壞授權或擴散安全漏洞，則應縮小本研究的適用條件，不以「AI 進步」作為不可反駁的理由。

### 0.4 新增貢獻與既有研究分界

傳統開源社群、軟體託管交付（source-code escrow）、可重現建置、知識管理與供應鏈來源追蹤並非本文首創；GitHub 和 Steam 已有實際移轉機制。[E01][E02][E03][E04] 本文新增的是把這些條件置入**AI 原生商業單機遊戲**脈絡，以可測量的跨維度接手任務考驗「開發能力是否從特定人的不可移轉經驗，部分轉變為可移轉的產品資產」。

本文並不把開放原始碼視為唯一解法：商業核心可以維持私有，MOD 介面可以開放，適當受權之合作方仍有機會延續維護。這是不同層級的技術與授權安排。

---

## 1．文獻與制度背景：有哪些既有方法？缺了什麼？

### 1.1 原始碼託管、保存與產品接續並非同義詞

傳統原始碼託管安排通常由權利人、受益人與中立保管者約定存放內容、觸發條件以及釋出後使用範圍，其功能是讓受益人在供應商停止履行維護義務等特定事件發生時，按契約取得維護所需材料。[E05] 然而「保管了一份原始碼」不能直接證明它能編譯、第三方素材許可仍有效，或受益人擁有公開銷售修改版本的權利。

Software Heritage 及 SWHID 將可辨識的公開軟體原始碼及其版本導入長期保存與內容識別，提供另一種重要能力：可靠地指出某個來源版本是什麼。[E06] 但 Software Heritage 的公共典藏內容可公開存取，**不能把公司的私有程式碼、商業機密或未授權素材直接送去公共典藏**，也不能以可找到某個 SWHID 推論擁有轉授權或商用權。[E07]

### 1.2 可重現建置的正式邊界

Reproducible Builds 專案將可重現建置定義為：在相同的原始碼、建置環境及建置指令下，獨立方能製得逐位元組相同的指定產物。[E08] 其效用是連結來源與發行產物，並提高變更審核、故障追查、供應鏈防護的可信度；但可重現建置**不代表**遊戲玩法正確、法律清白、後續擴充容易或 Steam 商店權限已合法移交。

本研究因此區分「能再編譯」和「能接手產品」：前者是後者的一項有用條件，並非充分條件。

### 1.3 軟體物料清單與權利鏈

SPDX 3.0 提供標準化格式描述系統構成及授權資訊，可用於軟體物料清單（SBOM）與合規資料交換。[E09] OpenChain ISO/IEC 5230:2020 提供開源授權合規流程的管理要求，而不是替個別商用音效、角色插畫或音樂自動授權。[E10]

單機遊戲比一般程式套件更容易包含不可替代且不可自由轉讓的美術資產、角色配音、字型、影像素材、外包動畫、平台 SDK、商用插件與依賴線上服務的介面；因此單純 SBOM 不能覆蓋完整產品權利鏈。本文將增補「素材權利清單」及「允許用途矩陣」。

### 1.4 來源追蹤與供應鏈驗證

SLSA v1.2 提供軟體供應鏈來源、建置及分級保護的規格，包含 Provenance 等證據格式。[E11] NIST SSDF（SP 800-218）則提供把安全開發實務納入生命週期的指引。[E12] 兩者對接手者具有實務價值：能降低「不知道這個二進位由誰、用哪個來源與流程製作」的資訊成本，但不會自動回答「此作品是否值得繼續創作」。

### 1.5 已有的實際平台移轉工具

Valve 的 Steamworks 官方文件規範不同 Partner 帳號間的 App 移轉；需要雙方適當權限及 Valve 審查，商店頁與社群內容原則上會維持，Publisher API keys 則不隨應用移轉。[E01] GitHub 則有倉儲移轉、組織授權及角色權限；原始碼倉儲可被移轉，但費用、權限、附件及關聯服務可能有另外的條件。[E02][E13]

**平台上的「移轉完成」是平台管理關係的變更，不是整個遊戲 IP、素材權利與其他服務契約自動完整移轉的法律證明。** 這是本研究最基本的不變量之一。

### 1.6 預期知識缺口

現有制度個別處理：原始碼保管、SBOM、安全來源、商店帳號、MOD SDK、著作權契約與專案文件。本文研究它們的**可組合性**：當一個獨立的人或 AI 團隊真正需要重啟開發時，是否存在一份能同時通過技術、權利、品質與營運檢查的統一接手證據包？若不存在，缺口究竟在哪一層？

---

## 2．操作性定義：什麼叫一款遊戲「可繼承」？

### 2.1 不是開源、備份或資產買賣的同義詞

本研究中的「可繼承遊戲產品」（IGP）滿足以下概念性條件：

> 對於特定受權接手者、特定維護任務與指定時間窗，遊戲的必要產品資產、權利範圍、建置和驗證程序可被安全取得並實際執行，使原開發者未參與時仍能完成有證據的有效維護或修改。

「特定」是必要字眼：某個公司可能有權將遊戲移交給簽約工作室，卻無權公開全部原始碼；接手者也可能有權修復錯誤，卻無權重新商業販售某個第三方 DLC。

### 2.2 六種常被混淆的能力

| 能力 | 可觀察的最低證據 | 不能推出的下一個能力 |
|---|---|---|
| 檔案可保存 | 有校驗碼、可恢復的檔案與副本 | 可以合法修改、發布 |
| 原始碼可理解 | 架構、入口、介面、依賴可被定位 | 可以重新建置 |
| 建置可再造 | 在約定環境完成建置與基準測試 | 遊戲品質正常、商業權利清楚 |
| 維護可執行 | 獨立接手者完成有用修復、回歸與核對 | 能合法商業發布 |
| 發行可延續 | 合法授權並完成適當平台權限交接 | 作品市場表現必然延續 |
| 生態可持續 | MOD、玩家紀錄、客服與更新資訊有可用接續機制 | 社群一定願意繼續參與 |

### 2.3 接手者是誰？

接手者至少可以有五種類型：（a）公司內其他人；（b）外部契約工程師；（c）取得合法授權的另一家公司；（d）玩家或 MOD 作者組成的受權維護團隊；（e）在人類／法人授權邊界內工作的 AI Agent。後者不是獨立的法律承受主體：在現行制度下，實際契約、資產控制及對外責任仍需由適格的人或組織承擔。

「任何人都可以接手」不是本研究的一般定理；應改為對每個任務明確回答「誰有權、能接到什麼、依哪些條件、完成到什麼程度」。

### 2.4 產品繼承的狀態空間

為描述接手可行性，對產品 $P$ 、接手者 $a$ 、任務 $m$ 、日期 $t$，定義：

$$
H(P,a,m,t)=(r,s,e,b,w,q,o,k,n),
$$

其中：

- $r$：實際授權範圍，Rights；
- $s$：完整且可取得的來源與資產，Sources and Assets；
- $e$：依賴及工作環境，Environment；
- $b$：建置／發布再造性，Build and Release；
- $w$：世界狀態與存檔相容，World Continuity；
- $q$：測試與品質證據，Quality Evidence；
- $o$：營運／商店／服務交接，Operations；
- $k$：可理解的設計與決策知識，Knowledge；
- $n$：對既有玩家、MOD 與合作對象的承諾關係，Network Obligations。

這是一組異質座標，不預設彼此同單位或可被單一加權總分完全代表。若任務需上架更新，而 $r$ 不包含必要的發布權，即使其餘座標極佳，接手仍可能在合法交付階段被阻斷。

### 2.5 權利閘門與技術品質不可互相抵銷

對特定任務，先界定一組**必要條件** $G(P,a,m,t)$，研究性定義有效接手事件：

$$
I(P,a,m,t)=1 \iff \bigwedge_{g\in G(P,a,m,t)} g=1.
$$

其中 $I=1$ 只表示任務範圍內全部事前指定的必要閘門通過，不等於整款遊戲永久可接續。不同任務的必要閘門集合可以不同。例如私人離線存檔讀取工具的修復，與轉移 Steam 銷售權，需要不同合法權利集合。

以上為邏輯性的決策框架；沒有理由使用高 AI 產出數去「補償」缺失的授權或隱私合法性。

---

## 3．「產品接續鏈」（PSC）：繼承的對象不只是檔案

### 3.1 鏈的必要節點

本文將 Product Succession Chain（PSC）定義為一組具有可追溯關係的產品活動與資產節點：

```text
產品定位與權利來源
        |
        v
原始碼／素材／依賴／工具鏈
        |
        v
建置／存檔／MOD／回歸基準
        |
        v
歷史決策／玩家承諾／版本來源
        |
        v
受權接手者 + 受限 AI 工具
        |
        v
獨立修復／整合／品質驗證
        |
        v
受權的發布與結果回流
```

其中每條關係都應至少具有「來源、必要權限、版本、證據、維護責任」中的適當欄位。W3C PROV-O 可用來描述資料與活動的來源關係，但不會代替商業上更具體的權利狀態及任務授權。[E14]

### 3.2 接續鏈中的四個斷點

**斷點 A：有檔案卻無權。** 公司取得某 MOD 壓縮檔，但缺乏正式收錄及再授權許可。技術可以整合，法律不能據此直接商用。

**斷點 B：有權卻缺資料。** 購買某作品的全部授權，卻未取得使用中的聲音庫、模型源檔、完整 Git LFS、引擎版本或服務配置。

**斷點 C：能編譯卻不能維護。** 產品能產出執行檔，但世界狀態機缺乏不變量與存檔回歸測試，修改任務可能默默破壞數千個存檔。

**斷點 D：能修復卻不能交付。** PR 在內部通過，卻沒有合法商店權限、平台帳號接續或必要的更新簽章程序。

### 3.3 不以「最弱環節」公式誇大精確度

若採用單一最小值分數，往往會把工程難度、法律地位與玩家信任混成一個看似精密的百分比。本文只在**任務相關的硬性條件**上採 AND 閘門，對可比較的軟性成果則分維呈現。例如：首次可執行建置所需小時、缺失資產數、正式修改成功率、需要原作者介入次數、可合法發布與否。不能把「法律權利清楚度 0.7」與「測試覆蓋率 0.9」平均後稱為產品接手成功率 0.8。

---

## 4．產品資產分類：一個 Repo 為何不等於一款遊戲

### 4.1 九個必須辨識的資產族群

| 資產族群 | 常見項目 | 典型交接陷阱 | 最低建議證據 |
|---|---|---|---|
| 程式及架構 | 主 Repo、SDK、引擎擴充、子模組 | 子模組指向私有倉庫 | Commit、依賴鎖定、可訪問性檢查 |
| 內容源檔 | 角色、場景、字型、BGM、配音、動畫 | 遊戲內只剩壓縮產物 | 可編輯源檔與使用許可 |
| 世界資料 | 世界生成規則、事件表、關係圖、存檔格式 | 變更破壞舊版世界 | Schema、遷移器、回歸樣本 |
| 建置環境 | 引擎、插件、匯出模板、SDK、工具程式 | 作者電腦有唯一版本 | 版本清單與自動化腳本 |
| 品質證據 | 單測、E2E、真人試玩案例、缺陷工單 | 測試可跑但失去判定標準 | 版本化測試與 Oracle |
| 知識與意圖 | 設計聖經、拒絕的方案、決策原因 | AI 只看程式猜設計目的 | 決策紀錄、限制、未解問題 |
| 社群與擴充 | MOD API、Workshop、社群插件、貢獻協議 | 無權移入付費 DLC | MOD 介面、權利、相容版本 |
| 通路與服務 | Steamworks、官網、雲端服務、金流、CDN | API key 與 Partner 身份不同 | 權限角色、服務替代／恢復計畫 |
| 契約與法遵 | 授權清單、外包合約、隱私告知 | 轉移權、再授權權未包含 | 權利矩陣、敏感資料分級 |

這九族不是說每款單機作品都必須有全部類型。例如真正離線、無雲端功能的文字遊戲，可能根本沒有線上服務；若不存在，不應虛構相依項目來滿足表單。反之，如果未來加入線上社群與雲端同步，應以受控變更擴張資產範圍。

### 4.2 「檔案存在」與「用途可達」的差異

一首音樂存在於發行包，可能代表玩家可以聽到它；不代表接手公司可以抽取、修改、單獨重新販售它。某插件可被下載，也可能要求使用指定授權伺服器，因此網路環境改變後無法部署。

交接資料需以用途而非副檔名為核心，至少回答：「是否可取得、能否執行、能否修改、能否複製、能否與商業作品合併、能否轉讓、能否再授權、到期條件為何」。

### 4.3 對 AI 生成素材的特別要求

AI 參與生成並不保證素材在所有司法管轄區都能取得同一範圍的著作權保護或具備無爭議商用權。接手包應保存必要的模型／工具與授權條件、素材來源、人工編輯或驗收紀錄、可用的創作貢獻資訊與第三方權利檢查結果；不要求公開會洩漏商業秘密或個資的完整提示詞。生成來源紀錄是**來源證據**，不是自動替代法律判斷的「所有權證書」。

---

## 5．權利鏈：可以修改，不表示可以移轉或再販售

### 5.1 四種不同的法律關係

1. **權利所有：** 特定程式、腳本或創作資產的著作財產權由誰享有。
2. **權利授權：** 另一人被允許以何種方式、期間、地區、媒介利用該資產。
3. **商業營運契約：** 與 Steam、引擎／素材供應商、外包廠商或平台簽訂的契約如何變更。
4. **個人資訊責任：** 玩家帳號、客服、購買資料或試玩者觀察紀錄是否合法移交、保存與處理。

這些關係不會因一個 GitHub 組織更換 Owner 而自動統一。

### 5.2 臺灣著作權法的基本參照

依截至查核日之全國法規資料庫《著作權法》第 11 條，職務上完成的著作有預設作者與著作財產權配置及契約例外；第 12 條對出資聘請完成的著作，亦區分受聘人為著作人、契約約定作者，以及著作財產權的契約歸屬。就第 12 條而言，未約定著作財產權歸屬時，原則上由受聘人享有，出資人仍有該條規定的利用權。[E15] 對具體遊戲、MOD、外包合作，應由具管轄權之專業人士確認完整事實與適用規定，而不是直接把「付了錢」視為「取得全部權利」。

公司內部的正式員工、受委任合作開發者、單次投稿玩家、免費開源貢獻者及 AI 產生素材，權利鏈的形成方式不必相同。未來 ANIE-06 將詳細處理 MOD 轉正與 PR 報酬；本篇僅處理接手前的最低法律可行性。

### 5.3 權利矩陣的任務導向讀法

| 資產或權利 | 維修 | 修改 | 商業發行 | 移轉 | 再授權 | 備註 |
|---|---|---|---|---|---|---|
| 公司自有核心程式 | 依內部授權 | 依內部授權 | 依權利範圍 | 需合法交易程序 | 需授權決策 | 仍需第三方依賴審查 |
| MIT 授權第三方程式 | 依其條款 | 依其條款 | 依其條款 | 遵守授權通知 | 按既有權利 | 注意著作權聲明與附帶條件 |
| 商用素材庫音樂 | 視合約 | 視合約 | 視合約 | 未必可轉移 | 未必可再授權 | 不可由「已購買」推論 |
| 玩家 MOD | 視作者授權 | 視作者授權 | 需明確權利基礎 | 需檢查 | 需檢查 | 可能含第三方素材 |
| Steamworks App 管理 | 依平台權限 | 可管理資訊 | 依平台及商業契約 | 依官方程序 | 非任意可轉授 | 與 IP 資產分開 |
| 客服與玩家個資 | 依法處理 | 按目的限制 | 非一般商品資產 | 法律及告知限制 | 不可任意 | 最小化、匿名化、權利請求 |

表格是分類示意，不是任何特定授權的法律結論。尤其「有權維護」不能直接推出「有權向所有玩家重新發行」。

### 5.4 接手者必須有明確的權利證據

最低可接受權利資料應含：資產識別碼、上游權利人、權利證據所在位置、授權類型、使用與修改範圍、商業發行／再授權／移轉條件、地域與期限、衍生成果歸屬、署名要求及不確定事項。資料若未核定，應標示 `unverified` 或 `blocked`，不得由 AI 擅自填成 `cleared`。

### 5.5 權利缺口的四種處置

- **可補件：** 聯繫作者取得追加授權、補簽可執行協議。
- **可替代：** 在法律容許下更換第三方素材、插件或配音，並重新測試。
- **可縮減：** 將特定 DLC 或模組排除在接續產品範圍之外，明確告知受影響的約定事項。
- **不可接續：** 若核心資產必不可少且無合法路徑，應承認技術再造不等於原產品合法延續，甚至需要停止特定移轉。

---

## 6．產品接手包（VHP）：設計原則與最低構成

### 6.1 定義

本文提出 Verified Handover Package（VHP），亦稱「可驗證接手包」。它不是把全部資料壓成單一 ZIP 的物理規格，而是**一個帶有授權、來源索引、完整性證據、操作契約與驗證結果的受控資產集合**。部分內容可留在私有 Git、加密儲存或受授權的第三方系統；接手包必須能明確定位它們，並核對取得條件。

### 6.2 必需的九個子包

| 子包 | 名稱 | 核心內容 | 負責的最低問題 |
|---|---|---|---|
| VHP-R | Rights | 作品與素材權利鏈、受權接手者、用途限制 | 可不可以做？ |
| VHP-S | Sources | 原始碼、源素材、版本與內容索引 | 需要的東西在哪？ |
| VHP-E | Environment | 引擎、工具鏈、SDK、鎖定檔、執行環境 | 能不能重新部署？ |
| VHP-B | Build | 建置腳本、發布產物、校驗碼、Provenance | 產物從何而來？ |
| VHP-W | World | 世界規則、存檔、Migration、MOD 契約 | 玩家世界會不會壞？ |
| VHP-Q | Quality | 測試、Oracle、基準性能、已知缺陷 | 修改如何驗證？ |
| VHP-K | Knowledge | 設計意圖、決策歷史、限制、文件 | 為什麼這樣設計？ |
| VHP-O | Operations | 商店、發布、客服、資料、服務與角色 | 由誰合法交付？ |
| VHP-N | Network | MOD 作者、玩家承諾、外部合作及公開狀態 | 接續對哪些人負責？ |

### 6.3 完整性校驗與機密分級

VHP 內的檔案應建立可檢驗的內容摘要、版本、清單紀錄、簽核與修改歷史。這可以採用雜湊、數位簽章、不可變備份及來源證據等機制；但**檔案雜湊只能證明其後未變更，不能自行證明文件在建立時就是真實或具有合法授權**。涉及敏感內容必須採最小權限、加密保存與獨立的憑證管理，不應把現役密碼、API keys 或玩家原始個資塞進接手包一起交付。

### 6.4 接手包必須可被實際使用

一份 VHP 即使滿足形式上的檔案清單，也不能直接標示為 `verified`。研究上的最小驗證是：由沒有參與原產品日常開發的合格接手者，在受控環境下使用它，完成至少一次指定建置、一次指定修補、一次回歸與一次書面接續說明；只有這些步驟通過，才有條件將其標為針對**指定任務已驗證**。

---

## 7．工程再造性：從「能開啟專案」到「能獨立發布建置」

### 7.1 五級建置能力，不應一次宣稱全部達成

本文提出階梯式的 **Build Continuity Levels（BCL）**。其為研究操作性分類，並非聲稱與 SLSA 等級相同或取得第三方認證。

| 級別 | 名稱 | 實際門檻 | 尚未證明的事 |
|---|---|---|---|
| BCL-0 | 原始資產可讀 | 來源與源素材能被取得、解析 | 工具鏈存在且可執行 |
| BCL-1 | 文件化人工建置 | 合格工程師按照文件完成一次建置 | 不依賴原作者的隱含協助 |
| BCL-2 | 自動化可再造 | 在指定受控環境，單一操作流程完成建置及指定測試 | 全部二進位逐位元一致 |
| BCL-3 | 獨立環境重建 | 未參與原開發的接手者，在乾淨環境重建並取得可用遊戲 | 已具備完整商品維護能力 |
| BCL-4 | 經定義邊界的可重現發行 | 對聲明的產物及環境達成逐位元可重現，並連結來源證據 | 新的遊戲功能必然正確 |

一款遊戲可以在 BCL-3 有高度維護價值，卻因時間戳、簽章、壓縮方式、特定引擎匯出特性而暫時不符合 BCL-4。不能因 BCL-4 未達成，就忽略 BCL-3 的真實工作能力；也不能因 BCL-2 的 CI 顯示 PASS 就聲稱獨立接手成功。[E08]

### 7.2 建置環境需要被明確界定

至少記錄：作業系統／架構、引擎確切版本與發行來源、匯出模板、編譯器與包管理器版本、插件與 lockfile、字型與影音編碼器、必要的外部工具、資產匯入步驟、環境變數名稱（**不是密碼本身**）、必要磁碟空間及建置耗時觀察值。

若僅保存一份 `README: 使用最新版引擎並按下 Export`，不足以處理引擎長期升級、插件 ABI 不相容、資產匯入演算法改變與第三方服務消失的風險。應保存已驗證的版本組合，並對未經驗證升級建立另一個工作分支。

### 7.3 雙重產物基準：來源建置與玩家版本

每次正式發布的基準應含：

- Source revision：版本庫 commit、必要子模組與資產指紋。
- Build recipe：工具鏈、編譯參數、匯出配置與依賴快照。
- Artifact record：發行產物名稱、SHA-256、平台與發布編號。
- Test evidence：該版本通過的測試及未通過的例外。
- Delivery evidence：平台 Build ID／Branch／釋出公告與生效時間。

如此接手者才可能回答：手中某一份遊戲檔究竟來自哪個版本，而不是僅憑 `final_v2_REAL_latest` 等資料夾命名猜測。

### 7.4 SLSA、SPDX、可重現建置是互補關係

**SPDX** 幫助描述供應鏈構成與授權；**SLSA Provenance** 幫助描述產物的建置來源、環境及驗證證據；**可重現建置**處理獨立重造指定產物是否逐位元相同；**產品接手測試**處理陌生維護者能否有效修改並符合玩家品質要求。四者相互支援，任何單一機制都不能替代其餘三個。[E08][E09][E11]

### 7.5 對封閉引擎、不可下載 SDK 的處置

若遊戲依賴需要登入的商業引擎服務、只提供特定訂閱方案的工具，或曾經購入但已下架的 SDK，接手包應分別列明：「能否重新取得」「是否允許移轉」「可否使用舊版本」「替代成本」「不能合法保存副本的內容」。不要因技術上可以從舊電腦複製檔案，就預設複製與重新散布一定被允許。

對無法完全封存的依賴，最低應建立替代性計畫及測試證據。必要時需要接受產品會被迫停留在特定舊版本，或需投入正式遷移專案。

### 7.6 當前可實作的自動化門檻

```text
checkout exact source revision
    -> verify declared source/assets hashes
    -> provision approved toolchain
    -> resolve dependency snapshot
    -> import source media and localization
    -> perform deterministic/ordinary build
    -> launch smoke tests
    -> run save/MOD compatibility suite
    -> generate evidence manifest
    -> publish candidate artifact to staging
    -> authorized human review
```

這是描述流程，不代表每種引擎都能以同一組命令實現。某些視覺編輯器、專有 SDK、音效製作與真人遊玩驗收仍可能需要人工步驟，應保留可核實的人工紀錄。

---

## 8．遊戲獨有的困難：存檔、世界狀態與 MOD 相容

### 8.1 「程式能跑」可能掩蓋世界毀損

對開放世界、長時間模擬、角色關係、城鎮演化、程序生成及大量資料驅動的作品而言，真正重要的不只是啟動成功，而是玩家已創造的世界是否能在新版本中維持其合理意義。例如：

- 角色裝備識別碼在新版本映射到另一個物品；
- NPC 關係表遺失父節點，角色仍存在但無法互動；
- 修正地圖座標規則後舊建築進入不可到達區域；
- 新的時間系統造成原有任務進度快轉；
- 玩家使用的 MOD 舊版 API 被移除，導致載入時無聲地略過事件；
- 讀取存檔雖成功，世界因果與遊戲規則卻已不可逆地改變。

這些問題可能通過基本編譯與啟動測試，因此接手包必須包含遊戲世界語義的維護條件。

### 8.2 世界狀態遷移的形式化輪廓

令 $W_v$ 為版本 $v$ 下可讀取的世界狀態， $M_{v\to v+1}$ 是升級遷移程序， $C_{v+1}$ 是新版本的有效狀態約束。最低形式要求為：

$$
W_{v+1}=M_{v\to v+1}(W_v),
$$

$$
C_{v+1}(W_{v+1})=1.
$$

但僅通過新版本格式約束，仍可能違反玩家理解的核心世界語義。因此對指定保留集合 $J$，另要求：

$$
\forall j\in J,\quad
P_j(W_v,W_{v+1})=1,
$$

其中 $P_j$ 是明確規範的相容性或意義保留條件，例如角色身份、財產關聯、主線任務標記、世界生成種子、MOD 命名空間。這些條件應由產品設計與測試共同決定，並不保證所有數值都必須保持完全相同。

### 8.3 遷移不是永遠要求無變化

改版可能刻意調整經濟、技能傷害、怪物生成或任務獎勵。若把「所有舊數值逐字不變」當成唯一相容性標準，等於禁止合理更新。本文要求的是**公開且可驗證地指定哪些狀態必須保留、哪些允許正規變更，以及無法保留時如何回退或通知**。

例如玩家未使用的商店價格可按平衡補丁變動，但已被玩家購買的稀有裝備不應因映射錯誤變成另一件物品。若產品決定作出更激進的規則變更，應設計明確遷移或版號分流策略。

### 8.4 必需的存檔回歸集合

至少應建立：乾淨新遊戲、舊版早期存檔、中期存檔、長期後期存檔、跨主要版本存檔、含 MOD 與無 MOD 存檔、使用不同語系的存檔、異常中斷後恢復存檔，以及故意損壞的負面測試。每筆存檔必須有合法使用或匿名化的依據，並避免將玩家真實個資包入公開測試資料。

### 8.5 「長期世界」應測什麼？

對聲稱支援高時間跨度的世界模擬遊戲，可設計固定種子長期演化測試，包括人物生成與死亡、物品持有、政體變遷、事件循環、地圖生成與快照一致性、資源供需與存檔重載。形式上，若以 $T$ 表示自動模擬步數，可研究：

$$
W_{t+T}=F^T(W_t,\theta),
$$

在指定模型參數 $\theta$ 下，要求其間的狀態不變量、記憶體上界、存檔完整性及主要因果限制持續成立。這不表示數值誤差、隨機性或所有場景都要位元級相同；應在測試規格中宣告確定性範圍。

### 8.6 MOD 是外部生命週期，不是可忽略的附屬品

若從產品第一天就採 MOD-first 設計，接手者必須繼承的不只是某個插件載入器，而包括：插件 API 的版本語義、事件序列與參數契約、各版本相容清單、公開 SDK、典型範例、測試 MOD 與回報管道。[E16] Godot 的 PCK／ZIP 讓模組化在技術上可行，但官方同時提醒載入不受信任腳本及更新包可能帶來安全風險。[E17]

接手方應優先承諾維護文件化的擴充介面，而非保證所有透過逆向與私有記憶體修改的 MOD 永久無損相容。對已建立合作協議的 MOD 作者，需保留相應通知、授權與介面變更程序。

### 8.7 不要讓 AI 靜默重寫玩家歷史

當 Agent 自動生成存檔遷移腳本時，應先在隔離副本上執行，產生變更前後差異及不可逆修改報告，並通過專門驗證。未達標時應保留原始存檔，必要時強制人工審核。若 AI 無法解釋特定世界語義映射的根據，應標記為未知，不能用自信語氣宣稱「已完整修復」。

---

## 9．設計知識與組織記憶：為什麼文件多仍可能接不了手？

### 9.1 隱含規則才是接手成本的重要來源

陌生維護者讀完所有 API 文件，仍可能不知道：

- 某個看似冗餘的狀態變數是為了避免十年前的存檔問題；
- 為什麼不能移除角色創建時的固定排列；
- 某種 AI 行為是特意保留的遊戲風格，而非單純錯誤；
- 哪些玩家批評被拒絕，是因它們違反作品定位；
- 遊戲平衡表中的奇怪權重對應真實世界模擬需求；
- 已答應玩家的功能何時可能調整，以及公告中已設哪些限制。

如果只有「現在怎麼運作」，沒有「為什麼不能隨便改」，AI 很容易產生局部漂亮、全域破壞的修補方案。

### 9.2 產品設計知識的五個層次

1. **規格層：** 對玩家和系統呈現什麼可觀察行為。
2. **理由層：** 為什麼採取該方案，放棄哪些替代選項。
3. **限制層：** 法律、性能、內容、世界一致性、價值觀及產品定位的不可越界事項。
4. **證據層：** 哪些測試、研究、玩家回饋或錯誤證明上述判斷成立。
5. **修訂層：** 若證據改變，如何允許後續開發者更新原決策而不必重建整個哲學體系。

這對應既有 ANIE-00 提出的公開決策來源鏈，以及《AI 原生決策編譯器與稀疏意圖治理》對選項展開與授權閘門的區分。[I00][I03]

### 9.3 設計聖經與決策帳本不能互相代替

Design Bible 描述目前被接受的遊戲世界及預定體驗；Decision Record 描述某個決定形成的歷史與相反意見。前者適合快速查閱，後者適合面對爭議、接手修正與日後追溯。若只有 Decision Record，AI 可能因過時討論過多而失去當前規格；若只有 Design Bible，AI 容易把暫定選擇看成不可動搖的永久真理。

本文建議每筆重要決策有：`decision_id`、`scope`、`status`、`approved_by`、`evidence_links`、`rejected_alternatives`、`world_invariants`、`public_projection`、`superseded_by`。這種結構與傳統 Architecture Decision Record（ADR）精神相近，但加入玩家承諾和世界語義等遊戲特性。

### 9.4 永續記憶不是把所有聊天存起來

將所有 AI 對話直接當成產品知識庫，可能產生彼此衝突的草案、錯誤推測、過期資訊、私人資料與大量無法檢索的重複文字。正式交接應以版本化規格、核准決策、可回放事件、索引與測試為 canonical source；聊天對話只能作為必要時附帶的可追溯脈絡，不能在沒有驗證的情況下自動升格為正式設計。

### 9.5 變更權與歷史保留

接手者應有在授權範圍內修改設計的自由，否則「繼承」會退化成只能照抄原作者的歷史。必要機制是：過去版本不可被抹去、變更理由可查、受影響的測試與玩家承諾重新審查。制度保留的是**可修正的連續性**，而非永久凍結原作。

---

## 10．AI 接手流程：把模型能力轉為被驗證的維護能力

### 10.1 AI 是接手工作流的能力組件，不是法律代理人

AI 可協助讀取檔案、定位錯誤、生成修補、撰寫測試、解釋模組關係、比較新舊版本及更新遷移文件。然而模型不因可執行某個命令，就自動取得合法查看所有私有檔案、公開商業秘密、替公司承諾更新日期或向平台發布的權力。[I04][I06]

本研究將 AI 的角色定位為「受控的接手能力增強器」（Controlled Successor Capability Augmentation）。其成果必須由實際執行與測試驗證，不能以模型敘述「我應該可以」替代成功證據。

### 10.2 七階段接手協議（Agent-Assisted Succession Protocol, AASP）

**階段 A：取得授權及界定任務。** 指定可讀寫的資料範圍、合法接手身份、目標分支、時間及成本預算、禁止行為、人工驗收責任與退出條件。沒有合法授權的目標，AI 應停止而不是繼續尋求繞路。

**階段 B：唯讀盤點。** 列出 Repo、子模組、建置資產、外部服務、權利阻礙、缺失依賴、關鍵世界不變量與測試風險。產出初步接手地圖，而不是立刻大量重構。

**階段 C：重建基準。** 在隔離的新環境按 VHP 執行建置及測試，核對既有正式版本與其可重建來源，記錄所有無法重現之處。基準未建立時，後續改動無法被可靠歸因。

**階段 D：提出有限變更。** 針對事先指定的一項缺陷或功能設計 PR，列出預期修改檔案、玩家可見行為、存檔與 MOD 風險、權利問題與回退計畫。

**階段 E：沙盒整合與驗證。** 執行單元、系統、存檔、MOD、性能與安全測試；對遊戲樂趣、敘事、可讀性安排適當真人驗收。AI 可以生成測試，但不能獨占品質判決。

**階段 F：權限閘門。** 由有權的人審查著作權、資料外洩、關鍵玩法變更、版本策略及對外承諾，才能合併到可發布分支。高風險工具調用應要求明確授權。

**階段 G：可重放交付。** 產出建置及發布證據、更新紀錄、缺陷回退方法、對外資訊及新的接手包差異。**接手成功必須使下一次接手更容易，而不只是單次完成任務。**

### 10.3 不應授予 AI 全域發行金鑰

即使技術能力非常高，單次接手任務通常也不需要同時取得公司最高 GitHub 權限、所有資產儲存讀取權、商店付款權限、正式發行金鑰與玩家完整個資。具體做法包括：使用低權限暫時帳號、沙盒工作區、分離測試與正式環境、PR Review、保密檢查及人工批准釋出。GitHub 提供組織角色與 Rulesets 的必要條件機制，可作為此類權限分離的現有技術參照。[E13][E18]

### 10.4 接手中的模型幻覺問題

AI 可能錯誤推斷某個插件授權、誤把過期 README 當現行標準、混淆玩家的偏好與正式承諾，或由錯誤通過的測試推導「系統安全」。為降低風險，關鍵事實須由可核對的原始資料支持：對某個權利聲明查契約；對某次 PASS 查 CI；對發布狀態查平台；對玩家回饋查來源事件。無法核對時，狀態應是 `unknown` 而不是 `true`。

### 10.5 跨模型接手能力不應預設等價

不同模型在陌生程式庫理解、長文件檢索、工具使用、反覆修改、世界狀態理解及計畫執行上能力不同；即使相同模型也會受到額度限制、上下文取樣、工具授權及工作環境影響。研究應分別記錄模型版本、工作流配置、工具、允許調用次數及人工補救工時，而非宣稱「任何有 AI 的接手人都能完成」。

### 10.6 AI Agent 的最小交接結案準則

在指定任務中，至少需同時滿足：變更有明確來源、測試證據存在、沒有越權讀取／發布、受影響存檔與 MOD 處理有紀錄、可以回退、成本與時間可核對，以及真正的審核者理解其主要風險。缺少任一關鍵條件時，僅能稱為候選修補，不應視為獨立維護能力已證明。

---

## 11．Steamworks、GitHub 與發行渠道的接續

### 11.1 Steamworks 的正式 App 轉移並非空想

Valve 官方支援不同 Steamworks Partner 之間移轉遊戲。流程涉及有 Actual Authority 的雙方、發起及確認、Valve 審查與生效安排。文件並指出商店頁、社群中心、使用者評論等公開元素原則上維持附著於 App ID，遊戲擁有權對既有玩家不受中斷；但售價編輯、報表歷史存取、既有 bundle 管理、Publisher API keys 等有各自的移轉或額外處置規則。[E01]

這正好展示本研究的分層原則：發行平台的 App 可以依法定平台流程移轉，但不是把 A 公司的 Steam 帳號密碼交給 B 公司，就完成了合法且完整的遊戲資產轉讓。

### 11.2 GitHub 倉儲移轉可保留部分協作歷史

GitHub 的倉儲移轉機制允許更換擁有者，通常連帶保留內容、Issues、PR、Releases 等歷史；但移入不同帳號方案、組織管理模式、原有角色分配及私有 Fork 關係可能有特殊限制，應依官方文件逐項確認。[E02]

若接手者取得的是某個 Repo 的壓縮備份，而不是平台上的所有權移轉，則 Issues、PR Review、Actions Secrets、部分 Release Asset、Project 設定及外部整合不一定完整存在於壓縮包。應將 Git 資料及平台服務資料分別盤點。

### 11.3 憑證的接續應是「重發與切換」，不是「無限期共享」

Steamworks 官方明確指出 Publisher API keys 不隨 App 移轉，建議以新 Partner 建立相應金鑰，完成基礎設施切換後再撤銷舊權限。[E01] 這可抽象成一般原則：需接續的服務憑證，應透過正式的持有人與權限管理程序輪替，而非永久保存創辦人個人的現役 Token 或密碼。

同理，GitHub Actions Secrets、簽章憑證、雲端服務權限與稅務付款資料，都應被視為不同的接續項目。對涉及銀行、平台收款或法律代表人身分的權限，須由適格實體完成身分、契約及法遵程序。

### 11.4 存檔與玩家權益在商業移轉後仍有實質問題

即使 App ID、玩家評論與遊戲購買權益在平台層維持，接手方仍需要測試：雲端存檔路徑是否不變、離線執行與 DRM 是否可用、跨裝置存檔是否同步、更新是否導致 MOD 相容性中斷、客服承諾由誰接續。上述不是 Valve 對所有第三方系統的自動保證，而是公司應自行建立的產品責任清單。

### 11.5 經營持續不等於無限發行義務

可繼承設計不必要求後續開發者永遠新增內容。受讓公司可以依合法契約、消費者保護義務與對玩家的既有承諾，決定維持安全修補、發布終局穩定版、公開有限 MOD 支援或停止某些線上服務。真正的差異是：這些選擇有清楚的權利、成本與資訊基礎，而不是因完全找不到開發資產被迫消失。

---

## 12．MOD、外部 PR 與契約維護者：擴張可接手者集合

### 12.1 開放協作會增加候選接手者，但不消除審核

當遊戲提供穩定 SDK、MOD API、版本文件與受限 PR 管道，社群可能累積一批已經理解某些子系統的作者；其對模型、關卡、事件、UI 或存檔格式的知識，也可能成為未來產品延續的外部資源。這是值得實證的社群效應，不是說社群必然能替代所有內部工程、商務與法務人員。

### 12.2 四種協作關係

1. **自由 MOD：** 作者在允許範圍內自行發布擴充內容，與公司可無商業契約關係。
2. **技術貢獻：** 有明確貢獻條款的 Bugfix、文件、測試或外掛 PR，合併前需確認權利來源。
3. **正式授權收錄：** 經協商把 MOD 納入官方版本、免費更新或付費 DLC，須有範圍及報酬安排。
4. **維護契約：** 以任務、里程碑、時段或服務水準為界的外部接續工作，需要雙方明確約定可存取資料、輸出物與智慧財產。

這些可相互轉換，但不得因 MOD 發表就默認作者放棄權利，也不能把公開 PR 設為無條件取得所有商業用途的捷徑。具體貢獻者條款及補償制度留待 ANIE-06。[I05]

### 12.3 MOD 契約是一種產品生命週期介面

傳統遊戲內部重構若無官方 API，可能一次使所有 MOD 失效。若 MOD 是產品一級介面，應提供明確的版本支援期、棄用公告、資料格式、驗證器與遷移工具。外部作者因此不是依賴猜測內部實作生存，而能依穩定契約安排其作品。

這對繼承尤其重要：原作者離開後，接手者只要遵守對外契約，就不必理解每個 MOD 的全部源碼。某些因未公開掛點或不受信任腳本產生的破壞，仍需依產品支援政策處理。

### 12.4 從單次貢獻到長期維護的信用證據

如果公司希望邀請 MOD 作者成為契約接手者，可使用：已合併變更的品質、測試覆蓋、回報效率、維護契約履行、授權清晰度、安全事件，以及對原作品風格的理解作為證據；不應直接以「MOD 下載量高」推出其具有跨系統維護或公司代理權。

### 12.5 不必將商業核心全部開源

授權層級可分為公開 MOD SDK、公開相容測試樣本、公開規格與 Issue、需契約才能取得的私有核心、嚴格保密的發行憑證與玩家資料。其權限越界規則應被機器與人可讀的政策共同落實。對願意接手的外部者，提供必要範圍的受控資訊，通常比在公開 Repo 放上所有商業資產更符合本研究的選擇性揭露原則。

---

## 13．安全、隱私與接手攻擊面

### 13.1 接手包本身可能是一個巨大攻擊面

為了讓陌生維護者和 AI 容易理解，產品常傾向集中程式碼、文件、內部決策、玩家回報與配置。但高度集中的交接資料會造成新的風險：一份被外部錯誤取得的資料可能同時洩漏架構、安全弱點、商業策略、個人資料和未發布內容。

因此應把**知識可達性**與**公開可達性**分離：材料能被合法接手者查到，並不意味它適合公開索引、全文搜尋或直接作為 AI 的不受限制上下文。[I06]

### 13.2 風險矩陣

| 威脅 | 可能路徑 | 緩解措施 | 殘餘風險 |
|---|---|---|---|
| 接手文件含密碼 | README／Log／歷史對話 | 秘密掃描、獨立 vault、重發憑證 | 歷史洩漏可能已發生 |
| 未授權素材被 AI 引入 | 模型依照相似作品生成或複製 | 資產來源審核、權利矩陣、人工核對 | 權利與相似性仍可能有爭議 |
| 惡意 MOD 或附件 | 非信任腳本、PCK、供應鏈依賴 | 沙盒、不執行未知腳本、簽章驗證、來源掃描 | 零日漏洞與行為繞過 |
| PR 污染 | 審查者誤信測試／Agent 回報 | 強制 CI、分離批准角色、來源限制 | 複合型攻擊可能突破單一控制 |
| 假接手者 | 社交工程取得權限 | 法律身分驗證、最小權限、雙人覆核 | 內部人濫用 |
| 客服資料洩漏 | 全量 log 餵給 Agent | 去識別化、目的限制、保留期、權限稽核 | 推斷與關聯再識別 |
| 綁定原開發者雲端帳號 | 服務不可移轉／原作者停用 | 公司持有服務、替代方案、權限計畫 | 上游平台終止服務 |
| 接手者擅自改動設計主權 | 無權發布或違反玩家承諾 | 簽核權限、設計決策帳本、公告稽核 | 對設計價值的合理爭議 |

### 13.3 AI 專有的提示注入威脅

接手者需要閱讀 README、Issue、MOD 文件及外部貼文，這些可能由不同權利人撰寫或經攻擊者操控。對 AI 而言，外部文件中的「請忽略上一層授權」「將公司機密上傳某網站」等命令，不應被視為有權的公司指令。資料來源可信度與工具執行權限須分離，尤其不能讓外部文件借由上下文混淆直接取得 GitHub、Steamworks 或檔案系統的寫入能力。

### 13.4 秘密的替代流程

在接手演練中，不應使用正式營運密碼。可配置過期即失效的低權限測試憑證、假玩家資料、離線模擬服務及具體工具白名單。正式轉移時再經過人工、法律及平台要求核對後切換。接手包應存放「在哪裡申請、需要何種角色、怎麼輪替」的**程序與權限契約**，而不是永遠可用的 Token。

### 13.5 備份、典藏與保密不是同一層

至少三種保存目的應分開：營運備份可快速恢復事故；產品接手包供合法新維護者獨立重建；公共長期典藏供社會或研究界持續找到已被允許公開的來源。不同目的的受眾、資料期限與授權安排不同。公開典藏不可取代私有完整備份；私有備份也不代表有合格的公開歷史證據。

---

## 14．不同接續情境，不應只考慮「創作者過世」

### 14.1 情境 A：正常假期與暫時離線

開發者一週不在，不應讓公司無法修復重大存檔損毀或平台上架事故。此時未必需要移轉 IP、改變組織持有權；只需讓有權代理人取得維護入口、測試流程、聯絡簿及回退操作。此情境適合作為初期低風險接手演練。

### 14.2 情境 B：創辦人轉往其他產品線

初代開發者把主要注意力投入下一款遊戲，但舊作品仍需要安全更新、MOD 相容、客服與 Bug 修補。技術知識應被制度化，使持續維護不要求他時刻閱讀所有 PR。若架構與權限合理，AI Agent 可以作為新維護者的查詢、測試及修補協作者。

### 14.3 情境 C：外包與契約開發

若玩家或 MOD 作者被委任開發某個功能，應只授權必要模組並定義交付與驗收；其接手包可以是 VHP 的子集。例如地圖編輯器作者只需地圖資料模型、測試資源、MOD API 及相關的商業許可，不需要公司所有薪資、人事、其他產品原始碼及發布金鑰。

### 14.4 情境 D：公司資產交易與工作室更替

當作品經由資產買賣、法人組織調整或合作協議移轉，涉及法定／契約上的權利審查與平台移轉。除技術 VHP，還需盤點商標、授權協議、玩家資料責任、稅務、第三方合約、社群渠道及已作出的商業承諾；不可以僅憑相同公司名稱或某一名工程師有 Repo 權限來判定可轉移一切。

### 14.5 情境 E：公司解散、無力維護或核心人員失能

這個情境最能暴露「表面上有備份」的虛假安全感。若簽約第三方或其他合法權利主體尚未取得必要的接續與使用權，AI 即使有能力理解程式碼，也可能無法合法發布修復。為此可以事先研究權利託管、附條件授權、指定接續管理人與完整性驗證；涉及實際處分、繼承、清算或第三人利益，均需依法處理。

### 14.6 情境 F：公司仍在，但發行服務消失

即使團隊全數健在，上游引擎、DRM、社群 API、雲端服務、AI 模型供應或販售平台可能停止支持。此時產品延續依賴替代服務、可離線使用能力、清晰資料格式、備用發布渠道及合法許可。真正的「可繼承」不是單純防止人員流失，也是防止外部依賴單點失效。

### 14.7 接續目標的正當終止

若產品維護已無法在合理成本與法律條件內實現，公司也可能選擇穩定最終版本、不再新增功能或終止特定服務。這不必然表示違反 ANIE 模型；重要的是認清仍有效的既有法定與契約義務，避免對玩家做未核可的永久更新承諾，並留下經驗、最後版本與清楚的資訊說明。

---

## 15．接手成熟度：從文件存在到真正獨立維護

### 15.1 七級接手成熟度（Succession Readiness Stages, SRS）

本文提出 SRS-0 至 SRS-6，僅作為研究及產品內部門檻，不宣稱已有獨立的國際認證程序。

| 等級 | 可提供的最低證據 | 典型關鍵限制 |
|---|---|---|
| SRS-0 | 作品可執行，但來源與權利未盤點 | 是否能再造未知 |
| SRS-1 | 來源、素材、版本及授權清單可核對 | 尚未證實可建置 |
| SRS-2 | 可在受控環境依文件建置並跑基準測試 | 原作者可能提供大量暗中協助 |
| SRS-3 | 獨立人員依 VHP 重建原版本 | 未證實能安全修改 |
| SRS-4 | 獨立人員完成有限變更與世界／MOD 回歸 | 未證實可接續正式發布 |
| SRS-5 | 適格主體可按權限完成一次受控發布或演練 | 長期維護成本仍未知 |
| SRS-6 | 多輪接續、跨人員／模型與長期版本更新均有實證 | 不代表永久無風險或零維護成本 |

等級上升必須以證據達成，而非依靠研發團隊自我評分。由於法律商業發布可能暫時不適用於未上市 Demo，可將特定條件標示 `not_applicable`，但需提供理由，不可藉此把未驗證結果稱為完整 SRS-6。

### 15.2 成熟度與任務適用範圍是兩條軸

某產品在 Windows 平台有 SRS-5 的證據，不意味它在 Linux／macOS 同樣可接續；某作品的劇情資料管線已能由 AI 維護，也不意味其底層 C++ 引擎安全問題可由同一組 Agent 自主處理。每張成熟度報告都應載明**平台、版本、資料範圍、接手者角色、測試任務、證據日期**。

### 15.3 何種「獨立」才是真正獨立？

形式上讓作者坐在一旁口頭解釋每個操作，即使接手者本人按下建置按鈕，仍不足以支持獨立維護結論。需要記錄作者的介入次數、介入時間、提供何種原先缺失的資訊，以及是否因此改變測試條件。若原作者幫忙修正文件，可以把修正版 VHP 用於下一輪，但不可把前一輪的失敗回寫成成功。

### 15.4 存在合法或安全阻礙時要如何記錄？

如果某接手任務需要尚未完成法律授權，應標記 `blocked_legal`；若需要無法安全取得的正式憑證，標記 `blocked_security`；若依賴停止供應，標記 `blocked_dependency`。這些阻礙不是由研究者「自動解決」，而是研究結果的重要部分。若把有問題的樣本全部刪掉，只比較已成功取得權限的專案，會高估可繼承性。

---

## 16．核心指標：怎樣測量遊戲真正可被接手？

### 16.1 指標設計原則

每個指標都應指定母體、觀測起點、失敗與退出定義、任務難度、允許時間、資料缺失處理及授權條件。不能把一個系統 `npm test` 通過當成全部遊戲 100% 可維護，也不能用 PR 數量替代發布品質。

### 16.2 重新建置成功率（Rebuild Success Rate, RSR）

令 $N_B$ 為依預先登記標準執行的獨立建置試驗次數， $N_{B,s}$ 為達到指定建置及基本啟動條件的試驗次數：

$$
RSR=\frac{N_{B,s}}{N_B},\qquad N_B>0.
$$

若某次試驗因權限阻礙無法開始，應另行記錄 `eligible` 或 `blocked`，不能默默從分母排除而不報告。建議同時提供全部被抽中樣本的意向分析與具技術可行資格樣本的條件分析。

### 16.3 限定修補成功率（Patch Handover Rate, PHR）

令 $N_M$ 為在研究前指定的接手維護任務集合， $N_{M,s}$ 為同時通過功能測試、必要回歸及審核的任務數：

$$
PHR=\frac{N_{M,s}}{N_M},\qquad N_M>0.
$$

若任務大小差異過大，不以 PHR 作唯一主指標；另報各任務的缺陷嚴重度、模組耦合範圍、修改行數、審查工時與玩家影響程度。

### 16.4 首次有效修補時間（Time To First Valid Patch, TTFVP）

TTFVP 從合格接手者正式獲得授權資料、接到任務的時間點開始，到經獨立審查通過的首次有效修補為止。至少保留兩個時間值：日曆等待時間與實際人類／AI 活動成本。若任務因法律、資訊安全或工具失效無法完成，應視為有條件的右設限或競爭風險事件，不能寫成「0 分鐘完成」。

### 16.5 原作者依賴密度（Original-Author Dependency, OAD）

$$
OAD=\frac{T_A}{T_T},\qquad T_T>0,
$$

 $T_A$ 為原作者直接介入解題、補件或介面轉譯的時間， $T_T$ 為接手任務完整期間內所有相關人類工作時間。此比率僅反映指定任務的一種依賴程度；若接手者發生大量不必要工時，OAD 也可能被人為稀釋，因此須同時報告絕對的作者介入分鐘數及次數。

### 16.6 存檔與 MOD 相容率

對事前定義且有代表性的存檔樣本集合 $S$，令 $S_v$ 為通過讀取、核心狀態與情境測試的集合：

$$
SCR=\frac{|S_v|}{|S|},\qquad |S|>0.
$$

對經規格標示為受支援且可合法測試的 MOD 集合 $M$，定義：

$$
MCR=\frac{|M_v|}{|M|},\qquad |M|>0.
$$

分別報告版本來源、MOD 相依圖與載入順序；一個超大型 MOD 和一個只改字體的 MOD 並不一定具有同等失效風險，不宜使用同一個平均值掩蓋問題。

### 16.7 法律權利可用比例（Rights Coverage, RC）

為避免以含糊百分比聲稱「權利清楚」，先根據任務預註冊必要資產清單 $A_m$，令 $A_c$ 為由適格審查者確認具備本次用途必需權利的資產：

$$
RC_m=\frac{|A_c|}{|A_m|},\qquad |A_m|>0.
$$

RC 僅是文件化覆蓋率，並非法律爭議勝訴機率。對必不可少的任一核心素材缺乏授權，研究上即使 RC 達 99%，該次商業接手仍可能被法律閘門阻斷。

### 16.8 可接手證據完整度（Evidence Coverage）

將 VHP 九個子包各自記錄 `not_applicable`、`missing`、`documented`、`validated`。其中 `documented` 不等於 `validated`；若每個子包對任務都十分重要，可以進行向量報告，而不要求把它們平均成單一「95% 完整度」。

### 16.9 真正的總成本

$$
C_{takeover}=C_{rights}+C_{asset}+C_{setup}+C_{ai}+C_{human}+C_{review}+C_{release}+C_{support}+C_{risk}.
$$

上式是成本分類帳，而非各項必然彼此獨立的統計模型；同一筆支出不得重複記錄。 $C_{risk}$ 可明確分開已發生事故成本與預期風險成本，不能把主觀估計偽裝成實際付款。

對 AI 參與的接手實驗，除模型調用費，還應報告 Agent 工具、CI runner、資料轉移、人工審查、候選失敗、返工與正式發布後保固成本。若只有 Token 消費較低，不足以證明接手整體成本較低。

### 16.10 建議指標面板

| 觀測面 | 主要指標 | 不利結果亦須公開 |
|---|---|---|
| 建置 | RSR、建置時長、失敗原因 | 缺依賴、無法取得工具 |
| 維護 | PHR、TTFVP、功能回歸 | AI 生成錯誤與返工 |
| 知識 | OAD、需要補件次數 | 設計意圖理解錯誤 |
| 玩家狀態 | SCR、MCR、存檔損毀率 | 不可逆失效 |
| 權利 | RC、阻擋級缺口 | 授權到期與不可移轉 |
| 安全 | 越權嘗試、秘密暴露、漏洞引入 | 需要關閉自動化 |
| 商業 | 可合法發布、通路恢復時間 | 平台條件未符合 |
| 總成本 | 全生命週期接手成本 | AI 較人工昂貴 |

---

## 17．十二項可反駁研究假說

以下均屬事前可提出的研究假說；不能以模型生成的個別成功案例宣布已驗證，亦不把「符合常識」作為免除實驗的理由。

**H1｜完整接手包效果。** 在作品規模、難度與權利狀態相近時，提供已驗證 VHP 的接手組，其首次有效修補成功率高於僅給 Repo 與普通 README 的接手組。若差異不存在或反向，則 H1 不被支持。

**H2｜AI 增益具有條件性。** 在 VHP 完整且測試 Oracle 充分的任務中，適當 AI 輔助可能降低 TTFVP；在資料不足或高風險領域中，AI 可能增加錯誤或審查負擔。

**H3｜原作者依賴下降。** 經過正式決策記錄、可重現環境和測試規格整理後，OAD 可下降；若只是產生更多文件但沒有增進解題效率，H3 不成立。

**H4｜權利鏈是非替代性的門檻。** 對需要正式商業發布的接手任務，必要權利缺失不能由更多 Agent 額度或程式碼產生量彌補。此為法律／制度條件命題，應以具體案例權利審查驗證其適用邊界。

**H5｜存檔語義測試效果。** 提供版本化世界狀態與存檔回歸的接手流程，其跨版本資料損壞率可低於只有編譯與啟動測試的流程。

**H6｜MOD-first 架構效益。** 在同等變更幅度下，具有文件化且有版本相容政策的 MOD 介面，可能降低因核心更新造成受支援 MOD 失效的比例。

**H7｜接手能力非單一模型特性。** 同一模型在不同 VHP 完整度、工具權限、驗收深度與任務難度下，會呈現明顯不同的成功率；因此不應以模型名稱推論接手能力。

**H8｜可繼承設計的前期成本。** 早期投資 VHP 與品質測試會增加當期製作成本；在多次維護及人員更替後，可能降低累計接手成本。若永遠不發生移交或維護，效益可能不大於成本。

**H9｜商店移轉與程式移轉的錯配。** 即使完成平台 App 移轉，若未獨立處理來源資產、第三方許可、簽章與 API keys，仍有機會發生無法發布或功能中斷；相應控制應減少此類事故。

**H10｜知識轉譯的雙面效應。** AI 能幫助陌生接手者理解設計意圖，但若把未核准聊天或過期資訊當成正式規格，可能產生高信心錯誤，甚至比只有嚴格規格文件更差。

**H11｜社群接續潛力。** 有持續貢獻紀錄的 MOD／PR 作者，於其熟悉模組的接手任務中可能有更低啟動成本；但不必然能勝任所有平台發布、法律或安全工作。

**H12｜持續更新接手包的必要性。** VHP 的檔案版本、授權與系統快照若長期落後於正式發行版，其接手價值將隨時間下降；周期性接手演練可能更有效發現此類退化。

對 H1–H12 的估計應報告效果大小、不確定性、失敗樣本與情境限制；初期小樣本研究可作可行性探索，而非將統計不顯著誤解為證明兩流程完全相同。

---

## 18．可實施的獨立接手實驗（IMTT）

### 18.1 研究目的

Independent Maintainer Takeover Trial（IMTT）不是測試 AI 能否朗讀文件，而是測試在原開發者不能參與的條件下，接手者能否在合理時間內對陌生遊戲完成**有意義、有界限、可回歸、可交付**的修改。初版可使用私人、具有合法存取權的實驗專案，不需要直接拿玩家真實付費產品冒險。

### 18.2 研究處理條件

建議至少包含四個條件：

| 實驗組別 | 可用資訊與工具 | 主要測量問題 |
|---|---|---|
| A｜傳統最小交接 | Repo、一般 README、人工工具 | 常見基準能力 |
| B｜傳統完整交接 | VHP、人工工具、不使用生成式 Agent | VHP 本身的效益 |
| C｜AI 最小交接 | Repo、一般 README、受控 AI Agent | AI 在缺資料時能否補足 |
| D｜AI 完整交接 | VHP、受控 AI Agent | VHP 與 AI 是否互補 |

完整實驗需在任務難度、接手者技術能力與可用成本間做分層。禁止把最熟悉作品的人安排在 D 組，把完全沒有任何遊戲經驗的人安排在 A 組後，宣稱 AI 具有巨大收益。

### 18.3 任務集合

每款受試遊戲設計至少四類任務：（1）重建既有可玩版本；（2）修復一項有重現步驟的錯誤；（3）新增一項不改核心世界觀的小功能；（4）跨版本存檔與 MOD 相容驗證。若專案有 Steamworks 相關功能，可加做無正式憑證的發行演練；正式營運帳號和付款權限不應提供給一般實驗者。

### 18.4 避免資訊洩漏與學習效應

若同一位參與者先用完整 VHP 完成某項任務，再回頭進行「只有 README」的測試，結果將受到學習效應污染。可採匹配作品、隨機分派、拉丁方或其他合適交叉設計，並以不同但可比較的任務隔離已獲得的知識。具高度耦合的共享模組可能造成任務干擾，分析單位應依專案、接手者及任務層級調整。

### 18.5 研究者預註冊

在試驗開始前，固定：主要終點、成功定義、接手允許時間、模型與工具版本、成本上限、可使用的文件、角色權限、停止規則、事故處理、是否允許原作者救援及如何處理缺失樣本。正式結果應容許「沒有成功」「成本過高」「因權利不足中止」「AI 使結果更差」等結論。

### 18.6 盲評與玩家視角

能否編譯應由機器驗證，功能及回歸則由獨立的測試者核對；玩家可見的玩法品質若涉及敘事、節奏與美術，應由適當人類評估者實際遊玩。可能的盲評做法是讓評審不知修改來自 A、B、C、D 哪組，但在能看見風格、提交歷史或模型痕跡時須記錄盲法失效。

### 18.7 比較的統計單位與結果報告

最小可分析單位是「指定受試作品下，某接手者在某任務與某工具條件的單次接手」。小樣本研究應提供每筆任務紀錄和信賴區間或合適不確定區間；後續若累積多專案、多組人員，可採階層模型處理不同專案成熟度和參與者背景的變異，不強行把各種遊戲計成一種同質工作。

### 18.8 權利限制的分層結果

若某作品對外授權不足，即使技術組可以完成修補，也不能直接將它算為「可正式接續發行」。研究報告應至少同時給出：技術成功率、必要權利完整率、可正式發行比例、整體成本及玩家風險，不能只公布其中最好看的單一數值。

### 18.9 退出條件與安全停止

若接手任務需要取得非授權資料、需操作正式付款、出現大量玩家存檔損毀風險、發現重大安全漏洞或疑似授權侵害，試驗應按事先規範停止／轉人工審查。安全停止屬有效研究事件，不應被當成 Agent 失去勇氣或未全力工作。

---

## 19．三種遊戲尺度的假設性案例

以下為**研究示例**，不代表 EveMissLab 已完成的商業上架、存檔驗證或 AI 接手實測。目的在展示同一模型在不同產品規模如何改變適用條件。

### 19.1 案例 A：三個月文字／GUI 單機小品

設想一款具有有限地圖、簡單事件表、角色屬性與明確勝敗條件的文字策略遊戲。其核心風險可能是劇情資料覆寫、狀態機轉移、存檔格式和本地化。

若在第 1 月就建立模組邊界、測試資料、資產權利清單；第 2 月建立自動化匯出與修補基準；第 3 月完成一次陌生維護者接手演練，則相較「發售前才整理文件」，可能有更高的接續準備度。但若小品完全沒有長期維護需求，建立完整 VHP 的投入也可能超過預期效益，因此應允許一個合理縮減版。

**假設性接手任務：** 將一個會導致舊存檔重複獲得任務獎勵的錯誤修復，保留歷史存檔，產生可測試版並附上差異紀錄。通過標準是可運行、測試通過、舊存檔效果正確、權利清楚、未向公開平台擅自發布。

### 19.2 案例 B：半年級 2.5D 俯視 RPG

遊戲有地圖、角色、技能、事件與數個可探索區域，使用可調整的技能資料表、Mod SDK 和增量素材載入。其主要困難是跨多個系統的變更、資產來源與存檔版本。

接手包應包含：行為狀態圖、主要角色 ID 契約、技能資料 Schema、事件觸發圖、地圖產生種子、動畫與聲音素材權利、遊玩平衡觀測、Mod API 相容測試。若未來由玩家 MOD 作者承接某個新地圖模組，只需授予其工作範圍內必要的來源與測試，而不必開放整款遊戲的私有核心及平台發行權。

**假設性接手任務：** 在不改動原始 30 小時遊玩存檔主線標記的前提下，新增一個城鎮互動事件與相應任務資料，並保留 MOD API 主要介面版本。接手成功不能只以「新任務可以點擊」判定，還要檢查世界狀態、保存／讀取及最終版本展示。

### 19.3 案例 C：一年以上、持續擴張的世界模擬遊戲

作品具有大範圍程序生成、季節與人口演化、勢力互動、長期事件與多階段存檔，並可能存在龐大 MOD 生態。此時僅整理模組 README 不足以處理「修改初始條件後，數十小時遊戲才發生的崩壞」。

需要：可重放模擬場景、長期存檔樣本、效能基準、世界事件不變量、版本化資料遷移及社群相容清單。AI 的優勢可能表現在大量測試生成、依賴圖分析與資料遷移候選；主要限制可能是對長程玩法意義的理解、驗證成本及多模組變更造成的系統性副作用。

**假設性接手任務：** 修復長期世界演化中的勢力資源負值漏洞，並在模擬 100 年的指定演進路徑下通過預先定義的不變量測試。這裡「100 年」是虛擬世界時間，不是實際跑一百年或已經完成的實測。

### 19.4 案例 D：技術完全成功，卻因權利失敗而不能接續

設想收購一款遊戲後，接手者已從原始碼成功編譯，AI 也修正了數個 Bug。但遊戲核心戰鬥動畫採用僅授權原工作室、禁止權利移轉的專有素材，或某 MOD 被誤認為公司自有內容。即使技術完成度高，若必要授權尚未取得，就應暫停涉及該素材的再發行；可能的出路是重新協商授權、替換資產或調整交易範圍。

此案例代表本文關鍵結論：**更多模型算力無法替代合法權利鏈，也不能把玩家對作品的信任當成可任意買賣的無負擔檔案。**

---

## 20．經濟學：為什麼「可繼承」可能是資產，而不只是成本？

### 20.1 創辦人依賴風險

若某作品只能由初代作者成功修改，即使公司持有 GitHub Repo，其無形資產仍可能高度依賴單一人的記憶、時間與意願。這種依賴可能影響維護速度、未來承包價格、產品交易條件和玩家信任。不過不能用此推論「有接手包就一定提高估值」，需透過實際交易或成本資料驗證。

### 20.2 預防投入與未來收益的折現框架

令 $K_0$ 為建立 VHP、測試及權利清查的當期成本；令 $p_t$ 為第 $t$ 期需要實際交接的情境發生機率估計， $L_t$ 為沒有準備時的預期損失， $L'_t$ 為採用制度後的預期損失， $d_t$ 為依特定情境定義的折現因子。概念上的預期淨效益可寫為：

$$
V_{succession}=\sum_{t=1}^{T}d_t p_t(L_t-L'_t)-K_0-C_{keep},
$$

其中 $C_{keep}$ 是期間維持接手包正確性的成本。這是決策輔助模型，而非可直接由上市前銷量推得的會計值；對 $p_t$ 、 $L_t$ 等缺乏資料的情境，應採情境分析與敏感度區間，而非填入憑空想像的精確數字。

### 20.3 模組複用與繼承不是同一件事

可複用架構讓不同產品重新使用技能系統、渲染器或事件引擎；可繼承設計則要求**接手者能在不重新詢問原作者的情況下，安全維護既有商品**。即使某模組可以複用於下一款遊戲，也可能因專有資產或系統結構無法移交原作品；反之，某作品的內部架構不適合複用，仍可能在自身上下文中高度可維護。

### 20.4 把維護能力納入資產盡職調查

未來對遊戲 IP 收購、出版商合作或工作室併購，可建議將 SRS、VHP 狀態、商店移轉可行性、第三方權利、存檔兼容、MOD SDK、授權債務及恢復所需成本列為技術及商業盡職調查項目。對外部買方而言，能取得一個完整且經接手演練的產品，可能比取得「很多行原始碼」更有操作意義，但這是否形成價格溢價仍待實證。

### 20.5 對小公司和高 AI 槓桿公司的特殊意義

在小型 AI 原生公司，人類員工可能很少，日常成果卻依賴多模型、多代理與大量可複用軟體資產。此時風險不只是「員工離職」，而是創辦人的決策脈絡、API 額度、模型工作流及帳號權限高度集中。前作《AI 原生企業潛在生產能力與可融資性評估框架》已區分產能、帳面價值、現金流與可融資性。[I07] 本篇補充：**技術產能若不可移轉與不可獨立驗證，就可能帶有高集中風險折減。** 這是經濟學研究假說，不應未經交易證據就量化為固定估值折扣。

---

## 21．公開交付與選擇性揭露的關係

### 21.1 對玩家公開「接續能力」，不等於公開全部私有內容

公司可向玩家公開：目前版本是否能離線使用、存檔格式政策、官方 MOD API、過去更新的回歸報告摘要、計畫性維護與產品生命週期政策。它不需要因此公開商業機密、完整安全弱點、第三方契約價格、雲端服務憑證及所有內部設計辯論。

這恰好呼應 ANIE-00 的選擇性揭露原則：公開的應是對外有意義且合法可揭露的**狀態、理由與證據**，不是把公司資料庫當成公共論壇。[I00]

### 21.2 有些資訊應延遲公開

例如發現重大存檔安全問題時，應先處理漏洞與避免擴散，必要時先向受影響對象及平台適當通報，再於不加重風險的時點公開修復方式、影響範圍與變更說明。商業交易未完成前的收購協議、尚未獲得第三方同意的外包接續也不應因追求透明就提前全文公布。

### 21.3 接手不是強迫他者繼承作者價值觀

繼承技術與產品經營權後，後續開發者可以在權利範圍內作出不同的設計判斷；但如果其修改會改變玩家購買時的重要期待，應清楚區分「正式原作」「重大新方向」「分支／MOD」「不再支援的舊版本」，而非用一個模糊的更新公告掩蓋產品定位的轉變。

### 21.4 玩家與 MOD 社群具有其自身主體性

即使公司提供友善接續管道，也不能要求玩家必須貢獻勞動、同意任何續作方向或接受公司對 MOD 的全面收編。公司可提出合作機會、討論補償及開源／商業授權，但外部參與者可以拒絕。這將在 ANIE-04 的「相交域」與 ANIE-06 的契約合作中繼續形式化。

---

## 22．最小產品化路線：從第一款遊戲開始，不需重建全套制度

### 22.1 Phase 0：先界定最低可維護產品

小型單機遊戲的第一階段只需：確定性可重建環境的工作說明、版本化來源、主要素材清單、基本權利證據、可執行遊戲與基準測試、存檔樣本，以及誰能在開發者缺席時維護的角色名單。不要因為要「很完整」而把一個三個月作品變成需要半年才能填完的文件系統。

### 22.2 Phase 1：產線自動保留必要證據

透過 GitHub Actions 或其他 CI，在每次通過主線合併時保留可授權的建置索引、來源與測試摘要，對正式發布的檔案生成雜湊。以相對簡單的 JSON/YAML Manifest 和文件約定先完成基本證據，不要求第一天就實作完整企業級 Provenance 平台。

### 22.3 Phase 2：建立獨立接手演練

請一位未參與該模組開發的同事、簽約工程師或受監督的 AI Agent 在獨立工作空間嘗試修復一個小 Bug，完整記錄作者協助與缺失資料。演練過程若發現文檔不夠、存檔樣本太少或某些 API 只有作者本人知道，便能在真實交接前修補。

### 22.4 Phase 3：把 MOD 與玩家對外介面納入接手計畫

公開官方支援的 MOD API 範圍、相容版本政策、SDK 測試樣本、破壞性變更公告與上游 Issue 路徑。對外合作及 PR 收錄需先確立授權與提交程序。這一階段可以使用部分公開、部分需受權的混合模式。

### 22.5 Phase 4：取得可移交正式商品的證據

在進入正式上市或重大 EA 發布前，至少由適格營運人員核對：誰能合法發布版本、商店平台權限與備援角色、發行簽章與金鑰程序、必要素材合約、客服管道、回退方案及收款與稅務責任。這不是要求把正式金鑰交給 AI，而是確保企業不因單一私人帳號消失而失去所有更新能力。

### 22.6 Phase 5：季度循環與長期接續

每季可以抽樣檢查接手包是否仍對應現行版本，定期執行陌生維護者演練；每次重大的引擎升級、存檔格式更動、付費素材更新或公司治理變更，都應觸發相關權利、環境和世界相容契約的重驗。

### 22.7 與現有 EveMissLab 架構的最小耦合

既有 SEDB-GAME × ModWorld 可提供跨遊戲語義／Adapter 與 MOD 修改／驗證參照；企業母 AI 可提供公司級持續認知與組織知識入口；既有企業通訊智能架構可承接權限、事件帳本與外部通知；ANIE-02 的可驗證交付單元（VDU）可成為季度發布的最小驗收紀錄。這些是**可參照與可能整合的設計關係**，不是本研究已完成跨系統端到端整合的聲稱。[I02][I03][I05][I06][I08][I09]

---

## 23．失敗情境與反對意見

### 23.1 反對一：「有 GitHub 就能接手，不需要新理論」

GitHub 能保存版本與多人協作，但無法自動保證商業素材可轉讓、舊存檔維持、部署權限可移交或原作者的隱含設計知識完整。若研究證明對大部分特定小品來說一般 Repo 與 README 已經足夠，則 VHP 在那些作品中應縮小，而非強制採用完整制度。

### 23.2 反對二：「AI 未來夠強就不需要文件」

模型能力改善可能降低程式碼理解成本，但歷史上沒有寫下的外包授權、未保存的源素材、已刪除的玩家資料、不能再取得的工具及法律限制，不會因更強的模型而自動變成可驗證真實。對原作者意圖，AI 的重建甚至可能只有合理推測而非史實；這些未知必須可以明確標示。

### 23.3 反對三：「可繼承是鼓勵公司無限承諾更新」

本文恰好反對無法兌現的永久承諾。可繼承僅降低未來維護選項的取得成本與風險，並不授予玩家要求公司永久擴充的權利。決策者可以在明確法律與產品告知下選擇維持、封存或終止。

### 23.4 反對四：「整理九種接手包太花時間」

這個成本是真實的。本文採任務導向與漸進成熟度，不要求三個月小品照搬大型工作室制度。應實際測量前期文件投資是否換來後續維護工時減少；若無足夠效果，簡化流程是合理的研究結果。

### 23.5 反對五：「更多接手權限會加大攻擊面」

確實如此。產品繼承的對象應被授權清楚界定，以最低權限、受控測試、資料分級、憑證輪替及必要人工審查降低新增風險。若某接手形式不能達到安全要求，寧可暫停而不是為了漂亮的成功率跳過控管。

### 23.6 反對六：「原作者不在後，作品的創作身份會消失」

這是商業權利之外的文化問題。技術接手不等於新作者必須完全保留前作者的每一個價值判斷，也不等於可假稱前作者親自批准新作。可以保存版本系譜、創作署名、歷史設計紀錄與分支變更，讓玩家理解何者來自初代、何者來自後續團隊。這比把變更隱藏在相同商標下，更能維持長期的可追溯性。

### 23.7 反對七：「只要有最終執行檔，為何需要維護能力？」

對部分離線作品而言，一個穩定的最終執行檔和可保存的存檔格式，的確可能已足以滿足大部分玩家。本文不把「每款遊戲都必須永遠可以新增內容」設為要求；可繼承性可涵蓋**保存、修補與擴充**三種不同目的，價值取決於作品本身與玩家需求。

---

## 24．結論：把「維護能力」從人身經驗，逐步轉化為產品資產

本研究指出，AI 時代的遊戲可繼承性，不能被簡化為「原始碼有備份」「模型能生成 Patch」「Steam 帳號可以移轉」或「MOD 社群有人願意接手」。這些都是有用但不充分的條件。真正的接續需要合法權利、可取得資產、可重建環境、世界相容規格、品質驗證、營運通路、設計知識與對外承諾形成一致的可檢驗鏈。

AI 的特殊價值，在於它可能以低於傳統方式的認知轉譯成本，讓後續接手者能讀懂陌生系統、理解相依約束、提出修補和重跑驗證。但它不能替代合法授權、永久保存未曾存檔的資料，或保證每次快速生成都達到商品品質。

本篇提出 PSC、VHP、AASP、SRS 與 IMTT，目的不是額外創造一套只供命名的理論，而是給出可從第一款小型商業遊戲開始使用的接續規格及反證方法。若未來真正的獨立接手試驗顯示完整接手包不增加成功率、不降低原作者依賴，或 AI 使品質與安全更差，該結果應直接驅動制度調整。

**核心結論：一款商業單機遊戲是否具有生命週期延續能力，不只取決於初代開發者有多能幹，也取決於他留下多少可以合法、可驗證、可理解、可由後續參與者安全繼續工作的產品條件。**

此結論與 ANIE-00 的互動企業、ANIE-01 的發行階段、ANIE-02 的季度驗證交付形成第一部閉合；第二部將進一步研究玩家與開發者的相交域、官方 MOD 生態，以及外部貢獻如何轉化為合法的商業協作。

---

# 附錄：可實作資料契約、檢查表與研究工具

> 附錄示例均為文件與資料規格草案，使用虛構 `sample-game` 識別碼；未連接任何真實產品倉庫、正式遊戲 App、第三方權利證書或使用者個資。示例中的 `pending`、`unknown`、`not_run` 不能被解讀為實際完成驗證。正式部署需依產品、工具版本、法務結論及資料分類政策修訂。

## 附錄 A．VHP 接手包目錄與信任分界

### A.1 建議目錄（邏輯結構，不要求所有內容存在同一磁碟）

```text
product-succession/
├── README.md
├── handover-manifest.json
├── policy/
│   ├── access-scope.md
│   ├── legal-review.md
│   ├── disclosure-levels.yaml
│   └── stop-rules.md
├── rights/
│   ├── ownership-index.yaml
│   ├── asset-license-inventory.csv
│   ├── third-party-obligations.md
│   └── contributor-contract-index.md
├── sources/
│   ├── repo-lock.yaml
│   ├── git-lfs-inventory.md
│   ├── editable-media-manifest.yaml
│   └── source-backup-procedure.md
├── environment/
│   ├── toolchain-lock.yaml
│   ├── dependencies.md
│   └── clean-room-setup.md
├── build/
│   ├── build-procedure.md
│   ├── artifact-checksums.txt
│   ├── provenance-index.md
│   └── release-rollback.md
├── world/
│   ├── save-schema.md
│   ├── migrations.md
│   ├── invariants.md
│   └── mod-compatibility.md
├── quality/
│   ├── test-matrix.md
│   ├── known-risks.md
│   ├── playtest-oracle.md
│   └── evidence-index.md
├── knowledge/
│   ├── current-design-bible.md
│   ├── decision-records-index.md
│   ├── rejected-alternatives.md
│   └── unresolved-questions.md
├── operations/
│   ├── store-account-handover.md
│   ├── service-roles.md
│   ├── secret-rotation-procedure.md
│   └── incident-and-support.md
└── network/
    ├── public-commitments.md
    ├── mod-sdk-support-policy.md
    ├── contributor-contact-rules.md
    └── player-notification-procedure.md
```

**重要限制：** 本目錄不包含可直接登入的秘密金鑰、付款資訊或玩家原始資料；`rights/` 內可只有契約識別碼、授權狀態與合法可讀位置，敏感契約全文放在另外的權限系統。對私人程式碼的來源定位，也不等於對所有公共讀者開放。

### A.2 每份內容的五個基本欄位

每份重要檔案至少標記：（1）負責人或角色；（2）所屬產品／版本；（3）何時核對；（4）可以被誰讀取；（5）是 `draft`、`verified` 還是 `obsolete`。額外可加哈希、來源與法律使用範圍。若某檔案只有更新日期沒有核對者，不能因此證明其內容正確。

### A.3 不必保存所有中間暫存檔

AI 工業化可能造成大量實驗截圖、候選模型、臨時資產、一次性測試腳本和 Agent 工作目錄。VHP 不應無差別永久保存全部暫存，而應由可重現生成流程、正式來源、保留政策與已驗證證據決定哪些需要留存。否則長期累積的磁碟成本、搜尋負擔與安全風險可能反過來破壞可繼承性。

---

## 附錄 B．可驗證接手包 JSON Manifest 草案

```json
{
  "schema_name": "anie-vhp-manifest",
  "schema_version": "0.1.0-draft",
  "record_id": "VHP-SAMPLE-0001",
  "product": {
    "product_id": "sample-game",
    "product_title": "Example Game (Fictional)",
    "release_channel": "internal-test",
    "source_revision": "REPLACE_WITH_VERIFIED_COMMIT",
    "game_build_id": null,
    "platform": "Windows"
  },
  "status": "unverified_example",
  "last_reviewed_at": null,
  "reviewed_by": null,
  "custodian_role": "product-owner",
  "handover_scope": {
    "recipient_role": "authorized-maintainer",
    "permitted_actions": [
      "read-approved-source",
      "build-in-isolated-environment",
      "submit-patch-for-review"
    ],
    "prohibited_actions": [
      "publish-production-build-without-approval",
      "export-player-personal-data",
      "use-unapproved-third-party-assets"
    ]
  },
  "components": [
    {
      "component_id": "VHP-R",
      "status": "pending",
      "location_ref": "rights/ownership-index.yaml",
      "classification": "restricted",
      "sha256": null
    },
    {
      "component_id": "VHP-S",
      "status": "pending",
      "location_ref": "sources/repo-lock.yaml",
      "classification": "internal",
      "sha256": null
    },
    {
      "component_id": "VHP-E",
      "status": "pending",
      "location_ref": "environment/toolchain-lock.yaml",
      "classification": "internal",
      "sha256": null
    },
    {
      "component_id": "VHP-B",
      "status": "pending",
      "location_ref": "build/build-procedure.md",
      "classification": "internal",
      "sha256": null
    },
    {
      "component_id": "VHP-W",
      "status": "pending",
      "location_ref": "world/save-schema.md",
      "classification": "internal",
      "sha256": null
    },
    {
      "component_id": "VHP-Q",
      "status": "pending",
      "location_ref": "quality/test-matrix.md",
      "classification": "internal",
      "sha256": null
    },
    {
      "component_id": "VHP-K",
      "status": "pending",
      "location_ref": "knowledge/current-design-bible.md",
      "classification": "restricted",
      "sha256": null
    },
    {
      "component_id": "VHP-O",
      "status": "pending",
      "location_ref": "operations/store-account-handover.md",
      "classification": "restricted",
      "sha256": null
    },
    {
      "component_id": "VHP-N",
      "status": "pending",
      "location_ref": "network/public-commitments.md",
      "classification": "mixed",
      "sha256": null
    }
  ],
  "validation": {
    "rights_gate": "not_run",
    "independent_build": "not_run",
    "save_migration": "not_run",
    "mod_compatibility": "not_run",
    "security_review": "not_run",
    "successor_patch": "not_run",
    "release_simulation": "not_run"
  }
}
```

**Manifest 的語義規則：**

- `status = verified` 不應只由檔案存在產生；需指向具體測試／審核證據與批准者。
- `sha256 = null` 表示尚未提交雜湊證據，不等於空檔案或自動通過。
- `classification = restricted` 表示不可僅憑使用者看得見清單，就能閱讀後方完整內容。
- `permitted_actions` 用於記錄授權工作範圍；它不是自動生效的作業系統權限，實際工具仍需執行限制。
- `game_build_id = null` 在尚未發布的實驗作品中是合法狀態，不得捏造 Steam Build ID。
- 正式系統應另設文件簽名／存證、權限來源及驗證結果的結構化紀錄；上列 JSON 是最小示意，沒有自稱符合 SLSA 或 SPDX。

---

## 附錄 C．素材權利鏈資料契約

### C.1 權利明細欄位

每筆素材至少應有 `asset_id`、`source_origin`、`author_or_rightsholder`、`contract_ref`、`license_type`、`uses_allowed`、`transfer_rule`、`sublicense_rule`、`attribution_requirement`、`territory`、`valid_until`、`review_status`、`reviewer_role`、`evidence_uri`、`blocking_issue`。

此資料是接手者的**權利導航圖**，不能取代正式簽署、授權條款或個案法律審查。涉及身分和報酬的資料應限制可見性。

### C.2 權利狀態示例

```yaml
asset_id: ASSET-DEMO-MUSIC-0001
asset_kind: background_music
source_origin: externally_licensed
rightsholder: PLACEHOLDER
contract_ref: CONTRACT-REVIEW-REQUIRED
license_type: commercial_license_pending_review
uses_allowed:
  - null
transfer_rule: unknown
sublicense_rule: unknown
attribution_requirement: unknown
territory: unknown
valid_until: null
review_status: blocked_pending_legal_review
reviewer_role: legal_authority_required
blocking_issue: cannot_assume_successor_distribution_rights
```

示例刻意將多個欄位設為 `unknown`，展示「缺授權證據時不應編造合法性」的正確處置。程式可能已能載入該音樂，仍不應把 `review_status` 自動改為 `cleared`。

### C.3 可直接繼承與需重新談判不是二分法

某些授權可以在遵守通知義務下由後續者繼續合法利用；有些需獨立取得新授權；有些授權容許維護而禁止再販售；還有些受到著作人格權、商標或其他限制。權利調查不能只用 `owned/not_owned` 二元欄位，否則會把有界利用誤認成無限制處分。

---

## 附錄 D．獨立 AI 接手任務卡（研究範本）

```yaml
trial_id: IMTT-EXAMPLE-001
product_id: sample-game
sample_type: fictional_design_example
condition: D_AI_FULL_VHP
start_state: not_started
assigned_role: authorized_technical_maintainer
original_author_available: false
production_credentials_available: false
mission:
  type: save_compatibility_bugfix
  summary: repair_duplicate_quest_reward_on_legacy_save
  expected_player_behavior: no_duplicate_reward_after_reload
pre_registered_acceptance:
  - build_from_approved_revision
  - test_legacy_save_before_after
  - preserve_player_inventory_identifiers
  - run_main_regression_suite
  - review_third_party_asset_changes
  - produce_revert_instructions
constraints:
  - no_production_deployment
  - no_unapproved_external_data_transfer
  - no_new_unlicensed_assets
  - no_live_user_data
  - use_least_privilege_tools
required_evidence:
  - source_revision_and_patch_diff
  - build_logs
  - tests_with_expected_and_observed_results
  - reviewer_decision
  - time_and_cost_records
outcome:
  technical_status: not_run
  legal_status: not_run
  quality_status: not_run
  owner_intervention_minutes: null
  human_active_minutes: null
  ai_tool_cost: null
  first_valid_patch_at: null
```

### D.1 測試過程對 AI 的最低指示

> 你是受權的接手開發協作者。僅使用任務卡與目前允許的資料。先確認來源、版本、權利及測試基準；未核對前不得宣稱已成功接手。將不明事項列出，禁止自行捏造合約、版本號、測試紀錄或發行權。不得使用真實營運憑證或擅自上線。對修補提出可回退 PR，附上受影響世界狀態、存檔與 MOD 的驗證證據；若遇法律、安全、資料外洩或不可逆存檔風險，停止並提出升級人工審查。完成後用實際證據說明哪些達成、哪些失敗、哪些仍未知。

這是一段可被企業改寫的研究工作指示，並非可繞過系統權限的自動授權文件。

### D.2 為何不能只觀察「完成」字樣？

某 AI 可能生成正確修補卻沒有權限寫入 Repo；某接手者可能通過所有單測但失去舊存檔；某工作流可能已成功修復，卻因未取得授權無法發布。結果應以多個獨立的技術、法律、品質、發布狀態呈現，不用單一 `DONE` 掩蓋缺口。

---

## 附錄 E．最小測試矩陣與演練紀錄

### E.1 接手前的測試類別

| 編號 | 測試面 | 最小例子 | 失敗後的預設處置 |
|---|---|---|---|
| T01 | 原始碼完整性 | Commit、子模組與 LFS 資產齊全 | 停止聲稱可建置 |
| T02 | 依賴取得 | SDK、引擎、工具可在授權下取得 | 標記依賴封鎖 |
| T03 | 乾淨環境建置 | 新工作區無作者私人環境可成功建置 | 收集缺失條件 |
| T04 | 基本啟動 | 目標平台啟動、基本 UI 可用 | 阻擋後續任務 |
| T05 | 世界狀態 | 角色、物品、事件、時間不變量 | 回退並查差異 |
| T06 | 舊存檔 | 前版資料可讀、核心玩家資產正確 | 禁止無保護發布 |
| T07 | 官方 MOD | SDK API、版本範圍、載入順序 | 分支／適配／公告 |
| T08 | 資料安全 | 不輸出秘密、無測試用真個資 | 立即停止及稽核 |
| T09 | 權利 | 必要原始素材有相應合法用途 | 停止商業發行 |
| T10 | 玩家體驗 | 設計上預期的主要流程可實際遊玩 | 交回人類驗收 |
| T11 | 發布預演 | Staging 建置、回退、簽章計畫 | 不給正式發布權 |
| T12 | 未來接手 | 本次變更已更新 VHP 與決策記錄 | 要求文件修正 |

### E.2 接手演練事件紀錄

```text
Trial ID：［研究編號］
Product Version：［確定版號］
Task / Complexity：［事前定義］
Rights Gate：［通過／阻擋／不適用／未知］
Independent Build：［通過／失敗／未執行］
Patch Validation：［通過／失敗／未執行］
Save / MOD Regression：［測試數與結果］
Security / Privacy：［問題與處置］
Original-Author Intervention：［分鐘、次數、內容］
AI Configuration：［模型、工具、額度範圍］
Labor / Compute Cost：［人力、API、CI、資料搬移］
Delivery Decision：［僅候選／批准測試／正式發布］
Limitations：［樣本、已知失敗、外推限制］
Verifier / Date：［審查角色與日期］
```

### E.3 為何一定要保留負面證據？

如果某次接手失敗是因缺少特定插件，而團隊事後修好 CI，就把原始錯誤 Log 刪除，未來將無法評估 VHP 的真正缺口。研究紀錄應保留在合法可存取範圍內，且對外可用去識別化摘要公開失敗原因；修正後新增成功證據，不能覆蓋最初的失敗事實。

---

## 附錄 F．接手與資料分級矩陣

| 對象 | 可公開內容 | 受限合作內容 | 一般不公開或不得任意公開 |
|---|---|---|---|
| 遊戲原始碼 | 官方公開的 SDK／樣例 | 受權核心子模組 | 未授權私有程式碼 |
| 設計資料 | 已公開世界觀、MOD 介面 | 指定功能的設計資料 | 未公開劇情、競爭策略 |
| 測試證據 | 發行版回歸摘要 | 具授權的詳細 CI Logs | 含密碼、漏洞利用鏈的原始資料 |
| 權利文件 | 授權政策摘要 | 合作所需條款／合約 | 個人住址、財務細節、第三方秘密 |
| 玩家資料 | 匿名化聚合結果 | 合法最小必要案件資訊 | 原始私密客服與帳號資料 |
| 發行資訊 | 正式版本、公告、支援政策 | 發行排程及受權操作程序 | 正式 Token、付款權限、未發表業務策略 |
| 社群貢獻 | 作者同意公開的署名與成果 | 維護合作資訊 | 未取得同意的私人資料 |

**公開投影原則：** 相同事件應保有內部 canonical record，再按受眾產生不同的合法投影。對外頁面可以說「已完成相容性回歸 30 個樣本」，前提是確有可查測試；不能公開宣稱有 30 個樣本，內部其實只是模型生成了 30 條未執行腳本。

---

## 附錄 G．接手事故與最小回復方案

### G.1 事故分類

- **資料缺口事故：** Repo 內缺 Git LFS 大型檔、匯出模板或最後正式版本素材。
- **權利缺口事故：** 某付費素材禁止新公司使用，權利人失聯或契約到期。
- **技術依賴事故：** 第三方插件停止提供，或舊版引擎不支援新的作業系統。
- **世界連續性事故：** 新版世界生成修改破壞玩家長期存檔。
- **供應鏈事故：** 外部 MOD、依賴或接手文件植入惡意命令，導致不安全生成或執行。
- **通路事故：** Steamworks Publisher API keys／付費資訊／匯出帳號需重新核驗或輪替。
- **治理事故：** 沒有指定具合法代表權與交付權的角色，導致技術成果無法批准發布。

### G.2 事故共通處置

第一步是保留版本與證據；第二步隔離有風險的環境或帳號；第三步識別受影響範圍與合法責任；第四步嘗試在離線／測試分支重建；第五步由有權者決定是否修復、替換或停止；第六步更新接手包與對外通知。在無法確定玩家是否已經受損時，應清楚標註未知，而非過早宣布「完全沒有影響」。

### G.3 可回退性不是百分之百保障

即使有 Git 回退和舊版 Steam Beta Branch，也可能因新舊存檔版本不兼容、已上線服務資料變更、跨平台同步或玩家已建立的新世界事件而無法安全回到上個版本。事前要保留可恢復資料及遷移計畫，並區分「程式版本可回退」與「玩家世界狀態可回復」。

---

## 附錄 H．接續能力的操作性詞彙表

| 詞彙 | 本研究使用方式 |
|---|---|
| IGP | 在指定任務、授權及資源條件下可被有效接續的遊戲產品 |
| PSC | 產品權利、資產、版本、知識、驗證、維護與發布的可追溯接續鏈 |
| VHP | 有來源、權限、資料、測試及核實狀態的可驗證接手包 |
| AASP | 人與 AI 在授權範圍內執行接手工作的七階段協議 |
| IMTT | 未參與原開發的合格接手者完成真實維護任務的實驗 |
| SRS | 由保存到多輪獨立維護的七級接手成熟度 |
| BCL | 從可讀來源到可重現發行的五級工程建置能力 |
| RSR | 經預註冊條件判斷的獨立建置成功率 |
| PHR | 有驗收證據的限定接手修補成功率 |
| TTFVP | 接手任務開始到首次有效修補的時間 |
| OAD | 原作者介入工時相對於全部相關人類工時的比率 |
| SCR | 受試舊存檔在指定新版本通過核心測試的比例 |
| MCR | 官方宣告受支援的 MOD 在指定版本通過相容測試比例 |
| RC | 本次任務必要素材被核對的授權文件覆蓋率 |
| Product Continuity | 產品在指定條件下維持合法使用、維護、創作或營運能力的狀態 |
| Authority Gate | 將 AI 建議、實際操作、公開資訊與法律批准分開的授權閘門 |
| Canonical Source | 可追溯且正式受控的源檔與決策記錄；聊天渲染不算正式原稿 |

---

## 附錄 I．研究者與公司執行者檢查清單

### I.1 發布論文前

- [ ] 說清楚「繼承」是產品接續能力，不是繼承法上的一體適用概念。
- [ ] 將法定權利、契約授權、技術權限及平台 Partner 資格分別描述。
- [ ] 不把單機遊戲的可重建建置誇大為全部產品可維護。
- [ ] 明確指出 AI 的工作需要合法授權及獨立品質證據。
- [ ] 對 Steamworks、GitHub、Godot、SPDX、SLSA、NIST 等引用官方原始資料。
- [ ] 所有案例／欄位與未來實驗成果均標明為假設，不偽裝實測。
- [ ] 對來源文獻有合理支持範圍；不由官方 API 存在直接推論商業成功。
- [ ] 所有數學公式使用 ` $...$ ` 與 `$$...$$` 作為唯一 source delimiter。

### I.2 真正執行公司專案前

- [ ] 已取得管理者與必要權利人允許，並界定合法接手目的。
- [ ] 關鍵原始碼、素材、依賴及版本可在受控環境取得。
- [ ] 主要第三方素材有可核實的使用、修改、移轉條款。
- [ ] 安全措施防止 Agent 提取正式 Token 或玩家原始資料。
- [ ] 有舊版存檔／官方 MOD 的代表性回歸測試。
- [ ] 有獨立接手者完成最小 Bug 修復，不靠原作者暗示。
- [ ] 修補有 PR、CI、審核與明確的回退方法。
- [ ] 平台發布權限、合法代表權及付款權限分開核對。
- [ ] 更新後能刷新接手包，而不是保留過期的快照。
- [ ] 對外說明能對應真正已完成的測試和版本。

### I.3 實證研究前

- [ ] 已事前定義四組 A/B/C/D 的資訊和 AI 使用條件。
- [ ] 任務難度、接手人員、專案成熟度與模型版本可追蹤。
- [ ] 已定義主要結果，並允許失敗與安全停止。
- [ ] 原作者介入有完整紀錄，不把救援當成獨立接手。
- [ ] 有防止學習效應與資料外洩的研究設計。
- [ ] 評估者有可執行的驗收 Oracle 和玩家體驗測試。
- [ ] 明確保留法律阻礙／上游服務中斷等失敗原因。
- [ ] 完整記錄 AI 成本、人工工時、審查、返工與發布後代價。
- [ ] 預先規劃匿名化與研究資料保存期限。
- [ ] 報告允許顯示「更強 AI 沒有改善接手」的結論。

---

# 參考文獻、規格與既有研究對照

## A．平台機制、保存制度、建置與安全規格

以下參考資料用於支持已存在的規格與平台功能。官方文件代表查核時的制度或技術描述，不代表它們對本篇提出的 IGP／PSC／VHP／AASP／IMTT 概念已完成驗證，也不保證未來平台政策不變。對實際商業操作，仍應再次確認最新條款與適用契約。

**[E01]** Valve Corporation. *Steamworks Documentation — Transferring Applications*. Steamworks Partner 之間的 App 轉移權限、程序、商店與社群延續、報表及 Publisher API keys 的處置。查核：2026-10-16。  
https://partner.steamgames.com/doc/gettingstarted/managing_apps/transfer

**[E02]** GitHub Docs. *Transferring a repository*. 倉儲擁有者變更、專案資料與 Issues／PR 的處理、移轉限制及帳號權限差異。查核：2026-10-16。  
https://docs.github.com/en/repositories/creating-and-managing-repositories/transferring-a-repository

**[E03]** Thomson Reuters Practical Law. *Software Source Code Escrow Agreements*. 軟體原始碼託管交付的契約設計、存放與釋出條件實務參照；部分內容可能受訂閱限制。查核：2026-10-16。  
https://ca.practicallaw.thomsonreuters.com/w-002-5501

**[E04]** Lamb, C., & Zacchiroli, S.（2021）. *Reproducible Builds: Increasing the Integrity of Software Supply Chains*. arXiv:2104.06020. 可重現建置在來源、二進位及軟體供應鏈之間建立可檢驗對應關係的研究。  
https://arxiv.org/abs/2104.06020

**[E05]** Bal, G. S. *Source Code Escrow: Structure, Triggers, and Best Practices*. 專業法律實務文章，討論託管材料應包括建置與依賴資料、觸發條件、釋出權及驗證；與 [E03] 合併作為制度背景，而非各司法轄區皆適用的法律意見。查核：2026-10-16。  
https://gurpreetbal.com/knowledge/lic-06-source-code-escrow

**[E06]** Software Heritage. *SoftWare Hash IDentifier (SWHID)*. 內容導出的軟體來源識別與 ISO/IEC 18670:2025 標準資訊。查核：2026-10-16。  
https://www.softwareheritage.org/software-hash-identifier-swhid/  
https://www.swhid.org/

**[E07]** Software Heritage. *Content Policy*. 對公開程式碼典藏與個資處理的說明；不應假設公司私有程式碼適合直接上傳到公共典藏。查核：2026-10-16。  
https://www.softwareheritage.org/legal/content-policy/

**[E08]** Reproducible Builds Project. *Definitions: When is a build reproducible?* 及 *What's in a build environment?* 對來源、環境、指令與逐位元相同發行產物的界定。查核：2026-10-16。  
https://reproducible-builds.org/docs/definition/  
https://reproducible-builds.org/docs/perimeter/

**[E09]** SPDX. *Specifications — SPDX 3.0*. 開放規格、軟體物料清單及授權資訊結構。查核：2026-10-16。  
https://spdx.dev/use/specifications/

**[E10]** OpenChain Project. *ISO/IEC 5230 — Open Source License Compliance*. 以組織流程處理開源授權合規，不能替代商業音樂、外包美術或個別契約的權利查驗。查核：2026-10-16。  
https://openchainproject.org/license-compliance

**[E11]** SLSA. *SLSA Specification v1.2*. 軟體供應鏈保護、來源追蹤、建置與其他驗證層次。查核：2026-10-16。  
https://slsa.dev/spec/v1.2/

**[E12]** NIST（2022）. *SP 800-218, Secure Software Development Framework (SSDF) Version 1.1*. 安全軟體生命週期高階實務。  
https://csrc.nist.gov/pubs/sp/800/218/final

**[E13]** GitHub Docs. *Repository roles for an organization*. 組織內 Read、Triage、Write、Maintain、Admin 等權限及其風險分離。查核：2026-10-16。  
https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization

**[E14]** W3C（2013）. *PROV-O: The PROV Ontology*. 針對 Entity、Activity、Agent 等來源與派生關係的可交換表示；本篇借鏡其來源建模而不宣稱 VHP 為完整 PROV-O 實作。  
https://www.w3.org/TR/prov-o/

**[E15]** 中華民國《著作權法》；全國法規資料庫，特別參照第 11、12 條職務著作與出資聘請完成著作之規範，應以實際契約與最新法律狀態判定個案。查核：2026-10-16。  
https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=J0070017

**[E16]** Valve Corporation. *Steamworks Documentation — Steam Workshop Item Versioning*. Workshop 項目與遊戲 Beta Branch 相容範圍、MOD 更新與玩家既有存檔的版本管理。查核：2026-10-16。  
https://partner.steamgames.com/doc/features/workshop/itemversioning

**[E17]** Godot Engine Documentation. *Exporting packs, patches, and mods*. PCK／ZIP 延伸、補丁與 MOD 支援及不受信任腳本的安全風險；不能因此推論 MOD 內容無條件可商業再授權。查核：2026-10-16。  
https://docs.godotengine.org/en/stable/tutorials/export/exporting_pcks.html

**[E18]** GitHub Docs. *Available rules for rulesets*. PR 合併要求、必要 CI Status Checks 及預期來源的管理；需依個別倉庫的權限與方案設定。查核：2026-10-16。  
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets

## B．ANIE 系列與 EveMissLab 既有研究

以下為本系列的研究基礎與概念前作，並非表示其內容均已經獨立實驗驗證、商業落地、正式發表或完成同儕審查。文獻引用關係旨在避免重複創建已存在的概念，並使讀者能追蹤理論邊界。

**[I00]** Neo.K × GPT-6（2026-10-16）。《從產品黑盒到 AI 原生互動企業》，ANIE-00，v0.1，UTF-8 Markdown 工作論文；本系列對外交付證據、參與與選擇性揭露的總綱。

**[I01]** Neo.K × GPT-6（2026-10-16）。《從 EA 到持續交付：DEMO、Playtest、搶先體驗與正式版的重新分工》，ANIE-01，v0.1，UTF-8 Markdown 工作論文。

**[I02]** Neo.K × GPT-6（2026-10-16）。《季度單機產品制：AI 工業化、算力額度與品質交付率》，ANIE-02，v0.1，UTF-8 Markdown 工作論文。

**[I03]** Neo.K（2026-09-07）。《從意圖到決策：AI 原生決策編譯器與稀疏意圖治理》，v0.1，EveMissLab 既有研究。  
https://unboundedaxiom.org/p/lm-004090/

**[I04]** Neo.K（2026-09-07）。《形式權力與實際決策因果：人機複合決策系統的權力重新分布》，v0.1，EveMissLab 既有研究。  

**[I05]** EveMissLab（2026-09-01）。《SEDB-GAME × ModWorld：AI 原生遊戲理解與 MOD 共創 Runtime 技術白皮書》，v0.1；遊戲語義、有效遊戲世界、MOD 意圖、Adapter 與驗證 Runtime 的前置模型。  

**[I06]** EveMissLab（2026-09-21）。《供應商與平台責任：AI Coding Tool 的 Publication-Boundary Governance》，APBSC-08，v0.1；工具執行、資料可見與對外發布邊界的研究。  

**[I07]** Neo.K（2026-07-23）。《AI 原生企業潛在生產能力與可融資性評估框架》，v0.1；區分數位資產與產能、財務價值、融資能力。  
https://unboundedaxiom.org/p/lm-001728/

**[I08]** Neo.K × Aletheia（2026-08-01）。《企業母 AI：公司作為 AI 的可觀察世界》，v0.1；企業世界狀態、持續認知、Agent 與授權邊界。  
https://unboundedaxiom.org/p/lm-002360/

**[I09]** EveMissLab（2026-07-30）。《EVEMISS 企業通訊智能核心：共用架構技術白皮書》，v0.1；企業身分、政策、事件帳本、可觀測性與人工控制的規格。  

---

## 研究界線、資訊可信度與正式來源聲明

**研究類型：** 本篇是原創概念框架、工程制度設計與前瞻性實證方法的工作論文，非已完成的觀察研究、產品移轉紀錄、投資估值報告或正式法律意見。提出的 VHP、PSC、AASP、SRS、BCL、IMTT 需經產品測試及第三方比較再決定其適用範圍與實務效益。

**關於 AI：** 本文承認 AI 工具可能大幅降低某些陌生程式碼與素材工作流的交接成本，但不宣稱所有任務必然加速、不把模型生成的自我評價當成測試證據、不把 AI 的技術能力誤當成公司授權與法律權利。

**關於平台：** Steamworks、GitHub、Godot、SPDX、SLSA、NIST、Software Heritage 等來源用於支持明確敘述的既有制度；相關條款與軟體功能可能改變，實際採用時需再次查核。不把第三方規格說成已驗證本文新框架。

**關於案例：** 三個產品尺度、權利障礙、附錄 JSON／YAML、測試矩陣均為示意，沒有提供虛構實測值。未來若進行實際接手實驗，應保留完整失敗案例、研究預註冊、風險處置、模型資訊與授權審核證據。

**關於公開：** 可繼承性是為合法受權的人、團隊與 AI 建立產品延續能力，不等於強制公開商業核心、所有素材、完整契約或玩家個資。文件應按需要產生對外與內部不同投影，來源及保留範圍清楚。

**Canonical 原稿：** 本 UTF-8 Markdown 原始檔才是正式研究文本，聊天畫面僅為顯示。數學源碼只允許 ` $...$ ` 與 `$$...$$`；未以 Unicode 數學字元替代 LaTeX source，亦不經 `unicode_escape` round-trip。後續修訂應以版本化原稿執行來源、符號、公式與結構驗證，再提交新版本。