Day 1 的文章，從一個情境出發：跟 AI 說一句話，幾分鐘後真的有一個網站跑出來，按鈕會動，版面有模有樣。

然後呢？

這 30 天，我想處理的就是這三個字。今天是最後一天，想聊聊撰寫這個系列文章時的一些心得、那些刻意保留的繞路，以及走完之後，我怎麼回答這個問題。

一、其實去年就想寫這個系列

這個系列，其實去年就想寫了，只是一直沒有時間，再加上當時也一直沒有想到完整的文章架構去安排整個系列。

晚了一年，反而讓我看清楚一件事：模型以及開發工具進步得真的非常快。回頭去看了一下去年先寫好的一些草稿，我花了不少篇幅介紹當時最熱門的模型、哪個工具有哪些按鈕/指令、哪種指令/模式很好用。一年後回頭看，其實那時候的內容放到現在都似乎有些過時了。（去年寫的草稿很多內容都被我捨棄了

正因為變得這麼快，今年在安排文章的架構的時候，我不斷問自己：有什麼東西，不會跟著一起過期？

所以這次開賽前，我就決定重點不是放在某個 AI 開發工具的操作手冊，而是寫那些模型換了之後還可能存在的問題：資料放哪裡、權限怎麼切、哪些東西能相信、怎麼確認沒有改壞，以及出了問題怎麼知道。Day 1 寫過一句話，到今天我還是這樣想：工具一直在換，但這些判斷不會。

這種寫法，其實也跟我自己學網站開發的方式很像。說起來，我開發網站的時間其實嚴格來說還不到兩年。這段時間裡，很多套件、工具，都不是我先學會才用的，而是從一個個問題出發：「我想讓使用者只看到自己的資料，該怎麼做？」「網站壞掉的時候，有沒有辦法第一時間知道？」我把問題丟給 AI，請它告訴我有哪些做法、各自差在哪裡、有哪些優缺點 / Trade Off？，再去試、去分析、去確認。

我覺得除了學習工具如何操作，還有一件很重要的是知道自己想解決什麼。問題想清楚了，AI 可以幫你找到路；問題不清楚，再強的 AI 也只能猜。這也是為什麼這個系列，很多篇都是從一個問題開始，不是從一個工具開始。（而且其實文章中提到的工具，通常也都有很多選擇，並不唯一）

二、那些刻意保留的繞路

這 30 天，有不少時候我是故意先用很簡單的 Prompt，讓 AI 做出一個「能跑，但少了某些東西」的版本：資料寫死在前端、每張專輯沒有自己的網址、登入之後誰都能看別人的收藏。

這不是因為不知道答案。Day 1 說過：要先寫出一份「一次就能做到位」的完整規格，本身就代表你已經知道很多答案。如果一開始就把答案全部塞進規格，讀者只會看到結果，看不到每個決定是怎麼來的。先讓問題浮出來，才講得清楚它為什麼是問題。

老實說，這 30 天裡，真正交給 AI 寫程式的時間其實不多，大部分時間花在整理觀念、確認做法、寫清楚文章怎麼安排。

如果已經知道要做什麼、哪些地方不能漏，以目前 Biashelf 實作的規模來看，實作時間其實可以壓的更少，甚至到幾天內。真正花時間的，往往不是把程式碼打出來，而是想清楚要做什麼、怎麼驗證，以及哪些地方不能只看表面上「能跑」。

但這個「幾天內」的前提，是已經知道答案。寫程式的速度，AI 已經幫我們拉得很快了；真正決定快慢的，是知不知道自己要什麼、要注意什麼。

寫文章的過程，其實也在逼我重新整理自己。很多事情做久了會變成直覺，但要寫給別人看，就不能只說「反正這樣比較好」，得重新問自己：為什麼？不這樣做會怎樣？有沒有例外？

但走完這 30 天，那些答案你已經有了。下次開始自己的專案時，就可以不用再繞同樣的路。再開始一次，Prompt 不一定會變得更華麗，只是會多一些已經知道不能漏掉的條件，例如：

我想做一個 K-pop 專輯查詢網站，先不要寫程式，先討論架構。
- 每張專輯有自己的網址；資料放資料庫，不寫死在前端
- 會員只看得到自己的收藏；管理員權限在伺服器和資料庫檢查
- 秘密金鑰不能出現在前端或 repo；目前不需要 App 和金流
請列出建議的架構，以及我還沒想到的地方。

不過也不一定要在第一天就把所有東西規劃好。要提前講好的，是那些一定會遇到、之後很難改的事，像網址結構、資料放哪裡、權限誰來檢查；還不確定要不要做的功能，可以請 AI 先記住，之後再來處理。

三、AI 會寫程式之後，我個人認為很重要的四件事

3.1 思考：找出問題在哪裡

這 30 天裡，大部分的程式碼是 AI 寫的。但「這裡是不是怪怪的」「為什麼會這樣」「還有哪裡沒想到」，這些還是要思考。傳出去的網址只會回到首頁、自己看頁面正常但爬蟲看不到內容，很多問題不會直接寫著「我是問題」，要先有人注意到結果和預期不一樣。

知道自己想解決什麼、實作的結果想像中長什麼樣子，才問得出好問題。AI 讓我不用親手寫每一行程式，但沒有讓「理解自己在做什麼」變得不重要。

3.2 表達：把事情想清楚，再說清楚

Day 1 開頭那幾句話：「這個不對，你再改一下」「剛剛明明是好的，你怎麼改壞了？」對自己來說可能很清楚，對 AI 來說幾乎沒有可以操作的資訊。

這一路寫下來，我越來越覺得，所謂的 Prompt 能力，很大一部分其實就是把事情想清楚，再說清楚：哪裡怪、預期應該怎樣、哪些地方不要動、要先分析還是直接改、怎樣才算完成。

3.3 判斷：哪個答案值得相信

AI 很擅長產生選項：像之前三種設計風格、分析出來的兩份資安報告、好幾種快取策略。但要留哪一個、接受什麼風險，多多少少還是需要由人去決定、判斷。

例如 Day 14 三個 AI 做出三種設計，要選哪一個？哪一種我覺得比較好看？三種模型的設計各自有哪些直得留住的細節？；Day 26 兩份資安報告結論不同，要確認哪個問題真的成立。AI 都能分析，但最後接受哪個答案，還是自己的工作。程式產生得越快，越需要快速判斷它值不值得留下。當然，很多時候 AI 也能輔助判斷，但他們的判斷的依據是否合理、是否正確，通常需要有相關的知識才能夠去辨別。

3.4 行動：動手驗證，也真的推出去

Day 1 問過：AI 說完成了，你要怎麼知道它真的完成了？答案通常不是再問 AI 一次，而是去找證據：用真的手機測、換別的帳號試、故意弄壞一次看監控會不會響。

行動也包括把東西真的做出來。一個停在 localhost 的專案，不會遇到 DNS、寄信、爬蟲、真實使用者這些問題；上線之後，才會知道自己還不知道什麼。

這 30 天示範的，也只是其中一條路。換成一種開發工具、換別的框架、資料庫或 AI，一樣可能可以開發出你想要的工具；比較不會變的，是那些一直回來的問題。工具換了，會遇到的問題通常還是那幾個。

四、回到「然後呢？」

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

我認為答案就是這一路走過的每一站：網址、資料庫、登入與權限、部署、寄信、測試、資安、監控、成本。

但比起這張清單，我覺得更重要的，是這 30 天一直在重複的那個動作：

畫面出來了，然後呢？資料存起來了，然後呢？登入了，然後呢？上線了，然後呢？

走完這 30 天，我的答案並不是「學更多 Prompt」，而是：知道下一個問題在哪裡。

換成別的產品，問題很可能就會不一樣。電商不是商品頁做出來就結束，接下來會問：付錢之後呢？記帳工具不是能新增一筆支出就結束，接下來會問：換一台手機，資料還在嗎？線上課程不是影片能播放就結束，接下來會問：誰有資格看？進度怎麼記？想要添加筆記功能，要怎麼做？

產品不同，「然後呢？」也不同；但習慣去找下一個問題，這件事是一樣的。

Day 1 也寫過：不一定要能從零親手寫出每一行程式，但要知道有這回事、知道該要求什麼，也知道怎麼確認它做對了。30 天後，我還是這樣想。

五、之後

一開始，搜輯 Biashelf 只是為了這個系列找的示範專案。選 K-pop 專輯，是因為這是我自己真的遇過的小麻煩，而且公開寫開發過程，也不會影響我手上的其他專案。

但一路把網域、登入、權限、寄信、CI、監控真的接上去之後，它慢慢不太像一個 demo 了。

它還有很多沒做完的地方，我可能會繼續慢慢補下去。鐵人賽替它畫了一條 30 天的路線，但網站不會因為 Day 30 就停下來。

結語

這 30 天，這個專案從一個能跑的畫面，變成了一個有網域、有登入、有權限、有監控的網站。但比起它多了哪些功能，我更想傳達的，是那個反覆出現的習慣：每做完一步，就再問一次「然後呢？」

模型會更強，工具會一直換，今天文章裡的某些操作，很有可能明年可能就不一樣了。但找出問題、把它說清楚、判斷答案、動手確認，這些比較不太會因為換了一個 AI 就失效。

謝謝這 30 天一路看到這裡的你。

我們下一趟旅途見。