語言遞迴自我改進：在近 280 種語言中打磨程式碼智慧

本文中的數字反映發布當下（2026 年 5 月）的系統狀態。目前最新數字請參見我們的團隊頁面。

Maguyva 會從大約 280 種語言的原始碼中擷取符號、參照關係與依賴關係圖。每種語言都對應一套自訂的 tree-sitter 處理器 — 查詢、啟發式規則、邊界案例 — 而每個處理器都可能以自己獨特的方式微妙地出錯：方法呼叫被誤判為讀取、函式被歸屬到錯誤的外層範圍、或是一段根本不存在的關係。

這種問題無法靠人力逐一稽核。沒有任何團隊能讀完橫跨 280 種文法的擷取輸出，並揪出其中的錯誤邊。因此，真正有意思的問題不是「我們的擷取結果正確嗎」，而是「在這樣的規模下，你要如何發現它出錯了，同時不必讓人力介入每一個迴圈」。我們的答案是語言遞迴自我改進：一套由語言代理人驅動的品質迴圈，搭配擔任評審的 LLM，以及一條我們不斷重新學到的規則 — 綠燈不等於正確。

綠燈不等於正確

每種語言都有一套固定測試集，發布關卡會依五個面向為其評分 — 準確度、結構完整性、涵蓋度、品質與效能。唯有在固定測試集上精確率 ≥ 0.95、召回率 ≥ 0.99、F1 ≥ 0.97，且預期關係邊數至少達 20 筆以取得統計信心，該語言才會判為綠燈。低於此標準即為黃燈或紅燈，不予發布。

這道關卡是必要條件，卻不是充分條件。固定測試集是拿我們自己寫的測試案例來驗證，只涵蓋我們已經想到的情境。一個處理器可能在固定測試集上完美無瑕，卻在只出現於真實程式碼中的模式上出包 — 一個巨集慣用法、一個泛型繫結方法、一個沒人為它寫過測試案例的語言特性。綠燈只代表固定測試集通過，不代表真實程式碼庫能乾淨地被擷取。所以這套迴圈必須跳脫固定測試集，正視真實世界的狀況。

內層迴圈：抽查、評審、修正、驗證

核心迴圈一次處理一種語言：

        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  1. corpus run ── clone real-world repos, extract relationships   │
        │                                                          │
        ▼                                                          │
  2. spot-check 100 edges (seed 42, then seed 123 to cross-check)  │
        │                                                          │
        ▼                                                          │
  3. LLM judge classifies every sampled edge:                      │
        CORRECT · FALSE_POSITIVE · TYPE_ERROR ·                    │
        SCOPE_ERROR · METADATA_ERROR                               │
        │                                                          │
        ▼                                                          │
  4. fix ONE thing — handler .py, .scm query, or config           │
        │                                                          │
        ▼                                                          │
  5. re-validate — F1 + re-classify + manifest diff (no regressions)│
        │                                                          │
   better? ──no──► revert, try a different fix ────────────────────┤
        │ yes                                                       │
        ▼                                                           │
  6. promote the fix into fixtures (a permanent regression guard) ──┘

有幾個關鍵設計，讓這套機制真正發揮作用，而不是原地打轉。

評審者是代理人本身，不是一次 API 呼叫。 我們所謂的「LLM 擔任評審」，指的是語言代理人親自對照真實原始碼，逐一檢視每筆取樣的關係邊，並依固定的五類量規進行分類：這條邊是正確的、是誤判、關係正確但類型錯誤、歸屬到錯誤的範圍，還是攜帶了錯誤的中繼資料？這套量規正是整套機制的關鍵所在 — 在你知道「23% 錯誤率」究竟是真實缺陷還是評審誤判之前，這個數字毫無意義。

一次只修正一件事，然後證明它有效。 每次迭代只變更一項可編輯的資產，接著針對固定的測試機制重新執行，唯有 F1 分數提升、且重新分類結果變好時才保留這項變更；若沒有，就回復原狀。不做批次的臆測性修改，也不接受「應該會變好」這種說法。一項變更必須靠實績留下，否則就出局。而一旦修正真正站穩腳步，就會被納入固定測試集 — 讓它修正的錯誤再也無法悄悄重現。這一步「納入測試集」的動作，正是讓這套迴圈成為遞迴、而不只是重複的關鍵：每一輪都會強化下一輪據以驗證的基準。

我們不斷重新學到的教訓：指標會誇大問題

這裡有個陷阱，而我們就曾一頭栽進去。次要的語料庫指標 — 例如擷取出的目標有多少比例找不到可解析的符號、有多少符號看起來「孤立」等等 — 會大幅誇大問題的嚴重程度。這些多半是語言典範本身的產物，而不是真正的錯誤。

最清楚的例子是：llvm 曾一度顯示 73% 的「有來源卻無符號」比例，並因此被貼上「災難性」的標籤。我們深入追查後發現，真實準確度其實是 98.5%。那些「缺少的符號」幾乎全是合理的外部參照 — 呼叫標準函式庫、呼叫框架、或呼叫存在於程式碼庫之外的程式碼。這項指標量測的其實是該語言本身的特性，而不是處理器的缺陷。像 Zig、COBOL、Odin 這類語言都出現 65% 到 70% 的「孤立」比例，卻完全正確無誤 — COBOL 甚至沒有任何真實錯誤。

如果我們當初任由這些數字主導工作方向，恐怕會花上好幾週去「修正」原本就沒問題的處理器，同時忽略那些真正暗藏錯誤的語言。結論很直白：彙總指標充其量只是粗略的分診訊號。真正的品質訊號來自搭配關係邊分類的抽查 — 逐一檢視真實程式碼庫中的實際關係邊並加以判斷。用資料取代直覺沒錯，但前提是你得先知道哪些資料才是真話。

外層迴圈：靠艦隊，而不是靠一場馬拉松

若一次只處理一種語言，280 種語言跑下來將遙遙無期，因此內層迴圈外面還包了一層外層迴圈，讓多個語言得以平行處理。

   pick a wave of near-GREEN / high-error languages
        │
        ▼
   fan out 10–15 agents, each ISOLATED in its own git worktree,
   each grinding ONE language, committing to its own branch
        │
        ▼
   orchestrator integrates serially: file-scoped apply, then
   `manifest diff` — any cross-language regression blocks the batch
        │
        ▼
   gated push (reviewed and confirmed) ──► rotate to the next wave

每個代理人都在一個用完即丟的工作樹中作業，彼此互不干擾。協調器會逐一整合各代理人的修正，每一項都要通過完整清單的迴歸檢查：如果一項變更改善了自己的語言，卻悄悄弄壞了另外三種語言，就不會被採納。整合會先經過關卡把關、確認無誤，才會推送出去 — 迴歸關卡決定什麼是安全的，但要不要正式發布，仍由人來決定。之後，代理人池會輪替到下一批語言，整套流程再跑一輪。

仍不完美之處

評審者也可能出錯，而且出錯是有方向性的：脈絡資訊不足的代理人往往會誇大回報問題。曾有一批任務中，8 種語言被標記為 5% 到 20% 的錯誤率；深入檢視後，真正屬於該語言本身的錯誤只有一項 — 其餘都是評審者因未掌握該語言自身語意而產生的誤判（例如一行原始碼合理地產生多條關係邊、參數繫結被誤建模成賦值、以每個識別碼為單位建立參照關係的語言）。這正是我們以兩組不同種子取樣並交叉核對的原因，也是為什麼評審者與固定測試集之間出現分歧時，我們會將其視為最值得關注的訊號，而不是定論 — 有時候，出錯的其實是固定測試集本身。

我們對目標也很誠實。目標是零真實錯誤，一點都不打折 — 但「零」是我們一種語言接著一種語言持續打磨、朝其邁進的方向，而不是打勾了事的檢查項目。永遠會有下一個程式碼庫、帶著下一種慣用寫法。

靠實績贏得，而非憑空宣稱

Maguyva 為代理人所做的每一件事 — 找出一個符號、追蹤一項依賴關係、以附上程式碼佐證的方式回答問題 — 都仰賴底層擷取結果的正確性。橫跨 280 種語言，「正確」無法憑空宣稱，必須不斷對照真實程式碼贏得。這套迴圈正是我們贏得正確性的方式：一個自主的抽查與修正循環，對自己產出的指標抱持懷疑，證明每一項變更確實有效，並讓每一次修正都成為抵禦下一次迴歸的守衛。這件事並不光鮮亮麗，卻是讓我們能夠說出「我們支援你的語言」、而且說到做到的那份工夫。綠燈很容易，正確得靠實績贏得。