從 Vibe Coding 新手到 Builder 的心態轉折點

本篇適合已經動手做、想解決實作細節的讀者！AI 初心者可以先從這篇需求拆解介紹文開始

我永遠記得 6/5 當天我反覆和 Claude 對話，試著要解決網站 SEO 的效能問題，一直不甘心 PageSpeed 出現 99 以下的分數，硬是撐到隔天早上十一點左右，才真正將效能問題解決

在新手魔法師的 Vibe Coding 教戰守則：從零開始自架個人網站這篇文章中，我分享了從零到一建置出網站的過程，以及在心態上我會建議 Vibe Coding 新手應該做哪些準備。這篇文章我會側重分享具體的執行細節，以及遇到問題時我的解決方案。（附上我用 Perplexity 來回對話整理知識點的對話串）

總而言之，我的 Vibe Coding 故事充滿了咖啡與 AI。

專案全貌：Next.js + Ghost CMS 的 AI Coding 架站流程

我使用 Zeabur 部署完 Ghost.io 後，用 Claude.ai 拆解需求、生成程式碼，最後再進行不同工具的串接（Google Analytics, Search Console 等），以下是整個專案的執行步驟：

- **前端基礎建設與 UI 組件開發**
    - 更新全域樣式（globals.css），建立全新配色系統
    - 新增 Layout 組件，整合 Sidebar、首頁等主要結構
    - 實作 Mobile-First 側邊欄與響應式設計
    - 重構首頁與主版型（layout.tsx）
    - 配置 Tailwind CSS，優化設計系統

- **內容串接與資料流設計**
    - 與 Ghost API 串接，建立資料取得函式
    - 定義 TypeScript 型別，設置環境變數
    - 實作文章列表與動態路由
    - 支援 Ghost 原生區塊（YouTube、Gallery、Button 等）

- **SEO 與結構化資料優化**
    - 設定 SEO 相關內容（metadata、sitemap、robots.txt）
    - 動態產生 sitemap，加入結構化資料
    - 優化 OG 圖片、favicon、社群媒體展示

- **追蹤與效能監控**（後來移動到最後）
    - 加入 Google Analytics 4 追蹤碼，設置自訂事件與轉換
    - 提交 sitemap 至 Google Search Console
    - 測試並驗證 GA 與 SEO 效果
    - Lighthouse、PageSpeed Insights 效能與無障礙優化

- **部署與自動化**
    - 準備部署檔案，設定 GitHub Actions 自動部署
    - 配置 Zeabur 平台、環境變數與網域
    - 持續測試 API 連線、內容更新、OG 圖片顯示

- **進階優化與維護**
    - 統一 metadata 系統與資料服務
    - 實作 API 快取與 revalidate 機制，確保內容即時更新
    - 持續調整設計一致性、效能、可存取性

Vibe Coding 三大挑戰與解法

需求拆解、進一步對應到功能的流程已經在前一篇文章分享，這裡我進一步提供「實際遇到的產品問題」＋「我和 AI 的拆解過程」＋「最後解方」來說明。

Mobile First UX 實戰：Next.js 響應式設計與交互改善

確保不同裝置上的瀏覽體驗、交互邏輯一致，是我在「前端基礎建設與 UI 組件開發」第一步時卡關 3 天的大難關。即便已經先找定交互邏輯以及視覺風格的 reference，實際執行上還是因為前端框架的限制，而必須做出調整

側欄 Sidebar 收合失敗

我原先就知道側欄會是個大門檻，原本想儘可能做的簡單、甚至零交互，但 Claude 直接生成了可收合的版本，我於是花了至少 2-3 小時在修改收合的動態效果上。主要卡關點是在於，要確保手機端點開與收合的效果和桌面端是相同，並確保桌面端預設展開、且有緩存不會因為 refresh 而重置狀態。

Mobile First 下的破版問題

我最後花了一段時間將主頁內容置中於「螢幕扣掉側欄後的中線」，並且在收合側欄時會隨著尺寸動態調整對齊。這個交互邏輯是超級大魔王，我花了超多時間確認在每個裝置尺寸上不會出現破版，並且交互效果有維持一致性。

動態交互的易用性問題

因為想在首頁做兩個簡單的動態交互：動態呼吸的標籤、Hover 時會浮起的頁籤，花了約 2 小時左右處理視覺問題，確保對比度、大小等符合 WCAG 規範及一般的易用性原則。

客戶端與伺服器端的混合渲染的網站結構

在執行到第三、四步驟時，我遇到因網站結構而導致的效能問題。對非技術背景的人來說，這塊會有點生硬，我自己花了不少時間理清背後的邏輯。先再次回顧上篇文章提到的「網站三大元素」：HTML（靜態的網站結構）, CSS（樣式與風格）, Javascript/JS（動態效果）

在對網站三大元素有基本認知的前提下，我試著拆解「若要將網站內容在他人裝置、瀏覽器上載入」這件事，也就是所謂「渲染」一詞背後的邏輯，我們先用「購買傢俱」的例子來理解：

- **客戶端渲染 Client Side Render （CSR, 類似 IKEA 組裝包）**
	你買了一組 IKEA 書桌，收到時只有零件和說明書。你得自己慢慢拼湊，剛開始房間是空的（網頁一開始是空的），等你拼好才有完整書桌（網頁才顯示內容）。
	- **優點**：組好後你要換抽屜、加層板都很快（互動、切換頁面很順暢）
	- **缺點**：一開始得等你慢慢拼（初次載入慢），親友剛來時什麼都看不到
- **伺服器端渲染 Server Side Render（SSR, 類似現成家具直送）**
	你直接叫傢俱行送來組裝好的書桌（完整 HTML），一進門就有完整家具（網頁內容馬上出現），可以馬上用。
	- **優點**：一進門就有東西可看（初次載入快，SEO 友善）
	- **缺點**：要換抽屜、加層板都得再請傢俱行來（每次互動都要伺服器幫忙，互動性沒那麼即時）

前者有利於呈現更細緻的動態交互以提升使用者體驗，後者則是因為能先載入靜態 HTML、因此有利 SEO 搜尋引擎爬取內容。各自有適合使用的場景，而多數人在架設網站時多半會採用混合型。

AI 寫出太髒的 SSR/CSR 混合程式碼

非技術背景的人用 AI 寫程式，很常會遇到的問題是「啊好，AI 寫好了但我還是不知道到底寫了什麼、架構是什麼」，再次 recall 神圖：

我這次也不例外，Claude 一開始生成了邏輯混亂的程式碼，導致我在測試主頁完後往下進行時，一直反覆遇到渲染失敗的問題，我在專案中期左右、待主頁及側欄功能確認後，花了 6-8 小時重新整理原本的架構，並在最後決定採用：

- 首頁：SSR
- 側欄：CSR（另外獨立一個程式碼分開渲染）
- Writing 總覽頁面：CSR
	- Writing 文章頁面：CSR
- Project 總覽頁面：CSR
	- Project 文章頁面：CSR

我聽前端朋友說，CSR 的渲染可以做到單一元件個別渲染，顆粒度能精細到某個按鈕或極小的元件，回顧自己的網站發現我也用了相同的邏輯來處理側欄。關於 Rendering 我這週讀到 Bosh Kuo 對 Next.js 的分享，覺得思緒和拆解的架構十分清楚。

Ghost API 串接與內容呼叫測試

對很多人來說 API 聽起來是個大門檻，但在 Content API 串接上這次我反而沒有遇到太多問題，將 API 串接好、Claude 建議切成不同階段（文章內容請求、載入時間印記）測試，很順利地就完成了。

p.s. 如果不確定 API 或 Webhook 是什麼，要先把知識點補滿再往下進行。

混合模式下的水合問題 Hydration Issue

最後是 SSR/CSR 混用時常見的（後來我才知道這很常見）水合問題，用同樣的傢俱組裝來類比：

我在處理側欄顯示時很常遇到這個問題，簡單來說是因為側欄需要被判讀的狀態以及對應生成的動態效果，和其他靜態的區塊出現先後渲染的問題，後來是使用了判讀收合的函示來解決問題。我也是在這段重新檢視專案結構的環節，邊做邊爬梳背後邏輯並且使用以下的 prompt 進行迭代：

我剛剛執行後遇到「附圖、程式碼 error code」的問題，

1. 如果大概判斷的出錯誤方向 >>> 可能是某某地方出了包，可能是「這類型」的問題
2. 如果判斷不出 >>> 請告訴我如何修改、背後的邏輯為何

---

*如果是較小、非整個程式碼結構的問題，我會直接用 Windsurf 編輯器修改
*如果是結構性問題，我會同時將關聯的程式碼一併檢附

技術 SEO 與網站效能提升

最後一個階段，我反覆用 PageSpeed 測試網站上線後的效能，並試圖讓每個都在 99 分以上（這才是花時間的點ＸＤ）。

圖片載入影響網站效能

一開始在效能上我發現圖片載入和快取是導致效能分數下降的原因，透過新增緩存、延遲載入圖片等，初步先改善了這個問題，並且也對 Image SEO 的外聯連結做調整。

OG Image 的渲染問題

我花了約 4 小時處理連結在不同社群平臺上的渲染問題，一開始是不知為何總是會卡在 Discord 和 LinkedIn 上，後來反覆刷掉快取後就沒問題了。

大概做到這步，整個網站就差不多正式上線了！

Zeabur 部署後的迭代與成效追蹤

GA4 進階追蹤與自動化

我等了約三天，確認先前埋點的設定都正確、有一定流量與事件後，才往下設定 GA 報表，另外也因為我這次想進一步測試且驗證 AI 對 SEO 的影響，因此設定了幾個關鍵行為作為追蹤指標：

Key Events：
- text_selection（文字反白，代表內容被引用或複製）
- ai_referral_traffic（AI 來源流量，判斷 AI 平台帶來的用戶）
- session_quality（會話品質，反映用戶深度互動）
- article_deep_read（深度閱讀，代表內容被認真消化）
- content_completion（內容完成度，代表用戶完整吸收內容）
- cross_content_engagement（跨內容參與，代表用戶有多元內容探索行為）
- brand_search_traffic（品牌搜尋流量，反映品牌力）

主要是想透過「瀏覽完整度」及「文字反白數」來初步檢視看看被檢索及引用的事件有多少。

Rybbit 埋點追蹤

又過了三週，和其他夥伴聊到 Rybbit 這個開源的網站流量檢測器，試用後發現完全是 GA 的 UX 改善版，先同樣把追蹤碼埋進網站，接下來會進一步測試看看是否有更完整的功能。

如果想部署 Rybbit 可以用我們這週剛上架的 Rybbit 模板，用這個更完整、使用者體驗良好的介面來追蹤你的網站流量！

新增文章分類篩選器

先前在拆分 Client 及 Server 端時，有特地在 Writing 的頁面上先預留了後續可以新增標籤分類功能的區塊，接下來想等文章數量多一些後，把這個酷酷的功能更新上去，同時也把文章內的 binge view 下一頁功能完善化，改善閱讀體驗。

給 Vibe Coding 進階 Builder 的三個建議

看到這裡還不頭昏腦脹（或頭痛但繼續閱讀）的你，想必是具備成為 Vibe Coding 進階玩家的意志力！

隨時暫停、確認開發次序

不是每個問題 AI 都能一次解決，會問問題、問題背後的問題，並拆解邏輯，遠比寫程式更重要。舉例來說，偏好對話型 Agent 的我，通常會在最初建立一個「貫穿所有對話串」的「專案腳本」，並且作為對話串的資訊來源，能夠有效在不同對話串以及腦袋失序時，重新拉回專案進度。

如果你會寄望 AI 能解決一切問題而放棄思考，這會讓你即便做出網站，後續要迭代、更新也無法有效瞄準問題、提升效率。

隨手做紀錄與管理

和資深工程師聊到他們覺得最重要的一項技能，既非程式本身、也非對某某工具的掌握度，而是「版本控制」。版本控制指的是，你在做出成功、能運行的版本後，要將其部署上線或儲存好，同時詳細記錄你做了哪些調修。

高度仰賴 AI 生成程式碼、且非技術背景的 Vibe Coder 可能一開始不會碰到這個問題，但隨著程式碼變複雜、出現相互依賴的關係，或甚至有多個迴圈彼此牽扯時，每一次的「正確版本」以及「對該版本的描述」會變得非常重要。

這件事並非透過某工具養成，任何工具皆可，用 Notion 將程式碼複製下來也是一種作法，也不必一開始就強迫自己上手 Github。但不管使用任何工具、任何技術，這個專案管理的心態與方法都是一致且重要的。

多延伸閱讀並反查資訊正確性

使用 AI Agent 彙整完資料後，記得反查內容來源是否有被正確引用，以下是我覺得還不錯值得閱讀的文章：

• 用 ReactJs、Redux 及 NextJs 打造高性能與 SEO 優化的網站應用
• iKala 撰寫的 AI 寫程式新流派 Vibe Coding 介紹
• 新手向的 Cursor Vibe Coding Tutorial - For COMPLETE Beginners
• Reddit 上很詳盡的 Claude AI 使用守則
• Git 版本控制入門教學

以上三點是我從零到一建置網站的過程中最深刻的體會，也推薦給每個想用 AI 做產品的你。

結語：實作才是最好的學習

一直到開發完畢、撰寫完回顧文後，我才算是真正結束這次的 Vibe Coding 修煉，也正式從初心者身份畢業（至少上次和五位工程師一起吃飯大概聽得懂 60% 的內容），我真的搞出自己的個人網站了！最後回顧整個開發的流程，我發現 Vibe Coding 完全是「做中學」的真實演繹。

6/22 週日舉辦 Cursor Meetup Taipei 時，iChef 的 Co-founder Spencer 分享了幾個他自己手上正在做的產品，提到他也透過 AI 探索了很多原本不在守備範圍內的新技術（像是語音辨識、影像生成等等），一位具有 10 年以上開發經驗的前輩都在工作之餘花費這麼多時間學習，真心覺得 Vibe Coding 雖說降低了技術的門檻，但這個技術門檻的突破，影響且助益地仍然是願意持續學習的先行者。