做一個個人網站這件事，在我腦中放了很久。
不是那種用模板拖拖拉拉就上線的網站，而是一個能完整呈現自己作品、經歷、想法的地方。問題是，從「想做」到「開始做」之間，通常有一段很長的猶豫期——不確定要做成什麼樣、不確定技術選型、不確定值不值得花這個時間。
這個系列要記錄的，就是我怎麼跨過這段猶豫，用 Claude Code 加上一堆 AI 工具鏈，從零把這個網站蓋出來。
起點：跟 AI 聊出一個雛形
一開始我只有幾個模糊的想法：要有作品集、要能寫文章、要支援多語系。但這些都太籠統了，直接開工只會寫到一半發現方向不對。
我用了 Claude Code 裡的 brainstorming skill 來做需求收斂。這個工具的運作方式很有意思——它不是一次丟給你一大堆問題，而是每次只問你一個問題，而且盡量用選擇題。
比方說它會問：
這個網站的主要目的是什麼？(A) 純作品集 (B) 部落格為主 (C) 兩者兼具
你需要支援幾種語言？(A) 只要中文 (B) 中英雙語 (C) 三語以上
管理後台需要什麼等級？(A) 直接改 code (B) 簡單的 CMS (C) 完整後台
就這樣一來一回，大概十幾個問題之後，原本模糊的想法就變成了一份具體的需求清單。這個過程的好處是，它逼你在動手之前先把每個面向都想過一遍。很多時候你以為自己想清楚了，被問到具體問題才發現根本沒有。
從需求到設計文件
brainstorming 跑完之後，下一步不是直接寫 code，而是產出一份設計文件（spec）。
這份 spec 會被存到專案的 docs/superpowers/specs/ 目錄下，裡面涵蓋了：
架構選型：用什麼框架、什麼資料庫、為什麼這樣選
資料模型：有哪些 model、彼此的關聯是什麼
頁面規劃：前台有哪些頁面、後台有哪些功能
多語系方案：翻譯怎麼存、怎麼切換、主要語言是哪一個
spec 不用寫得像論文一樣厚，但每個決策都要有依據。比方說為什麼選 Next.js App Router 而不是 Pages Router、為什麼用 Prisma 而不是 Drizzle——這些在後面實作的時候會不斷回來參考。
spec 寫完之後會讓我 review 一遍，確認沒有遺漏或誤解。這一步很重要，因為一旦 spec 定了，後面的實作計畫就是照著它走的。
從設計到實施計畫
spec 確認之後，接著用 plan skill 把它拆成一份可執行的實施計畫。
計畫會被存到 docs/superpowers/plans/ 目錄下，格式是一個個有明確完成條件的任務清單。每個任務都很具體：要改哪些檔案、要寫什麼測試、完成後要驗證什麼。
舉個例子，光是「建立多語系支援」這一項，就會被拆成：
設定 i18n 配置檔（支援 zh-TW、en、ja）
建立 translation group 的 Prisma model
實作 locale 切換的 middleware
在前台頁面串接翻譯內容
在後台加上語系切換的 UI
每一步都是獨立可驗證的——做完一步就可以跑起來確認沒壞，而不是全部做完才發現某個環節接不上。
這個流程解決了什麼
回頭看，「構思 → spec → plan」這條路徑最大的價值是讓你在還沒寫任何一行 code 之前，就把整個專案走過一遍。
以前我做 side project 的習慣是想到什麼就開始寫，寫到一半覺得架構不對就砍掉重來，反覆幾次之後就失去動力放棄了。這次不一樣的是，因為有了 spec 和 plan，開工之後就是照著清單一步步推進，很少回頭改大方向。
當然，計畫不可能完美預測所有狀況，實作過程中還是會遇到需要調整的地方。但有了這個基底，調整的幅度都不大，不會出現那種「做到一半才發現整個方向錯了」的情況。
下一篇會講設計和視覺原型的部分——怎麼用 cinematic-ui 這類工具，把一堆功能需求變成一個實際看得到的介面。