AI 時代的「快餐軟體工程」：代碼正失去可讀性，我們該如何自救？

最近滑社群、看廣告，三不五時就跳出「五分鐘做一個 App」、「一鍵生成完整網站」這類訊息。身邊也越來越多非技術背景的朋友開始用 AI 寫程式，連家人都會偶爾轉頭問我：「ChatGPT 給我的這段是不是有問題啊？」

不能否認，AI 確實把開發的「初期速度」拉到了我從業以來沒見過的高度。

但我是寫 Code 過日子的人。當我打開那些「AI 一鍵生成」的後台源碼時，老實說，心裡通常是先倒抽一口氣的。

這幾年我隱隱有種感覺：在大家忙著吹捧 AI 把效率翻 N 倍的當下，我們正悄悄迎來一場前所未有的技術債大爆發。

那些 AI 催生出來的「快餐代碼」

現在主流的 AI 工具，不管是 ChatGPT、Claude 還是各種 Copilot，本質上都只追求一件事：「現在能跑就好。」

因為這個權宜的底色，它最習慣的偷懶方式，就是把 UI 畫面、商業邏輯、API 呼叫全部揉在同一個檔案裡。Vue 3、Nuxt 3 這類現代框架本來都有一套滿優雅的目錄規範跟「關注點分離」的精神，但在 AI 無腦輸出之下，沒幾天就會變成檔名亂七八糟、單一檔案破千行的程式碼垃圾堆。

更糟的是，當工程師因為這份代碼太醜、可讀性太差、根本懶得理清架構時，現在的「標準解法」竟然是——把代碼整包再丟回給 AI 改一次。

這在我看來是個低效到爆炸的惡性循環。每次只想改一小段功能，卻得把整份幾千行的上下文當作 Token 餵給模型。商用成本算下來一點都不划算，開發體驗也差。等專案規模再上去一階，AI 就開始拆東牆補西牆——你叫它修 A，它在沒掌握全局的情況下亂動一通，A 是修好了，B 卻在你看不到的角落悄悄壞掉。最後這筆帳，還是要人類工程師熬夜擦屁股。

所以錯的其實不是 AI，是我們使用它的姿勢。AI 降低了寫 Code 的門檻沒錯，但它同時也把「沒有架構思維」這件事的代價放大了好幾倍。

我自己跟 AI 一起寫 Code 的方式

這陣子我摸索出一套防禦性的協作方式。簡單講就是：別把 AI 當成代工打字員，它應該是一個能跟你思辨的技術夥伴。

我自己有幾個一直在堅持的習慣，分享給也在被快餐代碼搞瘋的朋友們。

動筆之前，先逼 AI 跟我寫一份「開發計畫書」。 面對稍微複雜一點的任務，我幾乎不會在第一時間就要 AI 吐 Code 出來。我會先要它跟我一起擬一份開發計畫，把目錄結構、元件職責、資料流向、命名規範這些東西先攤在桌上談清楚。藍圖畫好、共識達成了，後面它產出的 Code 才會乖乖待在框架裡，不會像脫韁野馬一樣亂跑。這一步看起來像在浪費時間，但實際上是後面所有效率的來源。

給 AI 一份「編碼規範 Prompt」。 團隊會用 ESLint 來約束開發者，那我們當然也可以預先約束 AI。我會在對話一開始就明確告訴它：禁止把商業邏輯跟 UI 揉在一起、邏輯太複雜要主動拆檔、不允許單一檔案超過合理行數而不重構。AI 在約束裡跳舞，吐出來的 Code 才有人樣，一年後人類接手才不會崩潰。

用「蘇格拉底式」的對話，多問為什麼，少直接要答案。 當代碼噴 Error 或邏輯不通時，我最忌諱的就是丟一句「這段壞了，幫我修」。我會反過來問它：「你覺得這個錯誤的根本原因是什麼？」、「你提的這個修法，會不會動到我們原本的架構？」有時候我甚至會反過來要它質疑我這個問題本身合不合理。這種來回往往才是真正的價值所在。等我們在邏輯上達成最優解的共識，再讓它動手。AI 的幻覺幾乎不會再出現，每一次代碼異動也都還在我能掌握的範圍裡。

寫到最後想說的

軟體工程界有一句被講到爛的老話：「程式碼首先是寫給人看的，只是剛好電腦可以執行。」這句話在 AI 時代反而有了更深的意義。

當寫 Code 的「體力活」被自動化，工程師真正在賣的東西，已經整個轉移到架構設計、邏輯思辨、跟系統約束這些事情上面了。

盲目跟著 AI 的預設路徑走，到頭來只會被技術債淹沒。倒不如花點時間學會怎麼用清晰的計畫跟規則去馴服它——這年頭追求快餐沒什麼不對，但能不能在快的同時，做出一年後自己回來看還願意接手的東西，這才是分水嶺。