30 天到了。這篇不照前面的「今天要解的問題、想法與取捨……」五段模板，想回頭看看這一個月，也說說之後會繼續做什麼。
寫文章，逼我補上 vibe-coding 的落差
以前用 AI vibe-coding，我常常略過它的實作細節和裡面用到的技術。通常是看過 plan、驗證結果是對的，就讓它 go 了。
這 30 篇的產文流程剛好反過來：每篇都要 AI 回頭整理 session 裡的資訊，我再從頭爬一遍、梳理內容。爬的過程中，常常發現我腦中的想法和 AI 實際做的東西中間有落差，例如 Day7 測試全綠、功能卻永遠是空的，或是 Day16 連設計 handoff 本身都要先驗證。把這些落差寫出來，才算真的理解自己做了什麼。這個流程我覺得蠻實用的，賽後也會繼續用。
這是個美好的時代
寫扣也快十年了。以前想做 side project，總是被技術的橫溝擋住所有想法：腦中只有想法，卻無法輸出成作品。中間要花的技術力與學習時間，和作品做出來之後的成就感完全不對等，是痛苦的。
現在能在 AI vibe-coding 的時代做這些事，真的是個美好的時代。Day1 盤點時手上是四個專案，到今天 Projects 頁上已經有十個。
造輪子，是在養品味
現在很多人說 vibe-coding 就是不斷地重造輪子，做出相似的東西。這點我是接受的，因為我自己也一樣在造輪子。
但透過造輪子的過程，我知道哪裡是關鍵處、哪裡最影響體驗，也知道自己到底喜歡什麼、不喜歡什麼。品味，是透過不斷接觸各種樣本，去理解它存在的目的。
像是 travel-storage，我在 Day21 加了「往下滑就收起」的固定列，Day23 實際拿手機用過一輪後又拿掉。就是在這個過程中，我才理解隱藏 header 可能的潛在風險：卡、不知道東西去哪了。所以直接嘗試、有錯出現，勇敢改掉。
我把養品味拆成四步：
- 接觸樣本。 就是看越多做越多。
- 理解樣本。 可以借用行業內的框架去剖析，像咖啡用的杯測表（coffee-review 的 Day6、Day15）、藝術常用的顏色與線條判斷，都是幫我們拆解樣本的工具。一個人可以看一萬幅畫卻沒有增長，只因為那些東西沒有透過系統化的方式在腦子裡刻下來，如流水般過去的看過。
- 勇敢嘗試去實作、去表達。 去試錯，去調整。
- 知道東西有適合與不適合的場景，但真的很爛的東西就是真的很爛。 用 3px 的小字當內文，這就是真的很爛，眼睛會被破壞。
感想先說到這，接下來是技術上的心得。
資安
- 有了 AI，要攻破一個網站其實很簡單。 特別是 vibe-coding 出來的東西，常常沒考慮到太多情況。
- token 外流。 有些人會直接在對話裡丟 token 請 AI 操作，這個超級危險。建議還是先建
.env把機敏資訊收起來，並且主動問 AI 有沒有機敏資訊外流的風險。除了 token，如果有使用者資料，也要想 API 認證有沒有做好，避免使用者拿手上的 auth 取得別人的資料。AI 會知道怎麼改，但重點是你有沒有這個意識。 - 有接資料庫的網站，我現在預設都綁 auth。 之前用過密碼、也用過 email／password（Day1 的架構表），但我個人很容易忘記，所以都改成 Google 登入（登入擋在哪一層，見 Day4 與 Day12）。如果開成 public，我會擔心被攻擊、資料庫被塞爆、被亂用。雖然已經有用 schema 去防範，但還是多加一層保險。
- secret 不要進 code。 用 GitHub secret 或部署平台的 secret 機制（Day3 的
wrangler secret put、Day4 部署用的 GitHub secrets）。看過有人把 LLM token 寫在程式碼裡，而且是寫在前端呼叫的地方，這樣風險就很大。
成本
- 小型網站，HTML 配 JSON 就夠了。 只是靜態頁、或需要吃一點資料，可以用 JSON 當資料庫，改 JSON 就等於更新資料，很方便。travel-storage 在 Day24 改成「外殼＋JSON」就是這樣。
- 只要有輸入付款資訊的地方，一定要設 budget alert 與 budget limit。 避免 LLM／agent 被人攻擊打爆，或是程式有 bug、開了一堆服務狂收費。
- 資料庫放哪裡。 我之前用 Supabase，免費方案有限制，覺得很麻煩，所以計畫陸續全部搬到 Cloudflare（Day3、Day12）。
- 和 AI 溝通的成本。 side project 都小小的，沒有很複雜，基本上用不完我的 Max plan。真正的成本在方向：我要做新功能，一定用內建的 plan 模式，來來回回確認每個細節都符合我的要求，才讓 AI 執行（Day15 的方案被推翻五六次，Day23 的計畫被我退回六次，Day25 也退回過）。之前太多次直接開 auto，Claude 一頓猛做，把網站整個帶歪方向，最後是直接 reset 才救回來。
- 一定開 worktree。 worktree 是我現在覺得 git 很重要的一環，同時開發好幾個功能時，只有 worktree 能做好隔離（Day13、Day18）。
UIUX
- 手機和電腦是兩套導覽。 記得直接互用，體驗就是不好，要記得做 RWD，至於要不要做平板，就看個人。部落格在 Day20 補了手機的漢堡選單；travel-storage 在 Day23 因為一顆按鈕超出 13px、整頁能左右滑，之後改版面前都要在四種寬度量過。
- 做中學。 UIUX 就是不斷地做、不斷地和 Claude Design 溝通（Day25 的 /blogs/ 就是在 Claude Design 跑了三輪才定稿）。我其實不太了解前端底層的運作與邏輯，之後可能會找一本完整講框架的前端書來看。
- 先知道有哪些東西可以調。 顏色、按鈕的凹凸與框線、點擊與滑動……UIUX 的重點是你知道有哪些是可以調整的。像 Claude Code 的 mod（Day26～Day28），我花了不少時間去了解哪些地方是我能動的，還有面板該是我想像中 fancy 的 HTML，還是單純的 markdown。這個探索與記錄很重要：知道可以設定什麼，才有機會做出更貼近自己工作流程的東西。
- 實際使用。 這是 UIUX 萬年不變的定理。travel-storage 也是改完、實際用過之後爆改一波，最後甚至把 Day19 定下的「一趟旅行一個 HTML」單檔架構，在 Day24 整個砍掉，去貼近使用者習慣的操作方式。
- 但使用者習慣不一定是正確答案。 那只是約定俗成，都可以調整。像 travel-storage 原本以「回來後的紀錄」為主，實際用下來我只看行前指南，Day22 就把指南升成主角。
功能開發
要打磨自己的產品，得有想像力，對那個領域的品味也要夠。
AI 可以幫忙發想，但它提出來的常常偏向防守型、穩定型的功能，像是離線存取、資料檢索優化，coffee-review 開發時它就問過我要不要加入離線存取。這些都蠻重要的，但如果想讓產品真的破圈，只有這樣不行。需要更多想像力，理解痛點、解決它，然後持續打磨操作體驗。像 Day2 動工前先想清楚 art-tracking 給誰用、首頁要不要逼我表態；Day22 的目標是少切頁面、打開就是當天行程，都是從痛點出發。
沒有好的操作體驗，內容再豐富也沒用。想想沒套 CSS／JS 的 HTML 網站，就像人只有骨架，根本讓人提不起勁，甚至反感。
接下來
鐵人賽結束，但這些專案不會停，這個系列之後也會繼續在 kiwi-walk.com 更新！
- 繼續用寫文章來回顧 session。 「讓 AI 整理、我再爬一遍」這個流程會留著，新的文章一樣放在部落格上。
- 補前端的基本功，找一本完整的框架書來讀。
- 繼續養 llm-wiki（Day10）和 navi（Day27）。 這個月我的 llm-wiki 幫了很多忙：面對品味的培養、價值觀的反思、知識的交疊，都有突飛猛進的進步。期望 navi 之後能幫我越來越多。
動手吧
這是最好的時代，同時也是最讓人淪陷的時代。各種 AI 生成的快速，誘惑著每個人的多巴胺；卻也讓每個人都擁有足夠的工具，把自己的想法蓋在電腦上。
實作的過程中，要不斷問自己哪裡喜歡、哪裡不喜歡，挑戰自己的品味；同時也需要好的輸入，就像 Day17 說的，引擎要有人加燃料。
所以就開始動手做吧。就算是從一個 iPhone 捷徑開始，從對話裡生成一個 HTML 檔開始，都是開始。沒有開始的那一天，腦中的靈感就只是垃圾。唯有真正面對之後，才會知道靈感的想像有多空泛；你也會因此更敬佩每個行業裡的每個人，因為每件我們習以為常的事，其實都是無數嘗試堆疊出來的結果。
動手吧。
(終於結束了)