AI 輔助開發：如何用審查摩擦補足產出量指標

🌏 Read this article in English

如果團隊將 AI 輔助開發的優化目標設定為「最大化代碼產出」，系統的瓶頸是否轉移至審查階段，進而增加整體的維護成本與交付摩擦，取決於變更到達率與單次審查負荷的變化。在評估投資回報率（ROI）時，最直覺的選擇通常是「生成行數（LOC）」這類代理指標，這反映了工程管理的現實：容易量化的指標往往最先被採用。

一個待驗證的假說是：當生成式 AI 模型在缺乏全局上下文的前提下運作時，可能會傾向提供冗長、過度防禦或包含大量註解的解決方案。如果這個假設在特定工作流中成立，它雖然在表面上提升了產出體積，卻可能在實際工程管線中放大審查階段的驗證成本。

在討論產出時，需要明確區分生成行數（Generated LOC）、提交變更行數（Submitted Changed LOC）、淨新增行數（Net New LOC）與代碼流失率（Churn）。在實務上，要準確衡量影響，必須將 PR 或任務設為分析單位。一個待驗證的評估設計是：明確定義 AI 暴露（AI Exposure）的標記方式（例如透過 IDE 遙測或 PR 標籤），將其明確定義為處置變數或解釋變數。各結果指標應分別決定適當的分母；代碼行數（LOC）只能用於分層或敏感度分析，不得取代 AI／非 AI 分組。在評估設計上，必須明確區分三個層次：直接觀察指標趨勢屬於描述性監測；納入任務難度或風險分層等共變數進行配對，屬於混淆調整，這能估計條件關聯，但仍不足以識別因果效果；若要真正支持因果推論以估算 AI 導入的 ROI，則需要隨機對照實驗（RCT）或雙重差分（DiD）等嚴謹設計。若目前缺乏這些精細資料與實驗條件，以下推論將作為建立量測框架的先期假設。

根據 GitClear 針對 2020–2023 年間約 1.5 億行代碼變更的分析報告，代碼流失率（Churn，該報告定義分子為提交後兩週內被覆寫、還原或刪除的行數，分母為該次提交的總變更行數）呈現上升趨勢。這項數據僅作為同期訊號，不能作為 AI 使用與流失率增加的因果證據，但它提供了一個值得留意的視角：產出量並不等同於交付價值。假設代碼生成速率超過團隊的審查與整合吞吐量，系統的邊際效益就可能迅速遞減。

在軟體工程中，新增代碼會擴大維護面，這項投資是否值得，取決於交付價值與生命週期成本，而「閱讀並驗證代碼」的認知負載往往被低估。人類工程師在協作時，會基於團隊默契省略顯而易見的步驟；若 AI 在缺乏決策脈絡的前提下傾向於窮舉所有細節，這種無差別的完整性，在審查階段就可能轉化為高昂的摩擦成本。

Key Insight：摩擦成本與淨效益

Key Insight AI 輔助開發的生產力瓶頸是否會轉向交付摩擦（Delivery Friction），取決於系統條件。在實務上，必須統一容量、超載與瓶頸的定義：利用率接近 1 時，等待時間可能非線性增加；利用率大於或等於 1 表示佇列無法穩定消化；瓶頸則是限制端到端吞吐量的階段，不等同於單純超載。 到達率上升或審查時間增加皆可能造成超載，只要以下任一機制發生，審查階段就可能成為瓶頸（尚可能存在其他成因）：

1. 變更到達率上升：當提交變更的吞吐量超過團隊的審查與整合能力時。
2. 單次審查時間增加：當 AI 生成的代碼增加了閱讀、理解與驗證的複雜度時。 這兩個狀態的判準應獨立看待：當審查階段限制了端到端吞吐量時，即構成系統瓶頸；而當增量成本（如新增的摩擦與風險）超過增量交付價值時，系統的淨效益即轉為負值。兩者可能各自成立，不應混為一談。

為了解釋這個機制，我們可以建立一個概念模型：

Net Value = Delivery Value − (Generation Cost+Review Cost+Rework Cost+Operation Cost+Expected Risk Loss)

這是一個用於釐清取捨的框架。在實際量測前，需要將交付價值、生成、審查、返工，以及上線後的維運成本與風險期望損失換算成可比較的單位。為避免重複計算，必須為每個成本項指定互斥邊界，並盡可能先換算為共同單位（例如將工時乘上成本率換算為財務價值，否則應分列評估）。當部分指標無法合理換算為單一共同單位時，則應改用平衡計分卡（Scorecard）搭配品質護欄（Quality Guardrails）來綜合評估。其中，維運成本（Operation Cost）指已發生的日常維護代價，觀察窗內已經發生的逃逸缺陷、修復與事故成本全部歸入此項；而風險期望損失（Expected Risk Loss）只能用於根據缺陷率預測、但尚未發生的事件，並以機率加權計算。返工成本（Rework Cost）則專指上線前在 CI/CD 與審查階段被打回重寫的代價。

這裡有一個邏輯上的邊界需要釐清：審查時間（Review Cost）的增加必然提高成本端，但不必然使整體淨效益轉為負值。審查摩擦可以上升，只要 AI 帶來的交付價值增量（在統一單位下）或節省的開發時間，足以覆蓋增加的審查、返工與潛在風險成本，整體的淨效益依然為正。

這衍生出一個可操作的決策規則：評估 AI 輔助開發是否帶來實質改善，所有增量（Delta）必須一律相對同一基線（Baseline）計算，並統一完整公式中所有成本項的正負號，避免前後出現兩套定義。具體而言，節省的時間（Time Saved）只算作「生成成本（Generation Cost）」的降低（負增量）；而週期時間（Cycle Time）則作為獨立的交付結果指標。在計算整體增量淨效益時，必須確保單位一致（將工時乘上成本率轉換為財務單位）。當交付價值的增量（ΔDelivery Value），扣除生成、審查、返工、維運（ΔOperation Cost）與期望風險等所有成本項的總增量後，結果大於零時，才能判定為系統層面的淨效益提升。若無法統一單位，則不應強行加總，而是將收益與成本獨立檢視。

這可以形成一個可檢驗的情境假說：當單一模組的微小變更，因生成策略引發不成比例的附屬代碼，且伴隨高頻的整合重工時，其審查與返工成本可能會抵銷變更本身的價值。要驗證此假說，必須用相同基線與共同單位量測審查成本、返工成本及交付價值後，才能下結論。

以「交付摩擦」作為上位概念，可以將其拆解為三個子維度來評估系統平衡：

1. 審查工時：處理單一變更所需的人工時間與認知負載。
2. 整合摩擦：代碼進入主分支前遭遇的阻力與返工成本。
3. 品質風險：變更上線後可能引發的維護代價。

重新定義生產力：情境並存框架

要處理這個工程課題，需要將衡量標準從「產出體積」轉向「系統結果」。DevEx（開發者體驗）研究指出，認知負載與回饋迴圈是驅動生產力的底層機制。基於此底層機制，本文選用審查、缺陷、CI 三個維度作為操作指標：其中 CI 與審查等待時間對應回饋迴圈、主動審查工時對應認知負載，而缺陷則屬於品質護欄（需注意，這三項具體指標為本文選用，並非由 DevEx 來源直接驗證）。

必須明示的是，這三項指標只能監測「成本端」的摩擦，無法單獨回答生產力或 ROI。要評估完整的淨效益，必須在收益端增加效益量測（Benefit Measurement）：將「已接受的交付量（Accepted Delivery）」與「端到端週期時間（End-to-End Cycle Time）」明確標示為交付結果指標，不要將其稱為交付價值（Delivery Value）。收益端的交付價值，請另以驗收範圍、業務結果或價值加權交付量作為代理值。在評估時，若這些代理值能可靠換算，應先將其與各項成本統一為財務價值（工時需先乘上成本率），再計算整體增量淨效益；若無法可靠換算，則應保持分開呈現，將交付結果指標作為獨立參考，並搭配成本平衡計分卡（Scorecard）與品質護欄進行綜合判讀。

這種遷移需要團隊建立新的判準。在導入初期，首要任務是建立基線，而非追求完美的全局指標。先從摩擦最顯著的環節開始觀察，以下是具體的三維度測量框架：

1. 代碼審查時間（Review Effort）

這是衡量 AI 生成代碼「可理解性」的參考指標。如果 AI 生成代碼省下的撰寫時間，完全被增加的閱讀與理解成本抵消，那麼它的淨效益就會受到挑戰。

• 測量方法：建議分開審查前置時間（Review Lead Time）與實際審查工時（Active Review Effort）。PR 時間戳只能捕捉等待時間；實際操作中，通常依賴審查工具的活動紀錄或抽樣計時，才能準確評估後者。建議按變更規模正規化，以控制變因。
• 觀察方式：若引入 AI 後，平均審查時間顯著增加，這是一個需要進一步拆解的訊號。在確認這是生成策略帶來的摩擦之前，需要先排除任務難度提升、風險等級變化與審查者負載等混淆變數。

2. 逃逸缺陷相關指標（Escaped Defects）

這是衡量 AI 生成代碼「正確性」與「邊界處理能力」的參考指標。另可將「審查攔截率」列為輔助，觀察 AI 代碼是否在審查階段被有效驗證。

• 測量方法：建議統一觀察窗（例如：部署至生產環境後的 14 天內）。團隊可依據情境設立觀察指標，但缺陷的衡量不能只看數量，必須依據實際修復成本與嚴重度進行加權。單純計算「逃逸缺陷數」容易失真，主指標可採用每個已接受交付單位、任務、PR 或價值加權範圍的期望缺陷損失。變更行數僅用於規模分層或敏感度分析，避免以增加代碼產出稀釋缺陷密度。需要確保有明確的任務標記，以建立可比較的基線。
• 觀察方式：比較 AI 生成代碼與既有基線前，需要預先設定非劣性界值、所需樣本量與嚴重度護欄，不能以「未達統計顯著差異」代替可接受的等效判斷。一般缺陷應以增量期望損失納入淨效益；重大缺陷則另設不可跨越的品質門檻。需注意樣本量與發現能力的變化，比例分母失真會影響判斷準確度。

3. 首次 CI 成功率（First-Pass CI Success Rate）

這是衡量 AI 生成代碼「整合順暢度」的代理指標。指的是以單一拉取請求（PR）為計算單位，AI 輔助變更首次推送後，通過必要檢查（Linter, Unit Tests, Build）的成功率（分子為首次即通過所有檢查的 PR 數量，分母為總 PR 數量）。

• 測量方法：追蹤該分析單位首次觸發並通過自動化測試的比例，以及後續修補所需的平均次數。需同時記錄 flaky tests、基礎設施異常與檢查規則變動等混淆因素。在進行 AI 與非 AI 變更的比較時，加入相同工作類型、規模與風險分層的配對僅屬於混淆調整；若要支持因果推論，需依賴隨機分派或嚴謹的準實驗設計。若實務上做不到，必須明示團隊只能進行描述性監測，觀察同期變化訊號，不能據此估算 AI 導入的因果 ROI。
• 觀察方式：若該指標低於基線，通常表示生成的代碼與現有系統架構存在衝突，或 CI 環境本身具備可優化的地方。代碼行數與整合順暢度之間沒有絕對的線性關係，不能作為反向指標。

邊界與風險：當指標邊際效益遞減時

任何衡量標準都有其適用邊界。以產出字數為核心的指標框架，在以下情境中特別容易出現邊際效益遞減：

1. 複雜邏輯開發：在涉及核心業務邏輯或演算法優化時，代碼行數與任務難度之間缺乏穩定單調關係。解決一個困難的架構瓶頸，可能只需要改動十幾行代碼，此時產出量不足以單獨或可靠反映交付價值。
2. 系統重構與維護：重構旨在改善內部結構且維持外部行為，其結果可能增加也可能減少代碼量（LOC）。如果以產出量為指標，系統誘因會傾向於保留舊代碼而非收斂它。評估重構的準則應是可維護性、耦合度與風險的降低，而非單純的行數增減。
3. 跨邊界整合：當 AI 生成的代碼需要與外部系統互動時，介面定義與錯誤處理的複雜度遠高於內部邏輯，此時驗證成本會顯著上升。

衡量標準必須與工作性質相匹配。對於重複性、模式化的任務，產出量仍可作為輔助指標；但對於創造性、複雜性的任務，結果導向的指標與摩擦成本的控制更為重要。

關於 LLM 模型的進化，一個常見的假說是：它們生成的代碼在語法上已具備高度正確性，但若缺乏深層邏輯驗證，仍可能隱藏未被察覺的邊界條件。如果這個趨勢在特定團隊與工作流中成立，這意味著對於這些特定任務，審查的重點可能正從「語法正確性」轉移到「邏輯完整性與架構對齊」。

這是一個工程挑戰，因為邏輯完整性的檢查需要更深層的領域知識。在此條件下，工程師在這些任務中的角色，可能需要從單純的「代碼撰寫者」擴展為「系統架構師」和「質量守門員」。精準實現依然是紮實的功底，同時增加了架構判斷與品質驗證的責任。

導入順序：建立情境化的評估框架

面對這個轉變，團隊可以採取漸進改善的策略。

首先，建立基線。在全面引入 AI 輔助之前，記錄系統現有的審查前置時間、逃逸率與 CI 成功率。缺乏基線，後續的效能評估將失去客觀的判準。

其次，釐清工作流在系統中的邊界。將任務區分為「生成密集型」（如測試腳本、API 骨架）與「思考密集型」（如架構設計、核心邏輯）。對於前者，產出量可作為輔助指標；對於後者，架構品質的權重遠大於產出量。先從生成密集型的任務開始觀察摩擦成本。

最後，動態調權。不同系統的工作流具備不同特性，單一指標無法涵蓋所有情境。必須注意的是，動態調權只能用於決策排序，不得用來跨單位直接加總。若要建立綜合分數，必須先定義正規化方式、權重來源及敏感度分析；否則應保持各指標分開呈現。將「審查摩擦」納入常規的量測週期中，透過量化數據與團隊在審查過程中的質性回饋進行交叉驗證。

系統思維的延伸

AI 提供了一個新的機制，讓團隊能夠以不同的成本結構達成工程目標。當目光從「產出字數」轉向「處理需求的效率」時，團隊可以透過自身基線與審查、缺陷、CI 三個維度，驗證生產力是否出現實質改善。在特定工作流中，對系統邊界的理解與風險控制可能是影響改善幅度的機制，但不能據此推定為已確立的普遍因果。

市場訊號尚未完全明朗。與其在急於證明價值的壓力下最大化產出指標，不如先建立屬於自身系統的量測基線。團隊的邊際時間，是流向了代碼生成，還是流向了需求理解與架構確認？

這是一個值得思考的方向。你想建立哪一種衡量系統？數據說了什麼，你自己判斷。

Sources

• Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality — 分析 2020–2023 年代碼流失率的同期變化。
• DevEx: What Actually Drives Productivity — 探討認知負載與回饋迴圈對開發者體驗的影響。