title

商業遊戲也可以 PR：玩家轉開發者、MOD 正式收錄與契約報酬

english_title

Commercial Games Can Accept Pull Requests: Player–Developer Transitions, Official MOD Integration, and Contractual Compensation

series

AI 原生互動企業論

series_en

AI-Native Interactive Enterprise

series_id

ANIE

paper

06

part

第二部：玩家與外部開發者共創

author

Neo.K

institution

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

research_assistance

GPT-6（外部文件核對、理論形式化、制度設計、反例分析、實證規劃與原稿驗證）

version

v0.1

date

2026-10-16

language

zh-TW

status

Public Working Paper / Conceptual and Methodological Study / Not Peer-Reviewed

canonical_source

UTF-8 Markdown

math_delimiters

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

research_status

Conceptual and methodological design; contract templates are non-binding examples; no actual paid contribution program, production integration, or controlled experiment claimed

external_sources_checked

2026-10-16

related_papers

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

商業遊戲也可以 PR：玩家轉開發者、MOD 正式收錄與契約報酬

Commercial Games Can Accept Pull Requests: Player–Developer Transitions, Official MOD Integration, and Contractual Compensation

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

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

摘要

在傳統商業遊戲供應模式中，企業通常持有官方版本的整合、發行及品質責任，玩家則以購買者、測試者、評論者或 MOD 作者身分參與。這種角色區分具有契約、風險與工程上的理由，但並不必然要求參與者永久停留在同一身分。當遊戲正式提供資料擴充接口、玩家具備模組開發能力、Git 型版本控制允許外部提出候選變更，而 AI 逐漸降低程式理解、實驗與修補的技術成本時，原本被動回饋產品的玩家，可能直接提出可測試的修補程式、內容資料、工具、MOD，甚至接受一次性或長期付費委託。

本文的核心命題不是「任何玩家都應被當成公司的免費員工」，不是「商業遊戲必須完全開源」，更不是「GitHub 接受 Pull Request（PR）便自動取得投稿者著作財產權」；而是提出：商業產品可以在保留正式發行權、核心程式碼保密、品質閘門與既有法律責任的條件下，設計讓外部參與者合法地提交候選成果、受到審查、議價、簽約、獲得報酬，並在條件成立時進入正式產品的持續合作制度。

本研究提出「外部貢獻進入機制」（External Contribution Admission, ECA）、「權利—品質雙閘」（Rights–Quality Dual Gate, RQDG）、「玩家轉開發者路徑」（Player-to-Developer Pathway, PDP）、「貢獻—報酬契約」（Contribution–Compensation Contract, CCC）與「官方整合後責任移轉界線」（Official Integration Responsibility Boundary, OIRB）。ECA 把一般建議、免費社群 PR、MOD 展示、一次性授權、付費委託、持續維護與收益分成分成不同合作車道；RQDG 則禁止把「技術測試已通過」誤認成「商業使用有充分權利」，亦禁止把「授權完整」誤認成「作品品質足以合併」。

外部對照顯示，這並非完全空白的制度領域。GitHub 原生提供 fork／PR、CODEOWNERS、保護分支及不同 repository role；Steam Workshop 官方文件明確區分 Ready-to-use 與 Curated Workshop，也描述經選拔的創作者內容被納入遊戲、作為 DLC 及與作者另行議價的模式；Yochai Benkler 的 commons-based peer production 研究則早已質疑企業僱傭與純市場交易是唯一生產組織形式。然而，這些既有機制並未替一間 AI 原生、以季度持續交付單機遊戲的商業公司，完成跨越玩家意見、PR、MOD、權利清理、合約與獎酬的統一可追蹤工作流。[E01][E02][E03][E04]

本文特別以臺灣法律為初始司法轄區，區分著作權法第 11 條的職務著作、第 12 條出資聘請著作、第 21 條著作人格權、第 36 條讓與與第 37 條授權；並依勞動部指導原則說明「契約制」不因名稱而當然排除僱傭關係。Steam Workshop 條款亦須與公司欲另行取得的跨遊戲、跨平台及收費發行權區分，不能假設 Workshop 授權自動覆蓋所有公司商業整合情境。[E05][E06][E07][E08]

在 AI 方面，本文將代理系統定位為投稿整理、來源清單建立、侵權風險提示、候選補丁生成、測試補齊、維護成本預估與合約流程協助者；AI 不應自行承諾獎金、簽署有法律效果的授權、把來源不明的素材轉正，或讓未可信任 PR 透過 CI 取得內部秘密。為檢驗制度效果，本文提出 12 項可反駁假說、四組以上對照實驗、參與者權益與長期維護指標，以及從「只開放提案」至「經驗證的付費共創」的階段部署路線。本文僅提出制度、契約及研究方案，不聲稱 EveMissLab 已實施正式外部付費貢獻平台或已完成相關法務審查。

關鍵詞： 商業遊戲、Pull Request、MOD 正式收錄、玩家轉開發者、外部協作、開放創新、社群貢獻、付費委託、著作權、承攬與僱傭、開源授權、權利鏈、AI Agent、收入分成、貢獻治理、驗證交付、Steam Workshop、GitHub。

0．研究問題：為什麼商業遊戲不能接受 PR？

0.1 這是一個制度問題，不是 Git 指令問題

「商業遊戲也可以 PR」包含兩種不同含義。狹義上，PR 是開發者在 Git 協作系統提出程式碼變更，由具備權限者審查及決定是否合併的技術操作。廣義上，它可以象徵玩家與公司的新關係：外部人不只評價已推出的產品，還能提交具體修改，要求企業依明確程序處理，而不是只能等官方選擇是否理會某則留言。[E01]

但第二種關係的成立，並不以公開所有遊戲原始碼為必要。外部人可以只接觸：

1. 公開或限制授權的 SDK／插件介面；
2. 官方另外發布的資料、模組、示例與測試項目；
3. 經隔離的問題重現專案；
4. 經邀請、受限權限的私有貢獻分支；
5. 自有 MOD 專案的原始碼與成果封包；
6. 公司以明確契約指定的委託工作範圍。

因此，PR 不等於開源核心，合作不等於聘僱，合併不等於買斷，署名不等於付款，付款也不等於取得無限制利用權。若把上述概念混在一起，最終可能傷害玩家創作者、企業與終端消費者。

0.2 本篇要處理的四種不對稱

能力不對稱： 某些玩家比公司更熟悉特定玩法或實際問題，但不熟悉產品整合、安全或銷售責任；公司反過來可能具備整合能力，卻不具備該玩家的特殊領域經驗。

權利不對稱： MOD 作者擁有自身原創表達的權利，但可能同時利用官方素材、第三方開源程式或其他人的共同著作；公司有權控制官方商業發行，卻不代表可無條件買賣玩家創作。[E05]

成本不對稱： 玩家可能只花數小時完成一個修改；正式整合卻可能需要數月維護、跨平台測試、翻譯、無障礙、客服及存檔遷移。反之，公司也可能低估一項 MOD 作者投入的多年勞動與無形價值。

權力不對稱： 公司握有官方合併與發行權，玩家握有自己是否投稿、是否授權、是否接受報酬及是否退出合作的選擇權。雙方可以協商，無須被塑造成互相服從的上下級。

0.3 本篇與 ANIE-04／05 的精確分工

ANIE-04 研究的是「應不應該做、如何與玩家協商」；ANIE-05 研究的是「外部 MOD 如何技術上安全擴充與長期相容」。本文研究另一件事：當外部作品可能進入公司正式商業產品時，誰有權提出、誰有權審查、誰擁有哪一部分權利、誰負責維護、何時該支付何種報酬、如何留下可驗證紀錄？

若本篇退化成單純的 GitHub 使用教學，便沒有完成制度研究；若把 ANIE-04 重寫成玩家投票指南，或把 ANIE-05 重寫成 MOD Loader 設計，則失去本篇的獨立價值。

0.4 命題與可反駁性

主命題 P0： 對有持續更新需求、具備可隔離的擴充邊界與足夠審查能力的商業遊戲，建立自願、明確權利、可選擇報酬且具備正式驗收程序的外部貢獻路徑，可能提高可用改進的來源多樣性、縮短特定功能開發時間、降低部分知識缺口，並形成可累積的合作信任。

反命題 C0： 若外部合作產生的審核成本、法律糾紛、惡意投稿、責任轉嫁、維護債、創作者剝削或核心設計破壞，高於其新增產品價值，則高開放度路徑不一定優於封閉開發；在某些作品階段，僅接受玩家回饋或只開放資料型 MOD 可能更好。

本文不把「更多投稿」等同「更好成果」，也不把「有 PR」當成企業良好治理的充分證據。

1．外部研究脈絡：市場、企業與社群生產不是三選一

1.1 Peer production 已經質疑傳統生產二分法

Benkler（2002）在 Coase's Penguin, or, Linux and The Nature of the Firm 中研究大規模協作如何在傳統企業命令結構及市場價格機制之外組織生產。[E04] 他的研究並不自動證明所有遊戲都應社群化，卻提供重要的對照：若對某些工作而言，分散式動機、知識與協調機制有效，則「不是員工就不能貢獻商業產品」不是必然的經濟定律。

開放原始碼、百科、玩家 MOD、公開資料集與社群工具都提供某種形式的外部生產。然而，這些產出能否進入商業作品，仍需處理品質、內容責任、商標、付費與授權條件。

1.2 使用者創新與專業分工的互補

von Hippel 的使用者創新研究說明，使用者常能因為自身需要而提出製造商未事先辨識的解決方案。[E09] 遊戲玩家因長時間體驗特定職業、裝備流派、語系與 MOD 組合，可能最先發現原版設計的某個局部缺口。這種知識可以被產品團隊吸收，也可以讓玩家自行製作替代方案。

但是使用者提出的解法，並不必然具有可移植、可持續或可授權的品質。 高價值問題辨識與正式採用，是兩個不同的驗證階段。

1.3 Steam Workshop 已有「選拔型」與「直接使用型」制度

Steamworks 官方把 Workshop 分成 Ready-to-use 與 Curated 等不同整合模型：前者讓玩家訂閱使用投稿，後者允許公司選擇項目進入正式遊戲；官方亦明確指出，如果把 Workshop 作品作為 DLC 銷售，通常需要公司與作者自行協議一次性付款或持續權利金。[E02] 因而不能把「MOD 正式收錄」描述成前所未有的機制。

本研究所追求的新增整合層是：把外部 PR、MOD、承攬合作、授權、報酬與交付證據放進同一套跨版本的治理語義與管理流程，而不是只保留一個 Workshop 投票頁。

1.4 GitHub 的工具不是權利歸屬的答案

GitHub 的 fork／PR 可以使沒有主儲存庫寫入權限的人提出修改；組織級 repository 角色又能細分 Read、Triage、Write 等存取能力，搭配 CODEOWNERS 與保護分支要求審查。[E01][E10][E11] 這些措施處理「誰能看到什麼」與「誰能合併什麼」，並不直接決定一段程式碼的著作人、授權範圍或是否應支付費用。

GitHub 官方另提醒：公開儲存庫沒有選擇適當授權時，通常不會因程式碼可被瀏覽，就自動變成任何人可自由複製、修改和商用的開源程式。[E12] 所以企業如果保留私有核心，應更加清楚地定義外部公開的貢獻層，以及其授權條款。

1.5 本研究與既有制度的不同

本研究不主張發明 PR、MOD、crowdsourcing、Curated Workshop 或契約承攬。它提出的研究增量，是針對 AI 原生商業遊戲，測試不同法律與生產身分之間的低摩擦轉換能否成立。重點是持續交付產品中「外部自由創作」與「公司付費採用」的明確邊界，而不是將一方吸收進另一方的控制關係。

2．五個基礎定義與兩組不可混同的事件

2.1 外部貢獻（External Contribution）

外部貢獻指公司正式雇用與內部製作流程之外，由具備自身權利或授權的個人或組織提出，可能有助於產品的資訊、代碼、資料、藝術、工具、測試或成品。它可以是免費的，也可以是付費的；可以進入正式版，也可以永久保持獨立。

2.2 玩家轉開發者（Player-to-Developer Pathway）

指參與者由純粹使用產品，轉而投入可測試、可署名或可接受報酬的產品相關勞動。這是活動或合作身分的轉換，不是自動產生勞動契約、公司職稱或社員地位，也不是某種必然的進階階級。

2.3 官方整合（Official Integration）

指公司在具備相應權利與品質證據的情況下，將外部成果全部或部分併入其管理、發行、宣傳或維護的正式產品版本。可被整合者不只程式碼，亦包括腳本、翻譯、圖像、音樂、資料、關卡、劇本與可驗證測試。

2.4 合作契約（Contribution Contract）

指雙方在特定貢獻範圍、利用權限、報酬、期限、交付物、署名、維護與爭議處理上形成可識別的約定。其法律性質不由本文術語決定，仍須按照實際合作關係、適用法規與個別契約認定。

2.5 產品整合責任（Official Integration Responsibility）

指某項第三方成果成為公司正式販售內容後，公司必須依其角色、對外承諾、平台契約與適用法律承擔的相應責任。某段程式來自玩家，不能成為公司完全放棄品質檢查、資訊告知或消費者救濟的充分理由。

2.6 必須區分的事件 A：接受投稿不等於接受商業利用

投稿被系統接收、PR 被 AI 評估、團隊核准其技術價值、作者同意授權、契約成立、完成報酬結算、合併正式版本、正式公告，是八種可能具有不同時間與證據的事件。

2.7 必須區分的事件 B：拒絕採納不等於貶低貢獻

公司可以因設計方向不合、測試失敗、負擔超標或授權不全而拒絕投稿。拒絕正式整合不表示創作者的 MOD 應被刪除、作品價值不存在，亦不表示公司有權沒收其獨立創作。

3．貢獻者的六條合作車道：避免單一路徑統治所有貢獻

上述車道不是價值排序。L1 作者可能擁有最具創造力的成果；L4 受託者也可能只修復一個小錯誤。玩家可以長期只選擇 L1，而不必被誘導為公司提供勞務。從 L1 升至 L3 或 L5 應由雙方自願協議，不得因作者使用官方 SDK 就推定其所有自創內容可被公司免費商用。

3.1 車道轉換不是自動吸收

若一個廣受歡迎的 MOD 被公司注意，合理程序是邀請作者討論。作者可以拒絕、要求署名、提出一次性授權費、接受分潤、維持獨立版本，或提出新的衍生開發條件。公司也可因成本、保密、產品一致性或風險而不收錄。

3.2 關於免費貢獻的必要限制

免費貢獻是合法且有價值的協作形式之一，但不應被描述成「社群義務」。對有明確工期、公司指揮、交付義務與商業用途的工作，應主動評估是否改為有償委託或適用勞動關係；不應把有薪工作拆成一連串「自願 PR」以規避成本或責任。

3.3 獎金、謝禮與委託的區分

事後主動致謝或無事先承諾的獎賞，不必然與事先談妥的報酬契約相同。若平台廣告「合併就給 新臺幣 X」，應事先釐清達標條件、審查權、付款期限、稅務及取消辦法，不宜模糊地稱作社群鼓勵以避免履約。

4．ECA：從外部提案到正式商業版本的進入機制

4.1 八階段事件鏈

一項外部貢獻可依下列程序流轉：

1. 提出：貢獻者選擇車道與對象，提供必要文件及檔案。
2. 初步分類：系統辨識提案、測試、SDK PR、MOD 收錄與委託等不同類型。
3. 權利來源盤點：辨識個人創作、共同作者、第三方資產、開源授權、AI 輔助與未明來源。
4. 工程與產品評估：分析功能、效能、可維護性、版本相容、設計適配與成本。
5. 商業條件協商：需要時另行簽署授權、讓與、委託或維護條款，完成必要的付款安排。
6. 候選整合驗收：在隔離環境建立候選建置、執行 CI、回歸與真人遊玩驗證。
7. 正式整合／不整合：具授權權限的公司決策者決定發布、拒絕、修改或延期。
8. 後續追蹤：版本、授權摘要、報酬狀態、作者署名、已知限制與維護責任持續連結。

這是建議的事件鏈，不是宣稱任何單一平台已完整提供上述功能。工程實作可以平行執行初步分類與技術掃描，但不得在必要權利文件未成立前進行沒有授權依據的正式商業發布。

4.2 不可把技術與權利合為單一 PASS

定義五種驗收證據：

• $Q_T$：技術功能與回歸通過；
• $Q_S$：安全、供應鏈與敏感資訊邊界通過；
• $Q_P$：產品體驗與設計目標可接受；
• $Q_R$：利用權源、授權範圍、第三方權利與契約完備；
• $Q_O$：正式發布、維護責任及對外承諾已有人負責。

基本的官方收錄條件可表示為：

此處每個 $Q$ 必須由明確證據及具有對應權限的人員確認，不能讓 AI 以自然語言的一句「看起來合法」替代。若任何高風險閘門不通過，狀態應為拒絕、隔離或補件，而不是為了追求合併率勉強降格。

4.3 兩條不同的接受線

技術接受線：指 PR 可合併到公開 SDK、資料範例、工具庫或候選分支；此線不代表取得對全部平台及收費產品的權利。

商業採用線：指公司對特定著作取得足以進行約定利用的權利，並完成正式產品驗收。此線可以透過授權使用已存在的 MOD 而達成，並不一定需要把 MOD 的原始碼全部轉移給公司。

4.4 退件、保留與再談判

即使投稿品質優秀，也可能因作品整體平衡、故事設定、合規限制、財務資源或作者期待價金而不進入正式版。合理紀錄應保留決策原因，而不是把「未收錄」直接寫成「貢獻失敗」。若未來條件改變，系統可重新發出談判邀請，不能擅自把前次未成立的授權當作有效。

5．PDP：玩家轉開發者的多方向通道

5.1 玩家可以先提供問題知識，再提供程式碼

玩家最早提供的價值可能是對一個難以重現 Bug 的精確步驟，也可能是替非主流控制器實作適配器、替某語言補完翻譯，或用 MOD 證明另一種玩法可行。制度應允許參與者選擇擅長的形式，避免只有熟悉 Git 者才被當成正式貢獻者。

5.2 從單次貢獻到合作邀約

建議依成果與意願形成非強制性的合作軌跡：

觀察問題 → 自主實驗 → 提交成果 → 取得回覆 → 經驗證的貢獻紀錄 → 選擇是否接受正式合作邀請。

任何一段都可以停止；公司也不應因一次優秀 PR 就暗示作者必須持續無償維護後續版本。

5.3 不依據「粉絲忠誠度」決定報酬

遊戲時間、論壇活躍度、社群頭銜與社交聲量可形成某種參與背景，卻不能替代實際交付能力、權源與專業報酬談判。即使是剛加入的陌生人，只要提出合法、有價值且可驗證的成果，也應能進入相同的投稿程序。

5.4 少數創作者也可擁有議價權

著名 MOD 可能累積多年社群支援、品牌辨識、角色設定及特殊工具鏈。公司收錄時應分辨：可辨識的著作財產權、社群價值、長期維護成本及作者的個別談判意願。這些都不能被簡化為「原版遊戲是公司的，所以 MOD 應該全歸公司」。

5.5 署名與身份切換

作者可能希望顯示 GitHub 名稱而非真名，也可能希望公開作品名稱、不公開合約報酬；在適用法令及履約證據保存下，可以將公開署名、法定身分驗證與付款身分分開處理。付款資料不應因產品公開透明理念就被推送到公開論壇。

6．PR 可以存在於商業遊戲，卻不必暴露商業核心

6.1 開放的應是有意義的協作介面

建議採取核心／擴充／協作三層：

對含有特殊設計或未公布劇情的 MOD，可以限制其測試資訊對外顯示，不代表整個社群協作制度因此失敗。

6.2 公開 GitHub 儲存庫和商業授權可以並存

公開 SDK 不必與主遊戲採相同授權。某個 SDK 可採寬鬆開源授權、文件可採另一授權、示例 MOD 又另有使用條款；前提是清楚標示、遵守第三方相容性義務，不能把全部內容一律假設為可任意移植。[E12]

6.3 私有儲存庫的合作不是無風險

組織儲存庫可針對外部合作開發者提供合適的 Read／Triage／Write 等角色，而不是讓所有投稿者共享完整內部程式。GitHub 亦提醒，私有專案的本地複製即使權限收回，也可能仍留在先前合作對象設備上，因此保密、最小資訊提供與契約義務須同時考慮。[E10]

6.4 變更審查不等於合併授權

CODEOWNERS、保護分支和必要審查可防止未經批准直接合併，但它們只提供技術與工作流控制。授權審查需要獨立角色；例如一個修改遊戲資料的 PR 即使通過效能測試，若附帶未經授權的第三方音樂，仍不能因此發行。[E11]

6.5 第一版不用先開放全部資料

對三個月內希望完成商業小品的公司，第一階段可以只開放語系檔、資料表、外掛示例、測試基準和回報工具。只要接口足以產生有意義的改善，就已具有實際合作價值；不需要以全面公開商業核心的成本換取看似更高的透明度。

7．著作權與權利鏈：合法持有檔案不等於擁有全部利用權

7.1 本篇的法律定位

本篇以中華民國（臺灣）法律為主要起點，引用智慧財產局與全國法規資料庫可公開核對的條文；跨境投稿、公司設於海外、多人共同創作、音樂授權、商標與平台分潤另可能受不同法律或契約影響。下列制度架構是研究及產品設計建議，不是針對個別案件的法律意見，實際導入時仍應由適用司法轄區的專業人士審閱。[E05][E06][E07]

7.2 第 10 條與第 10 條之 1：保護的不是所有想法

臺灣著作權法對著作完成時的著作權取得及思想／表達分界有規定。玩家提出「希望加入門派經營」的抽象概念，與玩家實際完成具有原創性的劇本文字、圖像、程式碼，通常不是同一層次的權利客體。不能把所有建議都承諾為公司需要支付著作授權費的作品；但也不能因為最初是玩家提議，就無視其後具體完成的創作。[E05]

7.3 第 11 條：受雇職務創作

就受雇人在職務上完成的著作，法定預設與契約另行約定的效果，和出資委託他人創作不同。此處不宜用一張「所有外部人都是自由工作者」條款取代工作關係的實質認定。當合作實際上具有雇傭從屬性時，既有僱傭規定可能適用。[E05][E08]

7.4 第 12 條：出資聘請完成的著作

臺灣著作權法第 12 條明定，在非第 11 條情形的出資聘請著作，原則上以受聘人為著作人，得依契約約定以出資人為著作人；若受聘人為著作人，著作財產權依契約決定歸屬，未約定則原則上歸受聘人。條文亦有出資人得利用著作的規定。[E05][E06]

這裡存在必須避免的兩種錯誤：

1. 「我付錢，所以自動取得全部著作財產權。」這與第 12 條的約定機制不符。
2. 「未約定權利時出資人可以利用，所以公司可無條件再授權、出售、跨平台永久商用。」這也不能直接從條文字面推出。

商業遊戲長期需要移植、改版、合併、拆分、再授權、平台移轉與續作利用，因此應以明確書面約定解決範圍問題，而不是依賴概括推測。

7.5 第 21 條與著作人格權

臺灣著作權法第 21 條規定著作人格權專屬於著作人本身，不得讓與或繼承。[E05] 因而，契約若涉及作者姓名表示、公開發表、作品變動與不行使著作人格權等議題，應逐項檢查法律容許的安排及適用限制；不應將「所有權全部轉移」當作一份可以消除所有人格權問題的萬用條款。

7.6 第 36、37 條：讓與與授權不是同一動作

第 36 條允許著作財產權全部或部分讓與，約定不明部分推定未讓與；第 37 條允許授權他人利用著作，涉及地域、時間、內容、利用方法等約定，約定不明部分推定未授權，且非專屬被授權人原則上不能未經同意再授權。[E05][E07]

因此，在制度上至少應明確區分：

• 公司只取得在某款遊戲內使用的非專屬授權；
• 公司取得該 MOD 或部分內容的專屬授權；
• 公司取得特定著作財產權的讓與；
• 公司僅取得暫時測試、內部評估或宣傳展示的有限使用許可。

不應把它們合稱為「收錄同意」。

7.7 以 MOD 為例的權利層析

某個 MOD 可能包括：

1. 自行撰寫的腳本；
2. 改動官方遊戲資料的設定檔；
3. 由第三方工具生成的插圖；
4. 引用某位藝術家的字型；
5. 使用採特定授權的開源 library；
6. 由朋友共同製作的角色配音；
7. 以 AI 輔助改寫的翻譯；
8. 遊戲官方授權使用的現有角色與世界觀素材。

作者可能對第 1 項具有明確權利，卻沒有權限替第 4、6 或 8 項任意再授權。公司若只簽一份「作者聲明全部為本人創作」卻不做最少必要的權源核對，會留下易預見的風險。

7.8 權利來源清單應達到檔案或資產粒度

理想的資產權源紀錄包括：asset_id、author_or_owner、source_uri、license_or_agreement、allowed_uses、attribution_requirements、modification_right、sublicensing_right、commercial_use、territory、term、AI_provenance、evidence_ref。這不是要求每位創作者手工寫法律百科，而是讓平台依投稿種類要求不同深度的資料，並由工具盡量自動整理可驗證部分。

7.9 對「來源不明」的正確反應

當投稿無法說明素材權源時，合理狀態是 RIGHTS_PENDING、QUARANTINED 或 REJECTED；不能要求 AI 幫忙換一種檔名或重新生成近似作品，便假裝風險消失。若可以在合法條件下由作者或公司自行重新創作替代素材，也應把新來源和新權利狀態重新記錄。

8．Steam Workshop 的權利界線：上架不等於可被公司任意收購

8.1 平台條款與公司契約同時存在

Steam Subscriber Agreement 第 6 節對 User Generated Content 與 Workshop Contributions 設置權利與聲明保證。條款涉及 Valve 及其關係企業使用 UGC 的授權、Workshop 專屬事項、可能的應用程式個別條款及投稿人對自身權利的保證。[E03]

但應區分三個主體：Steam 平台、遊戲公司、投稿作者。平台取得某些授權，不代表遊戲公司在任何地域、任何產品、任何期限都可無限制利用投稿；公司對正式版的利用還可能需要遵守 Workshop 專屬條款，或另外與作者訂立契約。

8.2 Ready-to-use 的 MOD 不等於公司收錄

可供玩家訂閱下載的 MOD，可能只是玩家與作者間透過平台形成可使用的擴充關係。公司在官方版本中重做類似功能、採納玩家所提出的問題，與直接重製 MOD 的具體程式、角色插圖及音樂，是不同的事。

8.3 Curated Workshop 更接近正式整合，但仍需核對條款

Steamworks 官方指出，Curated Workshop 允許開發者篩選符合遊戲要求的作品；若作為 DLC 銷售，應自行與作者處理報酬安排。[E02] 因此，ANIE 的商業收錄路線可以將 Curated Workshop 作為前端投稿管道之一，但不能以 Workshop 的投票數量取代公司權利驗證與整合測試。

8.4 平台報酬與公司外部契約不得重複計算

假設某位 MOD 作者已在官方 Workshop 商業分潤體系獲取收益，公司若又簽一份將相同收入視為獨立的全面分潤合約，可能造成重複分配或計算方式衝突。應建立一個能辨識哪些銷售由平台結算、哪些由公司結算、哪些只給固定授權費的條件矩陣。

8.5 不在公開文章中保證特定 Workshop 收費功能

Steam Workshop 的付款、作者收益及平台審核機制與具體整合種類、產品啟用及當時有效條款相關。公司可以公告「願意洽談 MOD 正式收錄」，但未實際核准的機制不應宣稱已支援一種普遍適用的作者分潤渠道。[E02][E03]

9．DCO、CLA 與個別商業授權：不要用一張勾選框做完所有事情

9.1 DCO 的用途

Developer Certificate of Origin（DCO）通常是貢獻者對其有權提交作品且符合指定授權的來源聲明；GCC 與 DCO 的官方說明提供了具體範例。[E13] 使用 Signed-off-by 之類的紀錄，可以提升貢獻者責任可識別性，但 DCO 不是為私有商業遊戲自動建立不限範圍的著作權讓與契約。

9.2 CLA 的用途及爭議

Contributor License Agreement（CLA）是專案可選擇設置的貢獻授權協議，內容因專案及法律環境而異。可能涉及公司獲得修改、散布、重新授權的權利，也可能造成作者擔心權利過度集中。本文不預設 CLA 是必要條件；對極小型 SDK PR，採清楚的專案授權及合理的來源聲明可能已足夠；對未來要進入私有商業核心的大型成果，個別契約往往更能精確描述雙方期待。

9.3 商業授權不能透過無關條款偷渡

若某公開範例庫採開源授權，公司接受 PR 應依該授權及貢獻政策處理；若公司希望將投稿者另外提供的其他作品收錄為付費 DLC，應另行談判。不能把「在公開專案提出 PR」寫成投稿者已放棄所有未來作品之商業權利。

9.4 三種建議文件

A. CONTRIBUTING.md： 說明投稿範圍、審查、來源、署名、既有授權、無償或有償分界及投訴路徑。

B. CONTRIBUTION_POLICY.md： 說明外部投稿等級、產品相交域、禁止類型、AI 參與披露、個資、安全與爭議程序。

C. COMMERCIAL_INTEGRATION_AGREEMENT： 僅在公司希望取得超出原投稿條款的商業權利時個別簽訂，載明對象、利用方法、修改權、再授權、版本、平台、報酬及維護責任。

所有範本均需依實際情境完成法律審查，不應以 README 一行概括所有法律效果。

10．契約合作不等於自動排除僱傭：臺灣法的實質審查

10.1 勞動關係不是看合約標題

臺灣勞動部《勞動契約認定指導原則》強調，雙方雖可約定勞動、承攬或委任等契約類型，實際是否屬勞動契約仍應由個案事實及整體契約內容，依從屬性程度實質認定，不受名稱拘束。[E08]

故「讓 MOD 作者用契約制合作」是一種商業構想，不是只要寫下「非雇員」就能免除可能存在的勞動法上義務。

10.2 高風險判斷因素

若公司要求特定人士每天固定上班、接受持續指揮、使用公司指定工具與場所、不得自行安排工時、進入考核懲戒制度，或長期具有高度組織依附，則應審慎檢視是否逐漸接近僱傭關係。具體認定仍依法律、個案及證據，不能僅憑本文列舉作結論。[E08]

10.3 真正適合一次性委託的情境

例如公司公開一份明確規格：修復特定崩潰問題、提供可重現測試、附完整原始碼與權源清單、於約定期限提交；作者可自主選擇是否接案、如何安排工作方法，經協商由公司依成果驗收。此情境可能較容易設計為成果導向的委託，但仍須視實際執行方式判斷法律關係。

10.4 長期維護可能改變契約性質

最初只委託某作者修一次 MOD，後來每週固定安排產品值班、進入公司持續管控、被要求參加內部例會與排班，不能仍以原契約標題推定其法律性質永遠不變。公司應定期檢視關係變化，必要時轉換為合適的合作或僱傭安排。

10.5 未成年參與者與跨境合作

遊戲 MOD 生態可能包含未成年人和不同司法轄區的作者。可公開一般意見收集，不代表可不加審查地與任何人簽訂有償權利交易。年齡、簽約能力、法定代理、個資處理、付款身分與稅務都需要依個案處理。跨境合作另涉及匯款、發票、稅務文件及爭議解決地。本文不對未核對的國家、年齡或稅額設一概通則。

11．CCC：可選擇且可比較的六種報酬設計

11.1 模式 A：自願投稿與公開署名

適用真正自發、範圍清楚、允許自由退出且不預設公司有償指令的貢獻，例如修正文件錯字、補充測試案例或按公開授權修復 SDK。需先告知是否無償、作品預定授權範圍、是否可能進入商業工具，以及署名方式。

11.2 模式 B：一次性酬謝或 Bounty

適用公司事先公告的明確缺陷修復或功能任務。若設定獎金，應說明完成判準、重複投稿如何處理、同時多位作者是否分配、接受與否由誰決定，以及何時付款。對無法客觀驗證的創意提案不宜直接用競賽式「先寫完才可能拿錢」取代公平的預先洽談。

11.3 模式 C：一次性商業授權

MOD 作者保留原有權利，公司支付一筆授權費，取得在指定作品、版本、渠道與期限內使用、修改、宣傳或必要再授權的權利；是否專屬、是否包含續作，均以約定為準。這種方式特別適合作者想保留獨立 MOD、公司只想正式收錄部分功能的情況。

11.4 模式 D：著作財產權讓與

在作者確有可讓與權利，雙方亦理解其範圍、金額及後果時，可討論特定內容的全部或部分著作財產權讓與。它不應被預設為所有 MOD 收錄的必要方式，亦不應忽略臺灣著作人格權不可讓與的規定。[E05]

11.5 模式 E：持續維護費

公司可能向作者支付每季或每次版本調整的維護費，對應既定更新範圍、回應時間、最低品質、可用性及交接義務。維護服務費與原創內容商業授權是不同對價；若合作終止，公司仍應確認有無合法權利繼續維護、修改或委託他人修改該模組。

11.6 模式 F：營收分成與混合報酬

若某 MOD 成為 DLC 或與正式商業功能直接相連，可以協商分潤，也可以採一次性費用加有條件分潤。Steamworks 本身亦描述過由公司與作者另行協商 DLC 一次性付款或持續權利金的做法。[E02]

最容易引發爭議的不是「比例是 10% 還是 20%」，而是百分比的分母究竟是什麼。制度至少需定義：

• 哪些產品、地區和渠道的銷售納入；
• 計算基礎是總營收、平台扣除後收入、退款前或退款後收入；
• 稅捐、代收代付及折扣如何處理；
• 哪些通路由 Steam 或第三方先行結算；
• 退款、折價券、組合包及跨產品促銷如何分攤；
• 是否有最低付款門檻、遞延、結算週期與報表查核方式；
• 契約終止後哪些利用與對價繼續有效；
• 作者是否能合理查核公司提供的結算摘要。

11.7 報酬不是只有金錢，但不能用曝光替代已約定的金錢

自願署名、作品介紹、作者頁面和未來合作推薦可以是有價值的非金錢回饋；然而當雙方已約定具體對價，公司不能事後改稱曝光就足夠，亦不能以社群情誼掩蓋既存的付款義務。

11.8 平台商業條款與公司財務紀錄對齊

如果部分收費項目透過平台結算，應保留足以辨認付款來源、分潤負擔與授權生效條件的對帳資料。公開季報可揭露總體付款金額區間、合作項目數與處理時間，但個人銀行資料、稅務識別和未公開單價仍應受權限與契約保護。

12．公平不等於所有貢獻者拿相同比例

12.1 數量不是價值

同一款遊戲中，有人貢獻一段十行的存檔修復，卻避免數萬名玩家的世界紀錄損毀；另一人交付數千行大量樣板程式，卻不形成玩家價值。依程式碼行數、提交次數、Discord 活躍度或 AI token 消耗進行獎酬排序，容易扭曲實際產出。

12.2 應分離四個價值來源

第一是創作價值：內容、玩法與技術創新。第二是工程交付價值：可維護、可測試、跨版本能力。第三是風險承擔：後續修復、出錯責任及時間承諾。第四是權利價值：原創資產及允許公司使用、修改、再授權的範圍。

這四項可以共同參與價格協商，但沒有公認的客觀總分可以自動得出「公平酬勞」。報酬始終需要考慮替代方案、市場、談判力量與雙方自由同意。

12.3 避免利用粉絲情緒取得過低報酬

當作者本身是長期玩家，對作品有情感投入，可能願意給公司優惠。公司可以接受自願且充分知情的安排，但制度應避免利用作者不清楚法律、錯估維護義務或誤解 Steam 條款的弱點，來取得不可逆的廣泛權利。尤其新作者不應被要求先「證明忠誠」才能進入付費合作。

12.4 為反向機會成本留下位置

如果某 MOD 因被官方收錄而失去獨立品牌、原先捐款或訂閱收益，作者的機會成本可能很高。公司可選擇拒絕收錄，但若決定收錄，便應允許作者把損失納入授權價格的協商，而不是只按公司重做一次需要多少工時估價。

12.5 明確排除「產品成功後才付錢」的單一路線

持續分潤會把商業風險轉嫁給作者；若作品失敗，作者可能花大量時間卻沒有收入。某些人願意承擔風險，某些人更需要固定對價。制度應提供選擇，而不是把具有市場不確定性的收入分配當成唯一報酬形式。

13．從 MOD 轉正到官方維護：責任界線比合併動作更難

13.1 官方採納前後的責任不同

在合法獨立 MOD 的階段，作者可能控制發布、更新、相容範圍與支援政策。當公司選擇將其正式整合於商業遊戲、宣稱該內容為商品一部分後，對消費者的品質、功能、保固／退費及平台義務的責任配置，就不能假設仍完全留在原作者身上。

13.2 四種正式收錄模式

內建整合（Bundled Integration）： 公司將內容併入主遊戲建置。優點是版本與安裝便利；缺點是公司必須處理核心相容與跨平台品質。

官方 DLC（Official DLC）： 內容獨立發行、可銷售或免費提供；需要清楚定義收入、支援年限、依賴與平台計畫。

官方認證 MOD（Verified MOD）： 作者仍獨立發布，公司提供明確兼容認證與一定程度的驗證，但不應使「已驗證」被誤認為「公司擔保所有未來版本無風險」。

維護轉接模組（Maintained Adapter）： 公司只對某些相容層或官方接口負責，作者仍維護 MOD 自身的其他內容。此模式不應用含糊宣傳掩飾支援邊界。

13.3 「官方化」可能反而限制創作自由

一款自主 MOD 可能故意破壞平衡、充滿惡搞、使用成人主題或有尖銳社會諷刺；其魅力正來自不受公司核心產品方向拘束。公司若要求正式收錄，可能必須限制尺度、修改角色、重新平衡與審核語言。作者完全有權判斷這是否仍是自己希望創作的作品。

13.4 選擇不收錄也是可能正確的合作結果

「保持 MOD 獨立，但公司替其改善 API、提供測試與文件」可能比買斷更有利於整個生態。這與 ANIE-04 的非服從式協商一致：合作不等於所有可合作的東西都要變成官方資產。

13.5 官方收錄後若作者退出

合作契約應先釐清：作者退出時，既有玩家可否繼續使用、公司能否修補安全漏洞、是否可委託下一位開發者、如何處理原作者署名、哪些收入分成持續存在、是否提供合理移交。這與 ANIE-03 的可繼承遊戲產品研究直接接軌。

14．AI 參與後，合作的核心門檻將從「會不會寫」移向「能否證明」

14.1 AI 可能降低外部投稿的候選生成成本

過去要製作可運作的 MOD，可能需要理解大量遊戲程式、編輯工具與繁雜檔案格式。AI 輔助閱讀 SDK、產生資料表、測試腳本與功能候選，理論上能讓沒有傳統程式訓練的人提出更完整的成果。但此變化必須實際測量，不能因模型可生成程式碼就推論所有人能生產同等品質的正式遊戲功能。

14.2 不能把「AI 寫的」視為自動有權商用

臺灣智慧財產局 2025 年 10 月 17 日的解釋說明，AI 生成作品是否享有著作權，取決於有無人類實際創意投入；完全由 AI 演算獨立完成、欠缺人類實際創意投入者，不因此享有著作權。[E14] 這是臺灣法律脈絡的說明，不代表每個司法轄區的著作權制度、AI 平台服務條款和輸出權利風險完全相同。

因此投稿者至少應能回答：

1. 哪些內容由本人實際創作、選擇或編排？
2. 哪些內容由 AI 產出後經本人實質修改？
3. 使用了哪些模型或服務，在何種授權及使用條件下？
4. 是否引用第三方的圖片、音樂、程式或非公開資料？
5. 是否有可疑的風格、商標、肖像或實質近似爭議？
6. 如果原始片段沒有可受著作權保護的創作性，哪些其他權利或契約可支援預定商業使用？

這不是要求創作者公開每一個私人提示詞，而是依風險及價值提供足夠可追溯資訊，使授權與品質判斷不完全依賴口頭聲明。

14.3 AI 可以輔助權源查核，不能代替權源成立

AI 可比對檔案清單、分析開源依賴、標記可疑高相似內容及缺少署名的資產；但模型的分類結果是待驗證線索。它既不能單方確認某藝術家允許商用，也不能因未偵測相似圖片就證明作品具有完整合法來源。

14.4 公司 AI 不得私自改變報酬條件

如果玩家對公司 AI 說「我幫你完成這個 MOD，你們給我五萬元好不好」，AI 可以說明目前開放的合作車道、價金談判需要的資料與送審程序；除非公司明確授權它在預先規範的條件內形成有效報價，否則不能把一段聊天自動升格為公司已承諾支付的契約。對重大權利讓與、排他合作、分潤及稅務承諾，應設更高的授權閘門。

14.5 AI 不應拿投稿者作品暗中訓練其他產品

當公司取得 MOD 的內部測試或商業收錄授權，不代表當然取得以該作品訓練其他模型、再分發資料集、提供第三方推論服務或在無關產品使用的全部權利。若確有這類用途，應核對法律及既存授權，必要時另行取得明確授權；對上傳資料也應告知處理方式與保存期限。

14.6 AI 增加提交數量，可能惡化審查瓶頸

假設每季原本收到 100 個 PR，其中 20 個符合基本品質；AI 讓投稿量增加到 1,000 個，但合格率下降至 5%，那麼有效候選增加為 50 個，審查工作量卻可能提高數倍。是否值得，取決於自動分類精準度、人工複核成本與作品實際帶來的價值。

因此本文以通過權利與品質雙閘後的淨產品價值作為目標，而不是每月 PR 或 AI token 數量。

15．供應鏈與 PR 安全：開放協作不能變成內部系統入口

15.1 外部 PR 是不可信輸入，而不是預設善意可執行程式

即使大多數投稿者基於善意，外部程式仍可能存在錯誤、惡意行為、依賴套件竄改、隱藏網路請求、檔案刪除或資訊外洩。供應鏈防護的目標不是先懷疑所有玩家的人格，而是將安全機制設計得不依賴投稿者動機。

15.2 GitHub Actions 的信任差異

GitHub 官方文件指出，來自 fork 的一般 pull_request 工作流程通常不會取得一般儲存庫秘密，token 權限受到限制；相對地，pull_request_target 屬於較高信任上下文。若在高權限工作流程中檢出並執行外部 PR 的程式，可能形成敏感資訊外洩或供應鏈攻擊；因此應避免混用不可信程式與具權限的秘密及部署憑證。[E15][E17]

15.3 建議的三環執行邊界

第一環：投稿資料檢查。 僅讀取 PR metadata、差異檔案、檔案類型、檢查和規則，不能取得正式上架憑證；對腳本內容進行靜態檢測。

第二環：隔離建置與執行。 如需執行投稿內容，使用隔離、最少權限、有限網路、短期憑證、有限計算與不可重用秘密的環境；原始碼與資產均視為不可信輸入。

第三環：正式合併與發布。 權利和品質閘門均通過後，由受權限審查者合併；正式簽章、Steam 發行金鑰、付款執行等仍在可信環境另行操作。

15.4 保護分支與角色分離

至少分離「提出變更」「審查變更」「批准商業權利」「執行付款」「發布正式建置」五種操作權限。對少人公司而言，某些角色可以由同一人暫時兼任，但系統中的批准證據應維持邏輯上可追溯，不應由同一個 AI Agent 直接自我提案、自我核准、自我放款及自我發布。

15.5 安全漏洞的責任揭露

投稿者如果報告可利用的安全漏洞，公司應提供低風險通報管道及修復程序，不應強迫作者先公開 exploit 細節才能被注意。若補丁需要引用原作者報告，應視個資、保密與合理署名條件處理。涉及實際玩家安全的修補，可以在公開季報中揭露問題類型及修復狀態，但不必公開會使漏洞被即時利用的全部技術細節。

15.6 開放程度越高，安全訓練與人工治理越不能省略

AI 有能力幫忙縮短審查，但也會讓低品質或具攻擊性的變更更容易大量生成。故應測量每季安全退件率、外部依賴警示、隔離建置失敗率、審查逃逸缺陷及投入的安全人時，而不是只公布幾個 PR 成功合併。

16．可形式化的合作模型：權利、品質、報酬與責任必須共同閉合

16.1 貢獻候選狀態

對貢獻項目 $i$，定義：

其中 $A_i$ 是投稿與作者資訊， $R_i$ 是可驗證的權利集合， $Q_i$ 是品質與安全證據， $F_i$ 是議價與財務條件， $M_i$ 是後續維護與交接安排， $D_i$ 是公司對產品設計的正式決策。此處的 $A_i$ 不要求公開自然人真實姓名，只要求公司在必要合法範圍內能履行契約及完成適當查核。

16.2 授權集合不是二元值

令公司希望對投稿作品實施的利用集合為 $U_i$，作者或其授權鏈合法提供的權限集合為 $L_i$。候選商業利用的必要條件可表達為：

例如公司僅獲得單一遊戲內的非專屬授權，便不能把同一授權自動解讀為可用於未來續作、獨立售賣素材包或任意再授權。更現實的情況是利用權利受到作品、地域、期間、平台與利用方法限制，故 $U_i$ 與 $L_i$ 不一定能壓縮成一個「已同意」勾選框。[E07]

16.3 正式整合的可行域

定義經合法、技術與產品限制共同保留的採用集合：

公司僅應從 $\mathcal{F}$ 中評估何者進入正式版本。然而，屬於可行域不代表必須採用：公司仍需依 ANIE-04 的產品判斷與資源約束排序。這保留開發者的設計主體性，也保留作者拒絕不合理條件的選擇權。

16.4 公司觀點的淨貢獻價值

令 $V_i$ 是假設可測量的玩家使用價值與商業價值代理指標， $K_i$ 是整合與審查成本， $P_i$ 是報酬支出， $M_i$ 是預期長期維護成本， $RISK_i$ 是在相同時間尺度及可比較尺度下估計的風險成本，則可定義：

這不是普遍適用的貨幣精確估值定律。 $V_i$ 往往無法完整貨幣化，而分潤又會隨銷售而變，因此實務上應採多目標決策與敏感度分析。特別不能因模型算出 $N_i>0$ 就推論可以忽略作者權利。

16.5 投稿者觀點的接受條件

令 $B_i$ 為作者自主感受到的協作利益， $W_i$ 是實際和預期報酬， $O_i$ 是時間與機會成本， $X_i$ 是排他或失去作品控制的成本， $T_i$ 是其主觀信任及交易風險，則：

作者願意接受的條件可能要求 $A_i^{creator}$ 非負，也可能有不可貨幣化的底線，例如禁止作品被加入某種商業用途、要求保留獨立 MOD 版或要求特定形式署名。故不同作者不必共享單一效用函數，公司也不能用自己的價值模型替作者做接受決定。

16.6 協商空間可為空

當 $\mathcal{F}$ 非空，但作者要求的授權或報酬與公司可接受條件不相交時，合理結果可能是沒有交易。此時作者維持自主 MOD，公司維持原版，雙方仍可對公開接口、Bug 資訊與玩家回饋合作。非服從式協商最重要的功能之一，就是讓「不成交」不是治理失敗。

16.7 正式版本的維護責任向量

可將維護責任分解為：

分別代表版本相容、安全、存檔、玩家支援、權利維持和接手可行性。契約可以在內部約定誰提供何種維護服務，但對外已作出的承諾與依法不能免除的責任，不得僅透過作者和公司之間的內部約定推定消失。

16.8 合併速度與治理品質的可能衝突

若縮短權利審查使 PR 每週合併率翻倍，但未來著作權爭議和重工同時上升，制度不一定更有效。應建立沿時間累積的交付證據，而非只公布短期開發速度；例如同一個 PR 於合併後 90 天與 180 天的回歸缺陷、授權問題及維護成本。

17．對 AI 原生企業的產品組織意義

17.1 少人公司可以擁有較大的外部生產網絡

AI Agent 可以幫助少量核心人員拆解提案、提供示例程式、編排測試和整理授權資料，使公司能在不建立大量固定編制的情況下與不同專長的創作者合作。但這不代表一個人可以無成本管理無上限的社群：審核、溝通、法務、付款與品質責任仍可能成為主要瓶頸。

17.2 外部作者不必為了貢獻而放棄自身其他工作

一位 MOD 作者可以同時是玩家、其他公司員工、獨立創作者、兼職受託者，或只是偶爾提交補丁的技術社群成員。外部合作制度的價值，部分來自它允許低頻、非排他、專案型的專業參與。但如果某份合約有必要的利益衝突或競業約束，則仍應在具體法定及契約範圍內處理。

17.3 付費合作不一定要隨著社群規模擴張

某款遊戲即使有大量免費 MOD，也可能只需要對幾項核心技術、重要翻譯或持續更新的內容簽有償合作。另一款遊戲可能相反：社群很小，但某個精細的物理模組值得正式委託。決策依產品需要，而非只依投票數及貢獻者排名。

17.4 對多作品產線的正向效果

若同一位外部開發者擅長世界狀態存檔、MOD 遷移或 Unicode 排版，其技術能力可能在數款不同遊戲被重用。公司可以在每款遊戲適用的權利與對價清楚界定的前提下，邀請其參與不同作品，並在獲得同意的範圍內建立非敏感的合作履歷。

17.5 外部社群生產並非固定的公司資產

即使公司提供 SDK、論壇、任務和工具，玩家仍有權選擇退出、轉往其他社群或不再維護 MOD。公司可投資社群支援和良好的 API，但不能把外部作者的可得性當成已擁有的人力資源。這也再次說明 ANIE-03 的接手文件與替代維護能力仍然必要。

18．季度公開交付制度如何容納社群協作

18.1 雙週、月、季三級資訊

雙週： 公開已受理的協作類型、SDK 修復和可分享的候選成果；保密案件只公開匯總統計或不公開。

每月： 公開已批准的合作機制、回應率、平均審查延遲、MOD 相容情況及規範變更。

每季： 公開正式整合內容、通過權利與品質雙閘的項目數、維護責任與經作者同意的合作故事；若適合亦可公布範圍化的付費合作統計。

18.2 不是所有議價細節都要公開

公司可以公開「有償合作制度」「已支付」「報酬類型」「合作範圍」等非敏感狀態，但不代表必須公開個別創作者銀行帳戶、私人住址、稅務資訊或每份合約的全部秘密條款。公開的應是社群需要理解的政策與決策結果，而非其他人的財務隱私。

18.3 公開例子與證據鏈

一個合格的季度案例可顯示：某 MOD 被邀請評估、作者簽訂指定授權、公司修改 UI 和翻譯、完成三個月相容測試、正式於 v1.4 發行，以及作者同意公開的署名。每個事件應能追溯到內部真實來源，但不必把原始契約全文公開。

18.4 公開失敗不是宣布所有合作都失敗

若一個合約談不攏，可以在雙方允許的範圍內公布「本季未取得商業授權，MOD 維持獨立」；若技術不通過，可公開已知相容問題、目前不正式收錄的原因。這樣社群能判斷進展，而不必讓創作者或企業受到不必要的公眾羞辱。

18.5 累積成企業信譽的不是 PR 數，而是履約紀錄

一家企業若長期公開征求貢獻、核准獎金並依時付款、尊重作者署名、維持合同約定的授權和更新品質，其信譽有機會隨時間累積。反之，若公開平台有許多漂亮的協作頁面，卻長期拖欠協議或未經同意使用作品，增加曝光反而會放大聲譽損失。

19．案例推演：從普通玩家到正式商業協作者

以下案例全部是假設性的研究情境，不是 EveMissLab 已執行的合作、付款或產品發布紀錄。

19.1 案例 A：玩家修復一個嚴重存檔錯誤

某位玩家透過公開測試版發現長時間遊玩後的存檔遺失問題，提供重現步驟及精確測試。公司用 AI 輔助擷取問題後，在公開 SDK 的測試套件收到一個 PR，修正序列化的版本標記。

理想流程：確認問題 → 驗證程式修復 → 核對貢獻者的來源與授權 → 合併測試 → 發布修復 → 依事前政策署名或處理約定 Bounty。即使修補很小，也不能因其數量少而認定沒有價值；但如果沒有事先約定報酬，也不宜憑事後情緒單方面推定公司已負有固定價金債務。

研究問題： PR 結構能否比單純客服回報更快使存檔問題完成可驗證閉環？

19.2 案例 B：十萬訂閱級的玩家 MOD 被考慮正式收錄

假設某款策略遊戲有高度受歡迎的門派經營 MOD，作者與社群共同維護多年；公司希望把其中部分機制改作原版功能。首先應拆解出哪些是抽象玩法概念、哪些是作者的具體程式／圖像／文本表達，哪些利用原版素材，以及是否有其他共同作者。[E05]

可能結果包括：

• 公司自行重新設計類似功能，而不複製受保護的具體表達，並就需要的權利完成適當處理；
• 公司取得指定原創資產的非專屬授權，官方化一部分內容；
• 公司與作者簽訂付費委託，另製作官方版本；
• 作者拒絕授權，公司改善 API，讓 MOD 繼續獨立存在。

研究問題： 官方收錄是否真的增加作者與玩家的整體利益，或使原本自主生態失去活力？

19.3 案例 C：AI 自動生成的翻譯 PR

某位使用者提交完整的新語系翻譯，聲稱都是自己用 AI 一次生成。雖然可以把翻譯納入測試，但需核對其是否包含原版受保護文本、作者對翻譯的實質選編與修訂、語言品質、敏感詞、工具使用條款及目標平台政策。臺灣智財局關於 AI 內容著作權的見解提醒，不能未經分析就聲稱所有由 AI 直接生成的內容均有由投稿者排他授權的權利。[E14]

研究問題： 以 AI 增加翻譯候選後，人類校對和文化適配是否成為新的主要成本？

19.4 案例 D：優秀作者要求按 DLC 營收分潤

公司希望把獨立大型內容 MOD 轉為付費 DLC。作者要求某固定比例，公司希望一次性買斷。雙方在財務條件不一致的情況下，可以試算各自風險，提出混合條件，例如有最低保證費用加有限期間、明確結算基礎的分潤；也可以談判失敗、保留 MOD 獨立。

研究問題： 具有最低保障的混合報酬能否降低後續糾紛與作者收入波動？

19.5 案例 E：同一成果有五位實際作者

主投稿者負責程式，其他四人提供圖像、配音、翻譯與建模。主投稿者無法自然代表所有人的著作財產權。若公司希望全部收錄，需依共同創作或各別作品的權源完成確認。若只有三人同意，不應把另外兩人的成果直接併入；可以重新設計替代部分或暫停整合。

研究問題： 資產級權利清單是否能降低多人創作整合的漏查比率？

19.6 案例 F：合作完成後原作者要求撤回

撤回請求涉及既有授權是否持續有效、已發布版本與使用者期待、受約定範圍內的修改權，以及可能的法律終止事由。公司不應說「簽過一次就永遠沒有任何權利」，作者也不能只因不再喜歡公司就假定既有合法授權自動失效。應依契約、法令及平台條款逐項處理。

研究問題： 明確的終止、回退與存量用戶保障安排能否降低合作關係破裂的成本？

19.7 案例 G：公司 AI 誤以為已經簽約

外部作者與 AI 客服討論一份授權條款草案，AI 生成「公司已同意你的分潤」。但實際沒有受權限的人批准，亦未履行必要簽約流程。這是一個治理失敗的設計案例。系統必須分離 DRAFT_OFFER、APPROVED_OFFER、COUNTERSIGNED 和 ACTIVE 等法律／業務狀態，公開介面不能將待審文案投影成有效契約。

研究問題： 授權狀態與 AI 文字生成分離，能否降低錯誤承諾及申訴？

19.8 案例 H：不具備原始碼權限的外部玩家提出核心效能改進

玩家只能看到公開 Benchmark、遊戲行為、API 契約與測試場景，卻找到一個能大幅降低成本的算法路線。公司不必立刻開放商業核心，而可以建立一個獨立的最小重現專案，在不暴露秘密的情況下驗證候選，再由內部工程人員整合。若需要進一步使用作者具體程式與商業權利，則另行取得授權。

研究問題： 將問題隔離到公開測試介面能否降低外部合作的保密成本？

20．可反駁假說：不是把開放合作當成道德上的必勝答案

以下 H01–H12 皆為待驗證假說；無一被本文視為已有 EveMissLab 實測結論。

H01｜有效交付假說。 在具有明確 SDK、權利政策與審查工作流的遊戲中，外部投稿的高品質正式交付比例，可能高於只有論壇提案而無正式協作入口的對照組。

H02｜審查成本假說。 AI 輔助初步分類能降低每個有效投稿的人工審查時間，但在低品質投稿大量增加時，總審查成本仍可能上升。

H03｜合作轉換假說。 提供自願且清楚的 L1→L3／L4／L5 合作路徑，可能提高具備開發能力玩家的參與意願，但不必然提高其對公司的忠誠或正式收錄率。

H04｜授權衝突假說。 資產級權源表與正式商業採用前的權利雙閘，可能降低授權不全及事後下架事件。

H05｜公平感假說。 清楚區分無償、Bounty、買斷、委託與分潤的政策，可能提升貢獻者的程序公平感與理解程度。

H06｜維護可繼承假說。 合約中明確處理維護退出、移交、修改及再委託，可能降低官方收錄內容在原作者退出後的修復延遲。

H07｜安全成本假說。 對外部 PR 使用隔離 CI、最小權限與權利審查，比直接以內部高權限自動化執行未知投稿更能降低特定供應鏈事故風險，但可能增加開發時間與部署成本。

H08｜分潤爭議假說。 具有固定收益計算基礎、報表與查核條款的分潤合作，比只約定模糊比例而沒有計算細節的合作，較少發生後續財務爭議。

H09｜非收錄價值假說。 官方提供相容 SDK、回報與測試支援，即使不買斷 MOD，也可能提高玩家滿意度與社群活力。

H10｜產品一致性反作用假說。 若外部正式整合過多、缺少設計治理，可能使遊戲平衡、敘事一致性與維護成本惡化；高投稿合併率不必然提高商品品質。

H11｜AI 權利模糊假說。 AI 生成投稿比例上升，如果缺少來源與創意投入紀錄，可能增加權源不確定案件以及審查延遲。

H12｜可觀察信譽假說。 公開回覆、合理報酬與正式交付有連續證據的公司，可能比只公布「我們重視玩家創意」的公司，得到更高且較穩定的外部協作信任；但公開失敗紀錄也可能對短期評價形成負面影響。

20.1 不支持假說時如何修正框架

若 H01 不成立，應先檢查是否作品並不需要大量外部貢獻、SDK 定義不足、審查閘門過度複雜，或投稿類型不具可比性。若 H05 不成立，應檢查報酬條款是否過度專業化，使社群反而不敢參與。若 H10 成立，則需要降低官方採納率或調整設計決策方式，而不是執著於開放協作數量。

20.2 不應為維護理論而挑選有利樣本

必須允許出現：外部協作比封閉團隊更慢、作者寧願獨立而不希望收錄、正式開放 PR 幾乎沒有人參與、AI 篩選導致優秀非典型投稿被誤刪、公司付款後仍陷入版權爭議等不利資料。它們是理論邊界，不是應從報告中刪除的例外。

21．實證研究設計：區分生產力、社群活力與制度成本

21.1 研究單位不只是一個 PR

單一 PR 可能影響數個版本、玩家群體、MOD 或共同作者；同一位創作者也可能多次投稿。若把每個 PR 當作彼此獨立的實驗樣本，可能高估統計有效性。建議觀察單位至少分成：投稿事件、個別資產、合作關係、正式版本及季度產品線，並依作者與遊戲建立分層或群集分析。

21.2 最少四組比較條件

在同類型、相似複雜度、相近開發階段的候選任務中，設計四組條件：

這是研究設計草案，不應直接把不同遊戲、不同比例的自願者當成可比的隨機實驗。若真要進行比較，需事先規劃任務分派、玩家同意、基準難度、樣本大小、反作弊與敏感資料最小化。實務上可先採用配對或階段性部署的準實驗，而非追求形式上的隨機化。

21.3 主要觀察指標

品質交付率（Verified Contribution Yield）：

其中分母應是進入指定比較條件的有效投稿，而非把 spam 或不完整機器灌水一律排除後才計算。並另提供原始投稿數、無效投稿數與分群理由。

正式採納率（Official Integration Rate）：

此數值低不一定代表制度失敗：公司可能依創作方向選擇保持 MOD 獨立。因此應與作品類型和拒絕理由共同解讀。

平均處理成本（Review and Integration Cost）：

此處各成本需換算到可比較的期間及相同單位；若某期間沒有成功交付，不能進行除以零，應報告為「無法估計／該期間零交付」，並保留總成本。

權利問題逃逸率（Rights Issue Escape Rate）：

不能只看已被投訴的項目，最好另抽樣對照來源檔以辨識未報告問題的方向性偏差。

付款履約準時率（Timely Payment Fulfillment）：

尚未到付款期限的項目不應放入分母；沒有有償案件的期間應標示不適用，而非 100%。

作者持續合作選擇率（Voluntary Continuation Rate）： 對完成有效合作且已有充分觀察期的作者，測量願意再次合作的比例，並區分公司是否曾發出邀請，避免把沒有新任務誤作作者不願合作。

21.4 非量化結果同樣必要

建議訪談作者對議價的理解、退出自由、著作權尊重、AI 介面是否會造成不當承諾，以及公司拒絕正式收錄後是否仍能維持良好互動。外部投稿可保持匿名或化名，不應為研究要求公開個人聯絡資訊。

21.5 反事實與差異中之差異

若某遊戲導入制度後 PR 大幅增加，也可能是同期大型更新、銷售折扣、遊戲知名度增加或一名意外爆紅的作者造成；不能把前後差全部歸因於制度。可尋找功能相近、時間相近的對照遊戲或產品子系統，建立差異中之差異等較穩健方法，並公開平行趨勢假設、樣本選取及失敗限制。

21.6 觀察期間不能只看合併當天

PR 合併時通常最容易留下正面指標。真正成本可能在 30、90 或 180 天後，因存檔回歸、第三方授權、DLC 退款或作者退出才出現。建議每項正式收錄至少有預定觀察窗，而不是只在發售公告上寫「合作成功」。

21.7 公平比較需要處理難度與重要性

修復錯字、補日文語系檔、改世界經濟模組、提供安全修補和新增 3D 地圖，不應無條件算為同等一項成果。研究可依需求規模、風險、資產類型、依賴數量與預定玩家價值分群，再呈現加權與不加權結果。權重若由公司自行設計，應揭露其形成理由，避免以權重美化成果。

21.8 最小研究預註冊

開始實驗前應固定：主要假說、樣本範圍、比較組、主要指標、缺失資料處理、停止條件、可用的法律與安全資料範圍。事後可以擴展探索性指標，但不能把事後挑選最漂亮的數字當成最初預註冊的研究結果。

22．最強反例與制度失敗路徑

22.1 開放投稿反而讓玩家不敢發言

若公司把每條意見都引導為「請自行修復後提交 PR」，一般玩家可能因沒有程式能力而被排除。制度必須保留不需寫程式的回饋管道；有能力提交 PR 是額外選項，而不是取得客服與產品回應的資格門檻。

22.2 公司用熱愛遊戲作為無償工作的理由

若公司不斷把原應由內部付費完成的修復標成「社群貢獻」，可能創造實際勞動剝削。研究必須追蹤有償／無償邊界，並讓作者有權拒絕額外維護義務。不能因有開源文化就自動替代所有契約公平性。

22.3 作者過度要求權利使公司無法維護

若公司只取得無法修改、無法移交、不適用未來版本的非常狹窄權限，短期可能完成漂亮的官方收錄，長期卻無法修復安全漏洞。這不是作者一定錯，而是提醒公司：在簽約前應先衡量最小必要的合法維護權利；談不攏就不收錄。

22.4 公司要求廣泛永久權利反而失去優秀作者

若所有投稿都被迫簽下無報酬、可任意轉售與永久排他使用的條款，可能只留下不了解條款的創作者，反而讓有經驗者退出。制度應檢驗「更高權利取得比例」是否導致合作品質與信任下降。

22.5 AI 讓公司低估作者的原創性

某 MOD 大量使用 AI 產碼，但真正創意在玩法架構、數據平衡與測試迭代；若公司因「AI 很容易再寫一份」就忽略作者的獨特設計和累積工作，會錯估其貢獻價值。反之，AI 生成也不應自動把欠缺合法來源的內容神化為創作者的排他資產。需要分開評估可保護的著作權、專業勞動、品牌與使用價值。

22.6 大量惡意 PR 淹沒審查

外部投稿的低成本可能誘發 spam、程式植入、供應鏈攻擊與不實來源聲明。安全隔離、入口限流與風險分層必要，但若過度自動化封鎖，又可能壓制非典型作者。應保留合理申覆與人工抽查。

22.7 合作者署名變成另一種社群權力

若公司只與大 MOD 作者合作，其他作者可能不再有參與機會；若曝光位置由平台流量決定，也可能誘發刷票和派系競爭。評估提案時應盡量區分內容證據、人氣與作者社群關係，且不必要求公司永遠平均分配所有資源。

22.8 過度公開合約害到作者

公司為了強調透明，把創作者真名、金額、帳戶或私人談判內容全部公布，可能破壞安全及信任。選擇性透明不是保密的藉口，而是將應解釋的產品決策和不必公開的私人資料分離。

22.9 團隊為了追求社群合併率而失去遊戲完整性

某款敘事作品有明確的作者意圖及難度設計，不適合每月吸收十種互相衝突的系統。公司的正當權力包含選擇「只支援作為 MOD，不正式收錄」，並清楚解釋理由。[I04]

22.10 收入分成成本遠高於收益

極小 DLC 若涉及多平台、多作者、多種退款與稅務條件，長期結算可能比 DLC 本身的收益高。在此情況下，一次性授權費或讓 MOD 維持免費獨立，可能比複雜的永久分潤契約合理。

22.11 作者並不希望成為公司的合作夥伴

有些創作者享受自主、匿名、非商業的創作關係，對公司邀約沒有興趣。制度不能把不想轉正的作者描繪成不成熟或放棄機會；其選擇權本身就是良好生態的一部分。

22.12 制度形式完整，但公司根本沒錢履行

公司可能具備很強的 AI 生產能力，卻缺乏現金支付已承諾的委託費。公司應將付費合作建立在可負擔的實際預算上，而不是以「未來遊戲賣得好就付」取代清楚的風險分配。ANIE-02 對產能與現金流的分離，在此處仍然適用。[I02]

23．EveMissLab 可採用的最小部署路線（概念性方案）

本文不宣稱下列任何階段已在 EveMissLab 遊戲產品生產環境上線。它是一條可拆解、可驗證、可停止的實施路徑，可依產品、人力、現金流、法務與平台限制調整。

23.1 階段 0：對外建立貢獻邊界

發布簡短政策：哪些作品接受提案、哪些接受 PR、哪些歡迎 MOD、哪些不接受外部權利不明素材，以及免費貢獻與付費合作如何區分。設立正式聯絡與爭議處理入口，不要求玩家先成為公司社群成員才能提交一般建議。

驗收： 外部新使用者可在沒有私人解釋的情況下回答：自己能提交什麼、誰能回覆、是否有機會取得報酬、公司是否自動取得作品權利。

23.2 階段 1：公開 SDK 與貢獻指引

選一個非敏感且真正能影響遊戲的擴充子系統，建立範例、相容測試和 PR 流程。初始可以是資料型規則、語系檔、地圖資料或事件掛點，不必開放世界狀態核心或內部 AI 工具。

驗收： 陌生開發者能依公開文件完成最小插件、通過測試並提出審查請求；官方可以在不公布私有原始碼的情況下重現其成果。

23.3 階段 2：AI 分類與安全驗證

導入低風險 AI 分類、資料盤點、回報摘要與候選測試生成。所有外部腳本在隔離環境執行，沒有內部部署憑證和正式付款權限；投稿系統對外顯示的狀態從資料庫取得，而不是任由 LLM 編造。

驗收： 不可信 PR 不能讀取正式秘密、不能因 AI 的自然語言回覆直接取得合併權或付款權；每項 AI 建議都有人工可追蹤的接受或拒絕紀錄。

23.4 階段 3：一個真實但低風險的有償試點

在實際預算允許時，選一個權利界線清楚、可驗收且後續維護成本有限的候選任務，透過書面合作條件委託外部作者。驗收必須包含雙方簽署狀態、付款條件、著作權利用範圍及失敗退出機制。若缺少現金流或法律準備，可暫不啟動付費試點。

驗收： 公司能完成提出需求、報價、批准、交付、驗收、付款與署名的全流程，且沒有意外擴張權利或個資公開。

23.5 階段 4：一個 MOD 正式收錄試點

從合法、作者願意談判且能建立權利清單的 MOD 開始。簽署具體的商業整合授權後，檢查原始 MOD 所有相依資產、多人共同作者、第三方字型和 AI 生成素材，並進行實際遊玩及存檔回歸測試。

驗收： 對外能指出作品來源、作者願意公開的署名、正式產品版本、授權範圍摘要、已完成測試及後續維護責任。

23.6 階段 5：多遊戲、跨產品共用治理中樞

若前面階段可驗證有效，再將貢獻資料與原有遊戲進度網站、Publication Hub、GitHub、AI 客服及公司內部決策系統連結。各產品可以有不同法律政策與開放程度，但基礎事件、權限與報酬資料可使用共同資料模型。

驗收： 新遊戲可重用貢獻入口、審查狀態、權源檢查及季報框架，而不會把舊遊戲的授權自動帶到新遊戲。

23.7 初期應明確不做的事情

不急著建立跨平台全自動合約、無人審核付款、對所有投稿的營收分成、社群治理代幣、永久免費勞動排名，或讓公司 AI 對外承諾任何新增功能與報酬。這些不是因為技術必然不可能，而是因制度尚未證明有效時，其權利與財務風險可能超過 MVP 所需價值。

24．與 ANIE 其他篇目和既有研究的接口

24.1 ANIE-00：互動企業不等於全部公開

外部貢獻可以作為企業互動生產的一條新通路，但只有完成權利、品質與權責決策後，才適合投影成對外承諾。每個事件都有可公開與需保密的不同欄位。[I00]

24.2 ANIE-01：EA 和正式版都可以接受貢獻

EA 玩家可能更願意參與功能創作，但非 EA 遊戲亦可有公開 PR、MOD SDK 和合作委託。是否接受 PR，不應被平台發售標籤一概決定。[I01]

24.3 ANIE-02：AI 產能與外部協作成本需合併計算

公司可能很快地生成遊戲程式碼，但外部權利與財務審查需要不同能力。完整的生產力衡量應把合作審查、合約、結算及後續維護列為實際成本。[I02]

24.4 ANIE-03：合作成果必須能被合法接手

受託人離開後，若公司無權修改其程式或沒有建置文件，即使已付費，也可能無法繼續維護。契約不只應處理收錄，亦應處理合法維護與資產移轉。[I03]

24.5 ANIE-04：拒絕與協商均可合法且合理

作者和公司可以談不成；玩家提出改善不等於公司有義務採納；公司希望採納也不等於作者有義務商業授權。[I04]

24.6 ANIE-05：技術接口是最低可行基礎

穩定 MOD API、schema、相容性測試與回退能力，可讓外部成果在不同版本更容易存續。但原生 MOD 生態的技術 PASS 不能替代本篇的權利與報酬契約。[I05]

24.7 ANIE-07／08／09：對外網站、AI 互動與決策帳本

下一部將定義外部資訊平台、AI 客服與公開決策記錄。本文提供其中的 contribution_id、license_gate、contract_status、payment_status、official_release_ref、disclosure_policy 等接口欄位，使跨系統資訊能以受控方式互相連結，而不讓敏感資料直接進入公開網站。

24.8 與 SEDB-GAME × ModWorld 的區分

既有 SEDB-GAME × ModWorld Runtime 研究處理遊戲語義、MOD 生成和有效世界驗證；本文關心的是 MOD 作者作為外部權利主體，何時以及如何與持有商業發行權的公司形成明確交易或合作關係。兩者可互相對接，卻不應相互替代。[I06]

25．跨出遊戲產業後的可遷移性

25.1 對開源與閉源混合軟體的應用

SaaS 公司可以公開外部插件、讓用戶提交擴充與修復，同時保留後端私有服務。付費擴充、插件市場、授權及安全檢查面臨相似問題；但不同軟體可能有更高的資料安全及營運持續性要求，不能直接套用遊戲容忍度。

25.2 對研究軟體與學術平台的應用

外部研究者可能提出演算法、論文校對、驗證程式與資料集標註。若將其收錄為正式研究服務或商用模型，需另外處理學術署名、資料倫理、授權與研究證據保存，不能把本篇的 MOD 收錄條款原封不動搬到科學貢獻上。

25.3 對內容與數位創作平台的應用

使用者創作的字體、音效、素材和互動敘事，可以經由明確的授權與報酬進入商業內容。惟第三方表演者、著作權集體管理、肖像、商標及跨境利用的複雜性，可能高於單純的程式碼 PR。

25.4 對企業管理的新增命題

在 AI 系統提高外部知識轉換能力的時代，公司真正需要思考的，或許不只是「哪些事情交給員工做」，而是「哪些成果可以由外部自主生成、哪些需要公司委託、哪些必須內部承擔責任」。這是一個值得量化的組織邊界問題，與 Benkler 的同儕生產理論形成可比較研究，但並不預設外部協作在所有領域都比正式組織更有效。[E04]

26．研究限制與必要保留

26.1 法律不是跨國一體適用

本文以臺灣法及目前可核對的 Steam／GitHub 官方條款作為研究起點。跨境合作者、跨平台販售、多人共同創作與 AI 著作權涉及不同適用法與契約條件；真正商用前須重新確認最新有效規範。

26.2 本文不是契約法律意見

附錄中的政策與條款僅用於說明制度欄位，不能直接視為已可執行的標準契約。尤其著作人格權、著作財產權讓與、再授權、付款稅務、爭議處理及勞動從屬性，應經實際法務程序審查。

26.3 制度成功需要真正可用的技術接口

若遊戲根本沒有穩定的擴充或測試介面，外部人再有意願，也很難完成低成本協作。ANIE-05 提出的 MOD 原生接口可提供前置條件，但不應誤認其已完成正式生產驗證。[I05]

26.4 作者自願參與具有選擇偏誤

本制度吸引的往往是熱愛遊戲、具備開發能力及願意公開協作的人；其意見不代表所有玩家，更不能推論一般消費者也希望參與公司治理。[I04]

26.5 AI 可以改善流程，也可能製造新風險

AI 可能提高缺陷回報與 PR 候選數，卻同時提高來源不明素材、錯誤代碼或合約誤解的數量。任何主張「AI 讓外部協作幾乎沒有成本」的敘事都須經驗證，而不能用理論可能性替代測量。

26.6 產品品質依然不是民主票數

公司應有責任地處理外部意見、支付已約定報酬、遵守授權與法規，但它仍可以選擇不將某款受歡迎 MOD 收進正式版。合法權利與程序正義，是必要邊界；「所有人意見都被滿足」不是可行的品質標準。

27．結論：讓玩家能夠成為創作者，但不必變成公司的附屬物

本研究的起點是一個容易被舊式商業遊戲開發直覺忽略的問題：如果一位玩家能發現真正的產品缺陷、提出可重現測試、提交合法 PR、製作高品質 MOD，甚至有能力獨立完成某個功能，為什麼他只能停留在留言區等待公司回覆？為什麼公司一定要在「完全封閉」與「全面開源」之間二選一？

外部研究與平台文件已說明，使用者創新、同儕生產、PR 協作、Curated Workshop 與有償收錄都並非新發明。本文的目標是把這些分散機制安置到AI 原生、可驗證季度交付、具有正式權利與報酬治理的商業遊戲組織之內。真正的核心不變量是：

1. 玩家不是公司人力庫。 玩家可自願提出需求、創作 MOD、接案或拒絕合作。
2. 公司不是所有玩家作品的自然權利人。 技術接受與商業授權須分開。
3. 作者不是因為完成 PR 就當然成為員工。 實際法律關係依個案事實認定。
4. MOD 不是只有被公司買斷才有價值。 獨立創作與正式收錄可以並存。
5. 付款不是合約全部。 維護、修改、署名、再授權、退出及已有玩家的權益亦需處理。
6. AI 不是自動裁決者。 它能協助建立證據、縮短候選生成及檢查成本，卻不能未經授權形成法律承諾。
7. 公開治理不是全面揭露。 可供社群檢驗的政策、決策與交付證據，應與個資、契約保密內容及商業秘密分開。

因此，「商業遊戲也可以 PR」真正要說的不是請玩家免費幫忙寫程式，而是：當玩家願意提供可驗證成果時，公司有能力提供一條清楚、合法、有尊重、可議價、可拒絕與可持續維護的合作路徑。

倘若制度在實證中確實降低協作摩擦、提升產品品質、增加作者選擇權且維持商業可持續性，它便可能成為 AI 時代小型科技企業擴張產能的一種方式；倘若結果顯示成本、衝突與剝削風險更高，也應修改或收斂制度，而不是以開放口號替代現實證據。

附錄：工程資料契約、法律審查欄位與實驗工作文件

以下附錄均為研究用最小提案規格，並非已部署的產品配置或經律師審定之法律文件。JSON／YAML 是資料表達範例，不表示執行它們即能合法取得商業權利。實作前應完成權限、架構、契約與資安審查。

附錄 A．外部貢獻政策示例（CONTRIBUTING.md 概念草案）

A.1 政策標題及摘要

《行界遊戲：外部貢獻與合作政策（示例）》

本遊戲歡迎玩家提出問題、意見、翻譯、MOD、SDK 改進、測試與技術提案。我們尊重作者自主創作，不要求玩家成為公司員工。接受投稿不代表接受所有功能，也不代表所有作品將進入正式版。若欲取得超過一般貢獻政策授權範圍的商業使用權，我們會依情況另行洽談。

A.2 接受的投稿形式

• 意見與問題回報：可透過公開網站或支援管道提出；敏感內容可走非公開管道。
• SDK 與公開工具的 PR：應說明更動理由、相容影響、測試方式和適用專案授權。
• MOD 創作：可依已發布的 MOD 指南自行維持獨立作品。
• 商業收錄邀約：作者可自主決定是否談判，需釐清作品來源與使用權。
• 付費委託：只在經公司授權的正式程序下生效，不以 AI 客服的閒聊回覆作為付款承諾。

A.3 給投稿者的明確承諾

我們會努力確認問題是否可重現、明確標記投稿的處理狀態，並在必要時說明未收錄理由。涉及著作權、商業機密、安全與個資的細節可能不對外公開。創作者有權選擇不接受公司提出的商業授權條件，並可就具體合作提出不同方案。

A.4 公司保留的必要權限

公司保留是否整合到正式版、採用何種替代設計、是否安排資源、如何處理安全和合規風險，以及是否開始商業協商的決策權。此權限不代表公司能未經適當權源取得投稿者作品，也不代表公司可免除既有承諾或法定義務。

A.5 投稿者須知

投稿者應有合理依據說明所提交作品的來源及有權提供的利用範圍。請勿提交含有未經授權的第三方作品、私人資料、惡意軟體、商業機密或可能危害玩家的內容。若包含 AI 協助生成的程式或素材，應按政策提供足以識別權源與人工創作貢獻的必要資訊。

A.6 重要澄清

未經另行明確約定，玩家的一般提案不等於公司已承諾製作；公司未邀請合作不等於投稿作者的作品價值受到否定。公共 PR 的授權以該公開專案的具體授權及有效貢獻規範為準；正式商業收錄或付費開發的額外權利應另行確認。

附錄 B．最小貢獻資料契約（JSON 示例）

以下 JSON 為格式示例，全部識別碼及內容均是假設值，不是已接受、已簽約或已付款的實際案件。

{
  "schema_version": "ANIE-ECA-0.1",
  "contribution_id": "ANIE06-EXAMPLE-0001",
  "game_id": "fictional-game-a",
  "contribution_lane": "L1_INDEPENDENT_MOD",
  "contribution_type": "gameplay_mod",
  "title": "Independent faction management experiment",
  "public_display_author": "SampleModder",
  "identity_verification_ref": null,
  "submitted_at": "2026-10-16T00:00:00+08:00",
  "candidate_artifact_uri": "example://unresolved/artifact",
  "artifact_sha256": null,
  "source_provenance": {
    "author_claim_received": true,
    "coauthors_declared": false,
    "third_party_assets_declared": true,
    "ai_assistance_declared": true,
    "evidence_status": "PENDING_REVIEW"
  },
  "workflow": {
    "intake_status": "RECEIVED",
    "technical_gate": "NOT_EVALUATED",
    "security_gate": "NOT_EVALUATED",
    "product_gate": "NOT_EVALUATED",
    "rights_gate": "NOT_EVALUATED",
    "maintenance_gate": "NOT_EVALUATED",
    "official_integration": "NOT_REQUESTED"
  },
  "commercial_terms": {
    "negotiation_requested": false,
    "contract_ref": null,
    "contract_status": "NOT_APPLICABLE",
    "compensation_model": "NONE",
    "payment_status": "NOT_APPLICABLE"
  },
  "public_disclosure": {
    "proposal_metadata": "PUBLIC",
    "rights_evidence": "RESTRICTED",
    "identity_records": "CONFIDENTIAL",
    "contract_details": "CONFIDENTIAL",
    "public_decision_ref": null
  },
  "official_release_ref": null,
  "notes": "Hypothetical research example only"
}

B.1 資料中的必要區分

author_claim_received 不等於 rights_gate=PASS，artifact_sha256 能證明位元組一致性但不證明著作合法，public_display_author 不是具法律效力的付款身分，negotiation_requested 不代表契約成立。各欄位的真實證據必須另行存在受權限控制的正式來源，不能靠公開 JSON 自己聲稱有效。

B.2 狀態不得跳躍的規則

若 contract_status 不是 ACTIVE，系統不得對外投影「付費合作已成立」；若 rights_gate 不是 PASS，則不能標為已完成商業收錄的法律檢查；即使 official_release_ref 存在，也應在事後稽核確認公司是否真的具有相關權源。

附錄 C．權利來源與再授權清單（YAML 草案）

schema_version: ANIE-RIGHTS-0.1
submission_id: ANIE06-EXAMPLE-0001
status: research_example_not_legally_verified
asset_records:
  - asset_id: script.faction-management
    asset_type: source_code
    origin_type: contributor_authored
    owner_claim: SampleModder
    owner_claim_verified: false
    upstream_license: pending
    contributor_grant_scope:
      game_products: []
      platforms: []
      territories: []
      commercial_distribution: false
      modification: false
      sublicense: false
      continuing_maintenance: false
    ai_assistance:
      involved: true
      disclosure_received: true
      provider_terms_reviewed: false
      human_creative_contribution_reviewed: false
    evidence_refs: []
  - asset_id: character-portrait-001
    asset_type: image
    origin_type: third_party
    owner_claim: unknown
    owner_claim_verified: false
    upstream_license: unknown
    contributor_grant_scope:
      game_products: []
      platforms: []
      territories: []
      commercial_distribution: false
      modification: false
      sublicense: false
      continuing_maintenance: false
    ai_assistance:
      involved: false
      disclosure_received: false
      provider_terms_reviewed: false
      human_creative_contribution_reviewed: false
    evidence_refs: []
conclusion:
  rights_gate: BLOCKED
  reason: missing_rights_and_incomplete_third_party_clearance
  can_publish_officially: false

C.1 為何將範例設為 BLOCKED

如果範例把 owner_claim_verified 標成 true、把 commercial_distribution 全部設成 true，讀者可能誤把研究範本視為可以直接放進正式遊戲的授權文件。因此特意建立一個「有投稿、但沒有完成合法權利查核」的負面案例。工程上的正確行為是保持阻擋、等待補件或刪除有疑慮資產，而不是 AI 自動補上擬制同意。

C.2 跨平台、跨續作不是預設範圍

未來若需要讓 MOD 同時用於 Steam、GOG、直接下載版本或後續作品，應把每一種目標利用範圍納入協商；若有不確定處，保持未授權狀態。不能以「公司擁有遊戲 IP」代替對投稿者自有作品的權利確認。[E07]

附錄 D．商業收錄契約議題清單（非可直接簽署的契約）

D.1 雙方與作品

記錄雙方合法簽約主體、用於公開署名的名稱、作品識別、版本 hash、作者與共同作者名單、第三方來源清單，以及雙方對內容是否完整具權利處分能力的陳述。未知權源不得以「本人保證」單獨替代客觀查核。

D.2 權利條款

必須具體討論：

• 授權／讓與／委託成果的法律性質；
• 遊戲本體、DLC、宣傳、官方網站、串流畫面、續作、移植、其他產品是否包含；
• 改作、翻譯、拆分、合併、資料化、修補及必要再授權是否允許；
• 是否專屬、地域、期間、撤回或終止條件；
• 作者人格權與合理署名安排；
• 第三方權利、共同作者和開源授權的保留義務；
• AI 訓練、跨模型再利用、資料集二次商用是否另受限制。

D.3 交付與驗收

應載明交付版本、需求規格、測試環境、來源檔、依賴資料、已知限制、修復期間和驗收方式。驗收不合格時，是否允許補正、補正期限、部分驗收及爭議處理，須提前約定。不能只在交付後由單方臨時新增完全不同的功能要求。

D.4 報酬與帳務

約定金額或計算公式、支付節點、發票／扣繳與合法付款資料、匯費、退款與折扣影響、分潤期間、報表提供方式和合理查核程序。對跨境交易應另查當地法規，不能將公司一般會計設定直接作為所有國籍創作者的法定稅務處理。

D.5 維護與退出

約定最低維護範圍、更新通知、公司必要修補權、原作者退出後是否可以委託他人維護、既有產品版本是否可繼續販售、重大漏洞處理及交接資料。若維護費是獨立對價，則它的終止也不必然等於原始作品授權一併消滅，需依具體契約處理。

D.6 保密與公開

應區分作者可公開的作品資訊、公司能公開的合作摘要、雙方需要保密的金額、未發布劇情、原始碼、個資和付款紀錄；並規範何時可共同公告正式收錄。公開的「合作成功」也應有真實可驗證版本作為基礎。

D.7 事故與爭議

明確約定權利爭議通知、涉嫌侵權資產處理、緊急下架或替換、對既有玩家的處理、責任範圍及合理救濟。此處不能假設所有條款都可以排除法定責任；正式簽署時需要律師依具體情況審查。

D.8 一個需要特別避免的條款

「凡作者現在或未來對本公司遊戲之任何貢獻，均無償、永久、排他地歸本公司所有，作者不得提出任何請求。」

這種模糊、過廣、未區分著作類型與法律性質的文字，可能造成法律與社群上的重大爭議。本文不以此形式作為任何作品投稿的預設條款。

附錄 E．PR 安全與合併的最小檢查矩陣

E.1 低權限示意 CI（不含部署憑證）

以下 YAML 僅為安全方向的最小示意，不能單憑此範例認定完整安全。實際需要依 GitHub Actions 當時版本、權限政策、隔離環境與依賴關係完成審查。[E15][E17]

name: external-contribution-check
"on":
  pull_request:
    types: [opened, synchronize, reopened]
permissions:
  contents: read
jobs:
  validate:
    runs-on: ubuntu-latest
    timeout-minutes: 10
    steps:
      - name: Check out proposed change
        uses: actions/checkout@v4
        with:
          persist-credentials: false
      - name: Inspect static contribution rules
        run: |
          python3 -c 'print("Example only: replace with a vetted, non-secret static validation tool")'

本示例特意不使用 pull_request_target、不提供部署金鑰、不自動呼叫公司商業發布流程，也不執行未來投稿者附帶的任意 install hook。GitHub 官方對 pull_request_target 與不可信程式執行的風險有專門警告；實作時應使用經驗證的 action 版本／pinning、限制權限與進一步的執行隔離，而不是直接將示例當作生產等級配置。[E15]

E.2 為何 CI 成功仍不能正式收錄

CI 可以執行測試與部分規則，但無法憑一次 green 狀態證明第三方圖片有合法商業權源、合約已簽署、玩法符合設計、玩家不會失去存檔，或公司已準備好支付約定款項。技術 CI 是 RQDG 中的一部分，不是整個制度。

附錄 F．三種合作報酬的假設計算及爭議情境

F.1 固定費用委託

假設委託一個經雙方同意的 UI MOD 相容修復：固定報酬 新臺幣 12,000；完成規格驗收後支付 新臺幣 8,000，三十日穩定驗證期滿且符合約定條件後支付剩餘 新臺幣 4,000。這裡的兩個節點只是假設，不代表任何真實專案報價，亦不意味著可以任意延長已完成工作應付的報酬。

需另外處理：未通過驗收時的可補正內容、公司臨時變更需求、作者時間成本、已交付的合理部分、保固或修復期限與契約解除後的權利。若只談金額而不談權利與維護，付款後仍可能無法合法修改程式。

F.2 一次性授權與讓與比較

假設某作者提供已完成的角色 MOD。公司只需要在單一作品兩個主要版本內使用該角色，作者仍想維持獨立 MOD。在此情境下，有限、可修改的非專屬授權可能符合雙方意願；買斷全部可讓與著作財產權可能超過公司的實際需要。反過來，若公司規劃大量衍生版本、跨平台移植及獨立周邊，則需要更廣泛的利用權利，通常也應反映在議價條件上。

這並不是設定非專屬授權永遠比較好。真正的選擇標準是：預定用途是否清楚、作者願意付出多少控制權、公司是否願意承擔對價及維護成本。[E07]

F.3 分潤假設算例（完全虛構）

假設某 DLC 在一個結算期間有以下數字，全部為示意，不是 Steam 或 EveMissLab 真實抽成率、銷售量或合約：

若合約沒有定義退款、稅款、通路費用是否可扣除，單純約定「15% 營收」就可能產生爭議。上述算式只說明計算應具有透明分母，不意味著此扣除方式在任何司法轄區或平台均合法、必要或最公平。真實稅務應按實際法規與契約處理。

F.4 平台先行分配的雙重付款問題

如果某平台已代公司向作者分配該內容收益，則公司內部對帳要標示 settlement_origin 與 already_disbursed。否則看似給作者雙倍獎金，也可能在下一次才發現重複給付，造成返還糾紛。相反地，也不能以「平台應該有付」拒絕履行公司自己已成立但平台未代為支付的義務。[E02][E19]

F.5 分潤與失敗的風險分配

固定報酬由公司承擔較多銷售風險，持續分潤由作者承擔部分市場風險；但分潤也可能使作者在產品成功時取得更多收入。雙方可事先協商不同方案的情境估算，而不是把其中一種包裝成絕對公平。合理的方案應讓作者理解：銷售為零、公司暫停遊戲更新、DLC 被下架或平台停止供應時，合同將如何處理。

附錄 G．外部協作事件狀態機（研究規格）

G.1 受理狀態與契約狀態分開

INTAKE_STATUS:
  DRAFT -> SUBMITTED -> RECEIVED -> TRIAGED
  TRIAGED -> IN_REVIEW | NEEDS_INFO | DECLINED
  IN_REVIEW -> ACCEPT_CANDIDATE | NEEDS_INFO | DECLINED
  ACCEPT_CANDIDATE -> RELEASED | WITHDRAWN | ARCHIVED

RIGHTS_STATUS:
  NOT_EVALUATED -> CLAIM_RECEIVED -> PENDING_EVIDENCE
  PENDING_EVIDENCE -> PASS | BLOCKED | REJECTED
  PASS -> RECHECK_REQUIRED [when scope/artifact changes]

CONTRACT_STATUS:
  NOT_NEEDED | NOT_STARTED
  NOT_STARTED -> DRAFT -> APPROVED_FOR_OFFER
  APPROVED_FOR_OFFER -> OFFER_SENT
  OFFER_SENT -> COUNTERSIGNED | DECLINED | EXPIRED
  COUNTERSIGNED -> ACTIVE
  ACTIVE -> COMPLETED | TERMINATED | SUSPENDED

PAYMENT_STATUS:
  NOT_APPLICABLE | NOT_DUE | DUE | PROCESSING
  DUE -> PROCESSING -> PAID | FAILED
  FAILED -> REVIEW_REQUIRED

RELEASE_STATUS:
  NOT_REQUESTED -> CANDIDATE
  CANDIDATE -> BLOCKED | VERIFIED_FOR_RELEASE
  VERIFIED_FOR_RELEASE -> RELEASED | WITHDRAWN

G.2 拒絕「AI 聊天造成狀態跳轉」

OFFER_SENT 不應因聊天文字中出現「我們同意」便自動變成 COUNTERSIGNED。PAID 必須對應真實經驗證的付款事件，RELEASED 必須有正式發行版本與可驗證的發行紀錄。若網站被重建或資料庫重新匯入，狀態應以事件來源及授權審核紀錄重建，而非讓 AI 根據敘事補齊缺失。

G.3 權利範圍改變必須重新審核

即使初始版本已獲授權，若公司後來增加新平台、續作、收費方式或 AI 訓練用途，應檢查是否超出原授權範圍。若超出，狀態可回到 RECHECK_REQUIRED，並由作者決定是否擴充授權；原已合法取得且仍有效的既有利用與新用途的授權問題應分開處理。

G.4 付款與公開公告不是同一種權限

產品發布者可以公布某項合作已正式推出，但不應因此取得編輯作者私人付款資料的權限。財務人員可以記錄已付款，也不應單憑此權限修改公開的著作人名單。可實施基於角色或案件的存取控制，並保留例外處理的稽核紀錄。

附錄 H．季度外部貢獻報告範本（非真實成果）

季度： YYYY-QN
遊戲： <某遊戲>
公司對外資訊頁： <正式入口 URL>
資料截止時間： <含時區時間戳>

H.1 投稿與協作

H.2 產品與社群的雙重回顧

公司認為本季最有價值的外部貢獻： 說明理由、驗證結果與採納狀態。
玩家認為最有價值的外部貢獻： 說明回饋來源、樣本與代表性限制。
雙方分歧： 保留具體不同立場，不必假裝完全一致。
維護風險： 說明有哪些模組尚依賴特定作者，何時能完成適當接手。
公開財務摘要： 只在合規、契約允許且能維持個資安全的範圍揭露。
下一季度改善： 對審核瓶頸、版本破壞、作者合約與回應品質提出實際措施。

H.3 不應當成正向績效的數字

不能因外部無償工時增加就宣稱公司節省成本，而不計入審查、作者機會成本及維護責任；不能因獨立 MOD 作者增加就宣稱所有人都是公司的正式開發者；不能因有大量候選 AI PR 就宣稱大量可交付商業成果；也不能因合併率上升就推論使用者滿意度必定提高。

附錄 I．研究樣本與假說預註冊清單

I.1 前置定義

1. 指定遊戲類型、發售階段、可投稿接口及分析期間；
2. 指定外部貢獻定義與剔除規則；
3. 將文檔 PR、測試、修復、素材、MOD、付費委託分開；
4. 明確表示哪些資料是個人資料或契約秘密；
5. 事先決定外部作者是否需知情同意或其他倫理處理；
6. 確立公司實際可投入的人工審核與法務預算。

I.2 主要結局與次要結局

主要結局： 有效貢獻交付數、每個可用交付物的總成本、權利問題逃逸率及收錄後主要缺陷率。
次要結局： 投稿者理解度、再次合作意願、公司回應延遲、社群信任及付款履約準時率。

I.3 預先設定停止條件

若發生可能造成嚴重個資洩漏、金鑰暴露、重大侵權或不可信程式取得正式環境權限的情形，應停止對應實驗路徑並進行事故調查；若連續發生無法按時支付的合作，應停止新的付費委託招募，直到可負擔預算與內控恢復。

I.4 需要報告的負面結果

若開放 PR 降低工作效率、某類合約使作者滿意度下降、AI 把第三方作品錯誤判成原創、進入正式版的 MOD 破壞玩家存檔，均應納入最終報告。此要求不代表公開會造成進一步漏洞利用的細節，而是保留適當的匿名化統計、問題事實及處置證據。

I.5 不能從小樣本推論整個產業

EveMissLab 若未來在自身作品中取得良好成果，也不能直接推論所有遊戲公司、所有司法轄區、所有社群規模都能複製。需考慮遊戲類型、作者群、資料結構、開發文化、AI 工具與經營資源差異，並規劃獨立復現研究。

附錄 J．FAQ：給玩家、公司與未來的 AI 協作者

Q1：商業遊戲不公開原始碼，還能接受 PR 嗎？
可以針對公開 SDK、插件、資料檔、文件、測試和受控合作儲存庫接受 PR；但外部人不能憑 PR 機制要求取得公司所有私有原始碼。[E01][E10]

Q2：玩家先做 MOD，後來官方加入同樣功能，算不算偷 MOD？
不能只靠功能名稱相同就下結論。需要分辨玩法思想、具體著作表達、原始素材與相關授權，並依事實判斷；合理制度應留下來源和開發決策紀錄。[E05]

Q3：我把 MOD 放上 Workshop，是否公司已取得所有使用權？
不能這樣推定。Steam Subscriber Agreement 和個別 Workshop 條款有其授權內容，公司若需超出其已取得的有效權利進行跨平台或其他商業利用，應核對條款及必要時另行協議。[E03]

Q4：我給作者錢，公司是不是就擁有全部著作？
不一定。臺灣出資聘請著作的權利歸屬及授權／讓與方式，須依相關條文及具體契約處理。[E05][E07]

Q5：公司邀請我長期合作，但說我是契約制，所以沒有勞工權益？
不能只看「契約制」的名稱。臺灣勞動部強調依實際從屬性判斷是否為勞動契約；必要時應尋求專業法律或主管機關協助。[E08]

Q6：我只會用 AI 製作 MOD，可以參與嗎？
技術上可以提出候選成果，但必須依政策提供必要的來源、使用條款、人類創作貢獻及品質證據；AI 可協助生成，不替代合法權利和正式驗證。[E14]

Q7：公司若不收我的作品，我必須刪掉嗎？
不因單純未收錄就自動有此義務。仍須遵守原版遊戲及 SDK、MOD、平台和第三方權利的有效規範；與正式商業採用是不同問題。

Q8：創作者有權要求公司一定收錄或支付多少嗎？
除非存在已成立的法定或契約義務，一般提案不能自動形成公司必須收錄或支付特定金額的義務；但作者亦可拒絕公司提出的授權或報酬條件。

Q9：AI 客服說會給我報酬，是不是等於公司簽約？
不能僅憑一般對話推定。須依是否存在適當公司授權、法律要件與正式約定判斷。制度應避免 AI 把草案描述成完成契約，並提供可以檢驗的合同與款項狀態。

Q10：如果公司收錄 MOD，未來更新後壞掉，誰來修？
可依合作與維護契約在公司和作者之間分工，但公司對外商品的適用責任和既有銷售承諾不能單靠「原作者負責」作概括免責。應事前建立回歸測試與可繼承維護權限。[I03][I05]

Q11：為什麼公開網站不公布個別合作報酬？
企業可以公開合作政策、程序、總量及可分享案例，但具體合約金額或個人資料是否公開，應由法律、雙方約定及隱私安全邊界決定。公開更多與公開所有資料不同。[I00]

Q12：這個制度是不是要取代 Steam Workshop？
不是。Steam Workshop 適合內容發布、訂閱與部分選拔流程；公司網站可作為跨平台提案、進度、商業合作與權利審查入口，GitHub 可處理程式協作，內部系統再負責保密與付款。它們是互補而非同一個平台。[E02][E18]

附錄 K．本篇術語索引

附錄 L．AI 生成內容與 Steam 發行調查的額外邊界

L.1 MOD 作者用 AI 不等於公司可省略平台內容審查

若公司最終把含 AI 輔助生成圖像、音樂、文本或其他內容的外部 MOD 併入正式發行的遊戲，便需重新確認該內容在 Steamworks Content Survey 等當時適用的申報與審查要求。Steamworks 官方文件區分遊戲上市時玩家能接觸到的預先生成內容（Pre-Generated）與遊戲運行期間的即時生成內容（Live-Generated），並特別要求對即時生成內容描述防止違法內容的管控機制。[E16]

這不代表所有使用 AI 進行內部開發的工具都必然需以同一方式公開；申報範圍應依 Steam 當時有效的正式文件、實際產品功能與發布狀況判定。也不能因投稿者已在 MOD 頁面自行聲明使用 AI，就推論公司未來正式收錄時不再有任何自身審查義務。

L.2 版權聲明、品質驗證與平台申報是三件事

某張插圖即使具有可商用的授權，仍可能因內容政策或素材品質而無法進入正式版；某張插圖即使畫質極佳，也可能沒有合法商業來源；即使兩者都通過，也仍需檢查平台對正式內容的相關申報要求。公司在對外溝通時不應把其中任一個 PASS 宣稱為全數合規。

L.3 MOD 持續更新的額外檢查

若作者保有獨立更新權，未來的 MOD 更新可能加入不同來源的圖像、腳本或即時生成內容。對直接訂閱的社群 MOD，官方應清楚告知支援邊界；對已正式收錄或官方認證的 MOD，公司應決定何種變更會觸發重新審查，不能只依初次通過的權利清單永久視為有效。

參考文獻、官方資料與既有研究

A．外部學術研究、平台文件及法律來源

[E01] GitHub Docs. About forks. GitHub 官方技術文件。可用來核對無主倉庫寫入權者如何使用 fork 與 PR 提出候選修改。
https://docs.github.com/en/pull-requests/get-started/about-forks

[E02] Valve. Steam Workshop — Steamworks Documentation. 官方開發者文件；包含 Ready-to-use、Curated Workshop、經選拔作品整合、部分 DLC 與收益安排說明。
https://partner.steamgames.com/doc/features/workshop

[E03] Valve. Steam Subscriber Agreement, Section 6: User Generated Content／Content Uploaded to the Steam Workshop. 官方服務契約。引用應以實際使用當日有效條款及個別 App-Specific Terms 為準。
https://store.steampowered.com/agreement/

[E04] Benkler, Yochai. (2002). Coase's Penguin, or, Linux and The Nature of the Firm. Yale Law Journal, 112, 369–446. 同儕生產與企業／市場生產組織之研究。
https://yalelawjournal.org/article/coases-penguin-or-linux-and-the-nature-of-the-firm

[E05] 經濟部智慧財產局。《著作權法》現行法條全文。本文主要參照第 10、10-1、11、12、21、36、37 條；實際法律問題應查證最新版及個案適用性。
https://www.tipo.gov.tw/tw/copyright/693-8432.html

[E06] 法務部全國法規資料庫。《著作權法》全文。作為臺灣著作權法第 11、12 條及相關規範的官方交叉核對。
https://law.moj.gov.tw/LawClass/LawAll.aspx?PCode=J0070017

[E07] 經濟部智慧財產局。《著作權法第 37 條》條文說明頁。用於核對著作授權之地域、時間、內容、利用方法及約定不明部分的法定推定。
https://www.tipo.gov.tw/tw/copyright/694-17702.html

[E08] 勞動部。《勞動契約認定指導原則》（2019 年 11 月 19 日）及《勞動契約如何認定》。法定僱傭關係須依實際從屬性判定，非僅依契約名稱。
https://laws.mol.gov.tw/FLAW/FLAWQRY03.aspx?id=FL092317
https://www.mol.gov.tw/1607/28162/28296/28340/28342/28344/lpsimplelist

[E09] von Hippel, Eric. (2005). Democratizing Innovation. MIT Press. 使用者創新、社群分享及製造者與使用者之關係研究。
https://mitpress.mit.edu/9780262002745/democratizing-innovation/

[E10] GitHub Docs. Repository roles for an organization. GitHub 官方權限文件；區分組織儲存庫角色與外部協作管理。
https://docs.github.com/en/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/repository-roles-for-an-organization

[E11] GitHub Docs. About protected branches. 以核准審查及保護分支控制正式版本合併。
https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches

[E12] GitHub Docs. Licensing a repository. 公開程式碼不自動等同開放全部著作利用權的授權說明。
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/licensing-a-repository

[E13] GNU Project / GCC. Contributing to GCC: DCO Sign-off. 官方 DCO 來源聲明與 Signed-off-by 機制解釋。
https://gcc.gnu.org/dco.html

[E14] 經濟部智慧財產局。電子郵件 1141017b（2025 年 10 月 17 日）。詢問利用 AI 生成作品是否享有著作權的解釋資料，強調人類實際創意投入的重要性。
https://www.tipo.gov.tw/tw/copyright/692-63403.html

[E15] GitHub Docs. Securely using pull_request_target. 官方說明不可信 PR 程式與高權限 workflow、秘密及憑證的安全風險。
https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target

[E16] Valve. Steamworks Content Survey, AI Generated Content 部分。用於正式遊戲發行內容對 AI 參與生成的申報與防護機制之理解。
https://partner.steamgames.com/doc/gettingstarted/contentsurvey

[E17] GitHub Docs. Events that trigger workflows；另參 Managing GitHub Actions settings for a repository. Fork PR 的工作流程權限、預設秘密存取與必要安全邊界。
https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository

[E18] Valve. Steam Workshop Implementation Guide. 含投稿上傳、Workshop item 可見性、內容整合與基本法律協議接入流程。
https://partner.steamgames.com/doc/features/workshop/implementation

[E19] Valve. Supplemental Workshop Terms — Revenue Sharing. Steam Workshop 付費投稿的補充收益條款；具體適用與收益比例依對應 App／Publisher／有效協議判定。
https://steamcommunity.com/workshop/workshoplegalagreement/?appid=0

[E20] GitHub Docs. About code owners. CODEOWNERS 及保護分支搭配審查的官方資訊。
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners

A.1 對研究來源的使用限制

上列來源包含理論研究、工具文件、平台合約與臺灣法律。平台說明可能因版本更新改變，法律結論需核對現行法及具體事實。本文提出的 ECA、RQDG、PDP、CCC 和 OIRB 是對既有實務的研究性概念整合，不應因引用上述文獻就推定其原作者或平台已認可本文完整制度。

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] EveMissLab. 《SEDB-GAME × ModWorld：AI 原生遊戲理解與 MOD 共創 Runtime 技術白皮書》v0.1，2026-09-01，既有研究。

[I07] Neo.K. 《開源技術的商業補償方案：從道德義務到生態共榮》，2026-02，既有研究。本文沿用其中「貢獻有權利與經濟價值」的核心問題，但不沿用其中未經獨立實證核對的示例市場數值。
https://unboundedaxiom.org/p/lm-001094/

[I08] EveMissLab. 《EVEMISS 企業通訊智能核心：共用架構技術白皮書》v0.1，2026-07-30。可作為未來 AI 合作客服與權限控制接口的相關前置研究。

[I09] EveMissLab. 《供應商與平台責任：AI Coding Tool 的 Publication-Boundary Governance》APBSC-08 v0.1，2026-09-21。可作為外部投稿與 AI 發布權限隔離的前置背景。

C．研究新意與誠實聲明

本文與既有研究的接合點是：玩家投稿由需求轉成可執行成果、開發公司可以有條件地擴大外部協作、作者可選擇保持獨立或以契約參與、AI 可以降低部分溝通和候選測試成本，而正式商業使用仍受權利與品質雙閘限制。這個方向結合了早已有之的使用者創新、同儕生產、平台選拔、開源／閉源軟體協作及委託契約實務；本研究不能因重新命名就主張所有要素皆為首次發現。

截至 2026-10-16，本文完成概念模型、官方資料核對、假說設計與可實作的資料契約草案；並未在 EveMissLab 建立已付費外部開發者網絡、發布經律師確認的標準授權契約、實施本文實驗或完成 Steam 平台商業 MOD 分潤的真實集成。若未來正式部署，應以真實簽約、程式測試、版本發布及支付憑證逐項更新研究狀態，而非追認草稿描述為已發生的事實。

文件版本與驗證紀錄

• 版本： v0.1；日期：2026-10-16（Asia/Taipei）
• 性質： 公開工作論文／概念與方法論；未經同儕審查
• 主要內容： 28 個編號正文節（0–27）、12 項可反駁假說、12 項附錄（A–L）、外部官方與學術來源及 ANIE 前置研究
• 範本性質： JSON、YAML、契約議題及算例全部為研究用假設示例，非現行協議或生產系統
• 數學原始格式： 僅使用 $...$ 與 $$...$$ 作為正式 Markdown source 的 LaTeX 定界符
• 作者／研究協作： Neo.K／GPT-6；EveMissLab
• 後續研究： ANIE-07《Steam 不是唯一入口：跨平台公告、開發網站與公開資訊樞紐》