---
title: "從 EA 到持續交付：DEMO、Playtest、搶先體驗與正式版的重新分工"
english_title: "From Early Access to Continuous Delivery: Reorganizing Demos, Playtests, Early Access, and Full Release"
series: "AI 原生互動企業論"
series_en: "AI-Native Interactive Enterprise"
series_id: "ANIE"
paper: "01"
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: "This UTF-8 Markdown is the canonical manuscript; rendered chat is non-canonical."
related_papers:
  - "ANIE-00｜從產品黑盒到 AI 原生互動企業"
  - "ANIE-02｜季度單機產品制（預定）"
  - "ANIE-03｜可繼承的遊戲產品（預定）"
keywords:
  - "Early Access"
  - "Steam Playtest"
  - "Game Demo"
  - "Full Release"
  - "Continuous Delivery"
  - "AI-Native Game Production"
  - "Verifiable Delivery"
  - "Release Readiness"
  - "Quarterly Product Cycle"
  - "Commitment Semantics"
---

# 從 EA 到持續交付

## DEMO、Playtest、搶先體驗與正式版的重新分工

**From Early Access to Continuous Delivery: Reorganizing Demos, Playtests, Early Access, and Full Release**

**《AI 原生互動企業論》（ANIE）第 01 篇｜第一部：可驗證的 AI 原生產品交付**  
**作者：Neo.K｜一言諾科技有限公司（EveMissLab）**  
**版本：v0.1｜日期：2026-10-16**  
**公開工作論文；本篇提出制度模型與可檢驗假說，非同儕審查研究成果**

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

---

## 摘要

數位遊戲的開發與發行通常被描述為一條階段路徑：原型、展示版本（DEMO）、公開測試、搶先體驗（Early Access, EA）、正式版及後續維護。然而，這條路徑容易將原本不同性質的制度混淆：DEMO 偏重讓玩家評估實際體驗，Playtest 偏重取得測試資料，EA 涉及未完成但具有現有價值之可付費產品，正式版則表示產品已達開發者對其完整性與商業發行的特定標準。上述選項在現行 Steamworks 機制中並非一套強制順序，亦不應以開發歷時長短直接決定。[S01]–[S04]

當 AI 輔助程式開發、Agent 協作、可重複使用資產、持續整合、自動化測試與數位發行能力逐步成熟後，部分遊戲的開發與修補成本可能下降；但 AI 生成候選的數量，不等於遊戲功能已整合、可玩、通過驗收、符合授權條件或具有商業價值。現有實證亦顯示，AI 對軟體工作流程的影響存在情境差異，無法僅憑額度或模型能力推定必然提高總交付率。[S10][S11] 因此，本研究不宣稱 EA 已過時，而提出：**應將平台發行階段，與可驗證的產品交付制度解耦**。

本文建立「發行狀態—交付成熟度—承諾強度—外部參與—資金依賴」的多軸模型，提出「非強制線性發行圖」「當前價值優先原則」「品質閘門式階段選擇」「週／月／季不同公開時間尺度」「交付證據包」「延期與取消的可修正承諾程序」，以及短週期、中週期、長週期單機遊戲三種示例路線。季度交付被定義為可追蹤的規劃與驗收尺度，不表示每款遊戲均應在三個月完工，也不代表每季必須無視品質風險推出重大更新。

本篇承接 ANIE-00 的「意見—決策—交付—驗證—回應」架構，但將焦點限定於：一款數位遊戲在什麼條件下應公開測試、何時適合收費 EA、何時應直接正式推出，及如何藉由公開且可核對的交付紀錄，使玩家了解自己正在購買什麼，而不是僅根據未來宣傳評估商品。文末提出可反駁假說、實證研究設計及適用於獨立工作室的最小實作規範。

**關鍵詞：** 搶先體驗；Steam Playtest；DEMO；正式版；AI 工業化；季度單機產品制；可驗證交付；承諾治理；發行狀態機；玩家參與。

---

## 0．研究定位、界線與原始命題

### 0.1 要回答的問題

本研究要回答的不是「EA 是不是應該被禁止」，而是以下五個問題：

1. **制度問題：** DEMO、Playtest、EA、正式版各自提供何種不同的權利、經濟與資訊功能？為何不應將其強行排列成唯一發行路徑？
2. **生產問題：** 當 AI 與可繼承數位資產增加開發選項時，哪些作品適合更快直接達到正式版，哪些作品仍需要較長時間的外部共同測試？
3. **承諾問題：** 開發者如何公開季度目標與交付結果，而不把未驗證的願景包裝成對付費玩家的確定承諾？
4. **證據問題：** 如何讓外部觀察者區分「展示影片存在」「遊戲建置存在」「玩家可下載」「特定功能已通過驗收」「實際體驗足以支持商品描述」？
5. **延伸問題：** 如果同一個可驗證交付制度可跨越 EA 與正式版，是否有可能讓它成為遊戲品牌長期的生產與信任基礎？

本文的關鍵主張：

> EA 應保留其「未完成但已具現有價值、且需要玩家參與完成開發」的功能；但企業的可驗證交付、資訊回應與後續維護，不應被 EA 標籤所限制。遊戲是否進入 EA，應由作品實際狀態、商業需求與測試目的決定，而非把 EA 當成一切遊戲開發的預設階段。

### 0.2 明確不主張什麼

本篇**不主張**：

- 2026 年的 Steam 平台已經因 AI 發展修改 EA、DEMO 或 Playtest 的正式規則。
- 開發者只要增加 AI 額度，就能保證在三個月、半年或一年完成任何預定規模的作品。
- 發行速度、修補頻率或 Git commit 數必然等於玩家價值。
- 所有遊戲都應有 EA；所有遊戲都應拒絕 EA；所有遊戲都應有 DEMO。
- 玩家投票可以取代公司合法的產品與商業決策。
- 收集玩家資訊可以無條件蒐集個資，或免除平台、消費者保護與隱私義務。
- 公司的公開季度目標可以凌駕既有商店描述、購買條件、法律或具體合約。
- 只要貼出開發日誌就足以證明遊戲能夠持續維護。

### 0.3 研究對象與假設邊界

主要觀察對象為 PC 平台的商業單機遊戲，特別包括文字／GUI 驅動的世界模擬、小型策略遊戲、具 MOD 可能性的沙盒遊戲，以及可用 AI 產線加速內容製作的作品。本文不直接外推至網路伺服器經營、持續服務型遊戲、大型多人對戰、受監管的博彩產品或主機平台認證；這些產品可能具有不同的內容發布與安全要求。

本篇採取「制度分析 + 可操作化模型 + 未來實驗方案」的研究設計。尚無對 EveMissLab 未來遊戲產品線完成本篇模型的正式實證，因此對生產力與玩家信任的因果宣稱均保持待驗證狀態。

## 1．傳統 EA 的實際功能：先釐清制度，而不是批評標籤

### 1.1 Steam EA 的正式定義

依 Steamworks 官方文件，Early Access 允許仍處於開發中、已可玩的遊戲在 Steam 上販售。核心不是先收錢再給產品，而是**玩家付款當下即可取得具有現有價值的遊戲**，並知悉它仍屬未完成狀態；官方同時將與社群共同改善遊戲視為 EA 的主要意義。[S01]

這項機制包含至少四項可區分功能：

- **提前供給：** 商品尚未達到開發者定義的最終完整度，仍可合法合規地讓玩家使用當下版本。
- **資訊提示：** 對玩家明示內容尚未完成，並列出實際現狀與預期方向。
- **意見取得：** 真實使用者可以在長期遊玩與真實購買情境中提出問題與需求。
- **商業交易：** 開發者因既有產品取得收入，但收入不能作為保證完成未來功能的替代品。

這些功能不等同於「遊戲爛也可以先賣」，更不等同於「只要開發者承諾未來會做，今天的商品可以沒有價值」。

### 1.2 EA 是收費商品，不是群眾募資保證

Steamworks 明確提醒，EA 不是主要依賴售出一定數量來完成開發的群眾募資工具，也不是單純預購。開發者應認真評估：假設銷售不如預期，還有沒有能力繼續開發？[S01]

本研究承認小型工作室可能確實透過 EA 取得初期資金，且當下收入可以改善現金流。然而，**實際具有資金效果**與**可以把尚未完成的未來版本當作收費對價**是兩件不同的事。資金不是研究禁忌，資金依賴度才是需被揭示與治理的變數。

若公司原本有其他營收產品，可能減少單一 EA 遊戲對當期銷售量的依賴；相反，若其他業務也需要大量現金與時間，遊戲便可能遭到跨專案資源排擠。公司多元業務本身既不構成品質保證，也不自動形成風險防火牆。

### 1.3 「舊時代 EA」與「新時代 EA」的可比較之處

傳統 EA 所處理的根本不確定性包括：遊戲是否有趣、系統是否可擴充、玩家願意接受什麼內容、開發者能否長期維護，以及未來收入是否足以負擔後續成本。AI 可能減少部分製作成本，卻無法直接消除這些不確定性。

因此，時代變化更精確的表述應是：

> 某些傳統上被視為難以降低的開發與互動成本，現在可以重新量測；在成本結構變化的條件下，EA 的必要性與最適進入時點可能改變，而玩家對更新頻率與資訊揭露的合理期待，也可能隨市場上可觀察的交付能力重新形成。

這是**比較制度與產能**的研究命題，並不是宣稱所有開發者已經具備相同的 AI 生產能力。

## 2．DEMO、Playtest、EA、正式版：四種不同的產品契約

### 2.1 選項比較，不把「早期」一概而論

| 比較維度 | DEMO | Steam Playtest | Steam EA | 正式版 |
|---|---|---|---|---|
| 主要目的 | 讓玩家體驗代表性內容、形成購買判斷 | 以控制人數或測試窗口取得可用資料 | 銷售仍在開發中的可玩商品並持續改進 | 提供達到產品完整性標準的商品 |
| 玩家支付 | 通常免費 | 免費，官方禁止販售測試資格 | 收費，須有購買當下的可玩價值 | 可以收費或免費 |
| 核心資訊 | 此 DEMO 可玩的內容與限制 | 測試目標、限制、資料用途 | 現況、未完成事項、計畫與風險 | 目前實際具備的產品功能與支持範圍 |
| 可取得性 | 可持續、限時或依策略調整 | 可控制參加名額及可玩狀態 | 一般為公開可購買的現有版本 | 正式對外發行 |
| 與社群關係 | 展示及部分回饋 | 定向測試與回饋 | 持續體驗、玩家影響開發方向 | 正式使用、維護、更新與擴充 |
| 主要風險 | 試玩內容失真、誤導購買期待 | 樣本偏誤、測試外洩及隱私 | 過度承諾、現有商品品質不足、資金依賴 | 正式品質未達標、上市缺陷及維護風險 |

資料來源與範圍：Steamworks 官方 DEMO、Playtest、EA 與 Release Options 文件。[S01]–[S04] 表中的「主要目的」是本研究的功能分類，不是平台對所有作品的強制定義。

### 2.2 DEMO：當前體驗的樣本，不是未來成果的支票

Steam 的 DEMO 通常是免費且可玩的產品片段，可能在正式發行前或後上線。Valve 官方提醒開發者注意 DEMO 的品質、時機及長度；官方並未要求每款遊戲都應提早放出 DEMO。[S03]

從 ANIE 的角度，DEMO 應回答三個問題：

1. 玩家是否可以從 DEMO 理解產品的主要互動循環，而非只看到視覺素材？
2. DEMO 所示玩法是否確實存在於可交付的建置版本，而不只是影片中的未完成原型？
3. 玩家若因 DEMO 決定購買，正式商品是否與其形成合理一致的體驗預期？

DEMO 可以高度精簡，但不能利用未實裝系統製造已具備功能的錯誤印象。對世界狀態機與文字／GUI 型作品而言，完整但精煉的一小段時間、地圖或角色經營循環，可能比展示大量無法實際互動的功能選單更有證據價值。

### 2.3 Playtest：測試工具，不是比較便宜的 EA

Steam Playtest 以與主遊戲相關但獨立的 App ID 運作，提供免費報名、控制測試人數、隨時調整可玩狀態等能力；其運作不等同 EA 商業銷售，且不能銷售 Playtest 參與資格。[S02]

適合的研究問題包括：

- 玩家能否理解首次操作導引？
- NPC 世界行為在長時間推進時是否出現異常？
- 高階技能組合是否存在可重現的破壞性玩法？
- 存檔格式跨測試版本是否穩定？
- 遊戲循環是否具備重玩價值，以及哪些人群感到挫折？

測試資料的蒐集應以明確目的、必要範圍及合法權限為前提。測試者對產品的意見可能不具市場代表性；某些被邀請的高投入玩家，對複雜度與難度的偏好可能與一般消費者不同。

### 2.4 EA：未完成狀態本身的可銷售價值

EA 是否合理，不取決於「做了多少百分比」，而取決於購買當下的版本是否已提供足夠、可描述、可持續遊玩的實際價值；仍有重要內容待完成，且持續與玩家互動能實質影響後續開發。[S01]

因此，單機世界模擬遊戲即使尚未具備全部地圖或完整劇情，只要核心世界循環、存檔、可玩目標和當下價值足夠，可能適合 EA。反過來，如果只剩最後的小型錯誤排除、功能設計已全部固定，而不需要玩家長期改變其設計，Steam 官方明確提示這種情況不一定適合 EA。[S01]

### 2.5 正式版：完成的是承諾範圍，不是停止演化

正式版應被理解為：開發者已根據對外描述、核心玩法、支援平台、品質、完整性與必要維護條件，判定產品適合以正式商品上市。這個判斷具有可被購買者評價的性質。

正式版不等於從此不能加入地圖、MOD API、玩法擴張、免費內容、付費 DLC 或品質修復。Steam 官方長期支持正式發售後持續更新，並提供相應版本與新聞工具。[S07]

因此：

> 發行制度的重大轉變，不是取消「正式版」概念，而是讓正式版與可持續交付同時成立。單機產品可以有可獨立完成的核心遊戲，也可以有長期更新的生命週期，兩者並不矛盾。

## 3．線性發行神話：產品階段不是必走的階梯

### 3.1 四種狀態具有不同的語義座標

以 $\mathcal R$ 表示對外測試與發行策略集合：

$$
\mathcal R = \{Demo, Playtest, EA, FullRelease, PostRelease\}.
$$

此集合不表示互斥的時間點，也不要求形成總序關係。DEMO 可以在正式版前後存在；Playtest 可以與 DEMO 的準備時間重疊；正式版之後仍然可以經由版本更新與受控測試分支進行實驗。[S02][S03][S07]

為避免將商店欄位與工程狀態混同，定義：

$$
X_t=(M_t,A_t,U_t,C_t,F_t),
$$

其中：

- $M_t$：產品實際成熟度，包括玩法完整度、品質、相容性與內容可用性；
- $A_t$：可取得及測試方式，包括免費公開、限量測試及正式購買；
- $U_t$：玩家意見對未來核心設計的預期作用程度；
- $C_t$：公開承諾及當前商品描述的狀態；
- $F_t$：產品維護與後續開發的資金依賴情形。

同一個 $X_t$ 對應哪個最適發行策略，應透過限制條件與效用／風險比較決定，而不是僅看開發開始後經過了多少天。

### 3.2 非強制發行圖

下圖為可用策略的研究性抽象，不等於 Steamworks UI 操作指南：

```text
                       ┌─────────────┐
                       │ 內部原型／QA │
                       └──────┬──────┘
                              │
                 ┌────────────┼────────────┐
                 v            v            v
              公開 DEMO     Steam Playtest   其他受控測試
                 │            │            │
                 └────────────┼────────────┘
                              │
                       可玩性與市場證據
                              │
                 ┌────────────┴─────────────┐
                 v                          v
         完整商品品質已達標           仍有實質開發工作
                 │                          │
                 v                    當前版本是否值得買？
             正式發售                      /       \
                 │                       否        是
                 v                       │         │
          持續修補與擴充             返回測試／開發   EA（可選）
                 │                                 │
                 └──────────持續交付───────────────┘
```

這張圖最重要的含義有二。第一，**EA 是可選路徑，不是每個遊戲都必須經過的關卡**。第二，正式上市後仍存在開發與回饋，不會因進入 1.0 就停止。

### 3.3 同時存在的不是「兩份產品真相」

遊戲可能同時有內部 `dev` 版本、測試分支、公開 DEMO 與正式銷售版本。若每個版本宣稱內容不同，容易產生誤解。本研究要求以建置識別碼與對外說明標示實際可玩的狀態：

$$
CurrentOffer_t \neq InternalCandidate_t.
$$

內部測試成功的內容，不能自動被寫成已經在 Steam 公開分支交付；即使「即將推出」，也應標為計畫或候選，而非當下可買的功能。

## 4．當前價值優先原則：購買行為的資訊底線

### 4.1 當前商品價值與未來期待必須分開

令 $V_{now}(g,t)$ 表示玩家類型 $g$ 在時間 $t$ 可實際取得版本的體驗價值； $E_{future}(g,t)$ 表示對未來版本的期待。研究中不預設存在可客觀計算的單一價值尺度，僅要求從行為與問卷分別測量。

$$
V_{now}(g,t) \neq E_{future}(g,t).
$$

在 EA 情境中，玩家可以同時期待後續更新，但不能因此讓開發者忽略當前版本已交付的價值。具體商品描述應回答：遊戲目前有什麼、沒有什麼、哪些版本可以取得、主要限制是什麼。

### 4.2 三種不可互相替代的「完成」

- **工程完成（Engineering Complete）：** 可建置、可啟動、測試通過所定義的工程品質門檻。
- **產品完成（Product Complete）：** 核心玩法與內容達到公開產品承諾範圍，品質與體驗在合理目標群內可接受。
- **交易完成（Commercial Release）：** 已通過平台發布條件、完成必要商店資訊與授權檢查，玩家能依標示條件取得商品。

一款遊戲可以先具備工程完成，卻還不能賣；也可能先透過 EA 成為商品，尚未具備完整 1.0 內容。二者並不矛盾，前提是資訊真實且符合平台規則。

### 4.3 不用單純的「完成百分比」掩蓋高風險缺口

遊戲的一千項小功能完成 990 項，若剩下十項包括存檔可靠性、操作無障礙、購買頁承諾的核心玩法或重大安全缺陷，就不能稱作「99% 已可放心發售」。

因此，完成度應是多維度的品質判斷，而非功能清單數量的平均。後文以不同發布閘門處理此問題。


## 5．發行路徑選擇：品質閘門而不是日曆倒數

### 5.1 六種獨立的發行準備度

對一款遊戲定義其準備向量：

$$
G_t=(g_{play},g_{quality},g_{content},g_{rights},g_{operations},g_{market}).
$$

這六項分別是：

1. **玩法準備度 $g_{play}$：** 核心循環已能由陌生測試者獨立體驗；勝負、成長或探索目標有可理解的反饋，不能只有概念畫面。
2. **品質準備度 $g_{quality}$：** 不存在發行前定義的不可接受崩潰、資料毀損、主要無法操作、長期運行不穩定等阻斷性問題；可靠性達到適用產品的測試標準。
3. **內容準備度 $g_{content}$：** 遊戲已提供與階段及價格相稱的可用內容，並與商店描述一致。
4. **權利準備度 $g_{rights}$：** 遊戲本體、第三方素材、聲音、字型、程式庫與 AI 輔助製作內容已具備可商業使用的必要權利；其餘尚待處理的內容不得違規上線。
5. **營運準備度 $g_{operations}$：** 建置、上傳、回退、客服、支援平台、備份、公告與事故處理具最低能力。
6. **市場資訊準備度 $g_{market}$：** 用戶能準確理解現在買到的內容、限制、開發狀態及後續不確定性。

本研究不將六維壓縮成單一 0–100 分的總數。尤其法規、授權與重大安全問題具有**阻斷性**，不能以其他四個維度優秀來抵消。

### 5.2 發行阻斷條件

建議將最小品質閘門分為三層：

| 閘門 | 代表情境 | 預設處理 |
|---|---|---|
| P0：不可接受 | 主流程無法啟動、存檔大規模損壞、違法素材、可造成顯著風險的安全漏洞 | 不公開發售；先修復或排除 |
| P1：需要明確處理 | 常見場景崩潰、嚴重效能退化、關鍵說明錯誤、重大相容問題 | 視影響決定阻斷／限縮測試、發布特別警示 |
| P2：可納入持續改善 | 非關鍵排版、邊緣玩法平衡、罕見視覺錯誤、可迴避的輕微問題 | 記錄已知問題、安排修復與回歸測試 |

此表是**建議的內部風險分類**，不是 Steam 的官方法定缺陷分級。P0、P1、P2 的具體閾值須依作品類型、玩家族群和實際傷害重新校準。某些無障礙問題或少數使用者受影響的資料損毀，仍可能構成最高級別，而不應依票數降低優先級。

### 5.3 EA 進入條件：可玩、可買、可參與、可持續

本研究建議 EA 至少同時回答四個肯定問題：

**可玩**：遊戲的代表性核心系統現在能被真實玩家完整操作，而不是只看到尚未可互動的片段。  
**可買**：當前版本具有與定價及商品說明相符的現有價值，而不是要求玩家預支對未來內容的信任。  
**可參與**：玩家回饋確實可能影響內容、平衡、系統或其他具有實質意義的後續工作。  
**可持續**：即使未來銷售明顯低於預期，開發者仍有一套可說明的縮減、延續或重新決策安排，不把必須達成某個銷量當成隱藏的完成先決條件。

最後一項並不保證企業不會失敗，而是禁止開發者把未經檢驗的樂觀假設誤當作可持續性證據。當可持續性不足時，應先控制承諾範圍、進行免費測試或重新評估發行策略。

### 5.4 正式版進入條件：不依賴未來更新才能成為作品

建議 1.0 至少符合：核心玩法封閉且可完整體驗、商店宣稱的功能均已存在、主要性能與穩定性通過驗收、關鍵使用者資料具恢復與相容策略，以及已有售後修補與支援流程。

這不代表遊戲需要涵蓋所有開發者想像過的內容。**正式版完成的是可銷售且可被合理評價的核心產品，而不是開發者一生所有可能新增的功能。**

假設某款小型戰術遊戲具備完整一輪戰役、存檔、平衡、遊戲設定、音效與美術一致性，並經過外部測試，它可以不經 EA 直接上市。反過來，一款大型世界模擬遊戲即便已經有許多系統，也可能因核心循環、社群互動及後續設計尚有重要不確定性而合理進入 EA。

### 5.5 不要把「發行階段」當作「品質等級」

Playtest 的內容可能非常成熟，但仍需要針對某項操作流程測試；EA 的既有內容可能已經相當完整，只是大型系統尚未全部加入；1.0 遊戲也可能存在需快速修復的缺陷。這些都不構成概念矛盾。

換言之，

$$
ReleaseLabel_t \not\Rightarrow QualityRank_t.
$$

「DEMO」「EA」「1.0」是外部交易與使用情境的分類，並不能替代具體品質證據。

## 6．三種產品規模與不同的發行策略

### 6.1 A 類：短週期完整單機作品

**示意規模：** 可能以數個月為目標的文字／GUI 遊戲、小型策略遊戲、獨立玩法小品，已大量重用測試工具、渲染能力或世界狀態機基礎。

**候選路徑：** 內部原型 → 外部限量測試／Playtest → 可選 DEMO → 直接正式版 → 季度維護與小幅擴充。

此類作品若已可在短期內完成核心玩法，投入 EA 的溝通、價格管理和對外承諾成本可能高於它所帶來的設計收益。公司並不需要為了呈現「仍在開發」而把原本可完成的商品刻意延後到 EA。

**反例：** 如果小品的唯一賣點是一種完全未驗證的複雜互動機制，即使程式碼能在三個月寫完，仍可能需要較長 Playtest 而不適合倉促正式發售。

### 6.2 B 類：中週期、內容可以逐步擴張的作品

**示意規模：** 半年左右的研究性產品目標；具有多種職業、地圖、事件與系統耦合，但完整基本遊戲可以先以合理範圍交付。

**候選路徑：** 內部原型 → Playtest → DEMO → 視情況 EA 或直接正式版。

重要分界是：在預定正式發行時間之前，是否仍有**玩家實際參與才能有效驗證或重設的核心問題**。若只是需要把同一個已確立玩法增加十倍內容，而製作流程已成熟，EA 未必比正式版後更新更有制度優勢。

**反例：** 若玩家回饋顯示整個核心遊戲循環尚未成立，不能只依既定季度行程強行進入 EA 銷售，應縮回測試與設計階段。

### 6.3 C 類：長週期世界模擬、沙盒及大型共創作品

**示意規模：** 一年或更長的目標；包含持續互動世界、多模組耦合、複雜 NPC、生態經濟、MOD、長時間存檔與大量路徑可能性。

**候選路徑：** 內部／邀請制測試 → DEMO／Playtest → 當核心循環已有現有價值時進入 EA → 透過季度版本增加與修正系統 → 通過 1.0 完整性門檻 → 長期更新。

這類作品可能有較高的社群共創價值，但也有較大的存檔破壞、模組衝突、技術債和交付期限風險。單純提高更新速度，未必能縮短系統穩定所需的測試時間。

**反例：** 即使進入 EA 後意外取得大量銷售，也不能以成長中的收入作為對既有玩家無限延後主要功能的合理化理由；應維持可核對的現況、修正紀錄與範圍管理。

### 6.4 三個月、半年、一年是產品假說，不是物理常數

上述時間只是研究者希望驗證的生產類別，必須依資產複用程度、AI 模型能力、審核工時、遊戲複雜度、用戶體驗及發行條件調整。未來 ANIE-02 將針對完整週期的有效產能建立更細的估計框架。

本篇先確立一項否證底線：若某款作品未能在原定季度達到品質閘門，應記錄該季度目標未完成，**不能透過降低驗收標準或重新命名為 EA，使未完成的工作在統計上被計作完成。**

## 7．持續交付不是持續上傳：時間尺度的重新組織

### 7.1 開發節奏、發布節奏與溝通節奏要分離

傳統「每週更新」說法往往混淆三件事：

- **工程整合節奏：** 程式碼、素材、測試及資產多久被內部合併一次。
- **公開可玩交付節奏：** 玩家多久取得具有可驗證差異的新建置版本。
- **進度與決策溝通節奏：** 玩家多久得到準確的現況、限制、延期理由及回饋處置。

三者不能強制相等。遊戲可能每天進行程式合併，每兩週有內部候選版本，每月發布一個可玩更新，每季作一次里程碑驗收；也可能因重大存檔格式變更而延長公開更新間隔，但仍每兩週發布有意義的進度說明。

### 7.2 建議的多尺度制度

| 尺度 | 核心目的 | 建議對外輸出 | 不可替代之事 |
|---|---|---|---|
| 每週或每兩週 | 追蹤短期變動與風險 | 已修復事項、實際阻礙、正在驗證的候選內容 | 不要求每次都有正式新建置 |
| 每月 | 聚合回饋與品質結果 | 缺陷趨勢、主要玩家意見、採納／拒絕／延後、可取得版本 | 不用提交紀錄數取代可玩價值 |
| 每季 | 驗證主要里程碑 | 本季目標對照表、實際交付、未完成原因、下一季可行範圍 | 不以宣傳影片取代正式驗收 |
| 每半年 | 評估維護與架構健康 | 相容性、重大重構、缺陷逃逸、技術債與支援負擔 | 不把補丁頻率當成品質 |
| 每年 | 檢查產品線及商業可持續性 | 長期版本、玩家與收入結構、成本及信譽證據摘要 | 不只挑選成功版本而隱去失敗紀錄 |

這不是「所有公司必須固定發布五套長篇報告」。對小型團隊而言，可以由同一個事件帳本產生不同時間尺度的受控摘要；若當期沒有達到需要公告的規模，也可在固定時間提供簡短、具體而可查核的說明。

### 7.3 季度作為公開驗收窗口

令一季開始前被確定列入比較基準的候選目標集合為 $P_q$ ；每個目標有固定範圍、品質驗收條件、預計窗口及責任歸屬。令 $A_q$ 為季末完成且通過驗收的目標集合。

最簡單且不可被隨意美化的實際達成率為：

$$
R_q=\frac{|A_q\cap P_q|}{|P_q|},\qquad |P_q|>0.
$$

此比例是**目標項目達成率**，不是勞動生產率，也不會反映各項目所需複雜度。因此必須與各目標的範圍、重大程度、成本、缺陷及玩家價值一起公布；不可拆成許多小目標灌高比率。

取消、縮減和移至下一季的目標不得默默從原始 $P_q$ 刪除。可以重新規劃，但應保存原目標與變更決策的歷史。若 $P_q$ 為空，該季度不應填寫 100% 達成率，而應標記「無預先登記目標／不適用」。

### 7.4 季度報告的最低真實性要求

每季至少區分：

1. **已可玩交付：** 玩家可以下載的版本、具體功能與驗證證據。
2. **已完成內部驗證但尚未發布：** 內部可以重現，但不能宣稱玩家已經取得。
3. **進行中：** 尚未通過目標品質閘門。
4. **未完成／延期：** 明確揭露與原定目標的差距。
5. **取消：** 決策理由、已投入工作和對玩家期待的影響。
6. **玩家意見的處置：** 接受、拒絕、選配、進一步研究或沒有足夠證據。

若只是維護存檔相容、修復重大漏洞或清理基礎技術債，仍然可能是優秀的一季；但應如實說明「品質與維護交付」，而不是擅自改寫成新玩法發布。

### 7.5 重大事故不能等待季度結束

定期報告是一種可觀察制度，不應成為事故處理的延遲藉口。存檔遺失、重大安全問題、顯著付款錯誤或大規模不可玩，需依實際風險建立事件驅動的額外公告與修復流程；必要時可暫停發布、回退分支或限制受影響功能。

因此：**固定季度節奏負責承諾與總結；不固定的事故與修復節奏負責及時安全處置。**

## 8．承諾語義：公開更多目標，不等於畫更大的餅

### 8.1 公開產品目標的五種語義

建議將任何對外功能敘述標記為下列之一：

| 等級 | 公開語義 | 可接受說法 | 不能誤導成 |
|---|---|---|---|
| L0 | 願景／探索 | 「我們正在研究此方向」 | 「一定會推出」 |
| L1 | 候選／評估 | 「已納入評估，尚無排程」 | 「已開始開發」 |
| L2 | 計畫／季度目標 | 「目前以本季完成為目標，視測試結果調整」 | 「本季保證有」 |
| L3 | 經正式授權的具體安排 | 「此範圍已經內部批准，後續以最新公告為準」 | 「任何條件下都不會改變」 |
| L4 | 已交付／有證據 | 「某版本已提供此功能，附建置與測試證據」 | 「已經沒有任何缺陷」 |

此處 L3 仍不是當然的法律上無條件保證；具體商店宣傳、契約與消費者規範仍須個別判斷。L4 僅表示經過所揭露的驗證範圍，不能保證所有硬體、環境與玩法下永遠正確。

### 8.2 狀態轉移不能由 AI 語言自行決定

AI 可以將開發者會議、Issue、測試及玩家回饋整理成文字，但不能因「看起來可行」就把 L1 自動升級為 L3，也不能因程式碼存在就把 L2 寫成 L4。

$$
EvidenceAvailable \neq AuthorityToPromise.
$$

一項宣稱已發布的功能，需由發布紀錄及相關測試支持；一項正式承諾，需符合公司內部授權及外部適用規則。公開承諾的權限與日常公告草擬權限應分離。

### 8.3 延期應被理解為可以受到檢驗的決策

延期不是必然違反誠信；**不承認延期、掩蓋差距、事後改寫原定目標**，才會破壞可追溯性。

建議每次延期紀錄：

- 原定範圍與公告日期；
- 尚未達成的測試條件及具體缺口；
- 原因類別：工程複雜度、玩法驗證不足、第三方依賴、法律授權、資金／人力、平台排程、其他；
- 已採取的風險緩解；
- 下一步是縮減、重新排序、替代方案、返工或取消；
- 新的預估若仍不可靠，明確標記未知而非捏造日期。

若延期是因開發者選擇重新設計更好的方案，也應保留原本承諾與新方案的比較；「我們想做得更好」不是自動充分的理由，還須解釋改動的利益與代價。

### 8.4 與 Steam 現行承諾規則的關係

Steam EA 官方明確要求不要對不確定的未來完成時間與功能做具體保證，購買者應以當前版本為購買依據；官方也允許開發者提供計畫時間範圍與現況說明。[S01] 官方 Roadmap 功能則可展示未來方向，並建議避免難以保證的具體承諾。[S05]

ANIE 的 L0–L4 分級是**在既有規則內提高資訊可檢驗性**，不是試圖讓開發者透過「L2 計畫」標籤免除所有不實廣告或消費者保護責任。如果商店頁面的語句、宣傳方式或交易條件實際構成其他法律上的承諾，不能靠內部標籤否認。

## 9．可驗證交付證據包：從新聞稿回到可下載版本

### 9.1 為何單純的 Patch Notes 不夠

遊戲公告若宣稱新增功能，玩家仍可能遇到：其實只在測試分支、功能預設關閉、存檔不相容、內容只在影片展示、只適用特定平台或已知缺陷無處查找等問題。這些未必都是惡意誤導，也可能源於公司不同部門和平台間的狀態不同步。

本研究將重要版本的公開證據定義為一個 **Release Evidence Pack（REP，發行證據包）**。它不是新的 Steam 官方檔案類型，而是企業可自行建立的產品級交付規格。

### 9.2 發行證據包的八個欄位

每個對外重要版本至少具有：

1. **產品及版本識別：** `product_id`、`release_id`、建置版本、公開或測試分支。
2. **可取得條件：** 已正式發布／限量測試／尚未發布；平台與支援環境。
3. **功能範圍：** 新增、修正、移除及暫時停用的功能，對應需求 ID。
4. **驗收來源：** 與版本配對的整合測試、核心操作驗證、已知測試環境。
5. **品質與安全限制：** 已知重大問題、存檔風險、MOD 相容性、回退安排。
6. **承諾對照：** 對應季度原始目標、完成或縮減情形與原因。
7. **真實可玩證據：** 可靠的版本下載條件、實機測試描述、由遊戲當前建置產生的畫面或短片。
8. **來源與修訂歷史：** 交付與公告時間、授權發布人、修正後保留的先前說明紀錄。

如果公司不打算公開整個商業原始碼，可以公開建置編號、摘要式 QA 報告、重現步驟及已知限制。可驗證性是依據公開權限提供充分證據，不要求違反商業秘密、資安、個資或第三方合約。

### 9.3 證據等級與語義

| 等級 | 觀察到什麼 | 可以支持的最強宣稱 |
|---|---|---|
| E0 | 文字想法、原畫、概念圖 | 此方向已被提出或探索 |
| E1 | 程式差異、可審閱的素材或測試程式 | 已有候選實作，尚未表示可玩 |
| E2 | CI 與局部自動測試通過 | 特定模組通過其定義的技術驗證 |
| E3 | 完整建置與目標測試通過 | 在列明環境達到既定驗收條件 |
| E4 | 玩家可從指定通道取得建置 | 特定功能已交付特定使用者族群 |
| E5 | 經發布後追蹤，確認實際功能表現 | 有初步實際使用成效證據 |

等級不是同一條必然的直線：部分玩家品質證據可能先於完善自動化測試；不同版本和平台也可能有不同等級。其用途是防止宣傳把 E0 說成 E4、把 E2 說成 E5。

### 9.4 版本證據必須支持更正，而非不可修改的神話

對外版本公開後發現錯誤，應保留更正事件：原聲明、錯誤理由、新說明、影響範圍及修正生效時間。不可用刪除舊公告的方式，讓過去的誤導訊息消失。公開過度詳細的弱點資訊可能傷害安全，因此事故細節須在修復與合理揭露時點中平衡。

### 9.5 建議避免的「假交付」

- 把大量 AI 生成檔案當成已完成遊戲系統；
- 把未上架的本地測試程式當成 Steam 已更新；
- 把自動產生的完成清單當成經過實機驗收；
- 把修復一次錯誤當成所有環境的根因已消除；
- 把玩家建議已讀當作公司已採納；
- 把外部 MOD 作者的實作當成公司可以無條件收錄的資產。

## 10．玩家回饋與產品決策：不是所有意見都要照做

### 10.1 不要以討論聲量直接替代產品價值

玩家提出大量需求，並不代表每項需求都符合遊戲世界觀、操作負擔與公司可投入資源。社群投票又可能受到自選樣本、活躍使用者偏好、多帳號、情緒動員與話題曝光影響。

ANIE-00 提出的「玩家—開發者相交域」可作為基本框架：玩家意願、創作者設計意圖、技術可行性、風險與商業條件彼此作用，但不保證存在滿足所有人的單一選擇。[I00]

### 10.2 意見的最低處理狀態

建議公開系統為每筆有意義的提案提供下列可分辨狀態：`received`（已收到）、`deduplicated`（已合併相近提案）、`verified`（有足夠重現或分析資料）、`evaluating`（評估中）、`accepted`（原則採納）、`rejected`（不採納並說明）、`deferred`（延期）、`scheduled`（納入工作排程）、`released`（已交付）、`observed`（已取得後續效果資料）。

這些狀態中，`accepted` 不等於 `scheduled`，`scheduled` 不等於 `released`。同一提案也可能因新的證據重新進入評估，不能假設結果永久不變。

### 10.3 玩家反對也是資訊，開發者拒絕也是決策

公司應該有權拒絕會破壞作品核心精神的提案；玩家也應有權透過評論、意見和不購買表達不認同。雙方的自由不必被折算成「誰服從誰」。

成熟的公開交付制度應能清楚記錄：玩家提出什麼、公司理解成什麼、是否有測試支持、公司採取何種選項、後來交付了什麼、玩家實際反應如何。

### 10.4 少數重大問題不得被多數娛樂偏好淹沒

無障礙阻礙、存檔破壞、違反承諾的售價或功能、安全缺陷，即使只有少數人回報，也可能優先於票數較多的新角色提案。此時應採取基於損害與證據的優先級，而不是投票即治理的表面民主。

### 10.5 Steam 不是全部，但已有重要工具

Steam 現有 Events & Announcements 可將更新消息展示於商店、社群、收藏庫，並提供 RSS 供其他通道整合；其 Roadmap 亦能在商店頁展示未來方向。[S05][S06] 因此，公司自建網站的目的，不是宣稱 Steam 完全缺乏公告或路線圖工具，而是管理跨產品、跨時間、跨提案的完整關係：提案 ID、公司決策、版本證據、變更理由與玩家追蹤。

下一階段 ANIE-07 將詳細研究如何把 Steam 作為正式分發與觸達入口，官方網站作為可追溯的公開產品中心，GitHub 作為工程協作工具，而不是各平台分別保存互相矛盾的版本資訊。

## 11．AI 的真正影響：把產生候選與完成交付分開

### 11.1 算力與模型額度是生產變數，但非充分條件

令 $B$ 表示可調度的 AI 資源， $K$ 表示可重用產品資產， $H$ 表示有效人力與合作能力， $W$ 表示開發工作流成熟度， $T$ 表示待開發任務組合。研究可將受特定驗收條件約束的有效交付函數寫為：

$$
D^{verified}=f(B,K,H,W,T,Q,C),
$$

其中 $Q$ 是品質閘門， $C$ 是審查、整合及營運成本。函數 $f$ 不預設為線性、可微、單調，也不預設資源擴張必然提高已驗收的交付量。

這一點對「給予額度就能快速產出」的產業假說尤其重要：模型可能在特定已模組化任務中近乎立即產出有效候選；但可銷售的遊戲仍需要互通、設計統一性、狀態持久性、品質測試、可取得建置與用戶理解。只有把整條路徑量測完畢，才能將速度主張轉化為生產制度證據。

### 11.2 已有外部實證同時包含正面與反面訊號

2025 年 Google DORA《State of AI-assisted Software Development》報告強調，AI 在軟體開發組織中常扮演放大既有制度能力與缺陷的角色，收益不單來自工具本身。[S10] 另一方面，METR 於 2025 年公開的隨機對照研究，在特定資深開源開發者、熟悉的成熟專案及當時模型工具條件下，觀察到開啟 AI 工具反而使任務完成時間平均增加約 19%。[S11]

兩者不應被粗暴轉成「AI 讓所有開發更快」或「AI 讓所有開發更慢」的普遍結論。前者是組織研究脈絡，後者具有明確人群、專案與模型時間窗。2026 年乃至未來模型在遊戲開發、內容生成、介面設計和測試自動化上的表現，仍需以當時實際可用工具測量。

### 11.3 生產線中的五道成本

將 AI 遊戲交付拆成五個互不替代的工作層：

1. **構想與候選生成：** 程式、文字、素材、測試提案或模型推演；
2. **整合：** 與遊戲世界狀態、UI、存檔、其他系統及依賴的相容處理；
3. **驗證：** 自動化測試、人工遊玩、效能與長時間模擬；
4. **發布：** 建置、商店、授權、跨平台檢查、補丁、公告；
5. **發布後品質：** 玩家事故、反饋、維護成本、MOD 相容與後續修復。

在任何階段出現的長尾工作，都可能成為真正的瓶頸。即使第一階段縮短十倍，總交付時間也不必然等比例改善。

### 11.4 AI 產線實驗不等於公開測試的替代

自動生成的一千名虛擬玩家、模擬場景或 Agent 測試，可以協助找到形式規則錯誤、狀態機異常及特定可預測操作；但這些資料不必然重現人類玩家的情緒、理解障礙、動機、文化期待或難度判斷。

因此 AI 測試是外部人類 Playtest 的可能補充，而不是當然替代。可分別記錄 AI 模擬發現的問題、人類玩家發現的問題，以及兩者的交集與差異。

### 11.5 資產複用是可繼承產能的中介變數

隨著公司完成更多遊戲，若能共享適當的事件系統、世界狀態、字型渲染、GUI 元件、存檔格式策略、測試規格和開發知識，下一款遊戲可能減少重複投入。但若被複用的架構與新遊戲不相容，過度抽象也可能增加整合成本。

資產複用的有效性應以「實際節省的工作」「引入的修改成本」「跨版本缺陷」「權利可轉移性」共同量測。完整生產效率模型留待 ANIE-02；合法交接與他人接續維護則留待 ANIE-03。


## 12．資金、定價與 EA 的可持續性：不把玩家當成隱形融資保證人

### 12.1 收入是現實變數，而非需要隱藏的動機

單人工作室或微型公司可能同時擁有多個產品、委託案、研究服務或其他營收來源。若一款 EA 遊戲在推出後立即有銷售收入，這些資金自然可能用於後續開發。研究不應將此事視為羞於承認的動機。

問題在於，公司對外描述的完成範圍，是否實際建立在「一定要有某個銷售額才能做到」的假設上。玩家在 Steam 購買的是目前可玩的商品；若開發計畫高度依賴尚未發生的收入，應評估其風險，而非把未來功能當成必然結果。[S01]

### 12.2 最小資金情境分析

設 $C_{remain}$ 為完成已批准的最小產品範圍尚需投入的現金成本， $B_{secured}$ 為已確定可用的資金， $I_{uncertain}$ 為尚未發生的預期收入。

$$
Gap = C_{remain} - B_{secured}.
$$

此式只是一個簡化的現金缺口觀察，不包括時間價值、可變成本、稅費、現金流時點與其他專案的機會成本。若 $Gap>0$，公司應在進入付費 EA 前明確理解：在預期收入落空時要縮減哪部分範圍、是否有其他可合法取得資金、如何保護現有消費者利益。

不能把 $I_{uncertain}$ 直接算成 $B_{secured}$。另一方面，如果能以已確認資產與有效 AI 產線降低 $C_{remain}$，也不必固守過去同規模團隊的開發成本估計；應以實測建置和驗收數據修正。

### 12.3 付費 EA 與免費 Playtest 的選擇不是單純資金優先

若主要目的是取得高品質玩法資料，免費 Playtest 可能更合適，因為可以控制測試窗口，且不要求當下向玩家出售未完成商品；但其樣本也可能存在參與者偏差。若已有值得購買的當前遊戲，同時需要長期社群反饋與可持續營運，EA 才較符合其制度位置。

不能將 Playtest 當作可付費的便宜 EA，Steam 官方禁止向使用者銷售 Steam Playtest 參加資格。[S02]

### 12.4 EA 定價與版本演進的成本

Steam 允許開發者依產品策略設定 EA 價格，但對漲價、折扣及升級為正式版的時間安排有相應規範。官方文件特別提醒，基礎價格上調後可能影響一段時間內的折扣與上市促銷安排；具體規則應於實際上架時再次核對。[S01]

因此，ANIE 建議：

- 玩家首先應為已交付內容付費，不應被迫賭未來版本。
- 若對外敘述「EA 價格較低是因內容較少」，日後提高價格時也要清楚說明額外價值。
- 價格決策可參考玩家理解、產品狀態與成本，但不能把社群投票當成必須照辦的定價權。
- 主要價格政策及變更紀錄應保留在可查的官方資訊系統，而非只依賴個別客服或短暫貼文。

### 12.5 從小公司延伸至多產品公司

同一家公司多條產品線並行，確實有機會分散單一遊戲收入的不確定性。然而，AI 帳單、模型額度、人員覆核、第三方素材及支援成本可能在高成長期同時增加。應將「可用 AI 產能」「已驗收產品價值」「可支配現金」分開計量。

ANIE-00 與既有《AI 原生企業潛在生產能力與可融資性評估框架》已建立這種概念區分。[I00][I04] 本篇僅要求 EA 決策不得用尚未變現的數位資產數量，替代可以支付下一階段費用的可靠現金流。

## 13．Steam 上架與更新工程：容易發補丁，不等於發布流程可以忽略

### 13.1 開發時間與平台前置時間不同

即使某遊戲在 AI 產線中已能完成，Steam 商店仍有獨立的資料填寫、審核、上架頁面與建置檢查。依目前 Steamworks Release Options，作品在可正式發售或 EA 上線前，必須有至少兩週可見的 Coming Soon 頁面；而商店與建置審核通常需要若干工作天，官方建議提早安排。[S04][S08]

這代表「本地端今天做完」不自動等於「今日可以首次公開販售」。但作品上市後，在通過初始審查的前提下，後續補丁上傳確實具有較高彈性；Steamworks 官方明確區分首次審核與後續可隨時更新的機制。[S07][S08]

這裡的等待時間與規則均以 2026-10-16 可查官方文件為準，實際商務排程需要在提交當日再次查核最新規定。

### 13.2 上傳容易，仍要管理增量風險

Steam 官方強調更新應透過 Steam 客戶端管道交付，且更新頻率可配合產品需求調整；若更新過大，玩家仍須承受下載時間與使用成本。[S07]

因此一個良好的交付系統需要：

- 標記穩定版與候選測試版；
- 先通過核心使用者旅程的 smoke test；
- 自動化檢查存檔與設定檔相容性；
- 對更新大小、檔案改動及下載影響作紀錄；
- 支援合理的回退或已知問題補救程序；
- 避免將完整更新資料放到 Steam 管道之外要求玩家自行下載；
- 讓實際公開建置與公告文字互相對應。

部分重大內容更新也可能需要遊戲內遷移程式、既有存檔備份或 MOD 作者提前測試，不能只因上傳功能簡單就輕忽部署後果。

### 13.3 Steam 的三個現成公開通道

1. **Early Access Q&A／商店描述：** 對當前可玩內容、預期 1.0 與未完成範圍建立購買資訊基準。[S01]
2. **Roadmaps：** 在商店頁展示未來方向；現行 Roadmap 主要可透過圖像呈現，適合高階計畫與概覽，不等於具有完整提案—決策—版本資料關聯的資料庫。[S05]
3. **Events & Announcements：** 可以發布主要更新、一般更新、Patch Notes 和其他新聞；部分更新公告還能與實際發布的建置關聯。[S06][S09]

因此，新建官方互動網站時，應先復用這些既有通道，不要因技術願景而重複製造全部功能。Steam 可以承擔觸達、購買與版本更新；公司自有平台處理跨作品與跨季度的決策溯源。

### 13.4 官方網站是公開證據的索引，而不是自建第二個 Steam

ANIE 建議每款遊戲具有一個可追蹤的產品資訊頁，但不要求玩家為了下載正常 Steam 補丁而離開 Steam，也不應在 Steam 公告中違反平台對其他網站連結與推廣的規則。[S06][S07][S08]

官方網站的重點是：以穩定識別碼連結「提案」「回應」「預定里程碑」「發布版本」「證據包」「後續修正」，而非重新建立商城、DRM、更新伺服器與全面論壇。如此才能把工程投入集中到傳統平台尚未完全解決的跨時間關聯問題。

### 13.5 官網與 Steam 公告不一致時的更正原則

如果自家網站先公布新版本已上線，但 Steam 實際分支因發布失敗而沒有更新，公開資訊系統應顯示「發布失敗／等待同步」，而不是強行宣稱已交付。若商店頁仍顯示已被移除的功能，則須及時修正，不能用「官網已說明」作為商店誤導的免責理由。

建議定義單一真實來源：以授權審核過的版本事件與實際平台可取得狀態為證據，將對外各平台視為此狀態的不同資訊投影。這是 ANIE-00 的重要原則，在此首次具體落入發行流程。

## 14．形式化框架：多軸發行狀態、交付與承諾的非等價性

### 14.1 狀態不是單一進度條

令某遊戲在時間 $t$ 的研究狀態為：

$$
S_t=(R_t,Q_t,V_t,P_t,U_t,F_t),
$$

其中：

- $R_t$：發行與使用情境，包括 demo、test、EA、full 等；
- $Q_t$：品質與可玩準備向量；
- $V_t$：目前已交付版本與可取得通道；
- $P_t$：公開目標及其承諾等級；
- $U_t$：玩家參與、回饋與尚待驗證的設計問題；
- $F_t$：營運與資金可持續性狀態。

本篇所稱「發行進度」，只是 $S_t$ 在部分座標上的變動，而非全域品質必然增加。某次大型更新可能提升內容與玩法，卻使穩定性短期下降；進入正式版可以改善商品清晰度，但不自動消除所有後續工作。

### 14.2 三種規範性不變量

**不變量 A：已交付聲明須有可取得對象。**  若宣稱版本 $v$ 已對玩家群體 $g$ 公開交付，必須能在合法授權範圍內指出其取得通道及建置狀態。

$$
ClaimDelivered(v,g,t) \Rightarrow Accessible(v,g,t).
$$

**不變量 B：承諾級別不得由候選內容自動提升。**  內部測試通過是可能的技術事實，並不等於已有權對外作出確定承諾。

$$
TechnicalPass(v) \not\Rightarrow AuthorizedPromise(v).
$$

**不變量 C：公共紀錄的重大修訂應能回溯。**  原定範圍與時間、修訂理由、授權人和新的公開版本，須保留必要關聯；但不要求把敏感資料本身公開。

這三項是本研究對「可驗證交付」的**設計規則**，不是從自然法則推導出的普遍定理。它們能否被低成本維持、是否改善玩家理解，需要進一步實證。

### 14.3 交付完成率與真實品質的雙軌測量

前述季度目標達成率 $R_q$ 可以衡量是否按照預定目標交付，但不能反映品質。令 $I_q$ 是某季正式公布已交付的重大項目集合， $I_q^{pass}$ 是其中有充分驗收依據的集合，則：

$$
E_q=\frac{|I_q^{pass}|}{|I_q|},\qquad |I_q|>0.
$$

 $E_q$ 是「可驗證交付聲明比例」，不是產品玩家滿意度。若 $I_q$ 為空，應標為不適用。

同時必須觀測：重大缺陷逃逸、發布後需回退的比例、因修補造成的回歸缺陷、平均修復等待、玩家對公告與實際版本的理解差距。任何企業若只改善 $R_q$ 與 $E_q$，卻造成缺陷逃逸或玩家不滿上升，便不能聲稱整體制度成功。

### 14.4 頻率與完整性的取捨

可為候選版本集合定義需要驗收與維護的固定工作負擔 $C_{fixed}$ 及隨功能數增加的成本 $C_{variable}$。若單季將相同總功能拆成過多次公開版本，實際成本可能增加：

$$
C_{quarter}=\sum_{j=1}^{n} (C_{fixed,j}+C_{variable,j})+C_{rework}.
$$

這個式子是會計式拆解而不是可識別的因果模型。它提示我們：較高更新頻率可能提升回饋速度，也可能增加打包、溝通、回退及 QA 負擔。因此沒有先驗理由認為每週都對玩家發布較大更新，必然優於每月或每季度發布。

### 14.5 發行策略是受約束的選擇

令 $\mathcal A_t$ 表示在時間 $t$ 合法且技術上可採取的發行選項， $U_a$ 表示某選項的預期玩家價值與研究收益， $Risk_a$ 表示品質、合規與後續義務風險。可以抽象寫成：

$$
a_t^* \in \mathop{\rm argmax}_{a\in\mathcal A_t}(U_a-\lambda Risk_a),
$$

其中 $\lambda$ 僅代表組織對風險的權衡，不構成單一可客觀求得的最優路線。公司還應排除違反法規、平台條款、授權與 P0 品質閘門的候選選項。

此式最重要的學術意義，是明確否定「EA 一定是下一步」或「所有產品都應先 EA」的路徑預設，而非為企業提供一個可按計算機按鍵求出的自動發行決策。

## 15．反例、批判與失敗機制

### 15.1 反論點 A：如果 AI 已經很快，為什麼還需要玩家付費測試？

**回答：** 速度的提升不會自動消除市場未知，也不代表所有 AI 模擬可以替代人的長期體驗。然而，當玩法已成熟且能直接完成商品，EA 可能確實成為額外負擔；這正是要求 EA 不預設為必經階段的原因。

**可反駁條件：** 若未來 AI 代理能對某類遊戲的人類可用性與玩法品質作高精度預測，外部 Playtest 的邊際收益可能下降。此時應修正本篇的測試配置，而非堅持人工測試永遠不變。

### 15.2 反論點 B：公開季度目標只會把開發者逼進過度承諾

**回答：** 當企業混淆願景、計畫、確定承諾與已交付時，此批評成立。因此本研究把承諾分級、品質閘門及延期原因建成制度核心，並禁止刪掉原始目標來美化達成率。

**可反駁條件：** 若即使採取上述措施，玩家仍系統性將 L2 目標誤認為保證，導致衝突、退費與理解成本上升，應降低公開細節或改變說明方式。

### 15.3 反論點 C：提高更新頻率會犧牲穩定性

**回答：** 此批評具有相當工程合理性，特別對高度耦合的沙盒遊戲、長期存檔及 MOD 生態。季度制的核心不是催促每週上傳，而是把「已交付」「進行中」「不宜發行」分清楚；實際可玩版本頻率由品質閘門決定。

**可反駁條件：** 若同等團隊中高頻版本組有顯著較高重大事故率，應調低其發布頻率；若 CI、測試隔離與小批次部署可降低回歸問題，則可提高頻率，不能先驗決定。

### 15.4 反論點 D：其他業務能賺錢，所以公司必然值得信任

**回答：** 多產品與可查聯絡資訊可增加經營者的可辨識性，但不代表具有足夠現金流、法律擔保或交付能力。更高的跨產品品牌辨識度，可能同時放大成功與失敗的聲譽外溢。

**可反駁條件：** 若公司可見度提高卻不改善實際交付與問題處理，玩家信任不應被假設持續增加。

### 15.5 反論點 E：AI 生成內容很多，玩家何必知道細節？

**回答：** 玩家未必需要知道每個內部 AI Agent 的工作紀錄，但有權在合理範圍理解已購買商品的現況、限制及重大變更。ANIE 鼓勵公開「可查證成果與決策」，而非把長篇內部提示詞及原始推論全部公開。

**可反駁條件：** 若高頻詳盡資料對玩家理解沒有實質幫助，還增加資訊噪音，最小有用揭露可能優於全量技術紀錄。

### 15.6 反論點 F：玩家可能只會利用透明資料攻擊公司

**回答：** 公開資訊可能被誤讀、惡意截取或競爭者利用；這是選擇性揭露要處理的真實成本。公司可保留合理的商業秘密、契約、未發布劇情、資安弱點及個人資料，僅公開外部可理解的結果、狀態、必要理由與事後證據。

**可反駁條件：** 如果一定類型的公開活動反覆造成可觀察的安全、隱私或不成比例的商業損害，應停止該類公開並調整範圍，而不是維護「永遠公開最多」的原教旨目標。

### 15.7 反論點 G：季度達成率容易被 KPI 作弊

**回答：** 是。開發者可能把一個大功能拆成一百項小修復、把目標往下調、將未驗收工作標為完成或把問題推給模組作者。因此指標必須事先固定口徑，保留原始基準，並與玩家可用性、品質、成本及維護負債共同比較。

**可反駁條件：** 如果觀測到達成率上升，但真實玩家任務成功率下降，表示此 KPI 失去代理效度，應停止將其作為核心成功判準。

### 15.8 反論點 H：一款遊戲不適合以季度當作主要創作節奏

**回答：** 某些高度敘事、解謎、美術實驗與一體化劇情作品，公開增量內容會劇透、破壞作品結構或降低首次體驗品質。它們仍可以公開品質里程碑、測試狀態、已知風險和進度理由，而不提前公開設計與故事內容。

**可反駁條件：** 若連有限進度揭露都損害作品體驗，應將對外節奏縮減為必要的商務資訊；可追蹤性不強制開發者事先暴露所有創作選擇。


## 16．研究假說：哪些結果能證成或推翻本篇建議？

以下假說是**有待實驗的命題**，不是已被 EveMissLab 或其他工作室證明的定律。研究不能只收集支持性案例，也必須記錄不利證據。

### H01：發行階段的非線性選擇可以降低不必要的 EA 成本

**命題：** 對玩法成熟、品質門檻已達標的短週期單機作品，略過 EA 而直接正式發行，可能降低額外的承諾管理與社群期待成本，同時不降低消費者對當前商品內容的理解。

**檢驗：** 比較相近規模與複雜度作品在「Playtest → Full」和「Playtest → EA → Full」兩條路徑的市場資訊品質、管理工時、缺陷率及玩家對購買當下價值的判斷。須控制發售季節、工作室知名度、定價與作品類型。

**反駁：** 若同條件下省略 EA 造成更多關鍵設計缺陷或低於預期的玩家滿意度，便不能宣稱此路徑一般較佳。

### H02：發行證據包能改善玩家對版本狀態的理解

**命題：** 在同等商品事實下，提供具建置對照、已知限制與承諾分級的 REP，相較於僅有宣傳式 Patch Notes，可能提高玩家對實際版本狀態的理解準確度。

**檢驗：** 以相同版本資料隨機提供兩種不同說明方式，事後詢問玩家「現在能玩什麼」「仍未完成什麼」「哪些只是計畫」並評分；同時量測閱讀時間與使用者負擔。

**反駁：** 若 REP 未提高理解、反而造成資訊疲勞或錯誤信心，應縮減或重新設計呈現方式。

### H03：AI 增加候選產出，不必然提高品質驗收後的有效交付

**命題：** AI 額度與 Agent 使用程度提高時，候選程式、素材及測試生成量可能增加，但實際交付量的變化受到審查、資產成熟度、任務類型及整合成本調節。

**檢驗：** 以同類型任務比較模型參與、資源成本、整合工時、回歸缺陷及通過驗收的功能數；對不同規模與不同代碼基礎分組。

**反駁：** 若在廣泛任務中，AI 資源增加能穩定帶來同比例的高品質交付，而沒有可觀察的審查或整合瓶頸，則本研究對瓶頸非線性的強調應予修正。

### H04：穩定的季度公開比較基準可增加交付可追蹤性

**命題：** 相較於零散新聞公告，預先登記季度目標並保留延期、更正與驗收證據，可能降低玩家追索進度所需的資訊成本。

**檢驗：** 計算使用者回答「上季承諾的功能究竟如何處理」所需時間、答對比例及對資訊可信度的判斷。可比較導入前後與類似產品的差異。

**反駁：** 若公開目標被廣泛誤讀為法律保證，或公告成本大於社群理解收益，應降低承諾粒度或改用更合適的呈現方式。

### H05：發行頻率提高可能同時改善回饋速度與增加維護負擔

**命題：** 在測試、自動化與風險控制能力固定時，更頻繁的公開發布可能使玩家更早發現問題，但也可能增加重複打包、事故回退、使用者下載和 MOD 相容性成本；最適節奏隨作品而異。

**檢驗：** 觀察每個已發布功能的重大缺陷、回退、維護工時、玩家問題回應時間和下載成本，而非單看補丁數。

**反駁：** 若在一致條件下，頻率提高不增加任何成本且持續改善品質，應依測得結果調整模型，不先假定必然存在中間最適點。

### H06：當前價值說明比未來願景更能降低購買期待錯配

**命題：** 對 EA 玩家，清楚表達目前已完成內容、已知限制與不確定的後續計畫，可能使玩家的購買期待更接近真實體驗。

**檢驗：** 比較不同商品說明下的功能預期與實玩後感知差距；輔以退款、評論和客服議題，但不將單一指標當成完整因果證據。

**反駁：** 若在等量資訊與相同商品條件下，額外揭露現況並未改善認知，或者造成更多誤解，則需要重新設計資訊密度及表達順序。

### H07：公開負面進度不必然損害長期信任

**命題：** 在具體且持續可核對的證據下，開發者公開延期原因、未完成事項與修正計畫，未必比模糊宣傳造成更低的長期信任。

**檢驗：** 以縱向追蹤玩家在多季度中的預測準確度、重購或後續作品關注、資訊信任調查與實際交付相符程度。必須區分「講述失敗」與「反覆失敗卻沒有改善」。

**反駁：** 若即使具有改善證據，公開細節仍反覆造成顯著負面效果，則應重新研究公開粒度與場景適用性。

## 17．實證方案：如何避免用一個成功遊戲證明整個時代改變？

### 17.1 研究樣本

建議至少區分下列軸：

- 產品規模：小品／中型系統／大型世界模擬；
- 開發者結構：單人／小型團隊／多團隊；
- 資產可繼承程度：低／中／高；
- 發行策略：DEMO、Playtest、EA、直接正式發售的不同組合；
- AI 使用：未使用、局部使用、系統化多 Agent 工作流；
- 公開互動：僅傳統公告、具有 REP、具有完整提案—決策—交付關聯；
- 支援內容：純單機、原生 MOD、高依賴外部內容及跨平台作品。

若僅觀察 EveMissLab 的單一作品，研究應明確標記為**探索性個案**，不可推論到所有 Steam 遊戲公司。至少應收集連續多季度資料，或尋找任務複雜度相近的比較群組。

### 17.2 最小因果設計

在可行且合法的情況下，採用三類方法互相驗證。

**A．同類型內部任務隨機分派。**  將可比較的模組任務隨機分配給 AI 參與與較低 AI 參與的流程；完整記錄人類覆核、設計變更及返工，並保持相同品質閘門。

**B．分階段導入的前後比較。**  例如先對一款遊戲導入 REP，再對第二款遊戲導入；在導入前即建立基準記錄，以減少純粹回憶偏差。仍須控制同期模型升級及外部熱度。

**C．公開資訊理解實驗。**  以相同內容的兩種資訊展示，測量玩家對已交付和未完成事項的理解，而非要求使用者在未讀取內容下回答是否「覺得透明」。

不得以刻意隱瞞重大風險、製造可預見的存檔事故或發布違反商店規定的內容當作實驗處理。

### 17.3 測量矩陣

| 指標 | 操作性定義 | 主要限制 |
|---|---|---|
| 目標達成率 | 季初預定項目中通過驗收的比例 | 小任務拆分與目標選擇偏差 |
| 交付聲明可驗證率 | 已宣稱發布的重大項目中具有有效建置證據的比例 | 證據品質需被抽樣稽核 |
| 玩家目前狀態理解率 | 玩家能正確回答目前版本包含與不包含的內容 | 玩家群體與問題設計影響結果 |
| 交付前置時間 | 從已批准工作開始到玩家能取得版本的時間 | 工作範圍不同不可直接比較 |
| 品質逃逸率 | 特定等級事故於發布後首次出現之比例 | 測試覆蓋與回報率影響觀測 |
| 重大事故修復時間 | 自確認事故到可用修復或安全替代方案之時間 | 事故類型與優先級差異 |
| 玩家問題回流率 | 玩家議題連到明確決策或產品修正結果的比例 | 拒絕也需視為有效完成處置 |
| AI 全鏈成本 | 模型資源、工具、審查、測試與返工的全部成本 | 內部分攤成本可能難估 |
| 版本相容性 | 更新後主要存檔、設定與 MOD 測試成功率 | 需事先界定支持矩陣 |
| 信任與預期差距 | 玩家預想功能與實際取得內容間的偏差 | 需要長期問卷和抽樣控制 |

所有指標應包含分母、測量期間、遺失資料與規則版本。不得把「沒有玩家回報 Bug」自動解讀為 Bug 數量等於零；可能只是樣本量不足、回報入口不友善或玩家已流失。

### 17.4 排除三種統計幻覺

**選擇偏差：** 願意參加 Playtest 或投票的人不一定代表買家；已經喜歡遊戲的人更可能讀取開發日誌。

**倖存偏差：** 只研究成功從 EA 畢業的作品，將低估停止維護、商業失敗及長期延期情形。

**版本選擇偏差：** 只統計大型內容更新而忽略修補與長時間 QA，會誤判維護負擔；反之只統計補丁數，又會誤把大量問題當成高生產力。

本研究不使用未經方法核對的「Steam EA 有多少作品一年未更新」數字作為直接定罪依據。沒有公開更新、沒有商店新聞、沒有可下載差異、沒有開發活動、實際棄坑及依法違約，屬不同概念，需要分開取證。

### 17.5 實際 A/B 測試的倫理與操作限制

對商品描述、價格、缺陷與安全警示，不應將部分真實消費者隨機安排在「刻意不告知重大資訊」的劣化狀態。可在完全揭露必要資訊的前提下，比較排版、索引、證據鏈導航和摘要方式。

在 AI 助理使用上，可經必要告知與權限管理，將 AI 用於分類、文件草擬與非敏感問題導覽；涉及客戶個資、正式承諾、退款、付款、法律爭議及商業秘密的動作須經適當授權，不能為了追求自動化率犧牲真實權責。

## 18．三個完整案例：讓制度能被實際理解

本節均為**合成示意案例**，不是 EveMissLab 已完成的遊戲營運成果，亦非所引用遊戲的真實統計。數字僅用於展示決策分歧與可驗收邏輯。

### 18.1 案例 A：三個月目標的 GUI 戰術小品

**情境：** 開發團隊已有可復用的戰鬥狀態機與 UI 工具，計畫製作一款單機短篇戰術遊戲。玩家完整遊玩一條故事線約數小時，主題與內容範圍清楚。

**第 1 個月：** 完成可重現的核心戰鬥原型與存檔，邀請少量人類測試操作理解、遊戲節奏與失敗回饋。  
**第 2 個月：** 整合完整內容、外部 Playtest、改善主要錯誤與通過核心品質閘門；視市場需要公開小型 DEMO。  
**第 3 個月：** 進行上架資料、授權檢查、產品完整性測試及平台審核；若準備度足夠，選擇直接正式發售。

**關鍵決策：** 在 1.0 已有完整商品價值時，不因公司希望收集更多意見，就必須先改成付費 EA。玩家回饋仍能透過正式版後的季度更新收集。

**可能失敗：** 若 Playtest 發現戰鬥循環沒有足夠樂趣，則即使開發進度「已達 80%」，也不應以固定三個月截止日強行上市。公開報告應記錄延期及理由。

### 18.2 案例 B：半年目標的多系統經營模擬

**情境：** 遊戲包含角色關係、日夜與生活、資源生產、事件鏈與進度保存。基礎玩法完成後，玩家發現某些資源循環可以無限放大，部分對話選項也造成不可逆的世界狀態錯誤。

**選項一：Playtest 延長、正式版晚些推出。** 當核心功能已確定，但需要找出各類型玩家的設計缺陷，免費測試較適合；修復後直接 1.0。

**選項二：進入 EA。** 當目前已有長期可玩的商品價值，且後續世界系統設計需要持續玩家共同驗證，才選擇 EA。此時要明確列出：已交付的核心循環、不具備的完整勢力系統、已知平衡問題與季度回顧方式。

**季度驗收：** 「新增勢力管理」不得僅以介面已畫好就視為完成，而要通過真正的世界狀態變化、存檔還原與跨系統相容測試。

**可能失敗：** 如果玩家意見分歧，公司可能決定保留原設計而不採納最高票提案；應說明理由並保留可選 MOD 接口研究，而不是讓投票完全控制作者意圖。

### 18.3 案例 C：長期沙盒與世界模擬遊戲

**情境：** 作品具有動態 NPC、長週期世界推進、不同國家或勢力、生活／冒險複合系統與未來 MOD 支援。此類遊戲有可能因外部回饋取得重大改善，也有更高的耦合與測試成本。

**EA 進入時的商品範圍：** 至少具備一個自洽的初始地圖、一套可持續的世界循環、基本存檔、角色成長與合理的玩家目標。尚未完成的地區、任務線與大型系統要清楚標記為未來計畫。

**第一季：** 修復長時間存檔與核心資源循環；若品質尚不足，不推出擴張地圖，但公開缺口與修復證據。

**第二季：** 根據玩家實測逐步擴充系統、維持內容相容；必要時開設測試分支供外部測試，不把測試版宣稱為所有玩家均可穩定使用。

**第三季：** 依產品品質決定是否擴大 EA、繼續研究或進入正式版候選；若仍有重大風險，不以「已經過了三季」作為 1.0 的充分理由。

**可能失敗：** 重大版本破壞 MOD 或存檔時，應先處理兼容性、備份與公告。比起增加新種族或故事內容，修復原有玩家的世界資料可能更具優先權。

### 18.4 從案例反推制度：三種作品共享規則但不共享截止日期

三個案例共同使用：清楚的目前版本描述、品質閘門、承諾分級、季度差距、玩家意見處置與交付證據包。但只有當產品實際條件支持時才選 EA；而其交付時間表、公告密度與系統完整性門檻可以完全不同。

這正是本篇所謂「平台階段與持續交付制度解耦」：**制度共用，產品路徑可變；原則穩定，實際日期不以猜測充當保證。**

## 19．從理論到工作室：最小可實作的 ANIE-01 原型

### 19.1 先用現有工具，不急著造全新的企業平台

單一工作室的最小建議架構：

```text
    開發原始碼／素材／權利資訊
             │
             v
        建置與測試流程
             │
             v
       Release Candidate
             │
       質量與授權閘門
             │
       ┌─────┴─────┐
       v           v
     未通過       正式通過
       │           │
   回到修正       確認發布通道
                   │
              ┌────┴────┐
              v         v
          Steam 建置   內部保留紀錄
              │         │
              └────┬────┘
                   v
             發行證據包 REP
                   │
             ┌─────┴──────┐
             v            v
        Steam 公告    官方產品資訊頁
             │            │
             └─────┬──────┘
                   v
              玩家意見回流
                   │
             下一輪授權決策
```

重要的是資料能一一對應，而不是系統名稱有多新。初期甚至可以用 Git 版本、現有 CI、人工審核與一個靜態網站完成核心閉環。

### 19.2 最小職能，而非最小員工數

即使只有一位人類負責經營，仍應在流程上區分五種職能：候選製作、獨立驗證、產品決策、商店發布與對外說明。不同職能可以由同一人於不同階段執行，亦可由 AI Agent 輔助，但不應因少人就讓「AI 說測試通過」自動變成「已獲授權發布」。

### 19.3 建議的發行狀態轉移

```text
idea
  -> prototype
  -> testable
  -> validated_candidate
  -> launch_ready
  -> release_authorized
  -> platform_uploaded
  -> platform_accessible
  -> outcome_monitored
```

此處 `platform_uploaded` 與 `platform_accessible` 必須分開，因為上傳完成、商店可見以及玩家實際可下載並不完全相同。若遇到錯誤，可進入 `blocked`、`rollback_planned`、`rolled_back` 或 `superseded`，且保留歷史。

### 19.4 防止 AI 自我認證

若生成與驗證完全由同一批未隔離的提示詞、測試資料與模型輸出控制，可能出現測試只滿足 AI 自己想像的條件，卻未覆蓋真實玩家風險。

建議採取：

- 在功能生成前保存相對獨立的驗收條件；
- 驗證程式與製作程式盡量分離；
- 對關鍵遊戲流程進行獨立的實機測試或隨機抽驗；
- 記錄測試輸入與版本，避免只有「PASS」而找不到測試證據；
- 對重大風險維持具適當權限的人類或獨立審核管道；
- 公開聲明只引用已批准且可以查核的結果。

「獨立」不必在所有地方等於不同自然人，但必須有足夠的流程隔離、證據來源與利益衝突控制。正式量化方案將在 ANIE-02 接續展開。

### 19.5 用最小透明度避免成為公關奴隸

若工作室每一段 AI 討論都需要寫成對外新聞，反而消耗真正開發時間。最小可行制度應把開發事件轉換為結構化資料，對外只發布重要里程碑、品質障礙、實際修復與明確決策。

**最小有用透明**不是隱藏成果，而是拒絕把公開資訊制度變成每天一篇沒有實際內容的表演式更新。

## 20．與 ANIE 全系列的分工

本篇僅解決**不同遊戲發行階段之目的、選擇條件與公開交付共同制度**。以下重要問題刻意留給後續研究，不在此重複推導：

| 後續篇目 | 本篇建立的前提 | 後續負責的專門研究 |
|---|---|---|
| ANIE-02｜季度單機產品制 | 已定義週／月／季與「生成量不等於驗收量」 | AI 額度、模組複用、流程排程、成本、總交付率與測試實證 |
| ANIE-03｜可繼承的遊戲產品 | 已要求建置／發布／授權證據 | 第三方接手、資產移轉、AI 維護、重現建置與接班試驗 |
| ANIE-04｜玩家—開發者相交域 | 已明確區分意見與公司決策 | 多方偏好、正當拒絕、代表性、非服從式協商 |
| ANIE-05｜原生 MOD 生態 | 已要求相容性與更新風險處理 | MOD API、版本管理、沙盒、安全、遷移工具 |
| ANIE-06｜商業遊戲也可以 PR | 已承認外部貢獻需要權利治理 | 程式審查、契約、著作權歸屬、報酬與 MOD 正式收錄 |
| ANIE-07｜Steam 不是唯一入口 | 已區分官方平台與企業公開資料中心 | 跨平台資訊投影、網站資料模型、身份與狀態同步 |
| ANIE-08／09 | 已定義需求、決策、發行與證據 | AI 客服及公開決策帳本的完整事件治理 |
| ANIE-10–12 | 已建立發行制度的選擇性揭露邊界 | 企業治理、競爭力與跨業實證 |

已有的 SEDB-GAME、企業母 AI、AI 原生決策治理與企業通訊智能框架可以提供技術、權責及資料治理基礎，但本篇不把它們視為已全部完成商業實作的證據。[I01]–[I05]

## 21．結論：EA 可以保留，交付制度應該升級

本文提出一個可操作的制度判斷：**未來遊戲應否進入 EA，不能以「開發還沒完成」或「公司需要資金」單獨作答，而應結合現有商品價值、外部回饋必要性、品質準備、營運持續性與平台規則共同決定。**

對能在短週期內完成核心商品的小型作品，Playtest 或 DEMO 後直接正式推出，可能是比 EA 更清晰的途徑。對仍需玩家長期驗證複雜系統、但目前版本已提供足夠可玩價值的沙盒作品，EA 依然具有制度上的合理性。兩種情況都應採取有品質閘門、有證據、有修訂歷史、有回饋處理的持續交付制度。

本文的主要貢獻是：

1. **非強制的發行路徑：** DEMO、Playtest、EA 和正式版各有功能，不構成必經的線性階梯。
2. **現有價值優先：** 不把未來承諾取代玩家目前取得的商品品質。
3. **交付與承諾分離：** 季度目標、授權承諾、內部驗收及已可下載版本須有不同狀態。
4. **品質阻斷條件：** 不用功能百分比、快速上傳或宣傳影片掩蓋重大風險。
5. **可驗證的交付證據包：** 讓外部理解實際產品變化，並能追蹤更正、延期及後續效果。
6. **AI 產能實證義務：** 不預設算力與額度可無限轉化為玩家價值，研究整個生成—整合—驗證—發布—維護生命週期。
7. **與企業公開互動銜接：** 玩家不必只是等待消息；公司也不必因更多公開資訊而放棄設計主體性。

這些命題不是宣告舊 EA 制度被 AI 技術淘汰，而是提出可被驗證的新制度提案。若實驗發現某些作品因公開交付而降低品質、因過密更新而傷害相容性，或因自建資訊系統而產生不成比例成本，研究就應修正節奏、縮減規格或改用更適合的發行模式。

本篇最終保留一句區分：

> **EA 是一種產品交易與共同開發安排；持續交付是一種可以跨越產品生命週期的組織能力。** 前者可以選擇，後者必須以實際成果、品質與成本證據檢驗，而不能只靠口頭信心成立。

---

## 附錄 A．Steam EA 對外 Q&A 草稿範本（待填寫，不代表已上線）

以下是**撰稿範本**，正式使用時必須填入與當前可下載版本相符的真實資訊，並逐項檢查 Steam 最新規範。

### 為什麼採用 Early Access？

本遊戲目前已具備［列出可完整遊玩的核心循環］，但［列出仍存在重大設計不確定性的系統］需要較長時間的真實玩家體驗與意見。我們希望在提供現有遊戲價值的同時，透過測試、版本更新和公開回應持續改進。

### Early Access 預計持續多久？

目前估計［可合理說明的時間範圍；若無足夠證據則說明不確定性］，但遊戲是否適合進入正式版，仍取決於已公告之核心完成標準、品質和測試結果。若計畫變更，會公開說明現況與原因。

### 正式版預計與 EA 有何不同？

我們希望增加／完成［候選功能集合］，但這些是開發方向與預估，不是目前購買即可保證取得的功能。當前已完成的內容以以下版本說明為準。

### 現階段 EA 版本有哪些內容？

目前可玩：［列出具體玩法、地圖、模式、系統及功能限制］。  
目前尚未完成：［列出玩家容易誤判的重要缺口］。  
已知重大問題：［列出已知存檔、穩定性與相容風險］。

### 未來價格是否會變更？

目前定價反映［當前可用內容與交易策略］。未來若因完整度與產品策略調整，會依 Steam 規則並提前在合適管道說明。

### 玩家如何參與開發？

可以透過 Steam 社群／官方提案網站［填入真實入口］回報問題、提供重現方式、討論需求。公司會定期整理進度及部分決策理由，但**提案支持數不等於公司必須實作**，所有重大版本仍需通過品質、權利與發布檢查。

## 附錄 B．季度公開交付報告模板

```markdown
# 遊戲季度交付報告 Qx YYYY

- 產品 ID：
- 實際遊戲版本：
- 公告時間：
- 產品階段：DEMO / Playtest / EA / 1.0 / 後續更新
- 本期受眾：全部玩家 / 特定測試者 / 其他

## 本季原定目標（保留原始公告）
| ID | 原定目標 | 原始承諾等級 | 驗收條件 | 目前狀態 |

## 已公開交付
| ID | 功能／修復 | 建置版本 | 可用通道 | 驗證範圍 | 已知限制 |

## 已內部驗收但未公開
- 不可寫為已交付；說明當前差距與可能發布安排。

## 延期、取消與範圍變更
| ID | 原定範圍 | 實際差距 | 原因與證據 | 補救與新狀態 |

## 玩家意見處置
| 提案 ID | 核心意見 | 公司決策 | 理由 | 後續版本關聯 |

## 品質與相容性
- 重大事故：
- 存檔遷移：
- MOD 相容性：
- 安全與隱私：

## 下季目標
- 清楚標記：願景／候選／季度計畫／正式安排。

## 修訂歷史與權責
- 與之前公告的差異：
- 已批准公開者與日期：
- 參考建置／測試／Steam 公告：
```

## 附錄 C．上市與更新審核檢查表

### C.1 DEMO 上線前

- [ ] DEMO 實際展現具有代表性的可玩核心內容。
- [ ] 畫面、說明、語言及支援功能與當前 DEMO 一致。
- [ ] 玩家可以理解 DEMO 與完整商品的差別。
- [ ] 已確認是否需要獨立的 Demo Store Page，並遵守相應規則。
- [ ] 主要測試環境中的啟動、操作與結束流程通過。
- [ ] 已確認素材及第三方依賴的發布權限。

### C.2 Playtest 上線前

- [ ] 測試問題明確，知道哪些資料對設計決策有用。
- [ ] 測試資格免費，沒有以遊戲內交易繞過限制。
- [ ] 測試對象與已知樣本偏差有記錄。
- [ ] 測試風險、資料使用及意見提交方式已說明。
- [ ] 測試結束後可以安全管理存檔及取得權限。

### C.3 EA 上線前

- [ ] 核心遊戲目前已具有可付費的現有價值。
- [ ] 商店說明、EA Q&A、實際建置互相一致。
- [ ] 重大未完成功能與主要已知風險已揭露。
- [ ] 不要求消費者憑未來保證購買當前版本。
- [ ] 若收入不如預期，已評估最低範圍及現金缺口。
- [ ] Steam 所需商店及建置流程、前置期已安排。
- [ ] 事故處理、退款與支援管道符合適用規則。
- [ ] 公開進度與決策由適當權限批准。

### C.4 正式版上線前

- [ ] 商店所承諾的核心玩法與支援範圍已實際提供。
- [ ] 完整主要遊玩路徑通過品質驗收。
- [ ] 沒有未處理的 P0 問題。
- [ ] 授權、字型、音樂、影像及第三方素材已確認。
- [ ] 建置、測試、上架狀態、公告與可下載狀態一致。
- [ ] 舊版存檔、重大 MOD 相容性及補救方法已記錄。
- [ ] 正式版後的支援範圍與方式有清楚說明。

### C.5 任一季度結束時

- [ ] 原定目標及其變更歷史都能核查。
- [ ] 已交付項目有對應版本與證據。
- [ ] 未交付項目未被悄悄移除或算作已完成。
- [ ] 玩家重要提案有查得到的處置或合理更新。
- [ ] AI 草擬的公開資訊已經受權人批准。
- [ ] 重大事故沒有被一般進度文字掩蓋。

## 附錄 D．發行證據包資料契約（研究示例）

以下 JSON 為**尚未部署的假想資料契約**。`null` 表示尚無可查證資訊，不能以虛構雜湊、連結或版本填補。後續工程可增加數位簽章、SBOM、測試憑證及更細的權利追蹤，但不應將本示例誤認為已完成的 API。

```json
{
  "schema": "anie.release_evidence.v0.1",
  "product_id": "example-singleplayer-game",
  "release_id": "example-q1-candidate",
  "release_stage": "playtest",
  "release_channel": "private-test",
  "actual_accessible": false,
  "build_id": null,
  "build_digest_sha256": null,
  "publicly_announced_at": null,
  "validation": {
    "result": "not_yet_verified",
    "test_report_ref": null,
    "supported_environment": [],
    "known_blockers": []
  },
  "scope": {
    "delivered_feature_ids": [],
    "candidate_feature_ids": ["example-feature-001"],
    "changed_or_removed_feature_ids": []
  },
  "promise": {
    "level": "L1_candidate",
    "approved_for_publication": false,
    "related_quarter_goal_ids": []
  },
  "compatibility": {
    "save_migration_status": "unknown",
    "mod_api_status": "not_applicable"
  },
  "provenance": {
    "release_approver": null,
    "revision": 0,
    "source_event_ids": []
  }
}
```

系統實作時的強制邏輯：

1. `actual_accessible=true` 需有真實可取得的發布通道及相應建置證據；不可由 AI 自行推測。
2. 重大功能的 `delivered_feature_ids` 應對應其驗收記錄，不能只來自提交者描述。
3. `approved_for_publication` 是發布工作流狀態，而非只靠 JSON 欄位檢查即可產生權限。
4. 公開視圖不得暴露未授權的內部測試、私有儲存庫、敏感帳號或個人資訊。
5. 更正只增加歷史事件或明確版本，不覆寫過去的對外聲明來源。

## 附錄 E．研究成熟度與後續工作

| 命題／模組 | 本篇狀態 | 下一個驗證要求 |
|---|---|---|
| DEMO、Playtest、EA 與正式版具有不同功能 | 以平台文件可核實的制度事實 | 實際遊戲選路與效果比較 |
| 發行階段不應強制形成單一路徑 | 規範性研究提案 | 觀察不同規模遊戲的實際成果 |
| 當前價值優先與承諾分級 | 制度設計；部分平台規則支持 | 玩家理解實驗、案例分析 |
| REP 發行證據包 | 新提出的組織資料契約 | 建置原型、稽核成本、玩家效用 |
| 季度公開驗收 | 待實證工作流程 | 至少多季度的實際交付紀錄 |
| AI 額度提升產品交付率 | 有方向性可能；效果未被本篇證明 | ANIE-02 實測／任務分層 |
| 非強制 EA 路徑更具商業效率 | 待證的比較假說 | 合理匹配對照、成本與信任觀測 |
| 長期可繼承的遊戲維護能力 | 本篇僅提出前置證據需求 | ANIE-03 實際交接演習 |

---

## 參考文獻與資料來源

### A．Steam 官方規則、產品能力與發行文件

**[S01]** Valve. *Steamworks Documentation — Early Access*. EA 的可玩性、現有商品價值、非群眾募資定位、未來承諾、商店描述、定價與升級為正式版等規範。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/store/earlyaccess

**[S02]** Valve. *Steamworks Documentation — Steam Playtest*. 免費參與、獨立子 App ID、控制名額、測試結束與不可販售測試資格等規範。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/features/playtest

**[S03]** Valve. *Steamworks Documentation — Demos*. DEMO 的目的、品質、發行時點、獨立 App ID、商店頁、共享資料與完整遊戲的關係。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/store/application/demos

**[S04]** Valve. *Steamworks Documentation — Release Options*. Coming Soon、EA 和正式版的不同發布操作與前置安排。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/store/types

**[S05]** Valve. *Steamworks Documentation — Roadmaps*. Steam 商店路線圖、未來計畫呈現與具體承諾的風險提示。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/store/roadmap

**[S06]** Valve. *Steamworks Documentation — Events and Announcements Tools*. 商店、社群、收藏庫、新聞及 RSS 等官方溝通途徑。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/marketing/event_tools

**[S07]** Valve. *Steamworks Documentation — Updating Your Game: Best Practices*. 遊戲正式上市後持續更新、Steam 作為更新交付通道、公告與內容發布最佳實務。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/store/updates

**[S08]** Valve. *Steamworks Documentation — Review Process*. 商店與建置審核、首次發布前置時間、資料與可玩功能一致性，以及初次審核後持續更新。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/store/review_process

**[S09]** Valve. *Steamworks Documentation — Event Type: Major Update*. 主要更新公告與特定 Steam 建置關聯之功能。查核日期：2026-10-16。  
https://partner.steamgames.com/doc/marketing/event_tools/type_majorupdate

### B．AI 生產力與軟體交付研究

**[S10]** DORA / Google Cloud (2025). *State of AI-assisted Software Development 2025*. 強調 AI 對組織既有能力與問題的放大效果；本篇僅將其作為軟體工作流背景證據，非遊戲業專屬因果研究。  
https://dora.dev/research/2025/dora-report/  
https://research.google/pubs/dora-2025-state-of-ai-assisted-software-development-report/

**[S11]** Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). *Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity*. METR 的特定開源工作隨機對照研究；樣本、成熟專案與當時模型工具構成其外推限制。  
https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/  
https://arxiv.org/abs/2507.09089

### C．EveMissLab 研究前作與系列內部依賴

下列為研究內容對照，不預設全部文件均已對外公開、完成獨立驗證或完成商業部署。

**[I00]** Neo.K × GPT-6（2026-10-16）。《從產品黑盒到 AI 原生互動企業：可驗證交付、開放協作與選擇性資訊揭露》，《AI 原生互動企業論》ANIE-00，v0.1，UTF-8 Markdown 工作論文。

**[I01]** Neo.K × Aletheia（2026-08-01）。《企業母 AI：公司作為 AI 的可觀察世界》，《母 AI 與區域認知體》系列第 09 篇，v0.1。

**[I02]** Neo.K（2026-09-07）。《從意圖到決策：AI 原生決策編譯器與稀疏意圖治理》，《AI 原生決策治理與認知資本》系列第 01 篇，v0.1。

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

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

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

---

## 文件完整性與研究狀態聲明

- **來源層級：** Steamworks 官方文件支持的是其目前實際的平台規則與功能；DORA、METR 支持特定研究條件下的軟體生產力觀察；ANIE 的制度模型與指標是作者提出的研究建議，不應混淆三者。
- **文件時間：** 平台規範、發布程序及外部資料截至 2026-10-16 已查核；往後實際發行必須再次確認最新條款及相應法律規範。
- **研究成熟度：** 本篇為公開工作論文，未經同儕審查，尚未以 EveMissLab 的新遊戲產品線進行長期對照實驗。
- **數據責任：** 所有具體遊戲時間線及模板案例均明確標示為示意，不代表實際上架或已完成的專案。
- **正式原稿：** 本檔為 UTF-8 Markdown，所有正式數學原始碼使用 ` $...$ ` 與 `$$...$$`，不以聊天介面的渲染內容取代來源檔。後續修訂須以原稿為準，通過內容與數學定界符檢查後再提交。