把寫 code 加速 3 倍,交付幾乎不動——AI 真正的槓桿不在打字那一段

大部分人買 AI coding 工具,心裡的算式是這樣:寫 code 變快,東西就出得快。這個算式錯在它假設瓶頸在打字。我想拆掉這個假設,因為押錯瓶頸,你的錢會花在一個幾乎不會動的地方。

把一格加速三倍,整條鏈幾乎不動

軟體交付不是一個人埋頭打字,是一條鏈:需求、設計、建置、測試、發布、維運。真正吃掉時間的多半不在寫 code,而在互等——開發等產品把 story 講清楚,維運等開發 release,測試等 build,而且每個人卡在不同工具、看到的環境還不一樣。

這條鏈裡你只把「寫 code」那一格加速三倍,會發生什麼?增益被周邊每一個階段吸收掉,整條交付幾乎不動。瓶頸是協調與等待,不是打字。這就是「AI 明明會寫 code,卻沒轉成真實生產力」的結構性原因——不是 AI 不夠強,是你把它裝在了一個不是瓶頸的地方。

自覺快 20%,實測慢 20%

有個更刺的硬證據。一個做模型評估的研究組織 METR 對開源開發者做了對照實驗:用上 AI 工具的人,自覺快了 20%,實測卻慢了 20%。

我喜歡這個數字,因為它把問題問對了。「AI 能不能寫 code」答案早就是能,再問已經沒意義。真正該問的是:為什麼這份「感覺快」沒有轉成整條鏈的真實改善?自覺生產力和真實生產力會反向——這不是直覺能修正的,你得用 outcome 去量,不能靠人自己回報。

委派的兩端都會失敗

知道槓桿不在打字,還得知道怎麼交給 AI。我看到團隊在建置階段常落到光譜的兩端,兩端都把增益丟掉。

一端是過度委派:把一個大而模糊的問題整包丟出去——「幫我做個電商平台」。這種需求裡塞滿沒講清楚的決策,金流、認證、物流,本該在需求階段想清楚的,現在全推給模型自己猜,吐出幾千行沒人讀過的 code。它幾乎上不了正式環境,因為審查很慢,你還得為模型擅自做的決定來回拉扯,反而更慢。

另一端是委派不足:資深工程師自己把規劃和拆解全做完,只讓 AI 補一個很窄的點——「寫這個 function」。這段 code 確實好,但智力重活 100% 還在人身上,設計和架構照樣慢。

正解在中間:把意圖轉成小而明確、模型讀得懂也照得做的規格。不是整套甩出去,也不是只敢丟碎片。

槓桿在兩端:需求,和維運

那該把 AI 擺哪?擺到鏈的兩端。

前端是需求:把問卷、用戶回報、利害關係人的對話這些非結構化的東西合成起來,看懂用戶卡在哪、生出 user story、推下一批 feature。後端是維運:讓 AI 去逆向那種沒人真懂、原作者早就不在的遺留系統,用你不熟的語言告訴你每個 function 在幹嘛、當初為何這樣寫。把「看不懂所以不敢動」的死結,換成「先讀懂、再改」。

這兩端的共同點,是把你這個人的角色從「親手做」搬到「指揮和驗證」。我自己的工作重心早就在往這邊移——以前是從零寫,現在是給 AI 提需求、改它的輸出、為決策負責。同一批人,因為手不再被打字綁住,反而能去咬更複雜、風險更高的判斷。這不是用 AI 換掉誰,是讓原本那批人變得更強。

所以我的結論很簡單:別把 AI 預算全壓在 coding 提速。衡量它不要看產出幾行,要看 outcome——系統健不健康、好不好維護、上一個新 feature 的前置時間。然後把它擺到需求和維運那兩端,那裡才是槓桿真正撬得動的地方。