74% 的 AI 程式碼要返工：你的 spec 少寫了什麼

New Relic 的《State of AI Coding 2026》調查裡，74% 的組織說至少四分之一的 AI 程式碼上線後需要大幅返工。

四分之一。這不是小數字。

但真正值得看的是他們列的原因：context 不足、資料不完整、系統假設有誤。

沒有一項是「模型能力不夠」。

也就是說，返工的原因不在 agent 那一端，在你這一端。你沒講清楚的事，它就自己補了。

這篇拆三件事：spec 該寫到多細、真正該寫進去的是什麼、以及這對你的履歷代表什麼。

瓶頸移動了，工作也跟著移

系列第一篇裡吳恩達的第四項技能叫 shaping the build。

他的推論很短：只要 spec 寫得夠清楚，agent 交付的能力正在快速變好，所以工程師的工作重心正在往「決定 spec 裡該放什麼」移動。

白話一點就是，不要再期待有人給你一份 pixel-perfect 的設計稿，你只負責照著實作。

傳統軟體團隊的分工是三段式：PM 跟客戶談、寫需求，設計師做 mockup，工程師照規格做。

這條線之所以成立，是因為實作本身很貴。

當 agent 可以把清楚的規格直接變成能跑的軟體，實作就不再是唯一的瓶頸。這道分工線也就開始鬆動。

團隊還是需要有人找出真正值得解決的問題、理解客戶要什麼、權衡各種取捨。而這些工作，正在往工程師身上移。

講直接一點：工程師工作裡「結果明確、單純執行」的那部分在減少，「充滿不確定、需要人類判斷」的那部分在增加。

分界線：這個任務有沒有唯一正確答案

不是每件事都需要 spec。判準只有一條。

有唯一正確答案的任務，不要寫 spec。 找 bug、查為什麼這支查詢變慢、修 CI 上掛掉的測試。你把現象丟給它就好，它會自己去找。你寫的任何規格，都只是在限制它的搜尋範圍。

開放式任務才需要。 「做一個訂閱管理頁面」沒有唯一解。你不寫，agent 就會自己編一個。編出來的通常能跑，但不是你要的那個，而且它不會告訴你它編過。

中間還有一種狀態值得認出來。

你自己也不確定要什麼的時候，先讓它做一個能跑的版本，再拿那個版本當 spec 的草稿。對著空白畫面想需求，比對著一個具體的錯誤版本想需求難得多。

上一篇談的五個審查點其實就是在收拾這個問題的後果。你沒寫進 spec 的取捨，agent 都替你決定了，而且決定得很有信心。

spec 裡真正該寫的不是實作，是取捨的優先順序

這是整件事最容易寫錯的地方。

大多數人想到「寫詳細一點」，寫出來的是更多實作細節：用哪個函式庫、資料表怎麼切、元件怎麼命名。

而這些恰好是 agent 最擅長、也最不需要你操心的部分。

真正該由你決定、agent 沒有立場決定的，是取捨的優先順序。長這樣：

• 這個功能慢一點可以，但絕對不能算錯。可靠度優先於速度。
• 這個功能可以不即時，但每次呼叫要壓在多少錢以內。成本優先於延遲。
• 這個資料寧可少給，也不能給錯人看。安全優先於功能完整。

這些句子寫進 spec，agent 的每一個實作決定就有了判準。

不寫呢？它會用一個你看不到的預設值。通常是「先做出來能跑」。

有一個很好用的檢查法：spec 寫完之後，刪掉所有講「怎麼做」的句子。剩下的東西如果還足夠讓另一個工程師做出正確的取捨，這份 spec 就夠了。剩不下什麼，代表你寫的是實作說明，不是規格。

這件事跟 evals 是同一件事的兩面

Hamel Husain 和 Shreya Shankar 在講 AI 產品的 evals 時，有一個說法很值得借過來：evals 是 AI 產品的新 PRD。

意思是，寫得好的 eval 本身就是一份會持續執行的產品需求文件。它不是寫完放著的文件，是每次改動都會跑一次的規格。

這跟 spec 是同一件事的兩面。spec 說「我要什麼」，eval 說「怎麼知道拿到了」。

只有前者，你會得到一個看起來對的東西。只有後者，你會很精準地量到錯誤的目標。

系列第二篇那套 evals 閉環講的就是後面那一半：從二十筆真實失敗長出自動評分，讓「我要什麼」變成可以被驗證的東西。

Ownership 的紅利，跟它的代價

吳恩達提到另一面：AI 給了你比以前更大的 ownership 空間，你可以自己找出有意思的問題、自己執行。

但要吃到這個紅利，你得知道怎麼推動一個專案。他點名的判斷是：什麼時候該快做一個 MVP 丟給用戶測，什麼時候該慢下來好好蓋。

這個判斷沒有通則，但有參考。三大產品開發迴圈那篇講的是他自己做 0 到 1 產品時的迴圈設計，重點在人類的 context advantage 還剩下什麼。

另一個方向是市場時機。一個專案爆紅，有多少是品質、有多少是時機？當實作變便宜，時機的權重就變高。

代價也很具體。GitClear 分析了 2020 到 2024 年間的兩億一千一百萬行程式碼，發現重構過的程式碼比例從 24.1% 掉到 9.5%，而複製貼上的比例史上第一次超過重構。

做得快不等於做得對。而快的那部分，現在幾乎免費。

利益揭露：以下是聯盟連結。從有想法到有 MVP 這一段，寫文件跟寫程式的時間其實差不多長，Typeless 這類語音轉錄工具適合把口頭想法先變成草稿再整理。

這對履歷代表什麼

系列第一篇提過，這張技能圖不是「想轉職 AI 工程師要學什麼」的清單，是「你現在這份工作再過兩年長什麼樣」的預告。

放到求職上，差別很清楚。

用 Claude Code 全自動求職那套流程已經示範了一半：能被寫進 portfolio 的不是「我用 AI 生了一個 app」，是「我看到什麼問題、設計了什麼架構、AI 錯在哪、我怎麼測出來的」。

前者證明你會用工具。後者證明你會做判斷。

而現在人人都會用工具。

常見問題

spec 要寫多細才夠？

細到能回答取捨問題就夠，不用細到像設計稿。實作細節交給 agent，但成本、可靠度、速度、安全性之間誰先讓，必須由你寫進去。

什麼情況根本不需要寫 spec？

任務有唯一正確答案的時候。找 bug、查為什麼變慢、修測試，直接給現象就好。

工程師還需要等 PM 給需求嗎？

愈來愈不能等。當寫程式不再是唯一的瓶頸，找出值得解決的問題、理解客戶要什麼、權衡取捨這些工作會往工程師身上移。

這對求職履歷代表什麼？

能寫進 portfolio 的不是「我用 AI 生了一個 app」，是「我看到什麼問題、設計了什麼架構、AI 錯在哪、我怎麼測出來的」。

系列到這裡

五篇走完，回頭看吳恩達那四項技能，有一個共同點：只有第一項在講「怎麼做出東西」，另外三項都在講在一個你無法完全控制的系統上怎麼做判斷。

沒有一項是「更快產出更多程式碼」。

• EP.1 總覽：一萬筆職缺裡沒有 prompt engineering
• EP.2 evals：先別寫評分標準，先讀二十筆真實失敗
• EP.3 指揮 agent：資深工程師用 AI 反而慢 19%
• EP.4 審查架構：45% 的 AI 程式碼帶漏洞
• EP.5 寫 spec：你正在看的這篇

四項一起練是不可能的。

如果只挑一項開始，挑 evals。因為那是唯一一項能讓你知道自己有沒有進步的技能。其他三項沒有它，你只能靠感覺。

而靠感覺這件事，開頭那個 74% 已經示範過結果了。