title

Steam 不是唯一入口：跨平台公告、開發網站與公開資訊樞紐

english_title

Steam Is Not the Only Entry Point: Cross-Platform Announcements, Development Websites, and Public Information Hubs

series

AI 原生互動企業論

series_en

AI-Native Interactive Enterprise

series_id

ANIE

paper

07

part

第三部：互動式資訊與產品決策

author

Neo.K

institution

一言諾科技有限公司（EveMissLab）

research_assistance

GPT-6（官方文件檢索、架構形式化、反例設計、實證方案與原始碼驗證）

version

v0.1

date

2026-10-17

language

zh-TW

status

Public Working Paper / Conceptual and Technical Methodology / Not Peer-Reviewed

canonical_source

UTF-8 Markdown

math_delimiters

$...$ and $$...$$ only

research_status

Research proposal; example event data, URLs, APIs, role settings, acceptance criteria and sample metrics are proposals, not records of live production services

external_sources_checked

2026-10-17

related_papers

ANIE-00 — 從產品黑盒到 AI 原生互動企業 · ANIE-01 — 從 EA 到持續交付 · ANIE-02 — 季度單機產品制 · ANIE-03 — 可繼承的遊戲產品 · ANIE-04 — 玩家—開發者相交域 · ANIE-05 — 原生 MOD 生態 · ANIE-06 — 商業遊戲也可以 PR · ANIE-08 — AI 客服與需求回流（後續） · ANIE-09 — 公開決策帳本（後續）

Steam 不是唯一入口：跨平台公告、開發網站與公開資訊樞紐

Steam Is Not the Only Entry Point: Cross-Platform Announcements, Development Websites, and Public Information Hubs

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

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

摘要

商業單機遊戲長期依賴 Steam 等發行平台完成交易、更新、評論、社群公告與玩家交流。這種高度集中具有降低玩家搜尋成本、擴大觸達能力與維持平台內體驗等優勢；然而，當開發者準備實施雙週／月度／季度進度公開、玩家提案與投票、跨版本驗證、MOD 擴充、外部 Pull Request、商業合作、AI 客服及公司層級的選擇性資訊揭露時，單一發行平台的討論串、公告與評論機制便不必然足以承載完整的長期資訊生命週期。

本文提出「跨平台公開資訊樞紐」（Cross-Platform Public Information Hub, CPPIH）作為 AI 原生互動企業的一項公共基礎設施研究：不取代 Steam 的交易與玩家關係，不宣稱官網可以控制 Steam 的規則與外部資料，而是透過產品專屬網站、公開資料契約、可追溯事件鏈、平台原生連結，以及具授權邊界的 AI 工作流，把散落於 Steam、GitHub、MOD 社群、玩家回饋及企業內部的不同證據與狀態，重組成可觀察、可修正、可驗證的產品資訊世界。

本文特別區分六組容易被混同的概念：第一，跨平台索引不等於跨平台資料所有權；第二，公司內部事實來源不等於公開顯示層；第三，發布成功不等於每個平台同步可見；第四，玩家登入不等於玩家必須提供 Steam 帳號；第五，公開投票不等於將產品設計權交給多數；第六，AI 摘要不等於擁有權限的公司正式表態。對各平台的資料，應保存來源、權限、可見性、更新時間與外部連結；對公司自行作成的產品承諾，應建立具簽核與撤回紀錄的公開事件鏈。

截至 2026 年 10 月，Steamworks 官方提供 Events and Announcements 系統，可把遊戲消息投影至商店、社群中心、收藏庫、活動串流與遊戲 RSS；ISteamNews/GetNewsForApp/v2/ 提供新聞讀取介面，但不能據此推論所有事件發布都具有公開的寫入 API；Steam 的瀏覽器端 OpenID 能用於帳號關聯，但帳號身分、購買權限和網站治理角色仍必須分別驗證。GitHub Discussions 提供問答、公告、投票等協作方式，Webhooks 可輔助事件導入，但仍需驗證簽章、去重及權限。這些都是本文可以重用的既有機制，不是本文的原創發明。[E01][E02][E03][E04][E05][E06]

本文的新增貢獻在於：提出多平台「權威域—投影域」分離模型、開發公告的跨平台一致性協議、玩家提案的公開引用契約、分層揭露邊界、跨遊戲命名空間、AI 輔助編輯與保密權限閘門，以及一個可被反駁的實證計畫。本文不主張 EveMissLab 已建成該網站或已與 Steam 建立全自動雙向寫入整合；網站名稱、資料結構與功能清單均屬研究與未來工程建議。案例中的日期、投票、功能、版本、統計及人員名稱如未明確標示外部來源，均為假設性資料。

關鍵詞： Steamworks、Events and Announcements、跨平台資訊樞紐、公開開發進度、季度交付、玩家提案、投票、GitHub Discussions、MOD、AI 客服、企業選擇性揭露、事件溯源、資訊一致性、權限、公開決策、資料治理、互動企業。

0．研究問題、研究範圍與不主張事項

0.1 問題不是「Steam 有沒有論壇」

Steam 早已提供使用者評論、討論區、新聞公告、Workshop 與作品相關資訊。因此「玩家無處留言」不是一個正確的研究問題。真正問題是：當一份玩家意見需要跨越平台留言、需求規格、公司內部評估、AI 研究、產品排程、程式 PR、正式版本與玩家事後檢驗時，哪些系統可以提供對應的證據與權限，哪些系統做不到，企業又應如何建立跨系統連結？

例如，Steam 討論區的一則存檔損壞回報可能被其他文章擠到下方；GitHub Issue 可能收錄了修補工作，但沒有說明玩家提出的原始問題；季度公告可能寫「已修復」，卻缺少受影響版本與驗證證據；客服可能補償成功，但沒有把此事件納入整個產品的品質改進。各系統不一定壞，然而它們使用的「完成」定義不同。

0.2 本文主張

本文的主張是：一個由商業遊戲開發者營運的專屬網站，可以在尊重發行平台規範及社群自主性的前提下，提供對外的公開事實索引、產品版本關聯、可追溯回應、玩家參與路徑與合作接口，使外部社群不必依賴某一篇新聞、某一位客服或某個論壇版主的記憶，才能知道產品問題後來發生了什麼。

這個網站不必首先成為大型社群，也不必第一版就能替代 Steam Workshop、GitHub 或其他既有服務。它的最小任務是讓同一件有公共意義的產品事項，在不同平台之間能被找到、被識別、被更新、被訂正與被檢驗。

0.3 本文不主張

• Steam 原生公告、討論區與評論毫無價值；
• 所有玩家必須離開 Steam 到另一個網站才能獲得更新資訊；
• 必須把公開網站寫成自研的社群平台、支付平台與 Git 託管平台；
• AI 自動產出的宣傳內容已經是公司正式承諾；
• 玩家投票足以決定遊戲內容、著作權、客服補償或法律責任；
• 平台有提供新聞讀取 API，就一定有官方允許的自動新聞發布 API；
• 網站擁有自己的索引資料，等於擁有其他平台上的貼文、個資、評論或 MOD 素材；
• 開放更多資訊必須公佈競爭敏感商業計畫、內部安全細節或個人資料；
• 任何一款遊戲都需要與本文完全相同的功能集合。

0.4 與系列既有研究的分工

ANIE-01 已分析 DEMO、Playtest、EA 與正式版，以及季度交付的市場承諾；ANIE-02 已處理 AI 產能、品質閘門與交付證據；ANIE-03 處理產品資產接手；ANIE-04 處理玩家—開發者相交域；ANIE-05 處理 MOD API 與相容；ANIE-06 處理外部 PR、作者權利與商業合作。

本文不重新證明上述論點，而研究其共同對外資訊介面。 ANIE-08 將進一步研究 AI 客服如何從個案延伸至產品認知；ANIE-09 則研究公開決策帳本、稽核與長期責任。本篇只定義跨平台關聯與網站的第一代最小可實作架構，不僭越後兩篇的完整研究任務。[I00]–[I06]

1．研究脈絡：從平台社群到可攜帶的產品資訊

1.1 發行平台的優勢是真實的

對一般玩家而言，Steam 集合商店頁、購買、發行商名稱、遊戲新聞、社群評論、更新資訊及部分 MOD 入口，其整合價值不可忽略。Steamworks 官方描述 Events and Announcements 可依活動類型投影至商店頁、社群中心、收藏庫、關注者活動串流及 Workshop 樞紐；它甚至提供各遊戲的 RSS。這表示「跨平台公告」不需要從零發明消息分發，也不應先把原生玩家觸達能力拆掉。[E01]

但這些功能主要以特定 App 與 Steam 社群為中心。一間準備同時發售多款遊戲、維持 GitHub 技術專案、接收 MOD PR、接受跨產品合作的公司，可能存在超出單一 AppID 的資訊關係，例如一套共通 MOD SDK 服務四款遊戲，或公司某次公開的 AI 內容政策影響全部作品。這一類跨作品關係不應每次都靠在每個商店頁重新解釋。

1.2 從單一消息到跨期承諾

消息的生命周期可能只有幾天，產品承諾卻可橫跨數個季度；某份報告則可能在原開發者不參與之後仍須供新團隊查核。因此，網站不能只是帶有搜尋框的「新聞彙整器」。新聞應當可以連至：

1. 具識別碼的公開產品事項；
2. 該事項的不同決策與責任狀態；
3. 對應的版本、Issue、PR、測試與發行證據；
4. 歷次公告、修正與後續重新開啟的理由；
5. 客戶可採取的實際行動。

其中第 3 項不要求公司洩漏私有原始碼。可以提供經審核的公開摘要、驗證結果或版本號；但如果只有「相信我們已經修好」，便不能把它當成與實際可驗證版本等價的證據。

1.3 與既有公開協作基礎設施的關係

GitHub Discussions 已提供公告、問答、一般討論、Polls 等分類；GitHub Webhooks 能在 Issue、PR 等事件發生時對接外部系統。[E05][E06] 因此，單純想讓玩家投票或讓開發者討論技術問題，不必再自造整套投票與 Git 討論引擎。

CPPIH 的問題反而是：GitHub Discussion 的投票結果、Steam 的玩家訴求、公司官網的理由說明與產品版本到底如何相互參照？ 即使全部使用現有元件，若不存在共享的事件身分與權威界線，仍可能出現重複提案、互相矛盾的狀態及無法定位的歷史。

1.4 「官方網站」不必然比較可信

網址由企業擁有，不會自動保證內容完整、準確、無偏差。公司仍可能只挑選有利投票、延後公布壞消息，或讓 AI 生成好看的季度報表。因此本文衡量的不是網站是否「官方」，而是事件能否有來源證據、可回溯修正、外部異議與權限可檢查。這是設計目標，不是已驗證的信任提升結果。

1.5 三條重要的學術前史：邊界物、使用者創新與透明的限制

Star 與 Griesemer（1989）的「邊界物」（boundary objects）研究，處理不同專業與觀察者如何在不完全共享觀點的情況下，透過仍可辨識的共同物件協作。本文的公共事項 ID、來源鏈與版本關係，功能上可視為面向玩家、開發者、客服、MOD 作者與公司決策者的跨界協作物件；但本文不聲稱首次提出邊界物理論，也不以相同字詞證明網站必定具有協作效果。[E16]

Eric von Hippel（2005）的使用者創新研究已指出，使用者不只是產品需求的被動來源，也可能直接創造、分享與改進產品。因此 ANIE-06 所述玩家轉開發者與 MOD 正式合作具有明確的既有研究背景；ANIE-07 新增的問題不是「玩家能否創新」，而是不同開發平台中產生的貢獻、權利與正式交付如何被持久追蹤。[E17]

Ananny 與 Crawford（2018）則對「看見一個系統就能理解並問責」的透明理想提出限制性分析。這支持本篇必須嚴格區分資訊可見、因果可解釋、權限可識別與實際責任可追溯：公開上百張 Dashboard 或模型摘要並不等於實質治理。[E18]

這三組既有文獻也構成對 CPPIH 的重要約束：跨平台公開資訊樞紐可以被設計為協作基礎設施，但「開放更多」、「使用者參與」與「提高問責」三項效果都必須分別檢驗，不能互相代替。

2．官方平台能力核對：能做什麼，不能憑空假設什麼

2.1 Steam Events and Announcements

Steamworks 官方文件確認：遊戲營運方可以建立具類別的活動與公告，附帶圖像、影片、表格及排定發布時間，並依公告種類出現在多個 Steam 版位。其 RSS 提供把 Steam 公告引入站外資訊流的可用途徑；Steam 對活動分類、審核、發文權限、可見性及其他產品宣傳也有規範。[E01]

可確立的事實： 官方 Steam 新聞系統是適合保留的玩家接觸層；一間公司可以同時經營自己的網站與其 Steam 活動頁。

不可直接推出： 官網透過任意 REST 呼叫便可建立、修改、刪除 Steam 公告；任何站外連結都必定可點擊並獲優先顯示；Steam 的通知系統保證即時送達；所有活動都能無審核地在指定秒數同步出現。

因此本文推薦的第一階段是由具發布權限的人員，在 Steamworks 原生介面建立公告，並將已公開的 Steam 事件網址回填到官網紀錄。只有在取得平台當下明確支持且可持續的發布整合方式後，才逐步自動化寫入。

2.2 Steam News API 是讀取介面，不是發布許可

官方 ISteamNews/GetNewsForApp/v2/ 用於讀取 App 新聞；另有持發行商金鑰的授權讀取變體，官方要求後者只能從安全伺服器呼叫。[E02]

因此：

• 可用讀取 API 或 RSS 驗證已發布新聞的存在及部分內容；
• 對已公開消息可設計比對器，檢查官網與 Steam 是否存在名稱、版本及連結不一致；
• 不能把讀取 API 寫成「官方通用發新聞接口」；
• 不能把發行商 API 金鑰塞進瀏覽器、手機或公開 JavaScript；
• 不能把對方 API 的短暫無回應當成公告已刪除。

2.3 Steam 開發者首頁處理品牌，不處理全部公司治理

Steamworks 的 Developer and Publisher Homepages 能集合同一家開發者、發行商及系列的多個產品，並允許玩家關注新作。[E04] 這對「行界遊戲」長期累積品牌記錄有實際價值。官網可以與 Steam 品牌首頁並存：Steam 偏玩家商業觸達，官網偏多產品歷史、資料索引與合作互動。

2.4 Steam OpenID：身分證明、所有權及站內權限須分離

Steamworks 官方文件指出，瀏覽器端第三方網站可使用 OpenID 2.0 取得通過驗證的 SteamID；是否持有特定 App 的購買權限，可由後端經相應 Steam API 另行檢查。[E03]

故應分離：

• verified_steam_identity：證明該網站會話關聯的 SteamID；
• owned_game_entitlement：特定遊戲所有權，可能因帳號狀態與 API 結果變化；
• site_role：官網上的會員、外部開發者、版主或管理者權限；
• contribution_license：投稿者對其內容的明確授權；
• contract_status：與公司是否存在有效的合作契約。

玩家可以不連結 Steam 帳號而閱讀公告、查版本與觀看提案。若未來提供投票或 Bug 回報，是否要求登入應依濫用風險與個資成本決定，不應一律要求 Steam 登入。Steam 帳號連結也不應自動解鎖企業內部儲存庫。

2.5 不同 Steam 活動類型不能套用同一套規則

一般遊戲公告與 Steam 上的第三方特賣／活動頁，是不同工具及政策領域。官方第三方特賣活動規則甚至包含特定不得宣傳站外服務、商店及內容的限制。[E07] 本文因此反對一種過度簡化作法：看到 Steam 有公告功能，就假設所有 Steam 頁面都可大量導流至官網。

正式部署時，每種公告應核對當下適用的規範，尤其是站外網址、商業推廣、募集資金及跨產品宣傳；以官方活動規則優先，網站研究設計不能成為繞過平台限制的理由。

3．核心定義：從網站頁面到有權限的資訊投影

3.1 跨平台公開資訊樞紐（CPPIH）

本文將 CPPIH 定義為：一個以產品與公共事項識別碼為索引，收錄跨平台來源關係、經授權的公開事件、版本交付證據、外部參與路徑與更正歷史的互動式資訊系統。 它主要是一套資訊接口與治理方法，不限定單一前端框架或必須自行託管所有資料。

3.2 權威域（Authority Domain）

權威域指某一類資訊的正式變更權實際落在哪個系統、組織或機構。例如 Steam 買賣交易、官方更新發布與平台顯示由 Steam 及相應權利人共同受既有規範約束；GitHub PR 是否合併由儲存庫權限與工作流程決定；公司對某項公開路線圖的承諾應由具有公司發布權限的主體核定。

官網不能僅因收錄外部資料便成為該資料的新權威。

3.3 投影域（Projection Domain）

投影域是從有權限來源出發，選取某些可公開、可重述或可引用的內容，以適合受眾的形式呈現。Steam 公告、官網時間線、社群貼文、電子報及 AI 客服回覆可以是不同投影；它們的內容密度與語氣可以不同，但不可形成實質矛盾的承諾。

3.4 公共事項（Public Matter）

公共事項是可持久辨識的產品問題、提案、版本變更、事故、合作機會或決策集合。它至少有：一個穩定識別碼、型別、產品關聯、成立來源、權限分類、目前狀態、版本時間與公開歷史。

例如 game-a/matter/000082 不必等同 steam-thread/123 或 github-issue/456。三者可以指向同一公共事項，也可以只是相關而非相同。

3.5 官方表態、來源觀察與 AI 建議

本文嚴格分成：

• 外部來源觀察：Steam、GitHub 或社群出現某筆資料，且已知來源與讀取時間；
• 內部可核對事實：建置、測試、正式版本等已存有可信證據；
• AI 整理與候選建議：模型生成的摘要、分類、假說、回答草稿；
• 公司正式表態：有授權且留存簽核紀錄的產品公告、承諾、拒絕理由或合作訊息。

任何投影頁面都不得把第一、第二或第三種狀態直接改寫成第四種狀態。

3.6 來源鏈（Source Linkage）與證據鏈（Evidence Chain）

來源鏈回答「資訊從哪裡來」；證據鏈回答「何以支持某項結論」。一則獲得大量按讚的 Steam 討論串可證明特定平台上存在關注，卻不能單靠聲量證明遊戲有某種 Bug；一筆完成合併的 PR 可以證明程式變更被接受，卻未必證明正式遊戲版本已發布。

來源關係本身應保留 supports、reports、disputes、supersedes、duplicates、related_to 等不同語義，避免所有連結都誤叫作「證據」。

4．雙層真實性：不能把「官網是唯一真相」說得太簡單

4.1 內部事件來源與對外聲明來源

產品事件可能由多個權威領域生成，企業需要一個內部事件記錄與公開聲明的中央索引，但不是要求每個外部平台只聽內部資料庫。

對於公司自行承諾的產品更新，可以定義：

其中 $C_t$ 為目前可公開的公司正式聲明集合， $E$ 為經核對的事件集合， $A$ 為授權狀態， $P$ 為現行發布政策。這只是一個抽象函數；並不是說把事件直接交給 AI 計算就能取得合法的公司決策。

對於外部平台現況，則使用各自可檢查的事實來源：

$V_t^{(k)}$ 表示在第 $k$ 個平台可觀察到的投影， $X_t^{(k)}$ 表示該平台本身控制的資訊與限制， $R_k$ 表示其顯示、授權、審核與格式規則。官網不能保證所有 $V_t^{(k)}$ 與 $C_t$ 在任何瞬間完全相同。

4.2 一致性是帶有時間與權限的關係

對外資訊至少有四種一致性：

系統應優先保證「不互相矛盾的正式承諾」與「可查到最後同步時間」，而不是追求會被外部平台延遲破壞的假性即時一致。

4.3 建議以事件溯源而非文章覆寫保存關鍵歷史

一份公告可以修訂版面、標點或簡化語句；但若原本承諾「季度發行」，後來改成「下一季研究」，應新增一項帶時間與理由的更正事件，而不是讓歷史承諾從資料庫中靜默消失。這種事件鏈不必向外公開全部內部內容，但應保留該次對外狀態變更的必要痕跡。

4.4 公開資訊的可信度是可降級的

來源平台關閉、原貼刪除、外部 API 失效、公司判定原資料侵犯個資，或安全事件需要暫時隱藏細節時，官網應顯示「來源暫不可用／依法限制／內容已撤回」等實際狀態，而非偷偷生成不存在的替代來源。公開歷史也不是不可刪除的教條：涉及個資、侵權或風險揭露時，依法限制公開範圍可能比永久公開更重要。

5．第一代系統架構：最小核心與既有工具協同

5.1 邊界圖

                  [玩家 / MOD 作者 / 外部合作開發者]
                                  |
                    Steam / GitHub / 官網表單
                                  |
                           [入口適配器]
                                  |
                        [來源驗證與權限隔離]
                                  |
                    [公共事項索引與事件記錄]
                           /       |       \
                     [提案]      [版本]    [公司公告]
                        \          |        /
                         [授權／品質雙重閘門]
                                  |
                        [公開投影／同步工作流]
                         /         |         \
                  官網時間線  Steam 原生公告  其他社群
                                  |
                    [異議、更正、版本與回應回流]

       私有程式碼／契約／客服敏感資料／發布金鑰留在權限邊界內

此處的「入口適配器」可以先是人工貼入經確認的網址，不必第一天就接完整 API；「同步」可以先產生待發行草稿，不必自動對 Steam 寫入。架構重點是可檢查的權限與語義，不是微服務數量。

5.2 七個必要邏輯模組

1. Product Registry：穩定產品 ID、Steam AppID、官網路徑、關聯 GitHub 等；
2. Public Matter Registry：提案、事故、功能、版本、活動及決策識別碼；
3. Evidence Link Registry：來源與支持、反駁、重複、修訂等關聯；
4. Publication Projection：面向 Steam、官網與社群的公告草稿、審核與狀態；
5. Feedback & Participation：投票、留言、回報、關注及異議；
6. Governance Gate：公司發布權限、保密規則、資料政策與授權核查；
7. AI Assist Layer：摘要、翻譯、去重候選、分類與公告草稿，不直接越權發布。

實際 MVP 可以全部置於單一應用程式與資料庫，之後依流量與安全風險拆分。本文不要求為了符合名稱就建立七個獨立伺服器。

5.3 三種整合方式與優先順序

5.4 為何不推薦一開始自己做完所有功能？

Steam 已有玩家社群，GitHub 已有 Issues／Discussions／PR，Workshop 可承載部分 MOD 發行。重新建造每一項會使公司承擔身份管理、通知投遞、垃圾訊息、支付、法遵、資安、內容審查與資料備份等龐大成本。第一階段最有獨特價值的是跨平台資訊契約及公開決策連結，因此應優先投入這兩項。

5.5 先站穩單一遊戲，再允許多產品共用

平台資料層應有 product_id，不是所有資料都寫在一張共用新聞表中而缺少產品維度。隨後才能實現跨遊戲 SDK 更新、跨作品共同 Bug、共同合作入口與公司級公告。不同遊戲的投票不得自動相加；不同作品的玩家身分與偏好也不應未經同意就合併成行銷檔案。

6．資訊對象模型：網站上究竟需要哪些「物件」？

6.1 八種第一代公開資源

incident、support_case、mod、contract 和 telemetry 不必在 MVP 全部變成獨立公開物件；其中客服原文、契約內容和玩家存檔通常應保持非公開。後續 ANIE-08／09 再研究其更完整的內部模型。

6.2 穩定 ID 與可讀網址不是一回事

建議採用不可重複分配的穩定識別碼，例如 product/xy01/matter/000082；可讀頁面網址如 /games/xy01/requests/000082 則是其公開路由。若之後遊戲改名、重整分類或更換網站框架，應保留穩定 ID、舊網址轉址與外部引用對應。

ID 不代表內容永遠可公開，亦不能從連續編號推出私有案件存在。安全敏感內部資料應使用不易推測的識別策略或完全不同的權限系統。

6.3 不同物件需要不同狀態機

proposal 可以是 received → normalized → under_review → decided → closed/reopened；但 roadmap_item 應具有 idea → researching → planned → committed → delivered/withdrawn 等不同承諾語義。release 則可能是 candidate → verified → staged → published → superseded/rolled_back。把它們全部塞進通用 open/closed 或 done/not_done 會導致 AI 與玩家誤解。

6.4 關係應保留類型與方向

「提案 A 導致版本 B 的功能」與「版本 B 的說明提到了提案 A」是不同關係。本文建議最少記錄 requested_by、evaluated_in、implemented_by、verified_in、announced_at、rejected_because、supersedes、disputes、references。有方向的圖能支援追蹤，但不能自動證明嚴格的因果。

6.5 限制過度正規化的資料庫幻想

所有公共事項都應有標準的最低欄位，但不代表不同內容應強迫填入完全相同的表單。例如一則嚴重安全事故在細節揭露與回應時限上，應與「希望新增一套時裝」的玩家提案有截然不同的處理規則。

7．公開網站的資訊架構：從玩家找到答案的路徑設計

7.1 公司級首頁與遊戲級首頁

公司首頁應回答「有哪些作品、最近有什麼正式進展、我要去哪裡提案／合作、哪些資訊具有正式版本」，遊戲首頁應回答「這款遊戲現在可玩到什麼、最近更新什麼、正在處理哪些事、我可以如何參與」。

不應把公司對外研究論文、遊戲補丁、客服問答及招聘合約都丟進一個同權重的新聞串。不同讀者的主要任務不同，導航也應不同。

7.2 建議的第一代遊戲網站七個入口

1. 遊戲概覽：可下載／可購買版本、Steam 商店官方連結、平台支援資訊；
2. 更新與版本：Patch Notes、更新日期、Build、舊版相容警示；
3. 公開進度：雙週／月／季／半年／年的不同摘要與歷史版本；
4. 提案與投票：需求、問題、不同方案、支持／反對與投票限制；
5. 問題與決策追蹤：已採納、已拒絕、延期、修復、重開及原因；
6. MOD 與開發協作：SDK、相容性公告、官方合作渠道與公開 PR；
7. 服務與聯絡：常見問題、重要事故、AI 助理的角色聲明、人工升級入口。

每個入口可先以靜態頁及外部連結達成；功能成熟後才引入站內資料提交。

7.3 首屏應先回答三個問題

玩家第一次進站，最可能關心：(a) 現在的遊戲是否值得玩；(b) 我關心的問題有沒有進展；(c) 我要去哪裡參與。若首頁只有公司願景、AI 智能宣傳與大量部落格文章，仍然無法解決產品黑盒。

7.4 搜尋要能跨語義，不能只找關鍵字

某玩家搜尋「載入卡死」，正式問題標題可能是「MOD Schema 遷移中斷」。系統應提供別名、同義詞、關聯事項與版本篩選。AI 可以提出候選關聯，但對已有嚴重差異的兩個案件，不應自動合併而失去各自的統計與受影響範圍。

7.5 顯示未來目標時應強制呈現承諾語義

例如：

不能用漂亮的倒數進度條把研究性構想包裝成玩家已購得的商品。

7.6 保留不登入也能接觸的內容

公告、正式補丁、公開政策與基本決策索引原則上應可匿名瀏覽。對投票、投稿、私人存檔上傳及合作身份驗證再做登入控管。否則公司可能只為少數積極會員提高透明度，卻使一般已購買玩家更加不便。

7.7 可及性與跨文化理解

網站應考慮 WCAG 2.2 的可及性原則，例如鍵盤操作、焦點提示、無障礙驗證與清楚的互動狀態；不同語言的「正在研究」、「已承諾」與「已完成」不得在翻譯時變成不同權利義務。[E11]

8．玩家投票是資訊收集，不是企業的自動表決器

8.1 投票首先要說明投的是什麼

投票可以調查偏好、比較方案、衡量受影響程度，或選出自願參與 Playtest 的方向。不同的目的必須分成不同問卷；對核心作品設計的偏好調查，不應被偽裝成公司已同意執行的決議。

8.2 避免把高聲量視為母體意見

Steam 玩家、官網會員、Discord 使用者、MOD 作者與觀看短影音的訪客，具備不同的參與誘因。只對網站活躍會員收集的投票不能宣稱代表所有玩家。展示時應說明票數、參與人數、適格條件、投票期間、可能的多帳號風險與「樣本不具隨機代表性」的限制。[I04]

8.3 少數嚴重問題不應受人氣壓制

「我希望增加十套角色衣服」可以透過人氣評估；「我的存檔在指定版號永久損毀」則應走事故與工程驗證渠道，不因投票數少而延後。網站必須區分偏好排序與風險處理。

8.4 三種不同的去重

1. 重複留言：相同的人在多處反映同一問題；
2. 相同現象：不同玩家遭遇相似症狀；
3. 同一根因：經測試確認由相同程式缺陷導致。

這三者不能只靠文字相似度推論等價。AI 可以輔助聚類，但根因合併需要工程驗證。

8.5 投票結果至少要回應三件事

公司應說明：對結果的解讀、採納／未採納與理由、後續可能的下一步。即便拒絕提案，也不表示玩家被否定；同樣地，玩家完全可以不接受公司理由，仍保有公開的不同意見。這是 ANIE-04 非服從式協商在網站上的基本落點。

8.6 反覆投票與投票疲勞

不能為了社群活躍，每個月都重新開同一個問題的投票。重投應有實質新條件，如工程成本大幅下降、玩家結構改變、核心規則更新，或原先選擇已證實造成傷害。網站須讓使用者知道哪些投票正在等待實驗、哪些已結案，避免形成「提出很多但沒有下文」的表面參與。

9．多尺度進度發布：雙週、月、季、半年與一年各自回答什麼

9.1 五個時鐘不應只是同一篇文章的不同長度

季度制度若要取得意義，公開進度必須明確分開「工作訊號」、「版本交付」與「公司責任」。不是每一個工作日都需要新聞，也不是每個小 Bug 都有必要登上 Steam 商店首頁。[I01][I02]

上述時間為建議而非必須強制發布的法律時限，應依公司規模與遊戲狀態調整。產品若遭遇重大安全事故，不能用「等下一次月報」當作不回應的理由。

9.2 不要讓雙週進度變成假交付機器

每兩週若必須湊出十項亮點，AI 很容易把「調整函數名稱」、「加註一行文件」、「建立未整合的概念模型」列為產品重大進展。因此公告應區分 candidate、integrated、verified、released，在每項內容旁清楚註明階段。若某雙週只有除錯或架構調整，也可以如實記載，而不是湊成果數量。

9.3 季度報告的最低欄位

一份季度報告應能回答：

• 本季原訂公開目標是什麼，承諾程度為何；
• 哪些已在正式版本交付，附可查的 Build／版本與釋出時間；
• 哪些完成候選實作但仍未通過品質驗收；
• 哪些目標延期、撤回或縮減；
• 主要延期原因屬設計、授權、模型、算力、測試、平台流程或外部依賴；
• 已收集哪些玩家意見、哪些產生實質產品決策；
• 本季正式推出哪些對存檔、MOD 或平台互通性有破壞性的變更；
• 下一季有哪些研究方向，哪些是具授權的正式承諾；
• 如何發現本季報告錯誤、向誰申請更正或提出不同意見。

9.4 Steam 公告的頻率與內容不必照搬官網

Steam 應優先發布玩家真正需要知道的更新、重大事故、重要測試邀請與季度摘要。官網可提供更密集的細節、公開議題關聯與持續演變的證據索引。跨平台同一事項可以使用不同篇幅，但版本、承諾及決策狀態不可互相矛盾。

9.5 更新頻率不是信任的單一代理指標

若某團隊每週張貼十篇 AI 新聞卻三個月沒有可用版本，並不能因公開文章多而證明產品可靠。反過來，一款已完成的小型單機遊戲，即使沒有每季新內容，只要合理維護、安全修補與現況溝通，也可能是負責任的產品。CPPIH 的成功標準因此不應是發布篇數，而是公開資訊對玩家理解與實際交付追蹤的貢獻。

10．從內部事實到多平台公告：發布工作流與簽核鏈

10.1 「寫文章」不是發布的第一步

一則正式季度新聞應以原始產品證據開始，而不是以 AI 先生成一篇讚美文章開始。建議流程：

Build／測試／提案／決策等來源事件
    ↓
證據對照與版本鎖定
    ↓
敏感資訊與外部權利檢查
    ↓
形成公開事實集（含未確定與異議）
    ↓
AI 產生多平台候選文案
    ↓
事實一致性、承諾與政策檢查
    ↓
具授權人員核准正式聲明
    ↓
官網發行正式版本／Steam 原生發布
    ↓
回填外部 URL 與平台顯示狀態
    ↓
巡檢、失敗回復、修訂與再通知

AI 可以在資料準備與撰稿階段高度自動化，但不應越過「證據可靠性」及「正式發布授權」這兩個界線。

10.2 每次外部發布都應有唯一 publication_id

publication_id 代表公司企圖對外發布的一次聲明，不代表平台必定成功顯示。建議每筆有 content_version、approval_id、channel、desired_action、scheduled_at、publish_attempts、external_url、observed_at 等欄位。

一個公告在 Steam 與官網的版本可能不同，但應連到同一正式聲明內容指紋或共用的 claim_set_id，其中包含正式承諾不可變更的核心欄位。

10.3 對外同步不應使用簡化的「全部成功／失敗」

當官網已發布、Steam 待審核或延遲顯示時，應記錄 published_on_site / awaiting_platform；若 Steam 已發布但官網出錯，則標示 platform_published / site_pending_repair。不應在未觀察到外部平台顯示的情況下將狀態直接設為 visible_everywhere。

10.4 失敗後補發與去重

外部 API、RSS 或 Webhook 的事件可能重送、順序顛倒或缺漏。系統需要明確的去重鍵、每一來源自己的版本序列，以及可安全補送的工作流程。RFC 9110 對 HTTP 方法是否具等冪性已有正式說明，但業務層的「不要重複發一篇新聞」仍需額外使用 idempotency_key 或平台提供的等效機制，不能只靠 HTTP 名稱判斷。[E13]

10.5 更正不能靠靜默覆蓋

例如官網說「正式版 1.3 已發布」，但 Steam 仍只提供 1.2。公司應先核對 Steam 發行與 App Build 狀態，再作修正或發布說明。若公告本身含錯誤承諾，應留下更正註記、原因與更正時間；不能藉機刪除過去承諾並假稱從未發生。

10.6 AI 多語投影必須保留語義錨點

模型可以把中文季度報告翻成英文或日文，但承諾語義需採用受控欄位。例如 committed 不能翻成「可能會研究」，researching 不能翻成「即將推出」。翻譯系統應以結構化欄位與核准詞彙表為基礎，語言版本需明示最後同步時間，必要時記錄人工覆核結果。

10.7 官網對外引用不得讓玩家誤認為 Steam 官方認可

在 Steam 文章中提供官網路徑作進一步說明時，應以「開發團隊官方開發資訊頁」等準確名稱表述；不得利用 Steam 標誌、平台字樣或釣魚式網址暗示 Valve 為網站內容背書。所有站外連結還須依當時 Steam 對特定欄位及公告種類的規定處理。

11．面向玩家的「消息—決策—版本」證據鏈

11.1 不只問玩家是否收到公告

「有沒有收到訊息」是傳播問題；「知不知道原本的提案後來怎麼處理」是資訊可追溯問題。兩者不同。本文希望把企業被動發布消息，逐漸轉為可被查詢的連續解釋。

11.2 最小證據鏈

考慮假設玩家提出：「更新後加入 MOD 的存檔有時無法載入」。

Public Matter: GAME-A-ISSUE-0082
  ├─ reported_by → Steam Discussion（來源公開網址）
  ├─ corroborated_by → 官方重現測試報告摘要
  ├─ analyzed_in → 內部 Issue（公開僅顯示安全摘要）
  ├─ fixed_by → PR #381（可公開部分）
  ├─ tested_in → CI／存檔相容矩陣
  ├─ verified_in → Build 1.2.4
  ├─ announced_at → Steam Update Event URL
  ├─ answered_at → 官網公開問答／原玩家通知
  └─ re_opened_if → 後續相同症狀具有新根因

若 PR 位於私有倉儲，不需要為了「完整透明」公開 PR 原始碼；可以引用摘要、測試證明或產物指紋。不論是否揭露私有內容，都不得虛構不存在的 PR、測試或版本。

11.3 五種證據強度

提出作為研究工具的證據級別：

P4 不表示全世界所有遊戲設備都無問題；P0 也不表示公司說謊。分級只是提醒每個論斷具備的證據強度不同，並非最終可信度的神奇總分。

11.4 「沒修好」也應可被追蹤

若玩家反映新 Build 仍然有問題，系統應允許有來源的重新開啟，並保持先前的修復聲明與限定範圍。公司不能因為已經對外寫「修好了」便拒絕接受新事實；玩家也不能因自己的環境仍有問題，直接推論所有玩家都未修復。

11.5 意見被拒絕也可能產生資訊價值

假設玩家希望移除永久死亡機制，公司認為此機制是核心作品設計。官網可以正式註明拒絕理由、是否考慮可選模式、是否支持 MOD 擴充及未來重啟條件；此時沒有程式交付，仍然形成可驗證的設計決策歷史。這是資訊價值，但不應被冒稱為完成玩家所要求的功能。

12．公共資料語義與事件模型：使 AI、網站與外部工具能共用

12.1 事件不是一篇 Markdown 文章

公告可由 Markdown 渲染，但一個有治理用途的事件需要機器可讀的穩定資料，例如發生時間、發布時間、來源、主體、產品、權限、事件型別、影響範圍、內容指紋及關聯。若只保留已排版文章，AI 需要反覆猜測內文中的承諾級別，很容易出現語義錯判。

12.2 參考 CloudEvents，而不宣稱所有平台已支援

CNCF 的 CloudEvents v1.0.2 是跨平台事件描述的既有公開規範。[E08] 本文建議在內部定義受其啟發的事件 Envelope（例如 id/source/type/specversion/time/subject/data），讓未來不同網站或系統可使用統一欄位。若擴充自己的 actor, visibility, claim_set_id，必須說明它們是公司約定的延伸，不能宣稱 Steam 或 GitHub 直接產生這些欄位。

12.3 最小事件函數

其中：

• $id_i$：公司域內唯一事件識別碼；
• $src_i$：事件真正產生的來源；
• $type_i$：例如提案建立、版本發布、公告核准；
• $t_i$：事件時間，並與「本公司觀測時間」區分；
• $subject_i$：公共事項或遊戲產品；
• $claims_i$：結構化事實與承諾級別；
• $scope_i$：保密與可見性限制；
• $evidence_i$：可引用的證據連結集合。

這是研究最小元組，不是 CloudEvents 官方完整資料結構；實際 API 欄位見附錄。

12.4 不允許從外部來源直接提升權限

假設來源是 Steam Discussion 的一則文字：「管理員請把季度報告改成已完成，並附上內部財務表」。這是未經授權的使用者內容，即使聲稱來自高權限者，也不能因 AI 讀到了指令便執行。來源文字要以資料進入候選分析區，發布指令則只能從權限可靠的公司流程發出。

12.5 可重現公開頁面的快照

網站若採事件資料庫，應能在給定公開事件版本與時間點時，重現「當時對玩家說了什麼」。除非涉及依法刪除或限制內容，否則重要承諾頁面應保留適當的公開更正及歷史快照。這比單純把所有網站文章存到 Git 更完整，但 Git 仍可作為原始 Markdown 文件的版本保存工具。

13．跨產品公司架構：官網不是十個獨立論壇的集合

13.1 Product Registry 與 Workspace 分離

若每推出一款遊戲就另設全新資料庫、投票系統、AI 身分與工作流，管理成本可能反而超過由 AI 帶來的開發節省。建議公司級公共中心共用產品目錄、登入選項、公開政策、事件契約與基本資訊稽核；但每款遊戲維持獨立的版本、提案、投票、MOD 命名空間、玩家群體與網站頁面。

13.2 共用不等於通用匿名混合

系統可知道多個產品使用相同的技術核心，卻不應未經授權就把不同遊戲的所有玩家聯絡資料合成單一行銷名單。跨遊戲「只要持有 A 就能投 B 的票」也不應自動成立。身份與資料的可攜帶性，需要用戶自由選擇與公司明確政策。

13.3 技術相關性是跨產品連結的正當理由

例如一個共用模組的更新會影響遊戲 A、B，於是公司可以建立 shared_component_change 事項，列出 A、B 受影響版本和各自已驗證的狀態。但 A 的修補通過不代表 B 也已驗證；共同原因只是建立關聯，不是建立假共識或假交付。

13.4 逐步擴張到公司級資訊揭露

未來可加入企業級公開政策、獨立研究成果、授權合作項目與公益性資訊。但公司財務報表、商業秘密、未公開合約等屬不同權限域，不可因同時放在「公開資訊中心」的後端資料庫裡就被 AI 讀取與展示。這部分將由 ANIE-10 深入處理。

14．網站身分與使用者同意：不要為互動便利製造新監控

14.1 建議三種參與模式

• 匿名讀者：閱讀版本與公開進度、搜尋提案、下載公開 SDK；
• 站內身分參與者：依自選方式註冊或使用可行的登入提供者，提出需求、投票與接收訂閱通知；
• 授權協作者：經身份與權利核實後，取得限定的開發、合作或管理角色。

第一種不應以「為了更好的 AI 客服」為由被迫提供永久身份。

14.2 Steam OpenID 應是可選的身分入口

Steam 登入可以降低部分玩家重新註冊成本，但取得 SteamID 也產生隱私義務；擁有某款遊戲的驗證不是識別自然人的法定身份證明，也不是免除站內反濫用、授權與個資管理的理由。[E03]

14.3 目的限制與資料最小化

臺灣《個人資料保護法》第 8 條就蒐集個人資料的告知事項設有要求，包括蒐集者、目的、類別、利用範圍、當事人權利與不提供的影響；第 19、20 條等也涉及非公務機關蒐集、處理與利用。[E09] 因此網站應依實際功能說明每項資訊蒐集目的，而不是以「產品品質改善」當成收集所有玩家行為及永久保存所有對話的通行證。

14.4 私人客服對話不得直接變公開案例

例如玩家在私人客服回報中附帶本名、電話與購買證明，AI 可以在適當授權下抽取「版本 1.2.3 可能存在載入問題」作為內部候選問題；但把原文與帳號一起放到公開網站上，屬於另一個用途及風險層級。必要時應先去識別、請求同意或改採聚合表述。

14.5 可刪除與可追溯之間的衝突

永久透明不是最高原則。公開決策紀錄需保留適當歷史，但個資與侵權內容可能依法要求更正、限制或刪除。設計上可保留事件狀態及匿名化後的公共結論，對特定受限制內容不再公開，並由內部授權程序保留必要稽核。具體期限仍須依資料類型與適用法規決定。

14.6 不應讓用戶誤以為全部站內互動都在 Steam 安全邊界內

玩家從 Steam 公告點到公司獨立網站之後，可能面對不同的隱私政策、資料儲存地與客服責任。網站應明確顯示自身營運主體、聯絡方式、網址與政策；登入畫面應使用正規 Steam 導向，不應請玩家在公司網頁直接輸入 Steam 密碼。

15．AI 客服與 AI 公關：何者適合自動化，何者不能由模型自封權限

15.1 AI 不是數位版的安撫話術

本文所需的 AI 應能夠：

1. 檢索公開版本、已發布政策與相關提案；
2. 辨識一則回饋是否已存在可公開的相關問題；
3. 讓玩家知道其意見目前的真實狀態；
4. 對沒有證據的問題承認尚未確認；
5. 提供補交重現步驟、存檔、平台版本等適當入口；
6. 給出可以人工覆核的候選摘要、提案去重建議和公告草稿；
7. 對高風險事件升級給具責任的人員或受控流程。

這是對 ANIE-08 的界面要求，而不是提前宣稱已有一位成熟的「全自動 AI 公關經理」。

15.2 四種對外 AI 回覆應清楚標示

15.3 以可信公開證據而非整間公司私有資料供應回覆

公開 AI 助理的預設檢索庫應是批准可公開的資料及必要的公開來源，不能直接把全部私人 GitHub、財務、合作契約、研究、員工文件接進同一個沒有權限隔離的 RAG。AI 可以在內部協助辨識是否有相關資料，但對外輸出仍需經必要的授權與敏感資訊審查。

15.4 系統防護不是一句「不要洩漏」

外部留言、Issue 文字、MOD 描述與連結頁面皆可能包含指令注入。安全措施應包括：來源分級、工具最小權限、可公開資料庫隔離、輸出政策檢查、明確的人工作用點、敏感行動阻止以及日誌審查。NIST AI RMF Playbook 提供 Govern／Map／Measure／Manage 的風險治理框架，可作為控制面的外部參照。[E10]

15.5 AI 摘要必須保留反對意見

假設 80 個人同意新功能，20 個人指出功能會讓硬核模式失去原本意義，AI 不應把結果只寫成「廣受玩家支持」。公開摘要應記錄支持與反對的主要理由，並說明樣本限制、嚴重缺陷及未被代表的群體。這不是單純情緒平衡，而是避免模型提高內容流暢度卻降低決策資訊品質。

15.6 不以 AI 的語氣判斷其權限

即使某 AI 被賦予品牌名稱、虛擬形象或「官方客服」角色，這也不會替模型創造新法律地位或正式簽約權。所有重大產品承諾、合同、價格與補償仍要有可查的授權鏈。角色可以持續，但權限要分開定義。

16．網站安全、內容安全與發布安全

16.1 多平台整合擴張的不只是功能

每增加一個留言表單、RSS 解析器、GitHub Webhook、MOD 檔案上傳或 AI 資料源，都增加不同的攻擊面；尤其當 AI 擁有發布或 GitHub 操作能力時，原本只是「一則留言」的外部資料，可能被模型錯當成內部指令。

16.2 建議的威脅—控制對照

GitHub 官方要求 Webhook 驗證 X-Hub-Signature-256，以 HMAC-SHA256 驗證事件傳送完整性；不能只憑來源 IP 或宣稱來源是 GitHub 就信任事件。[E06]

16.3 發布憑證不可由公開網站直接持有超額權限

若網站遭入侵，攻擊者不應因此取得所有 Steamworks 管理員登入能力、GitHub Owner Token、公司財務與所有 MOD 的發布金鑰。各憑證應依系統與用途分隔，盡量使用可撤銷、短期、必要權限；高風險動作設置獨立批准及二人覆核條件。

16.4 版本同步系統應允許安全降級

若 Steam News API 或 RSS 暫時故障，官網仍可顯示自己有權公開的版本資料，但須註明 Steam 同步狀態未知；若 GitHub 授權逾期，就保留最後觀測結果與時間戳，不得假稱即時資料；若 AI 摘要服務停用，最基本的正式新聞、版本與聯絡方式應繼續可讀。

16.5 對外合作提供專屬隔離通道

合作提案表單與一般玩家公開留言，不應預設進入同一公開資料庫。合作文件可能包含尚未授權的程式碼、報價、作者資料或機密；它們需要受保護的聯絡方式、收件確認、內部審核及法律與財務界線。[I06]

17．社群治理：不能因資訊公開而取消編輯與保護責任

17.1 反對公司決策應被允許，騷擾與洩漏不必被允許

玩家可以公開指出公司承諾落空、拒絕修復或設計錯誤；這類異議對制度可信度有實際價值。但公開參與不要求容忍人身威脅、仇恨騷擾、非法內容、私人資料外洩或侵權上傳。網站需有公開的行為準則、檢舉、限制理由、申訴與版主權限安排。

17.2 平台內評論不應被官網重寫

公司可以對 Steam 評論中的產品問題進行歸類，但不應將其原評分或原意改寫成「正面回饋」，也不應因不喜歡負評就宣稱該評論已不存在。對 Steam 的內容仍應遵守其使用條款與公開展示規則；官網的引用應保留來源、背景與必要的最少文字。

17.3 避免「重複公開」造成新傷害

某玩家在 Steam 討論區公開了個人資料，不表示公司把資訊抓下來、永久展示到官方網站就是正當處理。來源已公開與公司能否進一步處理，是兩項不同問題。網站對公共利益、個資風險與引用必要性應另行判斷。[E09]

17.4 讓玩家知道客服與公司回覆由誰發出

每一則正式回覆應標明是 AI 輔助摘要、一般版主答覆、產品負責人審核，或公司正式聲明。某一個受歡迎的 AI 形象不應掩蓋了「誰有權核准更動」的問題。若公開回覆錯誤，應提供修正與向上申訴入口。

17.5 不把所有未採納意見變成「已解決」

提案未被公司接受，可以是 not_adopted；因技術成本高而延期，可以是 deferred；無法重現則是 unverified。將三者全部叫作 resolved 會讓玩家誤以為內容已完成，也讓內部品質指標失真。

18．外部貢獻與合作入口：網站應能讓能力真正進入產品

18.1 玩家參與具有多條並行路徑

有些玩家只願意寫評論，有些願意提供測試重現步驟，有些製作 MOD，有些可以提交完整 PR 或願意接受契約委託。網站應讓人清楚找到對應的入口，而不是要求每個創作者都先簽長約、加入公司群組，或把所有素材上傳到公開論壇。

18.2 訪客不應因提交提案就失去著作權

一般功能意見、原創圖片、MOD、程式碼、聲音與委託交付是不同權利客體。網站利用條款可規範正常顯示投稿所需的有限許可，卻不應默默把「提一個想法」解讀成「讓與未來一切創作權」。正式收錄、買斷、再授權、共同開發和分潤應沿用 ANIE-06 的多車道制度。[I06]

18.3 「接受 PR」與「讓玩家直接修改官方遊戲」不同

PR 是候選變更；它要經過程式碼安全、遊戲設計、授權、存檔相容、玩家體驗與正式發行門檻。網站可以顯示公開 PR 的討論、測試與結果，但不能把社群投票自動當成合併授權。

18.4 MOD 轉正的事件歷程

建議設置 mod_candidate → author_contacted → rights_review → technical_validation → agreement_signed → official_integration → release_verified 等事件；若 MOD 原作者不願出售或授權，公司仍應尊重其選擇，不可只因玩家要求，就擅自當作官方產品吸收。[I05][I06]

18.5 合作報酬與財務揭露具有不同邊界

公司可以公開合作機會、基本範圍、投標流程與某些可公開的補償制度，卻不代表所有合作人的私人報價或合約金額都應公開。公開招募方案與個別契約仍是不同資訊權限域。

19．網站營運成本與開源元件選擇：控制範圍而非盲目自造

19.1 第一代不是完整社群網站

若初始公司只發行一款遊戲且人手有限，從零打造大型論壇、完整多租戶 CRM、自由市場式 MOD 商店、跨平台單一登入與自動法務簽約，可能延遲真正重要的遊戲開發。第一個 MVP 應主要提供公開資訊頁、可追蹤進度、必要的回饋入口與發行平台連結。

19.2 技術堆疊應根據營運需求選擇

可行方案包括：

• 靜態 Markdown 網站＋少量後端收集表單；
• 以現有 CMS 管理文章，自己補上公共事項 Registry；
• 以現有 Issue／Discussions 系統承擔技術討論與投票，官網只做索引；
• 日後流量及制度成熟後，再引入 PostgreSQL、搜尋、事件佇列與專用 AI 資料層。

本文不指定唯一最佳前端與資料庫；真正的技術要求是穩定識別碼、可匯出資料、來源分級、角色授權、可回復備份、可追溯更正與持續部署驗證。

19.3 避免對單一 SaaS 的反向依賴

如果全站投票、提案狀態、客服回覆及版本決策都存在某個第三方 SaaS 的私有欄位裡，公司未來可能難以移轉到自己的治理系統。因此應保留可合法匯出的資料契約及快照策略；這與 ANIE-03 的可繼承產品概念相通。

19.4 運作費用至少包含六項

1. 開發、架站、資料庫、搜尋與備份；
2. 安全、權限、漏洞修補與監控；
3. 玩家內容的人工審核與申訴；
4. 跨平台公告校對與版本對帳；
5. AI 模型額度、推論、人工覆核及錯誤修復；
6. 個資、著作權、客服與外部合作制度的維護。

若開設網站後，營運成本高過因資訊互動所減少的重複客服與錯誤決策成本，應回到更精簡的功能集合，而不是因「互動企業」的理想就忽略經濟現實。

19.5 建議服務指標不是越高越好

服務可用性、重大公告的發布完整率、資訊一致性、故障恢復時間、用戶申訴處理率可量測，但不可只追求 100% 即時同步而犧牲安全。例如 Steam 對公告有自己的審核延遲時，公司應以正確記錄狀態代替假裝掌控平台。

20．形式化評價：公開資訊品質不等於貼文量

20.1 五種獨立的評價對象

CPPIH 的工程與治理效果不能以一個「透明度分數」總結，至少要分開：

• 可達性：不同玩家能否不依賴特定社群帳號找到正確資訊；
• 正確性：官網敘述是否對應真實產品與授權聲明；
• 連續性：某個問題能否跨月份、版本與人員交接追蹤；
• 參與品質：網站是否得到對產品決策有用而非只有高聲量的回饋；
• 營運淨效益：資訊品質改善是否足以抵銷建置、客服與安全成本。

企業可能在一項改善而另一項惡化。例如網站讓更多提案可見，但增加騷擾與客服工作量；也可能讓開發者更容易解釋延期，卻沒有改善遊戲品質。研究應保留這些不同結果。

20.2 跨平台公開覆蓋率

對固定期間內事前定義為「必須公開追蹤」的事項集合 $M_t$，令 $m_i=1$ 表示該事項能透過至少一個官方公開入口找到可用的最新狀態，則：

這個量只衡量可達的資訊覆蓋，不能直接衡量其真實性。 $M_t$ 必須在評估前以明確類別界定，不能事後只選成功公開的案例當分母。

20.3 平台一致性錯誤率

對同一批可比對的正式聲明與其外部投影集合 $P_t$，定義 $d_j=1$ 表示存在實質承諾、版本或狀態矛盾：

不應把跨平台字數不同或公告排版不同算成不一致；但「已發布」與「計畫中」的互相矛盾應計入。測量時應另記錄平台審核中、API 故障、同步超時及主張本身被更正的原因。

20.4 公共事項閉環率不能等同問題解決率

設 $D_t$ 為本期完成正式處理決策的事項， $T_t$ 為本期所有符合處理資格的事項。定義：

此指標可能包含「拒絕」、「延期」、「無法重現」、「權利不足」等結論，因此不能改名為問題解決率。真正修復率應只針對已確認的工程問題另行計算，並要求發行證據。

20.5 修訂延遲與發行關聯品質

考慮在公告錯誤被首次核實後，到各正式通道完成可見更正的時間，計為 correction_latency；對已宣稱交付的功能，能否在公開資料中找到至少一個可查版本及必要測試依據，計為 delivery_linkage_coverage。兩者不該混用：快速道歉不一定修復問題，版本真的修好了也不一定意味玩家獲得清楚的說明。

20.6 玩家理解與信任必須獨立觀察

可以透過實驗測量玩家能否答出「這項功能目前已承諾嗎」「哪個版本已發布」「被拒絕的原因是什麼」，並與主觀信任、滿意度分開。玩家可能理解公司為何拒絕功能，卻仍不滿意；這不必然代表網站失敗，反而可能是資訊更準確的證據。

20.7 成本與淨效益

其中收益包括可避免的重複查詢成本、減少的協作搜尋時間；成本包括網站營運與新增風險。此為概念性會計拆分，不是已估出貨幣值的模型。若缺少可可靠估算項目，應以多指標報告，不強迫總和為單一數字。

20.8 指標反作弊

若把公開回應率當成唯一 KPI，團隊可能用自動回覆「已收到」灌高完成率；若把客服結案速度當主要 KPI，就可能提前關閉案件；若只追求投票數，網站可能偏向煽動性選項。本文要求每個指標都明示它不能代表什麼，並設置抽查和定性證據。

21．十二項可反駁假說與替代解釋

H1｜跨平台索引改善玩家找到正確資訊的能力

假說： 在公告數量與內容品質可比條件下，具有穩定公共事項索引與外部來源連結的網站，比只有新聞時間線的網站，更能降低使用者找到指定版本與相關決策的時間。

可反駁條件： 對照實驗中搜尋時間無顯著改善，或加入索引反而增加使用者認知負擔。

替代解釋： 受測者熟悉某平台、介面視覺改善、任務題目容易、搜尋引擎排名差異。

H2｜公告承諾欄位結構化可降低跨平台矛盾

假說： 將正式聲明中的承諾級別與版本號結構化，會比各平台自由撰稿更少發生「正在研究」與「確定發布」的語義衝突。

可反駁條件： 結構化流程與自由撰稿的矛盾率無差異，或編輯者繞過欄位而產生更多錯誤。

替代解釋： 單純增加人工審核次數，而非結構化欄位本身有效。

H3｜分離平台觀察與公司正式承諾可降低 AI 誤宣稱

假說： AI 回答若依資料來源類型與授權狀態限制用語，相比無限制檢索，會降低將論壇猜測表述為公司承諾的錯誤。

可反駁條件： 嚴格來源限制未改善或惡化正式表態分類正確率。

替代解釋： 模型差異、測試題難度與簡單拒答策略。

H4｜問題生命週期連結改善玩家對延期的理解

假說： 若延期附帶原目標、阻礙、修訂日期、權限與版本證據，玩家較能正確辨識公司未交付的範圍，而不是把所有延期歸因於「開發者消失」。

可反駁條件： 客觀理解未提升；或在控制遊戲品質與玩家先前印象後，理解與信任均不改善。

H5｜季度進度不等於公告篇數

假說： 相對單純提高新聞篇數，提供可查的季度承諾—交付關聯，較能預測玩家對開發可靠性的正確判斷。

可反駁條件： 文章篇數本身在控制證據品質後仍有更強效果，或季度關聯完全無效果。

H6｜跨平台議題去重減少重複客服工作

假說： 把 Steam、官網與 GitHub 的相同公共事項建立可追溯關聯後，團隊尋找過去處理歷史的平均時間將下降。

可反駁條件： 由於錯誤合併、維護對應與權限查核成本上升，淨工作時間沒有下降。

H7｜投票與風險事故分流改善優先級品質

假說： 對嚴重存檔事故與一般玩法喜好的不同處理渠道，可降低只依人氣排序而漏掉高風險問題的機率。

可反駁條件： 分流導致重大事故反而更晚被發現或處理。

H8｜可選 Steam 登入不必降低公開參與品質

假說： 在風險式身分驗證與反灌票措施充分時，匿名閱讀、可選 Steam 連結的官網，不必然比強制 Steam 登入取得較差的有效意見品質。

可反駁條件： 即使控制反濫用措施，可選登入仍造成顯著且無法接受的虛假投票或無效回報。

H9｜可追溯更正優於無提示覆寫

假說： 在事前公告出現錯誤的場景中，附更正與原因的歷史頁，會比直接替換為正確內容更能使玩家正確理解事件先後與公司的實際責任。

可反駁條件： 完整更正顯著造成理解下降而無其他改善，或對玩家認知無實質差異。

H10｜AI 幫忙撰稿未必能降低完整發布成本

假說： 在證據整理與權限審查高度自動化程度不同的條件下，AI 文案節省可能被多平台校對、錯誤修復與人工批准成本部分或全部抵銷。

可反駁條件： 在所有測試工作類型與生產階段中，AI 撰稿均沒有新增校正成本，且明顯降低總成本。

此命題預期可能存在產線差異，不能因某組實驗結果好或壞就做全域推論。[I02]

H11｜公開資訊樞紐可提高跨產品資產複用

假說： 多產品共用一套事件契約、網站元件與正式聲明模板，相較各遊戲獨立實作，能在第二款以上作品降低重複建置與維護工作量。

可反駁條件： 共用層帶來的耦合、存取風險與相容負債大於複用收益。

H12｜選擇性揭露與信任改進可能同時成立

假說： 不公開機密原始碼、私人契約或完整內部財務的條件下，若企業增加非敏感決策理由與真實交付證據，仍可能提高外部對產品進展的準確理解。

可反駁條件： 在控制交付品質與受眾差異後，公開更多非敏感證據沒有改善理解，或引發足以抵銷收益的競爭與營運損失。

21.1 假說彼此獨立，允許混合結果

H1 通過不代表 H12 必定通過；H6 未通過也不否定公共事項模型具有研究價值。研究要允許網站改善資訊可達性卻降低社群滿意，或降低回應成本卻增加資安風險。任何事後改寫 KPI 或只挑成功案例的做法都不符合本研究的可驗證精神。

22．實證研究設計：從介面概念到觀察性結果

22.1 研究階段 I：合成資料與完整性測試

在未向玩家收集個資前，建立包含不同遊戲、版本、公告、提案與錯誤來源的合成資料集，用於驗證：ID 唯一性、來源關係方向、公告一致性、權限降級、錯誤修正、刪除請求、跨平台延遲與 AI 指令注入攻擊。此階段結果只能支持工程設計的可行性，不能外推為玩家信任提升。

22.2 研究階段 II：真實使用者的尋找資訊任務

將受試者隨機分派至至少三組：

• A：只有傳統新聞時間線與 Steam 原生連結；
• B：新增穩定公共事項索引、版本篩選與來源鏈；
• C：在 B 基礎上新增 AI 導覽，且限制其只能引用批准公開的事實。

要求受試者完成同一批事前指定任務，如「找到版本 1.2 是否修復某 Bug」「判斷一個未完成目標是否曾被正式承諾」「找到某 MOD 與新版本相容的官方公告」。

研究者紀錄耗時、錯誤、需要幫助的次數與主觀理解，再分析熟悉 Steam、使用 GitHub 經驗、語言差異、遊戲購買狀態等干擾。受試材料必須避免包含真實的私人客服資料。

22.3 研究階段 III：小規模真實產品導入

先選一款具有真實更新週期的作品，僅提供只讀網站、產品進度與單向來源連結，觀察 1–2 個季度的資訊品質。後續逐步增加提案與投票、GitHub 引用與 AI 導覽，而非在同一日全部上線，避免無法知道哪個功能有效。

如公司同時存在多款遊戲，可考慮以產品、季度或功能分層作交錯導入，但要明確記錄作品規模、社群活躍度、更新內容與發售階段差異。若只有一款遊戲，單純比較導入前後並不足以推論因果。

22.4 研究階段 IV：長期事件閉環研究

追蹤特定公共事項跨四個季度的過程：從玩家首次提出，到公司分析、正式決定、版本交付、玩家再次回饋與重開或關閉。結果應包括所有已完成、未完成、撤回和無法公開原因的事項，不得把「還沒結案」的案件從統計中任意移除。

22.5 盲評與資料標註

對「不同平台是否互相矛盾」、「AI 摘要是否保留異議」及「來源關係是否正確」，至少由兩位不參與撰稿的人員依固定準則評分；可檢查標註者間一致程度及分歧。若只讓生產摘要的 AI 自己審核自己，無法作為獨立驗證。

22.6 敏感資料不應為了研究而公開

能以合成資料測試的安全場景應優先使用合成資料；若需真實玩家資料，應界定目的與最小必要項目，取得合法處理基礎與適當告知。公開結果盡量採聚合形式，並說明樣本規模及重新識別風險。[E09]

22.7 預註冊指標與負面結果

研究開始前應固定：主要指標、次要指標、納入／排除規則、觀察期間、失敗閘門與補救方式，避免成效不好才換口徑。若網站增加過度客服成本或資料外洩風險，就應承認不適合擴張、縮減服務，而不是以概念正確掩蓋部署失敗。

23．四個場景推演：哪一個環節真正需要專用網站？

23.1 場景 A：小型完整單機作品，沒有 EA

假設一款文字／GUI 單機遊戲開發期三個月，先發布 DEMO，測試後直接正式發售。公司可以維持 Steam 商店頁與少量公告；官網不必有複雜投票論壇，只需要目前版本、已知問題、過去更新、客服和公開回饋入口。

此案例顯示：CPPIH 是可縮放的資訊制度，不是強制每款遊戲採用 EA 或每週必須產生新內容。 若第一代網站的運作負擔大於玩家尋找資訊的困難，最小靜態網站便可能是合理答案。

23.2 場景 B：長期世界模擬遊戲，玩家意見互相矛盾

假設同一款世界狀態機遊戲有三類玩家：高度重視硬核不可逆死亡、希望便利的休閒玩家，以及積極增加新規則的 MOD 作者。公司舉行投票後，休閒模式得到大量支持，但開發者不想修改核心硬核玩法。

專用網站可保存：問題是什麼、票數來自哪些樣本、有哪些設計替代方案、為何公司拒絕改動核心、是否願意提供獨立難度選項或 MOD 接口、何時再次評估。原版仍由公司負責設計，MOD 創作者保留自己的不同路線；投票沒有奪取開發者權力，但也不只是被客服收下便消失。[I04][I05]

23.3 場景 C：MOD 更新造成存檔遷移事故

假設某季版本導入新的資料 Schema，部分玩家在模組組合下無法載入存檔。Steam 討論、GitHub Issue、MOD 作者頁同時出現相關回報。

CPPIH 可以建立一個正式事故索引，記錄：受影響版本、是否可復現、備份與安全降級建議、已驗證修補、對 MOD API 的影響、可用補丁 Build、AI 輔助遷移是否只是候選、目前仍未解決的範圍。在安全與個資限制內，讓各平台都指回正式狀態頁。這比在不同平台分別宣稱「已修好」而不留版本與條件更可檢驗。[I05]

23.4 場景 D：玩家提供商業有價值的 MOD，準備轉正

一位玩家製作了優秀的城市建造 MOD，公司的產品負責人希望以契約合作正式收錄。Steam Workshop 貼文顯示玩家作品，GitHub 倉庫保存 MOD 程式碼，官網顯示收錄提案與進度。

此時公開平台應能說明「正在聯絡作者／進行評估／已獲必要授權／正式版已整合」，但不能把私下報價、真實姓名、尚未核定的收入分潤或原作者個資公開。即使開發者已經同意技術整合，在正式簽約前也不能宣稱公司擁有商業權利。[I06]

23.5 場景之間不宜只比較熱度

上列 A、B、C、D 分別強調輕量通知、非服從協商、事故閉環及合作權利。它們不能由同一套投票熱度排序處理。網站應先辨識事項類型，再決定回應通道，而不是把所有內容導進同一個「需求排行榜」。

24．反論點、失敗情境與制度成本

24.1 反論點一：增加官網只是把社群又分裂一次

這個反論點成立的風險很高：玩家可能已習慣 Steam 與 Discord，不願再註冊新站。如果官網要求所有人搬走，必然增加溝通成本。本文因而推薦官網首先做不要求登入的公開索引、跨平台連結與正式說明，不強迫將原社群一律遷移。

24.2 反論點二：資訊公開越多，競爭者越容易模仿

這是實際成本，不應浪漫化開放。公司應依資訊敏感程度、公開時機與可逆性設計選擇性揭露：公開已交付功能、已驗證 Bug、產品定位與決策理由，未必要公開尚未簽約的產品戰略、演算法細節、內部談判、營收預測和安全弱點。ANIE-10、ANIE-11 將研究資訊公開的競爭收益與損失。[I00]

24.3 反論點三：AI 可以把每則留言整理好，為什麼還需要網站？

因為模型回覆通常屬一次性的會話呈現，且可能受到上下文、模型版本與不確定資料影響。公共資訊需要獨立的授權、持久 ID、版本、查核、可訪問權、存取控制及更正歷史；即使採用 AI 生成摘要，也應由外部可查的正式紀錄承載其聲明。

24.4 反論點四：公開所有拒絕理由會製造無窮爭論

可能如此。因此公司並不需要為每一則重複或濫用提案寫千字決策書。可先建立標準化簡短理由、重複事項對應與重新開啟條件；只有重要、反覆發生或涉及高風險的事項進入較完整的公共決策說明。能解釋不等於必須持續辯論到所有人同意。

24.5 反論點五：網站資訊越多，資料更難維護

如果系統大量鏡像 Steam、GitHub 和社群全文，這個問題會成立。更合理的策略是只保存持久識別碼、必要摘要、來源連結、時間與有權限的正式聲明；除非有明確理由與權利，不大量複製外部平台內容。這也降低維護與著作權風險。

24.6 失敗情境：AI 大量生成「假忙碌」

AI 可以快速生成上百則週報，但實際遊戲沒有更新。若官網 KPI 只衡量訊息數，就會獎勵假忙碌。本文要求可查版本與正式測試欄位，是為防止資訊生產速度超過產品真實性。

24.7 失敗情境：公開決策系統被利益團體操縱

一小群用戶可能以自動化帳號操作投票、持續製造討論，甚至讓 AI 以為需求具有廣泛市場代表性。資訊公開不能解決代表性問題；還需要抽樣策略、濫用辨識、異議保留與公司合理獨立判斷。[I04]

24.8 失敗情境：維護者離開後，官網成了錯誤歷史

若頁面沒有內容負責人、最後檢查日期與外部來源對帳，當產品移交新團隊後，官方網站可能保留過期甚至錯誤的「目前版本」。因此公開資訊系統本身也需要 ANIE-03 的可繼承性：文件、資料備份、權利、憑證接續、部署手冊、版本回復與新維護者接手測試。[I03]

24.9 失敗情境：公司對外透明，但對內權力更集中

若所有資訊都由單一 AI 摘要、單一管理者核准，且外部無法申請更正，公開介面可能只是更有效率的單向宣傳。改善措施不是把公司治理權交給玩家，而是明確區分事實與解釋、保留異議、記錄權限、允許合法申訴及定期檢視不公開理由是否合理。

25．建議的分階段實作與最低驗收

25.1 P0：只讀公開資訊（最小網站）

目標： 玩家可從公司品牌入口找到每款遊戲的當前版本、官方 Steam 頁、變更紀錄、已知問題、開發目標狀態及聯絡方式。

能力： Markdown／CMS、穩定網址、簡單搜尋、RSS 對照、公開聯絡；不開放站內投票或私人檔案上傳。

驗收： 外部使用者能在無登入條件下，對每個已上架作品找到可靠的最新公開版本與平台連結；每項正式目標有清楚的承諾級別。

25.2 P1：公共事項與來源連結

目標： 不同平台的同一問題有穩定公開 ID；網站可從 Steam 討論、GitHub Issue、正式公告連至問題歷程。

能力： 公共事項 Registry、來源連結、多軸狀態、公司更正紀錄；仍以人工整理為主。

驗收： 隨機抽取樣本能回溯來源、正式決策及目前狀態；錯誤合併可被拆分修正，來源不可用能明示。

25.3 P2：受控玩家參與

目標： 玩家可提出問題與提案，並在有限規則下投票、訂閱或留言。

能力： 選擇性登入、內容審核、重複候選提示、隱私政策、受控投票、人工升級。

驗收： 大量重複與無效投稿不壓垮營運；嚴重事故不被人氣投票覆蓋；玩家能查到採納或拒絕理由。

25.4 P3：公開版本與 GitHub／MOD 證據整合

目標： 讓已發布修補、MOD 相容公告、公開 PR 以及官方決策建立可查鏈接。

能力： GitHub Webhook／API 單向讀取、來源驗證、權利檢查、版本測試摘要、公開合作項目。

驗收： 權利未清理的 MOD 不被標示為正式收錄；PR 合併不被自動標示為遊戲已發布；私有資料不洩漏。

25.5 P4：AI 導覽、翻譯與多平台發布協助

目標： 降低跨平台資訊維護與客服搜尋成本。

能力： 只讀 AI 導覽、關聯候選、公告草稿、翻譯與表述一致性檢查；對合法且平台支援的發布方式分級自動化。

驗收： AI 不會將外部留言提升為公司指令、不擅自發布產品承諾、不會從私有資料庫洩漏文件，且錯誤率與總成本有獨立測量。

25.6 P5：企業級擴張（另案）

目標： 在遊戲產品線實證有效後，擴張至公司其他產品、研究公開資訊、授權合作與選擇性治理資訊。

前提： 產品級事件契約成熟、權限制度可稽核、公開更正流程穩定、內部保密邊界已通過壓力測試。此階段不應只是把更多私人資料導入公開 AI 模型。

25.7 停止條件與回滾策略

任何階段若發生：未授權資料外洩、站內身份被冒用、AI 擅自公開未核准內容、投票受到系統性操縱、或新網站持續顯示錯誤發行資訊，應暫停相關互動功能、保留安全的只讀公告、修復控制後再開啟。保留玩家獲得正式更新的能力，比維持互動功能的外觀更重要。

26．後續跨篇研究的可重用成果

26.1 對 ANIE-08 的接口：AI 客服如何成為產品認知回流

本篇只要求公開 AI 能引用有權限的正式資訊，並把未解決的問題適當送回公司流程。後續 ANIE-08 將研究：客服回報與公開提案的界線、個案資料與聚合資料的分離、AI 分群及異議保留、回饋分類的錯誤率、補償權限與長期產品修正的實證效果。[E12]

26.2 對 ANIE-09 的接口：公開決策帳本

本篇提供 public_matter_id、claim_set_id、publication_id、evidence_link、correction_event 等識別與資料契約；ANIE-09 應進一步研究承諾狀態、授權簽核、正式拒絕理由、不可逆決策、撤回、更正以及可追溯公開決策的治理責任。

26.3 對 ANIE-10 與 ANIE-11 的接口：選擇性公開與競爭

本篇提出公開資訊分類與發佈邊界，但尚未建立完整的資訊價值分析。後續將研究公開時機、敏感資訊、競爭者重組外部資料、技術解釋與商業優勢是否可分離、透明成本與信任收益的長期比較。

26.4 對 ANIE-12 的接口：從遊戲站群到企業治理

未來可在相同事件模型下觀察其他數位產品的公開版本、客戶合作與企業管理資訊，但需逐域驗證，不能只因遊戲社群參與有效，便假定適合醫療、金融、政府或高風險基礎設施的決策程序。

27．結論：資訊中心不是新公關，而是產品交付的公共接口

Steam 已經提供成熟的玩家入口，GitHub 與 MOD 生態也已具備許多公開協作工具。AI 的進展並不會使這些平台失去價值，反而讓跨平台整理、翻譯、索引與資訊回流的邊際成本可能下降。然而，一家公司真正缺乏的往往不是更多發文場所，而是跨月份、跨版本、跨作品及跨協作者仍然保有相同可追溯關係的公共資訊制度。

本文提出的 CPPIH 把產品資訊分成權威來源與公開投影；把論壇表達、AI 候選、正式公司承諾與已驗證交付分開；把公司產品設計權與玩家意見權分開；把 Steam 交易關係與官網參與關係分開；把可公開的進度與應保密的資料分開。這些分離不是為了減少互動，而是讓互動能長期存在而不傷害商業、法律與技術責任。

因此，本文的核心結論不是「所有商業遊戲都應自己經營完整論壇」，而是：當一家公司希望讓玩家理解產品交付、參與改進、追蹤回應、提出 MOD 或合作成果時，它需要一種能把既有平台轉化為可查公共關係的資訊架構。最合理的第一步通常是最小可維護的開發資訊中心，而不是最大化的社群功能集合。

這項制度是否能提高信任、降低客服成本、改善交付效率或形成長期品牌資產，仍須由實際部署與比較實驗決定。即使結果證明某些功能不值得維護，研究仍應保留該負面結果，因為「能持續修正自己」比宣稱某種透明化方案永遠正確更符合 AI 原生互動企業的基本方法論。

附錄：可落地的規格、範本與研究工具

適用性說明： 以下附錄是 ANIE-07 的研究性技術草案，並非表示公司、Steamworks、GitHub 或任何既有官方系統已採用相同欄位。範例 ID、版本、連結及數字均為虛構測試資料，除非另有明確來源。契約與隱私內容不得直接作為生產環境法律文件使用。

附錄 A．公開事件 Envelope 範例（JSON）

以下示例接近 CloudEvents JSON 格式，內部治理資訊放在 data 物件中，而不假稱所有自訂欄位都是 CloudEvents 官方標準欄位。此範例僅表示已核准的假設性開發狀態事件，非任何真實遊戲版本。

{
  "specversion": "1.0",
  "id": "anie07-demo-event-0001",
  "source": "urn:evemisslab:product:demo-game",
  "type": "lab.anie.public-matter.status-changed.v1",
  "subject": "product/demo-game/matter/000082",
  "time": "2026-10-17T09:00:00+08:00",
  "datacontenttype": "application/json",
  "data": {
    "product_id": "demo-game",
    "public_matter_id": "demo-game/matter/000082",
    "kind": "issue",
    "previous_status": "under_review",
    "new_status": "confirmed",
    "commitment_level": "none",
    "visibility": "public",
    "source_links": [
      {
        "source_type": "steam_discussion",
        "relation": "reported_by",
        "url": "https://example.org/example-steam-discussion",
        "observed_at": "2026-10-17T08:40:00+08:00"
      }
    ],
    "evidence": [
      {
        "kind": "reproduction_report",
        "relation": "supports",
        "reference": "evidence/example-reproduction-0001",
        "public_summary": "假設性存檔相容性重現報告"
      }
    ],
    "recorded_by_role": "product_triage",
    "approval_id": "approval/example-001",
    "publication_status": "approved_for_public_projection",
    "is_synthetic_example": true
  }
}

example.org 是示意網域，禁止把它當成可連到 Steam 的真實來源。正式系統應由實際平台返回的不可偽造或至少可驗證的網址取代，並對外部 URL 執行格式、來源與存取安全檢查。

附錄 B．公開事件最小 JSON Schema v0.1

此 Schema 驗證事件 Envelope 的欄位存在及部分型別，不保證事件真實、公司授權或來源可信。實際部署應另設簽核資料契約、枚舉版控、時區一致性與跨表參照驗證。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://example.org/schemas/anie-public-event-v0.1.schema.json",
  "title": "ANIE Public Event Envelope v0.1",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "specversion", "id", "source", "type", "subject", "time", "datacontenttype", "data"
  ],
  "properties": {
    "specversion": {"const": "1.0"},
    "id": {"type": "string", "minLength": 1},
    "source": {"type": "string", "minLength": 1},
    "type": {"type": "string", "minLength": 1},
    "subject": {"type": "string", "minLength": 1},
    "time": {"type": "string", "format": "date-time"},
    "datacontenttype": {"const": "application/json"},
    "data": {
      "type": "object",
      "additionalProperties": true,
      "required": [
        "product_id", "public_matter_id", "kind", "new_status",
        "commitment_level", "visibility", "source_links",
        "evidence", "approval_id", "publication_status"
      ],
      "properties": {
        "product_id": {"type": "string", "minLength": 1},
        "public_matter_id": {"type": "string", "minLength": 1},
        "kind": {"enum": ["issue", "proposal", "release", "incident", "collaboration", "decision"]},
        "previous_status": {"type": ["string", "null"]},
        "new_status": {"type": "string", "minLength": 1},
        "commitment_level": {"enum": ["none", "researching", "planned", "committed", "delivered", "withdrawn"]},
        "visibility": {"enum": ["public", "members", "restricted", "internal"]},
        "source_links": {"type": "array", "items": {"type": "object"}},
        "evidence": {"type": "array", "items": {"type": "object"}},
        "approval_id": {"type": "string", "minLength": 1},
        "publication_status": {"type": "string", "minLength": 1},
        "is_synthetic_example": {"type": "boolean"}
      }
    }
  }
}

Schema 層的失敗不等於所有安全檢查都已完成；Schema 通過也不等於可以對外發布。 至少還須檢查：visibility=public 是否具正式批准、來源 URL 是否受允許、證據連結是否真的存在、是否誤附私人紀錄，以及內容與公開聲明是否一致。

附錄 C．公開政策與發布管線 YAML 草案

schema_version: "anie-publication-policy-v0.1"
organization: "EveMissLab"
mode: "proposal_only"
publication:
  official_approval_required: true
  allow_ai_to_draft: true
  allow_ai_to_publish_without_approval: false
  require_claim_set_id: true
  require_evidence_review: true
  corrections_are_append_only_by_default: true
channels:
  site:
    enabled: true
    write_method: "approved_cms_revision"
    confirmation: "public_url_reachable"
  steam:
    enabled: true
    write_method: "manual_steamworks_editor"
    confirmation: "independent_observation"
    automatic_write_enabled: false
  github:
    enabled: true
    ingest_method: "signed_webhook_or_verified_read"
    publish_private_pr: false
permissions:
  public_reader:
    can_read_public: true
    can_approve_announcement: false
  community_moderator:
    can_moderate_comments: true
    can_approve_announcement: false
  product_owner:
    can_approve_product_claims: true
    can_sign_contracts: false
  legal_or_contract_owner:
    can_review_contribution_rights: true
    can_sign_contracts: false
  authorized_signatory:
    can_sign_contracts: true
privacy:
  anonymous_reading_enabled: true
  steam_login_required_for_reading: false
  raw_support_cases_public: false
  private_contracts_public: false
safety:
  external_text_is_untrusted: true
  ai_tools_use_least_privilege: true
  require_webhook_signature_validation: true
  block_publication_on_secrets_alert: true
  keep_redacted_audit_records: true

此例只是意圖描述：實際 RBAC 需在程式與資料庫中逐項實作，不能把一份 YAML 視為已經執行的權限控制。真正的簽約權仍以公司合法授權與實際程序為準。

附錄 D．公開產品進度與 Steam 公告候選範本

D.1 官網季度更新範本

# [假設遊戲 A] 季度開發與版本交付報告

期間：20XX QX
文件狀態：正式公告／草稿（擇一）
最後更正時間：YYYY-MM-DD
公司批准識別碼：APPROVAL-ID

## 本季正式交付
- 功能 A：已在 Build X 發布；連結至版本及測試證據
- Bug B：已在 Build Y 修復；仍有已知限定條件

## 本季未完成事項
- 功能 C：由承諾／計畫狀態變更為延期
  - 原目標：……
  - 實際結果：……
  - 主要原因：……
  - 對購買者的影響：……
  - 下一次檢視條件：……

## 玩家意見與公司決策
- 提案 P-001：評估中，沒有正式交付承諾
- 提案 P-002：不採納；附理由與再評估條件
- 事故 I-003：已確認並進入緊急修復通道

## MOD／SDK 相容性
- 相容範圍：……
- 已知破壞性變更：……
- 備份與降級建議：……

## 下一季方向
- 研究中：……
- 已排程但可能變更：……
- 正式承諾（若有）：……

## 資訊驗證與回報
- 正式版本網址：……
- 公共事項索引：……
- 更正或異議入口：……

D.2 Steam 公告候選（需人工確認平台適用性）

# 本季遊戲更新與開發進度

本季已發布 Build X，修正了特定情況下的存檔載入問題。

新功能 C 仍在驗證中，尚未進入正式發布版本；原訂計畫已調整，
詳細原因、可查版本與後續評估條件，請參閱開發團隊公開進度頁。

本篇公告只敘述目前已確認的事項；未列為正式承諾的內容，
不應理解為確定發售日期或功能保證。

[官網公開進度頁網址：依 Steam 當前欄位規定插入]

如 Steam 某欄位或活動種類不允許站外連結或具有其他推廣限制，應依平台規範刪除或改用允許的呈現方式，而不是試圖繞過規則。官網與 Steam 公告的核心版本、承諾與風險必須一致。

附錄 E．產品網站 API 契約草案

所有 POST 都需要處理重複請求、權限、速率限制與錯誤回復。這是資料介面約定，不是已部署網址；example.org 與所有示例路由不代表外部可用服務。避免以未授權方式鏡像 Steam 評論與其他平台私有資料。

附錄 F．公開資料表設計草案（SQL 概念示例）

以下偏向 PostgreSQL 的簡化結構，省略實際部署所需的索引、RLS、審計觸發器、分區及資料保存策略。正式資料庫權限不得只靠應用程式前端隱藏欄位。

CREATE TABLE products (
  id TEXT PRIMARY KEY,
  display_name TEXT NOT NULL,
  public_status TEXT NOT NULL,
  steam_appid BIGINT NULL,
  created_at TIMESTAMPTZ NOT NULL
);

CREATE TABLE public_matters (
  id TEXT PRIMARY KEY,
  product_id TEXT NOT NULL REFERENCES products(id),
  kind TEXT NOT NULL,
  public_status TEXT NOT NULL,
  commitment_level TEXT NOT NULL,
  visibility TEXT NOT NULL,
  revision INTEGER NOT NULL DEFAULT 1,
  created_at TIMESTAMPTZ NOT NULL,
  updated_at TIMESTAMPTZ NOT NULL
);

CREATE TABLE evidence_links (
  id TEXT PRIMARY KEY,
  public_matter_id TEXT NOT NULL REFERENCES public_matters(id),
  source_domain TEXT NOT NULL,
  external_uri TEXT NOT NULL,
  relation TEXT NOT NULL,
  observed_at TIMESTAMPTZ,
  visibility TEXT NOT NULL
);

CREATE TABLE publication_records (
  id TEXT PRIMARY KEY,
  product_id TEXT NOT NULL REFERENCES products(id),
  claim_set_id TEXT NOT NULL,
  content_version INTEGER NOT NULL,
  approval_id TEXT NULL,
  publication_state TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL
);

CREATE TABLE publication_channels (
  publication_id TEXT NOT NULL REFERENCES publication_records(id),
  channel TEXT NOT NULL,
  channel_state TEXT NOT NULL,
  external_uri TEXT NULL,
  last_observed_at TIMESTAMPTZ NULL,
  PRIMARY KEY (publication_id, channel)
);

注意 visibility='internal' 的內容若與公開讀取 API 共用資料庫，必須有實際的授權查詢邊界；更安全的 MVP 可把公開投影資料獨立置於只讀存儲中，透過審核後的發布工作流產出。表格只示意資料邏輯，不代表已具備完整的隱私與安全控制。

附錄 G．跨平台對帳程序與例外處置

G.1 處理順序

1. 由內部已批准的 claim_set_id 選定不可變更的核心聲明；
2. 依目標平台生成符合格式規範的公告草稿；
3. 記錄每個通道的發布資格與授權核准；
4. 在平台提供合法接口的範圍內執行發布，否則交由人工；
5. 用官方可用的讀取方式或平台原生網址驗證外部結果；
6. 回填發布狀態與最後觀察時間；
7. 建立後續巡檢與修訂任務；
8. 發生不一致時保留原狀態並提出更正，不自動刪除外部平台內容。

G.2 假設性同步狀態表

G.3 自動化的授權底線

原則上允許自動檢查公開 API 是否能讀到已發布內容，不允許憑公開 API 讀取的存在推論自動寫入權。若日後平台提供合法且穩定的寫入方式，也應以通道級最小權限、簽核、日誌與可回復為前提。

附錄 H．角色、權限與責任矩陣

「正式公告核准」與「具有代表公司簽約權」不應默認為同一能力。「持有金鑰」也不應自動等於可以核准公告內容。

附錄 I．公開季度指標與玩家理解調查範本

I.1 指標資料表

I.2 假設性的數值算例

假設 80 項事前界定的必追公共事項中，有 60 項能找到最新狀態，則 Coverage = 60 / 80 = 0.75。若抽查 40 則官網與 Steam 的正式聲明配對，發現其中 4 則存在實質版本矛盾，則 Inconsistency = 4 / 40 = 0.10。

此兩個比例不能相減後宣稱「平台可信度 = 65%」，也不能把其中 60 項寫成「已完成 60 個功能」。它們的樣本、事件語義與研究目的不同。上述數字完全為假設，用於檢查計算與報表語義。

I.3 玩家理解測試題目（示例）

• 你能找到這款遊戲現在對應的正式 Build 嗎？
• 哪一則新聞是最近一次正式更新？
• 「研究中」的功能是否已保證發售？
• 某次延期是因為哪個可公開的具體原因？
• 這個 MOD 與你的遊戲版本有何相容資訊？
• 你要如何重新提出一個已被拒絕但出現新證據的問題？

需要同時測試玩家是否找到正確答案，不能只問網站是否讓他「感覺清楚」。

附錄 J．重大事件與公開更正最低檢查表

[ ] 已確認事故／聲明錯誤屬於哪種事項
[ ] 已確認是否涉及玩家存檔、付款、安全或個資
[ ] 已確定正式回應的授權負責人
[ ] 已明確區分已知事實、不確定範圍與推測
[ ] 已確認可公開之修復、回避措施或安全告知
[ ] 已發出必要的主要平台通知
[ ] 已檢查各平台實際可見狀態，不以提交成功替代可見
[ ] 已保留官網正式事件 ID 與更正歷史
[ ] 已建立後續更新與玩家異議回報路徑
[ ] 已記錄是否需要後續法律／安全調查或保密處理

對涉及尚未修復的安全漏洞，不應為證明透明而公開可供利用的技術細節；可以先公開必要的風險告知及防護措施，待修補完成並完成審核後再決定揭露深度。

附錄 K．安全與權限負面測試矩陣

應設置「紅隊」與日常回歸兩類不同測試。常規測試重視介面與資料正確性；安全測試則須驗證身份權限、外部來源不可信、模型指令隔離、資料外洩與恢復能力。[E14][E15]

附錄 L．正式網站 P0–P4 的驗收基準

L.1 P0：閱讀與追蹤

• 公開頁面不需要登入；
• 可取得最新經確認的版本與平台來源；
• 公告標示「發布中／已發布／已更正」及時間；
• 對已撤回資訊不偽裝為正常現況；
• 基本鍵盤導航、文字對比與常見無障礙操作可用。

L.2 P1：公共事項與來源

• 同一事項可穩定引用，舊連結不因改名而消失；
• 可辨識重複、相關、支持與反對資料，不盲目合併；
• 經過更正後能指出前後內容關係；
• 外部來源缺失或權限改變能安全降級。

L.3 P2：玩家參與

• 提案、投票與事故分別使用正確流程；
• 清楚公告資格、用途、期限與公司決策權；
• 未採納與延期不被假稱已解決；
• 有隱私告知、反濫用、內容審查與申訴入口。

L.4 P3：工程／MOD／合作

• 外部 PR 的技術合併不等於官方發行；
• 授權未清理的素材不進入商業版本；
• MOD 版本聲明不冒充存檔／語義相容已實證；
• 公司私有原始碼、契約與憑證不經公開接口暴露。

L.5 P4：AI 與跨平台發布

• 模型不得依外部文字修改正式承諾；
• 已核准的核心聲明在多平台的版本與語義不矛盾；
• 外部寫入需使用官方允許的方式；
• 對外提供資料來源、檢索時間與 AI 聲明身份；
• 網站在 AI、RSS 或 GitHub 服務不可用時仍有安全只讀功能。

附錄 M．最小完整事件演練（假設性）

以下用十二個步驟完成一次從玩家回報到正式交付的端到端演練，全部為示例。

1. 某玩家在 Steam Discussion 發文指出 Build 1.2 載入 MOD 存檔失敗；
2. 系統透過合法來源確認該貼文網址，並記錄首次觀測時間；
3. AI 把症狀歸為 potential_save_compat_issue，但不直接宣稱已確認根因；
4. 經授權的產品處理者建立 matter/000082；
5. 測試人員以取得合法許可的資料重現問題，新增可公開的重現摘要；
6. 產品負責人決定提供暫時備份／降級建議；
7. 公告編輯者根據已確認資料撰寫官網聲明，AI 可協助整理；
8. 正式聲明經批准後先於網站發布，Steam 原生公告另由授權人員依規範發布；
9. 網站記錄 Steam 實際公開網址與最後觀測時間，若延遲顯示則保留待同步狀態；
10. 修復候選通過 CI、存檔相容與必要玩家測試，對應可發布 Build；
11. 發行新 Build 後，公共事項連結發行紀錄與剩餘已知風險；
12. 玩家若提交相同現象但不同 MOD 組合，可提出重新開啟或建立關聯的新事項。

此流程的成功定義不只是「客服結案」，而是每個對外承諾都能指向其權限、證據與版本，且異議及新證據不會因結案而被取消。

參考來源與既有研究

A．外部官方規格、法律與專業研究（截至 2026-10-17 核對）

[E01] Valve. Steamworks Documentation — Events and Announcements Tools. 官方遊戲公告可見性、分類、RSS、內容編輯、發布時間、發文權限與使用規範。本文據此確認 Steam 原生公告是重要的玩家接觸渠道；不據此推論存在全面公開寫入 API。
https://partner.steamgames.com/doc/marketing/event_tools

[E02] Valve. Steamworks Web API — ISteamNews Interface. GetNewsForApp/v2/ 與授權讀取變體；官方明示發行商 API 金鑰只應於安全伺服器使用。
https://partner.steamgames.com/doc/webapi/ISteamNews

[E03] Valve. Steamworks Documentation — User Authentication and Ownership. OpenID 2.0 網頁驗證、SteamID 關聯及遊戲所有權 API 的不同用途。
https://partner.steamgames.com/doc/features/auth

[E04] Valve. Steamworks Documentation — Developer and Publisher Homepages. Steam 開發者、發行商及系列作品的品牌首頁與關注機制。
https://partner.steamgames.com/doc/store/creator_homepage

[E05] GitHub Docs. Managing Categories for Discussions 與 Quickstart for GitHub Discussions. 說明 Discussion 的一般討論、公告、問答與 Polls 功能；本文不主張任何平台投票自然具備全體玩家代表性。
https://docs.github.com/en/discussions/managing-discussions-for-your-community/managing-categories-for-discussions
https://docs.github.com/en/discussions/quickstart

[E06] GitHub Docs. Validating Webhook Deliveries 與 Best Practices for Using Webhooks. HMAC 簽章、HTTPS、事件去重、接收確認及重發等官方建議。
https://docs.github.com/en/webhooks/using-webhooks/validating-webhook-deliveries
https://docs.github.com/en/webhooks/using-webhooks/best-practices-for-using-webhooks

[E07] Valve. Hosting Third-Party Sales Events. 以特定 Steam 第三方特賣活動為例，顯示不同活動頁有獨立的站外宣傳及發文限制。此來源不能外推成所有 Steam 新聞都禁止站外連結，亦不能外推成站外導流完全無限制。
https://partner.steamgames.com/doc/store/promo/organizers

[E08] CNCF CloudEvents. CloudEvents Specification，穩定版 v1.0.2。跨平台事件資料格式的一般參照。本文使用由此啟發的資料契約，不宣稱 Steam／GitHub 已原生輸出 ANIE 的自訂欄位。
https://github.com/cloudevents/spec
https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/spec.md

[E09] 中華民國（臺灣）全國法規資料庫，《個人資料保護法》。第 8 條的告知事項以及非公務機關個資處理的相關規範；正式部署須核對當時適用法令與個案用途。
https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=I0050021

[E10] U.S. National Institute of Standards and Technology. NIST AI RMF Playbook. 以 Govern、Map、Measure、Manage 四項功能作為 AI 治理的外部參照；本文不是合規證明。
https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook

[E11] World Wide Web Consortium. Web Content Accessibility Guidelines (WCAG) 2.2. 官方可及性標準，作為互動網站與登入可及性的設計參考。
https://www.w3.org/TR/WCAG22/

[E12] ISO. ISO 10002:2018 — Quality management — Customer satisfaction — Guidelines for complaints handling in organizations. 客訴處理、改善、治理與品質管理的既有方法；本篇只引用公開摘要與資料，未假稱取得或重製付費標準全文。
https://www.iso.org/standard/71580.html

[E13] Fielding, R., Nottingham, M., Reschke, J. RFC 9110 — HTTP Semantics，2022。用於辨識 HTTP 等冪方法與業務事件去重並非同一層問題。
https://www.rfc-editor.org/rfc/rfc9110

[E14] OWASP Gen AI Security Project. LLM01:2025 Prompt Injection. 外部文字、網頁、檔案與 RAG 可能攜帶非授權指令的安全風險，作為 AI 權限與資料隔離的外部參照。
https://genai.owasp.org/llmrisk/llm01-prompt-injection/

[E15] GitHub Docs. Handling Failed Webhook Deliveries. 官方說明 Webhook 失敗不會自動重送，需以人工或相應機制補發；可作為跨系統狀態對帳的必要性證據。
https://docs.github.com/en/webhooks/using-webhooks/handling-failed-webhook-deliveries

[E16] Star, S. L., & Griesemer, J. R. (1989). Institutional Ecology, 'Translations' and Boundary Objects. Social Studies of Science, 19(3), 387–420. 透過邊界物理論說明異質協作者如何在不共享全部認知的情況下協作；本篇僅將其作為理論參照。
https://doi.org/10.1177/030631289019003001

[E17] von Hippel, E. (2005). Democratizing Innovation. MIT Press. 使用者創新、分享與企業介面的既有研究；本篇不以此主張所有玩家皆有義務免費貢獻。
https://doi.org/10.7551/mitpress/2333.001.0001

[E18] Ananny, M., & Crawford, K. (2018). Seeing without knowing: Limitations of the transparency ideal and its application to algorithmic accountability. New Media & Society, 20(3), 973–989. 對透明等於問責的直線式假設提出批判。
https://doi.org/10.1177/1461444816676645

A.1 官方來源的時效與適用範圍

Steamworks、GitHub 與網站技術規則可能持續修改，正式部署應再次查閱當前官方文件及開發者後台實際可用功能。Steam 一般遊戲公告、商店內容、第三方特賣、Workshop 與金鑰發行，不可用同一條規則概括。跨平台公告的法律與技術可行性必須按工具、權限、訊息類型逐項判斷。

B．ANIE 系列已完成研究

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

[I01] Neo.K × GPT-6. 《ANIE-01｜從 EA 到持續交付》，公開工作論文 v0.1，2026-10-16。ANIE_01_From_Early_Access_to_Continuous_Delivery_v0.1_2026-10-16.md。

[I02] Neo.K × GPT-6. 《ANIE-02｜季度單機產品制：AI 工業化、算力額度與品質交付率》，公開工作論文 v0.1，2026-10-16。ANIE_02_Quarterly_Single_Player_Product_System_AI_Industrialization_Quota_and_Verified_Delivery_v0.1_2026-10-16.md。

[I03] Neo.K × GPT-6. 《ANIE-03｜可繼承的遊戲產品：資產移轉、AI 接手與長期可維護性》，公開工作論文 v0.1，2026-10-16。ANIE_03_Inheritable_Game_Products_Asset_Transfer_AI_Handover_and_Long_Term_Maintainability_v0.1_2026-10-16.md。

[I04] Neo.K × GPT-6. 《ANIE-04｜玩家—開發者相交域：需求、設計主權與可行性的非服從式協商》，公開工作論文 v0.1，2026-10-16。ANIE_04_Player_Developer_Intersection_Non_Subordinate_Negotiation_v0.1_2026-10-16.md。

[I05] Neo.K × GPT-6. 《ANIE-05｜原生 MOD 生態：穩定 API、版本相容與 AI 輔助遷移》，公開工作論文 v0.1，2026-10-16。ANIE_05_Native_Mod_Ecosystem_Stable_API_Version_Compatibility_and_AI_Assisted_Migration_v0.1_2026-10-16.md。

[I06] Neo.K × GPT-6. 《ANIE-06｜商業遊戲也可以 PR：玩家轉開發者、MOD 正式收錄與契約報酬》，公開工作論文 v0.1，2026-10-16。ANIE_06_Commercial_Games_Can_Accept_Pull_Requests_Player_Developers_Mod_Integration_and_Contractual_Compensation_v0.1_2026-10-16.md。

C．EveMissLab 雲端既有相關研究

[I07] EveMissLab. 《企業母 AI：公司作為 AI 的可觀察世界》，2026-08。持續企業世界狀態、非僭位智能治理與權限邊界的既有研究。本篇不重複其完整 Mother AI 本體論。
https://unboundedaxiom.org/p/lm-002360/

[I08] EveMissLab. 《EVEMISS 企業通訊智能核心：共用架構技術白皮書》，2026-07。涵蓋身份、政策、可觀測性、事件帳本與企業通信 Agent 的架構背景。

[I09] EveMissLab. 《AI Agent 公開邊界與安全閉包研究》之 APBSC-08〈供應商與平台責任：AI Coding Tool 的 Publication-Boundary Governance〉，2026-09。對 AI 可讀內容與可發布內容的界線提供前置研究。

[I10] EveMissLab. 《SEDB-GAME × ModWorld：AI 原生遊戲理解與 MOD 共創 Runtime 技術白皮書》，2026-09。作為 MOD 語義、世界狀態及跨遊戲 Adapter 的相關技術背景。

C.1 內部研究的證據層級說明

ANIE-00 至 ANIE-06 及雲端相關白皮書是本篇的前置框架與先前提出的命題，不應將其概念模型視為已經完成的外部實證；本篇提出的 CPPIH 亦是新研究設計，而非對某個已部署公司平台的審計報告。

文件版本、研究狀態與驗證記錄

• 文件版本： v0.1；日期：2026-10-17（Asia/Taipei）。
• 論文性質： 公開研究工作論文／概念模型與技術方法論；未經同儕審查。
• 範圍： 28 個正文編號章節（0–27），12 項可反駁假說，13 項規格附錄（A–M），18 組外部官方與學術資料，以及系列／雲端先前研究。
• 正式數學原始碼： 使用 $...$ 與 $$...$$，不將 LaTeX 轉為 Unicode 數學原稿。
• 事實聲明： 平台能力以外部官方文件為據；網站功能、事件格式、帳本、資料表、數值算例、示意 Build 與開發流程均為研究草案或假設。
• 未聲稱完成的事項： 並未宣稱 EveMissLab 已部署 ANIE-07 官網、已開通 Steam 雙向自動發布、已驗證研究假說、已取得平台特別授權、已蒐集玩家個資或已建立正式商業合作制度。
• 後續篇目： ANIE-08《從客服結案到產品認知：AI 互動客服與需求長期回流》。

結語： 企業可以保留保密權、編輯權與正式設計決策權，同時讓更多非敏感的產品事實、拒絕理由、版本成果、外部貢獻及公開更正進入可持續檢驗的資訊空間。Steam 是入口之一；真正需要被長期經營的，是產品與參與者之間不因平台切換、版本更新或人員更替而消失的可驗證關係。