跟 AI 討論產品架構

上一篇我說，
動手之前，先聊清楚一些架構內容的名詞。

那都有些什麼呢？
這篇就是答案。

很多人一打開 AI，
腦袋裡只有「我要做一個網站」、「跟什麼有關的」。

然後 AI 開始問：
要不要登入系統？
資料存哪裡？
要不要 RWD？

甚至一個問題都沒問，
直接幫你動手跑程式碼。

你可能知道一些功能或是也有點聽不懂他在問什麼，
就回「好，先幫我做出來」。

於是 AI 就用它自己以為的方式做下去，
結果只有兩種：

1. 做完跟你想的完全不一樣。

2. 你覺得 AI 真的太酷了，幫你做出一個能跑的網站。
但你完全不知道它背後在做什麼。
然後有一天它壞了。
你連從哪裡開始問都不知道。
這就是大部分人卡關的原因 —
不知道自己的 AI 到底做了些什麼。

其實主要問題不在 AI，
是你還沒學會跟他講同一種語言。

四個你一定要懂的名詞

你可以不需要會寫，
但要知道他們各自負責什麼。
通常一個網站是用什麼東西組成的，
這叫做「架構」。

這樣你才能告訴 AI 你想要什麼。

1. 前端（Frontend）— 使用者看得到的那一面

打開網頁，你看到的按鈕、文字、圖片、版面，
全部都是前端在做的事。

你可以想成「店面」。
客人走進來看到的長相、動線、燈光，
都是前端負責。

跟 AI 討論時要講清楚：
・這個產品要在手機看還是電腦看？（還是兩個都要）
・風格是什麼？簡潔？溫暖？專業？
・使用者進來第一眼要看到什麼？

2. 後端（Backend）— 客人看不到的廚房

客人在店面點餐，
廚房在後面煮，
煮好再送出來。

後端就是那個廚房。
使用者按了一個按鈕，
背後就有一段程式在跑：
驗證身份、計算結果、存資料、回傳。

你可能會想：
那為什麼前端不能直接去抓資料？

因為資料庫一旦被前端直接打開，
就等於把後門鑰匙放在門口。
後端就是那個守門員，
幫你檢查誰可以拿、誰不能拿。

跟 AI 討論時要講清楚：
・使用者按下按鈕之後，要發生什麼事？
・有沒有需要「記住」的東西？（例如登入狀態）
・有沒有要跟外面的服務溝通？（例如寄信、收款）

3. 資料庫（Database）— 記憶體

所有要被「記住」的東西，
都要存進資料庫。

會員資料、商品列表、訂單記錄、留言，
全部都在裡面。

你可以想成一本超級大的 Excel，
每一張表記一種東西。

跟 AI 討論時要講清楚：
・你要存什麼資料？
・這些資料之間有沒有關係？
（例如：一個會員可以發很多則留言）
・哪些資料只有自己看得到？哪些是公開的？

4. UI/UX — 好不好看 + 好不好用

UI 是 User Interface，使用者介面。
講白話就是「長得好不好看」。

UX 是 User Experience，使用者體驗。
講白話就是「用起來順不順」。

兩個常常被綁在一起講，
但其實是兩件事。

漂亮但難用，是 UI 強 UX 弱。
好用但醜，是 UX 強 UI 弱。
我們要的是兩個都好。

跟 AI 討論時要講清楚：
・你的目標使用者是誰？（年齡、習慣、痛點）
・他們最常用的動作是什麼？
・哪一步最容易停頓？

怎麼開啟這場討論

我自己每次開新專案，
都會先丟一段話給 AI：

這段話一丟過去，
AI 就會變成那個會問對問題的顧問，
而不是急著動手的工人。

NaLi Match 是這樣討論出來的

我跟朋友只花了一天，
就架構出 NaLi Match。

那天我們做的事情，
就是上面這四件事。

這四件事先講清楚，
寫程式的時候就不會迷路。

一個提醒

不要怕問題太簡單。

「資料庫」這個詞，
我去年才第一次搞懂。
在那之前我以為「網站」跟「資料」是同一件事。

但你只要願意問，
AI 會用任何你聽得懂的方式講給你聽。

問了，
你的世界就會大一點。

最後一個提醒

不要在還沒聊清楚架構之前，
就問 AI「我要用 React 還是 Next.js」。

那不是你現在該關心的事。
工具是最後才挑的，不是最先挑的。

先把要做什麼想清楚，
AI 自然會推薦適合的工具。

下一篇我會講，
這四個零件是怎麼組起來、互相合作的。
API、資料流、靜態 vs 動態、開發 vs 正式環境 —
vibe coder 卡關 80% 都跟它們有關。