Valve 收緊 Steam 發布規則，遊戲審批積壓
隨著開發者面對最長達 12 個工作天的版本審核，Valve 已收緊 Steam 的發布規則，令原定推出計劃承受壓力。新措施要求提交前進行更多檢查，包括實際透過 Steam 執行遊戲。措施出台之際，外界正關注 AI 生成遊戲，但 Valve 尚未量化 AI 對積壓的影響。
眼前的衝突圍繞共用審核隊列的使用權。開發者可以仔細準備自己的提交內容，卻仍要排在需要反覆檢查的遊戲之後等候。Valve 的回應是要求創作者在審核人員發現問題前，承擔更多責任找出基本錯誤。
與 itch.io 的比較有助說明事態的重要性。兩個商店平台同樣面對如何管理生成內容的問題，但測試要求與限制大量上傳，針對的是不同問題。Valve 最新措施聚焦於發布準備程度。其成效取決於這個做法能否改善審批時間，同時不為已在等候的開發者帶來更多不確定性。
Valve 更改了哪些 Steam 發布規則
Valve 要求開發者在提交遊戲供審核前，證明已具備基本發布準備。
其 11 月 3 日的發布前審核更新新增多項檢查，旨在減少重複審核。開發者必須透過 Steam 執行遊戲至少五分鐘。Valve 亦要求檢查必要軟件元件、成就、雲端存檔及螢幕截圖分類。
公司表示，其一般版本審核目標為三至五天，而目前等候時間最長達 12 個工作天。Valve 將大部分延誤歸因於問題浮現後需再次審核提交內容。這些屬於開發審批，與玩家購買遊戲後留下的用戶評價不同。
版本是提交作測試或發行的遊戲封裝版本。在開發者電腦上直接啟動該封裝，無法重現客戶會經歷的每一個步驟。當 Steam 發送遊戲時，安裝、啟動設定及配套軟件的表現可能不同。
這項差異說明了遊玩時間要求為何比其看似不長的時限更重要。這項檢查會詢問開發者是否實際走過真正的發行途徑。它建立了對已交付產品的最低接觸要求，而不是把可正常運作的本機可執行檔視為足夠證據。
常見可轉散發套件是遊戲運行所需的共用軟件元件，例如 DirectX 或 Visual C++ 函式庫。確認這些元件有助處理基本的部署問題：開發者的電腦可能擁有另一部電腦欠缺的相依項目。因此，本機測試成功仍留下重要問題未解。
Steam Cloud 是同步支援遊戲存檔的服務，也帶來另一個設定相當重要的環節。成就及螢幕截圖分類同樣把提交的產品與其宣傳功能連結起來。這些檢查合起來關乎遊戲的封裝及呈現方式，是否與玩家實際收到的內容一致。
現有審核流程已要求遊戲的商店頁面與其版本均獲批准。流程亦指出，宣傳的功能必須存在於提交的版本中。Valve 的新清單則在這道既定關卡上，加入明確的準備要求。
政策的意義在於 Valve 把工作放在哪一方。開發者必須在進入公司承認已出現延誤的隊列前，處理更多日常問題。這種做法把可避免的重新提交視為 Valve 可處理的問題，而毋須改變創作者使用哪些開發工具。
這也為公司對延誤的解釋提供清晰的檢驗。如果基本提交失誤佔去大量審核工作，及早發現應有助改善情況。若其他限制才是主因，更詳細的清單將令核心瓶頸大致維持不變。
獨立開發者承擔不確定隊列的成本
即使遊戲本身已準備好推出，延遲審批仍可擾亂發布安排。
發布日期協調的不只是一項上傳工作。它可以配合公告、創作者報道、社群期望，以及合作夥伴的可用時間。更改日期意味著要重新處理開發者未必能完全掌控的承諾，尤其是他們無法有把握地公布替代日期時。
Cubic Earth 說明了這種壓力。開發者 structmira 向 PC Gamer 表示，該遊戲已累積超過 6,000 個願望清單加入數，預告片在 YouTube 的觀看次數超過 60,000 次。根據對版本審核積壓的報道，該開發者形容，在審批仍未有結果時，玩家投訴持續增加。
這些數字反映受眾興趣，而非保證購買量。然而，它們說明了為何等候可帶來實質影響。團隊已要求人們留意，而尚未解決的平台決定中斷了原本應將這份注意力轉化為遊玩機會的時刻。
Wheel Make It 提供了另一個報道案例。其發行商 2 Left Thumbs 把推出受阻歸咎於審批延誤。根據對其延遲推出遊戲的報道，開發者更新亦提到一次未通過的審核，涉及控制器存取解像度設定的問題。
這種組合令「開發者只是在等 Valve」的簡單說法變得複雜。一項提交內容可以存在合理問題，但解決其狀態所需的時間仍可構成嚴重困難。發現缺陷與傳達可靠的審核時間表，是不同責任。
壓力尤其落在幾乎沒有空間重新安排工作的團隊身上。推出延誤可能延長社群管理工作，同時推遲正式發布。開發者於是花時間解釋一項他們無法作出的決定，而不是討論他們製作的遊戲。
不利的答覆與未知的答覆之間亦有分別。明確拒絕會讓團隊掌握具體可處理的事項。未有結果的提交則留下不確定性，包括原因、所需回應，以及再次作出公開承諾是否可信。
因此，Steam 審核積壓的協調成本不只存在於審核人員的工作桌上。開發者可能在公告中預留更大緩衝、延後宣傳承諾，或避免承諾精確的可用日期。這些反應可以理解，但它們把不確定性轉移至其餘的製作時間表。
準備工作仍有用，但不能保證免受影響。經充分測試的提交應可減少可避免的問題，但仍取決於共享的平台容量。Valve 的清單讓開發者對提交品質有更多掌控，卻無法控制何時有人完成檢查。
在公平評價此更新時，這項區別相當重要。開發者應為提交前可發現的缺陷負責。Valve 仍應為其審批流程的清晰度及運作負責。改善前者，不會自動消除對後者的憂慮。
更快的遊戲創作面對共享審批關卡
減少創作遊戲所需的努力，並不會免除負責任發行所需的工作。
這正是 Steam 發布規則更新背後的核心張力。生成式 AI，即能根據提示或其他輸入產生新內容的軟件，可以協助部分開發工作。但提交的成果仍須具備可運作的安裝流程、準確的呈現方式，以及有人為兩者的檢查負責。
這造成了產出素材與驗證成品之間的不匹配。生成圖像或草擬程式碼，是個別任務；發行遊戲則關乎另一個人安裝及遊玩時，多個部分如何共同運作。
以一款在創作者開發資料夾中啟動正常的假設遊戲為例。這並不能證明發行封裝包含了運作所需的一切。無論相關程式碼由人還是 AI 助手編寫，問題都屬於交付環節。
Valve 的最低遊玩要求正面處理這個缺口。它要求創作者從製作可運行的內容，跨越至測試可發行的內容。這項區別聽來基本，因為它確實基本；但共享的審批系統不能假定每項提交都已跨過這一步。
其中的經濟張力很直接。跳過準備工作的開發者可在本地節省努力，卻讓另一方發現遺漏。若發現問題後觸發重新提交，同一產品在抵達玩家手中前便會消耗額外注意力。
謹慎的開發者便要共同承受草率準備的後果。他們自己的版本可能只需少量修正，但仍依賴同一審批系統。這就是為何爭議不止於某一款 AI 輔助遊戲是否應受批評。
以結果為本的清單在這方面有可辯護的優點。它可對不同開發方法採用同一套準備標準。以 AI 輔助製作的遊戲仍應正確啟動，而手動製作的遊戲亦不應獲豁免於同一要求。
另一種做法可見於 itch.io 的內容品質指引。該指引明確處理過量的自動生成內容及大量生產的產品頁面。它容許有用的生成素材，同時警告不要利用自動化淹沒探索系統。
兩種做法針對問題的不同階段。提交檢查會詢問個別產品是否已準備好接受審查。限制大量生產則詢問上傳行為是否正淹沒市場平台。商店平台可能同時需要兩者，卻不必把每位 AI 輔助創作者都視為濫發者。
對讀者而言，有用的比較在於各平台把阻力放在哪裏。較早的檢查可防止明顯失敗項目進入隊列；重複上傳的限制則可約束數量。任何一種做法本身都不能判定遊戲是否原創、有趣，或獲得誠實宣傳。
Valve 對眼前的審批問題選擇了狹窄的介入措施。這為開發者提供具體標準，但也限制了更新可達成的效果。功能準備固然是發布的必要條件，卻只涵蓋圍繞 AI 生成遊戲爭議的一部分。
AI 披露並不能確定延誤成因
證據支持審核流程出現延誤，但 AI 生成遊戲的確切影響仍未有公開量度。
Valve 的解釋指出，重複審核是延誤的重要來源。這讓讀者了解流程內部累積的工作。然而，它沒有揭示未通過提交背後採用的開發方法，也未能確立哪些類型的遊戲耗用最多審核時間。
AI 披露回應的是另一個問題：它告訴玩家，開發者在披露政策涵蓋的範圍內聲明使用了生成內容。它並不能全面反映測試質素、原創性或遊戲投入的開發心力。
Valve 的內容問卷提供了相關政策框架。閱讀這類披露時，必須留意其涵蓋範圍。關於生成素材的標籤，不應被延伸為整款遊戲均由自動化方式製作的無根據說法。
同樣的審慎原則亦適用於沒有披露的遊戲。沒有標籤本身，並不能證明產品曾經過仔細測試。評估送審質素需要根據已提交的產品證據，而非假設開發者偏好使用甚麼工具。
目前爭論背後其實涉及幾種不同的衡量方式。已發行遊戲反映的是成功登上商店的產品；送審遊戲反映的是湧入的審核需求；重複檢查則反映該需求中需要額外處理的工作。把這些類別視為可互換，會令因果論斷比證據所能支持的更強。
即使 AI 披露確實可靠地上升，仍有重要問題未獲解答。這不能顯示這些遊戲有多常未能通過檢查、審核人員花了多少時間處理，或其失敗情況是否與其他送審作品不同。要解釋積壓工作的構成，正需要這些衡量數據。
這並不代表開發者的憂慮不合理。他們的投訴反映了面對不確定審批結果的真實風險，而快速生成內容亦是額外需求的一個合理可能來源。不過，合理性應引導調查，而非取代 Valve 尚未公布的細項分析。
「AI slop」一詞亦有相關問題，這是指低質素生成素材的簡稱。它有效傳達不滿，卻把不同的投訴混為一談。安裝失敗、重複設計、誤導性展示，以及不受歡迎的生成藝術，均需要不同證據，亦可能需要不同回應。
可正常啟動的檢查直接處理第一項投訴，但對一款遊戲是否抄襲其他創作者的構思，或能否提供有價值的遊玩體驗，則幾乎沒有說明。把這份清單稱為所有 AI 憂慮的答案，會誇大其適用範圍。
因此，最有力的分析會把各項主張分開。Valve 已承認出現延誤，並指出重複審核是原因之一。開發者及記者把這些困難與更廣泛湧入的 AI 輔助內容聯繫起來。公開紀錄目前仍未量化該湧入在多大程度上造成問題。
隨着政策發展，這個驗證缺口應保持清晰可見。讀者可以認真看待營運問題，而不把每次失敗都歸咎於 AI。開發者亦可以要求更好的服務，而毋須證明所有拖慢隊列的因素都源於單一解釋。
更完善的檢查有幫助，但 Valve 仍有工作要做
檢查清單可以減少可避免的失敗；但無法證明審批系統具備足夠容量。
Valve 的做法有明顯的營運邏輯。在送審前發現缺少依賴項目，總比在審核期間才發現更好。確認已宣傳的功能，亦能讓審核人員評估較完整的產品，並減少對應具備哪些內容產生分歧的機會。
支持這項做法的理據在於預防。如果創作者可以在本地發現基本問題，讓平台日後才發現並無多大價值。清晰要求亦可協助缺乏經驗的開發者明白，完成遊戲與準備發行是兩項不同工作。
不過，懷疑論點同樣值得重視。送審作品即使符合可見的清單項目，仍可能存在需要檢查的問題。最低遊玩時間無法涵蓋所有運作情況，而確認欄位亦不能證明創作者理解自己所確認的功能。
政策是否有效，取決於其檢查項目是否對應常見且可預防的審核失敗。如確實對應，額外工作應帶來有用回報。如開發者只是填寫欄位而沒有改善準備工作，流程便只會增加形式要求，缺陷仍然存在。
這亦涉及溝通挑戰。開發者需要分辨一般目標與目前的實際營運情況。當已承認的延誤令熟悉的預估時間不再可靠時，該預估對安排發行幾乎沒有價值。
Valve 無須保證審批日期，也可以改善這個情況。清晰的狀態資訊及當前預期，有助團隊決定可以負責任地作出哪些承諾。說明審核人員所需資料，同樣能減少送審需要修改時的不確定性。
對開發團隊而言，一致的文件記錄已成為發行準備的一部分。測試筆記、設定決策及早前回饋，可協助協作者了解哪些項目已經檢查。可搜尋的工程知識庫可支援這類紀錄，但不能取代親身測試。
更廣泛的問題關乎共享系統中的責任分工。創作者負責準備工作及其聲明的準確性。Valve 負責審核運作、要求的清晰程度，以及開發者等候期間收到的資訊。雙方各有對方無法代勞的工作。
玩家亦有保留有意義檢查機制的利益。若明顯的安裝問題仍能通過審批，更快的審批流程只會帶來有限好處。相反，若審核時機令開發者無法規劃可信的發行安排，再有效的檢查亦會失去價值。
因此，速度與可靠性是共同目標。Valve 需要可減少避免性修正的送審作品，而開發者需要一套其運作方式可被理解的流程。新要求處理了這種交換關係的一部分，但其存在本身並不能證明情況已有改善。
公平的標準是實施後可觀察的表現。更詳細的表格是一項介入措施；較少可預防的失敗及更可靠的審批才是結果。在這些結果出現前，這次更新仍是一項合理建議，其實際效果尚未明朗。
Steam 發行規則更新後值得留意甚麼
下一項考驗，是開發者是否遇到較少重複審核，以及更可預測的發行決定。
第一個訊號是審核時間表本身。在未來數月，留意 Valve 目前的預期是否回復至一般目標。開發者帳戶可提供更多背景，尤其是清楚區分首次送審、被要求修改及最終獲批的情況時。
較短的等候時間會支持「可預防的重複審核是可處理瓶頸」的說法。持續延誤則會削弱任何認為清單已經足夠的主張。不過，兩種結果本身都不能證明 AI 生成內容在原有問題中佔了多大比重。
第二個訊號是回饋循環的質素。留意是否出現更具體的文件、更清晰的狀態訊息，以及讓開發者可一併處理相關問題的說明。這些改變將顯示平台正關注送審質素與審核效率之間的互動。
若持續出現審核期間才發現新的基本要求的報告，便反映相反情況。若開發者在送審前無法判斷何謂準備就緒，責任仍難以界定。當創作者可在審核人員指出遺漏前自行套用標準，該標準才能發揮最佳效果。
第三個訊號是商店平台會否公布將內容量與營運結果連結起來的證據。更有用的報告會區分送審作品與已發行遊戲，並指出哪些失敗類型推動重複工作。這將直接強化或挑戰 AI 解釋。
競爭對手的行動亦值得在這個衡量問題中留意。限制重複上傳及改善內容探索，處理的是 Steam 審批關卡以外的壓力。其價值應按實際改善之處判斷，而非按平台對不受歡迎內容的措辭有多強烈。
對 AI 產品開發者而言，這亦提醒大家何謂已完成的工作。一個能在單一環境運行的生成專案，只完成了部分路程。即使創作變得更容易，發行、整合及驗證仍然是產品責任。
對玩家而言，實際問題是商店平台能否在處理更多送審作品時維持信任。準確展示及可正常運作的安裝程序仍是合理期望。這些期望不能解決所有關於 AI 的爭論，卻為評估平台政策提供具體基準。
對準備發行的工作室而言，應遵守現行要求，並讓承諾建基於已確認的里程碑。記錄已測試內容、收到回饋的版本，以及仍未解決的事項。把審批時間視為需要主動關注的依賴因素，尤其是在協調外部報道或社群活動時。
其後，應根據實際結果而非單憑公告重新檢視 Steam 發行規則。完整的送審作品是否更可預測地推進？審核人員是否發現較少可避免的問題？Valve 是否提供足夠資訊，讓開發者能如實解釋延誤？在判斷新檢查是否確實改善了遊戲從完成到可供遊玩的發行流程前，應持續追蹤這些答案。
