寫給設計師的 Vibe Coding 零基礎指南（一）：基礎、框架、工具

在上一篇設計篇中，我們完成了從設計理念到 Figma 設計稿的全部工作。但設計稿終究只是靜態的圖片，如何讓它變成真正可訪問、可交互的網站？

設計個人網站？看看這份實操指南（設計篇）

以前，這意味着你要學 HTML、CSS、JavaScript，還要懂框架、打包工具、版本控制……光是這些名詞就足以勸退大多數人。

但現在不一樣了。

Vibe Coding 讓“寫代碼”這件事發生了本質變化，你不再需要從零學習編程語言的語法，而是用自然語言描述你的需求，讓 AI 幫你生成代碼、調試問題、優化效果。

但是鋪天蓋地的 Vibe Coding 宣傳，可能讓大家錯誤的以為隨便聊聊就能做一個產品，實際上這是有難度和需要學習相關基礎的，只是在難度上，確實是從未過的簡單了。

這篇開發篇（一），我們不急着寫代碼，而是先夯實基礎。

你不用先學成工程師，也不用背一堆定義。你只要先分清，每一層到底在管什麼，第一次做產品時順序就不會那麼容易走反。

對於設計師來說，這件事可能比你想象的更加容易上手，因為你已經具備 Vibe Coding 所需的能力：

• 你懂設計語言：佈局、間距、顏色、字體——你用這些詞彙描述需求，AI 就能理解
• 你懂組件化思維：Figma 的變體、實例、自動佈局，本質上就是前端開發的組件邏輯
• 你知道你想要什麼：設計稿已經畫好了，你只需要把它描述出來

開發篇我們先把基礎打牢：搞懂技術名詞、理解前後端分工、選對 AI 工具、學會寫 PRD，再掌握 Vibe Coding 技巧。

一、開發入門：需要知道的幾件事

不少設計師第一次讓 AI 幫自己做項目，心情通常是：很興奮，然後很快困惑。

困惑的原因不難理解——你跟 AI 說"幫我做一個作品集網站"，它回覆裏可能同時冒出十幾個你從沒聽過的詞：前端、後端、API、數據庫、部署、域名、環境變量……你還沒來得及消化，AI 已經在推進下一步了。

更麻煩的是，如果你沒有項目方案的思路，AI 大概率不會對你說"你先想清楚再動手"。你描述一個模糊的想法，它也會立刻給出完整方案。這種"有求必應"很容易讓人產生錯覺，覺得自己已經上路了，實際上連方向都還沒確認。

所以這一節，我們不談代碼，先把這些基礎概念用設計師能理解的方式理一遍。搞清楚每個詞負責什麼，後面動手時才不容易走偏。

1.1 網頁的本質：三種語言

網頁的本質由三種語言組成：

舉個例子，你在 Figma 畫了一個卡片組件：一個圓角矩形，裏面有一張圖片、一段標題文字、一個按鈕。

在代碼中：

• HTML 定義「這裏有一個卡片，裏面有圖片、標題、按鈕」
• CSS 定義「卡片是圓角的、有陰影、背景是白色、標題是 16px 加粗」
• JavaScript 定義「點擊按鈕會發生什麼」

這是最基礎的一層。但你很快會發現，光知道這三種語言，還不夠理解一個完整產品是怎麼跑起來的。

1.2 前端、後端、數據庫：三層各管什麼

這是新手最容易纏在一起的三組詞。它們總是同時出現，但其實各管各的事。

先說結論：前端管你給別人看到什麼，後端管事情怎麼在背後流動，數據庫管產品記住什麼。

前端：用戶看到和操作的一切

你在瀏覽器裏看到的每一個像素，都屬於前端。

頁面怎麼排版、按鈕多大、文字什麼顏色、鼠標懸停有沒有動效、點擊之後跳不跳轉——這些全是前端的範疇。換句話說，你在 Figma 裏畫的所有內容，最終都由前端負責呈現。

不少人對前端的印象停留在"把頁面做漂亮"，這其實低估了它。視覺當然重要，但前端更核心的職責是把用戶流程跑通。

作為設計師，前端是你最容易上手的部分。你在 Figma 裏建立的那些習慣——組件化、間距規範、響應式佈局——在前端開發裏幾乎都有對應的概念。你的設計經驗在這裏直接有用武之地。

後端：按鈕背後的邏輯處理

用戶在頁面上點了一個按鈕，接下來發生了什麼？

如果只是跳個連結，前端自己就能搞定。但如果涉及"處理"——比如提交一份表單、請求 AI 生成一段文字、保存一條記錄——這些事情就不是前端能獨立完成的了。這時候就需要後端出場。

後端負責的是接收前端的請求、執行處理邏輯、返回結果。前端告訴你"用戶點了什麼"，後端來決定"接下來該做什麼"。

聽起來很複雜？其實對於設計師做個人網站來說，後端往往只有幾件事：接收請求、調用外部服務（比如 AI 接口）、把結果送回去。不需要一上來就想象一個龐大的系統。

一個簡單的判斷標準：如果你的網站只是展示內容（作品集、個人介紹），可能幾乎不需要後端。如果你要加評論功能、AI 對話、用戶登錄這類"有動作"的功能，後端就開始發揮作用了。

注意區分後端和數據庫——後端是"做事的人"，數據庫是"記錄本"。它們經常一起出現，但不是同一回事。

數據庫：讓產品擁有"記憶"

沒有數據庫的網站，每次刷新都像從零開始——你剛填完的信息沒了，你剛才的操作也忘了。

數據庫解決的就是這個問題：把需要保留的數據存下來，下次還能找回來。用戶註冊的賬號、提交的留言、保存的草稿，這些都需要數據庫來管理。

對於設計師做個人作品集來說，好消息是很多場景暫時用不上數據庫。Astro 這類框架生成的是靜態頁面，內容直接寫在代碼裏就行，刷新也不會丟。

但如果你將來想加功能——比如訪客留言、AI 工具需要記住上一次的輸入——那時候就需要引入數據庫了。

一個實用建議：不用急着在第一天就搭數據庫。先用寫死的數據把頁面和流程跑通，等確認哪些數據確實需要持久保存，再引入數據庫也不遲。

一個例子串起來：從聯繫表單看三層配合

拿設計師網站常見的"聯繫表單"來串一遍，你會發現三層其實很好理解。

前端做的事：展示一個表單，包含姓名、郵箱、留言內容三個輸入框，加一個"發送"按鈕。用戶填完後點擊按鈕，頁面顯示"發送成功"或"發送失敗"。

用戶點擊"發送"之後，前端不會自己發郵件，它只是把用戶填的信息打包，通過一條約定的通道（也就是 API）交給後端處理。

後端做的事：收到前端傳來的信息後，先檢查格式對不對（郵箱是不是合法的），然後調用郵件服務把消息發到你的郵箱。如果發送成功，告訴前端"成了"；如果失敗，告訴前端原因。

數據庫在這裏幹什麼？如果你想把每條留言都存下來，方便以後在後台查看，那後端在發郵件的同時，也會把這條留言寫進數據庫。下次你打開後台，就能看到歷史留言記錄。

如果缺了後端，按鈕點了沒反應；如果缺了數據庫，你永遠只能靠郵箱查看留言。三層各司其職，少了哪一層，體驗都會斷。

這個例子的意義在於：當你聽到"這個功能還不通"的時候，可以試着把它拆開看——是頁面本身的問題，還是背後處理邏輯的問題，還是數據沒存對。這種拆分思維，比記住一堆術語有用得多。

1.3 什麼是框架和組件庫？

框架是什麼？

想象你要建一棟房子：

• 從零開始 = 純手寫 HTML/CSS/JS（自己畫圖紙、買材料、打地基）
• 框架 = 預製模塊化建築系統（已經做好承重結構、水電管線，你只需要拼接房間）

常用的前端框架（設計師只需要瞭解這些）：

組件庫是什麼？

組件庫 = 設計師「組件面板 + 樣式系統」的代碼版。

在 Figma 裏你有一個「按鈕」組件，可以變體出主要、次要、禁用狀態；在代碼裏也一樣，只需要指定 variant="primary" 即可。

常用的組件庫：

設計師視角的類比:

理解了這些，你就可以用 Figma 的思維去理解代碼了。畫設計稿時的「抽離公共組件」= 代碼裏的「封裝複用組件」。

1.4 為什麼選擇 Astro + Tailwind？

我的開源模板使用 Astro 框架搭配 Tailwind CSS，原因很簡單：

Astro 的核心優勢：島嶼架構——只有需要交互的部分才會加載 JavaScript，其餘都是靜態 HTML。所以首屏加載極快、SEO 友好，非常適合個人作品集。

Astro 的另一個優勢：框架無關性——你可以在同一個項目裏混用 React、Vue 或純 HTML + Tailwind，想加 3D 交互時再引入 React 就行。

Tailwind CSS：最適合 AI 的 CSS 方案——傳統 CSS 需要命名和分離文件，而 Tailwind 把樣式直接寫在 HTML 裏，AI 看一眼就能懂。它的設計令牌也和 Figma Variables 完美對應（p-6 對應 spacing/24），改配色時只需要替換配置即可。

1.5 網站做好了怎麼上線：服務器、部署、域名

你在自己電腦上預覽網站，一切正常，但是截至目前你的網站還只活在你自己的電腦裏。

要讓它對外可訪問，需要搞清楚三件事：

• 服務器就是一台永遠在線、對外提供訪問的電腦。你的網站文件需要放在上面，別人才有可能訪問到。常見的平台有 Cloudflare、Vercel、Netlify，提供不同額度的免費方案。
• 部署是把你的代碼從本地電腦搬到服務器的過程，並確保它在服務器上正確運行。這一步相當於"發佈上線"。
• 域名是你給別人看的網址，比如 yourname.com。沒有域名，別人只能用一串不太好記的公網 IP 地址來訪問，域名讓這件事更友好。

三者之間的關係可以這樣理解：服務器是"空間"，部署是"搬進去"，域名是"貼上門牌"。缺了任何一步，別人都打不開你的網站。

一個最簡單直接的流程，Github（上傳代碼）-> Cloudflare（綁定 github）-> 一鍵部署上線（可訪問） ->（可選）綁定域名（Cloudflare 購買域名）

二、AI 編程工具推薦

AI 編程的核心是 模型 + 工具 的組合。模型是大腦，負責理解你的描述；工具是手腳，負責實際修改文件、運行命令。

IDE 與 CLI 的區別

IDE（圖形界面工具）像一個熟悉的代碼編輯器（類似帶 AI 的 VS Code），有窗口、側邊欄，看得見文件結構，操作直觀。代表：Cursor。

CLI（命令行工具）像終端窗口，只用文字對話，簡單專注，靈活性高，能自動處理更多任務。代表：Claude Code、Codex。

兩者都能讓 AI 直接操作你的項目文件。我經常把它們一起用。

主流工具

• Cursor：圖形界面 IDE，適合邊看 Figma 邊讓 AI 生成組件。
• Claude Code：命令行工具，理解複雜需求強，適合調整整個模塊。
• Codex（OpenAI）：輕量 Agent，能自主執行任務和調試。
• Gemini（Google）：免費額度高，適合快速嘗試。
• Kimi，CodeBuddy，TRAE，Qcoder：國產，免費額度大，零基礎友好。

我的建議

如果你想完全免費上手，優先選擇國產 IDE，比如 TRAE（國內版）和 Qcoder 等。這些工具免費額度比較大，中文支持好，各種模式也很適合設計師直接用自然語言描述 Figma 風格，幾乎不需要配置。

如果你能接受小額付費，想獲得更好的使用體驗，IDE 可以考慮 Cursor 或者 TRAE 國際版。Cursor 的編輯器操作最流暢；TRAE 國際版在模型訪問和穩定性上也有提升。

如果預算有限，但又想保持較高性價比，CLI 工具可以優先接入國內各大模型，比如 Kimi、GLM、Qwen 等。這些模型價格便宜，新用戶優惠力度大，日常調整顏色、替換字體、實現簡單交互已經足夠。

截至我寫這篇文章時，如果你追求更強的項目級能力，不太在意成本，那可以直接上 Claude Code 或 Codex。它們在理解複雜需求、多文件重構和項目級調整上表現更穩。

我的實際感受：大多數設計師剛開始時，用 TRAE 國內版或 Kimi 就能快速把模板跑起來，看到效果後再決定要不要升級。有能力的直接上 Claude Code 會帶來更好的體驗以及儘可能少的再修改，減少過程中的內耗，上頂配是個省時省心的決策。

三、產品需求文檔 (PRD)

先理清楚需求，再做事，這是 Vibe Coding 裏最重要的一步。

PRD（Product Requirements Document）原本指產品需求文檔。在 Vibe Coding 裏，它也是給 AI 的「項目說明書」：把你的想法翻譯成結構化的要求，讓 AI 少走彎路，減少反覆迭代。

很多人第一次用 AI 做項目，會直接說「幫我做一個網站」或者「幫我做一個工具」。AI 當然會開始寫，但它很可能不知道你真正想要什麼：給誰用、重點功能是什麼、哪些地方不能亂改、最終做到什麼程度才算完成。

PRD 解決的就是這個問題。

你可以把它理解成一張「項目地圖」。它不需要寫得像公司文檔那麼正式，但至少要把方向、邊界和驗收標準說清楚。尤其是零基礎做項目時，PRD 能幫你避免一個很常見的問題：做着做着，AI 越改越偏，你自己也忘了最開始到底想做什麼。

如果你的工具支持 plan 模式，也可以先讓 AI 幫你一起完善 PRD。先聊清楚方案，再讓它動手寫代碼，這一步會省掉後面大量返工。

零基礎寫 PRD 的 3 步：

1. 在項目根目錄新建一個 PROJECT_PRD.md 文件。
2. 複製下面的通用模板，替換成你自己的內容。
3. 以後每次讓 AI 修改時，都說："參考根目錄的 PROJECT_PRD.md，按裏面的要求幫我實現……"
   
   

通用 PRD 模板（直接複製使用）：

有了 PRD 後，你後面的每次對話都可以圍繞它展開。比如：

請先閲讀 PROJECT_PRD.md，然後幫我實現首頁第一屏。不要改動 PRD 裏寫明暫不做的功能。

這樣 AI 就不會只盯着你當前這一句話，而是會把整個項目目標、設計要求和邊界一起考慮進去。對 Vibe Coding 來說，這比單獨寫一個漂亮 Prompt 更重要。

四、Vibe Coding 簡單技巧

4.1 Vibe Coding 的核心理念

傳統的編程學習路徑是：先學語法，再理解概念，最後練習寫代碼。

Vibe Coding 的路徑是：描述需求 → AI 生成代碼 → 運行看效果 → 迭代調整 → 完成。

關鍵在於：你不需要先學會再做事。你可以在做事的過程中，慢慢理解代碼。

4.2 讓 AI 幫你搞定一切環境配置

很多人看不懂環境配置（安裝 Node.js、配置 npm 等）。現在你可以直接告訴 AI：

把這個項目跑起來

AI 會自動檢測環境、安裝依賴、啓動開發服務器，並告訴你訪問地址。你只需要一個意圖，剩下的事 AI 幫你完成。

4.3 上下文管理：讓 AI 理解你的意圖

不要說："幫我改一下首頁"

要說："我想修改首頁 Hero 區域的佈局。現在是左文右圖，我想改成上下結構：上面是標題和簡介，下面是頭像圖片。"

上下文四個要素：

1. 目標（你想達成什麼效果）
2. 現狀（當前是什麼樣子）
3. 素材（設計稿、截圖、參考連結）
4. 約束（技術棧、設計規範、不希望改動的地方）

4.4 模型搭配和迭代對話

AI 的能力由模型決定。實際開發時我常用模型搭配：

• 用 Claude Code 或 Codex 梳理需求文檔、精細調整和多文件重構（理解力更強）
• 簡單需求和代碼編寫可以使用 glm、minimax 等性價比較高的模型完成，設計到架構和方案，模型越好在後面越省事。

迭代對話是 Vibe Coding 的精髓。不要指望一次就完美，而是通過多輪「反饋 → 調整」逐步逼近目標。每改一次，都把 PRD 發給 AI，讓它記住整體風格。

4.5 善用 Skills、MCP、Agents

等你開始頻繁用 AI 改項目時，會遇到三個進階詞：Skills、MCP、Agents。它們聽起來很技術，但可以先用一句話理解：

Skill 是經驗包，MCP 是連接器，Agent 是執行者。

不同工具的叫法不完全一樣。有些工具會直接叫 Agents、子任務、工作流，意思都接近：把一個大任務拆開，讓 AI 按角色去處理。

舉個設計師最容易理解的場景：你已經有一份 Figma 首頁設計稿，想把它變成網站首頁。

第一步，你可以先用普通對話讓 AI 按設計稿搭出頁面結構。這個階段不用急着上進階功能，先讓頁面看得見、跑得起來。

第二步，如果你發現自己總是在重複強調「按鈕要有 hover 狀態」「間距用 8px 體系」「移動端不要擠在一起」，就可以考慮用 Skill。它相當於把你的設計檢查清單變成一套固定工作方式，以後每次優化頁面都能複用。

第三步，如果 AI 需要讀 Figma 文件、查瀏覽器裏的真實渲染效果，或者讀取某個外部文檔，這時候就輪到 MCP。它不是讓 AI 變聰明，而是讓 AI 能拿到更多現場信息。

第四步，如果頁面已經比較複雜，你想同時檢查導航、作品卡片、移動端佈局和性能問題，就可以讓 Agent / Subagent 分頭處理。它們像臨時拉出來的幾個助手，每個人負責一個方向，最後再彙總到主任務裏。

所以不要把這些功能想得太玄。它們不是第一天必須掌握的東西，但等你開始反覆改頁面、接外部資料、處理多文件項目時，會明顯提升效率。

五、建議的開發順序

概念都清楚了，接下來該動手了。但順序很重要——很多新手失敗不是因為能力不夠，而是因為步驟搞反了。

推薦的路徑：

1. 確認技術方案。技術方案確定，後續可以沿着方向一路跑通，大方向錯了，意味着一切都得重來。
2. 先做頁面和交互。把設計稿變成可見、可點擊的頁面。這一步能幫你驗證"用戶流程到底順不順"。
3. 用假數據先跑通。不要急着對接真實服務，先用寫死的內容把整個流程走一遍。
4. 再接入後端邏輯。頁面跑通之後，你才清楚後端到底需要處理什麼。
5. 按需加數據庫。等確定哪些數據需要持久保存了，再引入數據庫。
6. 部署上線。讓網站真正對外可訪問。
7. 最後打磨細節：綁域名、配密鑰、加日誌，把"能用"變成"穩當"。

這個順序看起來很基礎，但能有效避免"做到一半推翻重來"的情況。先讓最短的一條路跑通，再逐步完善。

六、提前實操：讓模板跑起來

理論講完了，下一篇我們會深入每個模塊的具體實現。這裏先給你一個最簡單的起步方式：

一句話啓動項目

開源模板地址：

• 中文版：github.com/ricocc/ricoui-portfolio-zh
• 英文版：github.com/ricocc/ricoui-portfolio

打開你選擇的工具（用 TRAE 或 Kimi），下載我的開源模板，然後輸入：

幫我把這個項目跑起來。

AI 會自動檢查 Node.js、安裝依賴、啓動開發服務器，並告訴你本地訪問地址。

最後

這篇開發篇我們講了很多基礎概念：前端/後端/數據庫的分工、框架和組件庫、服務器/部署/域名、以及 AI 工具選擇，以及簡單提了一下 PRD 寫法和 Vibe Coding 核心技巧等概念。

核心觀念：

• 概念先行，動手在後。搞清楚每層在做什麼，比急着寫代碼更重要。
• AI 是你的編程夥伴，不是工具。你可以和它討論方案，讓它給你建議。
• 先跑起來，再優化。完美是迭代出來的，不是設計出來的。
• 設計師的組件化思維是 Vibe Coding 的天然優勢。

在下一篇文章中，我們直接進入實操，以我開源的網站模板為例，聊聊個人在 Vibe Coding 中的一些經驗，以及視覺實現、容易踩的坑、如何部署上線等內容。

我是 Rico， 感謝閲讀！