這是 Whilst 系列的第二篇。第一篇講了為什麼做這個產品，這篇講怎麼做出來的。
我有 HTML 和 CSS 的基礎，但從來沒有獨立部署過任何東西。GitHub 對我來說是一個「工程師用的東西」，Supabase 是什麼我完全不知道，更別說資料庫或認證系統。
這篇文章記錄的是一個設計師，從零開始，第一次獨立把一個有後端、有認證、有資料庫的產品推上線的過程。不是教學，是真實紀錄，包括卡住的地方和來回七次才解決的問題。
整個過程從 Claude Chat 開始，不是 Claude Code。
這個選擇很自然，因為 Claude Chat 零設定，打開就用。我不需要裝任何東西，不需要連 repo，不需要知道 git 是什麼。我只需要開始對話。
但工作方式很重要。我很快發現，直接叫 Claude 做，和先和它討論，結果差很多。
直接叫它做的問題是，它會做出一個東西，但那個東西不一定是你真正想要的。然後你說不對，它改，你說還是不對，它再改。來回很多次，浪費的時間比你以為的多。
我後來養成了一個習慣：先討論，確認後再實作。
例如我想改 tab 的結構，我不會說「幫我把三個 tab 改成兩個」，我會說「我覺得 Now / Monthly / Annual 三個 tab 有點問題，你怎麼看？」然後我們討論為什麼，哪個 tab 的內容可以合併，用戶體驗上有什麼影響。討論完之後，我確認方向對了，才說「好，現在開始實作」。
這個習慣省了我非常多時間。
Claude Chat 的另一個優勢是速度。生成一整個 HTML 檔案，修改特定的 CSS，加入新的功能，速度非常快。這個階段的目標是驗證概念，快速看到東西長什麼樣子，Chat 完全夠用。
但它有一個明顯的限制：每次改完，我需要手動下載檔案，然後手動上傳 GitHub。一開始改動不多，還可以接受。但當 whilst.html 越來越長，改動越來越頻繁，這個手動流程就變得很痛苦。
在說 Claude Code 之前，要先說 GitHub，雖然以前有看過別人放檔案在上面，但自己實際上手，還是非常陌生。
Repository（repo）是你的專案的家，所有檔案都放在這裡。
Commit 是一個存檔點。每次你對檔案做了修改，commit 就是把這個修改記錄下來，附上一句說明。
Branch 是平行的版本。main branch 是你的主要版本，你可以在其他 branch 上測試新功能，確認沒問題再合併回去。
Push 是把你本地的修改上傳到 GitHub。
這是很多第一次用 GitHub 的人會卡住的地方。
GitHub 不讓你直接用密碼推檔案，你需要產生一個 Token（個人存取令牌）來驗證身份。步驟是：GitHub > Settings > Developer settings > Personal access tokens > Generate new token。
選擇需要的權限，通常是 repo，然後把產生的 token 複製下來。注意，這個 token 只會顯示一次，關掉頁面就看不到了，要馬上儲存在安全的地方。
我最後選擇在 terminal 自己 push，而不是讓 Claude Code 直接處理。原因是 token 是很敏感的憑證，我不想把它傳給任何工具，即使是 Claude Code。這是一個個人的隱私判斷，你可以有不同的選擇。
GitHub Pages 讓你可以免費把 repo 裡的 HTML 檔案變成一個可以訪問的網址。設定很簡單：repo > Settings > Pages > 選擇 branch 和資料夾 > 儲存。幾分鐘後，你的網站就上線了。
如果你有自己的域名，可以在 Custom domain 那裡填入，然後去你的域名服務商（我用 Namecheap）設定 DNS，加入四個 A Record 指向 GitHub 的伺服器 IP，再加一個 CNAME 指向你的 GitHub Pages 網址。
DNS 設定完之後需要等待傳播，通常幾十分鐘到幾個小時。這段時間你什麼都不能做，只能等。第一次等的時候很焦慮，不知道有沒有設對。後來刷新一下，看到 whilst.work 跑起來了。
那個瞬間有點不真實。
我的建議是：不要等到遇到問題才遷移。
我當初是因為手動下載上傳太麻煩才換到 Claude Code，但如果重來，我會更早做這個決定。一旦你確定這個專案要認真做，立刻設定 Claude Code 環境，比遇到摩擦再轉更省時間。
Claude Chat 是對話介面，它幫你生成內容，但檔案在哪裡、怎麼管理，是你的事。
Claude Code 可以直接讀你電腦裡的檔案，修改它們，然後直接執行 git 指令。它不只是給你建議，它可以直接動手。
安裝很簡單：
npm install -g @anthropic/claude-code然後在你的專案資料夾裡執行 claude，它就啟動了。如果你不知道怎麼用 Terminal 安裝，你也可以詢問 Claude Code，它會一步一步教你。
這是我覺得最重要的一步，也是很多人沒有想到的。
Claude Code 和 Claude Chat 不共享對話記錄。當你從 Chat 遷移到 Code，所有的背景、設計決策、技術架構，Code 完全不知道。如果你不告訴它，它就是一個剛認識你的陌生人。
解法是 CLAUDE.md，一個放在 repo 根目錄的文件。Claude Code 每次啟動都會自動讀取它，裡面寫了什麼，它就知道什麼。
我的 CLAUDE.md 包含：
Whilst 是什麼，設計哲學是什麼
完整的色彩系統和字體規範
Supabase 的設定和 table 結構
i18n 系統的邏輯（地域與多國語系）
所有重要的設計決策和原因
常見任務的操作方式（怎麼加翻譯、怎麼部署）
寫得越詳細，Claude Code 就越能在不問你問題的情況下做出正確的決定。這個文件應該在概念確定之後就開始寫，而不是遷移之後才補。這個 md 其實也可以請 Claude Chat 依據過去聊天記錄，直接幫你生成。
Claude Chat 生成 HTML 的速度比 Claude Code 快。這不是錯覺，Chat 的介面就是針對快速生成優化的。
但 Claude Code 的價值不在速度，在整合。它讀你的本地檔案，直接修改，直接 push，整個開發流程是連貫的。你不需要複製貼上，不需要下載上傳，改了就是改了。
在做 Whilst 之前，我對「後端」的認識只有一個模糊的概念：資料存在某個地方，有一個伺服器在處理。
Supabase 讓這件事變得具體。
Supabase 的 Dashboard 第一次打開的時候，我覺得有點複雜。左邊有一排 tab：Table Editor、SQL Editor、Authentication、Storage、Edge Functions，每一個都是一個新的世界。
但我不需要一次全部搞懂。Claude 幫我一步一步建好我需要的部分。
Table（資料表）就是一個試算表。每一行是一筆資料，每一列是一個欄位。Whilst 有六個 table：用戶資料、onboarding 答案、消費記錄、月度反思、靈魂問答、七天追問佇列。
RLS（Row Level Security）是資料的存取規則。它確保每個用戶只能看到自己的資料。設定好之後，就算有人知道你的資料庫網址，也沒辦法看到別人的資料。
Authentication 是登入系統。Supabase 內建 email 登入，你不需要自己寫任何驗證邏輯，接上 SDK 就可以用。
我測試了第一次註冊，填了 email 和密碼，按下 Create account。
幾秒後，信箱收到一封信。寄件人：Supabase Auth。標題：Confirm your signup。
我愣了一下。這是真的認證信，還是測試信？打開來，裡面是一行連結，沒有任何 Whilst 的風格，完全不像一個產品發出來的信。
後來我才知道，Supabase 預設的郵件模板就是這樣。但你可以在 Authentication > Email Templates 裡自訂，改成你的品牌名稱、你設計的文案。
這個細節很小，但很重要。第一次收到認證信的用戶，如果看到的是「Supabase Auth」，信任感會直接打折。
還有一個容易漏掉的設定：Authentication > URL Configuration > Site URL，要改成你的正式網址（例如 whilst.work）。如果沒改，認證信裡的連結會指向 localhost，用戶點了會看到錯誤頁面。我就是因為這個卡了一下
。
設計決策是你有判斷力的地方。你知道用戶體驗上什麼感覺對，你知道哪個方向符合產品的精神。Claude 的角色是幫你分析、提供可能性，但最後的選擇是你的。
Whilst 原本有三個 tab：Now、Monthly、Annual。我覺得哪裡不對，但說不清楚。我沒有直接叫 Claude 改，我說：「我覺得這三個 tab 有點問題，你怎麼看？」
我們討論了好幾輪。Monthly 和 Annual 其實是同一個維度，只是時間範圍不同，放在兩個 tab 讓結構顯得臃腫。Annual report 不是用戶每天都需要看的東西，更適合作為延伸。
最後的結構是兩個 tab：Now 和 Mirror。Mirror 裡面有三個層次，用滾動分隔。
這個決定是我確認的，不是 Claude 決定的。如果我直接叫它改，它大概會做出一個它覺得合理的版本，不一定是我想要的。
用了一段時間之後，我發現 Whilst 有兩個入口點問題。
第一，薪資一旦設定就無法修改。
第二，登入入口藏在 Mirror tab 的最底部，用戶幾乎不會發現。
我把這些問題丟給 Claude，一起討論可能的解法。
Claude 建議，把登入提示放在「北極星卡片」下方，或是「stats grid」下方。我進一步問它哪個比較好，它的回答很有意思：
北極星卡片是情緒性的，那個空間在傳遞你最珍視的是什麼。
如果馬上接一個登入提示，會像廣告打斷沉思。stats grid 是資料區。用戶剛看完數字，這時候出現提示，會更有說服力。
數字讓提示有了重量。
這是一個很好的 UX 判斷。但再往下想一步，我發現問題不只是「提示應該放哪裡」而是 Mirror tab 本身，混在一起兩種完全不同的東西：一種是反思內容：本月報告、靈魂問題、年度回顧。另一種是系統設定：帳號、薪資。
前者是情感的，後者是行政的。把這兩件事放在同一個空間，本身就不太對。
所以最後的決定不是「把提示放哪」，而是把帳號和薪資移到 navigation bar 的 menu 裡。讓 Mirror tab 回到一件事：只留下反思，沒有設定的雜訊。
這些判斷，Claude 不會自己做。它可以幫你推理、比較、甚至提出很好的理由。但「產品應該是什麼」，還是需要你來定義方向。
技術決策是你不知道問題在哪的時候。你只知道「看起來不對」或「沒有效果」，但不知道原因。這時候你完全依賴 Claude 去診斷，它找到原因，你確認這個解釋說得通，然後讓它修。
Whilst 的 onboarding 有一個 fixed footer，顯示 Back 和 Continue 按鈕。問題是 footer 的顏色比背景深，看起來像浮在頁面上的一塊深色板子。
我們改了七次。改透明度、改顏色、加毛玻璃效果，都不對。
最後找到的根本原因是：body::after 有一個全頁的 grain 紋理疊層，z-index: 9999，蓋在所有東西上面，包括 footer，讓它顯得更深。
解法是把 grain 的 z-index 從 9999 降到 9，footer 的 z-index 設成 10000。
七次之後解決的問題，原因是兩行 CSS。這個診斷過程我完全沒有能力自己做，我只能描述症狀，讓 Claude 找原因。
我想讓按鈕固定在頁面底部，用了 position: fixed，但完全沒有效果。
原因是：position: fixed 的參照點是 viewport，但如果父元素有 overflow: auto，參照點就會變成那個父元素。我的 .screen.active 有 overflow-y: auto，這破壞了 fixed 定位。
這是我以前寫 HTML/CSS 從來沒有搞清楚的東西。我不會自己找到這個原因，但 Claude 解釋之後我理解了，而且之後再遇到類似問題，我自己就知道方向了。
設計決策，你在用自己的判斷力。Claude 可以給你選項，但它不知道你的用戶是誰、你的產品精神是什麼、什麼感覺對。這些只有你知道。
技術決策，你在用 Claude 的診斷能力。它知道 CSS 的運作原理，知道 JavaScript 的執行邏輯，知道哪裡可能出問題。這些你不需要自己學會，但你需要能夠理解它的解釋，確認方向是對的。
很多設計師用 AI 會把這兩種搞混——把技術決策交給自己判斷（然後卡住），或者把設計決策完全交給 AI（然後做出來的東西沒有靈魂）。
不管是設計還是技術，有一件事是共通的：AI 生成的東西需要人來驗證，不能假設一次到位。
我每隔一段時間就會叫 Claude 做一次全面的 code review，或者把用了一段時間的 app 截圖給它看，問「你有沒有發現什麼問題」。每次都會發現東西——async function 沒有 await、翻譯沒有套到、id 對應不上。
不是因為 Claude 做得不好，而是 HTML 越來越長，context window 有限，每次修改都可能影響其他地方。
這不是失敗，是迭代的本質。真正的問題是不 review，以為沒有問題。
而後來才知道，Claude Chat 重點在於「快速」，它的程式不一定精準，主要呈現 prototype 為主，如果真的要上線，建議回到 Claude Code，會有更精準嚴謹的程式撰寫，這也是為什麼，Claude Code 會花更久的時間生成網頁。
這是我覺得整篇文章最值得記下來的部分。
這一點我在前面說過，但值得再說一次。遇到一個需要決策的問題，先問「你怎麼看」，不要先說「幫我做」。討論清楚之後再動手，省的時間比你想的多。
如果你覺得某個地方有問題但說不清楚，可以叫 Claude 先「列出你發現的所有問題」，不要實作，只列清單。你看過清單之後確認哪些要修、哪些順序先後，再開始動手。
HTML 越長，Claude 能同時看到的範圍就越有限。這不是 Claude 的缺點，是所有語言模型的物理限制。
實際影響是：如果你叫它掃描整個檔案找問題，它可能漏掉後半段的東西。解法是分區塊處理，或者把需要一起看的東西放在相近的位置。
每次重要的改動之後，自己測試。不要假設 Claude 改好了就沒問題了。它改的地方可能是對的，但改動可能影響了其他地方。
Claude Chat：概念討論、文案撰寫、快速生成原型。 Claude Code：本地檔案整合、部署、長期維護。 ChatGPT：圖像生成（我的 OG 圖是用 ChatGPT Image 做的，然後用 Claude 更新 metadata）。
沒有一個工具能做所有事。知道各自的強項，比強迫一個工具做它不擅長的事更有效率。
用 Claude Chat 驗證概念和做第一版原型 不需要裝任何東西，對話就能出 HTML。這個階段的目標是快速看到東西，不是部署。
一旦決定認真做，立刻設定 Claude Code 不要等到遇到部署摩擦再換。早一點建立本地環境，後面的每一次修改都直接 push，省掉手動下載上傳的摩擦。
CLAUDE.md 在概念確定後就開始寫 不要等遷移後才補。越早寫，Claude Code 能做的事就越多，問你的問題就越少。
技術不懂就直接問 「什麼是 RLS」、「z-index 是怎麼運作的」、「GitHub Token 要怎麼產生」，這些問題 Claude 都可以解釋，而且會用你能理解的方式解釋。不懂不是問題，不問才是。
定期做 code review 不是等出問題才看，而是定期叫 Claude 做一次全面掃描。越早發現越容易修。
把 whilst.work 推上線的那一刻，我有一種奇怪的感覺。
不是成就感，更接近「原來如此」。原來這件事可以做到。原來後端不是只有工程師才懂的東西。原來 GitHub 的那些概念，用一個下午就可以搞清楚。
工具降低了門檻，但門檻不是零。你還是需要有清楚的想法，知道你要做什麼、為什麼、什麼時候停下來問問題。AI 做不到的是判斷，哪個設計方向對、哪個 bug 值得現在修、哪個功能可以之後再說。
這些判斷，還是你的。
作為設計師，我的價值一直都不是寫 code。是知道用戶需要什麼，知道什麼設計決策背後有什麼取捨，知道什麼時候「夠好」就是夠好。
這些工具讓我可以把這些判斷，直接變成一個真實存在的東西。而不是停在設計稿裡，等待一個工程師有空的那一天。
Whilst 在 whilst.work。它的第一個問題是：你這輩子，最不想錯過的是什麼？
我是 Chun-Chuan，台灣設計師，在倫敦工作第八年。 寫職涯、財務、還有那些在工作與自由之間說不清楚的事。 如果你也在35-45歲之間，感覺不上不下，我的分享或許有你想看的東西。歡迎訂閱我的故事，我會持續書寫。
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.