2023 年之後，寫一個函式、生成一個 CRUD API、翻譯一段業務邏輯成程式碼——這些動作的邊際成本接近零。一件以前需要工程師花幾小時的事，現在變成幾秒鐘的提示。程式碼的生產不再稀缺；稀缺的是其他東西。
程式碼商品化的含義
當一個資源的生產成本趨近於零，它的價值就從「能不能產出」轉移到「選擇產出什麼」和「確保產出的是對的東西」。
程式碼歷來的真實成本從來不只是「打字」。打字是最小的部分。真正的成本在：
- 搞清楚要做什麼（需求澄清、假設驗證）
- 驗證做出來的東西是否正確（測試、審查、整合）
- 維護它（理解、修改、擴展、除錯）
- 對它負責（擁有結果、在出問題時能解釋它）
AI 把「打字」的成本降到幾乎為零。但搞清楚要做什麼、驗證、維護、負責——這四件事的成本，AI 並沒有顯著降低，甚至在某些維度上提高了（因為現在有更多程式碼需要被搞清楚、驗證、維護、負責）。
真正值錢的東西
意圖與規格（Intent & Spec）
把「我想要什麼」轉化成「AI 能可靠執行的精確指令」，是一種技能，也是一種槓桿。Spec 不只是人與 AI 的溝通介面；它是決策的固化，讓未來的人（和 AI）能理解「我們決定做什麼、為什麼、成功是什麼樣子」。
Thoughtworks 在 2025 年的 Technology Radar 把 Spec-Driven Development（規格先行開發）列為 AI 輔助工程的關鍵新實踐，核心理由是：一份清楚的 spec 同時是人類的共識文件和 AI agent 的執行 prompt。Microsoft 稱這個方法為「AI-native engineering 的規格先行方法」。
驗證能力（Verification）
AI 生成的程式碼，對還是不對？看起來對和真正對，是兩件不同的事（見 AI 生成程式碼的失敗模式）。能寫出好測試、設計有效的驗證閘門、識別邊界 case——這些能力在 AI 時代的稀缺性只增不減。
審查判斷（Review & Judgment）
審查一段 AI 生成的程式碼，需要理解它「為什麼這樣寫」、「有沒有更好的做法」、「它在什麼假設下成立、假設一旦不成立會發生什麼」。這需要的工程深度，比從零生成同等程式碼更高，不更低。
品味（Taste）
哪些設計決策是正確的，哪些是過度設計，哪些會造成日後維護困難——這是工程品味。它由經驗、失敗、閱讀與批判性思考積累，不是 AI 能替你建立的判斷能力。
擁有權（Ownership）
最終問責的是人，不是模型。當程式碼出問題，你要能理解它、解釋它、修復它。「AI 寫的，我不太確定為什麼這樣設計」是一個技術債聲明，不是一個交付聲明。
價值移動的圖示
AI 前 AI 後
─────────────────────────────────────────────────────
[搞清楚要做什麼] 稀缺 [搞清楚要做什麼] 更稀缺
[打程式碼] 稀缺 → [打程式碼] 便宜
[驗證正確性] 稀缺 [驗證正確性] 更稀缺
[維護] 稀缺 [維護大量 code] 更稀缺
[擁有 & 解釋] 稀缺 [擁有 & 解釋] 更稀缺
結論：AI 壓縮了「生產」的成本，但放大了所有其他步驟的重要性。工程師的角色從「生產者」往「意圖制定者、驗證者、審查者、責任擁有者」移動。
這對個人工程師的含義
- 「我能快速用 AI 產出功能」不是護城河；「我能確保這個功能是正確的、可維護的、我能解釋每一個設計決策」才是。
- 學習怎麼寫清楚的 spec、設計有效的測試、做深度審查——這些技能的 ROI 在 AI 時代反而升高。
- 能在 AI 輔助環境下保持工程嚴謹度的工程師，比能快速 vibe-code 的工程師更稀缺。
延伸
- 程式碼為什麼便宜還不夠好 → AI 編碼的 70% 問題與最後 30% 的陷阱
- 便宜程式碼的具體失敗模式 → AI 生成程式碼的失敗模式
- 怎麼建立讓 AI 可靠執行的規格 → Spec-Driven Development：規格先行
- 回到全景 → Engineering AI Coding Methodology 專欄首頁