在現代軟體工程中，生成式 AI 已能高效產出程式碼，但企業面臨的真正挑戰在於如何「信任」這些程式碼。許多團隊雖然使用了 AI 生成率高，但由於缺乏驗證機制，工程師仍需花大量時間審查，甚至在半夜處理由 AI 產生的未知 Bug。Roblox 的軟體工程副總監 Andrew Swerdlow 在 QCon AI 的分享中，揭露了他們如何透過「Prompt to Prod」計畫，將 AI 從單純的自動補全工具，提升為能自主執行整個軟體開發生命週期（SDLC）的 Agent（代理人）。
背景與核心問題：信任鴻溝與技術債
目前的 AI 開發模式存在一個悖論：我們解決了「打字」的問題，但沒解決「信任」的問題。如果僅僅加速程式碼生成而忽視安全性與可維護性，實際上是在快速積累技術債。當 AI 產出的程式碼量增加，而人類審核能力跟不上時，將導致沒有人真正理解生產環境中的程式碼邏輯。
Roblox 的目標是實現從一個 Prompt（提示詞）直接進入 Production（生產環境）而無需人工干預。然而，要達成此目標，核心難點不在於選擇哪個最強的模型，而是在於底層基礎設施的改造以及安全防護網的建立。
建立信任的基礎設施：沙盒與對齊引擎
為了讓 AI Agent 能安全地執行工作流，Roblox 首先解決了安全與權限問題。他們建構了專屬的 Sandbox（沙盒），這是一種隔離的執行環境，確保 AI 在執行程式碼時不會影響主機檔案或非法訪問網路。同時，他們實施了 Just-in-time permissions（即時權限管理）與 Least privileged access（最小權限原則），確保 AI 僅在需要時擁有最低限度的權限，且所有 AI 的操作紀錄必須與人類身分明確區分，以便審計。
在提升可靠性方面，Roblox 發現單純的微調（Fine-tuning）或系統提示詞無法讓 AI 像頂尖工程師一樣思考。他們提出了一套「Exemplars（典範）」機制：透過分析過去三年的 70 萬個 Pull Request（PR，合併請求）及其審核評論，提取出公司內部的制度化知識，並將其轉化為可測試、可擴展的 YAML 規則文件。
這些典範被整合進 Alignment Engine（對齊引擎）中。當 AI 進行程式碼審核時，引擎會調用這些專家經驗來指導 AI。結果顯示，加入典範後的 AI 審核建議接受率提升至 68% 到 70%，甚至超過了人類審核員的平均接受率（55%）。
從基礎設施到流程自動化：消除人為瓶頸
要實現「Prompt to Prod」，Roblox 發現最大的障礙其實是傳統的「管線（Plumbing）」不足。以修改首頁實驗功能為例，原本需要經過 18 個不同的人為觸點且耗時數週，且許多工具缺乏 API 或 CLI（命令行界面）。
為了讓 AI Agent 能操作這些工具，Roblox 進行了大規模的基礎設施改造，利用 Playwright 等工具將 UI 界面轉換為 AI 可調用的 CLI，並補齊了單元測試、集成測試、金絲雀部署（Canary Deployment，逐步推送新版本以降低風險）以及自動回滾（Auto-rollback）機制。
更激進的變革在於政策層面。Roblox 重新定義了審核流程，允許在低風險場景下由 AI 完成審核並直接合併至生產環境，打破了「每行程式碼必須經由人類審核」的傳統假設。他們建立了一個閉環：AI 撰寫、審核、修復、部署並根據反饋迭代，而人類則轉向提供正負面訊號來優化 AI 的評估集（Eval set）。
重新定義生產力指標：從 PR 數量到特徵速度
當開發流程自動化後，傳統的指標（如程式碼行數、PR 數量或 DORA 指標）將失效，因為這些指標衡量的是 AI 的產出而非工程師的價值。Roblox 提出了三套新的衡量維度：
第一是 Agent Quality（代理人質量），透過 Eval（評估框架）來量化 AI 的表現。例如，測試新模型在無人工干預下能將單元測試覆蓋率從 50% 提升到 60% 嗎？如果能，才予以採用。
第二是 Feature Velocity（特徵速度）。他們利用 LLM 自動分析 PR 的意圖，將其分類為新功能、Bug 修復或重構，並追蹤「每位工程師產出的中位數特徵數量」。數據顯示，在 AI 導入半年後，特徵速度提升了約 22%。
第三是 Long-turn Rate（長週期執行率）。這是邁向 24/7 全天候 AI 的關鍵。目前的 AI 互動多為 40 秒一次的短回合，這意味著人類仍需時刻盯著。Roblox 的目標是讓 AI 能在接收到規格書後，自主處理 8 小時而不需中斷，真正實現非同步的自主開發。
實務意義與限制
Roblox 的經驗表明，AI 驅動的開發轉型，其重心在於「基礎設施工程」而非「AI 模型工程」。如果缺乏強大的沙盒、自動化測試和可量化的評估體系，AI 只會加速產生技術債。
此外，這也改變了工程師的角色。未來工程師可能不再深入理解每一行程式碼，而是生活在 AI 抽象層之上，專注於定義規格（Spec-driven development）與管理系統邊界。雖然這種模式在醫療等高監管行業難以實施，但在快速迭代的消費級產品中，它將極大縮短從創意到上線的距離。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。