在 AI 的時代，越來越多人可以透過 Vibe Coding，替自己生活中的小麻煩做出一個解法，不一定要先成為工程師。

搜輯 Biashelf 也是這樣開始的。在專輯店買專輯的時候，我常常想查一張專輯有哪些版本、裡面附了什麼，卻總要翻好幾個網站。於是我想：來做一個吧。

做出一個能跑的版本，其實不用太久；但要讓它真的上線、讓別人用、出事時知道、還養得起，中間還有很多事。28 天後，它有了網域、登入、權限、測試和監控，也開始想怎麼養活自己。

今天我們要把這些分散的篇章進行總整理，看看除了工具之外，還有什麼值得帶走的。

一、這 28 天分享了什麼

AI 很會完成我們說出口的需求，但它不一定知道我們沒說出口的未來。叫它做一個專輯網站，它很快就能做出一個能跑的版本；但每張專輯要有自己的網址、要能登入收藏、要被搜尋引擎找到，這些如果沒說，它不一定會先想到。

能跑跟能長大是兩件事，能用跟好用也是。在 localhost 裡，網站只要能跑就好；公開之後，它開始需要更多東西：

• 找得到：網域、DNS、SEO
• 進得去：部署、登入
• 不被亂用：驗證、權限、資安
• 壞掉有人知道：錯誤監控
• 改版不會偷偷壞：分支、CI 與測試
• 養得起：成本、用量與營收

1.1 先看整張地圖

1.2 貫穿全系列的觀念

有些觀念不特別屬於哪一個領域，而是在不同的天數裡，用不同的樣子反覆出現：

先搞清楚誰說了算

同一個狀態，可以存在網址、瀏覽器、快取和資料庫裡，但重要的事只能有一個最後的答案。搜尋條件以網址為準（Day 11）；快取只是暫存，真正的資料在資料庫（Day 22）；付款成功頁不算數，驗證過的金流通知和資料庫裡的訂單狀態才算（Day 28）。

重要規則不能只靠前端守住

前端負責讓事情變得好用；不能交給使用者自己決定的事，要留在可信任的一側。送進來的資料（Day 17）、誰能看哪些資料（Day 19）、誰是管理員（Day 21）、使用者被導回哪個網址（Day 26），都要在伺服器或資料庫再檢查一次。至於篩選條件、要不要打開一個視窗，交給前端就好。

問題修好，留下防線

AI 可以幫我們檢查一次，但能自動化的檢查，盡量寫成測試、放進 CI，才不需要每次人工測試（Day 25）。Day 27 監控網站的錯誤，則是在驗證另一種防線：真的出事時，我會不會知道。

1.3 Biashelf 現在的樣子

【圖 1｜搜輯 Biashelf 的整體架構】

一個「能上線的網站」，背後通常會包含這些零件：放程式的地方、放資料的地方、讓人找得到的網域、寄信收信的服務、上線前自動檢查的流程，以及上線後看得見問題的監控。

二、Vibe Coding 開發過程的觀念清單

把這 28 天的重點，整理成一份清單。下次做自己的專案時，可以拿來對照、思考：

規劃與協作

• 想清楚要解決的問題，以及要做什麼（Day 4）
• 跟 AI 說好哪些事可以自己做、哪些要先問，特別是會動到資料庫的指令（Day 5）
• 讓 AI 大改之前，先開分支（Day 13）

前端

• 資料有明確的型別，不是能顯示就好（Day 9）
• 讓每個內容都有自己的網址，找不到時有 404（Day 10）
• 需要分享、重新整理後要保留的搜尋或篩選狀態，可以放在網址裡（Day 11）
• 載入中、沒有資料、出錯、輸入不合法時，畫面都有處理（Day 17、20）
• 用真的手機測過（Day 12）

後端與資料庫

• 會更新、要跨裝置同步的資料放在資料庫，不是寫死在前端（Day 15）
• 送進來的資料在伺服器端驗證（Day 17）
• 存放使用者資料的表都開了 RLS，並實際用別的帳號測過讀不到（Day 19）
• 管理員這類高權限操作，不只靠畫面隱藏，伺服器和資料庫也會檢查（Day 21）

部署

• 秘密金鑰沒有加上 NEXT_PUBLIC_，也沒有 commit 進 repo（Day 23、26）
• 正式網址、登入的回傳網址都設定正確（Day 23）
• 寄出的信通過 SPF、DKIM、DMARC（Day 24）
• 有 CI，讓測試沒過的版本上不了線（Day 25）

資安

• 做全專案的資安盤點，並判讀、分析過結果（Day 26）
• 第三方套件的漏洞看過、做了決定（Day 26）
• 會被大量送出的功能有頻率限制（Day 26）

營運

• 有 sitemap、robots，私人頁面設定不收錄（Day 27）
• 有錯誤監控，出事時會主動通知（Day 27）
• 知道每個服務什麼時候會開始收費；有提供用量通知的服務，也設好提醒（Day 28）

這份清單只涵蓋系列裡提到的部分；功能越多，要確認的事情通常也會跟著增加。

三、開發過程反覆走過的流程

不管是修 404、設 RLS，還是處理資安報告，做事的步驟其實都差不多：

這不是固定的 SOP，而是我在利用 Vibe Coding 開發時很常走的一個循環。

這七步裡，AI 最能幫上忙的是盤點和實作：它可以很快讀完整個專案、列出選項、寫出程式碼和測試。

AI 也可以參與判斷和驗證，但這兩步不能完全交給 AI。Day 26 讓兩個 AI 審同一份程式碼，一個找到 open redirect、另一個漏掉，對同一個問題的嚴重程度也判斷不同。問過 AI，不等於檢查過；名詞也一樣，它能幫我們找方向，但不能拿來當作結果正確的證據。

另外想補充的是，文章中示範的做法並不是唯一的答案。 就像網址的設計，/search/aespa 和 /search?q=aespa 都可以， 重點不是哪個方法正確，而是哪一種比較適合，並且知道自己為什麼這樣選。 還有像是要先做畫面還是先設計資料庫、用哪個框架、選哪家服務，也都是同樣的道理，並沒有絕對的答案，選適合需求、自己也好上手的就好。

四、不一定要會，但要知道

程式語言的語法，可以交給 AI；但如果連自己做的東西大概長什麼樣子都不知道，就很難判斷功能該放哪裡、哪些地方有風險。AI 大幅降低了上手的成本，但判斷的成本並沒有跟著消失。

而且很多技術，不一定要會從零做出來，但至少要知道它為什麼存在：

AI 通常知道怎麼做，但要我們先知道該問什麼，它才幫得上忙。

五、遺珠：這次沒分享到的事情

前 28 天不是網站或產品開發的全部，而是把一個產品從零帶到線上的主要路徑。下面這些主題，依照「什麼時候會需要」分成四類：

5.1 已經需要，但還沒做完

• 管理員 MFA（多重要素驗證）：除了 email 驗證碼，再輸入驗證器 App 上的一組數字。Supabase 本身就支援，但跟 Day 21 一樣，不能只在登入畫面多問一次，資料庫也要檢查這次登入有沒有通過 MFA。這是上線後我第一個想補的。
• 開發與正式環境分開：目前開發、正式環境共用同一個資料庫，所以 CI 最好不要跑會寫入資料的測試。分成兩個資料庫之後，收藏、回報這類流程也能自動測試。
• 備份與還原：資料庫能正常運作，不代表刪錯資料救得回來。要確認自己的方案有沒有備份、保留多久，最好實際試過一次還原。
• root layout 的登入狀態：它讓大部分頁面都變成每次請求才產生的動態頁面。目前用資料快取減輕負擔，根本的解法是把登入狀態從 root layout 拆出去。

5.2 等產品長大才需要

• 資料的索引與搜尋：資料少的時候查詢都很快，資料多了才會變慢。索引像書的目錄，讓資料庫不用每次從頭翻；也可以先用資料庫本身的全文搜尋。真的需要拼字容錯、更複雜的排序時，才需要考慮 Meilisearch 這類搜尋引擎。
• 排程與背景工作：有些工作要定時執行，例如每週寄摘要信；有些不適合卡在一次請求裡做完，例如大量寄信、影片轉檔，可以丟到背景處理。如果排程是透過網址呼叫，那個網址也要驗證來源，不然任何人都能觸發。（關鍵字：Cron Job）
• 檔案與影片：圖片、PDF 這類檔案，通常放在物件儲存（R2、S3、Supabase Storage），而不是資料庫。影片還要轉檔、產生不同畫質、串流播放，Cloudflare Stream 這類服務就是把整串包起來。簡單說，R2 解決檔案放哪裡，Stream 解決影片怎麼被觀看。（例如想自己架線上課程網站的話，會需要有地方可以儲存。）

5.3 走向其他平台

• App：做手機 App 不一定要重做一套後端。資料庫、登入、API 和部分商業邏輯通常可以共用；畫面和手機特有的功能則要另外處理。
• Monorepo：當網站和 App 開始共用型別、資料存取的程式，可以把兩個專案放進同一個 repo，共用的部分抽成套件。

就像網站有很多種框架，開發 App 也可以選原生的 Swift（iOS）、Kotlin（Android），或跨平台的 Flutter、React Native。開發完要上架，也要先通過 App Store、Google Play 各自的審核。

以往開發 App，通常要找熟悉該語言的工程師；有了 AI，這個門檻低了很多，比較關鍵的反而變成：你知不知道問題在哪、要注意什麼、要怎麼取捨。

5.4 AI 從開發工具變成產品功能

這個系列一直在用 AI 寫程式，但 Biashelf 本身沒有用到 AI 功能。不過在 Vibe Coding 的產品裡，AI 功能是很多人會想加的，例如 AI 客服、依學生的觀看紀錄推薦課程，或例如讓使用者可以輸入「aespa 有哪些專輯附海報」來進行自然語言搜尋。

這類功能通常要串接 AI 的 API（如 Claude API、OpenAI API、OpenRouter），用多少付多少，所以要多想幾件事：用量和成本要設上限；提示注入會從「攻擊幫你寫程式的 AI」變成「攻擊你網站裡的 AI」；回答要以資料庫裡的資料為準，不能讓 AI 自己編；哪些使用者資料真的需要送給 AI，也要先想清楚。

結語與明日預告

這 28 天用了很多工具，但工具會換、模型能力也會一直增強，今天整理一些我認為相對之下比較不容易過時的內容：四條貫穿全系列的觀念、從察覺到留下的七個步驟，以及一份「不一定要會，但要知道」的清單。

用 AI 開發，重點不是更相信它，而是知道什麼時候可以相信它、怎麼驗證它說的對不對。

明天是最後一天。不談工具，我想聊聊這次的參賽心得；以及在 AI 已經會寫程式的時代，思考、表達和行動，為什麼反而變得更重要。

我們明天見。