2025 年，我們還在為 Vibe Coding 興奮。
2026 年，比較誠實的說法是：大家開始收拾它留下來的東西。這句話不好聽，但很多團隊應該有感。
不是說 Vibe Coding 沒價值。它很有價值，特別是在原型、內部工具、活動頁、一次性腳本這些地方。你有一個模糊想法，丟給 Cursor、Claude Code 或其他代理工具，幾分鐘後畫面能跑、API 能接、甚至測試也補了一點。那種速度很難回頭。
但工程現場最麻煩的東西，通常不是「不能跑」。
最麻煩的是「看起來可以跑」。
它過了 happy path，demo 起來很順，commit message 也寫得像個認真的人。然後三週後，某個同事才發現權限邊界被繞過、資料同步有 race condition、測試只驗到表面，或是整個模組多了一層沒人敢動的抽象。
這就是 Vibe Debt。不是傳統技術債那種「我們知道先欠著」的債，而是更糟的版本：一開始大家甚至不知道自己欠了什麼。
Andrej Karpathy 把這波轉變稱為 Software 3.0。粗略講，Software 1.0 是人類寫明確程式碼，Software 2.0 是用資料訓練模型，Software 3.0 則是用自然語言去驅動大型語言模型完成工作。
這個說法很容易被誤讀成：「以後英文就是程式語言，所以工程師不用懂程式了。」我不太買這個版本。
它太省事了，也太危險。
自然語言變得重要，不代表工程消失。剛好相反。當你可以用自然語言叫一個代理改上百個檔案，工程能力只會變得更重要，因為你現在不是在打一行 code，你是在下放一段決策。
差別很大。
以前你寫錯一個 function，錯誤範圍通常還算局部。現在你給代理一個模糊任務，它可能替你重命名 API、改資料模型、補一堆它自己想像出來的測試，順便把本來很清楚的模組邊界揉成一團。速度變快，爆炸半徑也變大。
所以這波轉型不是從「會寫程式」變成「會聊天」，而是從「直接寫實作」變成「先寫出代理能安全執行的規格」。
很多工程師聽到規格書會皺眉。這很正常，因為我們看過太多沒人維護的 PRD、過期的 wiki、寫得像作文比賽的需求文件。
但在代理開發裡，規格不是拿來裝正式的文件。
規格是控制面。
它要回答幾個很具體的問題：
這些東西以前也重要，只是人類工程師常常靠默契補掉。代理沒有這種默契。它有上下文，但沒有責任感；它能推理，但不會替你的產品承擔後果。
這就是為什麼「寫規格」會變成 2026 年很硬的工程技能。不是會議室裡那種規格，是能拿來約束工作的規格。
你不是為了讓文件好看而寫。你是在替一個很快、很有用、但會亂猜的執行者畫邊界。
我通常會把代理規格拆成五段。不需要華麗，但要夠硬。
第一段是背景。不要寫公司願景，也不要寫抽象價值。只要說清楚現在系統怎麼運作，這次為什麼要改。
例如：
ryanvale
目前後台的 user export 只支援全量匯出。客服需要依照 created_at 區間匯出使用者，避免每次產生超大 CSV。
第二段是任務範圍。代理最怕任務範圍模糊，因為它會用「看起來合理」的方式自行補完。
只修改 admin user export 流程。
不要改公開 API。
不要調整 user schema。
不要重構既有 CSV formatter。
第三段是輸入與輸出。這一段越具體，後面 review 越省力。
新增 start_date 與 end_date query params。
日期格式使用 YYYY-MM-DD。
輸出仍為既有 CSV 格式。
沒有帶參數時維持原本全量匯出行為。
第四段是驗收條件。這裡不要寫「功能正常」。那等於沒寫。
- start_date/end_date 都存在時，只匯出區間內使用者
- 只帶 start_date 時，匯出該日期之後的使用者
- 只帶 end_date 時，匯出該日期之前的使用者
- 日期格式錯誤時回傳 400
- 既有無參數匯出測試必須保持通過
第五段是驗證命令。
完成後執行：
- pnpm test admin-user-export
- pnpm lint
這種規格不性感，但有用。它把代理從「幫我弄一下」拉回「照這個合約做」。
工程的成熟度，很多時候就差在這裡。
代理開發最容易讓人中毒的地方，是它一開始真的很準。
前幾次你仔細看 diff，發現沒什麼問題。後來你開始只看測試。再後來你覺得小改動不用看那麼細。最後，你按 merge 的速度越來越快，心裡還覺得這就是效率提升。
這就是 normalization of deviance 在工程流程裡的樣子。
它通常不是某一天突然做了很蠢的決策，而是每天都稍微降低一點標準，而且每次都沒有出事。久了之後，團隊就會把「沒出事」誤認成「很安全」。
AI 代理讓這件事更容易發生，因為它產出的東西通常很像真的。命名合理，註解完整，測試看起來也有補。它不像菜鳥工程師那樣明顯露餡，反而更容易讓 reviewer 放鬆。
所以 2026 年最危險的工程師，不是不會用 AI 的人。
而是那種看過幾次 AI 寫對，就開始相信自己可以不用理解的人。
很多人討論 AI 寫 code，都把焦點放在輸出速度。
但在真實團隊裡，瓶頸很快會轉移。code 產生變快後，卡住的地方會變成理解、整合、驗證、責任歸屬。
也就是說，真正值錢的能力會變成：
這聽起來很像以前的資深工程師能力。沒錯。只是現在它變得更稀缺，因為低品質實作的產量被 AI 放大了。
以前一個人一天只能寫出有限的爛 code。現在一個人可以用三個代理同時產生三倍的爛 code，而且都包裝得很像合理方案。
這不是反 AI。只是承認一件很基本的事：產能上升後，品質控制如果沒有同步上升，系統只會更快壞掉。
台灣軟體圈很愛問一個問題：工程師會不會被 AI 取代？
這個問法太粗。
比較貼近現場的風險是：某些工程師會被「PM + AI + 一個便宜收尾的人」取代。
PM 用 AI 做出 prototype，老闆覺得看起來可以，接著找工程師把東西接上正式系統。工程師如果只扮演收尾工，負責修 bug、補型別、擦屁股，價值感一定會被壓低。
問題不在於 AI 太強，而在於你被放在流程太後面。
要避免這件事，工程師不能只等需求丟過來再實作。你要往前站一點，參與規格怎麼被寫、任務怎麼被切、哪些東西可以交給代理、哪些東西要先做技術設計。
換句話說，你要成為那個設計代理工作流程的人，而不是最後被叫來整理代理輸出的人。
這個角色不一定叫 architect，也不一定有漂亮頭銜。可是在一個到處都有代理輸出的團隊裡，它會越來越重要。
如果要把這件事落地，我會建議用很樸素的四步驟。
不要一開始就開聊天視窗丟需求。先寫一份短規格，包含背景、範圍、驗收條件、不能碰的地方。
這份文件可以很短，甚至只是 issue 裡的一段 markdown。但它必須具體到代理不能自由腦補。
好的第一步不是「請實作」。先叫它說明會改哪些檔案，以及為什麼。
你要在它動手前先抓方向。方向錯了，越快越糟。
不要一次叫代理完成整個功能。把任務切成 migration、domain logic、API、UI、test 幾個明確階段。每一階段都要能 review。
這很煩，但比最後看一個兩千行 diff 好太多。
測試不是取代 review，review 也不是取代測試。
測試負責抓可機械化的錯。review 負責判斷設計、邊界、可維護性與產品語意。代理時代最常見的錯，就是把其中一個當成另一個的替代品。
我不相信「工程師不需要懂程式」這種說法。
剛好相反。你越想有效使用代理，越需要懂系統、懂架構、懂測試、懂失敗模式。只是你的輸出形式會改變。你不一定每次都親手打完實作，但你必須能寫出規格、設計流程、限制權限、審查結果。
Vibe Coding 是很好的起點，因為它讓我們看到軟體可以被更快地探索。
但如果要把探索變成產品，就不能只靠 vibe。
2026 年的開發者真正要練的，不是更會跟 AI 聊天，而是更會把不清楚的需求變成可執行、可驗證、可維護的規格。
以前我們寫 code 給機器跑。
現在，我們也要寫規格給代理跑。
這不是工程師價值下降。這是工程師的責任範圍變大了。
iThome鐵人賽
看影片追技術