Replit 如何規模化評測和持續改進 Vibe coding

原始來源與檔名：2026-06-07T100350+0800-Replit 如何規模化評測和持續改進 Vibe coding.md

NAPKIN | 餐巾纸

• 餐巾紙公式：Continuous Eval = Offline Greenfield Benchmark (ViBench) + Online Semantic Trace Clustering (Telescope) + Automated PR Loop
• 一句話：Replit 將 Eval 從「單次靜態評分」轉化為「驅動系統持續進化的資料流」，透過端到端功能驗證與線上語意分群，建立起幾乎全自動的 Agent 迭代引擎。
• 餐巾紙草圖： [Online Usage] -> Traces & Logs -> [Semantic Clustering] -> (Discover Tail Issues) -> [Coding Agent] -> Generates PR -> [Offline Eval (ViBench)] -> Pass -> [A/B Testing] -> Human Taste Approval -> [Ship to Production]

ROUND 1: SKELETON | 骨架掃描

• 核心問題：當模型、Prompt、工具都在快速迭代，且每天對著數百萬非技術使用者出貨時，如何確保 Agent 真的在進步且對齊使用者需求？傳統如 SWE-bench 只看 Patch 是否通過測試，無法衡量從零構建的「功能正確性」。
• 核心答案：建立雙支柱的 Eval 體系：第一支柱是出貨前的自動化端到端基準測試（ViBench）；第二支柱是出貨後的線上真實 Trace 語意分群分析（Telescope），並以此建立自動修復 PR 迴圈。
• 論證結構與章節骨架：
  1. 定義極端場景（從零到一的自然語言構建）與挑戰（基礎建設不斷變動）。
  2. 提出核心理念：Eval 是一條資料流，而非單一分數。
  3. 支柱一：Offline Eval，開源 ViBench，專注於「功能正確性」與實作無關的測試。
  4. 支柱二：Online Eval，A/B 測試與 Telescope（將真實 Session 的 Trace 進行語意分群，揪出長尾 Bug）。
  5. 人機協作：自動化包辦 90% 的發現與修復，人類負責 10% 的高階品味與決策（假設選擇、發布核可）。

ROUND 2: DISSECTION | 血肉解剖

• 隱形假設：
  • 使用者是零基礎的知識工作者，不關心底層框架、語言或程式碼優雅度，只在乎「應用能不能跑起來」。
  • 傳統的程式碼覆蓋率與靜態分析在此場景無效。
  • 大語言模型的推理與長文本處理能力已達到一定水準（如 Opus 4.5），足以分析大量雜亂的線上 Trace 並進行準確歸類。
• 邊界條件：
  • A/B 測試結果極少是「純好或純壞」（例如效能下降但成本降低），需要人類產品哲學介入判斷。
  • Eval 的 Evaluator 必須對「實作細節」一無所知（Agnostic），只能從最終瀏覽器操作行為來判定成功與否。
  • Model 在編輯自己寫的程式碼（Slop-on-slop）時表現最差，代表 Agent 累積技術債的速度極快。

ROUND 3: SOUL | 靈魂提取

• 知識連結：
  • Site Reliability Engineering (SRE)：Telescope 的異常分群思維類似於 SRE 的錯誤預算與長尾異常偵測，但使用 LLM 取代了 Regex 與靜態日誌分析。
  • Test-Driven Development (TDD)：演講中強調「增加新功能前必須插入測試步驟」，驗證了 TDD 原則在 Agent 開發時代依然適用，且更為必要。
• 深層洞見：
  • Eval 不再是 QA 的工作，而是 Agent System 的核心控制迴路。
  • 自動化程度越高，人類的「品味（Taste）」與「產品哲學（Product Philosophy）」價值越被放大。你設定什麼樣的 Eval 標準（形塑要爬的山），決定了最終產品的樣貌。
• 行動呼籲：
  • Agent 開發者應盡早投資 A/B 測試基礎建設。
  • 如果半年前因 LLM 能力限制放棄了「線上 Trace 語意分析」，現在模型能力突破，應立刻重試。
  • 將 Eval 視為驅動系統進步的引擎，而非發布前的最後一道檢查。

Replit 如何規模化評測和持續改進 Vibe coding (Architectural Deep Dive)

前言/背景

Replit 的總裁兼 AI 負責人 Michele Catasta 在「Code with Claude」活動中分享了他們如何解決 Agent 開發中最棘手的問題：「在模型、Prompt、工具定義每天都在變動的高頻發布環境下，如何科學化地評估 Agent 是否真的滿足了使用者的自然語言需求？」本文深度解析 Replit 如何透過開源 ViBench 與內部 Telescope 系統，建構出自動發現、自動修復的持續評測架構。

章節詳細總結

1. 極端場景與傳統 Eval 的失效

Replit 面對的是最極端的 Vibe Coding 挑戰：使用者不提供框架、不寫測試，僅憑一句自然語言期望獲得一個能跑的應用（Greenfield development）。

• 為什麼 SWE-bench 不夠用：SWE-bench 與 HumanEval 的邏輯是「驗證 Patch 是否能通過既有測試庫」。但 Replit 的場景是從零開始，沒有既有測試庫。這導致傳統評測忽略了最核心的「功能正確性落差（Functional Correctness Gap）」。
• 架構轉換：評測必須從「評估程式碼是否正確修改」轉向「評估應用程式是否如預期運作」。

2. Eval 應是一條資料流 (A Stream)，而非分數 (A Score)

在基礎建設持續變動（Shifting grounds）下，單次評分的 Offline Eval 無法反映真實產品狀態。

• 核心架構決策：不讓 Eval 停留在「人類檢視分數」的階段，而是將其轉化為系統運作依賴的「資料流」。
• 兩根支柱 (Two Pillars)：
  1. 出貨前的守門員 (Offline Eval)：發布前的硬性 Benchmark 關卡。
  2. 出貨後的持續挖掘 (Online Eval)：基於線上真實流量（Trace）的 A/B 測試與語意探勘。

3. 第一支柱：端到端基準測試 ViBench (Offline)

為了解決功能正確性問題，Replit 開發並開源了 ViBench。

• 設計機制： 輸入 20 個來自真實情境的產品需求文件 (PRD)。由 Agent 從空 Repo 開始建立應用，完成後觸發自動化的 Evaluator。
• Implementation Agnostic 評估器： 由於不能限制使用者/Agent 使用何種語言或框架，Evaluator Agent 必須完全不知道實作細節。

  // 評估流程概念
  1. 讀取程式碼庫理解結構。
  2. 啟動 headless browser 指向部署的應用。
  3. 根據自然語言撰寫的測試計畫一步步執行 (例如：登入 -> 點擊按鈕)。
  4. 記錄所有步驟，任一步驟失敗即彙整生成評分報告。

• 五大評測情境 (Strategy Slots)：
  • Zero-to-One: PRD 到 MVP。
  • Vibe-on-Ref: 在既有正確實作上加功能。
  • Vibe-on-Vibe (Slop-on-slop): 在 Agent 自己生成的 MVP 上疊加功能。（目前所有模型表現最差的情境）
  • Parallel + Merge: 平行跑多個 Agent 任務後合併 (Agent 4 的架構)。
  • Decomposition: 大型 PRD 的自我拆解。

4. 第二支柱：線上 A/B 測試與 Telescope 語意分群 (Online)

每天收集數百萬條無腳本的真實 Session (Trace)，如何從中萃取價值？

• A/B 測試的殘酷真相：指標極少是單向的。例如 Agent 執行時間增加 7%，但 API 成本降低 8%，情緒指標波動不一。這時候需要依賴產品哲學與品味來決策。
• Telescope (Trace Clustering) 的自動化發現迴圈： 當出現只在特定條件發生（如 1% 機率發生）的長尾 Bug 時，Datadog 等傳統監控儀表板無法抓出。
  • 實作方式：
    1. 將每日的 Trace 摘要轉換為 Embedding。
    2. 按類型與語意進行分群 (Clustering)。
    3. 丟給 LLM 精準分類發生了什麼失敗。
    4. 每天晚上重新訓練群集，以驗證昨天的 PR 是否真的消滅了該問題的群集。
  • Cold-Start 案例：Agent 因環境設定過慢（冷啟動），過度急躁（eager to fix）而開始錯誤地嘗試修復環境本身。這類問題在日誌中長得都不一樣，只有透過語意分群才能發現其高頻發生的本質。

5. AI 工程師日常的自動化與人類的「品味」

Telescope 建立了一個 90% 自動化的迭代迴圈： 發現問題 (分群) -> Coding Agent 開 PR -> 跑 ViBench 試金石 -> A/B 測試 -> 出貨。 儘管如此，Catasta 點出了人類在架構中無法被取代的四大高階「品味 (Taste)」決策：

1. 假設選擇 (Hypothesis selection)：決定迴圈的運算資源該投入哪個長尾問題。
2. 實作架構 (Implementation architecture)。
3. Eval 策展 (Eval curation)：形塑 Agent 要爬的山（優化方向）。
4. 發布核可 (Launch approval)：最終決定權。

總結與結論

1. 從 TDD 到 Agent-TDD 是必經之路：模型在擴展自己撰寫的程式碼（Slop-on-slop）時表現極差。架構師的防禦性設計必須是「在每次功能迭代之間，強制插入自動化測試步驟」，避免地基崩塌。
2. 拋棄純基於 Regex 與日誌的長尾除錯：針對 Agent 的非確定性行為，傳統的日誌監控已不敷使用。應建立基於 Embedding 的語意分群管線，找出那些「語意相同但路徑不同」的系統缺陷。
3. Eval 的去耦合設計：確保你的 Evaluator 與系統實作（語言/框架）完全解耦 (Agnostic)。像 ViBench 一樣，透過黑箱式的瀏覽器自動化與行為驅動測試 (Behavioral Eval) 來驗證 Agent 的功能正確性。
4. 結合產品內的非技術訊號：排障不應只看 Trace。在設計 Eval 系統時，應將使用者的提示詞情緒（Sentiment）、報錯表單與 Datadog 基礎設施指標融合在同一個 Context 中送交 LLM 分析，能大幅提升 Bug 定位精準度。