---
title: "關於Bun在全量重構中的經驗"
date: "2026-08"
category: "ai運用"
tags: ["ai運用"]
description: "我之前提到過 基於過程的質量控制 ，其實從 How Anthropic runs large-scale code migrations with Claude Code | Claude by..."
source: "https://enriquemark.com/zh-hant/posts/%E5%85%B3%E4%BA%8EBun%E5%9C%A8%E5%85%A8%E9%87%8F%E9%87%8D%E6%9E%84%E4%B8%AD%E7%9A%84%E7%BB%8F%E9%AA%8C"
---

我之前提到過 [基於過程的質量控制](/zh-hant/posts/基于过程的质量控制) ，其實從 [How Anthropic runs large-scale code migrations with Claude Code | Claude by Anthropic](https://claude.com/blog/ai-code-migration?utm_content=inline_link&utm_source=it&utm_medium=email&utm_campaign=2026_Q2_SS_MKTG_Dev_Newsletter_JULY&utm_term=claude_code&utm_campaignId=19258434) 這篇文章中也能看到相似的地方，他們對整個重構運作的核心強調點即是「過程」。

>The core insight is that you don’t fix the code. **You fix the process (loop) that produced the code**.

不要專注於修復程式碼，而是專注於修復過程（迴圈）。這點可以說是證明了我目前正在做的——至少我始終認為這就是未來的正確方向。隨著程式碼數量的膨脹，想要依靠純粹的人工去保持短期內進行的百萬級程式碼遷移的質量，是基本不可能的。

他們對遷移劃分了以下的步驟：

先建立**可驗證**的、嚴格的退出標準，測試、判別器。皆為保證程式碼在遷移之後還能確保其與之前的一致性——機械化乃至是形式化的可驗證性測試是唯一的辦法。甚至為了這一步可能要單獨製作一個遷移所用的測試框架。

然後確立可迭代完善的規則手冊、依賴關係圖、定義明確的目標。這一步的關鍵點在於確保遷移的過程中不發生漂移，尤其是關鍵的架構決策和依賴結構，以及當前距離結束還有多遠——這一步就和第一步聯動了。

設立以懷疑為直接目的的審查員agent，對抗性的審查——這就和我之前所做的一樣。但不同的地方是他們設定了兩個以上，獨立且交叉的審閱，當兩者發生矛盾時還有第三審閱者出場。這一步顯然是極其耗費token的，但對抗卻是穩健性在非機械化測試外的必要保證，這是能最好模擬人類的方式。到底要設定幾個我覺得取決於專案的重要度和規模，同時還有預算限制。

對「規則本身」進行壓測。這個做法我覺得很值得學習。他們在大型遷移之前會先做試點，去實際跑一次規則，然後觀察可能出現的問題。不夠這裡分兩種情況，一種是結構遷移形式的測試，這種的核心點是結構不變但是要換語言，所以觀察規則的模式是跑完之後看是否有維持結構上的不變，可以人工來檢查。但如果並非是此種遷移，官方推薦的做法就是「對抗性審查」，同時用e2e測試來保證。我覺得這裡的關鍵還是行為和特徵是否固定，因為後者這種典型的情況就是遷移的時候可能會順便進行大規模重構，所以不能只是觀察結構是否改變，因此用e2e測試來固定行為和特徵就很關鍵了，但是單測可能就會因為結構的改變而作廢。核心的關鍵點是保證輸入、輸出來保證（如果原先有副作用、且這個副作用還是關鍵功能的話，這種設計不良的結構一旦改變，大機率會在e2e上出錯）。

接下來就是實際開始跑loop了，實施-審閱-修復的迴圈結構。這個地方的整個workflow應該是機械化的，就是純粹的定義好就開始執行——如此才能最小化成本。而且很多工不見得要用最好的模型，小模型顯然在執行速度和成本上都有優勢。而根據規模的不同，這一步的後半部分還可以單獨拆分出來——構建、冒煙測試、審閱、修復。他們在這裡比較有意思的是構建了一個序列化的批次執行測試的守護程序，可以防止一堆子agent重複執行全量測試帶來的成本，先聚集測試需求，然後集中在一次性執行中解決這些需求，併發回結果。對大規模軟體來說這個確實很重要，否則每個子agent寫完都要跑三十分鐘測問題，那時間成本會被拉長到十數倍。

整個過程中他們一直很強調「過程」，即不要過度關注於個別故障，而是保持一個穩健執行的過程。而程式碼審查應當是對抗性的，驗證應當是機械化的——也印證了我之前在 [關於程式碼閱讀](/zh-hant/posts/关于代码阅读) 裡面說的，可檢驗的反饋對agent開發的質量控制來說至關重要。尤其是當前RL為主流的訓練會不斷獎勵agent去滿足這些可驗證的結果。當然這也導致一個問題，就是不擇手段的完成問題，以至於搞出各種表面完成但實際上可能破壞總體任務結果的操作，這時候就需要對抗agent。對後者來說，他的任務就變成了檢查，這同樣是一個可檢驗的目標。一個負責構建，一個負責攻擊，兩者進入一個迴圈時，反饋平衡才能建立起來。

而最終，我們對整體結果的評估和驗收也並非是通過「看程式碼」來實現的。對大型系統的重構來說，一行行看程式碼基本不可能，也不現實。但是驗收的標準卻可以很直接，那就是「檢視迴圈運作的最終結果」。功能正常只是基本，核心點是——我重構最初的目的到底是什麼？比如bun的目的就是記憶體洩漏，那洩露成功降低就是重構是否有效的黃金標準。如果你的目的是效能，顯然效能減少了多少直接表明了這次重構的收益如何。因此，驗收標準取決於最初的目的，但無論如何，確保功能都是首要前提。

一百萬行的重構，全程只需要1個人+11天，這是一個前AI時代難以想像的速度。當然，我覺得更加穩妥的方式可能還是採用 [絞殺榕模式](/zh-hant/posts/絞殺榕模式)，用逐步替代、緩步上線的方法去完成整體遷移。bun畢竟有取之不竭的token和最先進的模型，但對於一般的公司來說，我們都不具備他們的條件，過於激進的進行全量重構可能導致未預料的問題。

但是，時代仍然是變了。誠如文章中所說，重構至少不再是一個決定生死存亡的決策——這一點顯然也在提醒決策者。哪怕是同樣的行為，也無法再用過去的眼光等同看待。如果重構帶來的收益足夠高，那麼重構就應該是最佳選擇。剩下的區別只在於採用什麼模式去穩妥、健壯的重構而已。