Vibe Coding 零基礎指南：rico-md 實戰案例教程
整理版優先睇
透過 rico-md 實戰案例，掌握 Vibe Coding 從 PRD 到設計優化的完整流程
呢篇文章係由設計師 Rico 寫嘅 Vibe Coding 零基礎指南第二部分。佢哋之前已經講咗基礎概念，今次就用真實項目 rico-md（一個公眾號排版編輯器）做案例，帶大家行一次完整嘅 Vibe Coding 流程：揀技術棧、寫 PRD、重構項目、用 PRD 控制 AI、再用 DESIGN.md 優化設計，最後驗收。
Rico 認為，Vibe Coding 嘅核心唔係叫 AI 亂寫代碼，而係要透過文檔（PRD、DESIGN.md）清楚話畀 AI 個項目係咩、邊界喺邊、做到咩程度先算完成。佢哋用 rico-md 示範咗點樣從一個開源項目 Fork 返嚟，逐步模塊化，最後變成一個功能齊全嘅工具。成個過程唔使後端、唔用構建系統，純前端搞掂，對設計師嚟講好易跟。
最後佢總結咗幾點心得：PRD 係控制 AI 方向最有效嘅工具；文檔體系（PRD + DESIGN.md + CLAUDE.md）可以令 AI 更可控；要由簡單項目開始，逐塊逐塊嚟；仲有要定期叫 AI 總結嚇當前狀態。佢仲提供咗幾個可以直接用嘅 Prompt 模板，方便大家照住做。
- Vibe Coding 入門應由簡單項目開始，先用 PRD 講清楚做咩、唔做咩，避免項目失控。
- 重構項目結構（例如拆開核心模塊、導出模塊、存儲模塊）比直接加功能更重要，呢步可以令 AI 之後更容易定位。
- PRD 係控制 AI 方向最有效嘅工具，要包含產品定位、核心能力、產品約束同驗收標準，每一條驗收標準都要可以測試。
- DESIGN.md 係將設計系統翻譯成 AI 能理解嘅語言，設計師透過佢可以令 UI 優化更精確，唔使每次都講一大輪。
- 每次準備做新功能前，先更新 PRD，再叫 AI 閲讀 PRD 後出計劃，確認後先執行，咁樣可以大幅減少意料之外嘅修改。
生成 PRD 嘅提示詞
根據項目想法整理 PRD.md，包含產品定位、目標用戶、核心功能、頁面結構、技術約束、暫不做功能、驗收標準。
按 PRD 拆任務嘅提示詞
閲讀當前項目同 PRD.md，將開發任務拆成 TODO，按優先級排序，說明要改邊啲模塊，標出高風險部分。
執行前先出計劃嘅提示詞
喺修改代碼前先要求 AI 閲讀相關文件、畀出修改計劃、明確唔會改動嘅範圍，等你確認後先開始執行。
rico-md 倉庫
實戰案例項目，入面有 PRD、DESIGN、CLAUDE 等文檔可以對住睇。
由案例認識技術棧：揀個適合嘅起點
正式開工之前，可以先了解嚇唔同複雜度嘅項目分別對應咩技術方案。最簡單嘅係 靜態網頁，只需 HTML+CSS+JS 就可以，適合展示型頁面。另一個係本篇主線案例 rico-md，一個公眾號排版編輯器，佢涉及多文檔管理、圖片處理、主題系統等，所以要用 Vue 3（CDN）、markdown-it、IndexedDB 等技術。
揀技術棧嘅第一步唔係揾「最好」嘅方案，而係揾「最適合」嘅起點。如果需求只係一個靚嘅展示頁面，唔涉及登錄、數據儲存，咁 HTML+CSS+JS 就夠用。Rico 建議 由簡單項目開始，先將個想法變成一個睇得嘅嘢出嚟。
實戰改造：由 PRD 到功能開發，透過文檔控制 AI
正式改造前要先 認識項目文檔。對 Vibe Coding 嚟講，文檔唔係寫畀自己睇嘅說明書，而係畀 AI 快速理解項目狀態、目標同邊界嘅工具。最緊要係 PRD.md，佢解決三個問題：項目做咩、唔做咩、做到咩程度。
Rico 示範咗點樣從一個單文件項目開始，先叫 AI 做一次 結構重構，將原來 3500 行嘅 app.js 拆成 core/、export/、storage/、ui/ 等目錄，令後續功能更容易維護。然後建立 PRD，分為產品定位、核心能力、產品約束、實現邊界、驗收標準同後續方向。
產品約束係 PRD 最重要嘅部分之一，要寫明唔可以引入後端、唔可以用 Vite/Webpack/npm 等，避免 AI 亂改核心機制。
驗收標準每一條都要可以測試，例如「複雜塊級公式喺預覽中正常顯示」比起「公式顯示正常」更清楚。
用 PRD 控制 AI 嘅關鍵係：每次準備做一個功能，先更新 PRD，再叫 AI 閲讀 PRD 後執行，修改前先列 TODO，完成後按驗收標準自測。呢個習慣可以大幅減少 AI 偏離方向嘅問題。
用 DESIGN.md 將設計判斷轉化為 AI 可執行嘅規範
功能層面解決之後，仲要處理 UI 設計。設計師 Vibe Coding 嘅優勢係 比 AI 更懂咩係好嘅體驗，但要透過 DESIGN.md 呢個工具先發揮到。Rico 建議分兩步：第一步自己規劃佈局結構，第二步用 DESIGN.md 定義配色、排版、組件規範，等 AI 可以精確執行。
一份完整嘅 DESIGN.md 包括視覺風格定位、顏色規範、排版規範、組件規範、交互規範、響應式策略等。佢可以理解為將 Figma 嘅設計系統翻譯成 AI 能理解嘅語言。Rico 仲提供咗一個 Skill 工具 rico-skills/get-design-md，可以自動生成設計系統文檔。
用 DESIGN.md 優化設計時，可以禁止其他設計類 SKILLS 幹擾，確保 AI 按照你自己嘅規範嚟執行。
- 1 功能驗證：檢查所有 PRD 核心功能正常，文檔增刪改流程正常，主題切換即時生效，圖片處理同複製結果一致。
- 2 UI/交互檢查：桌面端同移動端佈局正常，暗色模式對比度正常，交互反饋清晰。
- 3 PRD 對照：確認產品約束冇被違反（例如冇引入後端），實現邊界之外嘅功能冇被提前加入，驗收標準全部通過。
核心心得同實用 Prompt 附錄
Rico 分享咗幾個關鍵心得：PRD 係控制 AI 方向最有效嘅工具，文檔體系（PRD + DESIGN.md + CLAUDE.md）可以令 AI 更可控；由簡單項目開始，逐塊推進；仲有要定期叫 AI 總結當前狀態，重新對齊上下文。
最後佢提供咗幾個可以直接複製嘅 Prompt，包括揀技術棧、生成 PRD、按 PRD 拆任務、執行前先出計劃、修改後自測、UI 優化、生成 DESIGN.md 同總結項目狀態。呢啲 Prompt 可以慳返好多溝通時間。
用「執行前先出計劃」呢個 prompt，可以確保 AI 唔會一嚟就亂改，而係先畀你睇計劃，等你確認後先開始。
下一篇會用 Astro + Tailwind 做個人網站，同埋介紹 React/Vue 相關科普，到時就可以由零構建到部署。
一、由簡單嘅項目開始
上一篇（一）我哋理清咗基礎概念——前端/後端/資料庫嘅分工、框架同組件庫、AI 工具選擇，仲簡單提咗下 PRD 同 Vibe Coding 嘅核心技巧。
寫畀設計師嘅 Vibe Coding 零基礎指南（一）：基礎、框架、工具
但概念始終都係概念。
「道理我明曬，但打開電腦仲係唔知第一步做咩。」呢種感覺好正常。知道 HTML 係結構，唔代表你可以用佢整到嘢；知道 PRD 係項目說明書，唔代表你會寫。所以呢一篇，我哋講下實例。
所以呢一篇，我哋講下實例。
呢篇以一個真實項目 rico-md（公眾號排版編輯器 md.ricoui.com）做主線，由「點解揀呢個項目」開始，講到「點樣寫 PRD」、「點樣用 PRD 控制 AI」、「點樣優化設計」，帶你行完一個簡單版本嘅 Vibe Coding 流程。
相關嘅 PRD 同 DESIGN md 都放咗喺倉庫嘅 docs 目錄裏面，可以邊睇文章邊對照：
倉庫（Star⭐161）：https://github.com/ricocc/rico-md
圖：md.ricoui.com
呢篇內容比較長，建議按大節閲讀。睇到 PRD、DESIGN md 同驗收部分嘅時候，可以打開項目對住嚟睇。
先睇一眼我哋跟住要行嘅完整路線：
每個環節都會攤開嚟講。唔使急，一步步嚟。
二、從案例認識技術棧
喺正式鬱手之前，先用兩個案例幫你建立對「技術棧」嘅直覺——由最簡單嘅靜態網頁，到呢篇嘅主線實戰項目，感受下唔同複雜度嘅項目分別對應咩技術方案。
2.1 最簡單嘅起點：一個靜態網頁
先睇一個最簡單嘅例子。
HTML+CSS+JS，係最基礎嘅網頁技術組合。你發畀豆包、Gemini、Kimi 等生成網頁，大部分輸出嘅就係呢啲 HTML 頁面，直接放落瀏覽器就可以打開。
呢個單頁係我用 Blender 做咗一套開源圖標，為咗方便預覽就順手做咗個網頁，功能同目標好簡單：展示同下載資產庫。
- 頁面：valentine.uiineed.com
- 倉庫：github.com/ricocc/free-3d-valentines-assets
- 技術棧： HTML+CSS+JS, 自由落體效果使用 Matter.js 庫
呢個係之前我手寫嘅，代碼好簡單。而家用 AI 嘅話，核心就係話畀 AI 你想要自由落體嘅效果，或者直接指定用 Matter.js 嚟開發，畀張圖佢就得。呢個頁面有價值嘅係設計諗法，呢個都係設計師嘅優勢所在。
一個小經驗： 如果你嘅需求只係一個靚嘅展示頁面——無論視覺有幾複雜、交互有幾過癮，只要唔涉及權限、內容管理、登錄註冊呢啲數據處理——咁 HTML+CSS+JS 就係最適合你啟動嘅第一版方案。先將諗法變成一個睇得嘅嘢出嚟，比咩都重要。
2.2 呢篇主線案例：rico-md 公眾號排版編輯器
跟住進入呢篇嘅重頭戲。我會以 rico-md 呢個真實項目做案例，帶你行完一次完整嘅 Vibe Coding 流程。
- 在線地址：md.ricoui.com
- 倉庫地址：github.com/ricocc/rico-md
rico-md 係一個面向微信公眾號寫作同排版嘅純前端 Markdown 編輯器。佢係我從花生嘅開源項目（github.com/alchaincyf/huasheng_editor）Fork 過嚟，然後透過 Vibe Coding 進行全面改造嘅。
我哋可以對比下優化前後嘅設計同功能
當前開發完成嘅 rico-md 嘅核心功能：
- 編輯與預覽：左側 Markdown 編輯工具欄，右側實時預覽；支援桌面/iPad/手機預覽模式切換
- 文檔管理：多文檔創建、切換、複製、刪除；文檔搜索；自動保存與狀態顯示
- 主題系統：20 套公眾號正文主題（按風格分類）+ 16 套獨立代碼塊主題
- 圖片處理：粘貼/拖拽/上傳 → IndexedDB 持久儲存
- 字號同圖片：全文字號自選同自訂圖片樣式
- 公式渲染：支援多種數學公式
- 導出與複製：導出 Markdown / HTML；一鍵複製到公眾號同 X
技術棧：Vue 3（CDN）+ markdown-it + highlight.js + IndexedDB + 原生 CSS
關鍵概念：IndexedDB（瀏覽器端本地數據庫，儲存大檔案例如圖片）、**img://**（自訂圖片協議，映射 IndexedDB 裏面嘅圖片）、KaTeX / MathJax（公式渲染庫，前者輕量適合預覽，後者兼容公眾號）
點解揀佢做教程案例？ 因為佢好典型——由一個已有嘅開源項目出發，透過寫 PRD 明確目標，用 AI 工具逐步改造，最終變成一個更貼近自己工作流程嘅工具。呢個正係大多數設計師接觸 Vibe Coding 時最可能行嘅路徑。
揀技術棧嘅第一步，唔係揾「最好嘅方案」，而係揾「最合適嘅起點」。
三、實戰改造：從 PRD 到功能開發
3.1 先認識項目文檔：從 PRD.md 開始
rico-md 項目嘅 PRD、DESIGN、CLAUDE 等文檔都放咗喺 docs 文件夾入面，可以對照跟住嘅內容：
github.com/ricocc/rico-md/tree/master/docs
喺 Vibe Coding 入面，文檔嘅作用唔係「寫畀自己睇嘅說明書」，而係令 AI 快速理解項目狀態、目標同邊界。
對新手嚟講，最重要嘅一份文檔係 PRD.md。
佢主要解決三個問題：
如果你啱啱開始做項目，唔需要一嚟就準備好多文檔。先寫好 PRD.md 就夠。
隨住項目變複雜，再補充其他文檔：
- 使用 Claude Code，可以維護 CLAUDE.md
- 使用 Codex 等 Agent 工具，可以維護 AGENTS.md
- 做 UI 優化時，再補充 DESIGN.md
呢啲文檔真正嘅價值在於：記錄項目嘅真實狀態。 當你開新嘅 AI 對話時，佢可以透過呢啲文檔快速知道當前項目係咩、已經做咗咩、邊啲地方唔可以亂改。
3.2 打地基：先將項目結構理順
花生嘅原版項目好簡單，主要係一個 index.html 加一個 app.js（超過3500行代碼）。呢個對新手嚟講易明，但功能一多，問題亦好明顯：曬士邏輯都塞喺一個檔案裏面，AI 每次修改都要重新理解成段代碼，後面好容易越改越亂。
所以起手唔係加功能，而係先叫 AI 做一次結構梳理。
你可以直接咁講：
重構之後嘅重點唔係「文件夾睇落專業啲」，而係令每一類功能有自己嘅位置。
重構之後，我哋得到現有項目優化之後嘅結構：
呢步做完之後，AI 再修改功能時就更容易定位。例如要改圖片上傳，佢會去揾圖片處理模塊；要改主題面板，佢會去睇 UI 同樣式檔案，而唔係每次喺一個大檔案裏面亂揾。
而下便係我哋最終開發完成嘅檔案結構：
呢個其實就係拆分組件嘅思維，唔好覺得複雜，拆分同梳理係 AI 做嘅事，你只需要畀明確嘅指令。
呢步我哋做到咗咩？將原本嘅單檔案 app.js 拆分為 core/（核心模塊）、export/（導出模塊）、storage/（儲存模塊）、ui/（界面模塊）等獨立目錄，每個模塊職責清晰，AI 易讀。
3.3 建立 PRD 文檔
PRD 唔需要寫到好似公司裏面嘅正式需求文檔咁。對 Vibe Coding 嚟講，佢嘅作用好直接：令 AI 知道呢個項目係咩、做到邊一步、邊啲地方唔可以亂改。
一份夠用嘅 PRD，可以先包含呢幾個部分：
下便用 rico-md 嘅真實 PRD 拆開嚟講。你唔使抄格式，重點係理解每一部分解決咩問題。
第一步：產品定位——一句話講清楚「呢個嘢係咩」
圖：先用產品定位講清楚項目係咩、唔做咩
呢度最重要嘅唔係句子寫得有幾靚，而係將使用場景同技術邊界講清楚。「面向微信公眾號」限定咗場景，「純前端」「唔依賴後端同構建系統」就話畀 AI 聽：跟住唔好為咗實現功能擅自引入服務端或構建流程。
關鍵技巧：產品定位裏面要包含「唔做咩」嘅訊息，同「做咩」一樣重要。
第二步：核心能力——列出當前已經有嘅功能
圖：核心能力只寫當前已經實現嘅功能
呢一節只寫「而家有咩」，唔好將未來計劃溝埋一齊。AI 睇到呢啲內容之後，先判斷到新需求同現有功能嘅關係，避免重複實現或改壞已有流程。
關鍵技巧：核心能力按模塊分組，令 AI 可以快速定位「呢個功能屬於邊個模塊」。
第三步：產品約束——話畀 AI「邊啲嘢唔可以鬱」
圖：產品約束要話畀 AI 邊啲嘢唔可以鬱
呢一節係成個 PRD 裏面最重要嘅部分之一。
冇呢節嘅話，AI 可能會喺「優化圖片處理」嘅時候順便將儲存方式由 IndexedDB 改成 localStorage，搞到曬士用戶嘅圖片唔見曬。或者為咗「代碼更規範」引入 Vite 構建系統，破壞咗「雙擊打開就用得」嘅核心特性。
產品約束就係喺話畀 AI：你可以自由發揮，但呢條線唔可以跨過。
關鍵技巧：約束要寫得具體，唔好淨係話「保持簡潔」，要話「唔好引入 Vite / Webpack / npm」。AI 需要嘅係明確嘅邊界，唔係模糊嘅原則。
第四步：實現邊界——明確「而家唔做」
圖：將當前唔做嘅功能列曬出嚟，避免範圍越做越大
呢一節睇落係「唔做清單」，但佢同產品約束嘅作用唔同，實現邊界就係「而家唔做」。呢個同產品約束唔一樣：產品約束通常係長期唔可以破壞嘅規則，實現邊界只係當前階段暫時唔掂嘅範圍。將「暫唔做」寫出嚟，可以防止項目喺 Vibe Coding 過程中越做越大。
關鍵技巧：將「暫唔做」列曬出嚟，可以有效防止項目喺 Vibe Coding 過程中越做越大。
第五步：驗收標準——做到咩程度先叫完成
圖：驗收標準要寫成每一條都可以測試
驗收標準係 PRD 中最容易畀人忽略嘅部分。好多人寫 PRD 只寫「做咩」，唔寫「點樣判斷做完」。
驗收標準嘅核心原則：每一條都應該係可以測試嘅。 驗收標準要寫成可以測試嘅句子。「公式顯示正常」太模糊，「複雜塊級公式喺預覽中正常顯示」就清楚好多。後者可以直接變成測試動作，亦方便 AI 喺修改之後生成自測清單。
關鍵技巧：驗收標準按模塊分組，每條用「可以 + 具體動作」嘅句式，令 AI 知道應該試啲咩。
第六步：後續方向——畀未來留個路標
呢一節唔係畀 AI 睇嘅，主要係畀自己睇嘅——提醒自己項目下一步應該點行。但 AI 睇到佢都有好處：當你做緊當前階段嘅任務時，AI 唔會提前去實現後續方向裏面嘅嘢，因為佢知道嗰啲係「下一步」嘅事。
3.4 用 PRD 控制 AI，唔好直接開改
大部分人係對項目框架冇概念嘅，所以好容易搞到 Vibe Coding 項目失控，呢個唔係因為 AI 唔識寫代碼，只係因為我哋一開始冇將邊界講清楚。
所以我嘅習慣係：每次準備做一個功能，先更新 PRD，再叫 AI 鬱手。
例如我要優化圖片處理，唔會直接話：
幫我優化圖片功能。
我會先在 PRD 裏面補清楚：
- 今次要優化啲咩：粘貼、拖拽、上傳、複製到公眾號
- 邊啲嘢唔可以破壞：img:// 協議、IndexedDB 儲存、已有文檔入面嘅圖片
- 點樣判斷做完：上傳之後可以預覽，刷新之後唔會丟失，複製到公眾號時圖片可以帶出去
然後再對 AI 講：
閲讀 PRD.md，按照圖片處理相關要求執行。修改前先列 TODO，完成後按驗收標準自測。
咁樣 AI 嘅工作會穩定好多。佢唔係淨係睇你當前呢一句話，而係會將 PRD 當成項目邊界嚟參考。
四、用 DESIGN md 進行設計優化
功能層面嘅問題喺上面透過 PRD 解決咗。
但仲有一個問題，我哋仲未鬱過設計：目前嘅 UI 好簡陋，交互亦唔夠好。 尤其係加咗好多新功能之後，原本嘅界面根本承載唔到咁多內容，需要全面重新設計，要點算？
設計師 Vibe Coding 時有一個天然優勢：你比 AI 更識得咩係好嘅體驗。 但呢個優勢如果唔透過某種方式傳達畀 AI，就發揮唔到出嚟。
所以我嘅習慣係分兩步：
第一步係搭好佈局結構。作為設計師，我會傾向先自己規劃佈局，例如左右側欄放置各種功能，導航放頂部，底部係狀態資訊，將框架搭好。當然你都可以完全利用設計 SKILLS 嚟做。
第二步先係視覺同交互。
你同 AI 講「靚啲」或者「設計感強啲」，佢可能完全唔知你講咩。但如果你畀佢一份結構化嘅設計文檔，定義咗配色方案、排版規範、組件樣式、交互模式：佢就可以按你嘅要求精確執行。
這就是 DESIGN md 嘅作用。
順便講句，呢步我更傾向用 DESIGN md，而唔係直接套用設計類 SKILLS。後者的確方便，但有時會帶出比較模板化嘅風格；DESIGN md 嘅好處係，佢可以將你自己嘅設計判斷保留落嚟，亦更容易貼合當前項目。
對設計師嚟講，保留自己嘅判斷，比直接套用現成風格更加重要。
4.1 咩係 DESIGN md
圖：DESIGN.md 係將設計系統翻譯成 AI 明白嘅語言
呢份係用設計語言（而唔係產品語言）寫成嘅指導文檔。佢同 PRD 嘅分別好簡單：
- PRD 管「做咩」——功能、流程、邊界
- DESIGN管「做成點樣」——視覺風格、配色、排版、交互
你可以將佢理解為：將 Figma 裏面嘅設計系統，翻譯成 AI 明白嘅語言。
一份完整嘅 DESIGN 通常包含呢啲內容：
4.2 點樣生成 DESIGN md
我自己做咗一個 Skill 工具 rico-skills/get-design-md，可以輸入任何網站自動生成完整嘅設計系統文檔，亦可以喺唔同設計令牌格式之間轉換（DESIGN.md、tokens.json、variables.css、theme.css）。有需要可以試下。
當然你都可以完全手寫。使用上好簡單：將 DESIGN.md 放喺項目根目錄，然後對 AI 講：
使用 DESIGN md 優化設計
如果你有安裝設計類 SKILLS，記得要禁止佢調用，唔係會造成幹擾。
執行後睇下設計優化效果，再針對細節自己調整。完成之後記得叫 AI 生成項目最終嘅 DESIGN md，保持文檔同實際代碼一致。
有咗呢份設計文檔，AI 喺修改 UI 時就唔再係「憑感覺」調整，而係按照一套明確嘅規範去執行。例如我話「畀設置面板加一個新嘅開關」，AI 會自動沿用 DESIGN md 入面定義嘅組件樣式同交互方式，唔使我每次都重複描述。
下便係我執行優化之後嘅頁面，效果我覺得幾好。
4.3 點解推薦喺 Vibe Coding 中使用 DESIGN md
三個原因：
第一，AI 對結構化設計指令嘅理解遠優於模糊描述。 「按鈕要有懸浮效果」不如「按鈕 hover 時背景色由 #2d6dc3 變為 #0066ff，過渡時間 150ms」。
第二，設計師寫嘅 DESIGN md = 將 Figma 嘅設計系統翻譯成 AI 明白嘅語言。 你喺 Figma 入面做組件化、定義 Variables、整理設計系統時累積嘅能力，喺呢度直接有用武之地。
第三，一次寫好，每次迭代都可以重用。DESIGN md 唔需要每次都重寫。項目初期花時間定義好設計規範，後續曬士 AI 修改都會自動遵守，保持風格一致性。
設計師喺 Vibe Coding 中嘅獨特優勢就係：你比 AI 更識得咩係好嘅體驗。DESIGN md 係你將呢個優勢轉化為實際效果嘅工具。
4.4 驗收檢查清單
最後再執行下便呢啲檢查，就已經完成咗一次完整嘅 Vibe Coding 項目改造。 由揀技術棧、寫 PRD、用 PRD 控制 AI、到設計優化同驗收，成個流程都行咗一次。
五、核心心得
喺結束之前，分享幾個喺實際 Vibe Coding 過程中總結嘅關鍵心得：
1. PRD 係控制 AI 方向最有效嘅工具。
PRD 嘅價值唔係「寫得正式」，而係令 AI 睇到項目全貌。佢知道目標、邊界同驗收標準之後，就唔會淨係根據你當前呢一句話臨場發揮。
2. 文檔體系（PRD + DESIGN.md + CLAUDE.md）令 AI 更可控。
PRD 管「做咩」，DESIGN.md 管「做成點樣」，CLAUDE.md 話畀 AI「當前代碼係點樣」。三份文檔配合使用，AI 幾乎唔會做出意料之外嘅修改。如果項目複雜，就進一步按照漸進式披露嘅思路嚟做。
3. 由簡單項目開始，好似砌積木咁推進。
rico-md 由一個單檔案項目開始，逐步模塊化、逐步完善。每一個功能完成，檢查通過，git 做好備份，再繼續下一個功能嘅開發。
4. 叫 AI 定期總結當前狀態。
喺長對話中，AI 嘅記憶會慢慢模糊。每隔幾輪對話，叫 AI 「總結一下當前項目嘅狀態同最近嘅改動」，可以幫佢重新對齊上下文。
六、附錄：幾個可以直接複製嘅 Prompt
下便呢啲提示詞可以直接複製使用。你唔需要一次過曬士用曬，按當前階段揀一個就得。
七、最後
呢篇原本仲想將框架案例一齊講完，但後嚟發現，好多人真正卡住嘅唔係框架，而係最開始嘅項目選擇、文檔梳理同第一步操作。所以我將呢部分拆開，講得詳細啲。
所以呢篇我哋做咗一個項目改造案例：由揀技術棧、建立文檔體系、寫 PRD、用 PRD 控制 AI、用 DESIGN md 優化設計，到最後嘅驗收。睇落內容唔少，但其實主要係同 AI 傾偈，出好文檔並執行，實際上並冇咁花時間。花時間比較多嘅部分，其實係我透過視覺去調整主題樣式同排版。
下一篇，我哋會再進階啲，用 Astro + Tailwind 嘅現代框架嚟做個人作品集網站/Landing Page，以及涉及嚇 React 同 Vue 相關嘅科普，然後對項目做橫向對比，最後將項目部署上線。由零構建到部署，完成成個閉環。
如果有興趣，可以先睇下下要我特登開發嘅開源模板項目(都有中英文版本)：
集合： github.com/ricocc
1. 畀 Vibe Coding 開發嘅啟動模板
2. RicoUI SaaS 模板
3. RicoUI 個人網站模板
如果你喺呢個過程中做咗自己嘅改造項目，或者有咩疑問，歡迎交流——微信 rico-ui
我係 Rico，多謝閲讀！
一、從簡單的項目開始
上一篇（一）我們理清了基礎概念——前端/後端/數據庫的分工、框架和組件庫、AI 工具選擇，還簡單提了一下 PRD 和 Vibe Coding 的核心技巧。
寫給設計師的 Vibe Coding 零基礎指南（一）：基礎、框架、工具
但概念終究是概念。
"道理我都懂，但打開電腦還是不知道第一步幹什麼。" 這種感覺太正常了。知道 HTML 是結構，不代表你能用它做出東西；知道 PRD 是項目說明書，不代表你會寫。 所以這一篇，我們來講講實例。
所以這一篇，我們來講講實例。
本篇以一個真實項目 rico-md（公眾號排版編輯器 md.ricoui.com）為主線，從"為什麼選這個項目"開始，講到"怎麼寫 PRD"、"怎麼用 PRD 控制 AI"、"怎麼優化設計"，帶你走完一個簡單版本的 Vibe Coding 流程。
相關的 PRD 和 DESIGN md 也放在了倉庫的 docs 目錄裏，可以邊看文章邊對照：
倉庫（Star⭐161）：https://github.com/ricocc/rico-md
圖：md.ricoui.com
這篇內容偏長，建議按大節閲讀。看到 PRD、DESIGN md 和驗收部分時，可以打開項目對照着看。
先看一眼我們接下來要走的完整路線：
每個環節都會展開講。不着急，一步步來。
二、從案例認識技術棧
在正式動手之前，先用兩個案例幫你建立對"技術棧"的直覺——從最簡單的靜態網頁，到本篇的主線實戰項目，感受一下不同複雜度的項目分別對應什麼技術方案。
2.1 最簡單的起點：一個靜態網頁
先看一個最簡單的例子。
HTML+CSS+JS，這是最基礎的網頁技術組合。你發給豆包、Gemini、Kimi 等生成網頁，大部分輸出的就是這樣的 HTML 頁面，直接放到瀏覽器就可以打開。
這個單頁是我用 Blender 做了一套開源圖標，為了方便預覽就順帶做了個網頁，功能和目標很簡單：展示和下載資產庫。
- 頁面：valentine.uiineed.com
- 倉庫：github.com/ricocc/free-3d-valentines-assets
- 技術棧： HTML+CSS+JS, 自由落體效果使用 Matter.js 庫
這個是以前我手寫的，代碼很簡單。現在用 AI 的話，核心就是告訴 AI 你想要自由落體的效果，或者直接指定用 Matter.js 來開發，圖片給它即可。這個頁面有價值的是設計想法，這也是設計師的優勢所在。
一個小經驗： 如果你的需求只是一個好看的展示頁面——無論視覺多複雜、交互多有意思，只要不涉及權限、內容管理、登錄註冊等數據處理——那麼 HTML+CSS+JS 就是最適合你啓動的第一版方案。先把想法變成一個能看的東西出來，比什麼都重要。
2.2 本篇主線案例：rico-md 公眾號排版編輯器
接下來進入本篇的重頭戲。我會以 rico-md 這個真實項目為案例，帶你走完一次完整的 Vibe Coding 流程。
- 在線地址：md.ricoui.com
- 倉庫地址：github.com/ricocc/rico-md
rico-md 是一個面向微信公眾號寫作與排版的純前端 Markdown 編輯器。它是我從花生的開源項目（github.com/alchaincyf/huasheng_editor）Fork 過來，然後通過 Vibe Coding 進行全面改造的。
我們可以對比一下優化前後的設計和功能
當前開發完成的 rico-md 的核心功能：
- 編輯與預覽：左側 Markdown 編輯工具欄，右側實時預覽；支持桌面/iPad/手機預覽模式切換
- 文檔管理：多文檔創建、切換、複製、刪除；文檔搜索；自動保存與狀態顯示
- 主題系統：20 套公眾號正文主題（按風格分類）+ 16 套獨立代碼塊主題
- 圖片處理：粘貼/拖拽/上傳 → IndexedDB 持久儲存
- 字號和圖片：全文字號自選和自定義圖片樣式
- 公式渲染：支持多種數學公式
- 導出與複製：導出 Markdown / HTML；一鍵複製到公眾號和 X
技術棧：Vue 3（CDN）+ markdown-it + highlight.js + IndexedDB + 原生 CSS
關鍵概念：IndexedDB（瀏覽器端本地數據庫，存儲大文件如圖片）、**img://**（自定義圖片協議，映射 IndexedDB 中的圖片）、KaTeX / MathJax（公式渲染庫，前者輕量適合預覽，後者兼容公眾號）
為什麼選它做教程案例？ 因為它非常典型——從一個已有的開源項目出發，通過寫 PRD 明確目標，用 AI 工具逐步改造，最終變成一個更貼合自己工作流的工具。這恰好是大多數設計師接觸 Vibe Coding 時最可能走的路徑。
選技術棧的第一步，不是找"最好的方案"，而是找"最合適的起點"。
三、實戰改造：從 PRD 到功能開發
3.1 先認識項目文檔：從 PRD.md 開始
rico-md 項目的 PRD、DESIGN、CLAUDE 等文檔都放在了 docs 文件夾中，可以對照後續的內容：
github.com/ricocc/rico-md/tree/master/docs
在 Vibe Coding 裏，文檔的作用不是"寫給自己看的說明書"，而是讓 AI 快速理解項目狀態、目標和邊界。
對新手來說，最重要的一份文檔是 PRD.md。
它主要解決三個問題：
如果你剛開始做項目，不需要一上來就準備很多文檔。先寫好 PRD.md 就夠了。
隨着項目變複雜，再補充其他文檔：
- 使用 Claude Code，可以維護 CLAUDE.md
- 使用 Codex 等 Agent 工具，可以維護 AGENTS.md
- 做 UI 優化時，再補充 DESIGN.md
這些文檔真正的價值在於：記錄項目的真實狀態。 當你開啓新的 AI 對話時，它可以通過這些文檔快速知道當前項目是什麼、已經做了什麼、哪些地方不能亂改。
3.2 打地基：先把項目結構理順
花生的原版項目很簡單，主要是一個 index.html 加一個 app.js（超過3500行代碼）。這對新手來說好理解，但功能一多，問題也很明顯：所有邏輯都堆在一個文件裏，AI 每次修改都要重新理解整段代碼，後面很容易越改越亂。
所以起手不是加功能，而是先讓 AI 做一次結構梳理。
你可以直接這樣說：
重構後的重點不是"文件夾看起來更專業"，而是讓每一類功能有自己的位置。
重構之後，我們得到現有項目優化後的結構：
這一步做完後，AI 再修改功能時就更容易定位。比如要改圖片上傳，它會去找圖片處理模塊；要改主題面板，它會去看 UI 和樣式文件，而不是每次都在一個大文件裏亂翻。
而下面是我們最終開發完成的文件結構：
這其實就是拆分組件的思維，不要覺得複雜，拆分和梳理是 AI 做的事，你只需要給明確的命令。
這一步我們做到了什麼？把原來的單文件 app.js 拆分為 core/（核心模塊）、export/（導出模塊）、storage/（存儲模塊）、ui/（界面模塊）等獨立目錄，每個模塊職責清晰，AI 易讀。
3.3 建立 PRD 文檔
PRD 不需要寫得像公司裏的正式需求文檔。對 Vibe Coding 來說，它的作用很直接：讓 AI 知道這個項目是什麼、現在做到哪一步、哪些地方不能亂改。
一份夠用的 PRD，可以先包含這幾個部分：
下面用 rico-md 的真實 PRD 拆開講。你不用照抄格式，重點是理解每一部分解決什麼問題。
第一步：產品定位——一句話說清楚"這個東西是什麼"
圖：先用產品定位說清楚項目是什麼、不做什麼
這裏最重要的不是句子寫得多漂亮，而是把使用場景和技術邊界說清楚。"面向微信公眾號"限定了場景，"純前端""不依賴後端和構建系統"則告訴 AI：後續不要為了實現功能擅自引入服務端或構建流程。
關鍵技巧：產品定位裏要包含"不做什麼"的信息，這和"做什麼"一樣重要。
第二步：核心能力——列出當前已經有的功能
圖：核心能力只寫當前已經實現的功能
這一節只寫"現在已經有什麼"，不要把未來計劃混進去。AI 看到這些內容後，才能判斷新需求和現有功能的關係，避免重複實現或改壞已有流程。
關鍵技巧：核心能力按模塊分組，讓 AI 能快速定位"這個功能屬於哪個模塊"。
第三步：產品約束——告訴 AI "哪些東西不能動"
圖：產品約束要告訴 AI 哪些東西不能動
這一節是整個 PRD 中最重要的部分之一。
沒有這節的話，AI 可能會在"優化圖片處理"的時候順便把存儲方式從 IndexedDB 改成 localStorage，導致所有用戶的圖片丟失。或者為了"代碼更規範"引入 Vite 構建系統，破壞了"雙擊打開就能用"的核心特性。
產品約束就是在告訴 AI：你可以自由發揮，但這條線不能越。
關鍵技巧：約束要寫得具體，不要只說"保持簡潔"，要說"不引入 Vite / Webpack / npm"。AI 需要的是明確的邊界，不是模糊的原則。
第四步：實現邊界——明確"現在不做"
圖：把當前不做的功能列出來，避免範圍越做越大
這一節看起來是"不做清單"，但它和產品約束的作用不同，實現邊界就是"現在不做"。這和產品約束不一樣：產品約束通常是長期不能破壞的規則，實現邊界只是當前階段先不碰的範圍。把"暫不做"寫出來，能防止項目在 Vibe Coding 過程中越做越大。
關鍵技巧：把"暫不做"列出來，能有效防止項目在 Vibe Coding 過程中越做越大。
第五步：驗收標準——做到什麼程度才算完成
圖：驗收標準要寫成每一條都能測試
驗收標準是 PRD 中最容易被忽略的部分。很多人寫 PRD 只寫"做什麼"，不寫"怎麼判斷做完了"。
驗收標準的核心原則：每一條都應該是可以測試的。 驗收標準要寫成能測試的句子。"公式顯示正常"太模糊，"複雜塊級公式在預覽中正常顯示"就更清楚。後者能直接變成測試動作，也方便 AI 在修改後生成自測清單。
關鍵技巧：驗收標準按模塊分組，每條用"能 + 具體動作"的句式，讓 AI 知道該測什麼。
第六步：後續方向——給未來留個路標
這一節不是給 AI 看的，主要是給自己看的——提醒自己項目下一步該往哪走。但 AI 看到它也有好處：當你在做當前階段的任務時，AI 不會提前去實現後續方向裏的東西，因為它知道那些是"下一步"的事。
3.4 用 PRD 控制 AI，不要直接開改
大部分人是對項目框架沒有概念的，所以很容易會導致 Vibe Coding 項目失控，這也不是因為 AI 不會寫代碼，只是因為我們一開始沒有把邊界講清楚。
所以我的習慣是：每次準備做一個功能，先更新 PRD，再讓 AI 動手。
比如我要優化圖片處理，不會直接說：
幫我優化圖片功能。
我會先在 PRD 裏補清楚：
- 這次要優化什麼：粘貼、拖拽、上傳、複製到公眾號
- 哪些東西不能破壞：img:// 協議、IndexedDB 存儲、已有文檔裏的圖片
- 怎麼判斷做完：上傳後能預覽，刷新後不丟失，複製到公眾號時圖片能帶出
然後再對 AI 說：
閲讀 PRD.md，按照圖片處理相關要求執行。修改前先列 TODO，完成後按驗收標準自測。
這樣 AI 的工作會穩定很多。它不是隻看你當前這一句話，而是會把 PRD 當成項目邊界來參考。
四、用 DESIGN md 進行設計優化
功能層面的問題在上面通過 PRD 解決了。
但還有一個問題，我們還沒動過設計：目前的 UI 很簡陋，交互也不夠好。 尤其是增加了很多新功能之後，原來的界面根本承載不了這麼多內容，需要全面重新設計，要怎麼辦？
設計師 Vibe Coding 時有一個天然優勢：你比 AI 更懂什麼是好的體驗。 但這個優勢如果不通過某種方式傳達給 AI，就發揮不出來。
所以我的習慣是分兩步：
第一步是搭好佈局結構。作為設計師，我會更傾向先自己規劃佈局，比如左右側欄放置各種功能，導航放頂部，底部是狀態信息，把框架搭好。當然你也可以完全利用設計 SKILLS 來做。
第二步才是視覺和交互。
你跟 AI 說"好看一點"或者"設計感強一點"，它可能完全不知道你在說什麼。但如果你給它一份結構化的設計文檔，定義了配色方案、排版規範、組件樣式、交互模式：它就能按你的要求精確執行。
這就是 DESIGN md 的作用。
順便說一句，這一步我更傾向於用 DESIGN md，而不是直接套用設計類 SKILLS。後者確實方便，但有時會帶出比較模板化的風格；DESIGN md 的好處是，它能把你自己的設計判斷保留下來，也更容易貼合當前項目。
對設計師來說，保留自己的判斷，比直接套用現成風格更重要。
4.1 什麼是 DESIGN md
圖：DESIGN.md 是把設計系統翻譯成 AI 能理解的語言
這是一份用設計語言（而非產品語言）寫成的指導文檔。它和 PRD 的區別很簡單：
- PRD 管"做什麼"——功能、流程、邊界
- DESIGN管"做成什麼樣"——視覺風格、配色、排版、交互
你可以把它理解為：把 Figma 裏的設計系統，翻譯成 AI 能理解的語言。
一份完整的 DESIGN 通常包含這些內容：
4.2 怎麼生成 DESIGN md
我自己做了一個 Skill 工具 rico-skills/get-design-md，可以輸入任意網站自動生成完整的設計系統文檔，也可以在不同設計令牌格式之間轉換（DESIGN.md、tokens.json、variables.css、theme.css）。有需要的可以試試。
當然你也可以完全手寫。使用上很簡單：把 DESIGN.md 放到項目根目錄，然後對 AI 說：
使用 DESIGN md 優化設計
如果你有安裝設計類 SKILLS，記得要禁止它調用，不然會造成干擾。
執行後查看設計優化效果，再針對細節自己調整。完成後記得讓 AI 生成項目最終的 DESIGN md，保持文檔和實際代碼一致。
有了這份設計文檔，AI 在修改 UI 時就不再是"憑感覺"調整，而是按照一套明確的規範來執行。比如我說"給設置面板加一個新的開關"，AI 會自動沿用 DESIGN md 中定義的組件樣式和交互方式，不需要我每次重複描述。
下面是我執行優化後的頁面，效果我覺得是不錯的。
4.3 為什麼推薦在 Vibe Coding 中使用 DESIGN md
三個原因：
第一，AI 對結構化設計指令的理解遠優於模糊描述。 "按鈕要有懸停效果"不如"按鈕 hover 時背景色從 #2d6dc3 變為 #0066ff，過渡時間 150ms"。
第二，設計師寫的 DESIGN md = 把 Figma 的設計系統翻譯成 AI 能理解的語言。 你在 Figma 裏做組件化、定義 Variables、整理設計系統時積累的能力，在這裏直接有用武之地。
第三，一次寫好，每次迭代都能複用。DESIGN md 不需要每次都重寫。項目初期花時間定義好設計規範，後續所有的 AI 修改都會自動遵守，保持風格一致性。
設計師在 Vibe Coding 中的獨特優勢就是：你比 AI 更懂什麼是好的體驗。DESIGN md 是你把這個優勢轉化為實際效果的工具。
4.4 驗收檢查清單
最後再執行下面這些檢查，就已經完成了一次完整的 Vibe Coding 項目改造。 從選技術棧、寫 PRD、用 PRD 控制 AI、到設計優化和驗收，整個流程都走了一遍。
五、核心心得
在結束之前，分享幾個在實際 Vibe Coding 過程中總結的關鍵心得：
1. PRD 是控制 AI 方向的最有效工具。
PRD 的價值不是"寫得正式"，而是讓 AI 看到項目全貌。它知道目標、邊界和驗收標準後，就不會只根據你當前這一句話臨場發揮。
2. 文檔體系（PRD + DESIGN.md + CLAUDE.md）讓 AI 更可控。
PRD 管"做什麼"，DESIGN.md 管"做成什麼樣"，CLAUDE.md 告訴 AI "當前代碼是什麼樣的"。三份文檔配合使用，AI 幾乎不會做出意料之外的修改。如果項目複雜，就進一步按照漸進式披露的思路來做。
3. 從簡單項目開始，搭積木一樣推進。
rico-md 從一個單文件項目開始，逐步模塊化、逐步完善。每一個功能完成，檢查通過，git 做好備份，再繼續下一個功能的開發。
4. 讓 AI 定期總結當前狀態。
在長對話中，AI 的記憶會逐漸模糊。每隔幾輪對話，讓 AI "總結一下當前項目的狀態和最近的改動"，能幫它重新對齊上下文。
六、附錄：幾個可以直接複製的 Prompt
下面這些提示詞可以直接複製使用。你不需要一次性全用，按當前階段挑一個就行。
七、最後
這一篇原本還想把框架案例一起講完，但後來發現，很多人真正卡住的不是框架，而是最開始的項目選擇、文檔梳理和第一步操作。所以我把這部分拆開，講得更細一點。
所以這一篇我們做了一個項目改造案例：從選技術棧、建立文檔體系、寫 PRD、用 PRD 控制 AI、用 DESIGN md 優化設計，到最後的驗收。看似內容不少，但其實主要是和 AI 交談，出好文檔並執行，實際上並沒有那麼耗費時間。耗時比較多的部分，其實是我通過視覺去調整主題樣式和排版。
下一篇，我們會再進階一點，用 Astro + Tailwind 的現代框架來做個人作品集網站/Landing Page，以及涉及一下 React 和 Vue 相關的科普，然後對項目做橫向對比，最後把項目部署上線。從零構建到部署，完成整個閉環。
有興趣的話，可以先看看下面我特地開發的開源模板項目(都有中英文版本)：
集合： github.com/ricocc
1. 給 Vibe Coding 開發的啓動模板
2. RicoUI SaaS 模板
3. RicoUI 個人網站模板
如果你在這個過程中做了自己的改造項目，或者有什麼疑問，歡迎交流——微信 rico-ui
我是 Rico，感謝閲讀！