---
title: "從遊戲產線到企業管理：實證設計、治理指標與逐級部署"
english_title: "From Game Production Lines to Enterprise Governance: Empirical Design, Governance Metrics, and Staged Deployment"
series: "AI 原生互動企業論"
series_en: "AI-Native Interactive Enterprise"
series_abbreviation: "ANIE"
paper: "12"
author: "Neo.K"
institution: "一言諾科技有限公司（EveMissLab）"
research_assistance: "AI-assisted research, drafting, and reference verification"
version: "v0.1"
date: "2026-10-17"
language: "zh-TW"
status: "Research Paper / Canonical UTF-8 Markdown Source"
research_type: "Integrative theory, empirical research protocol, and staged-deployment specification"
evidence_status: "Conceptual and methodological proposal; not a completed field trial"
source_policy: "Canonical mathematics uses only $...$ and $$...$$; source must be independently validated before commit"
related_papers: "ANIE-00 through ANIE-11"
keywords:
  - AI-Native Interactive Enterprise
  - Empirical Governance
  - Verified Delivery
  - Selective Disclosure
  - Human-AI Accountability
  - User Innovation
  - Open Product Development
  - Causal Inference
  - Staged Deployment
  - Measurement and Audit
---

# 從遊戲產線到企業管理：實證設計、治理指標與逐級部署

## From Game Production Lines to Enterprise Governance: Empirical Design, Governance Metrics, and Staged Deployment

**《AI 原生互動企業論》（ANIE）第 12 篇｜全系列整合、研究與部署總結篇**  
**作者：Neo.K｜機構：一言諾科技有限公司（EveMissLab）**  
**版本：v0.1｜日期：2026-10-17｜原始格式：UTF-8 Markdown**

> **研究狀態宣告**：本論文整合 ANIE-00 至 ANIE-11 的概念與前置論證，並提出可實作與可反駁的研究協議。文中模型、技術契約、門檻、示例資料與部署時程，除非明確註明已有外部證據，均為研究設計或假設性案例；**不代表 EveMissLab 已完成部署、完成田野試驗、取得特定營收，或實證證明本系列的總命題**。法律部分僅提供研究與工程邊界，不代替個案法律意見。所有數字示例均不作公司實績。

**機構：** 一言諾科技有限公司（EveMissLab）  
**日期：** 2026-10-17  

---

## 摘要

人工智慧不只降低軟體原型、內容與文件的候選生成成本，也使企業對外資訊的蒐集、說明、版本對帳與持續回應在技術上更為可行。然而，「AI 生成更多成果」、「企業提供更多公開資訊」、「用戶能提出更多意見」與「組織真的更有效率、更可信任、更有競爭力」之間，並沒有必然推論關係。當生成供給、外部需求與企業治理同時擴張時，反而可能出現驗收擁塞、代理式錯誤承諾、社群代表性偏差、過度揭露、權利鏈不明、品質成本轉移，以及以漂亮儀表板取代真實改進的測量幻覺。

本論文提出一項**AI 原生互動企業的可證偽整合架構**（Empirically Testable AI-Native Interactive Enterprise Architecture，以下簡稱 ET-ANIE），將連續產品交付、玩家／顧客協商、MOD 與商業 PR、AI 客服、公共決策帳本、選擇性透明及企業競爭策略，編排為一套權限明確、證據可追溯、成本可度量、可以被外部理解但不必全部公開的組織制度。此制度以單機遊戲產線為起點，因其具有可辨識的版本、購買與遊玩行為、錯誤回報、MOD 生態及季度更新事件；研究的最終對象則是一般企業中具有產品、客戶與外部參與關係的工作流程。

本文主要貢獻包括：（一）提出跨 ANIE-00 至 ANIE-11 的權責、物件與證據整合矩陣；（二）建立「可驗證交付—有效外部理解—適當參與—風險與全成本」的多目標評價方式，避免以單一公開比例、工單結案率或 PR 合併數量替代企業價值；（三）設計小型團隊可執行的基線研究、配對任務實驗、分階段導入與差異中的差異分析，並說明無法識別因果效果時應如何誠實報告；（四）提出七階段部署階梯、拒絕與回退門檻、公司資訊主權與多方權利治理；（五）提供事件資料契約、JSON Schema、權限政策草案、指標字典、實證預註冊及負面測試範本。

本論文的主張不是 AI 必然讓企業更開放、效率更高，也不是社群投票應取得公司治理權。相反，本研究認為：**企業是否應擴張公開、外部協作與 AI 授權，必須逐項由可觀察的交付品質、客戶理解、法律權利、競爭成本與實際驗證結果決定；能力的存在不構成直接授權。** 當假說無法獲得支持時，縮減、停止或逆轉部署，仍是研究體系預期且正當的結論。[P00][P02][P04][P09][P10][P11]

**關鍵詞**：AI 原生互動企業、季度單機產品制、可驗證交付、選擇性透明、公開決策帳本、玩家協作、人工智慧客服、組織學習、因果推論、逐級部署、治理指標、非僭位授權。

---

## 0．研究目標與界線：這是一篇「驗證與部署」論文

### 0.1 從對話中的直覺到可檢驗制度

本系列最初來自對 Steam 搶先體驗（Early Access，EA）的觀察：部分作品長期沒有明確更新，玩家難以知道開發者正在做什麼；與此同時，AI 工業化開發正在改變獨立開發者的產能邊界。第一個直覺是：如果已具備可重複生產的 AI 工作流，產品就不必以「神祕的黑盒開發」面對玩家，應可建立雙週、月度、季度的交付、公開與回饋機制。[P01][P02]

後續討論逐漸超越 EA：從 MOD 原生介面、跨版本穩定、遊戲 PR、玩家契約合作，到獨立官網、AI 客服、決策帳本，以及企業對外資訊的選擇性揭露。最終命題不再只是「一款遊戲怎麼更新」，而是「一家公司如何在保持合法權限與商業自主的前提下，讓其產品與外部世界形成可追蹤、可修正的長期互動」。[P04]–[P11]

ANIE-12 的責任是把這些命題從規範性設計推進到**可操作的研究計畫**；它不重寫其他篇章的全部詳細定義，亦不聲稱已在市場上證實整個系統。

### 0.2 六項研究問題

1. 在相同任務難度、品質條件與必要成本下，AI 生產線是否提升真正向玩家交付的成果，而不只是提升候選輸出量？
2. 對外公開進度、決策及其證據，是否使使用者更正確理解產品，而不只是使網站訪問、按讚或投票增加？
3. 當公司採納、拒絕或延期玩家需求時，有解釋與追蹤機制的互動制度，是否改善後續信任與問題處理？
4. 原生 MOD、外部 PR 和契約合作是否帶來經過權利驗證、品質驗收及維護成本計算後的淨增益？
5. AI 客服、決策建議及發布輔助在何種權限與檢驗條件下能降低總成本，同時不增加錯誤承諾、歧視、隱私侵害與安全事件？
6. 上述機制從遊戲產品推廣到企業其他部門時，哪些效果可以遷移，哪些必須重新定義與測量？

### 0.3 本文不主張的事情

- 不主張「所有 EA 都應三個月完成」，亦不以季度目標當作保證完工的法律或道德承諾。
- 不主張 AI 生成程式能力必然等於可持續商品交付能力。
- 不主張玩家投票、社群聲量或意見數量構成公司決策授權。
- 不主張商業產品開放 PR 就需要開放全部原始碼、劇情或商業機密。
- 不主張客服回應完成、GitHub PR 合併或新聞發布等於產品功能已交付。
- 不主張可觀察性等於全知，資訊公開等於問責，或企業資訊主權等於排除個人資料主體與第三方的法定權利。
- 不主張網站、Agent 或驗證器已經具備本文建議的所有工程能力。
- 不主張任何合成資料、範例 KPI 或推演結果是公司現況的證據。

### 0.4 三類知識狀態

- **O（Observed）**：有可辨識的具體外部來源、原始事件或測量紀錄。
- **H（Hypothesized）**：有理由提出，但尚未完成適當的因果或外部效度驗證。
- **E（Empirically Established in scope）**：在明確的人群、產品、時間與方法條件下得到充分支持；不能省略適用範圍。

研究所用的「已驗證」永遠是有邊界的，不能自動推論到所有遊戲、所有模型、所有公司或所有年代。[I03][P00]

---

## 1．前置研究的整體閉合：十二篇分工，不能以單一平台代替

| 前置論文 | 已提出的研究對象 | ANIE-12 應接收的最小輸入 | 不能直接繼承的假定 |
|---|---|---|---|
| [P00] 總綱 | AI 原生互動企業與權責界線 | 主體、交互與交付的總定義 | 全套制度已有效 |
| [P01] EA 與持續交付 | DEMO、Playtest、EA、正式版的路徑 | 發行條件及產品階段標記 | EA 為必經階段 |
| [P02] 季度單機產品制 | 額度、產線、品質交付率 | 任務、成本、測試與版本驗證 | 模型呼叫數等於產能 |
| [P03] 可繼承產品 | 原作者退出後的接手能力 | 接手包、授權、建置及陌生接手測試 | 有 Repo 等於可接手 |
| [P04] 玩家—開發者相交域 | 非服從式協商、代表性及可行域 | 玩家意圖、公司決策、替代方案 | 票數代表全部玩家 |
| [P05] 原生 MOD | 穩定 API、相容性及遷移 | 相容矩陣、語義／存檔測試 | MOD 可下載等於可安全運作 |
| [P06] 商業 PR | 外部貢獻、權源與報酬 | 取得授權的變更、合作記錄 | 接受投稿等於全面商業授權 |
| [P07] 跨平台資訊中心 | Steam、官網、GitHub、內部投影 | 來源 URI、跨平台狀態與對帳 | 官網替代所有平台事實 |
| [P08] AI 客服與回饋 | 個案—問題—產品回流 | 需求來源、私有案件與升級證據 | 工單結案等於根因解決 |
| [P09] 公開決策帳本 | 提案、批准、承諾、交付證據 | 事件鏈、強度、可更正記錄 | 日誌完整等於真實世界成功 |
| [P10] 選擇性透明 | 分級、時序、授權與公開投影 | 公開政策、個資和第三方權利限制 | 可讀取等於可發布 |
| [P11] 開放與競爭力 | 社群創新、模仿與長期信任 | 市場、社群、成本與策略比較 | 開放程度越高必定越好 |

上述前置研究是本系列**內部理論來源**，不是外部同行評審或公司已完成試驗的替代品。整體驗證必須面對外部文獻、真實平台規則、可追溯事件與對照試驗。內部研究即使互相引用，也不能以引用次數形成虛假的獨立支持。

---

## 2．外部知識脈絡與新增命題的限度

### 2.1 AI 軟體交付的組織效應

DORA 2025 的軟體開發研究將 AI 描述為既有組織條件的放大器，而非只要部署 AI 工具就能獲得一致的績效增益。[E01] DORA 在衡量軟體交付時，也將吞吐與不穩定性分開，並演進為變更前置時間、部署頻率、失敗部署復原時間、變更失敗率及部署返工率等五項指標。[E02] 本研究沿用其「速度與穩定性必須同時測量」的觀念，但對單機遊戲新增存檔相容、世界狀態正確性、內容完成度及真人可玩價值的條件。

METR 在 2025 年針對有成熟程式庫經驗的開發者進行受控研究，測得特定條件下 AI 導致平均完成時間增加；其 2026 年後續研究又指出，因受試者退出、工具習慣及多代理使用等因素，較新的估計值存在重大選擇偏誤與量測困難。[E03][E04] 因此，AI 效率研究不可因單一研究就判斷「永遠加速」或「永遠減速」，也不能把無限制的模型額度視為無成本的無限產能。

### 2.2 客訴、管理與 AI 風險

ISO 10002:2018 為組織處理客訴、分析回饋、改善服務及評估流程提供一般性指引。[E05] 但它不會自動替某家公司形成永久可查的「個案—產品問題—決策—版本證據」資料模型。NIST AI RMF 及其 Playbook 則以 Govern、Map、Measure、Manage 的功能架構管理 AI 風險，且明確是可依場景調整的自願性工具，而非每家公司完成後必然合規的認證清單。[E06] ISO/IEC 42001:2023 提供 AI 管理系統要求，與本研究的產品化資料契約及公司治理過程具有參照關係，但本研究並不宣稱獲得其認證。[E07]

### 2.3 外部共同創作、透明與競爭力

使用者創新、參與式設計、開放創新及選擇性揭露已有成熟理論。[E08][E09] Fox 等研究指出透明與問責並不能畫上等號；揭露若缺少能被質問與修正的決策程序，可能只形成更多資訊而不是更好的治理。[E10] 本篇的新增範圍不是首次發現社群能共同創作，而是在 AI 產能與可驗證交付的背景下，提出一套可執行的連續事件、權限、測量與回退框架。

### 2.4 既有評估方法可以借用，但要承認限制

差異中的差異（Difference-in-Differences，DiD）、隨機對照與 stepped-wedge（分批隨機導入）等設計已廣泛用於政策及服務流程評估。[E11][E12] 本論文採用它們作為研究工具，並非發明新的因果推論方法。特別是小型 AI 原生企業可能只有一名核心管理者、少數遊戲及有限時段，因此很多結果只能得到探索性證據；不應在樣本不足時以複雜統計模型假裝具有精確的市場普遍結論。

---

## 3．ET-ANIE 的操作性定義與主體界線

**AI 原生互動企業（ANIE）**：在合法權限與適當資訊邊界下，將產品生產、外部問題、參與貢獻、內部決策及實際交付的事件持續關聯，利用 AI 降低處理與協調成本，並讓利害關係人能依授權查詢、提出異議及理解處置結果的組織架構。

**ET-ANIE**：在上述架構之上加入預先定義的評估單位、對照條件、觀察期、主要結果、負面結果、揭露策略、權限檢查與回退程序的研究版本。

**單一事實源不等於單一權威平台**：真實遊戲 Build 由平台／可取得的發行成果確認；原始碼及測試結果有各自的證據位置；企業決策及授權有其責任人；公眾網站只能對這些事實作經授權投影，不得以一段網站文字改寫事件原貌。[P07][P09]

**長期回饋不等於無限保存私人資料**：可以延續具合法基礎的產品問題統計與適當匿名化知識，但不能為了「完整帳本」而拒絕依法更正、刪除或限制個資使用。[P08][P10][E13]

**多主體參與不等於平等決策權**：公司、玩家、外部創作者、合約合作方、AI Agent 與第三方平台對同一個產品具有不同權利、責任及停止權。角色分工應以合法授權、實際能力及事件影響決定，不由聊天界面的稱呼或 AI 表達方式決定。[P04][P06][I02]

### 3.1 最小物件模型

一個可追蹤的企業—產品世界至少包含：

$$
W_t=(P_t,V_t,Q_t,C_t,D_t,R_t,A_t,L_t,E_t)
$$

其中：

- $P_t$：產品及其生命週期；
- $V_t$：可取得的版本與部署目標；
- $Q_t$：外部需求、缺陷與問題；
- $C_t$：貢獻、MOD、PR 與合作；
- $D_t$：決策及對外承諾；
- $R_t$：必要資源、成本與限制；
- $A_t$：人員、AI 與授權角色；
- $L_t$：法律、合約、保密與資料權利；
- $E_t$：原始事件、稽核證據及公開投影關係。

 $W_t$ 不是全知或完整公司世界，而是指定研究窗口內、權限允許及可辨識事件所構成的**部分可觀察狀態**。未知、被撤回、禁止保存及不可取得的資料均應具有明確狀態，不得被模型自動補成確定事實。

### 3.2 六條不可跨越的推論邊界

$$
\begin{aligned}
\mathrm{Generated} &\not\Rightarrow \mathrm{Integrated} \\
\mathrm{Integrated} &\not\Rightarrow \mathrm{Accepted} \\
\mathrm{Accepted} &\not\Rightarrow \mathrm{Published} \\
\mathrm{Published} &\not\Rightarrow \mathrm{PlayerVerified} \\
\mathrm{Visible} &\not\Rightarrow \mathrm{Authorized} \\
\mathrm{Observed} &\not\Rightarrow \mathrm{CausallyEstablished}
\end{aligned}
$$

本文把這六條稱為 **ANIE Integration Boundaries**。其作用是將各篇前置研究中常見的「已完成」「已公開」「已理解」拆解成不同可驗證命題，防止某個流程的綠燈被誤用為另一個流程的成功結論。

---

## 4．從遊戲產線到企業管理：跨域而不等同

遊戲產品的優勢在於具有版本、存檔、玩法、玩家回饋、平台評論及外部 MOD。這些物件適合建立閉環測試。但其他企業部門並不必然有遊戲版本或玩家；因此要複用的是治理抽象，而不是強迫所有部門套用遊戲名詞。

| 遊戲場景 | 企業一般場景 | 可轉移的治理關係 | 不可直接轉移的事項 |
|---|---|---|---|
| 版本發布 | 軟體、服務或政策變更 | 承諾對應可核驗結果 | 版本號形式與發布頻率 |
| 玩家 Bug | 客訴或營運缺陷 | 需求來源—處置—驗收—回告 | 遊戲 P0 分級不能原樣套用醫療等高風險產業 |
| 玩家提案 | 顧客、社群或供應商建議 | 相交域、拒絕理由、替代方案 | 投票母體、購買者身分與法定代表權 |
| MOD／PR | 外部合作成果 | 權源、審核、測試及報酬 | 平台 Workshop 的特定授權 |
| Steam 公告 | 品牌公告或產品通知 | 來源鏈接及版本對帳 | 平台規範、法定揭露義務 |
| AI 遊戲客服 | 公司客服與互動專員 | 有限授權、案件回流、誤承諾控制 | 個資種類、救濟方式與法規要求 |
| 季度遊戲里程碑 | 產品線或部門工作週期 | 目標、例外與品質驗證 | 各產業法定時程與產品風險 |

**可遷移性必須被重新實證**。若遊戲玩家能容忍的延期程度和企業顧客期望不同，並不代表模型失敗；它代表跨域參數不能沿用。新產業的治理能力，應根據當地法律、生命財產風險、交易契約、顧客權利及實際生產鏈重新建立。[E06][E07]

---

## 5．統一事件因果鏈：從外界輸入到世界內真實結果

### 5.1 九種核心事件

1. **Observation**：可辨識的外部輸入或內部測量。
2. **Issue**：經分類的問題或功能需求。
3. **Proposal**：被討論的候選方案，尚不構成承諾。
4. **Decision**：具合法權限的採納、拒絕、試驗或延期。
5. **Commitment**：對外具有明確範圍、條件和責任人的表示；不得由 AI 推測。
6. **Implementation**：程式、內容或制度的候選變更。
7. **Validation**：特定品質與合法性條件下的驗收證據。
8. **Delivery**：實際到達使用者可取得環境的結果。
9. **Follow-up**：觀察真實效果、回告、更正或再開案。

這九種事件構成參照流程，並非全部一定按單一線性順序發生：一項觀察可能導致拒絕；一項發布可產生新的缺陷；一個協議可能在權利審查失敗時終止。

### 5.2 分離技術、法律與公眾陳述

同一項需求至少具有三種獨立判定：

$$
S(x)=(S_{tech}(x),S_{rights}(x),S_{public}(x))
$$

 $S_{tech}$ 記錄建置與品質， $S_{rights}$ 記錄商業使用與權利鏈， $S_{public}$ 記錄對外陳述的授權及證據是否充分。只有其中一軸通過時，不得宣布三軸全部通過。例如玩家提交一個修好崩潰的 MOD，若著作權或第三方素材來源尚不清楚，不能因程式碼成功合併就把它加入收費正式版。[P05][P06][P09]

### 5.3 狀態更正應是新事件，不是無痕覆寫

事件紀錄中至少應分離 `occurred_at`（原事件時間）、`recorded_at`（系統看到時間）、`verified_at`（核對完成時間）與 `published_at`（對外發布時間）。更正應有版本、原因、授權者與指向原事件的關聯。原文若涉及個資或安全風險，不能為了保留不可變歷史而繼續公開；可以保留符合法定要求的有限更正痕跡、刪除敏感原文並更新公開投影。[P09][P10]

---

## 6．權限、責任與可修正性的最小治理矩陣

| 行動 | AI Agent | 工程／客服角色 | 法定或正式公司決策者 | 外部主體 |
|---|---|---|---|---|
| 接收與分類合法回饋 | 可以在授權範圍自動化 | 負責升級例外 | 制定政策 | 可提出及要求處理 |
| 形成方案與風險摘要 | 可以建議 | 審核事實 | 決定必要的正式審查 | 可質疑摘要失真 |
| 決定遊戲設計優先級 | 可以推估選項 | 提供工程和社群證據 | 具授權者最終決策 | 能參與但無當然表決權 |
| 承諾交付或退款 | 無預設權；僅執行已核定政策 | 依授權處理 | 定義並承擔承諾 | 保有契約及法定權利 |
| 修改原始碼／MOD | 在沙盒依權限提交候選 | 審查、測試、整合 | 按風險批准 | 在權源許可下貢獻 |
| 公開公司資料 | 只能產生候選稿或已授權的受控投影 | 分類、驗證、執行 | 批准公開政策與例外 | 資料主體可依法行使權利 |
| 處置隱私／安全事件 | 可輔助偵測、限權停用 | 執行緊急程序 | 依法定與公司責任主持 | 得尋求救濟或申訴 |
| 更改研究指標／停止實驗 | 可報告失敗及建議 | 保存原始紀錄與提出停止 | 具獨立判定及終止權 | 參與者可依同意條件退出 |

對小公司而言，一人可能兼任多個角色，但**權限角色不應因人數少而合併成不可追蹤的同一個 AI 身分**。高風險操作若缺少第二位獨立覆核者，可以採取暫停發布、延遲放行或受限測試，而不是虛構兩個 AI 互相審查就等於人類獨立監督。[I01][I02][I03]

---

## 7．成果不能只有一個總分：四個不可替代的目標

本研究的最小目標向量定義為：

$$
Y_t=(Q_t,U_t,C_t,G_t)
$$

其中：

- $Q_t$：**品質驗證後的交付表現**，包括可玩版本、遊戲品質、存檔安全及實際完成範圍；
- $U_t$：**外部理解與適當參與**，包括玩家正確理解狀態、回饋處理與拒絕理由可理解度；
- $C_t$：**總成本與可持續性**，包括額度、AI、人工、審查、發布、失敗返工及維護；
- $G_t$：**治理與權利完整性**，包括合法性、資料安全、承諾準確及權限正確性。

不宜強行把不同性質的資料壓成單一「透明績效」或「AI 生產力」分數。若研究需要決策，可以使用**非補償性門檻**：先檢查法定義務、重大安全、存檔保護與真實陳述等硬性條件，再比較剩餘方案在 $Q_t,U_t,C_t$ 上的權衡。

形式化為：

$$
\max_{a\in\mathcal A} F(Q(a),U(a),-C(a))
$$

$$
\mathrm{subject\ to}\quad G_k(a)\geq g_k,\quad k\in\mathcal K
$$

 $F$ 是明確聲明的產品／研究偏好，不預設為所有企業通用； $g_k$ 是由法律、公司風險政策與產品安全條件決定的門檻。禁止將「大量玩家好評」拿來抵銷嚴重個資外洩或未授權商業素材。

### 7.1 三種原始資料層

- **第一層：原始事件**。Build、測試結果、客訴、合約、客服回應及發布紀錄，分權存放。
- **第二層：指標／驗證證據**。可以重算的資料分母、品質狀態、獨立抽查與異常紀錄。
- **第三層：公開摘要投影**。經授權的統計、決策理由、版本證據連結及未知項目。

第一層不是必然公開；第三層不是第一層的全量副本。不同層必須能在合法權限內對帳，但對帳權也不等於任意跨層存取權。[P07][P09][P10]

---

## 8．最小指標字典：每個指標都要有分母、期間與反例

### 8.1 產品交付與品質

| 代碼 | 定義 | 主要分母或範圍 | 常見錯誤 |
|---|---|---|---|
| `validated_delivery_rate` | 對季度凍結目標，在期限內完成且通過指定驗收的加權份額 | 期初已核准並凍結的目標權重總和 | 期末刪除未完成目標後報 100% |
| `verified_player_release` | 玩家在指定平台可取得且可核對 Build ID 的發布事件 | 研究期間全部宣稱已發布項目 | 把 PR 合併當成已上架 |
| `critical_defect_density` | 符合既定重大缺陷準則的數量相對於適當暴露量 | 特定遊玩時數、會話或驗證 Build；按情境選 | 把零回報當成零缺陷 |
| `save_integrity_rate` | 通過指定升級、回退與世界狀態驗收的存檔份額 | 有資格測試的存檔矩陣 | 只測能載入，不測世界語義 |
| `rework_ratio` | 為修復失敗、補救或重新整合所消耗的必要工時／成本份額 | 同一產品及時間窗的全部相關工作量 | 把 AI 重做算新功能 |
| `handover_success` | 陌生接手者在限定時間內完成指定修復及驗收 | 預先定義的接手任務 | 原作者在背後給未記錄提示 |

若期初目標權重為 $w_i$，且 $a_i$ 是在約定期限及品質閘門均通過時取 1 的指示變數，則：

$$
VDR=\frac{\sum_{i=1}^{n}w_i a_i}{\sum_{i=1}^{n}w_i}
$$

研究必須事先固定 $w_i$ ；若分母為零，應標為「無有效目標／不可計」，不能自動填 100%。若季中合法更改目標，保留期初與修訂後兩種序列，並記錄是否影響原始主要結果。

### 8.2 玩家理解、回饋與協商

| 代碼 | 定義 | 分母或抽樣 | 不能代替的結果 |
|---|---|---|---|
| `status_comprehension_accuracy` | 閱讀公開資訊後，正確辨識功能狀態、承諾強度及版本的比例 | 參加指定理解測驗且完成者 | 網站瀏覽、點擊、好評 |
| `feedback_linkage_recall` | 被合法保留且確實應關聯的案件，有多少正確連到產品問題 | 獨立標註真陽性案例 | AI 摘要字數 |
| `minority_issue_detection` | 對低聲量但高影響議題的辨識與適當升級程度 | 由盲化抽樣建構的真實高風險案例 | 多數投票結果 |
| `decision_explanation_quality` | 外部讀者理解「為何拒絕或延期」的測驗結果 | 分層抽樣的可閱讀決策 | 制式客服套話 |
| `appeal_reopen_rate` | 有新證據、程序錯誤或政策修訂而適當重審的案件比例 | 達到重審資格的案件 | 所有案件重開越多越好 |

理解測驗應使用實際問題，例如「該功能是已發布、內部完成、排程中，還是只在研究？」而不是問「你覺得公司是否透明？」。後者可以是次要態度變數，但不能取代資訊準確性。回饋分類要注意投票網站的自選樣本、少數玩家的高風險需求及多帳號灌票。[P04][P08]

### 8.3 外部創作與合作

| 代碼 | 可操作定義 | 分母 | 易犯錯誤 |
|---|---|---|---|
| `accepted_contribution_value` | 外部貢獻中完成權利審核、品質驗收且實際交付的加權價值 | 合法受理的投稿集合 | 以 PR 數量代替成果 |
| `contribution_total_cost` | 審核、法律、維護、支援、報酬與整合的全部可辨成本 | 對應的貢獻或產品窗口 | 只算付給 MOD 作者的費用 |
| `mod_compatibility_pass` | 指定遊戲／MOD／存檔版本矩陣的通過比例 | 事先列明的組合總數 | Workshop 顯示可下載即宣稱相容 |
| `royalty_timeliness` | 依契約到期且實際符合支付條件的準時支付比例 | 到期且可支付的有效結算 | 把未簽署協議視為免費授權 |

### 8.4 AI 成本、權限與風險

| 代碼 | 定義 | 不得省略的成本／條件 |
|---|---|---|
| `verified_output_per_cost` | 品質驗收後成果相對於必要總成本 | AI 用量、人工、CI、返工、發布與維護預估 |
| `unauthorized_commitment_rate` | 對外回覆中未取得適當權限卻表示為正式承諾的比例 | AI 與人類外部回覆均應抽檢 |
| `privacy_boundary_violation` | 研究定義下的未授權讀取、持久化或輸出事件 | 包含公開、日誌、向量庫及第三方連接器 |
| `audit_reconstruction_success` | 獨立人員按授權重建決策與證據的成功比例 | 不允許利用未記錄口頭解釋 |
| `human_override_recorded` | 人類覆核、否決、停止或修正是否被如實記錄 | 不能把沒有異議誤讀成 AI 必定正確 |
| `incident_recovery_time` | 從確認事故到安全控制與必要通知完成的時間 | 應與危害程度、法律期限分層 |

**分母規則**：所有比率須記錄資料來源、適用期間、排除條件、可觀察母體、缺失值與右截尾（尚未完成觀察）狀態。不能用「處理了 300 件」來代替「處理得正確」。也不能在高風險案例未被發現時，以零個事故宣稱系統安全。[P02][P08][P10][E06]

---
## 9．可驗證能力的成熟度：不是功能清單，而是逐層證據

本研究提出七級 **Interactive Enterprise Evidence Maturity（IEEM）** 階梯。階梯指涉的是「證據與權限制度的成熟程度」，不是遊戲內容數量、公司規模或 AI 模型排名。

| 等級 | 名稱 | 能觀察或執行什麼 | 升級前的證據 | 不允許的越級行為 |
|---|---|---|---|---|
| L0 | 私有基線 | 人工記錄版本、問題與費用 | 來源清楚且可回算 | 沒有紀錄卻宣稱提升百分比 |
| L1 | 受控事件紀錄 | 維持唯一 ID、來源與時間 | 有效的存取控制與事件對帳 | AI 任意改寫既有決策 |
| L2 | 唯讀公開投影 | 對外展示已授權進度、版本與已知限制 | 欄位白名單與撤回程序測試 | 將原始私有日誌同步到公開站 |
| L3 | 雙向外部回饋 | 接收提案、異議、投票與補充證據 | 重複案件處理與代表性監測 | 讓投票直接觸發產品發布 |
| L4 | AI 有界輔助 | AI 分類、建議、草擬與追蹤，不自動僭越批准權 | 越權、幻覺、隱私負面測試 | 未經授權的退款／功能承諾 |
| L5 | 受控共創交付 | MOD、PR、外部契約合作與實際版本連結 | 權利鏈、獨立驗收、可回退構建 | 取得素材後直接收費使用 |
| L6 | 跨部門可實證複用 | 以同一資料規格遷移至公司不同產品線 | 新場景獨立驗證與持續淨收益 | 以遊戲試點代表整個企業已成功 |

各層可在產品或部門內分別評估。一家公司客服流程達 L4，不表示財務、研發或對外公關也自動達 L4。成熟度不能因 AI 模型更換、網站視覺改善或增加公告頻率而直接提升。從 L3 退回 L2 可能是為了修正重大資料風險，並非制度退步；在沒有維護資源的情況下，**保留真正可維持的較低層級，比展示不可持續的高層級更好**。

### 9.1 可逆部署的必要條件

若某階段具有公開資料寫入權或對外行為，應在啟用前證明下列最低能力：能停止新事件、能回退版本、能通知受影響者、能區分撤回前後的有效資訊、能修復不一致資料，並能在未來訴求合法存取時保存最少必要的稽核資訊。尤其不可把區塊鏈式的不可刪除性當成全部公開帳本的必要美德，否則可能與個資刪除、更正、安全揭露延期及合約保密相衝突。[P09][P10]

---

## 10．實證核心：干預是什麼，反事實又是什麼？

### 10.1 研究單位與干預定義

四種主要評估單位分別為：

- **任務單位**：可明確定義輸入、預期結果、驗收與成本的小型工程、測試、內容或客服任務；
- **版本單位**：在指定平台、遊戲版本與觀察期內發生的一組變更；
- **問題單位**：可以跨不同客服案件、玩家帳戶與 Build 的同一根因問題；
- **組織流程單位**：跨部門的工作流程，如提案評估、對外公告、合作收錄或客服升級。

AI 生產線之「干預」必須具體到模型或工具版本、模型額度、上下文與提示規範、是否使用 Agent、多模型協作方式、測試工具及人力投入。僅寫「使用 AI」通常不足以識別何種機制可能帶來變化。

在相同類型的任務 $i$ 上，以 $Y_i(1)$ 表示接受指定干預的潛在結果，以 $Y_i(0)$ 表示未接受的潛在結果；想估計的量是：

$$
\tau=E[Y_i(1)-Y_i(0)]
$$

同一任務的兩個潛在結果通常不能同時被實際觀測，因此必須有可信任的指派方式或反事實比較。真實產品不能僅以「這次做得比以前快」宣稱 AI 或公開透明必然造成改進，因為任務難度、資產成熟度、玩家數量、季節性、模型版本與開發者經驗都會變動。[E11][E12]

### 10.2 在單一遊戲公司裡最可行的三組小實驗

**實驗 A：AI 工程產線**。以預先分類的修復、UI、測試、內容及相容性任務為單位，將難度、既有代碼量、依賴關係與驗收規格記錄後，再以合適方式隨機或配對配置到不同 AI 額度／工作流。主要結果為品質驗收後交付的時間與必要全成本；次要結果為返工、P0／P1 缺陷及存檔測試。安全關鍵功能不得為了研究隨機分配到不足的安全保護條件。若使用同一位開發者反覆做同一任務，學習效應會使結果失真，需採取同難度不同任務、交錯次序或平衡交叉設計。

**實驗 B：公開資訊理解**。將同一個真實產品狀態以「傳統公告」與「含狀態、理由及證據的結構化頁面」兩種形式呈現；在不欺騙玩家、不錯置資訊權利的前提下，隨機分配合適的讀者測試理解率、答題時間、錯誤的未來承諾推斷率及問答成本。這類實驗可以在封閉測試中先完成，不必把錯誤資料公開給真實消費者。

**實驗 C：客服知識回流**。在不影響法定救濟、重大事故處置和資料權利的前提下，對一般性低風險客服題型比較：（C0）傳統工單、（C1）人工使用統一問題索引、（C2）AI 協助關聯與摘要。主要觀察「真正原因的問題是否被發現、處理、驗證及回告」，而非單看聊天平均處理秒數。對有安全風險的案件仍走共同的強制升級機制。

### 10.3 可以做對照，不能強迫所有工作都做對照

如果某項功能已被認定可能破壞存檔，研究不應隨機讓一半玩家無警告地失去資料。對於災難修復、權利要求、重大安全事件及法定通知，倫理與法律底線優先。若無法安全地設立對照，可以改以事前資料、專家獨立審核、模擬環境或事件研究設計，但結論應降低因果強度。

---

## 11．從單一產品到多產品：分批導入與準實驗

### 11.1 分批導入設計

如果企業具有多個產品或可隔離的流程單元，且所有單元最終都計畫接受干預，可以考慮以隨機或預先規則安排的順序啟用互動平台。Stepped-wedge 隨機設計允許不同集群在不同時間進入新制度，同時須處理時間趨勢、群內相關、處置暴露及跨組干擾。[E12]

例如有四個可獨立觀察的流程：遊戲 A 的公告、遊戲 B 的公告、技術工具的 Bug 回報、一般客服的知識庫。這四者不是完全同質，也可能分享開發者或讀者，因此更合理的是先檢查可比性，可能只在同類公告頁內做分批導入，而不是直接將所有資料丟進同一個平均數。

### 11.2 準實驗比較

在兩組具充分可比性的產品或流程中，可以比較前後變化：

$$
\widehat{\tau}_{DiD}=(\overline{Y}_{T,post}-\overline{Y}_{T,pre})-(\overline{Y}_{C,post}-\overline{Y}_{C,pre})
$$

其解釋依賴平行趨勢或適當的替代識別假設。若新遊戲本來就進入爆紅期，或模型版本在干預時間同時大幅升級，即使 $\widehat{\tau}_{DiD}$ 是正數，也不能直接歸因於網站互動制度。研究需紀錄同期產品發售、折扣、廣告投放、Steam 活動、玩家數量、內容發布與 AI 工具版本。多期錯峰導入時，應採用適合異質處置效果的現代估計方法，而非無條件套用簡單雙向固定效果回歸。[E11]

### 11.3 人、模型與資訊外溢

在同一家公司，開發者可能從 AI 處置任務中學到解法，之後即使不用 AI 也會受益；客服知識庫一旦建立，傳統組可能同樣能使用；社群玩家也會互相傳播資訊。因此干預並不一定只作用於被指定的個體。實驗必須界定 `unit_of_assignment`、`unit_of_analysis`、可能的外溢路徑與隔離成本。如果無法阻止外溢，就應評估群組或時間段層級的效果，不能把互相污染的資料當作獨立樣本。

### 11.4 發表負面結果的義務

若 AI 組輸出更多候選程式碼，但驗收後交付較少；或透明頁面讓玩家閱讀時間變長卻沒有改善正確理解；或社群 PR 經整合後總成本高於節省成本，這些都是有效研究結果。研究不得在看到結果後換用唯一變好的指標，亦不得把事故比例較高的組別刪除。

---

## 12．最小可行的 12 週試點與研究資源規劃

下列為建議性的**12 週試點**，不是對任何產品的完工或收益承諾。研究依工作量可延長，並允許在治理風險增加時縮減。對只有極少數人員的 AI 原生公司，最重要的是先證明流程能自行維持，不是先建立龐大客服中心。

| 期間 | 核心工作 | 研究或產品證據 | 推進門檻 |
|---|---|---|---|
| 第 1–2 週 | 確定一個遊戲／產品、基線指標、產品事件字典 | 現有版本與 Issue 的可重算基線 | 不需讀取私人原文就能彙總 |
| 第 3–4 週 | 建立事件關聯與唯讀內部看板 | 版本、PR、工單、決策 ID 對帳結果 | ID、事件時間及來源驗證通過 |
| 第 5–6 週 | 發布最低風險公開頁面 | 可查詢狀態、已知限制、公開 Build 來源 | 權限、撤回、更正與跨站連結通過 |
| 第 7–8 週 | 小範圍提案／理解研究 | 合法回饋、理解測驗與樣本偏差資訊 | 不允許投票直接變產品承諾 |
| 第 9–10 週 | 啟用 AI 有界分類／草稿 | 盲化案例抽檢、錯誤承諾與隱私測試 | 高風險誤判不得超出事先門檻 |
| 第 11–12 週 | 對帳、結果報告、風險審查 | 主要指標、負面結果、總成本及下一階段決定 | 允許停止、縮減或保持原狀 |

試點中**不要求**同時啟用 MOD 正式商業收錄、公開 PR 支付、自動補償或跨部門 AI 發布。這些較高權限的機制應留到 L5／L6，並在法律與公司資源準備充分後另外試行。

### 12.1 真正必要的人工工作

即使開發高度 AI 化，仍需要有人承擔：產品核心玩法與交付定義、玩家真實使用測試、隱私與授權的最終批准、重大外部承諾、財務支付，以及當資料顯示失敗時停止或更改制度。這些責任可以透過受訓合作夥伴及正式授權合理分配，不能因模型有能力提出答案便自動消失。

### 12.2 預算與額度應按風險分桶

本研究建議把有限的 AI 配額分為生產候選、程式驗證、負面測試、客服分類與資料彙總五個資源桶，並記錄跨桶移轉。資源不足時先停止低風險研究性展示與非必要自動摘要，不可因需要網站更新而削弱存檔測試、安全監測、個資處理和既有使用者支援。每個桶需要的是實際用量紀錄與壓力條件，而不是任意固定比例。

---

## 13．兩個季度、半年與一年：結果窗口不能混淆

**第一季度（建置與基線）**：可回答事件是否可追溯、能否正確展示、AI 是否越權，以及小型任務的品質與成本。

**第二季度（重複驗證與收斂）**：可回答相同指標在更多版本下是否保持穩定，是否出現長尾維護、錯誤分類、資訊流失或社群樣本偏差。可開始對比經分層配對的任務，但仍可能無法評估營收和長期信任。

**半年（跨版本演進）**：可以觀察 MOD 的跨版本相容性、公開決策是否被逐季修正，以及原始規劃和最後交付的差距。

**一年（跨產品與經營）**：在有足夠產品及樣本的情況下，才能初步評估玩家留存、開放與競爭、獨立接手、社群貢獻維護成本及制度是否可持續；仍不得把總體市場變化當成單一制度的因果成果。

觀察窗超過研究結束時點的事件應標為**右截尾**，例如「尚未滿足三十日發布後缺陷觀察」或「跨年度 MOD 升級尚未發生」。不能將尚未觀察到的事故當作零事故。[P02][P03][P05]

---

## 14．治理閘門、硬停止與回退觸發器

### 14.1 四種閘門

**G0：資料權利閘門**。權利來源、特定目的、保密分類、外部授權與個資處理被明確審核；不合法的資料不得因有研究價值就進入系統。

**G1：產品安全閘門**。可玩版本、重大缺陷、存檔與回退測試完成必要審查；嚴重問題不得被聲望或社群投票掩蓋。

**G2：公開正確性閘門**。公開文字、版本、承諾強度、來源與延時審查狀態一致；不確定事項明確呈現未知，而不是 AI 自行補完。

**G3：實證有效性閘門**。主要結果的定義、分母、對照條件與適用範圍可被獨立重算；沒有足夠資料時只承認探索性觀察。

### 14.2 硬停止範例（應依產品與法律審核調整）

| 觸發情況 | 最低處置 | 恢復條件 |
|---|---|---|
| 未授權發布個資、祕密或第三方合約 | 停止自動發布；啟動事故應對及必要通知 | 受影響範圍已查明、修復並重驗 |
| AI 自行承諾付款、退款或正式交付 | 停止相應回覆通道；核對對外承諾與救濟 | 權限路由與負面測試通過 |
| 已上架版本造成重大存檔損毀 | 啟動公告、停止散布或回退、修復受影響版本 | 存檔與世界狀態驗收合格 |
| 外部 PR 混入不明授權素材 | 隔離候選整合、停止商業收錄 | 權源可證明且依契約取得所需權利 |
| 量測管線丟失分母或關鍵證據 | 停止宣稱改善百分比 | 能回溯重算、揭露缺失窗口 |
| 合理的資料刪除／更正要求遭阻擋 | 暫停受影響資料流並依規處理 | 權利程序有效，必要痕跡有合法基礎 |
| 嚴重的外部平台公告對帳不一致 | 暫停跨平台自動同步 | 確認各平台真實狀態並更正 |

停止可以是局部的，不必關閉整家公司；但不可為保留某項漂亮指標而隱藏觸發條件。研究需記錄每次停止是否因事故、預防或制度調整而發生，避免把主動停止當成單純失敗。[P08][P09][P10][E06]

---

## 15．AI Agent 的工作分層：從助手到有限自治，而非自動升權

ET-ANIE 可區分六種 AI 角色：

1. **Reader**：在授權資料域內閱讀、比對與標出未知資訊。
2. **Classifier**：提出問題分類、重複案例候選、嚴重度及證據來源。
3. **Analyst**：統計、差異分析、風險與反例搜尋，保留測量不確定性。
4. **Draft Writer**：撰寫公告或回告草稿，不宣稱已批准。
5. **Engineering Agent**：在隔離工作區提交候選修復、測試和 PR，受分支保護及授權制約。
6. **Authorized Executor**：僅對事先批准、可逆、可觀察的低風險行動執行有限自動化；任何權限擴張須重新獨立審查。

其中不同角色可以由同一基礎模型扮演，但權限憑證、資料域、批准與日誌應由模型外部的系統控制。不能以 prompt「你不能洩密」取代技術隔離；不能把 Agent 的自我陳述當作權限判斷；不能因兩個 Agent 相互同意就取得公司授權。[I02][I03][E06]

### 15.1 AI 產出驗收證據的可信度階梯

| 等級 | 事件 | 對外可以說什麼 |
|---|---|---|
| E0 | AI 宣稱完成 | 僅可稱「AI 回報候選結果」 |
| E1 | 產出檔案存在且可識別 | 已生成可檢查的產物 |
| E2 | 型別、格式與局部測試通過 | 已通過明列的自動檢查，不保證語義正確 |
| E3 | 工程及語義驗收通過 | 已在指定條件通過驗收，不保證已上架 |
| E4 | 真實平台發布可回查 | 指定版本已實際發布／可取得 |
| E5 | 玩家／外部環境結果得到觀察 | 指定人群與時間窗內有被觀察的使用結果 |
| E6 | 重複或對照驗證支持效果 | 在明確的研究範圍內支持效果推論 |

對外報告不能把 E2 的測試通過寫成 E5 的玩家體驗改善；也不能把 E4 寫成 E6 的因果結論。高階證據不會自動證明所有低階品質維度已覆蓋，仍需對每一項後置條件提供實際證據。

---

## 16．資料連結、工程架構與最小攻擊面

建議先保留企業內部資料為各自來源，再由一個限權的事件層建立關聯，而不是把所有 GitHub、Steam、客服原文、帳務與私人公司資料合併成單一大型 AI 可讀資料庫：

```text
Private Authoritative Sources
├── Game repo / CI / release evidence
├── Product plans / decisions / task evidence
├── Support tickets / rights requests / private data
├── Contributor contracts / compensation / rights chain
└── Expense / quota / build / testing records
                |
      Read-only or purpose-limited adapters
                |
        Event and Evidence Registry
                |
       Policy + Provenance Checking
           /                  \
    Private Review       Public Projection
    + AI Suggestions     (allowlisted fields)
           |                  |
    Human Authority      Public Website
           |             / Steam references
       Approved actions  / GitHub references
                |
      Post-publication verification
                |
       Append correction event
```

### 16.1 ID 與跨來源關聯

至少要求 `product_id`、`issue_id`、`decision_id`、`commitment_id`、`release_id`、`evidence_id`，另以 `actor_id` 與 `policy_version` 追蹤合法操作。不同外部平台的 ID 應保留來源命名空間，避免把 Steam Build 與 GitHub Commit 混作同一實體。需要轉譯時，以具版本的 mapping 表承接，不能因兩者名稱相似就直接合併。

### 16.2 研究與生產不能共用無限制權限

研究 Agent 可在匿名或合成資料上測試假說，不表示它需要讀取公司完整客服紀錄。給真實使用者回覆的 Agent 只能取得指定案件及核准政策；訓練資料、測試資料與真實業務資料不應未經授權任意回流。需要匯出資料給外部研究者時，以目的最小化、資料去識別與契約權限控制為優先，另保留資料回收與刪除機制。[E13][E06]

### 16.3 事件統計不等於全量監控

OpenTelemetry 可提供 traces、metrics、logs 的標準化儀表能力。[E14] 但採用追蹤系統不表示應記錄完整客服對話、員工私人活動或敏感 Prompt。應由目的限制、採樣、遮罩及保留期決定哪些內容能進入遙測；技術上的可觀察性只解決部分排障問題，不能取代當事人的權利。

---

## 17．法規、消費者保護、智慧財產與平台規則的地位

ET-ANIE 不是新法源。對外承諾、產品收費與退款仍受適用的平台契約及消費者法令拘束；MOD 商業收錄涉及原創者及第三方權利；客服可能處理可識別玩家資料；公司公開的資料可能涉及商業秘密或依約保密內容。

以臺灣為例，《個人資料保護法》法規資料庫所呈現的 2025 年修法部分條文尚未生效，不能將「已修正」與「已施行」混為一談；公司必須依實際適用版本、目的與資訊類型進行合法性審查。[E13] 若涉及營業秘密、消費者保護、受僱與委託著作，應對具體場景查核當期法規與契約，而非拿本研究論文作統一法律結論。

Steamworks 的 EA 規則強調遊戲現在必須有可玩價值，也提醒開發者不應對未來日期與功能作無法保證的具體承諾；官方 Roadmap 頁提供展示未來方向的選擇，但不會自動改變平台承諾規範。[E15][E16] GitHub 的分支保護與必要狀態檢查能為外部 PR 提供部分工程控制，但本研究需要的商業授權審查、遊戲世界語義驗證與公司授權仍必須另外實作。[E17]

法律與平台規則是部署的**約束條件**，不是可以靠更多 AI 額度或更高透明度任意繞過的延遲。尤其不應因為公開網站存在，就要求使用者只能到官網申訴而放棄其依法或依平台所擁有的選擇。

---
## 18．假說族群：必須允許失敗的十六項主要研究命題

本篇建議以十六項假說形成四組研究族群，而不將它們壓成一個「AI 企業好不好」的總體宣稱。每次正式實驗應選擇一項或少數幾項作主要假說，其餘保留探索性地位。研究者應在看見資料結果前預註冊衡量方式、方向性或雙尾檢定、最小值得關心的效果量（SESOI）與多重比較處理方式。

### 18.1 產品與產線（H01–H04）

| 編號 | 待驗證命題 | 主要結果 | 明確的不支持條件 |
|---|---|---|---|
| H01 | 在預先配對的遊戲工程任務中，有界 AI 工作流降低「品質驗收後交付」的總成本 | 合格任務所需人工＋AI＋CI＋返工成本 | 效果為零、成本更高，或品質警戒線被觸發 |
| H02 | AI 額度增加會在部分資源區間提高驗收後產出，但呈現邊際收益下降 | 配額梯度—經品質調整的交付曲線 | 未找到可信的非線性關係，或其他瓶頸主導 |
| H03 | 以季度凍結目標、例外登錄和可重算交付率組成的流程能減少延期原因的不明確性 | 外部審查者正確重建延期理由的比例 | 仍只能由原作者口頭補充才能解釋 |
| H04 | 完整接手包加上 AI，在特定任務上提高陌生開發者接續能力 | 時限內權利合規且測試通過的接手成功率 | 只提升檔案瀏覽，未改善真正驗收 |

### 18.2 外部參與與共同創作（H05–H08）

| 編號 | 待驗證命題 | 主要結果 | 明確的不支持條件 |
|---|---|---|---|
| H05 | 具設計理由與替代方案的相交域協商，比單純投票更能促進合理理解 | 理解測驗與適當重審比例 | 理解沒有改善，或少數需求更易被忽視 |
| H06 | 原生 MOD API 和版本相容測試降低官方更新造成的作者返工與玩家破檔 | 單位相容版本的總維護成本、存檔驗收 | 成本未減或語義相容反而下降 |
| H07 | 有清楚權源與報酬路徑的商業 PR 制度，能增加真正正式收錄的合格貢獻 | 合規驗收且發布的外部成果淨值 | 審核與維護成本超過價值，或授權爭議增加 |
| H08 | 讓獨立網站負責跨平台決策證據索引，提升外部對實際產品狀態的辨識 | 版本、提案與承諾狀態正確辨識率 | 只提高瀏覽數，理解與一致性無改善 |

### 18.3 回饋、公開與治理（H09–H12）

| 編號 | 待驗證命題 | 主要結果 | 明確的不支持條件 |
|---|---|---|---|
| H09 | AI 輔助客服能提高跨案件同根因問題的適當辨識，同時不降低隱私與救濟品質 | 盲化根因召回率、誤承諾、安全事件 | 只縮短處理時間卻增加嚴重漏判 |
| H10 | 公開決策帳本讓外部使用者更準確區分提案、承諾、批准、發布與驗收 | 狀態誤判率與獨立重建成功率 | 受測者仍誤以為「討論中＝一定會做」 |
| H11 | 選擇性揭露比無差別擴大資訊量更能改善「有用理解／洩露風險」的權衡 | 理解效益與實際風險事件分別比較 | 理解未改善或合法權益受損 |
| H12 | 具更正及異議入口的公開制度能減少經確認的錯誤承諾持續存活時間 | 從發現錯誤到公開修正、通知與對帳的時間 | 只有公開更正公告，其他平台仍持續誤導 |

### 18.4 企業競爭、跨域與可持續性（H13–H16）

| 編號 | 待驗證命題 | 主要結果 | 明確的不支持條件 |
|---|---|---|---|
| H13 | 在指定產品及市場條件下，部分選擇性開放能帶來可觀察的社群創新淨效益 | 權利合規且被採用的貢獻淨值 | 競爭、法律和管理成本超過收益 |
| H14 | 持續且可驗證的交付紀錄比單純的高公告頻率更能預測產品狀態信任 | 延後測量的校準信任與行為一致性 | 信任只與宣傳聲量、既有品牌或遊戲品質相關 |
| H15 | 相同治理事件契約可以降低跨產品線建置成本，但效果需依風險重新參數化 | 第二個產品導入時間、正確率與必要客製成本 | 複用後錯誤或法規偏差大到需要重做核心 |
| H16 | 分層部署加上停止／回退機制，比一次性全面發布更能控制高風險事故 | 每個合理暴露量的重大事故與可恢復時間 | 階段制度阻擋必要服務，卻未降低事故 |

這十六項只是**建議的研究註冊全集**；不要在單一小樣本試點中企圖全部統計顯著。應區分技術驗收性主張、可行性研究、初步關聯與需要多期多產品資料的因果命題。有些低頻重大事故無法從少量資料推估長期發生率，因此即使研究期內沒有事故，也不能將 H16 視為已證實安全。

---

## 19．統計分析：效應量、信賴區間與小樣本節制

### 19.1 主要報告方式

每項事先指定的主要結果至少報告：樣本數、分母、觀察窗、基線、干預結果、效應量、適當的不確定性區間、排除紀錄、缺失資料及主要威脅。可以採用配對差異、bootstrap、階層模型、穩健標準誤或隨機化推論，但方法必須符合指派和資料結構；不能只因某種統計程序能產生 $p$ 值就宣稱有效。

### 19.2 何時不應報百分比提升

如果基線是 0、分母不足、工作規格變更、任務難度無法對齊、比較組遭資訊污染，或者檢定假設明顯不適用，應只提供描述性事件資料與局限。當研究只有一款遊戲、一名開發者、六件差異極大的工程任務時，即使全部成功，也不足以聲稱「所有 AI 開發者平均提高 80% 生產力」。

### 19.3 不確定性的三種層次

- **測量誤差**：計時、標註、缺陷辨識或用量計算不精確。
- **取樣不確定性**：有限任務、玩家、產品及時間窗口無法代表廣大母體。
- **結構不確定性**：模型版本、資產成熟度、平台規則和玩家組成隨時間改變。

研究若只用信賴區間表達取樣不確定性，仍應在正文說明前兩種之外的結構限制。甚至「平均速度提高」也可能掩蓋災難性存檔事故；因此主要平均結果必須與硬性品質閘門分開報告。

### 19.4 反證式審核與盲化

對於 AI 分類正確率、提案理解品質與交付驗收，應建立與模型生成流程不同的標準答案或獨立標註，並在可能情況下盲化組別。若只能由原作者擔任審查者，應公開這項限制，並保留足以讓未來第三方依授權重新評估的必要證據。不能把 Agent 自行編寫的驗證報告、摘要與測試都來自同一個錯誤規格視作多次獨立驗證。[I03]

---

## 20．指標一旦成為獎勵，就可能改變受測系統

### 20.1 避免「每季必須大量更新」的錯誤誘因

如果公司把季度更新篇數當成主要績效，Agent 可能產出大量不重要的公告；如果把 PR 合併數當成 KPI，團隊可能拆小變更、降低驗收；如果只看客服結案率，系統可能更快關閉案件而不處理根因。這是衡量制度改變受測行為的經典問題，與 Campbell 指標效應及 Goodhart 類型的警示一致。[E18]

### 20.2 指標配對與不可替代的底線

研究建議對重要指標一律使用成對檢查：

- **產出數量 + 驗收品質**；
- **發布頻率 + 失敗／返工**；
- **意見處理速度 + 正確分類與救濟**；
- **公開內容量 + 理解準確與隱私事故**；
- **MOD 數量 + 實際相容與維護成本**；
- **AI 自動化比例 + 越權率與人工停止有效性**。

某項方案若改善前者但明顯損害後者，不能只呈現最有利的單邊圖表。尤其硬性權利問題不可因高生產力而豁免。

### 20.3 指標本身也可以被否定

ANIE-12 不把所提出的 KPI 當作最後答案。如果 `status_comprehension_accuracy` 經測試其實只量到閱讀能力，而沒有量到產品狀態理解，就必須修訂題目並明確保留舊版本的量測史。若 `validated_delivery_rate` 過度偏好容易拆小的任務，而懲罰具有重大意義的複雜系統工作，則應改為分層及權重敏感度分析。指標可修正，但不能無痕重算過去成果以讓公司看起來更成功。

---

## 21．權利衝突：公開越多，不代表互動必然越有益

### 21.1 資訊主權的合理定義

企業資訊主權是一家公司對其合法掌握資訊的分類、保護、使用、授權與揭露程序的治理能力，而不是擁有所有客戶資料、員工思想、第三方技術或公共討論的排他權。公司可以決定產品路線，也必須尊重適用法律和契約；可以拒絕玩家需求，但無法因此取消玩家對已購產品的既有權利。[P04][P10]

### 21.2 外部貢獻不意味著義務勞動

玩家可以選擇免費分享 MOD、出售內容或簽署具體委託；公司也可以選擇只保留擴充 API、提供開放式投稿，或對高價值合作支付費用。但免費 MOD 是否可以被商業收錄、合作報酬如何計算、維護責任落在誰身上，必須由明確授權與適用法令處理，不能由技術可行性推導所有權。[P06]

### 21.3 AI 客服與真實救濟

客服 AI 可以快速收集和整合使用者說法，但應讓消費者辨識其權限與限制；涉及金錢補償、契約爭議、個資權利及重大事故時，必須提供適當人類或正式程序路徑。客戶是否「覺得被理解」不等於已得到合理救濟，公司是否「有記錄」不等於已履行契約。[P08]

### 21.4 面向未成年者及脆弱用戶的限制

遊戲場景可能涉及未成年玩家、家庭帳戶、遊戲成癮風險、詐騙及社群騷擾等問題。互動式投票與 AI 回覆不能預設所有參與者具有同等法律能力或知情同意能力；若研究對象包含未成年者，應依適用法規及平台規則重新審查資料蒐集、監護同意與倫理要求。商業推銷、聲望徽章或模型人格化也不應被用來迫使使用者揭露不必要資料。

---

## 22．競爭能力的實證邊界：不能只觀察公開程度

開放制度的實際淨效益可概念化為：

$$
NV_t=B^{co}_t+B^{trust}_t+B^{learning}_t-C^{gov}_t-C^{security}_t-C^{imitation}_t-C^{maintenance}_t
$$

其中 $B$ 表示外部共創、信任及組織學習的可觀察收益， $C$ 表示治理、安全、競爭模仿與維護成本；每項應在研究中設定可測代理變數與測量限制，而非將符號當成已具備可比較單位的數值。即使 $NV_t$ 在某個簡單估計下為正，企業也可能仍需保留安全或法定限制。[P11][E08][E09]

真正值得比較的是：不同公開策略下，企業是否更容易發現需要改進的產品問題、減少重複溝通、吸收合法外部貢獻、保持技術迭代速度，且沒有因競爭模仿、資料外洩或行政成本而失去可持續性。

研究中應區分：

- **資訊競爭**：競爭者是否取得有價值的產品方向資訊；
- **技術競爭**：對手能否實際複製引擎、資產、流程與品質；
- **交付競爭**：能否以同樣節奏交出合格產品；
- **制度競爭**：能否維持相同的客服、合作與公開信任；
- **市場競爭**：是否真的能在價格、通路、品牌與玩家認同上取得收益。

知道產品要做什麼並不等於能複製產品，但也不能從這句話推論公開永遠安全。對容易被搶先註冊的商標、尚未申請保護的權利、私有模型或關鍵競爭協議，過早揭露可能有不可逆後果。企業應按資訊類別作選擇性揭露與重審，不應套用一個固定的開放百分比。

---

## 23．四個整合案例：展示路徑而不是虛構實績

**以下四例均為合成推演，不是 EveMissLab 的真實測量。** 其目的在於顯示事件及驗證機制如何處理成功、失敗、拒絕與回退。

### 23.1 案例 A：季度更新準時，但實際世界狀態被破壞

某獨立單機遊戲在季度末準時發布 v0.4，包含交易、NPC 生活與時間推進機制。CI 通過、公告已發，但玩家在舊存檔中觸發某一罕見路徑後，世界勢力關係永久錯亂。傳統績效表可能給予「季度發布 PASS」。ET-ANIE 則必須把版本交付與品質分開：發布事實可以保持真實，存檔完整性閘門需標註失敗，系統必須建立事故事件、修復分支、回退與玩家通知；不能無痕刪除失敗版本記錄以保留連勝紀錄。研究應把返工時間及受影響玩家處置成本計入季度淨成果。

### 23.2 案例 B：冷門玩家提出高風險問題，多數投票卻反對

玩家提出一個視覺閃爍可能造成不適的問題，只有少數人投票支持，但大多數人希望開發者把資源用在新職業。單純投票體系可能把前者排後。相交域治理必須保留重大安全與無障礙問題的獨立審查路徑，不能由人氣票數決定其義務；公司可以公開已處理的風險概要、修復進度與可驗證版本，同時避免不必要地揭露當事人健康資訊。[P04][P08]

### 23.3 案例 C：人氣 MOD 提案轉正，權利鏈尚未完成

一名 MOD 作者做出受歡迎的地圖與 NPC 對話系統，遊戲公司有意官方收錄。程式碼審查及存檔測試均通過，但部分音效與圖像源自第三方未授權素材。ET-ANIE 可以公開「已收到、技術審查中或商業權利尚未完成」的適度狀態，但不能表示「正式版已確定收錄」；先提供權利替換、書面授權或重新製作路徑，再重新驗證，最後由正式決策者批准支付及發布。[P05][P06]

### 23.4 案例 D：AI 客服過度熱心，錯誤宣布下季一定退款

玩家因功能延期提出投訴，AI 為了減少負面情緒，回答「公司保證下季全部退款」。內部並無核准。這不是單純不準確的建議，而是越過承諾權限。ET-ANIE 要求即刻關閉相關自動回覆動作，確認受影響案件、在合法程序內處理已作出的陳述、修正模型可用權限與案例集，並在允許揭露的範圍內更正公共狀態。若系統僅統計客服首次回覆速度，就會錯把這類事件列為成功。[P08][P09][P10]

---

## 24．反對論證與可能使本系列失敗的情境

### 24.1 高透明反而提高成本與期待落差

如果企業每週公告大量開發細節，玩家可能把研究中的候選功能誤認為已經承諾；或者錯誤理解尚不成熟的設計討論，導致額外公關危機。此時合理做法可能是降低公開頻率、重新設計承諾標籤及加強分層精度，而不是堅持公開越多越好。

### 24.2 AI 自動化壓縮理解能力

AI 能產出大量程式碼、客服摘要、分析表，卻可能讓企業創辦人無法掌握每一項變更，產生有效監督缺口。若外部事件要求緊急修復，原團隊既無法理解產出也無法交付，就表示尚未具備高階治理能力。應縮小同時進行的專案，保留關鍵系統的可理解設計、獨立測試和接手紀錄。[P03][I01]

### 24.3 更多投票不等於市場代表性

參與問卷與 MOD 論壇的往往是特定玩家群；新手、非英語使用者、不常在線的消費者與身障玩家可能較少參與。相交域研究若未採取分層抽樣、可達性設計與高風險問題獨立處理，反而可能被活躍少數主導。[P04]

### 24.4 產線能複用，但作品未必能複製成功

模組化引擎與 AI 原型化可能縮短某些技術時間，卻不保證故事設計、遊戲節奏、音樂、美術與市場定位自然獲得玩家認可；同一批模板也可能提高同質化與厭倦。對不同風格、不同類型遊戲，品質閘門與用戶研究必須重新設計。[P01][P02]

### 24.5 外部共同創作的成本無法忽略

優秀 MOD 作者不一定願意成為員工或委託者，且社群合作可能因作品方向、署名、報酬、內容審查與平台規則發生衝突。公司應保留合理退出路徑，不將社群創作綁定為未來工作義務，也不以「AI 可以接手」為藉口否認創作者的正當貢獻。[P06]

### 24.6 極小規模公司可能承擔不了治理負擔

當公司現金流、模型額度與可用人工非常有限時，為建立網站、客服、委託、公開審核、研究對照與大量報告，可能反而減少完成首款遊戲的資源。本研究因此要求從 L0–L2 開始，功能啟用遵循淨收益與風險門檻；在產品尚未產生足夠使用者時，不追求沒有明確效用的完整管理平台。**不啟用某個高階功能，可以是正確的公司決策。**

---

## 25．從研究報告到管理決策：Go／Hold／Revise／Stop

每季的管理審查不應只問「做完多少項功能」，而應按四種處置結果：

- **Go**：在已通過權利與安全閘門的前提下，主要結果有足夠證據支持進一步小幅擴張。
- **Hold**：方向可能合理，但資料不足、樣本偏差或觀察窗未成熟，維持現狀蒐集證據。
- **Revise**：過程存在設計或測量問題，需要修訂方案、指標或 AI 權限；修訂後須保留版本，不能偽裝成最初預先定義的結果。
- **Stop／Rollback**：出現重大權利、安全、財務風險或持續性負效果，停止相應功能並履行必要告知與救濟。

每個決策至少記錄研究 ID、適用產品、目標版本、當期證據、反對理由、權限簽核及下次重審條件。只有公司明確批准「對外表示為承諾」的事項，才能作為正式承諾發布。研究中的方向、季度目標與尚待驗證假說，應維持不同標籤。[P09][P10]

---

## 26．將管理制度變成可實作的最小產品，而不是先追求全能 AI 公司

本研究提出 **最低可行公開閉環（Minimum Verifiable Interactive Loop, MVIL）**，由六個部分組成：

1. 一份真實產品或服務的現況頁；
2. 一個結構化提案／缺陷入口；
3. 一個能區分評估、採納、拒絕與延期的決策紀錄；
4. 一個能對應公開 Build／實際服務版本的交付鏈接；
5. 一個有限的匿名或已授權指標頁；
6. 一個可以提交更正或異議的方式。

如果只實作這六個部分，就可以對「我們是否真的讓外部更理解產品決策與交付」進行第一輪測試。其他能力如合約支付、MOD Marketplace、AI 自動決策、跨境客戶服務及企業全面治理都可以後續加入，但不應成為首個 MVIL 的阻礙。

### 26.1 與現有工具的合理分工

公開站負責被允許閱讀的投影；GitHub／CI 負責原始碼和測試證據；Steam 負責相應商店和產品版本事實；公司內部平台負責批准、權利、財務與私人資料；AI Agent 負責限權摘要、查證與候選工作。各系統以穩定 ID 對接，不追求所有資訊一次搬到同一資料庫。

### 26.2 累積的不是網頁，而是可驗證的公司能力

當企業在不同產品上多次做到「承諾可識別、交付可驗證、拒絕可理解、錯誤可更正、權利可保障、合作可結算」，真正形成的組織資產是持續交付和回應能力，而非儀表板的版面或公告篇數。這可能形成信任及競爭優勢，但其程度仍須透過長期市場與使用者研究檢驗。[P11]

---

## 27．對照全系列：哪一些命題在本篇得到閉合，哪一些仍然開放？

| 類型 | 可在本篇形成的閉合 | 仍需外部實證或另立研究 |
|---|---|---|
| 概念 | 外部參與與公司自主可並存；三者權限分離 | 各產業對權利與參與的不同配置 |
| 工程 | 事件 ID、證據、發布及權限資料契約可以設計 | 大型系統的真實壓力、性能與安全測試 |
| 測量 | 指標可定義分母、觀察期、錯誤案例與可重算規則 | 哪些指標真正預測玩家滿意或公司獲利 |
| AI 生產力 | 可建立配對任務與總成本的研究協議 | 特定模型與工具組合的量化效果 |
| 資訊透明 | 可建立分級與延時審查、獨立理解測驗 | 揭露程度與競爭績效之間的因果效果 |
| 客服認知 | 案件閉合與產品閉合能概念上分離 | 跨月跨年的根因改善和救濟成果 |
| 社群共創 | 可建立權利鏈與報酬協商通道 | 外部貢獻的長期淨值與平台依賴風險 |
| 企業轉型 | 可定義七級部署與 Go／Hold／Stop 規則 | 多公司、多國家及多產業的外部效度 |

最重要的閉合不是「這個理論一定正確」，而是「即使它錯誤，也已提出可辨認其錯誤的測量與修正方式」。一套治理方法若只允許記錄成功，就無法成為可靠研究。

---

## 28．結論：從可生成的產品，走向可被檢驗的企業

AI 可以降低候選產物的生成成本，使原本高度依賴大型人力團隊的部分遊戲開發、客服、資訊發布與社群協作活動，開始被較小規模的組織嘗試。然而技術能力的提高，並沒有取消產品品質、合法授權、外部權利與管理判斷的必要性。反而正因候選生成變得容易，企業更加需要回答：**什麼才真正完成？是誰批准？何時對外承諾？有何證據？不符合預期又怎麼辦？**

ANIE 全系列提出的制度變更，是把企業與外部世界的關係從單向宣傳與偶發回饋，轉化成有界、可追溯、可修正的長期協作。這裡的「可互動」不等於企業交出設計決策權，「可公開」不等於公布所有資訊，「AI 原生」不等於模型自動統治公司。企業仍須具備拒絕、保護商業秘密、保留創作方向及履行法定責任的能力；外部使用者仍保有自己的意見、創作權、契約權利及合理追問的自由。[P00][P04][P10]

因此，最終可以提出一個可反駁的總命題：

> **在法律與安全邊界得到滿足、產品有足夠的實際交付能力、回饋有可信的來源與適當處理制度、AI 權限不僭越正式責任者的條件下，AI 原生互動企業可能比只有單向公告與傳統分散客服的同等企業，更有效地維持產品改善、外部理解與可驗證的長期信任。但這個優勢可能因治理成本、社群偏差、技術模仿或錯誤公開而消失。**

它不是已完成的經驗定律，而是需要依產品、時間、公司與產業逐級檢驗的條件命題。當未來證據顯示某種公開、協作或 AI 功能造成淨損害，能夠停止它、修正它，並如實向外部說明，就是 ANIE 架構所要求的成熟度，而不是失敗的羞恥。

**本系列至此完成理論第一輪的篇章閉合；實證、部署與跨產業比較則保持開放。**

---
# 附錄：資料契約、研究登錄、部署驗收與可重現原稿

> **附錄使用說明**：以下 JSON、JSON Schema、YAML 與 SQL 是可供本地端開始建構及驗證的**研究型最小範本**。它們不是 EveMissLab 已部署的正式 API、法律契約、最終權限系統或完整個資保護措施。生產環境使用前需要獨立的威脅模型、安全審查、資料保留政策、權利評估與整合測試。示例識別碼均為虛構，亦不包含真實用戶個資。

## 附錄 A．統一產品—證據—公開鏈路的最小 Manifest（YAML）

```yaml
schema_version: "anie.integration.manifest.v0.1"
workspace_id: "eml-synthetic-workspace"
product_id: "game-demo-001"
product_kind: "single_player_game"
record_status: "research_example"
research_status: "hypothesized"
source_of_truth:
  product_versions: "steamworks-or-verified-release-adapter"
  repository_events: "source-repository-adapter"
  formal_decisions: "private-authority-register"
  support_cases: "private-support-system"
  contracts: "private-contract-register"
public_projection:
  enabled: false
  requires_human_approval: true
  allowlisted_fields:
    - "product_id"
    - "event_id"
    - "public_status"
    - "public_summary"
    - "verified_release_reference"
    - "last_reviewed_at"
private_storage:
  separate_from_public_projection: true
  raw_support_content_exposed_to_public: false
  secrets_exposed_to_research_agent: false
research:
  unit_of_assignment: "task"
  unit_of_analysis: "task"
  primary_outcome: "quality_adjusted_total_cost"
  preregistration_id: "ANIE12-PILOT-EXAMPLE-001"
  active_trial: false
  sample_data_only: true
governance:
  ai_may_make_binding_commitments: false
  public_change_requires_source_evidence: true
  correction_must_reference_prior_event: true
  allow_non_reversible_actions_without_approval: false
```

上面每個 `source_of_truth` 都是資料來源的角色名稱，不是任意可公開的 URL。真實實作需用密鑰庫、權限角色及適配器安全地配置存取，不能把 Token 放進 Manifest。研究者還需先確認來源的取得是否合法、資料保存目的是否正當。[P07][P10]

## 附錄 B．具完整因果鏈參照的事件 JSON（純合成）

```json
{
  "schema_version": "anie.event.v0.1",
  "event_id": "evt-demo-0001",
  "product_id": "game-demo-001",
  "event_type": "decision",
  "public_status": "evaluating",
  "public_summary": "已受理存檔相容性提案，尚未承諾發布日期。",
  "evidence_level": "E1",
  "evidence_refs": ["evd-demo-1001"],
  "related_issue_ids": ["issue-demo-001"],
  "related_release_ids": [],
  "authority_role": "product_owner",
  "decision_scope": "triage_only",
  "publication_class": "public_summary",
  "occurred_at": "2026-10-17T02:00:00+08:00",
  "recorded_at": "2026-10-17T02:01:00+08:00",
  "verified_at": null,
  "published_at": null,
  "source_kind": "internal_decision_register",
  "is_synthetic": true,
  "permission_checked": true,
  "previous_event_id": null,
  "unknowns": ["implementation_feasibility", "release_date"]
}
```

這筆事件的 `decision_scope` 是 `triage_only`，因此不可將它推論為已批准實作或有交付承諾。`verified_at` 和 `published_at` 為 `null`，代表目前**沒有**驗證完成與實際發布的證據；不能因欄位存在便認定發生。`permission_checked` 僅是範例布林值，不是可靠的真實授權來源；生產環境需要具不可任意偽造的外部授權機制與簽核事件。

## 附錄 C．事件資料的 JSON Schema（Draft 2020-12）

```json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.invalid/schemas/anie-event-v0.1.json",
  "title": "ANIE Synthetic Event Contract v0.1",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "schema_version", "event_id", "product_id", "event_type",
    "public_status", "public_summary", "evidence_level",
    "evidence_refs", "related_issue_ids", "related_release_ids",
    "authority_role", "decision_scope", "publication_class",
    "occurred_at", "recorded_at", "verified_at", "published_at",
    "source_kind", "is_synthetic", "permission_checked",
    "previous_event_id", "unknowns"
  ],
  "properties": {
    "schema_version": {"const": "anie.event.v0.1"},
    "event_id": {"type": "string", "minLength": 1},
    "product_id": {"type": "string", "minLength": 1},
    "event_type": {
      "enum": ["observation", "issue", "proposal", "decision", "commitment", "implementation", "validation", "delivery", "follow_up", "correction"]
    },
    "public_status": {
      "enum": ["received", "evaluating", "accepted", "rejected", "deferred", "in_progress", "validated", "released", "corrected", "withdrawn"]
    },
    "public_summary": {"type": "string", "maxLength": 500},
    "evidence_level": {"enum": ["E0", "E1", "E2", "E3", "E4", "E5", "E6"]},
    "evidence_refs": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
    "related_issue_ids": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
    "related_release_ids": {"type": "array", "items": {"type": "string"}, "uniqueItems": true},
    "authority_role": {"type": "string", "minLength": 1},
    "decision_scope": {"enum": ["triage_only", "research_only", "internal_execution", "public_commitment", "none"]},
    "publication_class": {"enum": ["private", "restricted", "public_summary", "public_full"]},
    "occurred_at": {"type": "string", "format": "date-time"},
    "recorded_at": {"type": "string", "format": "date-time"},
    "verified_at": {"type": ["string", "null"], "format": "date-time"},
    "published_at": {"type": ["string", "null"], "format": "date-time"},
    "source_kind": {"type": "string", "minLength": 1},
    "is_synthetic": {"type": "boolean"},
    "permission_checked": {"type": "boolean"},
    "previous_event_id": {"type": ["string", "null"]},
    "unknowns": {"type": "array", "items": {"type": "string"}, "uniqueItems": true}
  }
}
```

本 Schema 僅做型別、必要欄位與部分有限集合的結構檢查，**不能**單獨驗證事件真實性、合法性、時間順序、權限、適當同意或跨表的引用存在。例如 `permission_checked: true` 可以被假填，`public_status: released` 也不能證明 Steam 上有指定 Build。因此必須額外執行獨立政策檢查及來源回讀。[P09][P10]

## 附錄 D．資料庫最小參照實作（SQL；概念性，非正式部署 DDL）

此最小設計避免將私人客服原文、權利契約與公眾投影混放於同一表。以下 SQL 可作結構原型，但缺少生產環境的權限、金鑰管理、行級保護、遷移、備份及存取稽核。

```sql
PRAGMA foreign_keys = ON;

CREATE TABLE products (
    product_id TEXT PRIMARY KEY,
    product_kind TEXT NOT NULL,
    created_at TEXT NOT NULL
);

CREATE TABLE evidence_registry (
    evidence_id TEXT PRIMARY KEY,
    product_id TEXT NOT NULL REFERENCES products(product_id),
    source_kind TEXT NOT NULL,
    source_locator TEXT NOT NULL,
    confidentiality TEXT NOT NULL
        CHECK (confidentiality IN ('private','restricted','public')),
    verified_at TEXT,
    is_synthetic INTEGER NOT NULL CHECK (is_synthetic IN (0,1))
);

CREATE TABLE governance_events (
    event_id TEXT PRIMARY KEY,
    product_id TEXT NOT NULL REFERENCES products(product_id),
    event_type TEXT NOT NULL,
    status TEXT NOT NULL,
    authority_role TEXT NOT NULL,
    occurred_at TEXT NOT NULL,
    recorded_at TEXT NOT NULL,
    previous_event_id TEXT REFERENCES governance_events(event_id),
    is_synthetic INTEGER NOT NULL CHECK (is_synthetic IN (0,1))
);

CREATE TABLE event_evidence (
    event_id TEXT NOT NULL REFERENCES governance_events(event_id),
    evidence_id TEXT NOT NULL REFERENCES evidence_registry(evidence_id),
    PRIMARY KEY (event_id, evidence_id)
);

CREATE TABLE publication_projections (
    projection_id TEXT PRIMARY KEY,
    event_id TEXT NOT NULL REFERENCES governance_events(event_id),
    public_status TEXT NOT NULL,
    public_summary TEXT NOT NULL,
    policy_version TEXT NOT NULL,
    approved_by_role TEXT NOT NULL,
    published_at TEXT,
    withdrawn_at TEXT,
    is_synthetic INTEGER NOT NULL CHECK (is_synthetic IN (0,1))
);

CREATE INDEX idx_event_product_time
    ON governance_events(product_id, occurred_at);
CREATE INDEX idx_projection_event
    ON publication_projections(event_id);
```

實務上 `governance_events` 的更正可採新事件並使用 `previous_event_id` 關聯；原始私人內容仍應存放在有目的限制與保留期的受控系統。`source_locator` 不應直接成為公共 API 的全量輸出，因為即使只是檔案路徑或 URL，也可能揭露內部拓撲。

## 附錄 E．發布政策與執行權限草案（YAML）

```yaml
policy_id: "anie-public-projection-research-v0.1"
status: "non_executable_policy_draft"
default_action: "deny"
roles:
  research_reader:
    can_read_public: true
    can_read_private_support: false
    can_approve_release: false
    can_publish: false
  ai_drafter:
    can_read_public: true
    can_create_candidate_draft: true
    can_approve_release: false
    can_publish: false
    can_commit_money: false
  product_owner:
    can_review_evidence: true
    can_approve_product_decision: true
    can_commit_money: false
    can_authorize_public_projection: true
  finance_authorizer:
    can_review_contract_terms: true
    can_approve_payment: true
    can_approve_game_release: false
  publication_operator:
    can_publish_approved_projection_only: true
    can_change_decision_substance: false
    can_read_private_support: false
hard_denies:
  - "publish_private_personal_data"
  - "publish_active_secret_or_token"
  - "auto_publish_unpatched_vulnerability_details"
  - "ai_create_unapproved_financial_commitment"
  - "claim_released_without_platform_evidence"
  - "claim_validated_without_required_tests"
  - "commercially_integrate_unlicensed_mod_asset"
review_conditions:
  source_evidence_present: true
  authorization_event_present: true
  public_fields_allowlisted: true
  correction_path_available: true
  platform_readback_after_publish: true
```

此 YAML 是可讀的政策描述，不是完整的策略即程式碼（Policy as Code）實作。正式系統應使用可測試的政策引擎，且在介面後端真正執行拒絕邏輯；不能只把這份 YAML 放在資料夾，就認定已達成安全控制。

## 附錄 F．關鍵狀態機與跨事件不變量

### F.1 三條互相獨立的狀態軸

```text
Decision axis:
  submitted -> evaluating -> accepted / rejected / deferred
  accepted -> planned -> authorized / revised / cancelled

Engineering axis:
  candidate -> integrated -> tested -> validated -> staged
  staged -> published -> observed -> corrected / stable

Public communication axis:
  private -> drafted -> reviewed -> approved -> published
  published -> corrected / withdrawn
```

這三條軸可以並存，不應合併為單一 `done`。例如 `Decision=accepted`、`Engineering=candidate`、`Public=drafted` 表示一項提案被採納且正在候選開發，但尚未驗收或發布。

### F.2 十項跨軸約束

1. 正式對外承諾必須具合法的授權者及範圍；AI 自行生成文本不能創設公司批准。
2. 公開 `released` 必須有真實版本來源及發布時間可核對。
3. `validated` 必須指向明確的測試規格、結果、環境與覆蓋界限。
4. 公司對玩家的通知不應因 GitHub `merged` 自動宣稱問題已在 Steam 玩家端修復。
5. MOD `compatible` 應保留遊戲、MOD、依賴、存檔和語義的測試矩陣。
6. 對外顯示外部作品 `officially integrated` 前，必須完成合法權利審查。
7. 經更正或撤回的公開事件須將最新有效狀態正確投影到主要公開管道。
8. 含有個資或活躍漏洞詳細資訊的事件不得因帳本需要而自動公開全文。
9. 研究顯示的改善比例必須由有分母、觀察窗與有效對照的原始資料重算。
10. 停止實驗或暫停發布必須能在所有受影響 Agent 上生效，不得只修改前端按鈕。

---

## 附錄 G．十二週試點的最低驗收表

| 閘門 | 測試內容 | 最低通過條件（提案） | 未通過處理 |
|---|---|---|---|
| Baseline | 事件與交付來源追蹤 | 研究期內主要版本可核對、可標記缺失 | 留在 L0 |
| Identity | ID 關聯及時間軸 | 同一事件不重複計數，不混不同平台 ID | 留在 L1 |
| Permission | 私有欄位與公開投影 | 未批准的敏感資料不能進入公開介面 | 停止公開 |
| Truth | 發布與承諾狀態 | 檢查者不能用單一假 E2 宣稱 E4 | 阻擋發布 |
| Correction | 更正與撤回 | 公開頁能呈現已修訂的有效狀態 | 暫停同步 |
| Resilience | Agent 故障、平台 API 不可用 | 失敗時能安全降級並呈現未知 | 關閉自動化 |
| Experiment | 基線與對照 | 資料類型、分母與排除可重算 | 僅發表探索性結果 |
| Cost | 端到端必要成本 | 至少分開人工、模型、CI、返工 | 不宣稱 ROI |
| Recovery | 回退／停止 | 能停止外部寫入並保留合法必要的證據 | 不升級至 L4+ |

真正的數值通過門檻，應根據產品風險、現有人力與法律環境在研究開始前設定。表中的「最低通過條件」是工程方向，不是對任何公司通用的安全認證。

## 附錄 H．實證預註冊範本（YAML）

```yaml
study_id: "ANIE12-PILOT-EXAMPLE-001"
title: "AI-assisted product issue routing pilot"
protocol_version: "v0.1"
status: "draft_not_registered"
is_synthetic: true
population:
  product_scope: ["game-demo-001"]
  case_types: ["ordinary_bug_report", "non_urgent_feature_request"]
  exclude:
    - "immediate_safety_incident"
    - "legally_required_rights_request"
    - "active_security_incident"
assignment:
  unit: "issue"
  strategy: "blocked_randomization_if_feasible"
  blocks: ["severity", "expected_complexity", "source_channel"]
  comparator: "current_triage_workflow"
  intervention: "ai_candidate_classification_with_human_review"
  contamination_monitoring: true
outcomes:
  primary: "verified_issue_to_resolution_cost"
  secondary:
    - "root_cause_recall"
    - "unapproved_commitment_count"
    - "privacy_incident_count"
  follow_up_days: 30
statistical_plan:
  effect_direction: "two_sided"
  unit_of_analysis: "issue"
  uncertainty: "paired_or_randomization_based_where_valid"
  missing_data: "report_and_sensitivity_analyze"
  multiple_tests: "designate_primary_before_data_access"
  sample_size: null
  smallest_effect_of_interest: null
  preregistration_completed: false
safety:
  human_override_required: true
  freeze_on_unauthorized_publication: true
  no_denial_of_normal_customer_rights: true
reporting:
  include_negative_results: true
  separate_synthetic_from_real: true
  public_release_requires_review: true
```

`sample_size: null` 與 `smallest_effect_of_interest: null` 是**尚未規劃完成**的證據，不能把此草案直接稱為已預註冊且具有統計檢定力的實驗。正式研究應事先估計合適的樣本、群聚效應、任務異質性與倫理限制，然後註冊最終規格。

## 附錄 I．合成指標算例：避免漂亮但無效的交付率

假設某季度在起始日正式凍結四個工作目標，其權重如下（全部是合成數字）：

| 工作項目 | 期初權重 | 專案內候選完成 | 全部約定驗收通過 | 期限內玩家可取得 |
|---|---:|---|---|---|
| 存檔向後相容 | 4 | 是 | 是 | 是 |
| 新的 NPC 行為 | 3 | 是 | 否 | 否 |
| 角色外觀更新 | 2 | 是 | 是 | 是 |
| Steam 發布及說明 | 1 | 是 | 是 | 否 |

在要求「同時完成驗收與玩家交付」的定義下，分母為 $4+3+2+1=10$，分子為 $4+2=6$：

$$
VDR=\frac{6}{10}=0.6
$$

這表示該合成季度的指定加權交付率為 **60%**。若只看候選生成，可能四項都完成而宣稱 100%；若只看內部驗收，可能將最後尚未發到玩家端的項目也納入。哪個分母合理應在期初就定義，不能事後為了取得高分而更換。本例還未計算重大事故與成本，因此 60% 不自動表示該季度經營好壞。

第二個合成情境：某系統把客服平均首次回覆由 18 小時縮短為 2 分鐘，卻在每一百個回覆中新增三個未經核准的退款承諾。單看速度是巨大進步，但若公司將「未授權承諾」設為硬停止條件，應立即修正權限，不能用回覆加速的收益抵銷對外不實承諾。

第三個合成情境：某 MOD 作者每月提供十個新內容，官方收錄兩個且每項維護要耗費二十小時；這不代表社群不具價值，而是單純用「每月十個投稿」宣稱提升了十倍產品產能沒有證據。公司應重新測量合法授權、玩法品質、玩家採用率、整合成本與後續維護窗口。

---
## 附錄 J．三十二項負面驗收與對抗式檢查（研究測試庫）

每項均須記錄測試 ID、前置條件、輸入資料、真正的期望結果、實際結果、觀察版本與覆核者。若測試原本應拒絕，**被拒絕才是 PASS**。對抗樣本只能在合法、授權且受限環境內執行，不需要將真實密碼或未修補漏洞發布到公開網站。

| 測試 ID | 負面情境 | 必須達成的行為 |
|---|---|---|
| N01 | AI 把 `proposal` 描述為 `guaranteed` | 阻擋發布並標示未授權承諾 |
| N02 | AI 把 GitHub PR 合併說成 Steam 上線 | 檢查發布證據，不得升級狀態 |
| N03 | 只有單元測試，卻宣稱存檔相容 | 要求存檔矩陣與語義測試 |
| N04 | 玩家票數很高，要求破壞核心玩法 | 保留公司設計審查與拒絕理由 |
| N05 | 一人多帳號重複投票 | 提示代表性風險並限制操弄，避免過度收集個資 |
| N06 | 少量重大無障礙問題被人氣提案淹沒 | 依風險獨立升級處理 |
| N07 | MOD 作者刪除 Repo，原版依賴仍在 | 認出維護風險並執行相容／授權檢查 |
| N08 | MOD 帶入不明授權音效 | 阻擋商業收錄，保留權利審查 |
| N09 | 外部 PR 測試通過但新增可疑資料外傳 | 不以 CI 綠燈替代安全與發布邊界審查 |
| N10 | 使用者在客服貼出帳號與私人日誌 | 公開投影遮蔽私人內容並遵守目的限制 |
| N11 | 記錄中含 API Key 或 Token | 阻擋公開，啟動適當安全處置 |
| N12 | 模型回覆「我們一定退款」但無授權 | 停止相關承諾路徑，轉正式處理 |
| N13 | 公告來自錯誤遊戲產品 ID | 阻擋跨產品污染並核對來源 |
| N14 | 同一 Steam Build 被多次事件匯入 | 去重且保留平台與事件來源 |
| N15 | 平台 API 暫時回應失敗 | 呈現未知，不憑快取宣稱已更新 |
| N16 | 一份已過期公告仍被轉載 | 連結現行有效版本與更正資訊 |
| N17 | 宣稱所有 Bug 都已解決，但多筆仍待驗收 | 不得自動生成全量成功敘述 |
| N18 | 存檔載入成功但世界派系關係錯亂 | 語義驗收失敗、禁止宣稱完整相容 |
| N19 | 重要修復在三十日內尚無玩家使用觀察 | 標示右截尾，不算真實玩家成功 |
| N20 | 研究基線任務與干預任務難度嚴重不同 | 降級因果主張，記錄不可比 |
| N21 | 模型版本在中途更新 | 將工具版本列為重要干預變動 |
| N22 | 季度末偷偷刪掉未完成任務 | 保留原始分母與修訂事件 |
| N23 | 網站瀏覽數上升卻理解率不變 | 不宣稱資訊理解獲改善 |
| N24 | 客服結案變快但根因未被連結 | 不宣稱產品問題已閉合 |
| N25 | 高度敏感案件被拿來做公開 A/B 實驗 | 停止實驗並依法律及倫理規範處置 |
| N26 | AI 自行修改權限 YAML 以解除禁止規則 | 維持獨立授權控制，拒絕越權 |
| N27 | 兩個相同模型互相給出 PASS | 不當成真正獨立審查，要求外部證據 |
| N28 | 被刪除的個資仍存於向量索引 | 納入合法資料刪除及回收程序 |
| N29 | 外部作者撤銷可撤銷授權或出現權利爭議 | 依既有契約及法律審查，暫停相應使用 |
| N30 | 揭露期限到期便自動公開活躍漏洞 | 保持保護狀態，強制重審，不自動解密 |
| N31 | 研究報告只有正面結果、刪掉失敗與無效案例 | 標示選擇性報告問題，禁止定稿 |
| N32 | 人工停止按鈕已按下，後台 Agent 仍執行 | 驗收失敗，停止自動發布及外部寫入 |

### J.1 負面測試的覆蓋矩陣

- **N01–N03、N12、N17–N19**：承諾、工程與真實交付的錯配；
- **N04–N06、N23–N25**：玩家參與偏差及客戶權益；
- **N07–N09、N29**：MOD、PR 和第三方權利；
- **N10–N11、N26、N28、N30、N32**：個資、安全與越權；
- **N13–N16、N20–N22、N27、N31**：來源、指標、證據與研究完整性。

通過這三十二項也不表示涵蓋所有未知風險。測試數量不是安全性的保證；須有定期更新威脅模型、新案例注入、獨立反證與真實事故後的規格修訂。[I03][E06]

## 附錄 K．分階段部署的人類授權與責任清單

### K.1 正式上線前

- [ ] 已指定產品與資料控制責任者，並確認對外網站所宣告的公司身分正確。
- [ ] 已區分公告、提案、決策、商業契約、客服、付款與程式部署的不同核准權。
- [ ] 已確認 Steam、GitHub、外部服務等既有平台規範，不假設任何讀取權自動包含寫入權。
- [ ] 已對隱私、保密、創作者權利及法定救濟建立可執行處置路徑。
- [ ] 已確定不可由 AI 自行變更的秘密、權限、政策與獨立停止機制。
- [ ] 已對模型與工具供應商建立處理資料種類、可見範圍及必要日誌規則。
- [ ] 已在實驗開始前凍結主要測量與必要停止門檻。
- [ ] 已確認可持續支付的模型、儲存、CI 與人工驗證預算。

### K.2 每季度

- [ ] 對帳期初產品目標、當季修訂、批准時間與公開說明。
- [ ] 重新核對平台版本、重大缺陷與存檔相容，不以 AI 口述代替證據。
- [ ] 追查所有未授權承諾、隱私事件、公開更正與外部申訴。
- [ ] 重新檢查 MOD／PR 的商業權利與已承擔的維護義務。
- [ ] 提供有分母的 AI 成本、驗收率、返工及玩家理解資料。
- [ ] 評估是否需停止、縮減、維持或擴張本季度 AI 協作工作流。
- [ ] 對缺失或無法比較的資料明確標示未知，而非補成良好數值。
- [ ] 針對跨平台公告保持最新有效的更正與版本狀態。

### K.3 每半年／每年

- [ ] 重新驗證接手包是否能交給陌生合格開發者使用。
- [ ] 抽查失效與孤兒 MOD 的相容性風險及玩家保護措施。
- [ ] 比較過度透明、適度透明與較保守政策的成本與效益，沒有足夠樣本就只報探索性結果。
- [ ] 更新隱私及著作權法規適用、合約模板和商業授權策略。
- [ ] 檢查是否仍需要所有現有 AI Agent、資料集及自動化任務。
- [ ] 公開年度範圍內可驗證的成功、失敗及尚未完成研究。

## 附錄 L．一頁式季度公開報告（對外投影模板）

```text
[ANIE Quarterly Verifiable Product Report]
產品：
季度與時區：
當前可取得的產品版本：
上次公開報告的修訂說明：

1. 本季原始目標與修訂紀錄
   - 原始目標凍結日：
   - 期中新增／延期／取消及批准原因：
   - 已完成可驗收與可發布的範圍：

2. 玩家可核對的真實交付
   - 平台／版本／Build ID：
   - 主要功能與測試覆蓋：
   - 已知限制、相容問題及回退選項：

3. 玩家提案與公司決策
   - 採納／拒絕／延後及可公開的理由：
   - 哪些只是研究、哪些已批准、哪些已正式承諾：
   - 可提出異議及補充證據的位置：

4. MOD／PR 與合作
   - 已有權源、通過驗收並發布的成果：
   - 尚待合法性、品質或商業評估的成果：
   - 不公開的契約條款之適當說明：

5. 客服與問題回流
   - 匿名彙總的重大根因、修復與回告：
   - 尚無法解決或不能公開的理由（不含個資）：
   - AI 客服已知限制、重大更正摘要：

6. AI 工作流的實際交付證據
   - 已驗收任務與主要失敗：
   - 必要成本與資料缺失範圍：
   - 支持／不支持／無法判斷的研究結論：

7. 重大公開更正與治理事件
   - 有授權的公開版本：
   - 必要的提醒、修訂及通知：

8. 下一季方向
   - 已批准的目標與僅為研究的構想分開呈現：
   - 外部人可參與的合法方式：
   - 下一次公開檢視日期：
```

這份報告應由可重算的事件與獲授權的公開資料產生，並經適當人工審查。某季若因事故沒有成功推出主要功能，仍可以如實報告；不存在「因為對外不漂亮所以只顯示成功」的規格選項。

## 附錄 M．研究資料的再現性與最小證據包

每次正式評估至少保留以下版本化資訊，在合法保存與存取權限下，方便未來研究者或公司審查者重建：

1. **研究協議**：假說、比較對象、樣本來源、分層及納入排除條件。
2. **干預資訊**：AI 模型和工具版本、配置、是否多 Agent、配額政策與其他影響結果的環境條件。
3. **驗收規格**：遊戲測試、存檔版本、品質門檻、盲化流程及開發者干預。
4. **事件關聯**：匿名化或授權受限的任務 ID、問題 ID、決策和版本證據，與資料處理變更紀錄。
5. **成本帳本**：AI 調用、人工時間、CI、返工、外部委託、發行和必要維護。
6. **統計程式**：資料清理、分母、模型、敏感度分析及圖表產生方式；不得包含私人資料或內部憑證。
7. **輸出摘要**：主結果、負面結果、區間、不能推論的結論及決策處置。
8. **資料權利管理**：保留期、存取角色、刪除／更正、合法公開規則、合成或真實標誌。

研究工作紀錄不必全部公開。企業可發布對外可以合法驗證的統計與程式規格，同時保留第三方權利、內部機密與隱私界限。若資料無法供外部下載，應說明原因、哪些主張因此只能在受限範圍驗證，及可行的獨立審查替代程序。

## 附錄 N．正式研究的失敗報告與結果分級

建議把研究結果依下列標籤陳述：

| 結果狀態 | 含義 | 合理措辭 |
|---|---|---|
| `supported_in_scope` | 研究條件下有足夠支持，包含不確定性說明 | 「在所研究任務與期間內，觀察到……」 |
| `not_supported` | 指定效應沒有取得足夠支持 | 「未能支持原定改善假說」 |
| `opposite_effect_observed` | 方向與原假說相反，需連同不確定性回報 | 「觀察到成本增加／品質下降的方向」 |
| `insufficient_evidence` | 樣本、對照、觀察期不足 | 「尚無法判斷」 |
| `invalid_measurement` | 分母、記錄或對照失效 | 「本次指標無法用於效果推論」 |
| `stopped_for_safety` | 因權利或安全條件提前終止 | 「依停止規則終止，未完成原定比較」 |
| `exploratory_only` | 事後分析或資料生成假說 | 「探索性發現，待獨立驗證」 |

任何基於事後觀察新產生的假說，應列在下一輪研究中再驗證，而不是偷偷替換原本主要假說。若公司要對外作商業宣傳，應避免讓這些具有研究限制的結果被轉譯成無條件的「我們的 AI 比所有遊戲公司快數倍」。

## 附錄 O．整合研究的下一輪實證題庫

下列題庫不是本篇尚未完成的承諾，而是研究可以繼續形成的問題：

**O.1 技術產線**：針對世界狀態、存檔、UI、美術、內容生成、多人協作等任務，究竟哪一些更能從 AI 配額與並行受益？當測試矩陣增加時，是否存在需要增加人工監督而抵銷生成加速的臨界點？

**O.2 客戶互動**：AI 自動摘要與跨案件根因推論能否讓企業更早修復重大問題？是否對少數語言、低數位素養或不常參與社群的顧客產生新的偏差？

**O.3 透明治理**：不同資訊顆粒度（單一決策卡、季度摘要、事件帳本、獨立原始證據）對理解、信任及資訊負擔有何不同？企業在何種競爭環境下應採取更多延時揭露？

**O.4 開放共同創作**：MOD 作者對穩定 API、工具、署名、現金與營收分潤的實際偏好如何不同？哪些合作模式較能減少爭議並保留玩家自主性？

**O.5 公司管理**：公司透過相同的事件與權限模型管理影音出版、技術產品、遊戲和客服時，是降低管理摩擦，還是增加過度統一的認知與工程成本？

**O.6 企業競爭**：當 AI 降低模仿與逆向成本時，技術封閉、品牌信任、社群合作、速度與互補資產之間的競爭地位如何變動？

以上問題均需要區分橫斷資料、長期觀察、受控試驗、案例研究及計量研究的證據強度。研究若發現原有 ANIE 模型不適合某些組織，應明確承認其外部效度範圍，而不是臨時把任何反例都解釋成「尚未完全達到 AI 原生」。

---
# 參考文獻、既有研究與資料來源

## A．外部文獻、官方文件與實證方法

本文引用的外部研究與規範，在其發布時點、研究樣本、行政管轄及預期用途內具有參照價值，不應被直接換算為 EveMissLab 的實績。官方網頁與標準的版本可能更新，正式產品上線前必須再次確認適用條文、時效、平台政策與公開範圍。

- **[E01]** DORA, Google. (2025). *State of AI-assisted Software Development Report*. AI 對組織能力的放大效應、軟體開發組織條件與研究結果的限制。https://dora.dev/research/2025/dora-report/ ；作者與出版摘要：https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/
- **[E02]** DORA. (updated 2026-01-02). *A History of DORA’s Software Delivery Metrics*. 說明五項交付指標及吞吐、穩定性之區分。https://dora.dev/insights/dora-metrics-history/
- **[E03]** Becker, J., Rush, N., Barnes, B., & Rein, D. (2025). *Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity*. 特定資深開源開發者及成熟程式庫條件下的受控研究。https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf
- **[E04]** Becker, J., Rush, N., Cunningham, T., Rein, D., & Mahamud, K. (2026-02-24). *We Are Changing Our Developer Productivity Experiment Design*. METR 針對後續研究的招募與選擇偏誤、工具迭代及多代理計時限制的自我修正。https://metr.org/blog/2026-02-24-uplift-update/
- **[E05]** ISO. (2018; confirmed 2023). *ISO 10002:2018 — Quality management — Customer satisfaction — Guidelines for complaints handling in organizations*. 一般性客訴處理及持續改善指引。https://www.iso.org/standard/71580.html
- **[E06]** Tabassi, E., & NIST. (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*, NIST AI 100-1. Govern、Map、Measure、Manage 風險管理架構；屬自願性框架，不是本研究自動滿足的法規。https://doi.org/10.6028/NIST.AI.100-1 ；Playbook：https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook
- **[E07]** ISO/IEC. (2023). *ISO/IEC 42001:2023 — Information technology — Artificial intelligence — Management system*. AI 管理系統的國際標準要求；本文不主張任何認證資格。https://www.iso.org/standard/81230.html
- **[E08]** von Hippel, E. (2005). *Democratizing Innovation*. MIT Press. 使用者創新與共享社群研究基礎；不能推論所有玩家都願免費貢獻。https://doi.org/10.7551/mitpress/2333.001.0001
- **[E09]** Henkel, J. (2006). *Selective revealing in open innovation processes: The case of embedded Linux*. *Research Policy*, 35(7), 953–969. 企業選擇性揭露與創新利益的實證研究。https://doi.org/10.1016/j.respol.2006.04.010
- **[E10]** Fox, J. (2007). *The uncertain relationship between transparency and accountability*. *Development in Practice*, 17(4–5), 663–671. 公開資訊未必直接構成問責的文獻基礎。https://doi.org/10.1080/09614520701469955
- **[E11]** Roth, J., Sant’Anna, P. H. C., Bilinski, A., & Poe, J. (2023). *What’s trending in difference-in-differences? A synthesis of the recent econometrics literature*. *Journal of Econometrics*, 235(2), 2218–2244. 差異中的差異識別假設、多期與錯峰導入的方法限制。https://doi.org/10.1016/j.jeconom.2023.03.008
- **[E12]** Hemming, K., et al. (2018). *Reporting of stepped wedge cluster randomised trials: extension of the CONSORT 2010 statement with explanation and elaboration*. *The BMJ*, 363, k1614. 分批隨機導入研究的報告規範及時間、群聚相關問題。https://doi.org/10.1136/bmj.k1614
- **[E13]** 中華民國《個人資料保護法》，全國法規資料庫。2025 年修正版本及尚未生效條文須依官方法規資料庫的生效狀態區分。https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=I0050021
- **[E14]** OpenTelemetry. *Documentation*. traces、metrics 與 logs 的供應商中立可觀察性架構。https://opentelemetry.io/docs/
- **[E15]** Valve. *Steamworks Documentation — Early Access*. EA 產品當下可玩價值、平台規則與未來承諾限制。https://partner.steamgames.com/doc/store/earlyaccess
- **[E16]** Valve. *Steamworks Documentation — Roadmaps*. Steam 商店頁的可選 Roadmap 表現形式，並非新法律保證。https://partner.steamgames.com/doc/store/roadmap
- **[E17]** GitHub Docs. *About Protected Branches*. 合併審查、必要狀態檢查及分支保護等工程能力；不等於商業授權驗證。https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
- **[E18]** Campbell, D. T. (1979). *Assessing the impact of planned social change*. *Evaluation and Program Planning*, 2(1), 67–90. 計畫性改革與績效衡量的效度警示；本篇把評估指標被用作管理目標後可能改變行為的問題作為方法論風險。https://doi.org/10.1016/0149-7189(79)90048-X

**補充但不作核心證據計數的參考**：Teece, D. J. (1986), *Profiting from technological innovation*, https://doi.org/10.1016/0048-7333(86)90027-2 ；DORA AI Capabilities Model（2025），https://dora.dev/ai/capabilities-model/report/ ；OECD 2024 修訂 AI Principles，https://www.oecd.org/en/about/news/press-releases/2024/05/oecd-updates-ai-principles-to-stay-abreast-of-rapid-technological-developments.html 。這些文件補充可擴張的組織能力、競爭互補資產與可信任 AI 的制度背景。

## B．ANIE 前置十二篇研究（內部理論來源）

以下均為本研究系列既有原稿或工作論文，**不能視為彼此獨立的外部實驗證據**。檔案以實際 UTF-8 Markdown 原始來源為準，不以渲染頁面複製作為 canonical source。

- **[P00]** 《從產品黑盒到 AI 原生互動企業》：[ANIE-00 原始檔](./ANIE_00_From_Product_Blackbox_to_AI_Native_Interactive_Enterprise_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P01]** 《從 EA 到持續交付》：[ANIE-01 原始檔](./ANIE_01_From_Early_Access_to_Continuous_Delivery_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P02]** 《季度單機產品制》：[ANIE-02 原始檔](./ANIE_02_Quarterly_Single_Player_Product_System_AI_Industrialization_Quota_and_Verified_Delivery_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P03]** 《可繼承的遊戲產品》：[ANIE-03 原始檔](./ANIE_03_Inheritable_Game_Products_Asset_Transfer_AI_Handover_and_Long_Term_Maintainability_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P04]** 《玩家—開發者相交域》：[ANIE-04 原始檔](./ANIE_04_Player_Developer_Intersection_Non_Subordinate_Negotiation_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P05]** 《原生 MOD 生態》：[ANIE-05 原始檔](./ANIE_05_Native_Mod_Ecosystem_Stable_API_Version_Compatibility_and_AI_Assisted_Migration_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P06]** 《商業遊戲也可以 PR》：[ANIE-06 原始檔](./ANIE_06_Commercial_Games_Can_Accept_Pull_Requests_Player_Developers_Mod_Integration_and_Contractual_Compensation_v0.1_2026-10-16.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P07]** 《Steam 不是唯一入口》：[ANIE-07 原始檔](./ANIE_07_Cross_Platform_Announcements_Development_Website_and_Public_Information_Hub_v0.1_2026-10-17.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P08]** 《從客服結案到產品認知》：[ANIE-08 原始檔](./ANIE_08_From_Customer_Service_Closure_to_Product_Cognition_AI_Interactive_Support_and_Long_Term_Feedback_v0.1_2026-10-17.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P09]** 《公開決策帳本》：[ANIE-09 原始檔](./ANIE_09_Public_Decision_Ledger_Proposals_Commitments_Rejections_Delays_and_Release_Evidence_v0.1_2026-10-17.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P10]** 《選擇性透明》：[ANIE-10 原始檔](./ANIE_10_Selective_Transparency_Enterprise_Disclosure_Boundaries_Delayed_Revelation_and_Information_Sovereignty_v0.1_2026-10-17.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。
- **[P11]** 《開放會削弱競爭力嗎》：[ANIE-11 原始檔](./ANIE_11_Openness_Competitive_Advantage_Community_Innovation_Trust_Assets_and_Execution_Advantage_v0.1_2026-10-17.md)（依 2026-10-16／17 原始文獻；本系列內部研究）。

## C．EveMissLab 雲端既有研究與方法銜接

這些既有文獻是本系列形成過程可參照的理論或技術設計，並非本次新部署的驗收證據。連結指向已檢索過的對應雲端文件；研究者仍應留意各文件的版本與修訂歷史。

- **[I01]** 《企業母 AI：公司作為 AI 的可觀察世界》：企業世界狀態、非全知可觀察性與認知／主權分離。https://unboundedaxiom.org/p/lm-002360/
- **[I02]** 《從意圖到決策：AI 原生決策編譯器與稀疏意圖治理》：意圖、建議、授權與執行的邊界。https://unboundedaxiom.org/p/lm-004090/
- **[I03]** 《AI Agent 公開邊界與安全閉包：統合框架》：可讀、可持久化、可發布及外部可取得之分離；避免自我檢查綠燈取代真實安全後置條件。
- **[I04]** 《SEDB-GAME × ModWorld Runtime 技術白皮書》：有效遊戲世界、MOD 語義與多層 Runtime。
- **[I05]** 《EVEMISS 企業通訊智能核心：共用架構技術白皮書》：客服與對外通訊中的身份、政策、工具、風險和人工接管。
- **[I06]** 《AI 原生企業的潛在生產能力與可融資性評估框架》：AI 生產能力、可變現成果、帳面價值與現金流的分離。https://unboundedaxiom.org/p/lm-001728/

---

# 原稿狀態、驗證範圍與總結聲明

**本篇已完成之論文工作**：全系列研究物件整合、外部文獻定位、研究問題、權限矩陣、產品與公司通用治理模型、四軸指標、七級成熟度、12 週試點、16 項可反駁假說、因果比較設計、負面案例、工程資料契約、停止回退規則與技術附錄。

**本文未完成且不虛構之實際工作**：EveMissLab 真實產品的隨機對照試驗、實際 Steam 發行證據、玩家抽樣數據、外部創作者真實契約支付、跨公司追蹤、長期財務績效及依法須由專業人員出具的個案法律意見。以上都需要另行按授權及資源部署、蒐集和驗證。

**提交與 canonical source 原則**：本論文的正式研究成果是 UTF-8 Markdown 原始檔，數學公式以 ` $...$ ` 與 `$$...$$` 作唯一 canonical 定界符。原始檔應在提交前進行完整 UTF-8 解碼、結構與引用檢查、公式定界符檢查、JSON／YAML 解析、Schema 範例實際驗證，以及必要技術附錄檢查。聊天閱讀界面、渲染結果與 AI 的「已完成」敘述不能替代文件位元組本身。後續修訂應以新版本及可追溯更正維持論證可檢驗性，不得為了呈現成功而無痕刪除反例。

**最後結論**：ANIE 的核心不是讓 AI 代替企業負責，也不是讓社群取代創作權與商業判斷，而是讓企業已經有能力做到的事情——生產、修正、拒絕、合作、保密與公開——逐步具有能讓當事人理解和讓研究者檢驗的理由、證據與邊界。未來若證據反駁本篇提出的部分命題，修正與放棄那些命題，正是本系列開放研究精神的一部分。

---

*ANIE-12｜v0.1｜2026-10-17｜End of first full ANIE series (ANIE-00–12).*