身為設計師和創業者，我的心中時不時會冒出一些天馬行空的想法，但礙於自己對技術的理解有限、遇到瓶頸時總是無法有很好的進展，後來久而久之就常常會畫地自限，覺得自己應該無法推進這些想法，然後先把這些想法擱置在角落塵封了。
但這陣子 AI 的話題開始變得很火熱，過去這幾個月來，我也一直沈浸在所謂的 Vibe coding 的世界當中，不得不說， AI 真的是打開了一個新世界的大門，尤其是對於非技術背景的人來說，那種「只靠一張嘴」就讓 AI 把心中的想法具象化的感覺，真的有種難以言喻的快感。
不過過程中也不是往往一帆風順，更多的是充滿了挫折感，有很多時刻我都在懷疑自己、思考人生，心裡想著「我真的有辦法做到這件事嗎？」「是不是其實根本是我太天真了？」
雖然我知道自己還沒有完全達到理想的狀態，距離實現「打造可上線的產品」目標還有一大段路要走。但經過過去幾個月的探索，我深刻的體悟到一件事 — 就是要透過 AI 來打造出一個小型產品應該不是不可能的任務，我相信每個願意努力的人都能夠達成自己的目標。
有了這樣的認知後，對我來說是心態上一個重要的轉捩點，也讓我對未來的挑戰有了更多的信心和期待。
寫在故事開始之前
首先我要先說，我的本職是設計師，不是專業工程師，所以我對技術的認識都是透過工作中和工程師夥伴交流學習的，因此這篇文章算是非常適合給無技術背景的人看的。
雖然在職涯的早期，我的確學過一些基礎程式，大概是大家熟悉的 HTML、CSS，還有一點點的 jQuery ，目的希望讓畫面能夠動起來，大概近十年前用來拼湊出一個靜態的 Landing page 還算堪用（其實我人生第一個設計作品集就是完全手刻程式出來的）。
但後來這幾年有了 Webflow 和 Framer 這類型的 No-code / low-code 架站工具，我已經好幾年沒碰過原始程式碼了，基本上透過視覺化的程式編輯介面就能做出還不錯的互動網頁，直到 AI 的出現，開始慢慢了改變了整個遊戲規則。
隨著 Vibe Coding 和 AI 開始融入整個工作流程的崛起，設計師們突然有了一個新的遊樂場，也讓我們重新思考自己的角色定位，重新去想像我們究竟能夠創造什麼東西，即使我們完全理解技術。
這段時間裡，我玩過 Claude、Bolt、Lovable、V0 等等對話式程式碼工具生成工具，當然還有 Cursor 和 Windsurf 相對進階一點的 AI-powered IDE 工具。我的專案一開始都是一些小型實驗性質，或是那種快速、用完即丟的概念驗證類型。但做到後來我一直在問自己：如果我能開始建造一些可重複使用的元件、甚至是可以上線的產品呢？
因此我決定記錄這段自我探索的學習旅程，我用 Windsurf 和 Cursor 進行 Vibe Coding 的經驗，包含我的學習和挫折、和與它們的愛恨情仇，以及一路上學到的一些課題、甚至是你可能在過程中想要留意的常見陷阱。
在開發之前，你需要先把專案環境設定好
如果你只是要快速拼湊出一個粗糙的原型(Prototype)快速展示，那你大概不用太擔心專案設定的問題，反正只是溝通用，一下就要丟掉了。
但是如果你打算打造一些可重複使用、或是會持續迭代的東西，那從一開始就好好設定專案絕對是值得的，就像你在設計之前會先大概規劃好 Figma 檔案和頁面一樣。
選擇主流技術對於後續開發會輕鬆很多
對於程式碼來說，你會需要了解一些技術架構，我目前慣用的技術組合是：
React.js 搭配 TypeScript：用於前端開發
Vite：作為快速、現代化的建置工具
Tailwind CSS + Shadcn UI ：用於 UI 樣式及元件設計
Netlify： 用於簡單快速部署網站（你也可以用 Vercel）
Git/GitHub：用於版本控制與雲端程式碼管理
當你從零開始一個專案的的時候，你可以在 Cursor 或 Windsurf 裡使用類似這樣的提示，它應該會幫你把大部分需要的環境給設定好，如果卡關就把錯誤貼給它修正即可。
🔮 Prompt 範例
「我想要建立一個新的 React.js 專案（請使用 TypeScript），請使用 Vite 作為建置工具。另外請幫我設定好並配置 Tailwind CSS + Shadcn UI，讓它可以立即使用。專案結構應該要方便部署到 Netlify，包括用於部署設定的 netlify.toml 檔案。」
在專案前期就把環境設定好，可以為你省下後續許多的頭痛問題，特別是在重構程式碼或部署時可能會遇到的各種小麻煩。
隨時管理產品開發進度 — 版本控制至關重要
如果你還沒有使用過 Git 或 GitHub 來做程式碼管理與版本控制，現在可能是開始學習的大好時機。
不像是在 Figma 裡你擁有無限延展的畫布，讓你可以安全地把草稿和各種素材放在一旁，寫程式碼開發的過程是不太相同的，你會必須要一直在「最新版本」上工作，而有時候這個最新版本是比較好的版本⋯但有時候可能不是。
版本控制做的好，花了幾小時做的東西壞掉時才不會想哭
這就是為什麼從一開始就整合 Git / Github 到你的開發流程中是非常必要的，它讓你在事情出錯時可以回到前一個能正常運作的版本，尤其是當 AI 不知道為什麼做了一些奇怪的事情，而你無論如何努力都找不到修復方法的時候（aka 走進死路整個壞掉）。
另外，把你的程式碼推送到 GitHub ，也能幫你追蹤和視覺化你的開發進度。其實你不需要對 Git 或 Github 瞭若指掌，IDE 當中都有視覺化的介面可以快速上手，你可以先從從簡單的指定開始：
在有明確目的變更後提交 (Commit) 你的進度
在嘗試全新想法或功能時建立一個新的分支 (Branch)
推送 (Push) 到遠端儲存庫（Remote repository），並在一切運作正常時合併 (Merge) 你的請求 (Pull Request, PR)
有了版本控制，你可以很好的保留所有編輯歷史紀錄，並且輕鬆回到任何先前的檢查點，再也不用怕你的檔案被 AI 做壞掉。
Cursor / Windsurf 讓版本控制變得超級親民，你幾乎不需要碰到終端機 (Terminal)。而當你遇到困難卡關時，ChatGPT 會是你最好的朋友，基本上它無數次引導我克服和解決一些奇怪的挑戰和設定。
AI 提示詞秘訣 - 盡量提供足夠的背景資訊得到最理想的結果
在用 AI 進行程式碼開發時，不要過於吝嗇你的提示詞 (Prompt) 文字內容。你可以把 AI 想像成一個非常聰明、懂很多的的工程師，但可惜的是它不會讀你的心。
如果你在要求它做某件事之前，沒有給它足夠的脈絡與資訊，它很可能會給你一個偏離目標的產出。
理想情況上，你可以試著去描述：
你具體想要打造什麼功能
這個功能應該如何運作
使用者會如何與它互動
你可能想到的任何邊緣情況 (edge cases)
甚至是 UI 畫面、排版大致上應該長什麼樣子
還有最重要的，你不希望看到什麼行為出現在這個功能中
🔮 Prompt 範例
「請幫這個文字編輯器建立一個字型大小的選擇器。使用者可以從下拉選單中選擇預設大小（選項從 12–64px、間隔 4px），選擇的大小應該只套用到目前畫面中選取的文字。
如果沒有選取文字，就設為新文字的預設值。如果選取範圍有多種大小就顯示『混合』。點擊外部應該關閉下拉選單。
UI 應該要乾淨風格且響應式（參考附圖）。避免全域套用樣式或接受無效值的輸入。」
另外，用視覺來輔助提示詞也很有幫助，我常常會放上一些網路上找的 UI 的截圖，或是在 Figma 裡快速模擬一些畫面。圖片在幫助 AI 理解你的確切意思方面算是滿有效的，特別是涉及到 UI 狀態或元件結構時特別有幫助。
先讓 AI 制定一個縝密的計畫，之後再進行開發
一般來說，在跳進 Figma 進行設計之前，大多數有經驗設計師會先往後退一步，用宏觀的視角去釐清使用者的需求以及要完成的任務（JTBD）、定義專案目標、了解限制等等，並明確了解成功的定義是什麼，一旦心中有了基本的計畫，我們才開始去真正把想法視覺化。
而用 AI 在進行程式碼開發時也是類似的的邏輯。
AI 可以透過很多方式來開發出某個功能，但如果不巧選錯方式，程式碼容易變的很複雜且難以維護。有可能一個小小的改動，就可能會在整個系統中產生意想不到的連鎖反應，之後就會是一連串 debug 或卡關的過程。
計畫的目的就是讓 AI 自己先思考和自我思辨，通常執行後效果會更好
這就是為什麼先要求 AI 去制定一個計畫後再開始行動會對整體流程有很大的幫助。
你可以試著從這樣的提示詞開始：
🔮 Prompt 範例
「根據以上功能需求，你可以先制定一個詳細且低風險的計畫來開發這個功能嗎？」
「計算看起來不錯，現在讓我們根據你的計畫來實作，確保我們謹慎管理潛在的風險，現行的功能都要可以正常運作。」
我發現當我先要求 AI 給出一個計畫，然後好好檢視它的計劃是否合理，AI 更有機會開發出與我腦海中畫面一致的成果，也大大減少了後續來回修改的次數。
尤其當我需要重構一個大型元件或架構時時，AI 在分解計畫和有效管理風險方面表現得算是非常出色。
不要讓 AI 認知超載，試著限縮需求和提示範圍
你可以試著想像一下，如果你的 PM 一次丟給你 10 個任務，你大概會覺得非常不知所措，而且在執行過程中肯定有些事情會漏掉，當你與 AI 工作時也會發生類似的情況。
如果你在單一提示詞中給它太多需求或過多細節，很有可能它不會把好好的每件事都做對。相反的，如果試著把你的提示拆解成更小、更專注的塊狀結構（一次處理一個功能或模組），AI 會更好理解。
這也有助於保持功能邏輯乾淨，並減少破壞程式碼其他部分的機會，特別是因為產品邏輯和不同模塊可能高度相互關聯、互相影響。
在下提示詞時要盡可能具體，盡可能詳細地描述你想要的東西，最好使用逐步的使用者流程來描述。每個提示專注和限制在 UI 上或其中改功能也很有幫助。這樣一來假設出了問題，後續要除錯和調整會相對容易得多。
🔮 Prompt 範例
「我想要建立一個文字框元件，讓使用者可以透過拖拉角落控制手柄來手動調整大小。
文字框應該支援寬度和高度的調整
在滑鼠懸停或選中時顯示可見邊框和調整控制點
文字框需要維持最小尺寸（例如 100x50px）
調整大小時，裡面的內容應該順暢地重新排列
確保調整大小不會影響頁面上的其他元素
現在只專注於調整大小的互動，不要處理到文字框裡面的編輯行為。」
在除錯（Debug）時可以向 AI 分享你的觀察
在 Vibe coding 過程中有一件幾乎肯定會發生的事：那就是你會遇到各種 bug、很多 bug。
隨著你的原型或產品變得更複雜，例如有多個元件和功能一起同時運作、邏輯又綁定，事情就非常容易出錯。而且由於 AI 在做大部分的執行開發，要靠你自己去精確找出哪裡出錯可能很困難，因為你並沒有親自去寫程式碼。
這就是為什麼很重要的地方是：
你對產品預期的行為要有清楚的理解
實際比較你在開發成果看到的體驗進行比較
去識別什麼東西感覺「怪怪的」以及原因是什麼
設計師通常對 UI 和 UX 的上的不一致有相對敏銳的眼光，所以我們可以善用這個優勢。只要有看起來或感覺不對的地方，可以去分享截圖或模擬圖（例如「預期效果」vs.「實際效果」），並一步步引導 AI 修復問題。
和 AI 分享你的觀察非常重要，有時候一些小小的差異都會幫助它找到可以修正的蛛絲馬跡
舉例來說，如果兩個元件看起來相似，但只有其中一個是正常運作，那就會是很好的線索。這可能意味著它們的底層程式碼結構不同，可以請 AI 進行調查並同步這兩個元件。
如果 AI 產出的結果有點出乎意料，我通常會分享我看到的和我嘗試過的，來幫助 AI 識別問題的根本原因。
另一個技巧是去仔細閱讀 AI 說實際它做了什麼，並再次檢查結果。如果你發現它講一套做一套，可以作為證據指正出來，例如跟它說「你剛剛說這個函數說它會更新狀態，但點擊時什麼都沒改變」給 AI 更好的脈絡來除錯。
這這個過程實際上也幫助我學習程式碼如何在底層運作，雖然 debug 的過程很令人挫折，但它也是很棒的學習方式。
當你卡住時，可以試試切換到不同的 LLM 模型
使用 Cursor / Windsurf 最大的優勢之一，就是是它可以讓你在不同的 LLM 模型之間切換。我發現這對 Vibe coding 來說非常有幫助，因為切換語言模型有點像是請不同的工程師來幫忙，每個模型都有自己的思考方式、解題方法和解釋事情的風格。
它們都很聰明，但各自都帶著獨特的方法來幫助你。
當我在處理某個棘手的問題時，如果發現多次提示後仍然撞牆時，我的慣用招數是去切換模型。我會解釋我想要做什麼，包含我已經嘗試過的，而新模型通常會從全新的角度來處理問題，並去嘗試一些我之前沒有考慮過的解決方案。
不同模型的思考方式都不同，遇到卡關時都可以試試看
就個人而言，我預設使用 Claude 4，以 Gemini Pro 2.5 作為備用，你可以自己實驗看看哪些模型最符合你的工作流程，有時候不同的 LLM 在處理問題的方法上會有不同的想法。
真的不只一次，我花了太多時間卡在一個頑固的 bug 上，然後我就切換模型試試看，加上重新去定義跟描述問題，突然事情又可以開始順暢地進行了。
不過我還是不建議平常太頻繁的切換模型，就像與不同的隊友合作一樣，你需要適應每個模型的「風格」並重新建立脈絡。所以找到你的慣用模型，大部分時間都使用它，並留個備用的模型來處理一些卡住的問題。
開發到一個階段後，你還是需要去理解你的程式碼架構（Codebase）
我知道很多設計師（包含我自己）都不是很喜歡閱讀原始程式碼。但一旦你專案中的程式碼庫慢慢長大，它可能會感覺像一個黑盒子，所有的邏輯、UI 和功能全部混在一起，變得難以閱讀和查找。
尤其當你在打造一個複雜的的原型或產品時，去理解事情如何在底層運作是相對重要的。就像在 Figma 中，你會為了追求效率和一致性會去規劃圖層和元件，同理你也可以試著去掌握你的程式碼庫是如何架構的，特別是這些完全由 AI 幫你生成的元件和頁面。
這些元件通常是可重複使用的「外觀」「功能」或「邏輯」，去了解它們如何被建構，可以幫助你在迭代原型時移動得更快、更有信心。
當你熟悉 codebase 你可以非常容易指向對的位置讓 AI 有更精準的脈絡
理解程式碼庫的另一個大好處就是，當你與 AI 對話時，你能夠指向明確的檔案來作為參照。你也可能會更清楚遇到問題時 bug 的根源可能藏在哪裡，或對哪些檔案需要調整做出更有根據的假設。如果我知道我的元件是如何架構/組織的，我可以很容易的去指向 AI 去看正確的地方。
這裡有個我用的簡單技巧，如果元件太複雜難以理解，我通常複製檔案的程式碼，貼到 ChatGPT 裡，然後問這樣的問題：
這個檔案在做什麼？用簡單的語言解釋給我聽
這裡這段程式碼處理了什麼邏輯或功能？
這一個檔案裡是否處理太多東西？需要拆解嗎？如何拆解？
如果我想要解重構這個檔案提升效能跟維護性，你有什麼建議？
這些過程讓我有更清楚的理解，並幫助我決定是否該把東西拆分成更小的部分。如果你的目標是擴展你的原型或有效的重複使用元件（不論 UI 和邏輯都是），了解你的程式碼庫是絕對值得的。
Vibe coding 流程
總結而言，Vibe coding 為身為設計師的我開啟了一個全新的大門，它讓我能夠打造一些我從未想過自己能夠獨立開發創造的東西。
在 AI 的幫助下，我現在可以製作高保真原型甚至是 MVP 產品，不僅讓我的想法落實、也讓它們更容易被驗證和溝通。我想要以分享我的 Vibe Coding 流程如何運作的快速概覽，幫助在達成目標的同時，盡量減少路上的阻礙。
你可以參考以下的 AI 開發視覺流程圖 👇
Vibe coding 的流程很多時候是動態的，但掌握大方向會避免自己走入死胡同
寫在最後的一些想法⋯⋯
當我在 Vibe coding 的同時，我發現我其實也一邊在設計、開發、測試和體驗原型，因此這個流程真的促使去我思考端到端的使用者旅程，包括我常常在 Figma 中設計時可能遺漏的一些特殊情境，因為當你能實際操作產品時和互動時，很多原本看不到的問題會一一浮現、變得更加明顯。
Vibe coding 的過程很有趣且超級有成就感，但有時我會卡在一些很小的事情（例如只是讓某些小東西正確運作）上，導致有時候花費的時間比預期長得多，去判斷和知道何時放手並繼續前進（選重要的事情）很重要。
身為設計師，我的完美主義偶爾會發作，特別是當我發現自己沉迷於調整微小的視覺細節和互動時，我希望每個像素都可以看起來盡可能完美，但總歸而言，原型的精神應該要是快速且粗糙，只要能驗證想法即可，除非你打算打造一個真正的產品。
我認為用 Vibe coding 來開發製作原型的真正強大的地方在於你能更快地獲得對想法的一致性和認同，讓其他人可以真正去「感受」和「體驗」產品，而不只是去想像它應該如何運作，它也有助於從使用者測試中收集更誠實的回饋，這非常有價值！
