Replit Self-driving company 是什麼？AI Agent 如何讓工程產出提高 2.9 倍
Replit CEO 提出 Self-driving company，並公布工程產出提高 2.9 倍、客服縮時等內部數據。解析企業 AI Agent 工作流程、應用方式與治理風險。
Replit 執行長 Amjad Masad 提出 Self-driving company，描述公司如何把 AI Agent 接進工程、資料分析、業務、行銷與客服流程，讓 Agent 從個人工具變成企業工作流程的執行層。
他提出的「Self-driving company」，可以翻成「自動駕駛公司」。但這不是一家完全不需要人的公司，也不是把所有員工換成 AI。更精確地說，它是一套由人決定方向、AI Agent 負責拆解與執行大量步驟，遇到需要判斷或承擔責任時再交回給人的營運模式。
Replit 公布的內部數據很亮眼：固定一批工程師的程式碼產出提高到原本的 2.9 倍，Code Review 延遲沒有增加，程式碼撤回率與重大事故數也沒有同步惡化；客服案件交由真人處理後，完整解決時間則縮短超過一半。
不過，這些資料目前都來自 Replit 自己的案例，還不能直接推論每家公司都能複製。真正值得注意的也不是「AI 寫了多少程式碼」，而是 Replit 已經開始用 Agent 改寫公司的工作分工。
Replit Self-driving company 重點整理
| 觀察指標 | Replit 公布的內部結果 | 應該如何解讀 |
|---|---|---|
| 固定工程師產出 | 提高到原本的 2.9 倍 | 排除擴編影響後，Agent 工作流程仍帶來明顯產出變化 |
| Agent Code Review | 超過三分之一的合併 Pull Request 由 Agent 核准 | Agent 不只寫程式，也開始參與品質檢查 |
| 程式碼品質 | 撤回率呈下降趨勢，重大事故數大致持平 | 產出提高時，品質指標未同步惡化，但仍缺少第三方驗證 |
| 客服處理 | 真人升級案件的中位解決時間從約 33 小時降至 13 小時 | Agent 先完成調查，能減少真人重新理解問題的時間 |
這些數字都來自 Replit 自行公布的約半年資料，不能當成一般企業導入 AI Agent 後的標準成效。它們更適合用來觀察 Agent 可以進入哪些工作環節，以及企業該如何同時衡量速度與品質。
Replit Self-driving company 是什麼？人負責方向，Agent 負責過程
傳統 AI 工具多半停留在單次任務：寫一封信、整理一份文件，或生成一段程式碼。AI Agent 的差別，是它能拿到一個目標後，自行蒐集背景、呼叫工具、執行多個步驟、檢查結果，必要時再請人介入。
在 Replit 的描述中，這些 Agent 不是只住在聊天視窗裡，而是能接觸 GitHub、Google Cloud、Azure、Linear、Notion、Slack 與 Zendesk 等企業系統。公司也加入存取政策、權限代理、稽核紀錄與 Zero Trust 網路。Zero Trust 是一套「每次存取都要重新驗證」的資安原則，不會因為使用者或 Agent 已在公司網路內，就預設它值得信任。
這個定義很重要。Self-driving company 並不代表 Agent 可以無限制地做決定，而是把目標、資料、工具、權限與驗證流程連成一套系統。人仍要決定問題是否值得解、接受哪些取捨，以及最後由誰負責。
因此，我認為「自動駕駛」是一個容易理解、但略帶行銷意味的名稱。現階段更接近的說法，是「由人監督的 Agent 化公司」。它的價值在於減少人逐步操作的工作量，不是取消人的判斷。
工程團隊先看到成效：同一批工程師產出提高 2.9 倍
Replit 表示，公司在 2026 年 1 月底擴大內部 Agent 實驗，讓工程師可以同時調度多個 Agent。從 1 月初到 6 月底，整體每週變更的程式碼行數增加 5.8 倍；若排除擴編影響，只比較固定的 30 名活躍工程師，程式碼產出仍提高到原本的 2.9 倍。
單看程式碼行數並不能證明產品變好。自動生成大量重複程式碼，也可能讓數字膨脹。因此 Replit 同時檢查了 Code Review、程式碼撤回、系統事故與專案完成速度。
Code Review 是程式碼合併前的審查流程。Replit 讓 Agent 先判斷 Pull Request，也就是工程師提出的程式碼變更申請，只有風險較高時才加入第二位真人審查者。公司表示，這套做法已節省約 30% 的真人審查時間，而且審查延遲維持穩定。
Replit 也表示，在產出提高的同時，程式碼撤回率呈下降趨勢，重大事故調查數量大致持平，平均緩解時間則縮短。這組結果比單純的程式碼行數更有參考價值，因為它同時觀察速度與品質。
但仍要保留一個限制：Replit 沒有公開完整原始資料、統計方法與對照組，這些圖表也是公司自行選定的指標。它可以視為值得研究的企業案例，還不是能證明因果關係的獨立研究。
真正的變化不是 AI 寫程式，而是工程師開始管理 Agent 團隊
Replit 把多個 Agent 反覆執行、檢查直到達標的流程稱為 loop。工程師不再親手完成每一個檔案，而是定義目標與驗收條件，再讓一群 Agent 平行處理可驗證的任務。
文章列出的案例包括：處理長期擱置的 CSS 系統遷移、建立產品在地化流程、維護不穩定測試，以及調查困難的網路問題。Replit 的 AI 團隊還建立了一套持續學習系統，分析使用者回饋、提出改善方案，再透過基準測試與 A／B Test 驗證是否真的更好。
這裡的關鍵不是 Agent 能不能生成程式碼，而是任務能不能被清楚定義與驗證。只要完成條件模糊，Agent 就可能高速產生大量看似合理、實際無法使用的結果。
換句話說，AI 並沒有讓管理消失，而是把管理單位從「人」擴大成「人加 Agent」。工程師的價值也會從執行每一步，轉向拆解問題、設計驗收、判斷風險與處理例外。
AI Agent 開始進入資料、業務、行銷與客服
Replit 的下一步，是把工程團隊建立的 Agent 系統推向整家公司。Slack 成為主要入口，其他部門可以直接詢問 Agent，再由它讀取文件、程式碼與授權資料完成工作。
資料團隊：把資料定義交給 Agent 使用
Replit 的資料團隊替資料倉儲建立 semantic layer，也就是清楚標記哪些資料表是可信來源、欄位代表什麼，以及資料彼此如何關聯。其他員工便能用自然語言詢問營運問題，由 Agent 產生圖表或簡報。
這種做法真正節省的，不只是寫 SQL 的時間，而是來回確認資料口徑的成本。但前提也很明確：如果公司沒有整理資料來源與定義，Agent 只會更快地產生錯誤答案。
業務與行銷：從內部資料直接產生客戶材料
業務團隊讓 Agent 尋找並補充潛在客戶資料，準備會議前需要的帳戶資訊，再把結果整理成客製化簡報。行銷團隊則能根據產品、工程文件與過往討論，先產生產品規格與上市材料的初稿。
這些流程的優勢來自企業內部脈絡，而不只是模型本身。通用 AI 工具也能寫文案，但若看不到實際產品狀態、客戶使用資料與公司知識，就很難完成同樣的工作。
客服：先調查，再決定回答或升級
Replit 的客服 Agent 會依照標準流程調查問題，判斷是否能用既有客服語氣回覆，或把摘要與調查結果一起升級給工程團隊。公司表示，即使只計算最困難、最後仍需要真人介入的案件，完整解決時間也從 2026 年 1 月約 33 個工作小時，降至 6 月約 13 個工作小時。
這個案例比「AI 自動回信」更有意思。Agent 先做資料蒐集與初步排查，真人接手時不必重新從零理解問題，等待時間才可能真正下降。
Replit 案例最值得學的，不是買哪一套 AI 工具
Replit 表示，內部 Agent 已經取代一套每年支出達七位數美元的 SaaS，也在事故調查與自動化滲透測試中，以十分之一成本達到相近或更好的結果。這些仍是 Replit 的自述，外界目前無法獨立驗證，也不知道被比較的產品、用量與完整成本口徑。
即使如此，這段經驗仍指出一個可能的企業軟體趨勢：當公司能用自己的資料、權限與流程快速組出專用 Agent，通用 SaaS 的價值就不能只靠功能清單，而要回到可靠性、維護、合規與總持有成本。
企業也不該看到案例後，就急著做一個「公司總 Agent」。比較實際的導入順序是：
- 先選擇高頻、耗時，而且結果容易驗證的工作。
- 限制 Agent 能讀取的資料與可執行的操作。
- 保留稽核紀錄、成本上限、失敗回復與人工升級機制。
- 同時追蹤速度、品質、事故與真人返工時間。
- 確認流程穩定後，再逐步擴大權限與部門。
這條路徑不像「全面 AI 轉型」那麼有話題，但更容易落地。Replit 的案例也顯示，成效最大的地方通常不是最複雜的策略決策，而是那些背景資料分散、步驟繁瑣、可以客觀驗收的工作。
Self-driving company 的三個現實限制
1. 公司內部資料不乾淨，Agent 就無法可靠工作
Replit 能讓員工直接詢問商業數據，前提是資料團隊先整理可信來源與欄位關係。對多數企業來說，真正昂貴的工作可能不是導入模型，而是補齊文件、權限與資料治理。
2. 權限越大，錯誤半徑也越大
Agent 若只能整理資料，錯誤可能只是一份不準確的報告；若能修改程式碼、處理客服或操作企業系統，錯誤就可能直接影響產品與客戶。Replit 官方文件也把權限控制、稽核紀錄、私有部署與安全掃描列為企業功能。這些不是附加選項，而是 Agent 能否進入正式流程的必要條件。
3. 自家案例仍需要更長時間驗證
Replit 的數據涵蓋約半年，且來自一家本來就以 AI 開發工具為核心的公司。它的工程文化、工具基礎與員工能力，未必適用於傳統企業。後續若程式事故、資安事件、客訴或維護成本上升，現在看到的效率優勢就可能縮小。
因此，我對「Agent 會成為企業的新執行層」偏正面，但對「公司已能自行駕駛」仍保持保留。更準確的判斷是：可驗證的執行工作正在快速 Agent 化，策略、責任與例外處理仍牢牢留在人手上。
Replit Self-driving company 常見問題
Self-driving company 會取代所有員工嗎？
不會。Replit 的定義仍由人設定方向、選擇問題、處理取捨並對結果負責。AI Agent 主要接手的是蒐集資料、執行步驟、檢查結果與處理重複工作。
Self-driving company 和一般工作流程自動化有什麼不同？
一般工作流程自動化多半按照預先設定的固定步驟運作；Self-driving company 則讓 AI Agent 根據目標與當下資料，動態決定要呼叫哪些工具、採取哪些步驟，以及何時交給真人處理。彈性更高，但也更需要權限限制、結果驗證與稽核紀錄。
Replit 的工程師產出真的提高 2.9 倍嗎？
這是 Replit 根據固定 30 名活躍工程師所公布的內部數據。公司也同步觀察 Code Review、程式碼撤回與系統事故，但目前沒有完整原始資料或第三方驗證，因此適合視為企業案例，不宜當成所有公司都能達成的標準。
一般公司應該從哪種 AI Agent 工作開始？
優先選擇高頻、耗時、規則清楚且結果容易驗證的任務，例如客服問題初步調查、內部資料彙整、測試維護或固定格式報告。不要一開始就讓 Agent 直接處理付款、刪除資料或無限制修改正式環境。
導入企業 Agent 最重要的是模型能力嗎？
模型能力很重要，但正式導入更常卡在資料、權限、驗收與責任設計。如果 Agent 不知道哪份資料可信、能做哪些操作、什麼情況必須停下來找人，再強的模型也很難穩定工作。
結語：Replit Self-driving company 的真正意義，是重新分配人與 Agent 的工作
Replit 的「Self-driving company」最有價值的地方，不是提供一個新的 AI 口號，而是公開了一套更接近實際營運的 Agent 導入方式：先從工程團隊建立可驗證流程，再把相同架構擴大到資料、業務、行銷與客服。
我不認為公司已經能真正「無人駕駛」。只要目標選擇、權限配置、品質判斷與責任歸屬仍需要人，自動化就有清楚的邊界。
但 Replit 的案例也顯示，企業真正要準備的已不只是讓員工學會使用聊天機器人，而是重新設計「哪些工作由人決定、哪些步驟交給 Agent，以及什麼情況必須交還給人」。這才是 Self-driving company 對其他公司的實際啟示。
