用 Claude 搬移網站——從設計障礙到上線的過程
重建網站與搬遷的過程
說到要搬移網站，真的想了好久。
卡關的點不是技術，是設計。我不是設計師，每次打開 Figma 或者找模板，腦袋就開始打結——哪個顏色組合看起來不俗氣？字型要怎麼搭？這種「我知道我要什麼、但不知道怎麼做出來」的感覺，讓搬網站這件事一拖再拖。
直到幾個月前，Claude 推出了Claude Design 功能——原本只是玩玩看，沒想到一發不可收拾，一下子打破了我的心理障礙。
為什麼要搬離 Ghost？
我的舊網站建在 Ghost 平台上。Ghost 是個不錯的部落格平台，但慢慢地，它的限制開始讓我有點煩躁：
版型太死板 — 設計總是看起來像「部落格」，很難同時放個人介紹、目前的服務項目和文章
不好延伸 — 我未來想加更多功能（課程、申請流程、想放自己其他的專案），但 Ghost 的彈性有限
Fake signup — Ghost 的訂閱功能，不知道為什麼引來一堆假信箱，官方論壇上也在討論這個問題
再來是身爲幫公司建立成長marketing的工程師，有點受不了自己的網站user flow亂七八糟的(笑)。總而言之，想要重建網站這件事一拖再拖，有很大原因是因為，我不會設計但是卻有很明確想要的使用者流程。
Claude Design：從零開始設計系統
幾個月前，Claude release了Claude Design，（還讓Figma 股價大跌）。本來只是玩玩看，結果一發不可收拾。
我把自己的審美偏好告訴 Claude——我喜歡什麼感覺的網站、什麼顏色讓我舒服、希望傳達什麼氛圍。Claude 幫我生成了一套完整的設計系統：
顏色系統（以暖赭色系
oklch為主色，帶有一點大地感）中英文字型搭配（英文用 Newsreader、中文搭配系統字體）
間距、圓角、按鈕、卡片的設計規範
當下設計完覺得很好看，做完之後發現跟Claude自己的設計很像，忍不住猜Claude design出來有可能都差不多這樣的顏色組合。
Design system
在做之前我就知道，我需要一套「設計系統」——簡單說，就是設計規則的說明書。網站的所有元素（按鈕、顏色、間距、卡片……）都遵循這套規則，這樣整個網站才看起來一致。
Claude Design 大部分時候都能輸出完整的設計系統，但有個小問題——它有時候會忘記更新。比如某個頁面需要新的按鈕樣式，它就直接設計了，卻沒有把這個新元素加回設計系統裡。
所以之後我在 Claude 的Agent （CLAUDE.MD)裡特別強調：每當有新設計元素，都要同步更新設計系統。這樣才能保持一致性。
我現在的Design system長這樣
我覺得最有幫助的是comments 和markup功能，可以直接在頁面上圈起來就條整，基本上就很像在用Figma時會跟Designer一起刁細節跟流程。
大致上可以看到設計出來之後跟現在的還是差滿多的，因為在製作過程中我還是會不斷地校正自己想要狀態，我覺得大致出來之後就可以把檔案載下來、開始用Claude code製作了。
Claude Code：架設 Next.js + Vercel
設計確認之後，就是真正的架設。把檔案載下來，指定一個資料夾，我直接告訴Claude code 用 Next.js + Vercel 的組合，還有我所有文章都會用marke down的檔案去做讀取：
Next.js ：頁面結構清楚，靜態生成讓速度很快，還有edge function如果之後想要做後端應用也可以直接使用
Vercel：這個就是Nextjs 部署的無腦選擇，免費的plan其實能用的還是滿多的，介面超簡單。
基礎架設滿順利的——以前用過 Next.js，所以上手快。比較特別的是，我為了實現後來加的「申請服務表單」功能，額外整合了：
Resend — 用來自動寄確認信和提醒信的一個Email 服務
Redis — 一個資料庫，用來暫存「申請狀態」（有點驚訝這在vercel裡面也是在免費方案裡）
轉移文章
這個環節看起來應該最簡單，但其實滿繁瑣的。我直接告訴Claude 所有文章都用純 Markdown 檔案儲存，一篇文章一個檔案。因為內容幾乎是靜態的，不需要額外的資料庫或伺服器。
轉移過程：
從 Ghost 後台匯出所有文章（JSON 格式）
直接丟給 Claude，要求轉成 Markdown——一篇文章一個檔案
轉換完就能直接放進他在project底下設好的folder裡，讓文章頁面自己去讀取
一些繁瑣的調整
圖片
Ghost 的某些文章圖片確實放在它的伺服器上，搬過來後連結就斷掉了。但幸運的是，我大部分圖片早就放在 Cloudinary（圖片管裡平台），使用的時候就是用URL，所以轉換時自動保留。
但是以往我還是有懶得上傳到Cloudinary的時候，所以有滿多圖片是缺失的，內文是沒關係。首圖缺失的我就直接叫Claude 用AI生成。它一開始建議我用Chagpt 或是 Nanobanana，但我說我要免費可以拿到的Api，最後使用Leonardo.ai，上去他們平台測試了一些prompt ，跟Claude code一起調整、產出無片。
所以缺失的圖片流程就變成-> 使用Leonardo.ai 產生圖片 -> 上傳到Cloudinary -> 加到文章的markdown裡面使用。
這個流程我後來也整理成skill，當我想要發佈文章時，Claude就可以使用這個skill 一次幫我把圖片跟發佈做完。
URL 不能變
文章的URL不能變，不然SEO全都會消失、還有之前的文章互相連結、外部連結等，這裡一開始Claude並沒有調整好，所以我還要再提醒它要完整保留 Ghost 的文章網址。
把 Substack 文章也納進來
我目前在 Substack 上有兩個 publication：
「邊走邊寫」 — 為自己記錄的內容，讀者直接在 Substack 訂閱就好，所以讀者能夠在我的網站看到、並且連結過去substack就好。
「海外職涯小信箱」 — 針對想找我的受眾，所以希望這些文章也能被 Google 搜尋到，因此要整個搬過來現在的網站。
搬文章的整個流程：
用 Substack API 抓取文章
在海外職涯信箱的文章上，加上 Canonical URL——告訴 Google「原文在我的網站」，這樣搜尋流量才會導向我的網站而不是 Substack
把海外職涯信箱的文章搬過來、圖片連結換成Cloudinary 的連結
只用Cloudinary的圖片是，在Cloudinary的URL直接轉換size，不要載入過大的圖片Size
再掃一遍文章，加上 AI 搜尋友善的 FAQ section（Google AI Overview 會從 FAQ 抽取答案）
把這整個流程建立成 Skill，這樣以後新增文章時可以重複使用
最後用 Claude Schedule 設定每週自動執行，讓新 Substack 文章自動同步到網站
這樣一來，一篇文章就能在 Substack、我的網站、Google 搜尋上都出現——對讀者和流量都是三贏。
順便優化了過去的 SEO
搬家時發現，以前的 SEO 做得其實滿馬虎的。趁這個機會，讓 Claude 掃過所有文章，補上更好的 meta description、關鍵字，還針對 AI 搜尋補了一些相關的內容。
安全性：防止機器人污染數據
加了申請表單之後，我最擔心的是被機器人和假信箱填充。要是數百個假信箱湧入，我的 email list 品質就毀了，後續 email marketing 的轉化率也會跟著下降，所以我讓 Claude 幫我加了簡單的驗證機制來過濾垃圾提交。
已經進一年沒有碰自己的網站，我查了一下 Google Analytics，發現有大量來自中國的流量。但這些流量的 engagement time接近零，明顯都是機器人。
我不想讓這些 bot 流量污染我的數據，影響真實用戶的指標判斷。所以我又叫 Claude 加了 middleware，直接在後端擋掉這些可疑的地理位置流量，還有在robots.txt擋掉一些中國的機器人。
(雖然我的流量是少的可憐，其實沒什麼好track的就是了lol)
自動化服務申請流程
網站架好之後，我手癢又加了一個功能——直接在網站上讓有興趣的人填表申請服務。其實是有些滿好用的表單第三方服務的，但是遵循所謂的Enginners don’t pay 自己架比較好玩。
表單不只問名字和信箱，而是一套完整的篩選問卷：
你的背景是什麼
你想達成什麼目標
預算範圍
時間表
填完之後，系統會自動：
寄確認信給申請者（「我收到你的申請了」）
記錄申請狀態（我能追蹤誰申請了、進度到哪裡）
如果 72 小時沒有後續互動，自動寄提醒信
填完自動加入到我的Notion 紀錄起來
比起讓申請者在外部工具（比如 Calendly）填表，直接在我的網站上申請會更直覺、更不容易流失。整個流程也自動化了——我不用手動寄確認信或提醒。
Claude 推薦用 Resend 服務寄信，免費額度夠用，比起其他郵件服務便宜很多。只是整個流程測試和修復花了一些時間。
Web Performance 的優化
網站上線後，我跑了 Google 的 PageSpeed Insights，行動版只有 55 分。
果然不看code ，第一次用AI直出的效能是有限的，說實話，以我目前的流量體量，這個分數對實際用戶體驗的影響其實有限。只是作為一個在意細節的工程師，我完全無法接受一個新網站的performance這麼差（笑）。
更改幾個項目：
字體載入太慢
網站在下載字體檔案時，頁面被「卡住」了，使用Next/font載入。圖片檔案巨大
雖然已經用Claudinary改過圖片size了，但是在HTML加上預先塞入的tag，可以讓首圖優先載入，增加分數。CSS 檔案肥胖症
Claude把整個網站的樣式規則都塞在一個global檔案裡，導致每一頁都得載入所有規則（即使只用到其中 10%）。改成「按頁面分割」——首頁只載首頁的樣式，文章頁只載文章的樣式。死亡 CSS
有些已經刪掉的頁面，它們的樣式規則還掛在檔案裡。清掉這些孤兒規則，檔案立刻少了 100 多行。
優化之後
Desktop：100 分
Mobile：77 分
在做下去大概就over engineering（畢竟沒流量對SEO的影響近乎為0)，但看到一百分還是很爽。
Claude MD 檔案
發現好像很多人不知道這件事，但是Claude.md (open AI 叫做AGENT.md)檔案，像是一本「工作筆記本」，他會記得你的context，所以不用一直重複同樣的指示。
可是很多人不知道的是，每次你發 prompt，這個檔案都會被包進每一個請求，也就是說，你的每一個跟AI的對話 token 用量會增加。
所以除非只在真的很需要全域規則時，才把它加到 Claude.md，而這個專案的Claude目前為止，我覺得只適用於這個專案，所以也不會把Claude.md 加到專案以外的檔案夾（不放到全域的設定裡）
我在專案的 Claude.md 裡加的規則：
遵循design system的設計規則，任何新設計元素都要同步到設計系統
改動網站時要考慮 SEO、GEO(AI 搜尋友善）和效能影響
所有圖片一律用 Cloudinary 連結
當然這個檔案我也是讓AI自己產生。
建立 Skill 和自動化流程
在整個過程中，有一些重複使用到的地方，我都會建立 Skill。像是圖片生成這件事，除了現在用得上，之後再新增文章時也會繼續使用。
同樣的，Substack 文章搬移屬於之後每週會用到的流程，我也建立了對應的 Skill，然後再Claude的Schedule裡排程這個流程。
最主要的這個publish article工作流，分享在這裡：
每次發布文章，流程從 `temp/` 資料夾開始：先確認要發哪篇，接著做 SEO 分析，把 slug、標題、摘要、tags 逐一確認好。如果文章裡有 Obsidian 的 `![[圖片]]` 語法，會先把圖片上傳到 Cloudinary 再替換連結，沒有圖片就直接跳過。接著生成 GEO FAQ（用 `article-takeaway` 的 HTML 格式），寫入 `content/posts/`，再用 Leonardo.ai 生成封面圖上傳。全部備妥後，啟動本機伺服器讓你到 `localhost:3000/<slug>` 親眼確認排版和圖片都正常，我說 OK 之後才會進到 commit 和 push 的確認——兩個動作分開問，可以只 commit 不推、或一次推上線。因為是邊做邊產生Skill 所以有一種做完才有流程的感覺，下次我想應該要先自己畫完流程圖讓AI根據對話跟流程圖去建立skill，會更有效率。
現在的流程還有些human check的部分，但使用幾次後，讓skill學習，應該最後只會留下preview的部分。
結語
過程中，我一直忍住不去看code，直接把cursor的檔案都關掉了，只該對話窗跟預覽窗。（工作時不能做的事...)
有時候AI還是滿笨的，像是在做feature表格的時候，Claude 說「資料已送出」，但我去後台一查，其實 API 失敗了，用戶根本沒有收到確認信。這不是 Resend 的問題，而是我們沒有驗證 API 回應。所以我在 Claude.md 加了一條規則：所有 API 呼叫都必須驗證成功或失敗，才能顯示給用戶。
還有一次，Claude 重複造輪子——Next.js 本身就會自動壓縮 CSS，它卻還要再跑一次 gzip。
我都是用edit auto ，所以Claude 還是需要詢問我問題的狀態，而不是全部auto mode ，主要也是自己有毛lol 但是也因此知道他的這些小問題，然後再加進去Claude.md 裡面去做改善，讓它越來越聰明。
這些看似瑣碎的規則，每加一條都讓 Claude 的表現更穩定。下次做網站時，我已經有一套「經過驗證的工作流程」——省掉所有前面踩過的坑。我估計下一個網站的時間會快至少一倍。
這次重架網站，主要可能自己毛很多，要一直提醒自己這麼小的站，不要做太多啊！所以還是花了兩週，但是比起以前對設計的要求、CTA、UX、 growth 的設計等等，還是真是快很多！不然自己搞真的要搞很久。而且玩過一次後，建網站的速度只會越來越快。
新網站真是高顏值！我最近也在思考要不要更新陪伴多年的Wordpress，讀到這篇覺得來的正是時候🤩
這篇文章含金量好高！希望之後能出手把手線上課程