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

Canonical source: https://maguyva.ai/zh-hant/blog/autonomous-quality-loops-language-grind

License: text under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); code samples under [MIT-0](https://opensource.org/license/mit-0); the Maguyva name, logos, brand assets and other code are not covered. Details: [maguyva.ai/license](https://maguyva.ai/license).

Date: 2026-05-26 · Author: Maguyva Team

> 我們為近 280 種語言提供程式碼智慧支援，沒有人力能逐一手動稽核。因此我們打造了一套語言遞迴自我改進迴圈——抽查、LLM 擔任評審、修正單一問題、重新驗證——並以一支隔離代理艦隊持續執行，直到擷取結果真正正確，而不只是綠燈通過。

> *本文中的數字反映發布當下（2026 年 5 月）的系統狀態。目前最新數字請參見我們的[團隊頁面](/zh-hant/team)。*

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

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

## 綠燈不等於正確

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

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

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

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

```text
        ┌──────────────────────────────────────────────────────────┐
        │                                                          │
        ▼                                                          │
  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 種語言跑下來將遙遙無期，因此內層迴圈外面還包了一層外層迴圈，讓多個語言得以平行處理。

```text
   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 種語言，「正確」無法憑空宣稱，必須不斷對照真實程式碼*贏得*。這套迴圈正是我們贏得正確性的方式：一個自主的抽查與修正循環，對自己產出的指標抱持懷疑，證明每一項變更確實有效，並讓每一次修正都成為抵禦下一次迴歸的守衛。這件事並不光鮮亮麗，卻是讓我們能夠說出「我們支援你的語言」、而且說到做到的那份工夫。綠燈很容易，正確得靠實績贏得。