---
title: "季度單機產品制：AI 工業化、算力額度與品質交付率"
english_title: "Quarterly Single-Player Product Systems: AI Industrialization, Compute Budgets, and Quality-Verified Delivery"
series: "AI 原生互動企業論"
series_en: "AI-Native Interactive Enterprise"
series_id: "ANIE"
paper: "02"
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: "single-dollar inline; double-dollar display"
source_policy: "Canonical manuscript is this UTF-8 source; chat rendering is not canonical."
evidence_scope: "Research synthesis and proposed framework; no new controlled trial or product-line deployment has been performed for this paper."
related_papers:
  - "ANIE-00｜從產品黑盒到 AI 原生互動企業"
  - "ANIE-01｜從 EA 到持續交付"
  - "ANIE-03｜可繼承的遊戲產品（預定）"
  - "ANIE-09｜公開決策帳本（預定）"
keywords:
  - "AI-native production"
  - "Quarterly game production"
  - "Compute budget"
  - "Multi-agent workflow"
  - "Quality-adjusted delivery"
  - "Critical path"
  - "Production evidence"
  - "Software delivery"
  - "Single-player games"
  - "Playable product quality"
---

# 季度單機產品制

## AI 工業化、算力額度與品質交付率

**Quarterly Single-Player Product Systems: AI Industrialization, Compute Budgets, and Quality-Verified Delivery**

**《AI 原生互動企業論》（ANIE）第 02 篇｜第一部：可驗證的 AI 原生產品交付**  
**作者：Neo.K｜一言諾科技有限公司（EveMissLab）**  
**版本：v0.1｜日期：2026-10-16｜公開研究工作論文，尚未經同儕審查**

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

---

## 摘要

傳統商業單機遊戲的生產排程，多以開發人員、經驗、預算、引擎、內容資產及測試人力估計交付週期。生成式 AI、程式代理、可重用遊戲系統、程式化內容生成、持續整合與自動驗證，使此類估計的部分前提有待重新量測。對於具備可繼承數位資產的微型科技公司，少量人員可能經由多代理工作流實施與過去不同的產品生產方式；然而，AI 的候選生成量，並不等於經過整合、驗收、可供玩家下載與使用的商品產能。本研究提出「季度單機產品制」（Quarterly Single-Player Product System, **QSPS**）作為一項待驗證的生產及公開交付制度，而不是一項主張所有遊戲必須三個月完成的普遍定律。

QSPS 將生產分為「任務候選—整合—系統驗證—人類遊玩判斷—平台交付—發布後品質」六個階段，區分算力／模型額度、可並行代理、可重用資產、審查能力、測試成本、產品範圍及市場接受度。本文建立多維資源預算、依賴圖與關鍵路徑、品質閘門、品質驗證交付量、季度承諾基準、成本與缺陷指標，以及同一團隊跨任務分層的比較實驗。雙週、月、季度、半年、年度被視為不同的資訊與決策時間尺度；其週期安排不直接等於必須每週推出大更新、每季發售完整新遊戲，或在固定期限內犧牲品質。

本文特別研究「提供更多可調度 AI 額度，是否能穩定提高高品質遊戲交付率」這項生產假說。模型指出，當候選生成是主要瓶頸、任務介面清楚、驗收可重複且資產可複用時，額度提升可能具有高邊際收益；當整合、審查、玩法評價、素材授權或發布後維護成為瓶頸時，單純增加 Token、代理數或 GPU 時數則可能產生冗餘、返工與風險。外部研究既包含特定 AI 輔助程式設計任務顯著加速的受控實驗，也包含成熟開源專案中 AI 工具導致減速的隨機試驗，以及後續對測量偏誤的修正討論。本文不以任何單一結果推論全部遊戲工作流，而要求本土化、任務分層、全成本與長期品質的實際測試。

研究的主要貢獻在於：將季度交付由「公開排程或經營口號」改造成「有任務基準、有實際建置、有可反駁產能假說、有成本帳本、有品質證據、能保留未完成原因」的工業化研究協議；並銜接 ANIE-01 的發行階段選擇，及後續 ANIE-03 的資產可繼承、ANIE-09 的公開決策帳本。本文為制度設計及實證研究規劃，**並未聲稱 EveMissLab 已完成此 QSPS 產線的跨季度實測，也未將示例數據冒充營運成果**。

**關鍵詞：** AI 原生遊戲生產；季度單機產品制；算力額度；多代理並行；品質驗證交付；模組資產複用；持續整合；遊戲用戶研究；公開季度目標；可驗證產能。

---

## 0．研究問題與立場邊界

### 0.1 本篇研究的獨立問題

ANIE-00 研究的是可驗證交付、外部意見與合法決策如何形成可追溯關係；ANIE-01 討論 DEMO、Playtest、EA、正式版如何選擇，而非把 EA 視為唯一必經路徑。本篇只回答更上游的問題：**一家採用 AI 原生工作流的微型遊戲公司，究竟能以多大的品質驗證產能，持續交付什麼規模的單機遊戲？**

它可拆成七個問題：

1. **資源問題：** 「AI 額度」如何被拆成可度量的使用權、費用、模型能力、推理次數、並發、算力與等待時間，而不是一個含混數字？
2. **流程問題：** 代理並行、可重用引擎及狀態機，如何縮短真正決定完成日期的任務鏈？
3. **品質問題：** 完成程式生成、通過測試、生成可下載建置與具有商品價值，為何不可互相替代？
4. **排程問題：** 三個月、半年、一年可作為哪些不同產品類型的設計目標？何時應減少範圍而不是延後所有產品？
5. **商業問題：** 額度費用、人工複核、發布後維護與跨產品資產攤銷，對經營現金流有何影響？
6. **可觀察問題：** 如何讓外部知道公司當季做成什麼、失敗什麼、為何改變計畫，又不公開所有機密？
7. **實證問題：** 如何設計足以推翻自身信念的比較試驗，而不是選擇成功案例後宣稱 AI 革命已被證明？

### 0.2 研究性命題而非普遍保證

本文認真對待以下產業主張：「若取得足夠 AI 額度並利用可重用產品資產，一家小型公司可能快速完成原本需要較多協作人力的產品工作。」此主張值得測試，也不應僅因過去產業慣例而被否定。然而，**它是可檢驗的條件命題，不是只憑模型輸出能力即可推出的結果**。

因此本篇**不主張**：

- 額度增加時，品質交付率必然單調增加，或必然呈線性比例；
- 任務可以任意拆分並在無成本下並行；
- 自動化測試足以取代對玩法、節奏、樂趣與文化理解的真人驗證；
- 某些小品三個月內可完成，就表示任何大型沙盒都能在三個月完成；
- Git commit 數、Token 數、PR 數、圖片數或測試通過率可單獨代表玩家價值；
- 需要季度說明，就必須每週發布建置、持續直播或揭露機密程式碼；
- 有其他公司業務，即表示遊戲後續開發所需的現金和時間已獲得保障；
- 商業產品可以用「AI 已驗證」作為未經獨立驗收的品質證書；
- 對外公開排程可凌駕 Steam 商店目前實際描述、授權或其他法定義務。

### 0.3 研究對象與不涵蓋範圍

主要對象為 PC 平台的單機數位遊戲：文字／GUI 世界模擬、回合制戰術、經營策略、程序化內容、可支援 MOD 的沙盒與中小規模敘事作品。這些類型的任務有些具備相對清楚的資料模型、規則、狀態轉移與測試 Oracle，可供 AI 原生產線反覆測試；有些則需要高度人類創意判斷。研究不直接推論到 MMO、雲端伺服器、主機認證、大型多人競技或需高度安全認證的系統。

本篇採「正式化概念模型＋外部實證比較＋未來前瞻性實驗設計」，沒有冒充已完成的遊戲上市或商業產線測試。

## 1．為什麼需要區分「工業化」與「AI 幫忙寫程式」？

### 1.1 六種不同的能力

單人開發者呼叫模型生成 3,000 行程式碼，與公司具備遊戲生產線，兩者並非同一事件。至少需要區分六種能力：

| 能力 | 可見產出 | 尚未自動取得的結果 |
|---|---|---|
| 內容／程式候選生成 | 程式、圖片、對話、關卡、測試草稿 | 可整合的版本 |
| 統一規格與介面管理 | API、資料結構、事件、限制 | 系統間不衝突 |
| 多代理工作調度 | 任務指派、分支、候選 PR | 交付關鍵路徑縮短 |
| 工程驗證與回退 | 測試、報告、重現案例、可回退建置 | 實際遊玩品質充分 |
| 發布與維護 | 平台版本、更新、公告、事故回應 | 長期相容、信任與市場價值 |
| 資產複用與知識移轉 | 模組、模板、規則、文件、授權 | 下款遊戲一定比較便宜 |

**AI 原生工業化**，在本文中特指：使遊戲任務能以重複且受版本控制的規格產生候選，經由受權限與品質限制的驗證流程提交，並將可以合法複用的成果轉化為下一輪產品資產。其最低要求不是公司必須自製引擎，也不是必須有大型代理團隊，而是具有可重現的**規格、執行、驗證、交付與回饋**。

### 1.2 不等於把所有判斷交給 AI

一個產品可讓 AI 協助建立 GUI、撰寫 NPC 狀態機、生成測試案例、執行差異比對、提議劇情、提出修補方案；但這不表示 AI 在法律上成為經營者，也不表示它能未經授權決定售價、著作授權、產品定位與對外承諾。技術候選的生成權、變更提交權、平台發布權與商業承諾權應明確分離。

這也與既有《從意圖到決策：AI 原生決策編譯器與稀疏意圖治理》及《形式權力與實際決策因果》相容：AI 的高實際因果貢獻，不等於制度權力自動移轉。[I02][I03]

### 1.3 原創研究問題

「AI 可以生成程式」早已是技術事實；「持續整合」「小批量工作」「產品線架構」也不是本研究首次提出。本篇新增的是將它們放入**商業單機遊戲的季度交付—品質驗證—公司公開紀錄**脈絡，研究 AI 額度成為顯著生產投入後，品質可驗證的成果是否足以支持更高頻率的作品交付及可持續經營。

## 2．既有實證文獻：為何不能只引用「AI 加速多少」

### 2.1 正面證據：受控小型程式任務的加速

Peng、Kalliamvakou、Cihon 與 Demirer（2023）針對 GitHub Copilot 的受控實驗，要求參與者以 JavaScript 實作 HTTP Server，報告使用 AI 組在該指定任務上的完成速度比對照組快約 55.8%。這是具有特定任務與測量條件的實證結果，能支持「部分明確界定的程式設計任務可獲顯著增益」，但無法直接代表整個遊戲的美術、系統整合、測試與上市。[E01]

### 2.2 反向證據：成熟開源專案的資深開發者可能減速

Becker 等人（2025）的 METR 隨機對照研究，涉及 16 位熟悉其成熟開源程式庫的開發者，共 246 個任務，觀察到允許使用當時前沿 AI 工具時，平均完成時間反而增加約 19%。受試者主觀上認為 AI 讓他們加速，與客觀測量形成落差。[E02]

該結果無法證明 AI 對所有軟體工程都造成減速；它提供另一個必要警告：成熟專案、深厚背景知識、高品質要求與大量理解／審查工作，可能改變候選生成速度的總體收益。

### 2.3 2026 年修正：新模型加速程度仍有選擇偏誤

METR 在 2026 年 2 月公布的新測量設計說明指出，較新的工具可能帶來更多加速，但後續樣本中有些開發者不願接受禁用 AI 的任務條件，形成不參與與選擇偏誤，且多代理併行使工時測量更複雜。因此，其後續初步估計不應被當作精確、可直接外推的「2026 年通用加速倍數」。[E03]

此處的學術教訓不是要否定開發者的實際感受，而是認為當 AI 系統持續進步、開發者越來越習慣使用時，**研究設計也必須跟著改變，否則很容易用錯誤的對照組低估或高估效果**。

### 2.4 組織背景：AI 放大工作流的優點及弱點

DORA 2025 年的《State of AI-assisted Software Development》以全球技術專業人士調查及質性研究，提出 AI 常會放大組織已有的技術與協作條件。其報告指出 AI 的正面效果應放在平台工程、工作單元分割、資料與工作流品質的脈絡理解，而非獨立歸因於模型訂閱。[E04]

DORA 對小批量開發與持續整合的說明，也指出 AI 生成的大量變更若無法被容易審查、測試及整合，可能增加交付不穩定性；因此應研究從變更到產品的完整價值流，而不是只研究編輯器端的速度。[E05][E06]

### 2.5 遊戲領域獨立的外部證據要求

*Games User Research*（Oxford University Press，2018）將玩家遊玩研究、理解、使用體驗及市場情境列為遊戲開發的重要方法，提醒我們遊戲品質不能被傳統軟體「API 正確回傳」全部涵蓋。[E07]

研究結論：AI 生產力至少存在**任務類型、既有資產、驗證強度、工具時間點、使用者能力、衡量時間窗**六個調節因素。本篇以這六個因素作為研究的最低分層維度，而不尋求一個對所有遊戲適用的固定倍數。

## 3．生產單位的四次轉換：從生成到玩家價值

### 3.1 工作候選不是商品交付

定義四種不同的觀測集合：

- $G_q$：第 $q$ 季生成的候選集合，例如程式、素材、草稿、測試案例；
- $A_q$：經指定驗收規則接受並可整合的工作項目；
- $R_q$：確已進入可取得之發布建置、且具備證據的項目；
- $V_q$：對實際玩家體驗具有正面價值的成果之研究性估計。

這些集合在概念上相關，但不要求簡單的逐層集合包含關係：例如一次批次生成可以支援多個功能，一項功能也可能整合多人及多輪候選。更重要的是， $V_q$ 通常需透過人類使用與多面向資料估計，不是一個可由 CI 測試直接列舉的集合。

研究上的必要區分是：

$$
|G_q| \neq |A_q| \neq |R_q|,
$$

而且不能僅由 $|R_q|$ 推知玩家價值的變動方向。

### 3.2 五種常見的虛假產能

**（甲）生成數膨脹。** AI 一晚產生數十個新的類別與畫面，整合後卻只有同一個功能真正有用。

**（乙）測試數膨脹。** 大量測試都只覆蓋理想路徑；存檔版本跨越、長時間世界演化或邊界錯誤仍然存在。

**（丙）候選 PR 膨脹。** 多代理同時提很多 PR，但互相修改同一個核心狀態結構，最終等待人工整合。

**（丁）版本號膨脹。** 發布了 v0.21、v0.22、v0.23，但玩家真正感知的玩法沒有改善。

**（戊）素材數膨脹。** 生成大量圖片、音效與敘事內容，卻缺乏統一風格、授權證據、容量預算與場景配適。

對這些現象最可靠的處置方式，不是禁止 AI 快速工作，而是**讓每個不同層級都保有自己的數量與成本紀錄，禁止互相冒充**。

### 3.3 最小品質交付單元

本文提出「可驗證交付單元」（Verified Delivery Unit, **VDU**），定義為一項具有穩定識別碼、明確玩家或系統用途、事前驗收條件、相關依賴、正式通過的驗證證據，以及可連到實際版本或經批准內部交付狀態的完整工作單元。

VDU 是**制度性的單位，不是通用物理計量單位**。一個 VDU 可能是「修正存檔回歸缺陷」，也可能是「新增戰鬥連擊系統」；兩者並不天然等價。跨作品比較必須建立任務複雜度、風險與工作價值的可比尺度。若沒有這些條件，就不能宣稱甲公司一季交付 50 個 VDU 必然優於乙公司交付 20 個 VDU。

### 3.4 「完成」至少需要四個獨立座標

對功能 $i$ 定義完成狀態向量：

$$
X_i=(c_i,u_i,q_i,p_i),
$$

其中 $c_i$ 為程式／內容實作， $u_i$ 為整合完成， $q_i$ 為品質驗收， $p_i$ 為已對指定使用群體發布。它們的狀態轉移需有對應的證據，不得因候選工作完成便由 AI 自動把 $X_i$ 改成「商品已交付」。此處的向量是研究性狀態模型，不意味著四個座標可以直接相加成單一完成百分比。

## 4．AI 額度：不是單一貨幣，也不是單一 GPU

### 4.1 可調度資源向量

日常口語中的「額度」可能指 ChatGPT／Codex 類訂閱配額、API Token、模型呼叫次數、並發工作階段、GPU 時數、雲端支出上限、GitHub Actions 執行分鐘，甚至大型任務需要的人類審查時間。這些資源不能直接按固定匯率換算。

令產品組合在週期 $q$ 可用的投入向量為：

$$
B_q=(b_q^{api},b_q^{sub},b_q^{gpu},b_q^{cpu},b_q^{ci},b_q^{human},b_q^{cash},b_q^{attention}),
$$

各分量分別對應可計費推論、訂閱配額、GPU／CPU 可用時數、CI 執行資源、具備特定能力的人力、可用現金，以及有效可持續的決策／審查注意力。

**不可把 $b_q^{human}$ 當成 $b_q^{api}$ 可以直接取代的數值**。加大模型推論總量若同時增加需要開發者判斷的候選，審查能力可能反而成為系統瓶頸。

### 4.2 額度還受能力與政策約束

同樣一百萬 Token，在不同模型、任務、上下文長度、工具權限、重試頻率下，產出並不等價。可實際執行的任務組合不只受支出限制，亦受模型適用性、權限、可用時間及任務依賴限制。

可表示成一組可行集合：

$$
\mathcal F_q=\{x:\, \Gamma_q x\leq B_q,\ x\in\mathcal P_q\},
$$

其中 $x$ 是工作調度方案， $\Gamma_q$ 是各任務的多資源消耗估計矩陣， $\mathcal P_q$ 則是依賴、授權、安全及品質規則允許的調度集合。式中的不等式按資源分量逐項理解；不假設所有資源都是連續可拆或消耗成本已完全可知。

### 4.3 必須區分額度、實際用量與可觀察成效

對每次代理任務紀錄：模型／工具版本、任務 ID、上下文摘要、推論費用或配額消耗、等待時間、人工介入、變更規模、整合結果與返工。若供應商僅提供模糊的訂閱配額、不公開 Token 明細或對不同計費類型使用混合方案，則應如實記錄「無法精確折算」，避免虛構費用。

對於本機模型還要記錄電力、硬體占用、維護及機會成本；對於私有 GitHub repository 的 CI，也應記錄雲端執行時間與儲存費用，依當時實際平台帳單為準。GitHub 官方文件已區分不同 runner、儲存及授權情境的費用計量。[E08]

### 4.4 研究假說：額度在什麼條件下有用？

若候選生成是瓶頸，增加模型可用額度可望縮短候選等待時間；若瓶頸改為審查、整合或玩法設計，額度邊際收益會降低甚至為負。故關鍵不是「大模型夠不夠強」這個單一維度，而是目前產線**限制性資源的所在位置**。

這個命題並不否認前沿模型可能透過更好的推理、Agent 協調或驗證能力，同時改善其他瓶頸；它只是要求指出**哪一個瓶頸被消除、消除成本多少、是否產生新瓶頸**。

## 5．非線性產能：關鍵路徑、並行成本與反覆驗證

### 5.1 任務圖比「寫了幾小時」更接近交付機理

令 $G=(N,E)$ 為工作任務的有向依賴圖。節點可以包括世界狀態資料結構、回合順序、物品規則、GUI、戰鬥系統、存檔、測試和發布。邊 $i\rightarrow j$ 表示 $j$ 在某種程度上需要 $i$ 的產出。

若依賴關係沒有形成環且工作資源足夠，完成時間仍受關鍵路徑約束：

$$
T_{crit}=\max_{p\in\mathcal P(G)}\sum_{i\in p}d_i,
$$

其中 $d_i$ 為節點在當前工作流下的實際持續時間， $\mathcal P(G)$ 是起點至終點的有效依賴路徑集合。此式是理想化排程下界；若有共享資源爭用、返工、等待審查或反覆狀態變更，實際週期可能更長。

### 5.2 代理越多，不一定越快

在非常簡化的可分割工作中，可以用以下式子提醒我們並行成本的存在：

$$
T(n)=T_s+\frac{T_p}{n}+C(n)+R(n),
$$

其中 $T_s$ 為不可並行部分， $T_p$ 為理想上可拆分的工作量， $n$ 為有效併行處理量， $C(n)$ 為溝通／整合／環境協調成本， $R(n)$ 為併行造成的衝突、回歸測試與返工成本。式中的項目是研究性分解，不假定所有項目可事前精確估值。

例如在同一個核心狀態機上讓十個代理同時修改資料結構，可能增加合併成本；讓它們分別完成具有清楚資料契約的十個獨立 UI 頁面，則可能取得更高並行收益。差異在於任務可分性與介面穩定性，而不只是代理總數。

### 5.3 減少關鍵路徑，優先於增加候選數

假設季度發行真正受限於「資料結構 → 存檔格式 → 跨版本驗證」這條鏈。將大量 AI 額度用於生成插畫、台詞或非必要功能，可能提高表面完成度，卻對真正的發行日沒有幫助。

因此每次資源調度都要回答：

1. 這項任務是否在目前的交付關鍵路徑上？
2. 它的完成是否解除其他任務的等待？
3. 增加一個代理是否會增加整合者的等待？
4. 是否能以先穩定介面、建立測試契約而縮短後續工作？
5. 若此任務暫時取消，是否會影響最低可玩商品？

### 5.4 反覆驗證也是一種產能

每次修補後能自動重新跑世界模擬、存檔遷移、UI 狀態轉換及效能回歸，是 AI 生產線持續擴張的重要條件。因為越快生成新功能，回歸風險與相互作用就越可能累積。反覆驗證本身不是浪費，而是維持加速收益不被長尾缺陷吞噬的能力。

## 6．資產複用：微型公司如何有可能形成工業規模

### 6.1 一次性產出與可繼承資產

專案交付一款作品後，可能累積以下資產：

- 可重用的世界狀態／事件總線與規則驗證系統；
- 回合制、經營模擬、人物關係等功能模組；
- 字型、Unicode／GUI、輸入控制、存檔及讀取框架；
- 美術風格資源、素材生成與後處理流程；
- 自動測試、基準測試、性能剖析及發布腳本；
- 玩家回饋分類、MOD SDK、翻譯與內容發布流程；
- 可以依法複用的設計文件、任務規格及已修復缺陷知識。

如果這些資產被適當模組化、授權清晰且文件可理解，第二款作品便可能不需重新建立所有基礎設施。但資產保存不代表必然可移植，遷移需要版本相容、玩法適應和介面成本。

### 6.2 複用並不等於必須採用自研引擎

本研究特別區分「公司擁有自己的世界狀態、測試或 MOD 架構」與「每個遊戲必須使用同一套自製完整引擎」。小型文字／GUI 或狀態機遊戲可能適合 Godot 等既有引擎，另以公司自主設計的模組處理其特色；有些專案可能以其他技術棧更快完成。

合理的工業化策略可以是：**共同的是驗收契約、產線語義與部分資產，不是強迫所有作品共用完整 Runtime**。若只為了架構統一而犧牲某款遊戲的實際交付速度，便違背此研究要提高真實產能的目的。

### 6.3 資產複用的成本分離

對第 $j$ 個遊戲，概念上可將總成本拆成：

$$
C_j=C_j^{unique}+C_j^{adapt}+C_j^{validate}+C_j^{publish}+C_j^{maintain}+a_jC^{shared},
$$

其中 $a_jC^{shared}$ 是共同資產開發與維護成本的一種攤配方式， $a_j$ 為事前固定的管理會計權重。該式不預設所有成本完全可加，也不將會計攤提直接等同現金流；其目的在於避免只報告「本次使用現成引擎三天做完」，卻把前一年建立共享架構的全部成本忘記。

### 6.4 資產愈多也可能引發另一種負擔

共同架構可能出現版本綁定、過度泛化、舊 API 被迫長期支援與相互衝突的產品需求。當維護成本接近新作的原生實作成本時，應考慮複製後分叉、逐步重構或只抽取穩定介面，而不是讓技術品牌壓過產品品質。

### 6.5 與既有 EveMissLab 研究的依賴

本篇可參照《AI 原生企業潛在生產能力與可融資性評估框架》（ANELCFF）對數位資產、AI 槓桿與工作流資本的區分。[I04] 對於 MOD 共創與遊戲語義，可參照《SEDB-GAME × ModWorld》而不重寫該 Runtime。[I05] 但 ANIE-02 的新貢獻是量化這些資產對**某種具體遊戲、某段觀察期間、某個品質門檻**的影響，而不是再次宣稱「資產很多，所以公司產能必然很高」。

## 7．世界狀態機遊戲的特殊優勢與不可忽略的複雜性

### 7.1 為什麼文字／GUI 遊戲是有價值的先導實驗域？

一款以文字、卡片、狀態列表、2D 地圖、回合制行為或 GUI 為主的遊戲，常能將主要玩法描述為有限的資料結構、轉移規則和可觀測事件。這可能降低部分高成本即時動畫、複雜 3D 美術與碰撞互動的前期要求，並讓 AI 更容易根據明確規格產生功能候選及測試。

例如一個世界狀態可以區分角色、地圖、勢力、資源、知識、任務和事件，但真正決定遊戲是否可玩的是不同狀態轉移間能否保持一致，玩家行為能否產生可理解的後果，以及遊戲是否有足以形成選擇意義的循環。即使外觀較簡單，底層也未必較容易。

### 7.2 狀態一致性是一種複合測試問題

設時間 $t$ 的遊戲世界狀態為 $W_t$，玩家與 NPC 行為集合為 $A_t$，遊戲規則與隨機種子為 $R_t$，則一次更新可抽象表示為：

$$
W_{t+1}=F(W_t,A_t,R_t).
$$

對確定性核心而言，使用相同前置狀態、輸入、版本與種子應能重現相同結果；但存在網路、硬體浮點差異、非決定性排序或外部工具時，必須另外建立可容忍的重現規格。不能因有一個函數 $F$ 就假設所有內容天然可證明正確。

若遊戲新增新的勢力法則、技能組合與資源轉換，每個新規則可能影響多個已存在的機制。其影響可以是局部，也可能形成跨系統長鏈。AI 可以協助遍歷測試空間，但不能在未列明假設下保證窮盡所有狀態。

### 7.3 世界模擬遊戲需要三層驗收

**微觀層：** 單一技能／物品／事件轉移正確，數值合法、碰撞與數據型別可接受。

**中觀層：** 隊伍、戰鬥、資源流、NPC 社群、區域經濟或派系任務能在多個機制互動後保持規則一致。

**宏觀層：** 長時間推進後世界不會崩潰、長期循環不會被單一策略無限制壟斷，且玩家仍能理解遊戲給予的選擇與反饋。

三層不能互相代替。某項任務的單元測試 100% 通過，仍可能在一百年模擬中形成不合理的資源爆炸；反之，遊戲平衡不完美不一定意味著程式邏輯錯誤。

### 7.4 存檔相容是「看不見的商品品質」

單機遊戲可以快速發布版本，卻也會在發布後立即面對存檔格式和回歸問題。長期存檔的玩家投入是真實利益：若新版導致進度不可恢復，功能增加再多也不能直接抵銷損失。因此存檔遷移測試、備份、舊版讀取及可回退策略應納入核心交付成本。

對提供 MOD 的作品，還要區分官方存檔模式、MOD 存檔的版本記錄、外部資源不存在時的合理退化行為，及不可恢復情況的透明提示。完整的 MOD 契約歸 ANIE-05，本篇先確認它會消耗真實的 QA 與維護資源。

### 7.5 具備狀態機不代表具備遊戲

若 AI 建立了多個可驗證系統，玩家卻只是在沒有動機的選單裡重複操作，產品仍可能欠缺遊戲性。值得驗證的是：每個行為是否存在有意義的代價與選擇、系統是否支援可理解的策略、內容是否不只是增加文字量。這些不能僅由編譯器、CI 或世界狀態不變量決定。

## 8．品質閘門：什麼情況下才允許宣稱「完成」？

### 8.1 八道彼此不同的閘門

本研究建議以分層閘門避免單一測試覆蓋率成為虛假保證。

| 閘門 | 核心對象 | 最低證據 | 失敗處置 |
|---|---|---|---|
| Q0 規格與來源 | 功能目的、素材來源、授權與依賴 | 任務規格、來源欄位、相關限制 | 不進入合併 |
| Q1 基本建置 | 編譯／打包／啟動 | 可重現指令與執行日誌 | 修復或退回 |
| Q2 局部正確性 | 單元測試、資料結構、規則 | 經確認的斷言與預期結果 | 不計入驗收 |
| Q3 整合一致性 | 模組介面、世界狀態、回歸 | 整合測試、版本契約、差異報告 | 暫停合併或隔離 |
| Q4 長程穩定性 | 存檔、隨機序列、時間推進、性能 | 長時模擬、遷移測試、效能基準 | 限縮功能或阻斷發行 |
| Q5 玩法與體驗 | 玩家理解、節奏、決策樂趣、可及性 | 真人遊玩紀錄、任務觀察與合理樣本 | 修改或重新設計 |
| Q6 商品與權利 | 商店描述、平台支援、素材及第三方使用權 | 權利清單、可玩範圍、發布檢查 | 阻斷對外銷售 |
| Q7 上線後 | 真實下載、玩家事故、MOD 與存檔回歸 | 平台建置、版本、支援工單與事件追蹤 | 修補、回退、公告、更正 |

這是研究設計，並非聲稱存在適用所有遊戲的官方八道標準。每道閘門可以根據遊戲類型調整，但**不能讓低風險的測試通過自動抵銷高風險的未通過項目**。

### 8.2 「可發布」與「可公開聲稱完成」有不同責任

一個 PR 通過 Q1–Q3，可能足以作為內部候選；一個公開 Playtest 建置還需要更高的可用性及資料安全；一個正在販售的版本則需要符合實際對外描述、適用平台規則與消費者合理期待。

因此形式上可分為：

$$
InternalAccept(i) \not\Rightarrow PubliclyDelivered(i).
$$

而：

$$
PubliclyDelivered(i) \not\Rightarrow PositivePlayerValue(i).
$$

後者是一項需要另外測量的市場與體驗命題。這些式子只陳述概念上不具有必然蘊含關係，不表示公開功能通常沒有價值。

### 8.3 風險分級優先於過度統一流程

參考以下研究性嚴重度分類：

- **P0：** 大量存檔毀損、個資／憑證外洩、確定的法規或平台重大阻斷事項、廣泛無法啟動等；在問題可緩解前阻斷發行。
- **P1：** 核心玩法難以完成、重大平衡破壞、普遍性系統錯誤；需要高優先級修正或明確限制適用範圍。
- **P2：** 次要系統與操作不便、局部相容性及品質問題；依玩家影響與成本排程。
- **P3：** 改良建議、非阻斷的視覺或文字問題；納入需求評估，不直接視為必做。

P0–P3 是內部優先級規則的示例；不同產品與安全情境下可調整，但調整應留下理由。若任何公開版本存在已知高風險限制，不能藉由「季度已達成百分之九十」掩蓋該缺口。

### 8.4 自動測試自身也必須被測試

當 AI 同時生成實作與測試，可能產生同源錯誤：兩者共享相同的錯誤理解。至少對核心規則設立部分獨立測試來源，包括固定的人工撰寫基準案例、反例、模糊測試、差分比對、屬性測試、封閉回放及真實使用者案例。

例如在資源不可為負的規則中，生成器可能把負數裁剪為零而掩蓋漏洞。獨立驗證應檢查「為什麼出現負數」、是否有資源重複消耗或世界狀態不一致。這比只驗證最終畫面沒有顯示負值更接近缺陷來源。

### 8.5 不允許 AI 自我簽發商業發行通行證

AI 可以提交報告、運行工具、分析差異、整理候選修復，但它產生的「PASS」文字不構成放行權。放行需要檢查可重現的測試產物、真正的平台上線狀態、相應責任人的權限，以及當時尚未解決的問題。

DORA 對測試自動化的官方說明也區分從自動建置、驗收、非功能測試到人工探索與使用者測試的不同層次；本篇將此原則移植到遊戲生產與公開證據。[E09]

## 9．玩家體驗與品質：軟體通過測試不是遊戲成功

### 9.1 遊戲品質是多面向，不是「Bug 少」一項

一款單機遊戲的品質至少可拆成四類：

1. **功能與穩定性：** 是否能啟動、運行、儲存、載入、完成主要操作、在宣稱硬體條件下保持可接受效能；
2. **互動理解：** 玩家是否了解操作、失敗原因、可選策略及世界規則；
3. **體驗價值：** 節奏、挑戰、策略深度、角色吸引力、敘事投入或探索樂趣；
4. **交易與信任：** 商品描述是否符合實際、付費後是否得到合理支援，以及重大修訂是否清楚說明。

四類相互關聯，但不能直接變成「95% 功能正確，所以遊戲達 95 分」的線性模型。

### 9.2 人類 Playtest 的研究設計

試玩者可以分成第一次接觸、熟悉類型、進階玩家、無障礙需求者及長期高投入玩家。每群人的資料用途不同：第一次接觸者適合觀察教學是否有效，進階玩家適合探索系統漏洞；兩者皆無法單獨代表全體市場。

研究應同時記錄：

- 是否能在無提示下完成核心遊玩循環；
- 出現失敗時能否理解原因與重新嘗試；
- 玩家如何描述自己的策略和目標；
- 遊戲在哪些時點顯著失去節奏或產生困惑；
- 玩家自願再次遊玩、推薦、購買的意願，以及它們與實際行為的差異；
- 哪些玩家表示不喜歡，但原因屬於產品定位而非功能缺陷。

不能只抽取正面評論作為成功證據。匿名化、取得同意、明確用途與避免不必要個資蒐集，是人類研究的必要條件。

### 9.3 AI 模擬玩家的正當功能與邊界

AI Agent 可用於大量產生輸入序列、探索 UI 狀態空間、執行策略搜索、尋找數值漏洞與產生可重現反例。這些操作能降低 QA 的部分搜尋成本；但其「喜歡程度」「情感共鳴」「疲倦感」等語言報告，沒有適當實驗驗證就不能等同於人類玩家的體驗。

研究可比較三組缺陷集合：純自動系統發現、人類試玩發現、兩者共同發現。真正有價值的不是誰提出最多問題，而是哪些方法對關鍵產品風險最有效。

### 9.4 玩家不認同也不是全部設計失敗

若一款困難的經營模擬遊戲刻意要求玩家承擔不可完全預測的世界後果，部分偏好簡單休閒遊戲的玩家不喜歡，並不自動要求公司刪除機制。ANIE-04 將進一步研究相交域：**玩家的需求是實際資訊，開發者保留設計判斷，接受與拒絕都要留下可理解的理由**。

## 10．三個月、半年、一年：不是三個固定遊戲等級

### 10.1 時間只是一項約束，不直接決定規模

三個月不必然是小品，半年不必然是中型遊戲，一年也不保證完成完整開放世界。不同遊戲類型可以選擇不同的內容約束、技術成本與美術要求；若原有資產可大量複用，預估期間可能縮短。但這必須在明確的成本與可測品質條件下評估。

本研究提供三種**假設性節奏**，不是對任何現有專案的交付保證。

### 10.2 A 類：三個月假設的完整單機小品

適合具有明確玩法核心、有限內容空間、已能重用大部分工程元件的作品，例如：單場景或少量地圖的文字／GUI 經營、回合制策略小品、規則導向關卡、短篇敘事冒險。其最低可銷售範圍應足以獨立完成，不依賴未來免費更新才成為完整遊戲。

**示例工作分配（非實測、非推薦固定百分比）：**

- 第 1–2 週：產品定義、核心循環、介面及最小可玩原型；
- 第 3–5 週：系統完成、持續整合、必要素材與存檔；
- 第 6–8 週：內容填充、玩法反覆、內部工具及缺陷修復；
- 第 9–10 週：受控真人 Playtest、體驗與平衡修改；
- 第 11–12 週：發行候選、平台準備、素材權利檢查、發布與緩衝。

若商店頁與平台審核有額外前置期，應提前安排，不能在最後兩週才開始必要程序。這是一個**含並行活動的示例序列**；實際工作必須依商店規定及任務風險重排。若核心遊戲在第六週仍不可玩，理性做法可能是砍掉次要系統、重新評估上市方式，而不是虛構剩餘功能已完成。

### 10.3 B 類：半年假設的多系統作品

可能包含多角色、經營資源、戰鬥／探索、基本關係系統及中等規模內容，允許循序擴大功能。核心難點由單一玩法轉向多個系統之間的互動。建議至少在中段先完成「從開始到局部結局或穩定循環」的垂直切片，避免每個子系統都完成八成但沒有能從頭玩到尾的遊戲。

半年制可以使用兩個季度作為可驗證公開窗口，但這不等於第一季就必須對外付費 EA；若測試所得的遊戲價值尚不足，可先做 DEMO 或 Playtest。發行形式仍依 ANIE-01 選擇。[I01]

### 10.4 C 類：一年或更長的世界模擬作品

若遊戲加入大地圖、多勢力、長程經濟、複雜 NPC 行動及大型 MOD 生態，成本可能集中在長時間耦合、後期性能、內容品質與版本相容，而不是前期有無成功生成系統。

一年制可以設四個季度驗收：核心世界、主要遊玩循環、跨系統穩定、外部測試／發布。對外何時進入 EA，應依目前可購買價值與玩家參與需求，而不是預設「一年就要從 EA 升級到正式版」。同樣地，若作品的實際風險高於預估，也可能需要一年以上。

### 10.5 三類節奏共用的是評價方法，不是同一套 Deadline

| 面向 | 三個月小品 | 半年多系統 | 一年或更長模擬 |
|---|---|---|---|
| 預設測試重心 | 完整核心循環與初次理解 | 子系統互動、平衡與回歸 | 長程模擬、存檔、效能與跨版本 |
| 最可能的重大風險 | 表面完成、內容過少或教學不清 | 整合困難、功能範圍膨脹 | 狀態爆炸、技術債與長期維護 |
| 重大交付證據 | 全流程可玩建置 | 垂直切片與跨功能測試 | 長程模擬證據及可重現世界狀態 |
| AI 潛在高效任務 | 模板化程式、介面、文本、測試 | 模組生成與複合規則測試 | 大量模擬、規則差分、素材輔助 |
| 需獨立驗證的事項 | 遊戲是否完整而值得購買 | 玩家是否理解多系統 | 世界是否長期穩定且有樂趣 |

### 10.6 範圍收縮是一種能力，不是失敗的掩飾

若已經確認某季度不可能完成所有預定功能，應公開區分：承諾內必需保留的基本商品內容、可以延期的非核心功能、應當轉為 MOD／DLC 的擴充內容，以及必須取消的設計。這種拆分需要遵守既有銷售承諾、平台規範、消費者權益與必要通知；不能在收費後偷偷縮減已販售的實質內容。

## 11．從單一遊戲到季度作品組合：產能不是多開幾個 Agent 就有

### 11.1 同時推進多款作品的風險

一家公司可能同時開發一款大型世界模擬、數款三個月型小品，以及維護舊遊戲。AI 使候選生成成本下降時，容易產生「每款都能很快推進」的錯覺，但玩家支援、平台發布、財務、素材檢查及創辦者設計審核，仍可能集中於少數資源。

若三款遊戲各自完成大量零碎功能，卻都尚未形成可出售版本，這不代表產能有效提高。相反，可能是工作在製品（Work in Progress, WIP）太多，排程、上下文切換和等待驗收超過其帶來的好處。

### 11.2 產品線的兩種輸出

本研究區分：

- **新作產能：** 在一段期間內產生並真正對外發行的新商業作品；
- **維護／演化產能：** 對既有作品提供修復、相容性、必要內容與經驗改善。

一家公司某季沒有發售新遊戲，卻對已上市遊戲修復重大存檔問題、改善可及性並發布有意義更新，仍可能提供非常高的現有玩家價值。不能只用「每季上市幾款新遊戲」衡量整體產線。

### 11.3 產線佇列與約束

至少將工作分類為「下一次發行關鍵路徑」「重大維護事故」「可延後功能」「下一代資產建設」「外部社群貢獻審查」。不同佇列應有不同服務等級與資源預算。例如 P0 事故可以中斷一般季度排程，而自動產生但尚未評估的內容候選不能無限制塞入下一版。

單一決策者的注意力可能是最難擴充的資源：若所有 AI 候選都需要其逐項閱讀、比較與決定，增加代理數最後會增加等待。應尋找可授權給自動測試或外部專業合作的低風險工作，將人類決策時間保留給需要真正設計判斷的地方。

### 11.4 維護負債與新作補貼

不能只算每季新遊戲毛收入，忽略上一季作品新增的長期成本。每一款發行品都有一組未來義務，例如事故修復、玩家支援、存檔格式維護、MOD 相容、第三方依賴更新。若沒有預留維護儲備，新作上市越多，長期可能越難繼續下一輪工業化生產。

可按年度規劃維護容量，但每季都需要重新觀察，不能把「已發行」當成「所有工程成本歸零」。

## 12．雙週、月、季、半年、年：五個時鐘不能混成一個

### 12.1 工作時鐘、發布時鐘、公開資訊時鐘

「每週開發」「每月更新」「每季驗收」是不同的治理概念。建議至少區分：

- **工程時鐘：** 每次任務、PR、建置、測試與修復何時實際發生；
- **發布時鐘：** 對某個實際玩家群體何時提供可下載版本；
- **治理時鐘：** 公司何時整理方向、回應提案、修訂目標及公開進度。

這三個時鐘不必同步。某週可以沒有面向玩家的大更新，卻有大量完成驗證的內部工作；某季可能只做一次重大公開更新，但日常 Bug 修補持續進行。只要對外說明精確、對內證據可查，這仍符合持續交付的精神。

### 12.2 建議的五尺度安排

| 尺度 | 主要目的 | 建議產出 | 不需要強制的事情 |
|---|---|---|---|
| 雙週 | 記錄接近實時的開發狀態 | 已完成／阻礙／下一步 | 每雙週一定上線重大更新 |
| 月度 | 合併玩家回饋與技術變化 | Bug 分級、功能取捨、進度更新 | 一定交出新的商業內容 |
| 季度 | 公開主要里程碑及能力驗收 | 版本證據、未達成理由、資源與風險回顧 | 每季一定發售一款遊戲 |
| 半年 | 檢查產品方向與組合成本 | 跨季度產能、維護、財務風險 | 中斷仍有價值的長期作品 |
| 年度 | 評估工業化能否複製 | 不同類型產品的品質、成本與交付紀錄 | 僅看營收或新作數決定成敗 |

### 12.3 為何「季度」是公共驗收尺度，而非天然最適生產週期

季度約可提供足夠時間完成一批可供玩家理解的重大功能，同時又短到能持續接受外部觀察。但不同公司、遊戲與風險情況可能更適合八週或四個月。季度制的理性依據是**外部比較與內部決策的可操作性**，不是存在一條適用所有創作活動的自然定律。

因此正式研究應比較不同回顧窗口對估計偏誤、行政負擔、交付品質及玩家理解的影響；若年度反而更適合某種作品，不能強迫其採用季度承諾而增加虛假進度。

### 12.4 突發事故可以打破時鐘

如果發現存檔損壞、難以啟動、嚴重資安風險或重大付費商品描述錯誤，應依嚴重度立即處理，而不是等到月底或季末才公開。季度報告應對這些事件保留後續處置紀錄，但不能取代即時危機應對。

## 13．品質驗證交付率：一組指標，而不是一個神奇 KPI

### 13.1 第一原則：分離「目標達成」與「品質驗證」

令某季開始時已固定基準範圍的目標集合為 $P_q$ ；每個工作項目 $i$ 有事前定義的比較權重 $w_i>0$，完成驗收指示變數 $a_i\in\{0,1\}$，真正已進入對外可取得版本的指示變數 $r_i\in\{0,1\}$，且對於本季度宣稱已公開交付的項目要求 $r_i\leq a_i$。對未發布的內部成果，另列內部驗收，不以 $r_i=1$ 冒充。

則可定義：

$$
PCR_q=\frac{\sum_{i\in P_q}w_i a_i}{\sum_{i\in P_q}w_i},
$$

其中 $PCR_q$ 表示固定基準下的計畫驗收比，而：

$$
PDR_q=\frac{\sum_{i\in P_q}w_i r_i}{\sum_{i\in P_q}w_i},
$$

表示已按相應玩家群體交付的計畫比。兩者可以不同：內部任務已完成但尚未發布，就不應計入 PDR。若 $P_q$ 為空、權重總和為零或基準未被適當批准，指標應顯示不適用，不得硬填百分比。

### 13.2 為何不能直接把 $PCR_q$ 當成整體產能？

公司可以每季先把目標設得很低，讓 $PCR_q$ 常態接近 100%；也可以在季中把做不完的工作刪掉後重新計算。為防止這種 Goodhart 型指標作弊，本研究要求**基準不覆寫**，所有新增、取消、換權重、改規格皆保留版本與理由。

除了 $PCR_q$ ／ $PDR_q$，必須分開公開原定工作量、實際驗收的總工作量、維護／突發工作占比、返工，以及品質負面訊號。不能用一個漂亮的百分比替代整個制度。

### 13.3 品質驗證交付量：只適合在可比較任務內使用

定義季度品質驗證交付量：

$$
QVD_q=\sum_{i\in R_q}w_i a_i e_i,
$$

其中 $R_q$ 是該季已實際發布的工作單元集合， $e_i\in\{0,1\}$ 表示該項是否具備事前要求的驗證證據。權重 $w_i$ 僅在相同任務分類、相同權重制定方式下才具有比較意義。

如果一項已發布功能沒有合格證據，它仍可能存在於實際版本中，但**不能在這個嚴格定義下算作已被驗證的交付量**。這不等於宣稱它必然有錯，而是宣稱的證據強度不同。

### 13.4 完整的產能必須是一個指標向量

本研究不建議把所有結果壓縮成單一「AI 生產力分數」。最小向量可以表示為：

$$
Z_q=(QVD_q,PCR_q,PDR_q,L_q,D_q,M_q,K_q,U_q),
$$

其中：

- $L_q$：從需求正式受理到可取得交付的延遲分布，至少記中位數與尾端分位數；
- $D_q$：發布後重大缺陷逃逸／回歸情形；
- $M_q$：維護與返工占用的實際工作負擔；
- $K_q$：完整生產成本；
- $U_q$：玩家理解、使用性與市場價值的多面向估計。

如果 QVD 增加、缺陷逃逸也大幅增加，不能僅因 QVD 較高便宣稱產線全面改善。同樣，如果維護減少但新功能變少，也要看產品當時的真正目標。

### 13.5 成本效率與前置期，不應混成同一個數字

對 $QVD_q>0$ 的特定可比較任務組合，可定義：

$$
CostPerQVD_q=\frac{K_q^{allocated}}{QVD_q}.
$$

這只是管理性效率指標，不代表權重是客觀貨幣價值，也不能跨不同權重尺度直接比較。應同步公開工作混合、品質等級與人力成本估計方法；若某季全部投入共同資產建設而無公開版本，數學分母為零就應註記「不適用／尚未交付」，不可以任意設為零成本。

相較之下，週期時間 $L_q$ 是觀察工作流快慢， $K_q$ 是投入成本，缺陷逃逸是品質後果， $U_q$ 才關乎玩家感知。四者均不應由單一數字替代。

### 13.6 指標不應忽略「不做錯事」的成果

修復一項能毀損玩家存檔的嚴重缺陷，可能在內容數量上不具吸引力，卻比新增十個外觀道具更有價值。研究可以依嚴重度與風險建立另行衡量的「避免損害」向量，但不能將未發生的災難當成已實證的貨幣收益。

為防範漂亮的功能數據掩蓋必要維護，季度公開應分別列出新功能、事故修復、品質改善、基礎設施與未交付工作。保留專業與創作價值上不可簡單加權的判斷。

## 14．指標反作弊：權重、基準、證據與反事實

### 14.1 權重與完成定義必須事前指定

如果功能做完後才以其完成難度指定權重，很容易把真正成本或成功結果倒過來作為評分依據。因此本研究建議：重要季度里程碑在期初確定驗收規格與估計權重；變更可以發生，但不能刪除原紀錄，且應註明理由、影響及授權人。

### 14.2 不把結果與努力混同

一個代理執行十小時但沒有得到有用的修復，這些費用仍是真實成本；一項改動只花五分鐘卻修復關鍵存檔漏洞，則可能產生高價值。**努力成本需要完整核算，成果價值需要另外驗證**。兩者既不應混為一談，也不應互相抹除。

### 14.3 外部獨立抽樣與任務反事實

在條件允許時，應由不直接撰寫該功能的人抽樣檢查完成聲明，並使用一批不由同一 AI 系統生成的驗證案例。對品質和產能爭議，不應只靠公司自己產生的宣傳簡報佐證。必要時可將原始敏感證據留在受控稽核環境，只對外發布經授權的摘要和可重現方法。

### 14.4 預先辨識 KPI 政策扭曲

若公司獎勵「每季完成項目數」，則團隊可能大量拆分無關痛癢的功能；若只看「重大版本次數」，可能每季發表無意義更新；若只看「玩家票數」，可能忽略少數重大障礙。良好的評價制度必須同時允許目標未達成、資料缺失與負面結果進入正式報告。

ANIE 的透明度不在於所有指標都漂亮，而在於對外可以區分「確實改善」「仍有爭議」「尚無證據」「驗證失敗」，以及產生這些結論的理由。

## 15．完整成本：額度便宜不代表產品一定便宜

### 15.1 將現金成本與經濟成本分開

對一家採用 AI 原生工作流的微型公司，總成本不只是付給模型商的訂閱費。可按管理用途區分：

$$
K_q^{cash}=K_q^{model}+K_q^{cloud}+K_q^{tools}+K_q^{assets}+K_q^{contract}+K_q^{fees}+K_q^{other},
$$

其中雲端運算、工具、素材採購與外部委託都可能形成現金支出。若該公司同時持有自有硬體，還須另記電力、設備維護與折舊估算。法律與會計分類應依當時適用規範，不可由這個研究式自行認定所有項目都是某種會計科目。

另可定義用於管理分析的經濟成本：

$$
K_q^{economic}=K_q^{cash}+K_q^{founder\_time}+K_q^{opportunity}+K_q^{risk},
$$

其中創辦者時間、其他產品被延後的機會成本與風險預估不一定是當期現金流出，並且可能存在估值重疊。因此此式**僅用於成本分類，不可在未處理雙重計算時直接當作財務報表數值**。

### 15.2 重要的是每個已驗收成果的總成本

假設同一類功能在某期間內採用 AI 後，候選生成成本大幅下降，但回歸修復與高階審核成本提高，應以全生命週期淨效果衡量，而非只比較模型生成的速度。

至少記錄六段實際耗費：

1. 需求釐清與設計；
2. 候選生成及重試；
3. 程式整合與介面調整；
4. QA／Playtest／修復；
5. 平台建置、公告、素材與合規；
6. 發布後固定觀察窗內的維護與玩家支援。

最後一項特別重要。若一款遊戲在上市當週看似非常便宜，但兩個月後必須花大量資源修正系統缺陷，早期的成本節省便可能被高估。為了研究可比性，應同時報告發布當日成本與發布後 30／90 天的累積成本，而不把尚未發生的支出虛報成精確事實。

### 15.3 多模型路由不是免費午餐

簡單任務使用較低成本模型，難題升級至高能力模型，理論上可能降低每個有效工作項目的平均費用。然而路由設計、上下文壓縮、轉換錯誤、不同模型的邊界能力以及重試開銷，都會影響實際結果。這應透過任務日誌驗證，不應先驗宣稱存在一個對所有遊戲都最優的模型組合。

對某任務類型 $k$ 的可接受策略集合，可比較：

$$
J_k(a)=\bigl(Cost_k(a),Time_k(a),Defect_k(a),Quality_k(a)\bigr),
$$

以向量方式呈現不同方案，不強制將品質與成本全部換算成單一分數。必要時由公司在合法、品質及現金約束下選擇可行的 Pareto 方案。

### 15.4 訂閱配額與 API 計費不可混記

固定月費、按 Token 支出、GPU 租賃、私有 CI 執行與人力報酬的邊際成本不一致。若某固定費率產品在大量使用下分攤較低，不能推論未來每個月都能取得相同可用配額或同樣的服務品質；若供應商更改模型或排隊機制，應將它視為外生條件改變。有效產能要以**當季實際可取得的工具能力和發生的費用**建模。

## 16．配額邊際收益：什麼時候應該加碼，什麼時候應該停？

### 16.1 研究性邊際產能

令 $QVD_q(B)$ 表示在可用資源向量 $B$ 下、固定任務樣本及既定品質門檻所能得到的可驗證交付量。若測量條件適合，可以研究第 $j$ 類投入的邊際變化：

$$
\Delta_j QVD=QVD_q(B+\delta e_j)-QVD_q(B),
$$

其中 $e_j$ 是某一資源方向， $\delta$ 是明確可比的額度增加量。此式是實驗性估計對象，不預設可微、線性或容易找到真正的反事實值。

若只比較「上月額度少、下月額度多」，模型升級、任務組合、遊戲成熟度與團隊熟練度同時變化，則不能把觀察差異全部歸因於額度。應使用合適的任務配對、隨機或階段性交叉設計。

### 16.2 四種可能的產能區間

1. **資源匱乏區：** 候選產生需長時間等待，額度略微增加可解除明顯阻礙。
2. **有效擴張區：** 任務已明確分割，QA 尚有餘裕，增加額度能促進更多工作通過驗收。
3. **瓶頸轉移區：** 整合、設計判斷或 Playtest 變成主要等待處，額度持續增加但有效交付提升有限。
4. **擁塞與反效果區：** 多代理搶占相同環境、候選相互衝突、審核積壓、返工增加，額度增加可能降低整體效率。

這四區是待實證的類型學，並非所有公司必然順序經歷四區；不同任務可以同時處於不同區間。

### 16.3 資源調度規則

若連續兩期觀察到候選工作積壓但可驗收功能增加有限，應優先檢查 QA、整合和設計決策瓶頸，而不是直接增加代理。若大量計畫工作在等待模型額度且後續驗收順暢，則有理由測試提高配額。

應避免把模型服務用量當成績效指標。最佳化的方向是**減少每個符合品質要求的交付所需的稀缺資源**，而不是最大化消耗。

### 16.4 簡化情境：候選加速可能被審查吃掉

下列數字純屬**算術示例，不是 EveMissLab 或外部研究的測試結果**。

| 工作段落 | 不使用 AI（示例工時） | 使用 AI（示例工時） |
|---|---:|---:|
| 候選實作 | 40 | 8 |
| 整合／審查 | 10 | 25 |
| 驗證與返工 | 8 | 15 |
| 發布準備 | 2 | 5 |
| **串行總計** | **60** | **53** |

若工作完全串行且其他條件相同，使用 AI 的 53 小時相對 60 小時約減少 11.7%。但若審查從 25 增至 34 小時，使用 AI 的總工時便為 62 小時，反而超出不使用 AI 的 60 小時。若可並行，真正經過的日曆時間又不能直接等於總工時。

此例只說明為什麼應量完整價值流；沒有任何部分構成 AI 現實表現的先驗估計。

### 16.5 成本與速度可能出現不同方向

假設 AI 工作流節省十小時人力，但新增一筆昂貴推論費；可能時間更短、現金支出更高。另一個工作流可能現金費用降低，但由創辦人承擔更多審查時間。公司決策必須根據當時現金壓力、時間目標、產品品質及可持續性選擇，而不是只追逐單一效率排序。

## 17．公開交付帳本：不把每日工作日誌當成研究成果

### 17.1 公開的是可核對的關係，不是所有內部細節

季度單機產品制可以對外公布：原定主要交付範圍、目前狀態、版本與發布日期、可供玩家下載的內容、阻斷原因、重大玩家意見的處理結果，以及未來方向。公司不需要公布每一個內部 Prompt、Agent 工作日誌、開發者私人生活、尚未公開 IP、重大漏洞重現細節或商業談判。

ANIE 所要求的是「重要聲明有來源」，不是「所有來源都必須直接公開」。

### 17.2 建議的季度狀態語義

| 狀態 | 意義 | 不得混淆的狀態 |
|---|---|---|
| 草案（Candidate） | 提出的可能工作，未經批准 | 排程與承諾 |
| 評估（Evaluating） | 正在估算成本、風險與價值 | 必然會做 |
| 已排程（Scheduled） | 已納入暫定資源配置 | 絕對完成保證 |
| 實作中（In Progress） | 正在進行工作 | 可取得的公開版本 |
| 內部驗收（Accepted Internally） | 指定驗收通過 | 已對外交付 |
| 已公開交付（Delivered） | 有真實可取得版本和相應證據 | 所有玩家滿意 |
| 暫緩／取消（Deferred／Canceled） | 有正式修訂紀錄 | 曾經不存在的目標 |
| 發布後修正（Corrected） | 記錄事故、回退、補丁或錯誤更正 | 抹除舊版事件 |

關鍵規則：AI 不能單憑自己看到測試通過，就將「內部驗收」提升為「已承諾」或「已對外交付」。授權與實際平台狀態必須另有證據。

### 17.3 何種公開資訊最有研究價值？

假設某季原定新增三個主要功能，最後只有兩個完成，其中一個是在玩家反對後主動取消。若只公開「完成率 67%」，外部可能誤以為公司能力不足；若交代已完成項目、取消理由、玩家回饋、實測成本及仍保留的核心體驗，就能提供更完整的可觀察資料。

公開紀錄應接受更正。錯誤的估計、對功能狀態的過度樂觀、漏掉的缺陷，都可以透過附加版本及修正聲明補救；但不能為了讓季度報告漂亮，直接覆寫原始基準。

### 17.4 公司治理可以延伸，敏感資源不能直接投影

未來若將相同事件／帳本架構用於非遊戲產品，公司可能採用類似的「目標—工作—證據—決策—回應」模式。但財務、人事、商業秘密、合約及個資具有不同揭露限制，不可因遊戲開發可公開就推論其他部門也應全公開。研究的可遷移性要留待 ANIE-10 與 ANIE-12 分別實證。

## 18．與 Steam 的更新工程：技術發布容易，不等於可以略過風險

### 18.1 Steam 既有工具足以支撐不同速度的版本交付

Steamworks 官方文件提供 SteamPipe 的內容上傳與管理、公開／私人 Beta 分支、建置切換與回退方式；已上市遊戲的修補與持續更新是官方支持的常態。[E10][E11]

這為季度制度提供一個重要現實起點：公司不必因為要實施持續交付，就另外建立自己的遊戲下載商店。Steam 可作為正式下載、更新與消費者平台；公開網站則管理更完整的進度、需求和交付證據。

### 18.2 建議的發布鏈條

```text
需求與季度範圍
      ↓
規格、驗收條件、資產／授權檢查
      ↓
AI／人類實作候選 → PR / 變更紀錄
      ↓
建置與自動化測試 → 整合／回歸／存檔測試
      ↓
真人測試、問題分級、必要修補
      ↓
發行候選（Release Candidate）
      ↓
Steam 私人／受控測試分支
      ↓
發布批准 → Steam 正式分支
      ↓
真實可取得狀態核對、公告及公開證據
      ↓
事故觀測、修復、必要回退、季度回顧
```

此鏈條的目的是標示必要的功能關係，實務中可平行化，也可以有多個候選及回退節點；不應把它誤認為所有步驟只能完全串行。

### 18.3 發布前後都要核對實際建置

內部 CI 顯示成功，不保證玩家拿到的 Steam Default Build 正是該版。ANIE-01 已提出發布證據包的概念，本篇要求明確記錄內部 build ID、平台 build ID、適用分支、公開時間、發行摘要以及最後已驗證的平台取得狀態。即使因權限或隱私不能公開全部識別碼，也要能提供可審計對應。

### 18.4 發布頻率應依內容與風險調整

Steam 官方同時提醒：修補可以按需要快速發布，但玩家每次可能需要下載新的更新，而大型內容更新需考慮宣傳、實際內容與使用者體驗的節奏。[E10] 因此本文不宣稱「每週更新一定比每月更新好」。快速修補、穩定性更新及重大內容發布，應有不同門檻和溝通方式。

### 18.5 與 MOD 相容策略的交界

若遊戲原生支援 MOD，重大更新可能破壞外掛與存檔。在研究上，每次影響公開 MOD API 的更新都應記錄版本差異、舊版支持及已知相容問題。若官方已公開相容承諾，便需按實際承諾管理，不能用「使用者自己安裝 MOD」一概免除所有溝通責任。具體的 MOD 版本化及 AI 輔助遷移歸 ANIE-05 詳述。

## 19．如何做真正的比較實驗，而不是拿自己的成功說服自己？

### 19.1 最重要的對照不是「人類公司 vs AI 公司」

一般市場上不同工作室的作品類型、員工、資金、工具及玩家規模差異極大。單純比較其開發月數，難以分辨是 AI 生產力、類型差異、既有資產，還是對品質要求不同造成的結果。

本研究優先建議同一公司內部採取任務分層、固定品質門檻與不同生產方式的比較，必要時加入外部合作工作室做更廣的驗證。這能部分控制組織文化、專案管理與品牌因素，但也需要防止同一團隊學習效應與工作內容互相污染。

### 19.2 四種介入條件

對風險適中、可合理配對的工作包，事先定義四種可能的生產條件：

- **A：常規工具條件。** 允許既有程式編輯器、文件檢索與人工工程程序，不使用本次指定的新 AI 代理工作流；此條件不應任意剝奪開發者為完成工作所必需的基本工具。
- **B：單一 AI 助手條件。** 允許單模型輔助生成與開發者審查。
- **C：多代理條件。** 允許多角色並行，但使用與 B 相同的品質閘門與來源規則。
- **D：AI＋成熟資產＋既定產線。** 允許可重用模組、標準化介面、CI 與 AI 代理共同作用。

這四組不是所有任務都能完整交叉比較；尤其 D 與其他組的資產差異本身就是一個需要分開估計的介入效果。若要測試「僅 AI 額度增加」，就應在資產與其他工具固定的條件下改變額度；若要測試「整條工業化產線」，則應明確標為組合介入而非單一 AI 效果。

### 19.3 任務分層與配對

每個工作包需在開始前標註：

1. 任務類型：程式新功能／Bug／存檔／UI／視覺素材／任務內容／測試／效能；
2. 專案成熟度：從零原型、早期單機、成熟既有作品；
3. 外部依賴與介面穩定度；
4. 任務難度、預估工時與不確定性範圍；
5. 是否直接影響關鍵路徑；
6. 資料與授權是否允許使用外部模型；
7. 必要的驗收 Oracle 與人工試玩需求；
8. 可複用資產占比。

若無法合理配對，應改採觀察研究、分批導入、歷史比較與保守結論，而非虛構隨機對照。

### 19.4 隨機化與實際限制

在可分離的任務集合中，可以按任務類型與難度區塊隨機指派條件；或採同一團隊交叉執行不同任務但交換工具條件的設計。需控制學習效果、候選外溢與先前 AI 提供的資訊影響。不能把一個已由 AI 解出的題目再交給「禁用 AI」組測試，卻宣稱兩者獨立。

當某位開發者實務上無法在沒有 AI 的情況下合理完成任務，或出於權益與意願不參加無 AI 組時，應如實記錄選擇偏誤，不能只留下願意參加的樣本而推論所有開發者。這也是 2026 年 METR 後續研究的重要教訓。[E03]

### 19.5 測量時鐘要同時存在

每個任務至少分別收集：

- **人員實際投入時間：** 寫規格、操作、等候決策、審查、重工等；
- **日曆交付時間：** 任務受理到驗收／上線的真實經過；
- **AI 工具活動時間：** 模型運算與待命，不等於人力工時；
- **CI 與測試時間：** 編譯、測試、重試和排隊；
- **發布後觀察窗：** 30／90 天維護與缺陷；
- **體驗結果：** 使用者研究、可用性與真正的遊戲價值。

多人／多代理併行時，人的總投入工時可以大於或小於日曆時間；兩者都要報告，不能把代理工作期間視為某個人全天都在工作，也不能把人員準備及最後整合完全忽略。

### 19.6 因果結果與觀察結果分開發表

若使用隨機設計，應報告樣本數、遺失資料、任務難度、預先指定的主要結果、效應大小、不確定區間及對偏離方案的處理。若樣本很小，應以估計不確定性為核心，而不是使用漂亮的小數點宣告「已證實」。

若只能取得公司內部歷史記錄，則可分析趨勢與可能關聯，但不能把模型更新、公司學習、資產增加及市場差異造成的共同變化直接歸因於某個工具。觀察成果有商業管理價值，但它的因果證據強度需另行標示。

### 19.7 研究結果應包括不利發現

若多代理條件產生更多候選、更多測試、更多 PR，但總交付日變晚，這是一項實際可用的研究結果，應該發布。若單一 AI 模型在某類 GUI 工作上優於五個併行 Agent，也可以依此重新配置產線。研究不是為了確保所有結論支持「AI 工業化一定勝利」，而是找到什麼條件下哪些方法有效。

## 20．十項可反駁假說與觀測判準

為避免「一切結果都能用 AI 時代的變化合理化」，本文提出十項可預先註冊、且允許被否定的研究假說。每項必須在正式測試前指定主要觀測對象、可接受品質門檻、比較期間與何種結果算作不支持。

### H01：增加 AI 額度可以提高特定任務的可驗證交付量

**假說：** 對規格清楚、驗收可重複、AI 候選生成為主要瓶頸的任務，適度增加可調度模型額度，可提高固定時間內的 QVD。

**觀測：** 在相近任務樣本、相同資產和品質規則下，比較額度提高前後的驗收與發布結果，而非只看 Token 增加。

**反駁：** 額度增加但 QVD 無顯著改善，或因審查、返工與缺陷增加而使淨效益為零或為負。

### H02：多代理並行的收益受介面穩定性調節

**假說：** 具有獨立接口和明確驗收契約的任務，多代理可降低日曆交付時間；高度耦合任務則更容易發生衝突與返工。

**觀測：** 將任務按介面耦合程度分層，記錄代理數、合併衝突、審查等待和交付日曆時間。

**反駁：** 在控制難度後，低耦合任務並未獲得預期收益，或高耦合任務同樣表現良好，迫使研究修正其因果機制。

### H03：可繼承資產提升的是後續作品的效率，而非僅第一作速度

**假說：** 具備合法可重用模組、測試與文件的公司，其後續相近作品在維持品質下的單位交付成本逐步下降。

**觀測：** 追蹤同一類型跨作品的適配成本、共享模組的維護成本、缺陷與玩家體驗，不只看原始碼複製率。

**反駁：** 共同資產的抽象與維護成本高於節省的重複投入，或使新作的設計選項受限。

### H04：候選生成量與品質交付率之間不存在固定正比例

**假說：** 生成量在某些工作流與 QVD 呈正相關，但當審核與整合成為瓶頸時，相關性降低，甚至可能出現負向效果。

**觀測：** 同時記錄生成候選、已接受、已發布和驗證通過，分析不同任務型態的轉換率。

**反駁或修正：** 若在受測範圍內生成量能穩定且高準確度預測 QVD，則需縮小本假說聲稱的限制範圍，而非忽視結果。

### H05：品質閘門與小批量提交降低發布後重大回歸風險

**假說：** 在相近版本及任務條件下，具有獨立整合測試、較小可審查變更及發行候選流程的產線，相比缺乏這些措施的產線，重大缺陷逃逸率較低。

**觀測：** 比較缺陷密度、事故嚴重度、回退比例及實際修復時間，同時控制發布內容規模。

**反駁：** 增加驗證程序但風險未下降，或其成本高到超過產品可承受範圍；可能需要調整測試有效性而非一味增加測試數量。

### H06：固定季度公開基準提高外部對產品進度的理解

**假說：** 與只有一般更新新聞的同類作品相比，提供可查的原定目標、變更、實際版本證據和未完成理由，能改善玩家對「目前能玩到什麼」的判斷。

**觀測：** 以自願參與且樣本適當的理解測驗、訪談、支持工單錯認率、期望落差指標衡量。

**反駁：** 外部仍普遍誤讀承諾，或維護紀錄所需成本對遊戲品質形成不成比例的傷害。

### H07：高頻率更新不是最佳值，應存在產品情境依賴的頻率區間

**假說：** 在固定總內容量下，過多小型公開更新可能增加下載、測試與溝通負擔；某些情況下較少但品質充分的更新更有效。

**觀測：** 比較不同發布頻率的錯誤率、下載負擔、玩家回應、工時和內容接受度。

**反駁：** 在控制其他因素後，較高頻更新在整個受測區間內均更好且沒有負面影響；則不得強加本篇所猜測的內部最適頻率。

### H08：玩家體驗研究能發現純機械驗證無法捕捉的品質缺口

**假說：** 對涉及玩法理解、動機與節奏的工作，真人測試可以發現自動測試未能辨識的重要問題。

**觀測：** 按缺陷類型標記人類測試／模擬測試獨立發現率、有效性與後續修復結果。

**反駁：** 在特定遊戲類型與驗收設計下，純自動系統已涵蓋實際重要問題，且人類測試邊際收益很低；則可重新安排人類研究密度。

### H09：完整成本納入發布後維護時，早期 AI 增益可能改變方向

**假說：** 只量開發當下的速度，可能高估部分 AI 工作流的淨效益；納入固定觀察窗的缺陷、更新和支援成本後，某些初期收益會縮減或反轉。

**觀測：** 同時報告上市日和上市後 30／90 天的累積成本與品質結果。

**反駁：** AI 工作流在兩種時間窗內均穩定改善成本與品質，此時應如實承認長期收益，而非堅持反轉一定會發生。

### H10：季度單機產品制可以遷移至其他數位產品，但效果依賴驗收性

**假說：** 具有可驗證任務、發布事件及外部反饋的 SaaS／工具／數位內容專案，可部分採用 QSPS；依賴難以明確定義的創作或高度監管系統，其產能測量需大幅修改。

**觀測：** 在不同領域比較建置成本、公開理解度、品質指標及合規風險。

**反駁：** 模式在遊戲以外缺乏可重現價值，或只有在非常狹窄的特殊任務中才有效。若如此，應將理論縮小為特定產品線工具，而非保留不實的企業普遍性。

### 20.11 研究結論不應用單一顯著性門檻代替效應判斷

小型遊戲工作室可能沒有足夠樣本進行高功效的統計檢定。此時更合理的做法是預先指定最小具有實務價值的效應、提供合理的不確定性區間、記錄重複次數，並把不足以作結論的結果保留為「尚無充分證據」。不能只因檢定不顯著就斷定沒有差異，也不能只因看到一次明顯變快就宣稱普遍已證實。

## 21．三種假設性產品的端到端案例

以下所有案例均為**設計情境，用來說明研究如何落地；不是某款 EveMissLab 遊戲已正式完成、銷售或獲得測試結果的紀錄**。

### 21.1 案例 A：三個月 GUI 戰術小品

**產品假設：** 使用已可合法複用的回合、角色、存檔和 GUI 元件，遊戲有固定戰場、少量角色與一個完整主線循環。美術初期可採統一而節制的風格，但對外版本必須已達可接受商品品質，而非以未完成的視覺承諾替代目前商品。

**關鍵路徑：** 基礎規格 → 可玩循環 → 存檔與結束條件 → 玩家測試 → 發布建置。

**AI 適合嘗試的任務：** UI 控件、資料驅動角色表、測試案例、敵方策略原型、文本校對、缺陷定位。

**不能跳過的驗收：** 玩家能否理解回合規則、戰鬥節奏、無法啟動與存檔問題、素材授權、商店頁的真實描述。

**可能失敗：** 候選 UI 看似漂亮，但操作多一步、遊玩回饋遲鈍；或 AI 產生多種角色能力後，玩家只需要固定一種策略就能通關。

**合理處置：** 縮減不必要的角色和地圖數量，優先完成戰術選擇與遊戲閉合；若發布前品質不足，修改時程或測試階段，而不是為了滿足三個月標籤強行開賣。

### 21.2 案例 B：半年世界狀態經營模擬

**產品假設：** 包含地圖、任務、資源、生活日程、人物關係與事件決策；以統一世界狀態為核心，但採與作品相稱的表現風格。

**關鍵路徑：** 狀態資料模型 → 核心事件 → 存檔 → 多系統交互 → 長程平衡 → 外部測試。

**AI 適合嘗試的任務：** NPC 行為測試、規則轉移反例、介面資訊顯示、生成任務候選、事件統計分析。

**不能跳過的驗收：** 長時間推進後不變量、存檔相容、玩家是否理解關係系統、可能的循環策略漏洞。

**可能失敗：** 產生大量世界事件卻缺乏可觀察的玩家後果；或者人物關係和任務互相矛盾，人工修正的成本遠高於生成。

**合理處置：** 優先建立規則與事件驗證，凍結過多的次要系統，並用一個可從頭玩到尾的垂直切片檢查遊戲是否仍有趣。

### 21.3 案例 C：一年以上、跨版本的沙盒世界

**產品假設：** 多區域與派系、長週期角色演化、自由技能、經濟模擬、MOD、長程存檔；產品可能持續數年更新。

**關鍵路徑：** 世界基本規則 → 長程穩定 → 核心遊戲循環 → 可測擴充介面 → 存檔與 MOD 相容 → 真人長時遊玩 → 發行階段判斷。

**AI 適合嘗試的任務：** 大量狀態遍歷、NPC 策略模擬、規則衝突定位、效能瓶頸分析、內容規格輔助、MOD 相容性測試。

**不能跳過的驗收：** 內存／CPU／GPU 成本，長程狀態穩定，存檔與 MOD 使用者利益，內容風格一致性，玩家在龐大世界中的方向感。

**可能失敗：** 初版世界框架很快完成，接下來幾個月都在修補因耦合造成的長尾錯誤；或者內容看似無限，玩家卻感受不到有意義的差異。

**合理處置：** 將可交付的世界範圍分層、優先完成具有完整體驗的區域或年代，持續測量新增世界模組的邊際成本。是否以 EA 收費由當前產品價值決定，而不是認為 AI 能繼續寫就可以先出售。[I01]

### 21.4 三種案例的共同教訓

同樣採 AI 原生產線，真正的主要阻礙可能各不相同：案例 A 是整體體驗，案例 B 是系統相互作用，案例 C 是長期耦合與維護。因此公司應為每類產品維持不同產能模型，而不能將小品的工時縮短倍數直接乘到大型世界模擬上。

## 22．失敗模式與反對論證

### 22.1 反對 A：「有額度，生成夠多就一定做得完」

如果「做得完」指產生足量程式與素材，模型可能非常強；如果指完成合理售價、平台要求、玩家可玩內容、長期穩定與真實驗收，則仍需要實證。這不是否認 AI，而是避免把一段工作流的成果當成整個商品的證明。

### 22.2 反對 B：「越透明就會讓公司失去創作自由」

透明度可以針對結果與決策理由，不必開放每項內部設計討論。設計者可以解釋某項玩家需求不符合產品定位並決定不做。ANIE 不把公開理解轉化成強制群眾指揮；外部參與與產品主權可以同時存在。

### 22.3 反對 C：「有季度報告會增加公關負擔」

若需要人工從十幾個工具中重新複製資料寫報告，此批評成立。因此應先由正式任務、測試及發布事件生成摘要，經授權審查後對外投影。最初可以只維護最小公開頁面，不必替每一個小 PR 寫一篇新聞。

### 22.4 反對 D：「三個月目標會逼出低品質遊戲」

如果把截止日看得高於品質閘門，確實容易造成低品質產品。但本文的三個月是測試性的產品範圍與產線目標，重要承諾不得被未完成的時間表強行取代。若無法通過 P0、商品描述或玩家核心循環，應減少非核心範圍、改變發行方式或修訂時間。

### 22.5 反對 E：「玩家喜不喜歡無法科學測量」

玩家樂趣無法被一組普遍客觀數字完全描述，但不代表完全不能研究。可操作化的使用性、理解、行為、可重玩、體驗報告與市場資料，各自提供有限的證據。學術上應承認偏好異質性，不把玩家價值假裝成編譯器的布林值。

### 22.6 反對 F：「AI 代理會互相學習，對照實驗不可能乾淨」

此疑慮部分成立，尤其長期產品工作流中的上下文外溢、共用資產、模型升級都會破壞簡單隨機化。這不表示永遠無法研究，而是可能需要以模組／時間區塊為隨機化單元，或在無法隔離時承認只有觀察性證據。透明揭露限制勝過製造不實的因果確定性。

### 22.7 反對 G：「既有 AAA 與大型工作室可以做出更高品質，季度小品沒有價值」

兩者屬不同產品定位。市場可能同時存在小型完整體驗與高預算精品。研究的核心是某一產品約定的品質與成本是否可以持續達成，不是宣稱小工作室所有作品的藝術品質必然高於大工作室。工業化也不表示每款遊戲都要有相同風格或規模。

### 22.8 反對 H：「資本額低、公司業務很多，玩家就一定安心」

法人身分與跨產品可追蹤性可能提高辨識與聲譽約束，但不是可持續開發的充分證據。現金流、可用人力、售後義務與實際交付紀錄仍須分開評估；若公司有多項業務，還要衡量遊戲是否經常被更緊急的業務中斷。

### 22.9 反對 I：「既然 Agent 能自己寫測試，審查者就不需要人」

部分可形式驗證工作或低風險資料轉換可能高度自動化，但人類遊玩品質、商業權利及公開責任的制度仍需符合適用法律與實際授權。是否需要多少人力，應由任務風險、測試有效性及經驗資料決定，而不是固定要求所有修改都一律需要或一律不需要人工介入。

### 22.10 反對 J：「季度公開會讓競爭者直接抄走生產流程」

公開交付證據不等於公開所有流程、Prompt、測試語料或商業策略。企業可以選擇性公開可驗證但不構成機密的內容，並保留合法智慧財產與敏感資料。其競爭收益或損害，需要在 ANIE-10／11 中另外比較，而不能當作完全保密或完全公開的理由。

### 22.11 反對 K：「AI 模型進步太快，今天的研究明天就過時」

模型能力的實際數值可能迅速變動，所以本篇不將某個 2025 年模型倍數奉為永恆常數。研究保留的是分層定義、測量協議、輸出驗證與成本歸因；新模型出現時重新測試，就能產生可比較的資料。這也使本篇可以被未來反駁、修訂或部分淘汰。

## 23．制度不變量、授權與可修正性

### 23.1 三項基本不變量

**不變量一：候選不推出交付。** 一份候選、PR 或測試通過不能自動被公開宣稱為玩家已取得的商品功能。

$$
Candidate(i) \not\Rightarrow Delivered(i).
$$

**不變量二：資源消耗不推出品質。** 額度、Token、代理數與算力可以成為重要投入，卻不能直接證明商品品質。

$$
ComputeSpent(i) \not\Rightarrow QualityPass(i).
$$

**不變量三：技術完成不推出商業授權。** 即使遊戲可以成功建置並運行，也需要權利及發布許可、素材來源、平台狀態與具體承諾的相容確認。

$$
TechnicalPass(i) \not\Rightarrow AuthorizedRelease(i).
$$

這些均為本文的規範性設計約束，而非自然科學定律；其實務收益仍應接受檢驗。

### 23.2 權限分離

至少區分：候選提出者、整合者、測試／驗證者、產品決策者、發布批准者與公開資訊批准者。一家小型公司可能由同一自然人承擔多種角色，但系統仍應保留不同操作事件與驗收結果，避免混淆「我已經看到」與「已經核准」。

### 23.3 公開更正與失敗的治理

當原定季度目標未完成，紀錄至少包含：原目標識別、變更日期、當時已掌握的原因、對已購買玩家的影響、目前新範圍，以及是否需要更新商店描述。若後來發現最初原因判斷錯誤，可以再補更正，不必假裝第一次說明一定正確。

### 23.4 AI 的權限與安全

AI 讀取內部工單，不表示可把所有內容發到社群；AI 能使用 GitHub，不表示可以合併任意 PR；AI 能觸發發行流程，也不表示有權更改售價或對外承諾。對工具授權、公開邊界、密碼、私人資料與跨庫資訊應保留明確的政策閘門。可參照 EveMissLab 已有 Agent 公開邊界研究，不在本篇重寫其全部安全工程。[I06]

## 24．最小可落地的 QSPS 產線規格

### 24.1 不必先建造完整公司 ERP

對第一輪測試而言，現有 GitHub 專案、CI、版本分支、測試報告、Steam 發布通道，以及一個簡單的公開頁面便可以形成最小資料鏈。是否要把這些整合進內部軟體管理中樞或未來的企業 Mother AI，可以在制度獲得實證之後再決定；不應為了打造企業平台而先阻礙第一款遊戲交付。

### 24.2 六個最小紀錄物件

1. **Product：** 作品身份、範圍、目前發行階段與合法權利責任人。
2. **QuarterGoal：** 期初基準、工作清單、驗收門檻、風險和外部承諾級別。
3. **WorkItem：** 任務分類、規格、關聯 PR／修正、驗收證據。
4. **ResourceUse：** 每次 AI／人類／CI／素材投入與已知成本、測量缺口。
5. **BuildEvidence：** 構建與實測的版本證據、可取得分支、阻斷缺陷。
6. **PublicDecision：** 目標變更、發行批准、延期解釋、公告投影及更正歷史。

每個物件都應有穩定 ID；但公開顯示的資訊只需是經授權的欄位，不是內部原始資料全集。

### 24.3 最小工程條件

- 能從乾淨環境重新建置至少一個指定平台版本；
- 重大任務有可執行驗收案例，通過狀態對應具體版本；
- 有可重現的遊戲主要循環，以及存檔版本記錄；
- 有 Release Candidate 與正式版之間的分支或其他隔離；
- 能記錄回退、事故與版本更正；
- 重大素材與第三方依賴有合法使用來源；
- AI／人類工作成本可以在合理範圍估計並標示未知；
- 一份公開季度摘要可由現有正式事件資料產生，經授權人檢查後發布。

### 24.4 參考技術棧的選擇

研究不強制使用某個特定引擎。若選用 Godot，其官方命令列可支援 `--headless` 及無介面匯出流程，有利於自動化建置與部分測試；但實際畫面、美術、輸入及遊玩體驗仍需另行驗證。[E12]

Steam 的 SteamPipe、Beta Branches 與建置管理可負責平台測試及發布，不必重新發明下載與修補機制。[E10][E11] GitHub 或其他版本控制系統可保存變更、PR 與測試結果。這些只是可用的工程選項，不表示本研究已實際部署完整工作流。

### 24.5 第一輪 90 天觀察的研究程序

**第 0 階段：先有 Baseline。** 先記錄現有任務類型、模型使用、建置和缺陷統計，確定需要改進的瓶頸；若完全沒有可比較的過往資料，則可先做 2–4 週的觀察基線，但不聲稱這代表所有未使用 AI 的反事實。

**第 1 階段：選擇有限研究產品。** 只選一個具有明確完整遊戲循環的作品。避免把尚未完成的多個大型世界產品同時當成初次 QSPS 成功檢驗。

**第 2 階段：建立 Task/Build/Evidence 三鏈。** 為主要功能設 ID、驗收條件、可重建環境、缺陷分類、平台版本對照；AI 產生的測試必須有部分獨立抽驗。

**第 3 階段：執行數個不同類型的配額／代理測試。** 控制工具與工作範圍，盡可能分離候選生成、整合、驗收及發布後缺陷效果。

**第 4 階段：真人 Playtest 與產品審查。** 不只問產品是否可執行，也要問玩家能否理解、是否存在有價值的選擇，以及目前可交付內容是否符合宣稱。

**第 5 階段：公開季度結果。** 記錄已完成、未完成、延後、取消及原因。公開必要的研究限制，不把候選進展包裝成已交付功能。

### 24.6 第一輪完成條件

第一輪 QSPS 的成功，不必等同「一定發售一款新遊戲」。可以把最低研究交付定為：一個真實可玩候選、一次規格完整的 Playtest 或正式版決策、一份能重現的 QA 證據、一次季度基準對照、一組可信的 AI 全流程成本資料，以及對失敗環節的具體改進清單。

如果商品已達上市條件，當然可以正式發行；若仍缺乏當前可購買價值，則應先保留測試階段。這維持 ANIE-01 的原則：**發行狀態由商品現況決定，研究進度不能代替商品責任**。

## 25．與 ANIE 前後篇及 EveMissLab 研究的責任分工

| 文獻／專案 | 本篇借用的前提 | 本篇不重複處理的部分 |
|---|---|---|
| ANIE-00 | 可驗證交付、外部互動、非僭位決策、分層揭露 | 全系列企業制度總綱 |
| ANIE-01 | DEMO／Playtest／EA／正式版的非強制路徑 | Steam 發行階段的完整制度分析 |
| ANIE-03（預定） | 可繼承數位資產與維護的必要性 | 他人接手與 AI 後續開發的完整移交試驗 |
| ANIE-04（預定） | 玩家的需求與產品設計權需分離 | 相交域、投票與協商的完整模型 |
| ANIE-05（預定） | MOD 相容成本是產線品質的一部分 | MOD SDK、介面契約與遷移制度 |
| ANIE-09（預定） | 季度目標需對應決策與版本證據 | 公開決策帳本的完整權限與資料架構 |
| ANELCFF | AI 原生企業的無形資產、產能與現金價值區分 | 企業融資及全部估值模型 |
| SEDB-GAME／ModWorld | 遊戲語義與 MOD 共創 Runtime | AI MOD 語義底層完整設計 |
| Mother AI／ANDC | 企業認知、意圖展開、權力及授權分離 | 公司 Mother Runtime 與決策編譯器本體 |

本篇的獨立學術焦點是：**用可操作化且可反駁的方式，研究 AI 額度、資產複用、多代理工作與品質閘門能否共同形成可持續的季度遊戲交付產能**。

## 26．結論：從「給我額度」走向「給出可驗證產能曲線」

AI 發展提供了重新檢查遊戲產業生產函數的真實理由。某些程式、介面、素材、測試與內容任務，今天已可以採取與過去不同的完成方式；對擁有可重用數位資產和明確工作流程的微型公司，人工規模未必能直接代表產品交付能力。這個變化值得研究，也可能使部分三個月、半年乃至一年規模的作品路線具有新的可行性。

但對外能夠形成長期信譽的，不是生成量、模型名稱或豪言壯語，而是實際玩家可以下載並使用的版本、可複核的品質證據、誠實的未完成原因、經過充分核算的成本，以及在下一輪產品中能否重現的交付能力。

因此本文將「季度單機產品制」定義為**允許多種發行路徑、具有多尺度公開回顧、由 AI／人／資產共同構成、受到品質與權限閘門約束、以真實成果而非候選數量評價的生產制度**。

本文不把季度期限當作品質之上的命令，也不否認產能可能大幅進步。相反，它使「AI 工業化真的能有多快？」成為可持續收集資料、可公開接受質疑、能夠由未來結果修正的研究問題。

最後，若未來 AI 產線能交付高品質單機產品，又能將其來源資產、測試與文件保存為合法可移交的結構，則公司的競爭能力便不必完全依賴少數人的長期手工操作。這將自然通往下一篇 ANIE-03：**可繼承的遊戲產品——當原開發者暫停或離開時，如何驗證另一個人或另一組 AI 系統真正有能力接續維護，而不只是能讀懂程式碼。**

---

## 附錄 A．季度產品基準與公開報告範本

以下所有欄位是**研究性建議格式**，不是現已部署的平台紀錄；如有使用者資料，公開前須經匿名化／合法處理及必要審查。

### A.1 期初基準

```text
文件 ID：ANIE-QPS-PLAN-EXAMPLE-Q1
性質：示例，不代表真實遊戲的承諾
產品：［待填］
計畫季度：［起始日期—結束日期］
版本階段：內部原型／DEMO／Playtest／EA／正式版／維護
最低可玩產品範圍：［玩家目前可完成的完整循環］
本季批准工作：［Work Item ID、描述、權重、驗收門檻］
本季不納入：［明確排除的內容與原因］
主要風險：［技術、玩法、資金、授權、平台］
重要依賴：［自有引擎／第三方／合作方／平台］
模型／代理可用資源：［授權下可揭露之摘要］
QA／Playtest 安排：［類型、窗口、必要判準］
對外承諾語義：［探索／計畫／已批准承諾］
決策者與批准時間：［授權記錄］
```

### A.2 季中變更事件

```text
事件 ID：ANIE-QPS-CHANGE-EXAMPLE-0001
基準連結：ANIE-QPS-PLAN-EXAMPLE-Q1
原目標：［原 Work Item ID 與描述］
變更：加入／修改／延期／取消／升級優先級
觀測原因：新技術限制／玩家回饋／缺陷／授權／現金資源等
證據：［相應 Issue、建置與測試、必要的匿名摘要］
對玩家已付費範圍的影響：無／待評估／有，需說明
修改後處置：［下一個可驗證節點］
批准者：［公司授權人或授權流程］
公開程度：公開／部分公開／暫緩公開／保密
```

### A.3 季末公開摘要

```text
季度：［待填］
當前對外可取得版本：［平台、分支、版號、核實時間］
期初批准主要項目：［數量及可比較工作量］
本季完成內部驗收：［逐項清單與證據］
本季實際已對外交付：［逐項清單與建置證據］
本季延後／取消：［原目標、變更理由及已批准處置］
重大缺陷／回退：［非敏感摘要及修復狀態］
玩家與測試者的重要發現：［匿名化且有同意之摘要］
成本與產能：［實際可證實部分，缺失資料須標註］
下一季方向：探索／評估／排程，避免未授權保證
更正歷史：［若有，保留可查追蹤］
```

### A.4 對外說明的語義紀律

「預計研究」與「已承諾交付」不可使用相同標籤；「內部 build 可跑」與「Steam 玩家可下載」不可使用相同時間戳。若平台狀態短暫不同步，應註記狀態核實時間，而不是用網站公告強行宣稱玩家必然已取得版本。

## 附錄 B．任務／資源／版本事件的最小資料契約

此 JSON 是**供未來工程討論的假設性 schema 示範**；尚未形成產品 API，不含真實 token、憑證、private repository URL 或使用者個資。

```json
{
  "schema": "anie.qsps_observation.v0.1",
  "kind": "work_item",
  "work_item_id": "example-task-001",
  "product_id": "example-game",
  "quarter_baseline_id": "example-q1",
  "task_class": "save_migration",
  "planned_weight": 2,
  "baseline_frozen": true,
  "risk_level": "P1",
  "acceptance_criteria_ids": ["example-ac-001"],
  "status": "candidate",
  "resource_use": {
    "ai_provider_type": "unreported",
    "ai_tool_version": null,
    "model_cost_amount": null,
    "model_cost_currency": null,
    "subscription_quota_units": null,
    "ci_compute_minutes": null,
    "human_active_minutes": null,
    "human_review_minutes": null,
    "data_completeness": "missing"
  },
  "integration": {
    "revision_id": null,
    "pr_id": null,
    "result": "not_checked"
  },
  "validation": {
    "test_report_ref": null,
    "independent_check": "not_yet_done",
    "risk_gate_result": "pending"
  },
  "release": {
    "release_id": null,
    "build_id": null,
    "channel": null,
    "accessible_to_intended_users": false,
    "verified_access_at": null
  },
  "post_release": {
    "incident_ids": [],
    "save_compatibility_status": "unverified",
    "observation_window_days": 90
  },
  "governance": {
    "technical_reviewer": null,
    "release_approver": null,
    "public_disclosure_status": "not_approved",
    "amendment_event_ids": []
  }
}
```

**不可違反的資料語義：**

1. `candidate` 不代表 accepted；accepted 不代表發布；發布不代表所有玩家滿意。
2. `data_completeness: missing` 不得被統計成零費用、零工時或零缺陷。
3. `accessible_to_intended_users` 須根據實際分支／權限／下載核對，不能只看內部 CI。
4. `planned_weight` 應保留最初批准版本；若調整要有獨立變更事件。
5. `release_approver` 不得由 AI 自行寫入虛構身份；授權以實際存取控制為準。
6. 外部公開視圖必須先通過機密、個資、第三方授權與安全規則檢查。
7. 正式工程系統需自行定義 schema 驗證、身分權限、事件時序及不可偽造的紀錄保存方式，僅有這個 JSON 範例不足以提供安全或稽核保證。

## 附錄 C．指標字典：哪些可以直接計，哪些不能

| 指標 | 研究性定義 | 必要資料 | 常見誤用 |
|---|---|---|---|
| Generated Candidates | 生成候選次數／物件數 | AI 工作事件 | 當成完成功能數 |
| Integrations Accepted | 審查合併的有效變更 | PR／測試／審查記錄 | 當成玩家已下載 |
| PCR | 期初計畫的權重驗收比例 | 固定基準、驗收證據 | 季中刪掉難題後重算 |
| PDR | 期初計畫的權重公開交付比例 | 固定基準、實際版本 | 把內部候選算作發布 |
| QVD | 有權重、發布與合格證據的交付單元量 | 可比較分類、版本與測試 | 跨遊戲直接相加稱總產能 |
| Lead Time | 任務受理到實際驗收／交付的時間 | 起訖時間戳、暫停原因 | 只算生成或 PR 完成時間 |
| Review Burden | 人工審查及修復負荷 | 工作紀錄、抽樣估計 | 忽略創辦者注意力 |
| Escape Defects | 發布後被發現的重要問題 | 工單、版本、嚴重度 | 只用未回報視為零缺陷 |
| Maintenance Load | 維護工時、現金與優先級占用 | 事故／支持／版本歷史 | 發布後視為無成本 |
| Player Experience | 可用性、理解、遊玩價值多面向資料 | 合法、適當的玩家研究 | 直接等同好評率或下載量 |
| Total Economic Cost | 現金與非現金機會成本的估計 | 費用、時間、估值方法 | 當作法定財報數字 |
| Quota Saturation | 增加額度後的有效產出變化 | 可比介入、工作混合 | 只看額度用盡與否 |

### C.1 必須公布「未知」的欄位

若無法取得模型供應商的實際配額計量、公司沒有完整人力計時、某個缺陷在發版 90 天後才被發現，研究應把這些資料列為未知、延遲取得或右設限，不可自動記成零。可使用缺失率描述資料品質，並在敏感度分析中評估不同合理假設下的結果是否改變。

### C.2 玩家樣本的代表性

若自願試玩者大多來自熟悉模擬遊戲的社群，不能推論所有 Steam 顧客都擁有相同學習意願。發布後的評論更可能存在自我選擇與極端經驗偏誤。分析應區分玩家分層、樣本來源與觀察窗口，不應只用「正評率上升」證明工業產線改善了遊玩體驗。

## 附錄 D．可操作的遊戲測試矩陣

下表為**示範性測試案例分類**，不宣稱任何作品已通過。

| 測試 ID | 系統 | 輸入／情境 | 預期驗證 | 測試性質 |
|---|---|---|---|---|
| G-QA-001 | 回合狀態 | 同一初始狀態與確定性種子重跑 | 產生可核對的一致結果 | 自動回放 |
| G-QA-002 | 資源交易 | 連續買賣、取消與超額交易 | 符合帳本規則，不發生非法複製 | 屬性／反例 |
| G-QA-003 | 存檔 | 舊版本存檔開啟新版本 | 按版本契約遷移，失敗時不毀損原檔 | 遷移／回退 |
| G-QA-004 | 世界演化 | 長時間多勢力模擬 | 重要不變量持續成立，效能符合預算 | 長程模擬 |
| G-QA-005 | 回合策略 | 多種技能及優先級交互 | 不違反行為規則與合法結束條件 | 整合／策略 |
| G-QA-006 | GUI | 鍵鼠與必要輸入配置操作 | 操作正確、介面有清楚的回饋 | 自動＋人工 |
| G-QA-007 | 初次遊玩 | 不看文件的受測者開始遊戲 | 可以觀察教學理解與困惑點 | 真人研究 |
| G-QA-008 | MOD | 官方版本升級、舊 API 外掛載入 | 相容性狀態有客觀記錄 | 契約／相容 |
| G-QA-009 | 平台版本 | Release Candidate 切換正式分支 | 真實玩家可取得正確建置 | 發布核對 |
| G-QA-010 | 缺陷事故 | 假設公開版出現 P0 回歸 | 可啟動修復、回退及通知流程 | 事故演練 |
| G-QA-011 | 內容與素材 | 第三方圖片／音樂／字體來源 | 授權證據符合產品用途 | 法務／人工 |
| G-QA-012 | 遊玩價值 | 不同類型玩家完成核心循環 | 收集理解、困難、選擇及再玩意願 | 人類研究 |

這個矩陣應按遊戲功能改寫。對某些沒有 MOD 的小品，MOD 測試可能不適用；對使用真實網路或外部服務的作品，還需要另增負載與安全測試。測試數量不是目標，測試是否真的會在錯誤時失敗才是關鍵。

## 附錄 E．公開季度指標算例與反作弊檢查

### E.1 虛構數值，不代表實際產品或實測

假設一個示意季度：

- 期初核准工作權重總和為 **20 點**；
- 其中通過內部驗收的權重為 **15 點**；
- 其中實際進入可取得公開版本的權重為 **13 點**；
- 另有本季臨時完成的緊急事故修補，不計入原定基準的分子，但另行報告。

依第 13 節定義：

$$
PCR_q=\frac{15}{20}=0.75,
$$

$$
PDR_q=\frac{13}{20}=0.65.
$$

這兩個數字只表示：原定基準中 75% 權重完成驗收，65% 權重真正對外交付。它們沒有直接表示遊戲的「完成度 75%」、玩家有 65% 的滿意度，或公司品質及財務安全已達標。

### E.2 事前權重的重要性

如果公司在季度末把原定 20 點工作改成 15 點，並將 15 點全部算作完成，報告會突然變成 100%。這種做法抹除了原定範圍，無法協助外部了解計畫與現實的落差。本研究要求原目標總量保持可見，變更後的工作量另外列出；不得用新的分母覆蓋舊基準。

### E.3 缺乏驗證證據不能補成一個漂亮數字

假設 13 點已發布工作中，有 2 點尚缺乏規定的合格驗證證據，則依嚴格的 QVD 口徑，只有 11 點可被計入品質驗證交付量。此處將 13 點及 11 點分別報告，不將缺證視為「肯定有 Bug」，也不將它們算作「全部已驗證」。

若該季包含 P0 存檔損毀事故，報告需要另外呈現事故，不能藉由這三個數值中的任何一個自動宣稱品質合格。

### E.4 經濟指標的算例邊界

若某一可比較的研究工作集合有 11 個權重單位 QVD，相關完整配置成本假設為 11,000 個同一貨幣單位，則依簡化的管理性指標，CostPerQVD 為 1,000 貨幣單位／權重點。**這不等於一個功能的市場價值，也不表示同種指標能跨不同遊戲權重系統比較。**

## 附錄 F．研究執行前的預註冊清單

- [ ] 已定義研究主要因果問題，不在觀察結果後更換目標。
- [ ] 已定義工作類型、難度、成熟度、依賴與驗收條件。
- [ ] 已說明 A／B／C／D 條件中的工具、模型版本、資產與人員分工。
- [ ] 已處理 AI 工作結果對其他任務的資訊外溢與樣本選擇問題。
- [ ] 已保留人員活躍工時、日曆時間、模型資源與 CI 工作成本之區別。
- [ ] 已指定主要品質結果，包括 P0／P1 缺陷及存檔相容。
- [ ] 已指定真人 Playtest 對遊玩理解與體驗的觀察方法。
- [ ] 已明訂發布後觀察時間窗及尚未觀察完成的資料處置。
- [ ] 已明訂樣本數、分析單位、缺失資料、停止規則與效應大小報告方法。
- [ ] 已設定對外公開分級，確保不公開個資、憑證與未授權的原始資料。
- [ ] 已決定由誰審查研究報告，不讓 AI 自行產生未經核對的 PASS 聲明。
- [ ] 已允許結果顯示 AI 無效、較慢、較貴或品質較差。

## 附錄 G．一頁式季度可驗證交付證據包

```text
產品身份：［Product ID］
期初基準：［QuarterGoal ID、批准時間］
目前實際可取得的玩家版本：［平台、版號、Build ID、核對時間］
本季研究條件：［模型／工作流／資產條件摘要］
工作混合：［候選／修復／內容／維護／基礎設施比例］
候選生成：［數量、分類、已知缺失］
內部驗收：［數量、權重、證據摘要］
真正公開交付：［數量、權重、平台證據］
重大品質問題：［嚴重度、受影響玩家、已知處置］
資源用量：［API、配額、CI、人工、合同與必要成本］
玩家研究：［樣本來源、方法、觀察限制］
未完成與更動：［原目標、原因、修訂、授權］
公開資料邊界：［公開／匿名／限權／保密］
研究性結論：［支持／不支持／資料不足，不含過度外推］
後續期限語義：［目標／估計／承諾的清楚區分］
```

## 附錄 H．命題成熟度與來源支持矩陣

| 核心命題 | 本篇證據狀態 | 不能推論的結論 | 下一步 |
|---|---|---|---|
| AI 可在部分明確程式任務加速 | 外部受控實驗支持特定條件 | 所有遊戲、所有團隊都更快 | 以遊戲任務重新測量 |
| AI 在某些成熟專案可能減速 | 外部 RCT 支持特定條件 | AI 對全部軟體都無效 | 比較新模型、任務與審查成本 |
| DORA 強調組織系統及小批量工作 | 外部組織研究與能力文件 | 一套 QSPS 必然提高獲利 | 觀測交付與穩定性 |
| 額度增加可能提高 QVD | 理論條件命題，未直接驗證 | 額度越多一定越好 | 配額梯度／瓶頸實驗 |
| 資產複用可能縮短後續作品交付 | 理論與既有工程常識支持可能性 | 資產複用可以免費或無限 | 跨作品成本和相容性測試 |
| 3／6／12 個月產品制 | 工作假說與產品規劃 | 任何作品按此時間必可完工 | 多作品縱向實證 |
| QVD／PCR／PDR 指標 | 本篇提出的規範性測量方案 | 指標已被外部校準 | 專案試用、反作弊與校準 |
| 季度公開提高玩家信任 | 待驗證假說 | 透明越多必然越好 | 玩家理解實驗與成本估計 |
| Steam 可提供分支與持續更新 | Steamworks 官方文件 | Steam 的所有發布操作沒有前置條件 | 實際 Steamworks 操作與條款複核 |
| AI 代理可接續他人遊戲開發 | 技術上有值得研究的可行路徑 | 任意接手者都有權且能維護 | ANIE-03 實際交接試驗 |

---

## 參考文獻與可查來源

### A．AI 生產力、軟體交付與玩家研究

**[E01]** Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M.（2023）. *The Impact of AI on Developer Productivity: Evidence from GitHub Copilot*. Microsoft Research / arXiv. 受控 HTTP Server 實作任務中報告約 55.8% 完成時間加速；不可作為整個遊戲開發週期的倍數。  
https://www.microsoft.com/en-us/research/publication/the-impact-of-ai-on-developer-productivity-evidence-from-github-copilot/  
https://arxiv.org/abs/2302.06590

**[E02]** Becker, J., Rush, N., Barnes, E., & Rein, D.（2025）. *Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity*. METR / arXiv:2507.09089. 16 位開源開發者、246 項任務的 RCT，特定成熟專案情境下 AI 使用組平均增加約 19% 工作時間。  
https://arxiv.org/abs/2507.09089  
https://metr.org/Early_2025_AI_Experienced_OS_Devs_Study-paper.pdf

**[E03]** METR（2026-02-24）. *We are Changing our Developer Productivity Experiment Design*. 關於後續測量的參與者選擇偏誤、多代理併行工時計量困難，以及加速估計不確定性的研究說明。  
https://metr.org/blog/2026-02-24-uplift-update/

**[E04]** DORA / Google（2025）. *State of AI-assisted Software Development 2025*. AI 採用與組織能力的研究，指出 AI 常放大既有工作流的優勢與問題；應區分調查、組織關聯與特定任務的因果實驗。  
https://dora.dev/research/2025/dora-report/  
https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/

**[E05]** DORA. *Working in Small Batches*. AI 與小批量工作、驗證、回饋速度和產品價值流的關係；查核日期 2026-10-16。  
https://dora.dev/capabilities/working-in-small-batches/

**[E06]** DORA. *Continuous Integration*. 小規模變更、共享主幹、建置／測試、自動化回歸及交付穩定性；查核日期 2026-10-16。  
https://dora.dev/capabilities/continuous-integration/

**[E07]** Drachen, A., Mirza-Babaei, P., & Nacke, L. E.（eds.）（2018）. *Games User Research*. Oxford University Press. 包含遊戲使用者研究、玩法理解、試玩與設計回饋方法。  
https://academic.oup.com/book/26677  
相關章節：*A framework for player research*，https://academic.oup.com/book/26677/chapter-abstract/195455905

**[E08]** GitHub Docs. *GitHub Actions billing*. 公開／私有 repository、runner 執行及儲存的不同計量；此處引用原則而非一份固定且永久不變的價格表。查核日期 2026-10-16。  
https://docs.github.com/en/billing/concepts/product-billing/github-actions

**[E09]** DORA. *Test Automation*. 由建置、驗收、非功能測試、人工探索到可發行狀態的不同步驟。查核日期 2026-10-16。  
https://dora.dev/capabilities/test-automation/

### B．遊戲發布與建置技術

**[E10]** Valve. *Steamworks Documentation — Updating Your Game: Best Practices*. Steam 持續修補、內容更新、官方下載、Beta 分支與更新公告；查核日期 2026-10-16。  
https://partner.steamgames.com/doc/store/updates

**[E11]** Valve. *Steamworks Documentation — Uploading to Steam*；*Branches (Betas)*. SteamPipe、建置分支、測試與回退的官方機制；查核日期 2026-10-16。  
https://partner.steamgames.com/doc/sdk/uploading  
https://partner.steamgames.com/doc/store/application/branches

**[E12]** Godot Engine Documentation. *Command line tutorial*. `--headless`、命令列建置與 CI 情境；應依實際引擎版本核對指令和匯出設定。查核日期 2026-10-16。  
https://docs.godotengine.org/en/stable/tutorials/editor/command_line_tutorial.html

**[E13]** Valve. *Steamworks Documentation — Early Access*. 本篇沿用 ANIE-01 對商品現況與未來承諾的界線；查核日期 2026-10-16。  
https://partner.steamgames.com/doc/store/earlyaccess

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

下列文件為研究前作與內部概念來源，不應自動被視為已通過獨立實證、已對外公開或已在商品化環境部署。

**[I00]** Neo.K × GPT-6（2026-10-16）。《從產品黑盒到 AI 原生互動企業》，《AI 原生互動企業論》ANIE-00，v0.1，UTF-8 Markdown 公開工作論文。

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

**[I02]** Neo.K（2026-09-07）。《從意圖到決策：AI 原生決策編譯器與稀疏意圖治理》，《AI 原生決策治理與認知資本》系列，v0.1。  
https://unboundedaxiom.org/p/lm-004090/

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

**[I04]** Neo.K（2026-07-23）。《AI 原生企業潛在生產能力與可融資性評估框架》，v0.1。  
https://unboundedaxiom.org/p/lm-001728/

**[I05]** EveMissLab（2026-09-01）。《SEDB-GAME × ModWorld：AI 原生遊戲理解與 MOD 共創 Runtime 技術白皮書》，v0.1。  

**[I06]** EveMissLab（2026-09-21）。《供應商與平台責任：AI Coding Tool 的 Publication-Boundary Governance》，《AI Agent 公開邊界與安全閉包研究》，v0.1。  

**[I07]** Neo.K × Aletheia（2026-08-01）。《企業母 AI：公司作為 AI 的可觀察世界》，v0.1。  
https://unboundedaxiom.org/p/lm-002360/

---

## 文件完整性、局限與正式原稿宣告

- **研究性質：** 本篇為原創概念與方法框架的工作論文，不是完成的實證研究，未經同儕審查；其中 QSPS、QVD、PCR、PDR 及成本／資源模型屬提出的研究規格，尚待校準。
- **事實來源：** 外部文獻提供特定研究條件下的觀測或官方技術能力；本文不以軟體編輯器實驗直接推論全部遊戲開發，也不聲稱平台條款會因 AI 普及自動改變。
- **示例責任：** 三個月／半年／一年案例、60 與 53 工時、20 點／15 點／13 點及 JSON 都是明確標示的假設性示例，不是 EveMissLab 遊戲上市、營運與驗證成果。
- **可反駁性：** 若未來對照研究發現 AI 額度增加造成整體產能下降、品質風險增加，或季度制度不具實務價值，應據實修正甚至收斂本篇理論適用範圍。
- **正式來源：** 本 UTF-8 Markdown 檔是 canonical source；聊天渲染不是正式原稿。數學僅使用 ` $...$ ` 和 `$$...$$` 作為定界符，不以 Unicode 公式反向重建原始碼，不以渲染畫面複製所得取代原檔。
- **版本治理：** 後續版本應保留前稿、來源查核、變更理由、公式／連結驗證與必要的資料更正，不因新敘事較漂亮而覆寫先前不利證據。