AI 時代的軟體框架 Framework 比你想的要重要

不要看 AI 寫程式很快，直上軟體框架就對了。這件事我也是試了很久才得出這個心得。

現在 vibe coding 很流行，很多人直接讓 AI 自己去寫。但實際上 AI 就是有很多的幻覺。

很多高手不太信任 AI 寫的東西。我自己一開始也有這個牴觸。因為我們太常、也太想讓 AI 去照著我們的方式寫了。如果你寫程式寫到一定程度，你一定有自己的風格、自己的慣例。那當你讓 AI 來幫你寫的時候，你的第一反應一定是「照我的方式來」。

但這裡有一個很現實的問題。

既有專案跟 AI 訓練資料的落差

公司裡的既有專案，很多都是東補西補出來的。裡面有歷史原因留下來的特殊寫法、有前任工程師的個人風格、有趕上線時候硬寫的 workaround。這些程式可以跑，但它們不標準。

AI 碰到這種程式的時候，它會改壞。原因是這些寫法跟它訓練模型裡面的程式碼不太一樣。

AI 的訓練資料主要來自 open source 和公開的 repo。而我們上傳到 GitHub 的時候，至少還是會有一些面子問題的，會把程式盡量修得乾乾淨淨。當然偶爾還是會有些 hardcore 的東西、或是比較久遠的程式碼，所以 AI 還是吃得到這些。但大部分公開 repo 上的程式碼還是偏乾淨的。

這就是一個比較大的問題：如果你要求 AI 去照著你的想法寫，它多半會寫得很差。因為你不照著規矩寫，你有你自己的版本。

[圖：Express.js 官網 - 刻意不給你規矩的框架]
 

100 個人 100 種寫法

就像以前別人說 React，100 個人有 100 種寫法。React 的彈性很高，它是一個系統適合、但不適合人統一寫法的東西。

但 AI 很適合 React。因為 AI 的整個邏輯就很適合 React 的思維方式。

所以我個人會比較傾向：如果今天你跟 AI 起爭執的時候，如果你想要讓 AI 幫你寫得更好的話，盡量跟它去討論、去理解它的邏輯，然後使用它的邏輯繼續進行下去，而不是硬要它融合進你自己原本的框架。

當然這是一個取捨。你今天使用 AI 就是為了讓你既有的東西不會壞掉，可以幫助你。但結果現在變成你要遷就它。

可是你想一件事：在現在或是在未來，AI 要生成一個跟你現在那個程式一模一樣的東西，如果你今天只是一個小程式的話，它對於一個有經驗的人來說，說不定是一個下午的事情而已。

所以你一直硬要去訓練它寫成你的方式，但這是大語言模型，它當初訓練的時候吃的那些東西就不是長成這個樣子。

[圖：React 官網 - AI 最熟悉的前端框架]
 

使用框架，不要聽 AI 偷懶

所以我會覺得，如果你今天要讓 AI 寫程式的時候，最好是使用框架。

然後也不要聽 AI 的。AI 很喜歡偷懶，它會跟你說「只要這樣就好」「只要一個小東西就好」。我覺得就是大，就是浪費，也沒關係。重點是那個框架必須要有一個很明確的邏輯。

因為 AI 非常討厭違反它自己的訓練模型。

舉個例子。如果你今天用的是 Ruby on Rails，AI 碰到資料庫的時候，它沒事就會在那邊乖乖寫 migration，它不會自己衝進去資料庫。因為 Rails 的慣例就是這樣，AI 學過的幾萬個 Rails 專案全部都是用 migration。

但如果你今天用的是 Node.js 的 Express，它就會整天一直衝進資料庫，想要去直接修改裡面的東西。因為 Express 本身沒有規定你怎麼處理資料庫，它的世界裡沒有「你不能這樣做」的慣例。

同樣的 AI，同樣的問題。差別是框架有沒有給它一條明確的路走。

[圖：Ruby on Rails 官網 - 慣例大於配置的代表]
 

先指定框架，再做事情

所以我建議大家，不管讓 AI 做什麼事情的時候，直接使用框架，不要使用它告訴你的方式。你就先說「我一定要用什麼框架」，然後基於那個框架再去做某件事情。

這樣的成功率會遠高於你直接叫它做什麼。

因為通常它會把第一個目的做得很快、做好。但它後面會整個亂掉。第二個目的可能跟第一個目的連不起來，你後面一直疊加的時候它就會出問題。

但如果你一開始就在框架裡面，框架的東西都在，只是你沒有用。就是浪費。但總比你浪費時間再去訓練它、然後它又會忘記、然後你要寫什麼 skill 去控制它的動作來得好。

不要用 skill 去對抗 LLM

有點像是：你不要去跟時代的洪流對抗。

你用 skill 寫的那些東西，就是那短短的幾個字、或是一篇幾百字的規則，然後要去對抗整個大語言模型 LLM 裡面它的訓練內容。

真的是傻了。

框架是幾萬個 repo、幾百萬行程式碼形成的共識。你的 skill 是你一個人寫的幾行字。哪個對 AI 的約束力比較強，答案很明顯。

不過 Skill 跟 Memory 這一段其實有蠻多東西可以討論的，所以我會另外擺一篇來講。

那如果要我推薦的話

如果今天是一個新的專案，你應該用什麼來寫？

如果要我首推的話，我會推薦 Django + Next.js + React，直接做前後端分離。你只要做出這個區隔，目前來看這些 AI Agent 不會沒事就去摸兩邊。

為什麼是這個組合？原因主要是因為大語言模型裡面都在學這兩個東西。AI 對 Django 跟 React 的熟悉度非常高，你用它們的時候 AI 犯錯的機率最低。

如果你對 Python 並沒有那麼在行，或是你心裡有牴觸、你喜歡用原本熟悉的東西去寫的話，我覺得也無所謂。你可以用 Ruby on Rails、Laravel、或你喜歡什麼其他的都沒什麼問題。

不過我現在是傾向完全不寫程式的。我都讓 AI 去寫，我看程式而已。尤其是當後期你用了很多比如說 AI 的模型、或是一些比較你沒辦法控制的那些訓練出來的、你不懂的程式，確實是沒有可能去真的完全理解它。並不是說真的看不懂，而是你有需要做的事情太多。像我有時候開發，我一次是開 6 個 AI Agent 在那邊看，然後 6 個都在開發，那我要看哪一個？有時候我想要的東西並不是我在行的，但是它還是跑出來了，那我要再花半天去看裡面的東西嗎？

我覺得不應該是這樣。而是我們應該要有一個標準，說它只要做到什麼，它就代表是沒錯的。不過這個議題也是之後我會再拉一個獨立的文章講這件事情。

[圖：Django 官網 - 首推的後端框架]
 

如果你是程式小白

不過如果你是程式小白的話，直接照上面這樣做你應該會死得很難看，因為你完全不知道這在幹什麼。

而且你會碰到部署的問題。目前來說，部署還是需要有點程式基礎、或至少是維運基礎的人。不能說你沒有就做不到，而是你會比較安心。

如果你確實是想要往程式發展的話，我個人比較推薦的幾個方向：

如果你這次是做網站的話，一樣直上 WordPress。為什麼是 WordPress？因為 WordPress 它可以改。它的小改的地方就是 Extension 跟 Theme。實際上你可以先動 Extension，如果你有辦法動 Extension 的話，你就會慢慢抓到那個感覺。

如果你今天是直接叫 AI 寫一個網頁，那當然也是可以。不過那就是純的 HTML、CSS、JavaScript，或者是它直接用 React 幫你做出來。但那個在串接後端的時候就會有問題。WordPress 至少一開始就有後端，所以它有一個穩定的架構。我覺得並不見得算是一件壞事，從這邊開始。

當然還有另外一種玩法，就是你直接走自動流，N8N 之類的，然後可能串一些 Python 小程式或是 Node.js 的程式。那個也可以。不過從這邊進的話會有部署問題，就是環境沒有那麼乾淨，而且你電腦裡面的東西會東一塊西一塊。最後會有環境整合的問題。不過你要從這邊開始也是可以，因為畢竟你還是有一件事情在做的話，你會學得比較快。不一定說一定要從網頁開始，就是你有一件真的想做的事情，你可以學得比較快。

[圖：WordPress 官網 - 程式小白的起點]