SteamVaultsSteamVaults

Steam Deck 的「可遊玩」,究竟能告訴你什麼?

理解Deck的四種相容性評等,以明確虛構的A、B範例區分操作、文字與圖形條件,再查看真實商品的詳細資料與有日期的官方案例。

文章語言

在 Steam Deck 上選遊戲時,除了綠色的 Verified,也可能看到 Playable 或 Unknown。若把標示直接當成「能啟動」或「能照自己喜歡的方式舒服地玩」,就可能忽略重要條件。繼續讀下方詳細說明,才能分辨需要自己準備的操作,和仍未得到解答的問題。

本文談的是 Valve 官方相容性資料的閱讀方式,並非在 Deck 實際執行遊戲、比較幀率或測量電池續航的評測。文件查閱日為 2026 年 10 月 19 日。遊戲與軟體都會變動,請勿把文中假想遊戲的評定當成真實商品資訊。

四種評定不是效能排行榜

將四個評定名稱安排在三行後續問題的圖表

這是閱讀標示後的提問示意圖,不代表特定遊戲目前的評定,也不是效能實測結果。

Steam Deck 官方介紹將 Verified 說明為使用預設狀態就能順利遊玩;Playable 則可能需要使用者手動調整。Unsupported 表示目前無法在 Deck 正常運作,Unknown 是還沒檢查相容性。閱讀中文意思時,也保留英文名稱,比較不同資料會更容易。若把四個名稱依效能由好到壞排列,就會讀錯 Unknown。

Unknown 並不是拿到低分。尚未完成審查而缺乏資訊,與審查後發現不能在裝置運作,不能放在同一格。規劃遊玩時,兩者都可能讓人先保留,但原因不同。把原因分開,下一步需要找的資料也會不同。

Verified 與 Playable 也不能簡化成快與慢。只看標示,無法比較「Verified 比 Playable 有更多幀數」。把不同遊戲的徽章並列,不會生出兩款遊戲的速度測量。要比效能,必須另找符合目的、時間也合適的資料。

記下何時、在哪裡讀到標示。儲存的圖片留下當時的閱讀內容,但不能證明今天仍是同樣資訊。如果搜尋結果的小徽章取自舊資料,就把其日期也保留為資料的限制。除了遊戲名稱,也確認評定針對哪個裝置。省去裝置名稱的摘要,不能證明所有使用 Steam 的掌上型電腦都適用。

完整遊戲與獨立試玩版即使共用品牌,也要對準查閱對象。假設兩個虛構商品頁中,正式版有 Verified 詳細資料,試玩版卻沒有可讀的相容資訊。不能拿正式版徽章補試玩版的空白;是否購買完整遊戲,和能否在 Deck 用獨立試玩版,本來就是不同決定。反過來,試玩版的注意事項也不能直接當成正式版評定。

這也關係到「試玩版能回答所有購前疑問」的期待。假設你在意正式版長篇說明讀起來累不累,但假想試玩版只有一小段操作內容。即使試玩版有相容說明,也沒有代替正式版長文字畫面作答。先找打算使用商品的 Deck 詳細資料,再問它是否涵蓋自己必經場景的問題。這裡不是延伸比較試玩版是否免費、內容差多少,而是弄清徽章究竟對哪件商品、哪個問題提供資訊。

虛構Playable範例也會同時包含通過項目

虛構A的五行表格,包含三項警告與兩項通過結果

依Valve文件檢查類別編寫的虛構比較,並非實際評等、商店記錄或執行測試。

虛構圖A把三行假定警告與兩行通過結果放在一起。結果是編寫的,行的分類取自文件檢查清單。應當作混合結果來讀,不是全部否定,也不是無條件推薦。

查看真實遊戲時,要回到該商品自己的目前項目。Valve官方指南說明,已審查遊戲的詳細資料可在商店與收藏庫查看。核對商品和評等裝置,再開啟可用資料,逐項閱讀通過內容與提醒。小型徽章或搜尋圖片無法補齊省略資訊。找不到可讀內容時,就保留這個限制,不猜評等、提醒、審查日期或原因。以下比較說明取得實際資訊後如何判斷。

每一行回答的範圍要分開看。一行通過不會取消別處的警告,一條警告也不會推翻全部通過項目。額外工作的頻率可能尚未寫明,不要自己補成「每回合」或「只有開頭一次」。保留有利結果與尚未釐清的負擔,再分別對應到真正需要的功能。

使用姿勢在此會產生差別。手持近距離看,和接底座後遠看另一個螢幕,閱讀條件不同。外接螢幕也不一定解決問題,因為解析度與尺寸不會單獨決定觀看距離和遊戲版面。需要的是接近自己配置的實際畫面,或這款遊戲顯示選項的說明。

操作頻率與必經流程的卡點是兩個問題。接下來換一款假想遊戲:假設開始前必須輸入一次名字,而且無法略過這個畫面。即使只有一次,若使用者做不完,仍進不了後面的場景。只因「偶爾需要鍵盤」就把負擔當得很小,會漏掉這個必要步驟。要問的不只是總次數,還包括這張畫面是否為目標流程所必需,以及有沒有完成輸入的手段。

另一款假想遊戲,每寫一筆附加備忘就會輸入文字,但不寫也能達到想要的進度。重複輸入與必要進度被擋住,在這裡不是同一回事。一定要用備忘功能的人,會把它列回必要條件;其他人則可以從計畫排除。先選需要的功能,再判斷操作能不能避開、能不能完成,比計算警告數更貼近問題。同樣的手動輸入提示,會因目標不同而有不同準備。

用虛構Verified範例理解預設設定的範圍

兩列R/S矩陣:P在設定P下確認R,Q在設定Q下確認S,交叉的兩格仍未確認

完全虛構、使用抽象要求的資料比較,不代表真實遊戲結果、官方審查分類、Steam擷取畫面或遊戲測試。

對虛構B,假定在某一種初始設定下有正面報告。這項假定不提供速度測量,也不給真實商品評定。這裡要思考的是,讀者改變計畫後,原有結論還能適用到哪裡。

文件審查針對預設條件。虛構B所假定的報告只涉及一套起始組態。個人改動會產生新問題。另一種配置未必比較差,但需要對應預定用法的依據。把別種配置的結論搬過來之前,先決定自己要用哪一套。

假設B還另外介紹VR模式。這也是虛構設定。規劃VR時,要分別查看該模式需求與支援裝備。商品功能與特定裝置審查回答不同問題。

如果打算把 VR 頭戴裝置直接接上 Deck,又該如何評估?Valve 官方 FAQ說明,技術上可以連接 PC VR 頭戴裝置,但 Deck 並未針對 PC VR 體驗最佳化。能接上,不代表插好線就具備想要的 VR 使用條件。應分開閱讀遊戲 VR 模式需求與頭戴裝置的官方支援環境,再找資料核對實際規劃的組合。

用底座或外接 GPU 補強效能的提議,也需要另外檢查。同份 FAQ 說,接底座不會增加 Deck 效能,且不支援外接 GPU。更換顯示或連接配置,不等於增加運算能力。因此不能預設底座會讓效能提高,或外接 GPU 會補足落差,就當作 VR 計畫已完成。底座的連接功能和執行遊戲的環境選擇,是兩個不同問題。

可依所需 VR 模式、頭戴裝置支援環境,以及要承擔條件的主機官方範圍依序查。遊戲資料回答模式需求,頭戴裝置資料回答連接對象與支援環境,裝置資料則回答機器能擔任的角色。先分清是用掌上螢幕與內建操作遊玩,還是要準備獨立 VR 環境,就能具體知道下一份要找什麼資料。

商品頁面的其他標示各有用途。玩家多或好評多,可以幫助你判斷是否對遊戲感興趣,但不能回答資料是否涵蓋你打算使用的設定。設定方面的正面報告也不決定你會不會喜歡遊戲類型和推進方式。把問題分開,才不會讓一方面的期待掩蓋另一方面的缺口。

實際遊玩心得若看似和詳細資料不一致,先確認是不是同一個問題。別人用另外的設定與裝置測量,毋須直接否定,讀條件即可。短短一幕不能確認預定遊玩後續部分會發生什麼。比較是為了找出直接回答自己計畫的部分,不是無條件相信其中一方。想比平均幀率,就找有實際測量條件的資料,而非只看相容項目。

兩段正面資訊不一定支持一個完整計畫。用完全虛構、只有抽象要求R與S的比較來看。讀者需要在同一套不變的組態中同時滿足兩者。報告P只確認組態P下的R,沒有回答那裡的S。報告Q只確認另一套組態Q下的S,沒有回答R。把兩句正面結論合起來,還沒確認任何一個完整可用的計畫。P下的S、Q下的R仍未知;空白本身也不是失敗結果。

這和挑哪份報告比較可信不同。兩者都可能正確,卻仍未回答需要的組合。在摘要裡把P寫成Q,會遮住兩次觀察之間的條件變更。報告更長,也不會自動填滿缺項。增加說明P下R的頁數,只會補充R的細節,不會產生S的證據。下一份有用資料,是同一個預定組態下缺少的結果,不是已確認條件的另一段正面評語。

若讀者真的能在P與Q之間選一個,不必維持同一組態,待判斷的計畫就改變了。彈性帶來兩個待查方案,不會自動確認其中任何一個。若計畫也包含來回切換組態,能否完成切換並滿足兩項要求,也需要自己的依據。合併資料前先講清楚正在判斷哪個計畫。誠實留下空白,才能縮小後續問題;把不同條件的正面片段合併,會對一個沒有任何來源描述過的計畫給出確定答案。

現在不改變讀者的要求,只改變虛構資料。假定報告M確認R,報告N確認S,而且兩者都明確指向同一個未改變的設定P。每份文件單獨都不能回答全部問題,但相關陳述合起來,可以支持P下的R與S。前一例的問題,不是少了一份包含所有答案的文件,而是沒有同一設定下的必要組合獲得支持。堅持全部答案必須寫在一個檔案裡,會以錯誤理由排除這個已涵蓋所需要求的不同案例。

把不相容的兩段話放進同一份摘要,不能修補它們的差異。反過來,相容的陳述分散在兩份文件,也不會只因檔案分開就產生缺口。有用的合併筆記會保留:哪條陳述回答R,哪條回答S,以及為何兩者都適用於P。結論不能超過這個組合;它既不確認另一項要求T,也不把結果轉移給Q。

相同設定是第二個案例明確給定的前提,不是重複字母P就能證明的事實。如果文件只是名稱相似,彼此關係尚未確認,共同涵蓋仍無法確定。這時缺少的是兩條陳述是否描述同一個計畫的資訊。再加一篇只詳細說明R的資料,也不能解決這個同一性問題。把缺少結果與資料之間的連結尚未證明分開,才找得到真正能完成判斷的證據。

幀率與字體大小,還要加上自己的期待

區分文件預設效能標準與個人對幀率、可讀性、電池續航期待的表格

官方標準與個人期待的解說表,沒有測量幀率、電池時間或文字尺寸。

查閱時的 Steamworks 文件將 Deck 預設組態效能標準定為 800p 下可遊玩的 30fps。不要把這句變成目前所有 Verified 遊戲、每個場景都固定幀率的實測結論。文件的審查標準和個別遊戲今天的運作,是兩種資料。

如果你要更高幀率,就另外寫下這個期待。例如把「我需要在想玩的模式達到更高幀率」和 Verified 的定義分開。這並非建議每個人都用同一數字。遊戲類型和偏好會改變所需資訊。看了徽章就認定所有額外期待都已滿足,會忽略繼續找具體資料的理由。

你的視力、坐姿與偏好字級,仍是個人判斷的重要部分。若在意小字,可再查官方是否說明文字大小或版面調整。其他語言畫面的可讀性資料,不宜直接當成自己語言的實際結果。

假設讀者 E 想在短程移動時手持遊玩,F 想在家長時間閱讀小字。相同徽章下,E 也許想知道進入遊戲快不快,F 更在意文字調整。兩人都沒有讀錯,只是把自己的條件加到共通資訊上。

四種分類不會直接提供續航時數。遊戲是 Verified,不足以承諾能玩多久。需要同時說明裝置設定與遊戲情境的另外資料。熱與噪音是否舒服,也難由徽章判斷。重要就加入待查問題;沒有資料時,這一項仍可以保留未知。

Cyberpunk 2077 的儲存媒體要求不等於徽章

分開Cyberpunk 2077在2023年的Verified公告及之後2.0的SSD條件的文件時間表

2026 年 10 月閱讀兩份 2023 年官方公告的歷史案例,不是目前徽章查證或儲存媒體效能實測。

CD PROJEKT RED 在 2023 年 2 月 28 日宣布 Cyberpunk 2077 取得 Deck Verified。之後的 2023 年 9 月 21 日 Update 2.0 說明要求從 SSD 執行,並不建議 HDD 與 Deck 的 SD 卡,因為頻寬限制可能影響新內容正確載入。較早的正面相容公告,能與後來明列的安裝條件並存。

需要問的比「有沒有 Deck」多一步:遊戲裝在哪種媒體。即使同一台機器,換個安裝位置,也可能改變是否符合文件條件的答案。型號或收藏庫持有標示,不會告訴你檔案現在在哪。先看打算使用版本的官方安裝要求。

尤其要把可用容量和媒體種類分開。一位假想玩家的 SD 卡很空,另一位的 SSD 空間不足。前者的空間不能代替文件指定的媒體,後者用對媒體也不會多出安裝空間。一項是可放多少資料,另一項是官方要求的媒體。知道哪個條件還不符,下一步才會分成清出空間或確認目前安裝位置。

啟動成功的經驗也不會取消支援條件。2.0 公告解釋,舊需求不一定表示絕對無法啟動,但沒有在那些條件測試或積極支援,因此無法保證運作。有人用舊組態看到起始畫面的紀錄,與發行商後來更改條件,可以同時為真。不必否認那次啟動,只要限制在當時的組態。一次起始畫面不能證實後續場景都載入正常。

不買擴充內容,也不能自動避開變動。同份公告說 2.0 是套用於本體的免費更新,並與 Phantom Liberty 的新增內容區分。沒買擴充,不代表仍停留在舊本體條件。持有哪些商品,和已安裝遊戲是哪一版,並非同一資訊。這裡也不推出加買內容能解決儲存條件,或必須取消購買。

參考舊設定教學時,版本同樣重要。2.0 公告提到 Deck 圖形設定檔更新,所以不能直接搬用舊畫面數字,稱為「Verified 建議值」。官方相容標示和發行商的遊戲內設定檔,是不同資料。更新設定檔,也沒有提供每個場景固定幀率的測量。查目前選項,應讀該版本文件。

把這例子說成所有 Deck 遊戲都禁用 SD 卡,也是不對的。條件出自特定遊戲、特定更新。別的遊戲需要自己的依據;「大部分沒問題」的印象同樣不能抹掉這一條。由共通徽章追到遊戲個別安裝條件,是為了不讓容量充足與滿足官方執行環境互相替代。

LCD、OLED 與其他 SteamOS 裝置要分開

包含LCD、OLED、其他裝置組別與Deck螢幕行的表格

文件中的裝置分組,不是機型效能測試,也不評估未來裝置。

這張圖沒有提供某款遊戲多幾幀、增加幾小時續航的結果。記錄要保留正確型號,避免往後比較時,不知不覺換了正在討論的機器。

文件同時談多台機器時,摘要需要主詞,也需要結論。否則針對某一行的說法,容易看成整組裝置的結果。與其他文件一起使用前,先挑出自己打算用的硬體所屬那一行。術語相近,並不足以確認測試條件相同。

網路上的「支援 SteamOS」不代表資料已檢查 Deck 的掌上螢幕和操作條件。作業系統名稱與硬體審查對象是兩種資訊。共用軟體家族,不會消除畫面、輸入與組態差異。若資料說的是別台裝置,保留其名稱,不要改當 Deck 評定的直接證據。

加底座或外接螢幕也改變自己的使用條件。看見 Deck 徽章,不表示底座、線材、顯示器與某控制器的整套搭配都測過。若連接方式很重要,另外確認組合的官方功能與現行資料。單一遊戲標示不應像是所有周邊的認證。

保存評定時,連同日期與遊戲版本

下方有分支註記的四行事件表

依文件整理的事件圖,不是特定遊戲的真實時間線。

保存評定時附上閱讀的來源與日期。截圖留下那次查閱,不代替往後所有版本。若看不到確切審查時間,就保留未確認,不拿更新日補上。保留各筆紀錄實際證明的範圍,別人才看得懂兩份日期不同的紀錄為何有差別。

遊戲更新與相容審查是不同事件。更新不表示立刻完成新審查,評定相同也不證明完全沒變。能確認兩個日期就分開記,只有一個就別拿來補另一個。文件描述持續作業,不是本文保證所有畫面即時更新。

反作弊處理也是同樣區分。Valve 的開發者說明提到,先前因反作弊受限的遊戲完成支援工作後,可以申請後續審查。能提出申請,和完成新評定,是不同階段。發行商回應公告無法代替今天的 Deck 標示。

假想遊戲 H 在上個月圖片為 Playable,如今商店為 Verified。把來源與日期分開,就不用硬把看似相反的資訊壓成一個結果。現在的標示可能更切合今天的計畫,但不清楚原因就說不清楚。猜是幀率改善或某功能修復,會添加文件沒說的因果。

Valve 的 Verified 宣傳頁文件說,獨立宣傳頁需要 Verified 及已公開的全年齡預告片。找不到宣傳頁不能證明 Unknown,因為另有宣傳素材條件。回到實際商品的相容詳細資料,而非猜 URL 格式查詢,才能避免把未搜尋到的連結當成尚未審查。

發行商的變動公告不是現在的評定

把Warframe 38.6輸入變更及後續預定恢復註記與目前評定分開的關係圖

這是 2026 年 10 月讀到的 2025 年更新文件,沒有直接查證現在評定、輸入設定或恢復完成。

Warframe 38.6 官方更新說明描述 2025 年 5 月 22 日 PC Steam、Deck 的輸入組態改動。同頁後來加註預定恢復 Steam Action Sets。目前恢復是否完成、Deck 評定如何,並未確認。閱讀初始說明與追加註記,能區別過去改動和後續計畫。

這份更新文件回答的是發行商的輸入設定變更。光憑它不能解釋後續相容性結果的原因。舊手動程序留在文件裡,也不表示今天仍要操作。你問的是評定原因,還是過去的使用者設定是否保留,會決定需要哪些資料。

後續的預定措辭,不是已完成狀態。需要完成版本的人,得再找後續官方說明。這裡不是叫你照舊方法操作,而是看每句話屬於哪時候、哪種條件。過往變動與現在徽章的關係不明,就各自保留;說不同時間,本身不代表文件矛盾。

比較實玩心得和官方標示,也要對齊裝置、遊戲版本與設定。把觀察結果限定在實際說明的條件內。先定是否只用內建操作、哪些功能不可少,才能挑直接回答的資料。必要功能缺乏依據可成為暫緩原因,手動工作清楚則可預先估入負擔。

區分相容性審查與線上使用條件

虛構線上使用條件與Apex的2024年歷史公告

遊戲X是假設,Apex公告是歷史資料,不是目前連線測試。

Valve的Proton文件說明,即使是受支援的反作弊中介軟體,也可能需要開發者為各遊戲手動啟用或設定。這不確認使用同一中介軟體的所有遊戲都允許透過Proton線上參與。現在假設虛構遊戲X的公告只允許在環境A使用某線上模式。這不是真實遊戲的許可、不相容或封鎖政策,而是區分裝置名稱、到達初始畫面與滿足所需線上功能條件的例子。

有了資料,Unsupported 不必被看作自己得修好的分數。與其持續嘗試不許可的路徑,可以比對所需環境和官方支援。擁有遊戲檔案,不等於獲准使用服務。收藏庫可見、開始安裝,都不能直接跳成可以連線。徽章之外明列的限制,只要涉及必要功能,就直接關係到計畫。

另一例是 Apex Legends 在 2024 年 10 月 31 日的官方 Steam 公告。當時宣布阻擋 Linux 和使用 Linux 的 Deck 存取,並區分 Windows 的 Steam。它只作為過去政策變更的例子,不能證實 2026 年徽章或現行反作弊產品。帶日期的變動,能解釋為何「以前玩過」還不足以回答今天。

假設一人只有舊 Deck 啟動影片,另一人有後來官方存取公告。當初真的啟動、之後真的改變,可以同時成立,不必選一個當作假消息。兩份資料描述不同時間。現在的判斷還要確認最新官方條件,也要分清影片只是短暫起始畫面,還是有用到線上功能。舊紀錄不能延伸成現在帳號安全的保證。

不要把一款遊戲的限制原樣套到其他遊戲。實際決策時,讓每份文件對應它所討論的確切商品和功能。關於存取的結論與關於另一項要求的結論,不應默默替彼此填補空白。

暫緩的理由也因此具體。因官方條件不合而考慮其他環境,與已有條件說明、卻缺現在 Deck 審查而等待,不是同一情況。等待時也能決定,什麼新資訊會改變計畫:新的許可公告、後續相容審查,還是必要功能的官方支援說明。目的不是尋找繞過方式,而是釐清現有依據尚未回答的問題。