# 你的 Cloud 應該內建 App Builder > 📖 本站完整內容索引（documentation index）：[llms.txt](/llms.txt) > 原作者：Railway (@Railway) · 策展與摘要：EasyVibeCoding · 平台：X (Twitter) · 熱度：🔥🔥 · 日期：2026-08-15 > 原始來源：https://x.com/Railway/status/2088343101966528926 ## 證據與延伸閱讀 - [# 你的 Cloud 應該內建 App Builder](https://x.com/Railway/status/2088343101966528926) ## 中文摘要 # 你的 Cloud 應該內建 App Builder 顯然，20 分鐘足以讓 Agent 建置並部署一款支援多人遊玩與重生的線上第一人稱射擊遊戲。 以下是完整 Prompt： > 建置一款即時多人第一人稱射擊遊戲。玩家可以自動快速加入房間、輸入房間碼加入現有房間，或建立新房間並取得可分享給其他人的房間碼。玩家可以互相射擊並造成傷害。死亡後會再次重生。產生所有 asset，包括地圖、音效和視覺圖像。確保即時功能在本機與正式環境中都能正常運作。 Agent 開始執行、建置遊戲，透過和自己對戰一回合來測試，然後完成部署。這款遊戲玩個幾分鐘還滿有趣的，但要讓人願意一再回來玩，還需要更多工作。話雖如此，Agent 現在只靠幾個指令就能做到這種程度，確實相當令人印象深刻。 更棒的是？ 整件事都是在 dev.new 上完成的，而這正是我們真正想讓你看的東西。 ## dev.new？ 直到最近，如果你想把某個東西部署到 Railway，就需要先有來源。來源可以是透過 `railway up` 提供的本機程式碼、GitHub 程式庫，或 Docker 映像檔。接著，我們會建置你的應用程式並完成部署。 但如果你沒有來源，就沒什麼能做的了。幸好，Agent 讓這件事不再是什麼大問題。你只要告訴 Agent 想建置什麼，它就會提供程式碼。接下來，Agent 甚至可以把它部署到 Railway，持續迭代，直到一切正常運作。 我們一直都在針對這種工作流程進行建置：以 Agent 為優先的 CLI、MCP 伺服器和 skills，讓 Agent 能輕鬆操作 Railway。我們已經撰寫過不少相關內容。 但在這種工作流程中，建置仍然是在其他地方進行。程式碼要到最後才會來到這裡。所以我們接著問了下一個問題：如果你能在同一個地方完成建置與部署呢？只帶著一個想法出現，離開時就帶走一個正在運作的應用程式？ 我們再次回到實驗室。成果就是 dev.new。 你使用 Railway 帳號登入，描述想建立的內容，接著你的應用程式就會自動為你建置。你可以預覽應用程式、持續迭代，等對結果感到滿意後再進行部署。完成部署後，你的應用程式會在同一個 Railway 專案中擁有自己的服務，並取得可分享的公開 URL。 在 dev.new 上，從第一次 Prompt 開始，你的應用程式就會在 Railway 的真實電腦上執行：具備持久性磁碟、真實網域，以及能夠保存狀態的伺服器。 這就是我們選擇即時多人遊戲作為示範的原因。這類應用程式不是只靠前端就能建置的。必須有某個東西保存比賽狀態：每位玩家的位置、剩餘生命值，以及所在的房間。還必須有某個東西為每位玩家接受一個 WebSocket、判斷誰射中了誰，並在玩家進出時維持房間運作。這些都需要一台長時間執行的伺服器。 以下就是這台電腦的樣子，以及 Agent 如何使用它。 ## 電腦、Agent 與執行過程 ### 電腦 你的第一個 Prompt 會在 workspace 中建立一個 Railway 專案，並以你正在建置的內容為專案命名。接著，專案會啟動 Agent 所在的電腦：一台完整的 VM。它使用的基礎架構，和驅動 Railway 沙盒的基礎架構相同。以下是各個元件之間的連接方式： ![展現 Development and preview 與 Live app / production 兩大區塊架構及其部署流程的系統流程圖。](https://pub-75d4fe1e4e80421b9ecb1245a7ae0d1a.r2.dev/curated/0f2461f048b076f5.jpg) > 比較 Development and preview 與 Live app / production 兩大區塊運作流程的架構圖，左側展示 Coding agent workspace、Development server 與 Stable preview link 的開發預覽流程，右側則標示 Railway service、Railpack build、New deployment 與 Stable public link 的生產部署流程，並透過 New prompt 及 ship 動作將原始碼上傳與更新。
展開畫面重點
Development and preview - Coding agent workspace (Mutable): The agent edits source in a persistent `/app` - Development server: Starts from the workspace, listens on port `8080` - Stable preview link: Hot reload shows each change as the agent saves it Live app / production - Railway service: Created on first deploy (`Stable target`) - Railpack build: Builds the uploaded source - New deployment: Runs the deployed version - Stable public link: Stays fixed across deploys 中間連接與標籤： - `New prompt` - `Deploy uploads the current source` (`ship`)
workspace 是 `/app`。第一次啟動時，系統會複製一個內建範本，其中包含 Vite、React 19、Tailwind CSS v4 和 TypeScript。相依套件已預先安裝，因此預覽可以直接啟動，不必等待冷啟動安裝。 `/app` 中的所有內容都會持續保存，包括 Agent 的工作階段逐字記錄。電腦閒置一段時間後，系統會將檔案系統內容寫入磁碟並關機。你下次回來時，它會重新連結相同的磁碟區並再次啟動，程式碼和對話都會保留在原本的位置。範本也包含 workspace 規則。開發伺服器已經在連接埠 `8080` 上執行，並支援即時重新載入，因此 Agent 絕對不能啟動、停止或重新啟動它。新增相依套件則沒有問題。 `vite :8080` 這行也是你查看電腦狀態的視窗：當 Agent 工作時，studio 會將它呈現為即時預覽。在預覽中點選某個元素，dev.new 就會解析出產生該元素的元件、檔案和行號。接著，這個元素會連同你的下一個 Prompt 一起交給 Agent。這比寫一大段「從左邊數來第三張卡片」的描述好用得多。 ### Agent 其中的程式撰寫 Agent 是 Railway Agent，也就是我們自行打造的程式撰寫 Agent：`railway-agent`。它直接在 VM 內執行，而不是從外部連入 VM；它會像一般開發者一樣在 `/app` 中工作：編輯檔案、執行指令、讀取記錄。 除了 Shell 之外，它還能使用已完成驗證的 Railway CLI、映像檔中預先內建 Chromium 的 Playwright，以及能夠部署工作目錄的 `ship` 工具。連接的 context 整合功能則透過 MCP 提供。這次執行主要使用了 Shell、Playwright 和 `ship`。 ### 執行過程 Agent 一開始先四處查看：workspace 中有什麼、專案長什麼樣子，以及目前已經有什麼正在執行。接著，它安裝了所需的幾個函式庫，便開始工作。 最後產生的是一個可直接部署的單一應用程式：一台負責管理比賽的伺服器，包括目前有哪些房間、房間裡有哪些人、每個人的位置與生命值，以及誰射中了誰；同時提供一個呈現遊戲畫面的前端，並將你的輸入傳回伺服器。所有 asset 都是在過程中產生的。地圖、材質和每個音效都是由程式碼生成的。 Agent 在 VM 中使用真實瀏覽器檢查成果、讀取主控台，並找出型別檢查器可能無法發現的錯誤。 它甚至實際玩了這款遊戲來進行測試！它在同一個房間中啟動了兩個瀏覽器工作階段，觀察玩家移動、射擊、死亡和重生。針對遊戲規則，它撰寫了一個小型腳本，連接兩名玩家，讓其中一人反覆射擊另一人，確認傷害、死亡和重生依照正確順序發生。 所有內容在本機通過測試後，它使用 `ship` 完成部署，並再次透過正式 URL 執行完整的遊玩測試。 `ship` 是 Railway 一般部署流程的簡易包裝程式。第一次執行時，它會在同一個專案中建立一項服務，並記住這項服務，供日後部署使用。它會上傳 `/app`，接著由 Railpack 偵測應用程式、安裝相依套件、執行正式環境建置，並判斷啟動方式。建置成功後，Railway 會指派一個公開網域，而 `ship` 會回傳正式環境 URL。下一次部署時，則會更新同一項服務。 ## 接下來的發展 由於 dev.new 應用程式就是一般的 Railway 專案，dashboard 已經知道該如何處理它：新增資料庫、設定變數、連結自訂網域，或直接操作已部署的服務。今天下午先建置一個一次性內部工具，之後再把它發展成正式環境系統。當原型開始認真投入使用時，不需要匯出或重新遷移到其他平台。 長期來看，我們希望將這個迴圈直接整合進 Railway dashboard，讓你的 Agent、來源、基礎架構、預覽和部署不再分散在不同地方。在那之前，先把想法帶到 dev.new，接下來就交給我們。 我們目前正在和使用者一起測試。建置點東西，然後告訴我們 Agent 或介面在哪些地方妨礙了你的工作。歡迎在這個 Central Station 討論串或 Discord 上留下回饋。 ## 標籤 Agent, AIGC, 自動化