引言：「然後呢？」

當生成式 AI 開始走進日常開發，很多人都曾經這樣試過：跟 AI 說一句話 —「幫我做一個可以記帳的網站」、「做一個查詢客戶名單工具」— 然後幾分鐘後，真的有一個畫面跑出來。按鈕會動，版面看起來有模有樣，完全就是一個網站。

然後呢？

然後你想改一點東西，卻發現自己說不出來要改什麼。你能看出畫面不對，但形容不出哪裡不對。於是你的對話大概變成這樣：

「這個不對，你再改一下」

「可不可以幫我把介面調的比較有質感一點」

「剛剛明明是好的，你怎麼改壞了？」

「它壞掉了，但我不知道為什麼」

四句話，對你來說可能很清楚；但對 AI 來說，幾乎沒有任何可以操作的資訊。它只能猜，你也只能一次又一次試。

你把做好的網站傳給朋友，發現他打不開——因為它只活在你自己的電腦裡。你輸入的資料看起來好好存著，換一台裝置打開，卻什麼都沒有。你用手機看，整個版面塌成一團，變得異常混亂。到最後你也不確定這個專案裡到底有什麼，只知道「目前看起來是動的」。

嗨，我是 Leo。這 30 天，我想處理的就是「然後呢」這三個字。

今天這一篇，我想先把四件事說清楚：1. 為什麼我要寫這個系列、2. 這 30 天想解決什麼問題、3. 接下來會怎麼走，以及 4. 這份日誌是寫給誰看的。 在真正開始開發之前，先把這趟航行的方向講清楚。

我與 AI 的奇幻漂流

這種狀態，我想了很久該怎麼形容：你身邊有一股很強的力量。強到只要你開口，就能替你划出很遠的距離。

但你不知道自己要去哪裡，也看不懂它划出來的方向對不對。你沒辦法完全信任它，可是也離不開它——因為靠你自己划，根本划不動。

於是你只能一直划。划得很快，但不知道是不是在繞圈。

這不就是《少年 Pi 的奇幻漂流》嗎？

那部電影裡，Pi 和一頭孟加拉虎困在同一艘救生艇上。很多人記得的是畫面很美，但我印象最深的，是 Pi 一直在做的一件事：他不斷試著搞清楚，這頭老虎的規則是什麼。

他沒有馴服牠，也沒有跟牠變成朋友。他做的是找出界線——什麼時候牠會攻擊、什麼時候不會、自己能站在哪裡、哪裡不能踏過去。他甚至造了一個小木筏，用繩子把自己跟救生艇綁在一起，既保持距離，又不會漂走。

他靠那些規則活了下來。

所以這頭老虎不是敵人。牠是一股你還不知道怎麼指揮的力量。而接下來的 30 天，我想做的事情只有一件：弄清楚哪些事情是老虎能做的、哪些事情需要由你來決定，以及怎麼建立一套讓彼此能安全合作的規則。

1. 這趟航行想證明什麼

1.1 一個被問爛、但問錯方向的問題

這兩年最常被問的問題大概是：「AI 會不會取代工程師？」

我不打算加入那個戰場。因為對你來說 —— 一個想把自己的想法做出來的人 —— 那個問題其實沒那麼重要。我個人認為更好的問題是這個：

當 AI 已經能替我們寫出大量程式碼，真正決定一個產品能不能上線的工程知識，還有哪些？

這個問題值得問，是因為答案很具體。

第一類：你已經感覺得到的問題

如果你用 AI 做過東西，下面這些應該不陌生：

• 做出來了，但只有我自己的電腦打得開，要怎麼讓別人也看得到？
• 用手機打開，版面全部跑掉
• 改了一個地方，別的地方壞了，而且不知道是什麼時候壞的
• 想把網址傳給朋友，但傳過去只會回到首頁，看不到我剛剛在看的東西
• 朋友幫我試用，一按下去就出錯
• 我明明輸入過資料，換一台裝置打開卻完全找不到

這些問題有個共同點：它們會自己跳出來煩你。 你遲早會撞上，然後開始找解法。

第二類：你感覺不到的問題

真正麻煩的是另一類。它們不會跳出來，網站看起來完全正常——直到有一天不正常。

• 你以為要登入才看得到的資料，其實不用登入也拿得到
• 你做了登入，但A 使用者可以看到 B 使用者的東西
• 現在只有 100 筆資料所以很快，資料變多之後會突然卡住
• 網站壞掉了，而你完全不知道，直到有人跑來跟你說

1.2 那 AI 為什麼不順手幫我做掉？

這個問題我想誠實回答，因為答案不是單一的。

• 有些事它知道怎麼做，只是你的需求沒有把它叫出來。 它知道什麼叫響應式設計，也知道搜尋沒結果時該顯示提示。但你只說了「做一個搜尋功能」，它就做了一個搜尋功能。

還有一件事：更強的模型，確實常常會自己補上這些。 但那是機率，不是保證。同一句需求，不同模型、不同脈絡，甚至不同一次生成，可能都會得到不一樣的完整度。而你不會知道這次是哪一種 —— 除非你知道該檢查什麼。模型變強，會提高你一次拿到合理答案的機率；但從「大概沒問題」走到「我確定沒問題」，仍然需要驗證。

有些事 AI 可以幫你分析，但它缺少產品情境，不能替你做最終判斷。

不管是哪一種，最後都要有人來決定。而那個人只能是你。

1.3 那我為什麼要寫這 30 天

我不覺得想用 AI 做出產品的人，都必須先回頭從變數、函數、迴圈、HTML、CSS 開始，把傳統學習路線完整走過一遍，才有資格開始做東西。但我也不覺得，做一個要給別人用的產品，可以完全不知道自己在做什麼。

這中間應該有一條路：不一定要能從零親手寫出每一行程式，但要知道有這回事、知道該要求什麼，也知道怎麼確認它做對了。

這 30 天，就是我對那條路的嘗試。我會把一個產品從一個念頭到真的上線的過程完整走一遍，然後把每個階段「你至少該知道的事」講清楚。盡量用非程式背景的人聽得懂的方式。

2. 這趟航行要抵達哪裡

2.1 這不會是 30 個互不相關的小範例

這 30 天，會從零完成一個 Web 產品。

不是今天做待辦清單、明天做登入頁、後天換成天氣 App，而是讓同一個專案一路長大：從一個模糊的念頭，到看得見的介面，再接上真正的資料庫、使用者系統，最後部署到網路上，接受真正的使用情境考驗。

也就是說，後面介紹的每一個概念，都必須回答一個很現實的問題：

這個東西，在一個真的產品裡到底拿來做什麼？

至於這個產品最後會是什麼，我會隨著文章推進，一步一步把答案揭開。

2.2 在開始寫程式之前，先決定什麼值得寫

很多人用 AI 開發會從一句：

「幫我做一個 XXX 網站。」

開始。

但我想往前多走一步，那個 XXX 到底是怎麼來的？

生活裡每天都有不方便的地方，但不是每一個問題都值得做成產品；網路上也幾乎永遠找得到某種程度的替代方案。

那麼：

• 什麼樣的問題值得自己做？
• 「已經有人做過了」是不是就代表不用做？
• 一個生活中的小麻煩，要怎麼收斂成明確需求？
• 第一版到底該做到哪裡？
• 哪些功能現在看起來很酷，其實根本不需要？

這些問題，我預計會在 Day 04 的文章和你一起從零走一遍——包括我當初怎麼從幾個念頭裡選出這一個，以及那些被我否決掉的。到那一天，這個決定才會正式變成一份規格文件。

在知道怎麼寫之前，先弄清楚什麼值得寫。

3. 這份航海日誌怎麼寫

3.1 四個階段

為了讓這趟旅程不至於雜亂無章，我把 30 天分成四幕：

第一幕：啟航與馴虎｜開發前的準備

AI 工具的簡介、名詞的釐清、需求的拆解，以及怎麼跟它建立一套可靠的工作方式。

預計會提到：Model／Agent／Context／Harness、Cursor、CLI 工具、需求規格、Git 基礎

第二幕：造筏｜前端

浮在水面上、看得見的那一半。從第一個頁面開始，做出可以真的操作的介面。

預計會提到：前端元件、DevTools、TypeScript 型別、假資料、狀態管理、響應式設計、Git 分支

第三幕：海面之下｜後端、資料庫

看不見、卻決定生死的那一半。

預計會提到：PostgreSQL、Prisma、API 設計、資料驗證、Supabase Auth、權限控制、查詢效能

這一幕會出現整個系列最危險的一座島。

第四幕：抵達彼岸｜部署

把產品送上線，以及上線之後才開始的事。

預計會提到：部署、網域、Cloudflare、寄信與 DNS 驗證、CI/CD、資安、SEO 與 GA4、成本結構

以及一份我認為比任何程式碼都重要的檢查清單。

3.2 我會保留過程，但幫你省掉不必要的坑

這 30 天，我不會用最快的方式把網站做完。如果只追求「畫面有了、主要流程會動」，我大可以先寫一份完整規格，再讓 AI 一口氣把大部分功能生出來。現在的工具，確實已經能把這段時間壓得很短。

但「看起來做完」和「真的做完」之間的距離，正是這個系列想討論的東西。

更重要的是，如果我只把最後成果端給你看，你看到的會是答案，卻看不到每個決定是怎麼下的。等到換成你自己的專案、自己的需求，還是很難知道該怎麼選。

而且，要先寫出一份「一次就能做到位」的完整規格，本身就代表你已經知道很多答案。

那些答案，才是這 30 天真正要一件一件釐清的東西。

所以有些看起來像繞路的步驟，我會刻意保留下來。例如：先用假資料把介面和需求跑過一次，再決定資料庫結構。這不是故意拖慢，而是因為需求還沒被驗證以前，太早把資料結構定死，後面很可能還是得跟著重改。

但也有另一種繞路，是可以避免的。可能是錯的技術選擇，也可能是做到一半才發現前提不成立。這些地方，我會把「為什麼會踩進去、怎麼發現、最後怎麼修」一起寫下來。

我踩過的坑，你可以用讀的跳過；但那些值得走一次的路，我不會替你省略。

3.3 程式碼不會有太多

這裡不會出現整頁貼上、你根本不會讀的程式碼。取而代之的是三件事：我怎麼把需求和限制說給 AI 聽、我為什麼這樣決定、以及 AI 說做完之後我怎麼確認它真的做對了。

最後一項是我認為這個系列最重要的部分。網路上有很多文章教你怎麼下 prompt、展示 AI 生出了什麼。但幾乎沒有人教你——

AI 說完成了，你要怎麼知道它真的完成了？

所以接下來的文章裡，你會反覆看到三個資訊框：

先別急著叫 AI 寫
在下 prompt 之前，有哪些事是人必須自己決定的。

AI 說完成了，然後呢？
具體怎麼驗證。不是看畫面會動就算，是真的去確認。

換一艘船也適用嗎？
這個原則換成別的產品——記帳、預約、客戶管理——還成不成立。

還有一件事：我會盡量寫那些不會過期的部分。

買網域有好多家可以選，部署平台也不只一個，連 AI 工具本身都還在每個月換介面。我會說我用了什麼、大致怎麼操作，但不會把篇幅花在那些一年後就長得不一樣的步驟上。

真正會花時間講的是三件事：為什麼需要這一步、選的時候該比較什麼、做完之後要怎麼確認它真的成功了。

因為工具一直在換，但這些判斷不會。

4. 這份日誌，為誰而寫

• 用 AI 做過東西，但不確定它夠不夠好的人。
  你已經做出過能跑的網站，但心裡隱約知道有些地方不太對，只是說不出來哪裡不對。
• 想開始，但不知道從哪下手的人。
  看過很多教學，每一個都從不同的地方開始，你不確定自己該先學什麼。
• 想看一次完整過程的人。
  從一個想法，到真的有人在用，中間到底發生了什麼。

我不預設你有完整的軟體工程背景，也不要求你先把 React、SQL、部署那一整套學完才開始。但我也不會因為這樣，就把真正重要的東西拿掉。

但我也要先說清楚：不是每個產品都需要走完這 30 天。

如果你只是要做一個介紹頁、作品集或活動網站，Wix、Framer，甚至現在的一站式 AI 建站工具，可能才是更合理的選擇。能用現成的船抵達目的地，就沒有必要自己從木板開始造。

這個系列真正想處理的，是當需求開始超出模板——有自己的資料結構、使用者、權限、商業邏輯，甚至必須長期維護——你至少該知道哪些事情正在發生。

不是每個人都需要自己造船。但當你開始改船的結構，你最好知道自己正在拆什麼。

結語

船很小，海很大，而老虎就在你對面。

接下來的 30 天，可能會有幾次迷航，可能會有幾次得把做好的東西重新拆掉再來。但比起漫無目的地划，我想試試看——先弄清楚方向，再讓牠幫我划。

明天，在學會和這頭老虎合作之前，我們先把救生艇上的東西全部攤開來看。

Day 02，我們要清點船上的物資。 Model、Prompt、Context、Tools、Agent、Harness —— 我們每天都在說「AI」，但其實常常把不同層的東西混在一起。明天，我們先把它們一個一個拆開來看：它到底在想什麼、看得到什麼、又為什麼能從回答問題，變成真的動手做事。最後，也會聊聊面對每天都在更新的模型，到底該怎麼選。

模型排行榜每個月都在變。但理解它們的方式，不會。

我們明天見。