Vibe Coding 很多人都試過，叫 AI 做個小工具不難，難的是做到一半開始亂掉。這篇想整理一套比較完整的 AI 寫程式流程，從讀專案一路走到上線。
內容整理自設計師兼開發者 Rico 在優設網的實作紀錄。他用兩天的空閒時間，把自己每天在用的截圖美化工具重做一遍，取名 RicoScreenshot，程式碼開源在 GitHub。
他想說的其實很簡單，提示詞不用多厲害，知道每個階段該讓 AI 做什麼、做到什麼程度再往下走，比較重要。
為什麼拿截圖工具當第一個練習
RicoScreenshot 是以開源專案 image-beautifier 為基礎的二次開發。原專案底子不錯，只是功能陽春，Rico 用久了累積不少需求，像更多背景、標註工具、裝置外框、更順手的匯出，這次一起補進去。
專案是純前端，沒有資料庫和帳號系統，改完馬上能在瀏覽器看到結果。他覺得這很適合新手跑第一次完整流程，從讀程式、規劃、設計、測試到部署都會經歷到。
他也提到，很多教學做到「功能能跑」就結束了。但能長期用的產品，還要處理預設狀態、資訊層級、操作路徑和回饋，這剛好是設計師的強項。
第一步：先讓 AI 讀懂專案，別急著寫程式
AI 還沒理解整體架構就動手，很容易做出跟原架構對不上的局部方案，越後面越難收拾。所以第一步只做一件事，讀專案。
Rico 給 AI 的指令就一句：通讀專案，把架構和規範寫進根目錄的 AGENTS.md。之後每個新對話，AI 先讀這份檔案，動手前就有上下文。
這個階段的目標是確認 AI 真的懂了。他會自己檢查核心模組有沒有理解錯、資料怎麼流動、有沒有把舊程式誤認成主邏輯，比較細的架構說明再請 AI 整理到 DOCS/ 資料夾。
讀懂之後也不用預設先重構，原架構清楚就沿用。真的要整理，原則是只調結構、不加功能，兩件事混在一起，出錯時很難判斷是哪一步造成的。
第二步：用 DESIGN.md 把視覺規範先定下來
AI 寫一個按鈕、一張卡片都不難。問題在於連續寫了幾十個元件之後，還能不能維持同一種視覺語言。
所以 Rico 在根目錄維護一份 DESIGN.md，記錄主色、字體、字級、圓弧、陰影、間距、按鈕與面板樣式、圖示來源和深色主題規則，請 AI 先照規範統一目前的畫面。
他也提醒，設計類的 Skill 不是裝越多越好。規則重疊時，不同作者的審美會混在一起，最後做出來沒有明顯錯誤，卻也沒有方向。
他的分工是 DESIGN.md 管專案應該長什麼樣，少數幾個 Skill 負責檢查互動，例如動畫有沒有必要、回饋準不準。
圖示也要統一。AI 臨時生成的 SVG 線寬和視覺重心都不太一樣，排成一排就亂了，所以他選定 Mage Icons 圖示庫，並把來源寫進 DESIGN.md。
第三、四步：用 TODO 管功能，一次只做一件
視覺方向定了，才規劃功能。需求來源大概三種，原專案 README 留下的待辦、自己長期使用累積的不便，還有競品。
看競品時他不只抄功能清單，更在意預設背景是什麼、匯入圖片後第一步發生什麼、匯出要幾步。很多體驗差距就藏在這裡。
需求整理成 TODO.md，標上優先順序、複雜度和完成狀態。對話斷了或換模型接手，讀一下 TODO 就知道進度。到這裡，專案已經有三份上下文檔案：
- AGENTS.md：這個專案怎麼運作
- DESIGN.md：這個專案應該長什麼樣
- TODO.md：這個專案接下來做什麼
接著開發交給 Agent，從 TODO 最上面開始，一次做一個功能。他不交代 React 怎麼寫，只描述這個功能最後應該怎麼運作。
一輪大概是：實作、執行、檢查、更新 TODO，再進下一個。上下文都在檔案裡，每輪對話反而可以很短。
還有一個常見狀況，AI 很容易過度測試，改一個小地方也跑完整建置。他建議在 AGENTS.md 寫清楚，測試規模要跟修改規模相符。
第五步：手動走查，是設計師最有優勢的一步
這一步是 Rico 花最多注意力的地方，也是很多教學略過的部分。功能做完只代表能用，能用和好用之間還差很多細節。
他舉底部工具列為例。放上面還是下面？預設展開還是收起？展開會不會擋到畫布？收起後使用者找不找得到入口？
直接問 AI，它放哪邊都講得出道理。Rico 是自己用過之後判斷，標註屬於低頻操作，移到底部更靠近畫布，也減輕畫面上方的壓力，收起後在左下方保留明確入口。
我覺得這段最值得記下來。真正重要的不是提示詞，而是親自用過之後，能第一時間發現哪裡怪怪的。
說不清楚問題在哪也沒關係，先模糊描述，例如「底部工具列左邊第三個圖示互動不對」，Agent 讀過程式碼，通常定位得到。模型支援圖片的話，直接丟截圖更快。
第六步：測試上線，讓 AI 寫程式流程留在檔案裡
收尾時 Rico 做兩類檢查。一是請 AI 跑 lint 和正式建置，二是把核心路徑寫進 DOCS/development.md，自己一項一項走過才部署。
他也請 AI 把文件整理好，想法只有一個，把長期有價值的資訊從對話搬進檔案。下次開新對話，AI 讀完就能接著做。
因為產出是純靜態檔案，他用 Cloudflare Pages 部署，連上 GitHub 儲存庫就能上線，之後每次 push 都會自動重新建置。
Rico 給新手的建議是，不用一開始就挑戰複雜的商業專案，找一個規模適中的開源前端專案，從讀程式做到上線就好。
重點是知道自己在哪個階段，只解決這個階段最重要的問題。讀專案時專心讀，定視覺時不要順手加功能。
我想這套 AI 寫程式流程最值得帶走的，是先想清楚階段，再讓 AI 動手。完整走一遍，也許會比做十個 Demo 更清楚。
如果你也在想 AI 產品的介面節奏該怎麼拿捏，可以接著看這篇：AI 越快，使用者越不放心？聊聊「刻意放慢」的介面設計。
AI 寫程式流程的常見問題
開始 Vibe Coding 之前，PRD 要寫很詳細嗎？
不用。Rico 的看法是把專案在做什麼、用什麼技術、哪些地方不能亂動寫清楚就夠，其他邊做邊補。
不確定功能做不做得出來怎麼辦？
把需求列出來，請 AI 評估優先順序和實作成本，它通常比你想的更清楚邊界在哪。
設計師做 Vibe Coding 的優勢在哪？
在手動走查。AI 可以很快修改，但哪裡卡、哪裡多餘、什麼狀態更符合使用者預期，還是要真的用過才判斷得出來。
