借助代理式 AI，從 7 年縮短到 7 天

作者 Ghazi Triki 2026年8月12日 · 閱讀時間 4 分鐘

本文內容

如果您曾經盯著一張 COCOMO II 試算表，看著它預測一個您的團隊只用兩個 sprint 就交付的專案需要 33 個月，您一定明白問題所在：今天正式使用的每一個估算模型，都是在這樣的世界裡校準的：開發者親手敲下每一行程式碼、切換工作情境要付出代價，而行事曆在下午 5 點就停止。那樣的世界已經不存在了。我們最近從零開始開發了一套 286 KLOC、672 個檔案、包含多個子系統的應用程式，涵蓋協定層、資料層、渲染引擎與平台整合，並在 7 天 內完成可供測試的 Alpha 版本。完整的模型組合（COCOMO Basic／Intermediate／Post-Architecture、功能點、SLOC 基準、Putnam／SLIM）給出的中位數預測是 30.3 個月。生產力倍數的中位數：4,240 倍。即使是最保守的基準（複雜系統每位開發者每天 25 SLOC），也差了 1,433 倍。這些模型沒有錯，而是被用錯了地方。以下依序說明各模型的拆解結果、同一作者的實證校準，以及 2024 至 2026 年的隨機對照試驗（RCT）文獻，對於代理式 AI 在哪些情況下能縮短工期、哪些情況下不能，究竟說了些什麼。

讓估算失靈的專案

在 RIADVICE，我們最近開發了一套複雜、功能豐富的應用程式，屬於需要在分散式架構中協調多個子系統的那一類。它是一個原生的跨平台環境，以單一程式碼庫同時支援行動裝置與桌上型電腦，起因是市場需求要求一套全新的實作。程式碼庫本身就說明了規模：

286,662 SLOC（約 286 KLOC），分布於 672 個原始碼檔案
總變動量 1,329,399 行：新增 862,488 行，刪除 466,911 行
在 7 個實際開發日 內完成 700 次 commit，達到第一個可供測試的 Alpha 版本
完整國際化，支援數十種語系
多個彼此毫不相關的子系統，包括協定處理、資料管理、渲染與平台整合，全部為目標環境從零打造

這不是一層包裝，也不是換個外觀而已。這是一套從底層開始的原生實作，目的在滿足現有解決方案無法達成的市場需求。在寫下第一行程式碼之前，我就在專案中接上一套自訂的分析工具，隨著程式碼庫成長，持續以 業界標準軟體工作量估算模型的完整組合 進行評估。目標很單純：衡量傳統模型的預測，與 AI 輔助交付的實際成果之間有多大的落差。結果不是四捨五入的誤差，而是類別上的斷裂。

估算模型的預測與實際結果

這套工具會執行軟體工程文獻中所有主要的估算模型：COCOMO Basic（Organic、Semi-Detached、Embedded）、COCOMO Intermediate（Semi-Detached 與 Embedded，經調校）、COCOMO II Post-Architecture（經調校）、功能點、SLOC 生產力基準，以及 Putnam／SLIM，並使用原始文獻中公布的常數，依專案類型進行校準。

估算模型	預測工作量	預測工期	相較實際的加速倍數
COCOMO Basic（Organic）	913 人月	33.3 個月	2,282×
COCOMO Basic（Semi-Detached）	1,696 人月	33.7 個月	4,240×
COCOMO Basic（Embedded）	3,200 人月	33.1 個月	8,000×
COCOMO Intermediate（Semi-Det.，經調校）	1,259 人月	30.4 個月	3,148×
COCOMO Intermediate（Embedded，經調校）	2,376 人月	30.1 個月	5,940×
COCOMO II Post-Architecture（經調校）	1,703 人月	30.3 個月	4,257×
功能點（粗略估算）	17.9 人月	7.5 個月	45×
SLOC 生產力基準（每人每天 25 SLOC）	573 人月	573.3 個月	1,433×
Putnam／SLIM	略過（工期少於 30 天，T 的 4/3 次方發散）	不適用	不適用

所有模型的生產力倍數中位數為 4,240 倍。即使是最保守的模型，預測的交付時間也比實際情況長了大約 1,400 倍。最樂觀的功能點模型，仍然預測需要 7.5 個月，比實際的 7 天 長了 45 倍。依照這些模型，這個專案應該要花上 7 個月到 47 年 不等。而 Alpha 版本 7 天就可以開始測試了。

各模型之間的差距，從 50 倍到 8,000 倍

這些模型彼此並不一致。在同一個程式碼庫上，預測值從 17.9 到 3,200 人月不等，相差 178 倍。SEAA 2013 針對 COCOMO II、SEER-SEM、SLIM 與 TruePlanning 在 51 個真實專案上進行的基準評估，發現平均相對誤差（MMRE）高達 50% 至 100%。2023 年一項以 COCOMO NASA 資料集進行的評估，則發現 MMRE 接近 1.0，PRED(0.25) 為 0.0，也就是沒有任何一個專案的估算落在 25% 的誤差範圍內。這些模型從來就不是為 AI 輔助的專案而設計。但即使考量模型本身的不準確，落差之大，也告訴我們有些結構性的東西已經改變了。

關於代理式 AI 與開發者生產力，研究實際上怎麼說

4,240 倍是一個極端的數字，我不想過度渲染。全新專案的鷹架程式碼會灌高變動量，而 SLOC 本來就不是衡量價值的好指標。所以，讓我們來看看經過同儕審查的文獻。Copilot 類型的助理帶來的是有限但真實的提升。 Peng 等人（2023）發現，使用 AI 結對程式設計工具的開發者完成任務的速度 快了 55.8%（95% 信賴區間：21% 至 89%）。Microsoft、Accenture 與一家財星百大企業進行的 RCT（2025），是迄今規模最大的研究（n=4,867），發現 完成的任務數增加了 26%。Google 的內部 RCT（2024）發現任務耗時減少了約 21%。BIS 與 Ant Group 的實地實驗（2024）測得初階人員的 程式碼產出增加了 55%。誠實的總結是：在合適的任務上提升 1.26 至 1.56 倍。 很真實，但稱不上翻天覆地。代理式 AI 則處在完全不同的層級。 Cognition 在 2025 年對 Devin 的回顧中，公布了客戶的成果：ETL 遷移快 10 倍、Java 版本遷移快 14 倍、安全性修正快 20 倍。Nubank 在一項原本估計需要上千名工程師、耗時多年的數百萬行程式碼重構中，回報了 效率提升 12 倍、成本節省 20 倍。我們的這次移植正好落在這個範圍內：commit 分布圖顯示在 22:00、00:00 與 01:00 出現密集的高峰，這正是代理驅動工作階段的特徵。反面證據同樣真實。 Metr.org 在 2025 年的 RCT（16 位資深開發者，在成熟專案上執行 246 項任務）發現，AI 讓完成時間增加了 19%，也就是在熟悉的程式碼庫上，它反而 拖慢了 資深開發者。2026 年一項針對 807 個導入 AI 工具的 GitHub 儲存庫所做的差異中的差異（DiD）研究（He 等人，MSR ’26），發現速度只有「短暫」的提升，程式碼複雜度卻「持續」增加，進而導致長期的速度下滑。標題已經說明了一切：Speed at the Cost of Quality（以品質換取速度）。共識是：AI 在全新專案與結構化開發上幫助很大，在補全類任務上幫助有限，而在成熟的程式碼庫上則可能拖累速度。 品質負債是真實存在的。

模型為何失靈：三項結構性轉變

傳統模型中的成本驅動因子，沒有一項能設定成「開發者擁有一個永不休息、能將整個程式碼庫放進脈絡中的自主代理」。以下三項轉變讓工期曲線全面崩塌：

打字的瓶頸消失了。

模型假設工作量中有相當比例屬於機械性工作：樣板程式碼、鷹架、重複性的重構、在地化資源，以及其他結構化資料。在這次移植中，大部分的量都是高度規律的文字與接線程式碼，代理可以大量產生或轉換。至於手工撰寫的程式碼本身，例如鷹架、建構函式與平台黏合程式碼，現在也是成批產生，而不是一行一行敲出來。

切換情境的成本正在崩解。

人在協定層、資料層與渲染引擎之間切換時，每次都要付出載入脈絡的代價。一個已經讀完整個 672 個檔案儲存庫的代理，只需要付出一次。在這種規模的程式碼庫上，這樣的不對稱會迅速累積放大。

行事曆不再是瓶頸。

模型透過一條假設人類工作日的人力配置方程式，將人月換算成曆月。代理的工作階段可以通宵執行。commit 分布圖顯示從 07:00 到 01:00 持續有產出：每天 18 個活躍小時，而不是 8 個。

同一作者的實證校準

參數化模型之間的差距可達好幾個數量級，因此我也進行了跨專案的實證校準，在同一生態系的另外三個正式環境儲存庫上，比較我自己 在採用代理式 AI 工具之前與之後，每人每天的程式碼變動量：

專案	AI 之前每人每天變動量	AI 時代每人每天變動量	倍數
專案 A（負載平衡器）	673	2,056	3.1×
專案 B（報告服務）	239	2,127	8.9×
專案 C（處理服務）	1,322	982	0.7×
彙總（平均／中位數）	不適用	不適用	4.2× / 3.1×

同一位作者、同一個領域、真實的維護工作。實證倍數為 3 至 9 倍，遠比全新專案的 4,240 倍保守得多，也與已發表的代理式 AI 研究的上限一致。其中一個專案甚至 變慢了：提升的幅度取決於任務，並非放諸四海皆準。

這對專案規劃代表什麼

如果您仍在用未經校準的模型與每天 25 SLOC 的基準來估算軟體專案，在 AI 輔助的工作上，您的估算會差上一到三個數量級。以下是我們在 RIADVICE 的做法：

以自己的歷史資料校準。 比較您自己在使用與不使用 AI 時，每人每天的程式碼產出。這樣做成本更低、更誠實，得出的 3 至 9 倍範圍，也能在專案計畫中站得住腳。
把全新開發與維護分開看待。 代理式 AI 的倍數在全新專案與結構化開發上最大，在成熟程式碼庫的維護上最小（有時甚至為負）。不要對兩者套用同一個數字。
為品質負債編列預算。 AI 帶來的速度，伴隨著複雜度的持續增加。請規劃一段強化階段，並加以量測：每次發行時都追蹤循環複雜度，並執行複製貼上偵測。
估算整條曲線，而不只是前段。 速度提升 10 倍，卻讓缺陷密度加倍，並不是真正的 10 倍提升，而是以更長的穩定化收尾期為代價，把時程往前拉而已。

結論

一個所有估算模型都說需要 7 個月到 47 年的專案，在 7 天內就完成了可供測試的 Alpha 版本。4,240 倍的中位數倍數，不應該成為任何人的專案計畫。但它清楚顯示，壓縮 工作量 的同一股力量，也正在壓縮複雜軟體開發的工期。已發表的研究顯示，AI 帶來的效果從 1.26 倍的小幅推進 到 20 倍的大幅躍升 都有，而在成熟程式碼庫上確實存在 負報酬 的風險，也有可量測的品質代價。那些告訴我們這個專案需要數十年的模型，正是今天仍在企業估算試算表中使用的同一批模型。問題不在於代理式 AI 是否會改變專案工期，研究已經回答了這一點。問題在於，您的估算實務是否已經跟上這些證據。如果您的數字仍然來自一個以 COBOL 與組合語言校準的 1981 年模型，現在就該重新校準，或至少別再相信它印出來的時程表。