Replit 如何規模化評測和持續改進 Vibe coding
來源：愛好 AI 工程 Blog（https://blog.aihao.tw） 發布日期：2026-06-01 演講：Michele Catasta（Replit 總裁兼 AI 負責人）@ Anthropic「Code with Claude」 原始影片：Evaluating and improving Replit Agent at scale
Replit 的總裁兼 AI 負責人 Michele Catasta 在 Anthropic「Code with Claude」場子的這場演講 Evaluating and improving Replit Agent at scale，小編覺得是少數真的把「規模化做 eval」講到骨子裡的一場。Replit 每天對著數百萬使用者出貨好幾個版本的 agent，模型又一直在變，他們到底怎麼確定 agent 真的有變好、而不是憑感覺?這場演講把整套體系攤開來講，還順手在台上 open source 了一個新的 vibe coding benchmark。
以下是重點整理:
1. Replit 面對的是 vibe coding 最極端的那一版
Catasta 一開場就先界定問題的特殊性。vibe coding 這個詞涵蓋範圍很廣，一端是給軟體工程師用的工具，但 Replit 的場景是最極端的那一端: 使用者只給一句自然語言的需求描述，其他什麼都沒有。
使用者期待「從一句 prompt 直接變成一個能跑的應用」，但他們不會告訴你要用什麼框架，不會寫測試，也不指定任何實作細節，就是預期 agent 跑完之後東西能動。這跟過去替軟體工程師打造 agent 的假設完全不一樣，所以「過去做 eval 的方式，跟過去建 agent 的方式，都必須從根本上改變」。
Replit 的使用者大多是完全沒寫過程式碼的知識工作者(knowledge worker)，這直接決定了他們的 eval 不能只看「程式碼有沒有改對」，而要看「做出來的 app 有沒有照使用者要的去動」。
2. 為什麼這件事特別難: 腳下的地一直在動
Catasta 用「shifting grounds」(腳下的地一直在動) 來形容他們的處境。
模型一直在變，而且演進速度比一年前更快。模型一變，他們的 system prompt、user prompt 就得跟著改;為了配合產品新功能，prompt 也要常常調整;工具定義也一直在動，他們不斷新增、簡化工具。然後最關鍵的是出貨頻率: Replit 每天都有好幾次發布，而且是直接推到數百萬使用者面前。
3. 核心主張: eval 不該是一個分數，而該是一條串流
左邊是「舊工作」: 你跑一次 eval，產出一個分數，然後由人類來看這個分數，決定「我的 agent harness 比之前好還是退步了」「該不該多做點 post-training」。整個流程在「人類做決定」這一步就停了。
Catasta 主張要往右邊那種「持續性」的設定走: eval 不是給人類消費的一個分數 (a score humans consume)，而是一個系統運行所依賴的串流 (a stream a system runs on)。
所以他們做的是 offline eval (類似 SWE-bench 那種 benchmark) 加上 online eval (基於真實系統使用) 的組合。他對 eval 的要求很明確: 第一要優化使用者真正在乎的東西，而不是只告訴你 agent 有沒有把程式碼改對;第二要能立刻指出什麼壞掉了。
4. 兩根支柱: 出貨前的守門關卡，出貨後的持續挖掘
一根是老派的 benchmark，通常在出貨新版 agent 之前跑，當成一個是非開關。如果 offline benchmark 出現重大退步，就停止發布;沒變化或變好，就放行。
另一根更有意思: 大量的 A/B testing，加上把線上所有的 trace 拿來分群、從中萃取洞見。這根 online 支柱是在你出貨之後才開始運作。
兩根支柱到位之後就形成一個迴圈: 看兩邊給你的結果、據此改程式碼、再跑 eval，洗了又重來。
5. 為什麼 SWE-bench 不夠用: 缺了「功能正確性」
SWE-bench、HumanEval 這類 benchmark 本質上都遵循同一套協定: 確認生成的程式碼符合 prompt、把 patch 套到 repository 上、跑測試。
問題是這完全不反映 vibe coding 的真實狀況。使用者不寫測試，常常是從一個完全空白的 code base 開始。根本不存在「套 patch」這種情境。
真正要捕捉的是: 這個 app 有沒有做到使用者要求的事?他把這叫做「functional correctness gap」(功能正確性的落差)——「沒有人在量測的那個訊號」(the signal nobody was measuring)。
6. 台上發表 ViBench: 端到端 vibe coding 公開 benchmark
Catasta 直接在台上開源了 ViBench (vibench.ai)，一個端到端、針對 vibe coding 的公開 benchmark。
輸入就是一份 PRD(產品需求文件)，從 Replit 的真實使用 trace 裡挑了 20 個案例。有一個 harness 把 app 從空 repo 端到端蓋成可以動的東西。
關鍵的 insight 在最後一步: 他們做了自動化的 evaluator。讓 benchmark 從「大概一週跑一次」變成「每次都能跑」。
7. ViBench 架構: 一個核心 + 五種情境
寫死核心是 behavioral eval (行為評估);前面兩個槽——輸入跟策略——可以接任何東西。
由淺到深:
- Zero-to-One: 輸入 PRD，一次到位從零蓋到一
- Vibe-on-Ref: 從已能動的 reference 實作開始加功能
- Vibe-on-Vibe: 從 agent 自己蓋的 MVP 開始再疊新功能 (slop-on-slop)
- Parallel + Merge: 任務分解、平行跑多個 agent、合併 patch
- Decomposition: 輸入超大 PRD，讓 agent 自己規劃拆解
還可從有 bug 的 app 開始加功能，型錄開放給社群貢獻。
8. 評分最難: 完全與實作無關的 evaluator
因為 Replit 完全不給使用者框限，愛用什麼語言、框架都可以。evaluator 必須對「實作長什麼樣子」完全不可知 (agnostic)。
做法: evaluator agent 先讀過整個程式碼庫，開瀏覽器指向 agent 蓋好的應用，一步一步照測試計畫走。測試計畫用自然語言寫，任何一步失敗就彙整生成分數。
對照 SWE-bench: SWE-bench 是固定場地，ViBench 是完全 greenfield。
9. ViBench 兩個發現
- 前沿模型跟開源模型之間有將近 2 倍的差距
- 大多數模型在「延伸自己寫的程式碼」時表現更差 (slop-on-slop 最難)
實戰建議: 每次新增功能之間一定要插測試步驟，否則在搖晃的地基上往上蓋，遲早會垮。
10. Online eval: 數百萬條真實 session
每天收集數百萬條 session，捕捉使用者在平台上真正做的事。問題變成: 怎麼從這堆東西蒸餾出有用資訊?
11. A/B testing 是讓自己保持誠實的方式
在 agent 裡埋大量監測點跟指標: 異常花費、執行時間、使用者情緒分析 (每次 prompt 都能做)、發布率。
但 A/B test 結果幾乎不會是非綠即紅的乾淨答案——人類品味跟產品哲學還是關鍵。
12. Trace 分群: 把不知道該找的問題浮現出來
把所有 trace 摘要轉成 embedding、按類型分群。不是靠 regex 或掃日誌，而是靠語意分群，能將語意相近的東西分一起。
每天晚上重新訓練這些群集。好處: 可以回頭看某個群集在修好問題後是不是真的消失了——對抓 1% 長尾問題特別實用。
13. Telescope: 全自動改進迴圈
- Discover: trace 分群發現問題
- Create code changes: coding agent 自動從 trace/日誌/儀表板資訊開 PR
- Evaluate: 重跑 ViBench (litmus test，掉超過 10 分判定壞的)
- 有爭議的跑 A/B test，明顯好球直接出貨
- 假設正確但 PR 不夠完美就繼續迭代
90% 由迴圈裡的 agent 代勞。
14. Cold-start 案例
Telescope 標記出一個小但在成長的群集——環境冷啟動長尾退化。agent 在環境還沒準備好就先動起來，因為太 eager to fix，開始試圖修環境。每次 debug session 長得都不一樣。
只靠撈日誌浮現不出來，語意分群才發現它發生得相當頻繁。
15. 人類品味還是最重要的
Catasta 把人類品味落在四個位置:
- 假設選擇 (hypothesis selection): 哪些問題值得花掉迴圈預算
- 實作架構 (implementation architecture): 工程跟產品決策
- Eval 策展 (eval curation): 你在「形塑 agent 要爬的那座山」
- 發布核可 (launch approval): A/B test 不清楚時要不要發布
品味養成: 一年半前沒什麼品味可言，像生存遊戲。現在 agent 變強、選擇變多，才開始發展品味，且必須跟真實使用者群對齊。Replit 80% 決策跟替工程師做 agent 時相反。
16. 實戰提醒
- 半年前 ROI 不好放棄的事，現在絕對值得再試一次 (長上下文 + 強推理模型)
- 認真投資「收集所有能收的訊號」: trace、產品回饋、Datadog 監測
- 分群幫你排出優先序: 當回饋多到喘不過氣時，分群告訴你什麼真正重要
結尾
別把 eval 只當成出貨前的最後一道檢查，要把它想成「一具能讓你每天出貨更好 agent 的引擎」(an engine that allows you to ship a better agent every single day)。
Replit 的答案: 把 eval 拆成兩根支柱——出貨前當守門員的 offline benchmark (ViBench)，加上出貨後靠 trace 分群持續挖掘的 online 系統 (Telescope)——再用一個幾乎全自動的迴圈把兩者接起來。
而最反直覺的: 自動化跑得越多，人類的品味反而越關鍵。eval 自動化解放了人，但沒有取代判斷。