📍 真實場景
阿凱，32 歲，一家 40 人電商公司的資深後端工程師，同時是團隊裡最常被點名審程式碼的人
公司全面導入 AI 寫程式代理後，他每天早上打開 GitHub，發現待審的合併請求（Pull Request）從 5 筆暴增到 12 筆，每一筆都有幾百行新程式碼。
😖 卡住的地方：老闆看到「程式碼產出量」上升 30%，期待這季功能上線速度加倍；但阿凱知道自己一天只有 8 小時，AI 寫得再快，他還是得一行一行確認這些程式碼不會把訂單系統弄壞。
💡 這課會用哈佛研究者分析 700 多家公司的真實數據，讓你看懂為什麼「寫得快」不等於「做得多」，以及怎麼用工程師的眼光找出真正的瓶頸。
🧭 這到底是什麼（白話版）
哈佛大學的研究者 Fiona Chen 與 James Stratton 做了一件很少人做過的事：不問工程師「你覺得 AI 有沒有幫上忙」，而是直接去看 700 多家軟體公司在導入 AI 前後的工作事件系統自動記錄下來的每一次工程師動作，例如提交程式碼、發出審查請求 資料。他們使用 Jellyfish 這家公司整理的資料，涵蓋 3 億筆工作事件、超過 70 萬名員工，時間從 2021 年一路到 2026 年 3 月。
研究把 AI 工具分成兩種。第一種是 AI 程式助理，像自動補全，程式主要還是人寫，AI 幫忙接下一句；第二種是 AI 程式代理（coding agent），你給它一個提示詞你用文字下給 AI 的指令 ，它就自己寫程式並送出。研究發現，導入代理之後，總程式碼行數增加約 30%，提交commit，把一批程式碼修改正式記錄進版本庫的動作 次數增加約 20%，合併請求Pull Request，寫程式的人說「我改好了，請別人檢查後再併進主程式」的申請單 增加約 23%。
但關鍵的結論是：公司在 Jira 這類議題管理工具用來記錄「要做哪些功能、修哪些錯誤」的待辦清單系統 裡的 Issue 與 Epic（也就是完整的軟體功能）完成率，在統計上沒有明顯變化。研究者也檢查過是不是大家改去做更小的任務，結果也沒有這種「組成轉移」。換句話說：程式碼變多了，但「做完的軟體功能」沒有變多。
原因藏在下游。文章引用研究的說法：寫程式階段省下的時間，被生產流程後面的限制「吸收」了——審查時間變長、合併請求更常需要修改、審查者留下更多評論。這就是工程裡所謂的瓶頸整條生產線中速度最慢的那一站，它決定整條線的總產量 ：前面再快，產量還是被最慢的一站卡住。
🎯 為什麼值得你花時間
「程式碼行數」是會騙人的指標 素材顯示，AI 代理讓程式碼行數、提交數、合併請求數全都上升，但功能完成率沒變。如果主管只看前三個數字，會以為團隊產能大增；真正該看的是「有多少功能真的做完上線」。
人工審查是新的瓶頸，而且會被放大 研究指出審查流程時間明顯變長、合併請求更常被要求修改、審查者留言更多。AI 讓「產生待審內容」的成本趨近於零，但「驗證內容是否正確」的成本仍然由人承擔，兩邊變得不平衡。
導入 AI 不一定能減少人力 研究結論是「幾乎沒有證據顯示公司因使用這些工具而提高軟體產出或減少雇用」。這對正在評估「買 AI 工具能不能省人」的團隊是直接的警訊：省下的是打字時間，不是整體交付時間。
⚙️ 它是怎麼運作的
1
提出需求（Issue） 產品經理或工程師在 Jira 之類的工具裡建立一個要完成的功能或修正，這是「軟體產出」真正被計算的單位。
▼
2
AI 代理寫出程式碼 代理依照提示快速產生大量程式碼並送出。研究中這一站的產量確實大幅上升：行數 +30%、提交 +20%。
▼
3
發出合併請求（PR） 程式碼被打包成一張審查單，等待別人檢查。PR 數量增加約 23%，代表審查者桌上的單子變多了。
▼
4
人工審查與來回修改 審查者要讀懂程式、找出錯誤、留下評論；作者再修改、再送審。研究發現這一站的時間變長、修改次數與評論數都增加。
▼
5
合併上線、Issue 結案 只有走完前面所有站，Issue 才算完成。因為第 4 站被卡住，最後一站的完成率沒有顯著提升。
導入 AI 程式代理後，各階段指標的變化（依文章所述研究結果）
階段 指標 變化 寫程式 程式碼總行數 約 +30% 寫程式 提交（commit）次數 約 +20% 送審 合併請求（PR）數量 約 +23% 審查 審查時間、需修改比例、評論數 皆增加（審查變長） 交付 Issue／Epic 解決率 無統計上顯著變化
🤔 這則沒有適合的實作——改用三個問題帶你想深
如果你是阿凱的主管，只能看一個數字來判斷 AI 工具有沒有真的幫到團隊，你會選「程式碼行數」「合併請求數」還是「Issue 完成率」？為什麼另外兩個容易誤導你？請用本課的流程（寫程式→送審→審查→上線）說明。
AI 讓「產生程式碼」的成本接近零，但「驗證程式碼」的成本沒有跟著降。請想一個你生活或工作中類似的情況（例如：用 AI 寫文章但仍要自己事實查核），說明瓶頸怎麼從「產生」移到「檢查」。
假設你想降低審查瓶頸，你會優先選擇哪一種做法：（A）限制每天能送出的 PR 數量、（B）要求 AI 產生的程式碼附上測試、（C）增加更多審查人力？請寫出你選的理由與它可能帶來的副作用。
🧠 工程思維透鏡（資深工程師看到的是什麼）
🔭 資深工程師看到「程式碼量 +30%」時，第一個會問什麼？
會問「這些程式碼是資產還是負債？」程式碼本身是需要維護、審查、測試的成本，不是產出。素材中行數增加了 30%，但功能完成率沒變，意味著單位功能背後的程式碼變多、審查負擔變重。工程上的取捨是：與其追求產生得多，不如追求用更少的程式碼解決同樣的問題。
🔭 為什麼優化「最快的那一站」對整體幾乎沒幫助？
這是限制理論（Theory of Constraints）的核心：系統產量由瓶頸決定。寫程式本來就不是最慢的一站，AI 把它再加速，只是讓前面堆出更長的待審佇列。研究所說的「效率提升被下游限制吸收」正是這個意思。設計理由是：要提升整體產量，必須投資在瓶頸（審查）上，而不是已經夠快的環節。
🔭 審查變慢是 AI 品質差，還是流程本身的問題？
兩者都有。素材提到寫程式的人本來就「知道不能盲信 AI 的程式碼」，所以需要花力氣審查；同時合併請求更常需要修改、審查者留言更多，顯示一次送來的內容更大、更難一眼看懂。工程上的取捨是：要嘛縮小每次送審的範圍、要嘛在送審前加入自動化檢查（測試、型別檢查、靜態分析），把「機器能判斷的事」從人身上拿走，把人力留給需要判斷力的部分。
🔭 這份研究的限制是什麼？我們該怎麼讀它的結論？
它是觀察性的「差異中的差異」迴歸分析，比較導入前後與不同公司之間的變化，並非隨機實驗，且 AI 導入時間是用實測使用量加上 GitHub 活動來推估的。所以結論適合說成「在這批公司、這段時期，未觀察到產出顯著提升」，而不是「AI 永遠無法提升產出」。工具會進化、流程也會調整，結論要隨證據更新。
📝 隨堂考（點選答案，立即回饋）
Q1. 根據這項研究，導入 AI 程式代理後，哪一項指標「沒有」出現統計上顯著的改變？
程式碼總行數
合併請求（PR）數量
Issue 與 Epic 的解決率
提交（commit）次數
✅ 行數約 +30%、提交約 +20%、PR 約 +23%，但 Jira 追蹤的 Issue 與 Epic 解決率沒有統計上顯著的變化，代表完整功能的產出沒有變多。
Q2. 文章中提到的「瓶頸」最主要出現在哪個環節？
AI 寫程式的速度
人工程式碼審查
電腦的運算效能
需求文件的撰寫
✅ 研究指出人工審查是瓶頸：審查時間變長、PR 更常需要修改、審查者留下更多評論，使寫程式階段的效率提升被下游吸收。
Q3. 研究者如何避免「大家只是改做比較小的任務」這個解釋？
訪問每位工程師的主觀感受
檢查 Issue 的大小與複雜度是否在導入 AI 前後出現組成轉移，結果沒有
只比較 AI 代理與 AI 助理兩種工具的價格
排除所有小型公司
✅ 素材提到研究者也沒有發現 Jira 追蹤的議題在大小或複雜度上有「組成轉移」，因此功能完成率不變不是因為任務變小。
Q4. 下列哪一種做法最符合「優化瓶頸」的想法？
再買一個更快的 AI 寫程式工具
要求 AI 每天多產生一倍的程式碼
在送審前加入自動化測試與檢查，減輕人工審查負擔
把提交次數當成績效指標
✅ 瓶頸在審查，所以應該降低審查的成本或負擔。自動化檢查能先擋掉機器可判斷的問題，讓人工審查聚焦在需要判斷力的部分。
🃏 翻牌記憶卡（先想答案，再點開對答）
這項研究的資料規模與時間範圍？點我翻面
約 3 億筆工作事件、70 萬名以上員工、700 多家軟體公司，時間為 2021 年至 2026 年 3 月，資料來自 Jellyfish。
AI 程式助理與 AI 程式代理的差別？點我翻面
助理主要是協助補全由人撰寫的程式；代理則是依照提示自主撰寫並送出程式碼。
導入 AI 代理後，程式碼產出面的三個變化數字？點我翻面
總行數約 +30%、提交約 +20%、合併請求約 +23%。
為什麼功能完成率沒有跟著提高？點我翻面
寫程式階段的效率被下游限制吸收：審查流程變長、PR 更常需要修改、審查者留下更多評論，人工審查成為瓶頸。
這個案例對「用 AI 省人力」的啟示？點我翻面
研究幾乎沒有找到公司因使用這些工具而提高軟體產出或減少雇用的證據，省下的是寫程式時間，不是整體交付時間。
ai-lecturer 教案工廠｜藍圖 flash-full-v1.0｜本頁零外部依賴，離線可開