因為軟體專案的時間，多半不是花在寫程式，而是花在需求確認、設計、審查、測試與交接的等待上。AI 縮短了寫程式的時間，瓶頸就會移到其他環節：審查要讀更多程式碼，需求不清楚的地方更早被暴露，交接的次數並沒有因此變少。公開的研究資料也顯示，個人寫得更快，不等於組織交付得更快。這篇文章先說明傳統流程慢在哪裡、人多為什麼更慢，再對照研究資料，最後提供找出自己專案瓶頸的方法。
為什麼程式寫得更快，專案不一定更快？
軟體專案的總時間包含需求確認、設計、審查、測試與交接的等待；AI 加快寫程式後，瓶頸常移到審查與驗證，整體交付不一定變快。
DORA（DevOps Research and Assessment）2025 年的報告說明：「AI 的主要角色是放大器，放大組織既有的強項與弱點」（DORA，2025 年）。流程順暢的組織，AI 會讓它更快；交接與審查本來就卡的組織，AI 會讓卡點更明顯。
這和書稿的一個觀察一致：真正拖慢速度的，往往不是工作本身，而是流程中的瓶頸。
傳統開發流程慢在哪裡？
傳統開發把需求、設計、開發、測試與維運交給不同角色，每次交接都有等待與轉譯；各段都準時完成，整體仍可能延誤。
書稿把傳統團隊分成三個階段：需求探索與設計（PM、商業分析、UI／UX 設計師）、工程開發與測試（系統架構師、後端、前端、資料庫、QA），以及維運與成長（維運人員、資料科學家）。分工的原因是軟體風險高，任何一個錯誤都可能造成金流損失、資料外洩或營運中斷，所以需要多重把關。
代價是每個角色只看到自己的一段。書稿舉了一個典型情境：業務發現客戶需要新的報表功能，需求先寫成簡報交給企劃整理，排入需求會議，再交設計畫流程與草圖，工程評估可行性與時程，開發完成後送 QA，發現邏輯與原需求理解不同而退回，修改後還要送資安或維運審核。全部走完，常是數週甚至數月，而這時客戶可能又有新的需求，流程要重新排隊。
上圖是書稿的示意，圖中的時間（例如提案與排會議耗時一週）是說明用的舉例，不是量測資料。重點是測試退回開發的那條回頭箭頭：需求在轉譯過程中走樣，到最後階段才被發現，只能回頭重做。
上圖說明局部最佳化不等於整體效率：業務、設計、開發、測試四個部門都準時交付，最終專案仍可能延誤。書稿把這個現象連結到《鳳凰專案》一書的觀點，也就是真正拖慢速度的是流程中的瓶頸，不是單一部門的努力程度。
人越多為什麼越慢？溝通線路是平方成長，不是指數成長
團隊溝通線路數是 n(n−1)/2，隨人數平方成長；3 人有 3 條、10 人有 45 條、20 人有 190 條，所以新增人力常讓延誤的專案更慢。
布魯克斯法則（Brooks's Law）出自 Fred Brooks 1975 年的《人月神話》：「往已經延遲的軟體專案增加人力，只會讓它更延遲。」（Martin Fowler 文章引述：Adding manpower to a late software project makes it later）新加入的人要花時間上手，既有成員要分心教，而且複雜的工作無法完全切開，成員之間仍然要溝通。
| 團隊人數 n | 兩兩溝通線路 n(n−1)/2 |
|---|---|
| 3 | 3 |
| 10 | 45 |
| 20 | 190 |
| 50 | 1,225 |
人數從 10 增加到 20，增加一倍，溝通線路從 45 條增加到 190 條，是四倍多。口語常說這是「指數成長」，Fowler 的文章也這樣寫，嚴格來說是平方量級，成長沒有指數那麼快，但已足以讓協調成本超過新增人力的產出。
要注意這個公式假設團隊裡每個人都要和所有人溝通。實際團隊常用分組、文件與流程縮減需要直接溝通的對象，所以它描述的是上限，不是每個組織的實況。不能用它推論某一家公司的具體人數與運作方式。
AI 能縮短哪些等待？
AI 讓任何角色都能在數小時內做出可操作的原型，把文件與會議的轉譯改成看得到、摸得到的成品，縮短需求確認的來回。
書稿的論點是，過去只有少數同時具備產品思維、技術能力與決策視野的全才，才能在小團隊裡讓決策與執行同步；生成式 AI 讓更多人能做到一部分。例如業務與客戶談完後，過去要寫需求文件、排入開發會議、等工程師實作，現在可以在數小時內用 AI 做出簡單原型，直接給客戶確認方向。這種「先驗證、再投入」的做法，能降低做錯方向的成本。
不過，這縮短的是「需求確認」這一段，原型要變成正式系統，仍然要經過審查、測試與上線。後面的資料說明為什麼這一段反而可能變成新的瓶頸。
研究資料怎麼說？AI 真的讓開發變快了嗎？
現有資料顯示，AI 的效果因情境而異：METR 的實驗未能證實一致的加速，Faros 與 DORA 的資料則顯示個人產出增加，但審查等下游環節吸收了大部分效益。
| 資料來源 | 研究設計 | 主要發現 | 限制 |
|---|---|---|---|
| METR（Model Evaluation and Threat Research，AI 模型評測研究機構），2025 年 7 月 | 16 位資深開源開發者，在自己熟悉的專案完成 246 個任務，隨機決定可否使用 AI | 使用 AI 的任務多花 19% 時間；開發者事前預期快 24%，事後仍認為快了 20% | 樣本小，限於早期 2025 年的工具與熟悉的專案，不代表其他情境 |
| METR，2026 年 2 月 | 後續研究：原研究的 10 位開發者加上 47 位新招募者 | 原開發者估計時間減少 18%（信賴區間 −38% 到 +9%）；新招募者減少 4%（−15% 到 +9%）；兩者區間都包含零 | METR 自己說資料不可靠：愈來愈多開發者不願在沒有 AI 時工作，造成選擇偏誤，正在重新設計研究 |
| Faros AI，2025 年 7 月 | 超過 10,000 位開發者、1,255 個團隊的工作紀錄 | 高度採用 AI 的團隊多完成 21% 任務、多合併 98% 的 PR（Pull Request，程式碼合併請求）；PR 審查時間增加 91%、PR 平均大小增加 154%、每位開發者的 bug 增加 9%；公司層級沒有顯著的改善 | 為軟體工程分析廠商自家資料；是相關性，不是因果 |
| DORA，2025 年 | 年度軟體交付研究 | AI 是放大器，放大組織既有的強項與弱點 | 本文只引用官方頁面的「放大器」一句 |
兩個 METR 結果需要一起看。2025 年的實驗發現變慢，2026 年的後續研究估計變快，但 METR 明確表示後者因選擇偏誤，只能算非常弱的證據，也說開發者現在可能比 2025 年初更能受惠於 AI。因此兩個數字都不應被當成「AI 讓開發變快（或變慢）」的結論。
Faros 的資料則指出一個具體的移動方式：寫的人多產出了，PR 變多、變大，審查的人要花更多時間，最後在公司層級看不到改善。這與本文開頭的判斷一致，也與書稿「AI 讓交接成本下降」的樂觀敘述需要平衡：交接的形式可能改變，但等待並不會自動消失。
怎麼找出自己專案的瓶頸？
把一項需求從提出到上線的每一段，分開記錄實際動手時間與等待時間，再數交接次數與審查排隊，通常能找到真正卡住的環節。
下面是我的整理建議，不是書稿或研究的方法。
| 要記錄的項目 | 怎麼記 | 看出什麼 |
|---|---|---|
| 每一段的動手時間 | 實際有人在做這件事的時數 | 工作本身多久 |
| 每一段的等待時間 | 完成後到下一個人開始的間隔 | 最大的排隊在哪 |
| 交接次數 | 一項需求經過幾個人或部門 | 需求被轉譯的次數 |
| 退回次數 | 被測試、審查或客戶退回幾次 | 需求是否在上游沒講清楚 |
| 審查等待 | 程式碼或文件在審查者手上多久 | AI 增加產出後是否塞在審查 |
先挑一項最近完成的需求，回頭填這張表，不需要工具。若發現等待時間遠大於動手時間，加人或加快寫程式的速度都不會有明顯效果，應該先處理最長的那一段等待。導入 AI 工具之後，用同一張表重新記錄，才能知道瓶頸有沒有移動。
常見問題
AI 寫程式很快，為什麼專案進度還是很慢？
因為專案時間包含需求確認、審查、測試與交接的等待。AI 加快寫程式後，瓶頸常移到審查與驗證。Faros 2025 年的資料顯示，高度採用 AI 的團隊 PR 審查時間增加 91%。
團隊人數增加，溝通成本是指數成長嗎？
不是，嚴格來說是平方成長。兩兩溝通線路數是 n(n−1)/2，20 人有 190 條，但這個公式假設每個人都要和所有人溝通，實際團隊會用分組與文件縮減。
布魯克斯法則是什麼意思？
Fred Brooks 在 1975 年的《人月神話》中指出，往已經延遲的軟體專案增加人力，只會讓它更延遲。原因包括新人上手的成本、教學占用既有成員時間，以及溝通線路增加。
METR 的研究證明 AI 讓開發者變慢嗎？
不能這樣解讀。2025 年的實驗在特定情境下測到慢 19%，但樣本只有 16 人。2026 年的後續研究估計變快，卻因選擇偏誤被 METR 自己評為不可靠。
要怎麼知道自己專案的瓶頸在哪？
挑一項最近完成的需求，記錄每一段的動手時間與等待時間、交接次數與退回次數。等待時間最長的那一段，通常就是優先處理的瓶頸。
資料來源與說明
流程與組織部分整理自書稿第三章。研究資料引自下列來源，數字與限制以原文為準；Faros 為廠商自家資料。
參考資料
- METR，〈Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity〉，2025 年 7 月 10 日，存取日期：2026 年 10 月 19 日。
- METR，〈We are Changing our Developer Productivity Experiment Design〉，2026 年 2 月 24 日，存取日期：2026 年 10 月 19 日。
- Faros AI，〈The AI Productivity Paradox Report 2025〉，2025 年 7 月 23 日，存取日期：2026 年 10 月 19 日。
- DORA，〈State of AI-assisted Software Development 2025〉，發布日期不明，存取日期：2026 年 10 月 19 日。
- Martin Fowler，〈Mythical Man-Month〉，頁面標示 2026 年 5 月 5 日，存取日期：2026 年 10 月 19 日。
- Wikipedia，〈Brooks's law〉，現行頁面，存取日期：2026 年 10 月 19 日；原書：Frederick P. Brooks Jr.，《The Mythical Man-Month》，Addison-Wesley，1975 年。
延伸閱讀
- AI 時代，為什麼懂工作流程的人也能參與系統開發？：流程需要有人定義與驗收，哪些人適合承擔。
- 社工先做出原型，再交工程師整合：AI 如何改善需求溝通？：用原型取代文件轉譯的實際做法。
- AI 一天寫完工具，為什麼上線卻卡了近一個月？：程式寫完之後，上線環節的等待。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19