Perplexity Roadster 遊戲亮相：Computer 做出的 AI 原型，離正式作品還差什麼？

Perplexity Roadster 遊戲把 AI 寫程式的結果，變成讀者可以直接打開的瀏覽器作品。比起只看生成的程式碼，它讓人更容易討論一個想法究竟長什麼樣子。

執行長 Aravind Srinivas 在 台灣時間 2026 年 10 月 19 日分享連結，稱它是由 Perplexity Computer 製作、帶有賽博龐克風格的自由駕駛遊戲。到 10 月 19 日查詢時，貼文約有 3 萬次瀏覽。

但能在一段影片裡開車，與完成一款長期營運的遊戲，中間還隔著操作、效能與維護。因為畫面呈現只是作品的一部分，玩家也在意按鍵是否可靠、目標是否清楚。

這次示範有用的地方，是讓創作者用可玩的原型討論構想，減少只靠文字溝通的落差。原型是先做出用來驗證想法的版本，功能可以少，但要能回答一個具體問題。

如果正在準備遊戲提案，我會先用這類工具驗證玩法與視覺方向，再決定是否投入完整開發。不會從單一展示推論它能自動完成所有正式製作。

因此看這則消息時，最值得問的是作品展示了什麼、哪些資料沒有公開，以及自己的專案要如何設計可檢查的交付標準。

Perplexity Roadster 遊戲展示了什麼？

官方分享的是一個可開啟的作品與示範影片，沒有完整開發紀錄。因此讀者可以評估展示方向，卻無法據此計算一般人的製作時間或成功率。

Aravind Srinivas 的原始貼文把作品描述為 Computer 製作的自由駕駛瀏覽器遊戲。這是作者對製作來源的說明，但沒有一併揭露完整提示詞與人工修改比例。

公開作品頁的名稱是「San Francisco · Drive and Fly」，頁面也包含 Roadster Demo 字樣。它把城市、駕駛和飛行的視覺主題放在同一個作品裡。

從頁面公開的操作說明，可以看到前進、煞車、轉向、加速、起飛與視角切換等按鍵安排。這表示設計者不只展示車輛模型，也提供了操控方向，但說明存在仍不等於所有裝置都能順暢運行。

本文核對了公開頁面與官方貼文，沒有量測實際遊玩效能，也沒有測試全部按鍵。因此這裡將作品當成案例，操作品質仍應由讀者在自己的裝置上確認。

飛行也是作品的玩法設定，不是實車功能驗證。因為遊戲可以設定任何移動規則，所以畫面裡能做的動作，不能直接拿來說明現實車款的能力。

以下把本次可確認與無法直接推定的內容分開。

表格中的差異，會影響創作者如何預期自己的結果。能看到一個完成示範很有幫助，但真正估計專案時，仍得從需求與測試範圍開始。

怎麼把遊戲想法交給 Computer？

先定義最小可玩迴圈，再描述畫面與操作。最小可玩迴圈就是玩家反覆做什麼、得到什麼回饋，以及為什麼想再做一次。

以駕駛原型為例，可以先選「加速、轉彎、回到起點」這個小迴圈。因為範圍有限，製作結果比較容易被檢查，也比較容易知道問題出在控制還是場景。

如果一開始就要求完整開放世界、任務系統與大量車輛，許多工作會同時展開。畫面可能很快變豐富，但開發者反而難以判斷哪一部分已經可靠。

因此需求最好寫出可觀察的結果。例如「按住方向鍵時車輛持續轉向，放開後停止增加轉向」，比「做出很真實的操控感」更能讓雙方對焦。

視覺也應有優先順序。如果目的只是確認路線和速度感，就可以先用簡單場景；若提案重點是城市氛圍，則應先保留光線、色彩與鏡頭表現。

這些是本文提出的規劃建議，並非本次 Roadster 作品實際採用的提示詞。官方沒有公開的方法，不應為了讓教學看起來完整，就寫成已知製作流程。

Perplexity 在官方 Computer 工作坊把服務描述為能規劃、執行多步驟工作並交付結果的工具。對創作者而言，這種定位適合把任務拆成可逐步檢查的階段。

例如先確認畫面能載入，再確認控制，最後加入音效與更多內容。因為每一階段都有清楚成果，發現錯誤時也能較快回到需要修改的部分。

延伸閱讀：Perplexity Computer 是什麼？一次搞懂 AI 數位員工的終極使用教學

可玩原型應該驗收哪些內容？

操作回饋與重新開始，會直接決定玩家能否順利體驗。因此驗收不應只看一段成功的遊玩影片，而要讓第一次接觸的人自己走一遍。

先看入口是否清楚。玩家應知道何時開始、目前是否載入完成，以及需要使用鍵盤還是其他裝置，否則很可能把等待或不支援誤以為遊戲壞掉。

接著看按鍵與畫面的對應。若按下加速後車輛沒有明顯變化，使用者便不知道指令有沒有生效，所以狀態顯示、動作與聲音都需要配合。

視角也會影響控制。車頭方向與鏡頭方向若不容易判斷，玩家可能以為轉向顛倒，因此測試時應觀察他在哪個角度開始失去方向感。

然後刻意走錯路。原型不必處理所有罕見狀況，但玩家離開道路、卡住或翻轉時，至少應有返回的方法，才能繼續討論核心玩法。

重新開始也需要明確定義。只是把車輛放回起點，與把速度、分數及場景狀態一起重設，可能產生不同結果，因此交付規格應寫出需要恢復哪些內容。

若作品包含飛行，就再看地面與空中的控制如何切換。因為同一按鍵可能在不同狀態有不同用途，提示需要讓玩家理解轉換，而不是靠反覆猜測。

測試紀錄應描述操作與結果。例如「降落後仍無法轉向」就比「手感怪怪的」容易修正，因為後者沒有指出錯誤發生在哪個狀態。

也可以把問題分成阻擋遊玩與影響美感兩類。先讓玩家走完最小迴圈，再處理不影響操作的細節，製作進度比較能對應原型的目的。

瀏覽器遊戲的效能與相容性怎麼看？

必須在目標裝置上量測，而不能用宣傳影片代替。因為影片是在特定條件下錄製，觀眾打開作品時卻可能使用不同電腦、瀏覽器與網路。

首先要決定作品給誰玩。如果目標讀者主要使用手機，就不能只完成鍵盤操作；若只打算在展場電腦展示，測試範圍則可以先以指定設備為主。

載入時間也會改變體驗。漂亮的場景可能需要更多素材，但玩家不知道要等多久時，就可能在看見遊戲前關掉頁面，因此載入狀態需要讓人理解。

這次公開作品頁設有載入進度與操作提示，顯示作者有把進入作品的過程納入設計。不過是否足以應付各種設備，仍要靠實際測量。

畫面流暢度則應看持續遊玩的表現。若一開始正常，切換視角或進入複雜場景後才變慢，只錄起始片段就看不出問題，因此測試應包含不同路線與狀態。

對提案原型而言，通常可以先降低不必要的視覺負擔。因為目的在驗證玩法，先保留可辨識的空間與控制，比一次堆滿細節更容易找到瓶頸。

還要檢查錯誤時能否理解原因。如果頁面無法使用某項圖形功能，能清楚告知需求，會比一直停在載入畫面更容易讓使用者知道下一步。

本文沒有提供每秒畫面數或載入秒數，因為沒有做對應量測。讀者若要以這個案例估計自己的作品，應把目標設備與驗收條件交給製作工具，再留下實際測試結果。

這類 AI 原型適合誰？

想快速討論玩法、製作視覺提案的創作者，可以先用小範圍作品試驗。若需要持續更新、多人連線或正式收費，則應把原型後面的工程工作一起納入。

對課程設計者而言，可玩作品也能幫助學生理解指令與回饋。學生不必只交一段程式，而可以讓別人操作，再根據觀察修正需求描述。

對產品團隊而言，原型能讓討論更具體。例如團隊原本爭論畫面要多大，實際操作後可能發現主要問題是按鈕位置，因此可用的作品能改變決策順序。

但原型仍需要有人理解並維護。若只有一個可開啟的連結，卻沒有可修改的專案、素材清單與部署說明，之後改一個小功能也可能重新開始。

素材權限也應在公開前確認。車輛外觀、音樂與地圖各自可能有使用條件，因此能被放進示範，不等於可以隨意改成商業成品。

這次公開頁保留 OpenStreetMap 貢獻者署名，提醒創作者第三方資料需要保留來源。自己的作品也應逐項整理依賴，避免最後只留下成片或截圖，卻找不到素材出處。

交接時，除了作品連結，還可以要求提供專案檔案、如何啟動、已知限制與測試設備。因為接手的人需要能繼續工作，這些資料才會把一次性展示變成可延續的原型。

延伸閱讀：Perplexity SPACE 開源：每個 AI 任務一台微型虛擬機，憑證與連線怎麼管？

Perplexity Roadster 遊戲常見問題

這是官方發布的正式遊戲產品嗎？

執行長分享的是 Computer 製作的示範作品與連結。公開資訊沒有提供正式遊戲的發行、維護或商業營運承諾，因此較適合當成原型案例理解。

是否證明一個人不懂程式也能做出相同作品？

沒有，因為完整提示詞、修改次數與人工協助比例未公開。讀者可以借用任務拆解方式，但不能把單一展示當成每個人的固定成果。

遊戲裡的飛行是否代表真車可以這樣飛？

不代表，遊戲使用的是作品設定的規則。實車功能需要產品文件與測試證據，無法由瀏覽器模擬推定。

可以直接估計開發費用嗎？

無法從這支影片得出完整成本。自己的預算應包含生成、修改、測試、部署與後續維護，並依實際工作紀錄估計。

用原型縮小問題，再投入正式開發

這次 Roadster 示範讓 AI 遊戲製作多了一個可以打開討論的例子。它的價值在於把想法變成可觀察的操作，讓團隊更快知道自己到底要做什麼。

願意限制範圍、讓別人試玩並修正需求的人，較適合從這種工作方式開始。若期待單次生成就完成正式產品，則容易忽略相容性、素材與維護的成本。

可以先挑一個最小玩法，寫清楚成功條件，再請工具交付可修改的專案。保留每次測試結果，並訂閱 AI 郵報追蹤更多從展示走向可用作品的案例。

資料來源

• Aravind Srinivas 分享 Roadster 遊戲
• San Francisco · Drive and Fly 公開作品
• Perplexity 官方 Computer 工作坊