AI 新手魔法師的 Vibe Coding 教戰守則：從零開始自架個人網站

Vibe Coding × AI：讓非工程師也能打造專屬網站

近期意識到 Agent Indexing 對長文的引用的長尾效應很高、是個潛在商機，同時想重新把以前做 SEO 的觀念撿回來練手，在兩週前決定使用 Claude.ai 自架個人網站（就是這個網站！），想在 2025 年養成固定寫作的習慣並累積流量。

「變現的可能」以及「AI 時代下的內容策略該如何做」是兩個我想透過此專案驗證的假設，同時我也深信 Dogfooding 是做好產品的不二法門，唯有自己也苦過他人之苦，才會真正理解 Vibe Coders 使用者的流程痛點何在。

Uber 首席產品官 Sachin Kansal 以「extreme dogfooding」聞名，他親自完成了近千次 Uber 駕駛和送餐服務，將每個痛點截圖記錄，撰寫 40 頁報告並追蹤改善進度。他接受 Lenny 專訪時提到：「我們要求終端使用者使用的產品，我們自己也應該使用。當 App 在時速 70 英里的移動車輛中運行時，感覺和在辦公室裡做產品是完全不同的」。（很推薦閱讀這篇專訪的摘要）

我早在 2020 年就購買過 thelingwu.com 這個網域並且串接 Wordpress 後臺作為內容管理，也上稿過幾篇當時訪談同時的文章（叫做實習開箱計畫）。那是個還沒有 AI 的時代，我用 Google Meet 和 Iphone 錄音程式，再使用雅婷逐字稿整理，就這樣也寫了 4 篇左右的訪談文章。

後來因對 Wordpress 後臺的 UX 流程深感痛苦，因此決定不再續約，自己撰寫 Blog 的計畫也就隨著疫情、畢業、當兵、出國而擱置。我從 2024 年 3 月還在倫敦時，就規劃要做個人網站很長一段時間，一開始初步研究後仍無法評斷投入成本多大，同時覺得 Ghost.io 既有的模板不符合需求，因此將規劃一再拖延到 2025 的 2 月，直到在 Zeabur 轉正後，我初步嘗試製作了第一個 Vibe Coding 小專案 Customised URL Shortener。

到了五月底，我在某晚失眠之際，打開 Claude 詢問這件事的執行步驟，而後就這樣踏上整整一週以新手魔法師身份的 Vibe Coding 閉關修煉之路。

我也想透過自己實作的經驗，告訴所有對 Vibe Coding 止步不前的夥伴，不管你是行銷還是設計人，其實這件事的上手門檻遠小於你的恐懼！

產品需求拆解：如何用 AI 規劃網站功能與架構

基於第一次製作產品的經驗，我會說在進入實作前，先釐清自己對產品的想像、以及背後的需求，重要性遠大過於直接先動手製作。過程中我也採了不少坑，因此這裡用後設視角分享，如果進一步要迭代，我會在最初先怎麼做研究。本次專案我總共使用了這些工具：

- 技術工具

  - Next.js + React：現代前端框架（管理視覺、網站 UI 交互的程式碼）

  - Ghost.io：內容管理平台（管理文章上稿、追蹤者管理的後臺，主要需求是簡潔的介面）

  - Zeabur：一鍵部署平台

  - Github：程式碼集散地

- 寫程式的 AI 工具

  - Claude.ai：AI 程式助手

  - Windsurf：程式編輯器（我會把 Claude 生成的程式碼丟入給 Windsurf 微調）

  - Perplexity：百科全書

自架網站的系統選擇：什麼是 Headless CMS？為什麼選 Ghost.io？

使用過 Wordpress 及 Webflow 編輯與管理過內容，我深刻知道自己討厭使用不合習慣的系統，我最偏好的形式是 Medium 那樣的編輯器，也會希望有能管理內容及追蹤者的後臺。與此同時，又需要能完全客製化 UI 設計及 UX 交互邏輯的前端介面，這必須和內容是分開管理的（最好我一次定好介面如何顯示，之後就不再需要做更動），這牽涉到兩個概念：

• Headless CMS：「內容倉庫」的角色，你專心寫好內容，至於要印成報紙、做成網站、App，還是電子看板，都交給不同的前端程式碼決定（兩者間透過 API 來串接）
• 傳統 CMS ：內容和展示都綁在一起的「報紙編輯部」，你需要在寫完內容的同時，處理排版、視覺的問題

選用 Ghost.io 則是考慮到「平臺的開源性」以及「操作簡易性」，完全免費之外，還具有內容創作者最需要的追蹤者管理系統，同時可以直接發佈電子報。

常見的前端框架選擇：React、Angular、Vue

前端語言是我的知識盲區，由於背景及技術相關經驗是「曾經以 Project Manager 角色帶過產品專案，因此知道基本的前、後端及 Design Library 等知識」，並且我做過 SEO 及內容行銷因此對「Google Analytics 及 Search Console 等平臺有基本認知」，然而更細節的程式碼彼此優劣差異等工程理論，我完全一竅不通。

也因此，我最初先花了一小時的時間，理解並評估何種框架較符合我的需求。

沒錯，技術背景的朋友光看我問的方式就能理解我的程度到哪 XD，前端語言只有 HTML（靜態呈現）、CSS（視覺風格）、Javasript（動態交互）三種，只是在將三者應用到不同規模的專案時，會考慮效能及維修難易度將其「包裝」成不同「框架」，但本質上的邏輯、也就是程式語言本身，都是相同的。

這裡另補充一點，我最後選定 Next.js + React 的組合，主要是這個 combo 是現在市面上最主流的搭配，同時最適合簡易 UX 交互需求的專案（沒有要做很浮誇的動態特效）

在決定完工具組合後，我訂下整體工作流並分為兩類：

1. 寫程式：丟需求給 Claude 撰寫 -> 進 Windsurf -> 開 Localhost 檢視問題 -> 小問題 Typo 直接 Windsurf 修改、大問題邏輯返還給 Claude 解析
2. 資訊研究：反白 Claude 的某理論框架 -> 丟 Perplexity 解析背後邏輯 -> 反查比對資料來源確認可信度

AI 需求翻譯器：將「需求」拆解成「功能」，再翻譯成「程式碼」

這是一個你用 AI 就能寫出高精細度產品的年代，這篇 Arstrun 的文章提到了好幾個在不同垂直領域內 Vibe Coding 出來的產品，在臺灣市場近期也有像焦慮戳戳樂、Introly.me 等有趣的產品。

這週恰好和朋友聊到「產品的品味」這件事，在 AI 當道的時刻、我覺得對產品的美感與對細節的注意，這兩個關於 UX 使用者體驗的要素是至關重要的，而在兩要素背後更重要的是如何在一步步的過程中，將 UX mindset 時刻放在刻印出產品的流程內，而非在製作完成後才試著要使用者貼著產品流程走。

這裡先提，我在實作這個專案以前，對 Repository 一詞只停留在「一包程式碼以及放置它的地方」這個印象

所有做產品的人，一開始都會花很多時間將「需求」翻譯成「網站功能」，再透過 AI 將其轉換成「Repo」的形式。而這次我想做的網站其實功能很簡單，只需要：

• 主頁
• Writing Page 文章總覽頁面
• Project Page 專案總覽頁面

但近一步拆解後，新增了：

• 主頁
  • 主頁本身
  • Sidebar 側欄
• Writing Page 文章總覽頁面
  • 每一篇文章具體的頁面
• Project Page 專案總覽頁面
  • 每一項專案具體的頁面

將視覺、ghost 串接、SEO 等功能放入後，1、2、3 就成了這樣（笑）

先別驚慌（1、2、3 的量級單位是週），我這裡想分享一個常見、重要且易忽略的步驟「找產品參考」，這裏的找參考也反映了前面提及的品味及對體驗細節的重視，以我為例：

• 網站的結構與功能，我找了 Brian Lovin 的個人網站並且也找到他的開源程式碼（我很喜歡該站的側欄 RWD 響應式交互的設計）
• 網站的視覺，我找了 Another Lane 的配色與字級

我將前者丟入 Claude 請它分析該網站的架構及實踐步驟，將功能拆解成「Repo」的格式，並且請 Claude 解釋背後的邏輯，而後才進入具體的對話環節。

Prompt Engineering 工程實戰：下對指令讓 AI 聽懂你的網站需求

防雷資訊，如果我真的知道何謂「對的 Prompt」那我大概也不會用到 17 個達上限的對話串來做這個專案。

但確實在來回對話中，我有重新檢視應該用怎麼樣的 Prompt 來達成 Vibe Coding 過程中最重要的兩個目的：拓展我不知道的知識、確認邏輯正確與否。

實例一：我怎麼請 Claude.ai 幫我產生元件或功能

在上古時代，工程師會抱怨產品經理永遠不知道該怎麼正確做事，而產品經理則覺得工程師很難溝通、能力不到位。

很多時候，對產品新手來說最大的問題不在不知道想要什麼，而是「不知道這個功能該怎麼做」，技術一點來說就是「不知道該如何翻譯成 Repo」，而這種「我沒辦法知道我不知道的事」的悖論，在以前沒有 AI 的時代（沒錯，真的是不同時代了）很常是產品經理和工程師吵架的原因。同樣的情況在 AI 對話時也會出現，因此應對這種情況，我會這樣下 Prompt：

我想做類似「Ref」這個產品的「XX 功能」，

1. 如果我了解要整併的方向 >>> 請協助我在既有的「XX 功能」下，看這個新功能該如何整併
2. 如果未知 >>> 我不確定在目前的架構下該如何整併，請給予我其他類似案例參考，以及執行建議

---

多半在第一次對話中，就能釐清大致產品迭代的方向

舉個實際案例，我在製作 Sidebar 側邊欄位時，最初毫無頭緒這個側欄的程式碼應該「長在哪個 Repo 內」，因此我丟了 Ref 並延伸詢問了不同製作同樣功能的方式，最後選定符合我需求的版本往下進行。

實例二：我如何用 Claude.ai 修正語法或辯證錯誤

不用擔心卡住、紅字錯誤，也不用自己內耗，直接截圖丟回去就對了，所有工程師最開始學習也是這樣。這邊講個笑話，以前上古時代有個東西叫 Stackoverflow。

總共 17 次達到上限的對話，很大部分都是在做 debug，最頭先我一定都是讓 Claude 生成完整程式碼後，不動腦地原地貼上。然而，在進行到專案中後期，你會漸漸開始掌握起做整件事的手感，一部分是你很熟悉了整個專案 Repo 的架構，不再依賴 AI 提供給純新手無腦複製的超長程式碼全文。

另一部分則是會發現很多時候錯誤都是重複出現的，像是 typo、指令或函示呼叫不到、路徑依賴錯誤等等，這些其實都是你實作到後期，經歷過無數次紅字、並且在紅字之中發現熟悉面孔時，累積的經驗。

後來為了避免對話太快達到上限，同時節省迭代成本，我都這樣下 Prompt：

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

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

---

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

上述這兩塊 Prompting 方法，是我花了整整一週彙整出適合我思考、解決問題方法的兩種策略，但我相信每個人在 Prompt Engineering 這塊都會有屬於自己的 Vibe，而這也是整個修煉過程中最有趣（但當然也是最累）的一件事！

新手卡關經驗談：常見問題與解決心法

我現在可以很大聲的說我至少是個 Vibe Coding 初階魔法師，也因此我完全能體會新手上路時會遇到的困境。

不要照單全收 AI 產生的程式碼

將 AI Agent 化，而不是將 AI 變成你的大腦，它是輔助你思考、執行的角色而非取代神經中樞的外置大腦。

永遠記得保持獨立思考及至少 50% 清醒的腦袋！寫程式很困難，複雜的點在於你不確定程式到底字裡行間在做什麼，而翻譯當然能交予 AI 執行，將撰寫複雜程式碼的繁瑣工作交給它完全沒錯，但思考產品架構、規定執行方向、確定錯誤不會一再反覆出現（會反覆出現代表產品結構有效能問題，要在後續改善），是 Vibe Coding 流程中人與 AI 協力下最重要的一環。

不會 git、前後端程式語言也能做出網站

沒錯，我就是連 HTML CSS Javascript 都花了時間去理解、爬梳邏輯的零技術背景初心者，這確實讓我在初期會比至少有 git 或 python 經驗的人稍微起步慢些，但我在執行到專案中後期後，發現其實更重要的技能反而是「Prompt 的管理」，而這個管理往後一層又反應了你是否確實了解產品及需求，以及是否具有良好的專案管理方法。

拔掉最初看似高聳的技術門檻後，剩下的就是在競爭誰的需求拆分明確、誰的管理方法有效率。

透過反覆辯證判斷自己卡在哪個環節

Vibe Coding 到某個環節，你一定會進入一種「我是誰，我在哪」的神遊狀態，這時你的程式碼大概會處在 half done 凌亂無比的狀態，這是所有非技術背景的人都會經歷過的「絕望之谷」，或者可說是 Vibe Coders 的撞牆期。沒有不二法門，唯有繼續將 Vibe Code 一條路走到底。

這個時期因著產品的複雜度而有差異，我在第一個短網址生成器大概只卡了總時長 3 小時中的 1 小時，而在這個專案裡則卡了大約 6-10 個小時左右（也就是 6/5 週四我熬夜的那天），並且也因爲這次我太在意 UX 交互邏輯上的各種細節，因此花費不少時間在修改易用性問題。

總之，這篇文章大致分享了我作為非技術背景的 Vibe Coder 新手閉關修煉的心法，希望能為「也想自架網站」或「做出小產品」的你有幫助，頭先洗下去就對了！接下來我會在 Zeabur 的 Guest Blog 上分享整個網站架構的功能拆解，以及更細節的執行步驟，以及我預計未來想擴充做的迭代更新。

推薦閱讀

• 這篇 Vibe Coding Case Study: ScubaDuck 用工程師的視角分享 Human AI Interaction 的方式，並且給出關於 Prompting 的建議
• 也建議讀這篇 I Built My Blog Using "Vibe Coding" Dev 社群上的另一篇新手教戰守則