AI Coding 技術債：寫程式快 10 倍，Temporary Fix 也可能快 10 倍
- 從「現在能跑」到「半年後還敢改」，把專案記憶留給下一個 Agent。 -
最近看到一則工程師笑話：一家公司發現訂單偶爾會「消失」，工程師一路追查 Cache、Database、Replication、Redis、Kubernetes、Message Queue……
查到最後才發現，整套龐大的企業架構，其實都在保護八年前的一個 Prototype。
最經典的是當年的 Commit：
quick prototype, will redesign later
八年後，還是沒有 redesign。
我看完笑得很開心，笑完卻想到一件更可怕的事：如果這個故事發生在 AI Coding 時代呢？
AI 讓 Prototype 更快，理解系統卻沒有變快
以前，一個工程師可能花兩個星期寫出 Prototype。現在用 Codex、Claude Code 或其他 AI Agent，一個下午就可能做出雛形：需求丟進去，Agent 開始寫程式、建立資料庫、串 API、部署 Cloudflare、接 Google Sheet、做登入、補後台。
跑起來、測一下、能用、上線。爽。
問題是，我們把「做出軟體」的速度提高了，不代表「理解系統」的能力也跟著提高。以前自己寫三千行程式碼，至少大概知道東西放在哪；現在 Agent 一個晚上可能改了幾十個檔案、加上套件、補 Issue，隔天打開 GitHub，看起來很厲害，卻只能祈禱不要壞。
AI Coding 加速的是產出，不會自動替你補上理解、判斷與維護能力。
真正麻煩的不是程式寫錯，而是沒人知道它為什麼能跑
AI 寫錯程式，通常還有訊號：測試失敗、CI 變紅、網站掛掉。至少我們知道某處出了問題。
更難處理的是一個「現在可以跑，但沒有人真正理解為什麼可以跑」的系統。它可能沒有明顯錯誤，還開始接到客戶、處理預約或帶來收入。這時候有人提議重構，第一個反應常常不是「好」，而是「現在不是能跑嗎？」
恭喜，第一筆技術債誕生了。
接著需求和臨時修補一層一層疊上去：
- 「這裡先加個判斷。」
- 「那邊先 Workaround。」
- 「這個欄位先不要動。」
- 「這個 Workflow 不知道為什麼不能刪。」
- 「這段是 AI 寫的，先不要碰。」
最後 README 可能出現一句 DO NOT MODIFY THIS SECTION. 沒有人知道原因，但大家都很尊重它。
Prototype 最危險的時刻，未必是它出 Bug，而是它開始被依賴、開始賺錢，卻沒有人敢改。
AI 降低開發成本，沒有自動降低維護成本
以前一年可能做三個 Prototype，現在一年可以做三十個。這些雛形不一定都會留下來，但只要其中一部分開始接觸真實使用者、營運流程或收入，它們就從「先試試看」變成需要長期照顧的系統。
如果每次都只追求先跑起來，AI 就可能讓臨時作法累積得更快：一年多做了十倍 Prototype，也可能多留下十倍需要理解和維護的東西。效率提高了，技術債也能跟著自動化累積。🤣
所以 Vibe Coding 下一階段重要的能力，不只是「怎麼叫 AI 幫我寫程式」，而是「怎麼讓 AI 幫我建立一套未來還敢修改的系統」。這兩件事差很多。
把專案記憶留在 Repository，讓下一個 Agent 接得住
比較大的 AI Coding 專案，我會開始要求 Agent 做幾件以前覺得很囉嗦的事：
- 先寫規格、拆 Issue： 把目標、範圍與完成條件留下來，讓每次修改都有依據。
- 記錄架構決策： 說明為什麼採用某個做法，以及有哪些限制，避免未來的人只看到程式碼、看不到背景。
- 補測試並做 Code Review： 不只確認功能能跑，也檢查變更有沒有破壞原本行為；重要修改還可以請另一個模型做對抗性驗證。
- 重要修改先 Commit： 留下可追蹤的變更邊界，搞砸時才知道從哪裡回復。
- 更新 README 與必要文件： 把執行方式、關鍵流程和已知限制放在下一個接手者找得到的地方。
更重要的是，別只問 AI：「可以跑嗎？」也問：「半年後，另一個完全不知道背景的 Agent 接手，它看得懂嗎？」
未來維護程式碼的人可能不是現在的你，也可能是下一代 Codex、Claude Code，或另一個從沒參與過這個專案的 Agent。Git、Issue、README、測試與 Architecture Decision Record，不只是寫給工程師看的文件，也是留給下一個 Agent 的專案記憶。
以前寫文件，是怕工程師離職；未來寫文件，可能是怕 AI 換模型。模型會變，Agent 的 Session 也可能重新開始。真正能留下來的，不是它「記得什麼」，而是 Repository 裡留下了什麼。
所以我現在看 Vibe Coding，已經不只是：
Prompt → Code → Deploy
而更像：
Spec → Issue → Agent → Test → Review → Commit → Documentation → Deploy
AI 可以讓每一步都變快，但不能因為變快，就把那些步驟全部刪掉。
八年後，某個新人打開 Git，看到一段奇怪的程式碼。Git blame 一查：作者是享哥，Commit message 寫著 temporary fix。
新人問：「為什麼這段不能改？」
資深工程師喝一口咖啡：「不知道。」
「那為什麼還留著？」
「因為刪掉會出事。」
「會出什麼事？」
「不知道。」
「那到底誰知道？」
資深工程師指向 Git 紀錄：「可能要問 2026 年的 Codex。」
問題是，那個 Session 早就不見了。😂
常見問答 (FAQ)
Q1：AI Coding 為什麼可能讓技術債累積得更快？
AI 能加快 Prototype 和功能的產出，但不會自動增加人對系統的理解，也不會替未來維護補上文件、測試和架構決策。當更多雛形開始被客戶或營運流程依賴，沒有整理的臨時修補就可能變成更難修改的技術債。
Q2：Prototype 已經可以跑、也開始有使用者，還需要重構嗎？
能跑和容易維護是兩件事。當系統開始被依賴時，應持續補上規格、測試、決策記錄與必要文件，並為重要修改保留可追蹤的 Commit；是否重構則要看實際風險與變更需求，不應只因為「現在能跑」就假設它永遠不需要整理。
Q3：怎麼讓下一個 AI Agent 看懂現有專案？
把背景和理由留在 Repository：用規格與 Issue 說明目標和完成條件，用架構決策記錄說明取捨，維護 README、測試與清楚的 Commit。這些內容能讓沒有參與前一個 Session 的工程師或 Agent 有線索理解系統。
