為什麼沒有團隊主管只承諾修 Bug？
AI 能幫你寫程式碼，卻沒人給你修 Bug 的動機
前言
各位訂閱者，上週我讀到一位開發者分享的經歷。銀行 App 在付款確認畫面要求了三次人臉辨識，而突然彈出的 Slack 視窗搶走了焦點，結果他正在終端機輸入的命令被發到了群組聊天室。冰箱的保固維修申請填完了漫長的表單，最後一步卻失敗了。汽車的資訊娛樂系統在更新後，行駛途中會重新啟動。
他補充的一個細節讓我印象深刻。幾個月前，重新設計該車作業系統的團隊 PM 在 LinkedIn 上發了一篇自賀的貼文，說他們完成了很棒的成果。而每天與這款產品較勁的使用者，會不斷想起那篇貼文。
製造方的自賀與使用方的切身感受，差距大到這個程度，並不常見。先說結論吧。AI 在很大程度上解決了「程式碼寫得不够快」的問題。但「修好 Bug 卻沒人給獎勵」這個問題，它一點都沒碰。工具越好，差距反而越大。
產出量確實增加了
先說清楚一點。這篇文章不是在講「AI 讓一切都變差了」。速度確實變快了。
Google DORA 團隊對全球約 5,000 名技術人員進行的 2025 年報告顯示，受訪者中 **90%** 在工作中使用 AI，每日使用時間中位數為 2 小時。與 2024 年的調查不同，AI 採用度越高，軟體交付產出量與產品績效越呈正相關。這意味著團隊正在學習如何、在什麼地方使用這些工具。
同方向的個別數據也有。分析程式碼變更歷史的 GitClear 在 2026 年 1 月發布的報告顯示，AI 使用最多的開發者群體產出了比非使用者多 4～10 倍的成果。不過這裡有一個誠實的註腳。這部分差距相當大程度來自 AI 之前就存在的個人能力差異，而將同一個人與自己的過去相比，速度提升約為 25%。與其說 AI 造就了優秀的人，不如說是本來就優秀的人先拿起了 AI。
問題在於同一份 DORA 報告中並列的另一個結果。AI 採用度越高，部署不穩定性1 也越高。這意味著因故障而產生的非計劃性部署增加了。DORA 這樣總結這個組合：AI 是一個放大器。它既放大了運作良好組織的優勢，也同樣放大了運作不佳組織的缺陷。
消失的不是程式碼，而是習慣
那麼，什麼正在被放大呢？GitClear 在 2026 年發布的後續研究相當具體地指出了這一點。這份資料追蹤了 2023 年到 2026 年間 6 億 2,300 萬筆程式碼變更，分為八個訊號。方向高度一致。
最引人注目的是重構2的消失。在所有變更行中，「被移動的程式碼」——也就是整理和重新佈局既有程式碼的比例——從 2022 年的 21% 降到了 2026 年目前的 **3.8%**。同期，複製貼上的程式碼比例從 9.4% 上升到了 15.7%。2022 年時，開發者選擇整理的頻率是複製貼上的兩倍，現在則反過來，複製貼上領先約 5 倍。這不只是偏好反轉，而是方向整體改變了。
其他數字也在講同一個故事。五行以上完全重複的區塊比 2023 年增加了 81%，創下觀測以來最高紀錄。新寫的程式碼呼叫既有程式碼中其他函式的頻率下降了 35%。這意味著新程式碼沒有與既有程式碼庫產生關聯，而是孤立在獨立的檔案中。重新開啟一年以上未動過的舊程式碼進行整理或淘汰的工作比例，從 1.7% 降到了 0.46%，下降了 74%。
為什麼這是個問題，想像一個重複區塊就明白了。如果五行的區塊散落在十個地方，修其中一個的人就自動承擔了找出其餘九個並判斷「這裡是不是也要一起改」的義務。甚至包括自己不知道的檔案和不知道的业务領域。今天省下的 30 秒，三年後由某人分半天來償還。
GitClear 將這種狀態稱為「可維護性差距」。報告中這樣總結核心：問題不是 AI 寫了壞程式碼，而是目前的預設工作流程被設計成只產出一條正常路徑、一個通過的測試、一張關閉的工單。看得見、能立即關閉的有獎勵，看不見、被推後的則默默累積成本。
但為什麼沒人修呢
這裡才是真正的問題。工具已經變好了，為什麼沒人償還這些技術債呢？前面引用的那位開發者用一句假想的發表詞寫出了答案。
「本季度不推出新功能，也沒有重新設計計劃。我們只專注於修 Bug。」
這句話能真正被放上季度計劃簡報的組織有多少？我幾乎沒見過。原因很簡單。新功能有演示、有可以講的故事、有績效評估可以用的措辭。穩定化成功時，表現形式是「什麼事都沒發生」。做得好的證據，只以「缺乏證據」的形式存在。
所以這看起來是技術問題，但實際上是衡量與獎勵的問題。產出量會即時顯示在儀表板上，可維護性則以三年後的帳單形式到來。如果管理者只能看到其中一個，會管理哪一個，答案早已注定。
韓國的這種扭曲不僅存在於個別公司的文化中，還寫在產業價格表上。這就是公共軟體維護費率3的問題。政府在 2017 年國政現案檢點調整會議上確定，將費率從 15% 左右提高到 2022 年達到 20%，以縮小與外資軟體（約 22%）的差距。但軟體政策研究所 2019 年的產業現狀調查顯示，受訪企業中 29.8% 仍然適用 10% 以下的費率。民間平均為 14.2%，公共部門反而更低。開發給錢、維修打折的做法，幾十年來一直留在文件裡。
結果也在默默累積。金融監督院在 2026 年 3 月的數位・IT 部門業務說明會上指出，近期發生的事故中，相當一部分不是因為精密的駭客技術，而是因為基本的安全原則和內部管控未被遵守。失敗的原因不在尖端，而在基礎。基礎本來就是沒人會稱讚的領域。
這些數字也需要質疑
讀到這裡如果總結成「果然 AI 是問題」就太草率了。需要一起看看這些證據的局限性。
首先，GitClear 不是中立的觀察者。它是一家銷售程式碼品質和開發生產力測量工具的公司。「品質指標正在惡化」這個結論與該公司的商業利益重合。數據規模大和解釋中立是兩回事。
DORA 調查也很大程度上是自我報告問卷，觀察到的是相關性。是 AI 使用多的團隊不穩定，還是本來就快速推進的團隊先用了 AI，僅憑這些數據無法區分。
最有趣的是曾經被廣泛引用的 METR 研究。2025 年 7 月的發布中，將 246 個實際任務隨機分配4給 16 名熟練開發者的結果顯示，使用 AI 時完成時間多了 19%。但 METR 在 2026 年 2 月自行修正了實驗設計。原因是從 AI 中獲益越大的開發者越傾向於迴避「禁用 AI」條件的參與，存在選擇偏差。以重新參與者為基準，反而估計快了 18%。簡而言之，研究團隊自己退到了接近「AI 是否提高生產力，我們也還不知道」的立場。
不過，在這次修正之後仍有一個發現站得住腳。那就是認知與計時器的差距。參與者在開始前預期會快 24%，實驗結束後也感覺快了 20%。無論測量值是哪個方向，「人無法憑直覺準確衡量自己的生產力變化」這個結論依然成立。而大多數組織現在正是憑著這種直覺來導入工具、規劃人力的。
奧斯瓦爾德的視角
在制定 GTM 策略時，我無數次參加了產品路線圖會議。穩定化項目在優先級中被排到後面的場景，幾乎沒有例外地反覆出現。有趣的是，在場沒有人輕視品質。但到了要選一句話放進季度目標的時候，「故障減少了 40%」永遠輸給「推出了三個新功能」。因為前一句需要證明沒發生的事，後一句只需要展示就行。
補充一個數據方面的經驗，「只有被衡量的才會被管理」這句話在組織中幾乎像物理定律一樣運作。所以我不認為這個問題的原因是 AI。這是本來就存在的扭曲，AI 只是讓它更快地執行的裝置。如果開發功能的成本降到十分之一，本來就偏向功能那端的天秤會更嚴重地傾斜。反過來，整理和淘汰的工作仍然需要人的判斷和時間，所以相對看起來更貴。
所以，我認為把這個問題當作工具選擇問題來處理的組織，大多會失敗。不管用 Cursor 還是 Claude Code，如果季度計劃裡沒有「修東西」的位置，結果一樣。DORA 得出的結論也完全是同一句話：AI 導入成功不是工具問題，而是系統問題。
有一件事我想留個開放。寫原文的那位開發者也沒有悲觀，而是留下了這樣的期待：在公司累積技術債的同時，個人開發者已經能獨自做出以前根本不敢想的軟體了。同一個工具既能製造債務，也能給被債務折磨到極點的人創造替代方案的力氣。
結語
用三句話總結。AI 導入後產出量增加了，但重構降到 3.8%、重複區塊增加 81% 這類讓程式碼長壽的習慣全面退步了。不是因為 AI 寫了壞程式碼，而是因為關閉的工單有獎勵，沒發生的故障卻沒有任何獎勵。韓國甚至把這種扭曲以維護費率的形式刻在了價格表上。
本季度可以試一件事。打開路線圖，數一數有多少百分比被分配給「修和整理」的工作。如果接近 0，那不是團隊的問題，是計劃書的問題。
你有沒有見過把整個季度都花在穩定化而非新功能上的組織？那個決定是怎麼通過的，下一次評估中那個團隊受到了什麼待遇，我特別好奇。
💬 請在留言區分享把季度花在穩定化上的組織案例。下一期會參考。 📨 如果有同事正在為往路線圖裡塞品質項目而掙扎，請分享這篇文章。
參考資料 & 延伸閱讀
核心來源
- GitClear, “The Maintainability Gap: AI Code Quality in 2026”, 2026. ··· 本文大多數數據來自這裡。不過建議在閱讀時留意該公司銷售程式碼品質測量工具的事實。
- Google Cloud, “2025 State of AI-assisted Software Development (DORA Report)”, 2025.9. ··· 產出量與不穩定性同時上升的部分是核心。「AI 是放大器」這個說法也出自這裡。
- Becker, J., Rush, N., Barnes, B. & Rein, D., “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, arXiv:2507.09089, 2025.7. ··· 19% 數據的原文。強烈建議與下方的後續文章一起閱讀。
- METR, “We are Changing our Developer Productivity Experiment Design”, 2026.2. ··· 研究團隊自己承認選擇偏差並修改設計的記錄。公開修正自己研究的這個方式本身就值得一看。
- 軟體政策研究所, “공공SW 유지보수 사업, 예산 사각지대 해소해야”. ··· 討論維護費率目標與現實差距的文章。了解韓國結構性背景時是好的起點。
背景知識
- DORA, “Balancing AI tensions: Moving from AI adoption to effective SDLC use”, 2026. ··· 分析 AI 省下的生成時間被重新分配為驗證時間。與本文第三節相連。
- 法律新聞, “2026년 디지털·IT부문 금융감독 업무설명회의 주요내용 및 시사점”, 2026.3. ··· 整理了金融業事故的原因診斷。適合從監管角度確認。
推薦搭配的往期文章
- 新任聯儲局主席為什麼像創業公司一樣說話 ··· 討論了「AI 生產力即將到來」的敘事先於數據流通的問題。與本文從精確的對立面看同一個差距。
