大 AI 時代：產品設計思維與 Vibe Coding

大 AI 時代 — 產品設計腦、Vibe Coding、產品上線！從需求出發，專注於產品與 User Story。Code & UI？交給 AI 來辦！

Aug 2, 2025 · 6 min read

在開始之前…

我是個設計師，幾乎沒有 coding 的概念

對於前後端技術上的認識，幾乎都是在工作每個專案中或者和工程師朋友們交流時認識的，所以基本上這篇比較像是自己的這次實作上的經驗分享，沒有要說誰準備要被 AI 取代之類的（先說清楚講明白 😂😂😂😂

大概在剛出社會在超小型公司，可能有自學一點 html、css 拿來魔改 WordPress 模板之外，其實一直以來都沒有碰過任何的 coding。曾經想幫自己寫一些 figma Plugin 也因為自己對於技術上了解的不全面，選擇躺平。

自己的作品集網站也是用 Framer 這種 no-code website builder 去製作的，完全沒想過自己也有可以實際用 IDE 去寫出個什麼來。

直到今年，各種 LLM Coding Tool 出現之後，真的是直接發現新大陸。從一開始請 AI 幫我寫腳本「可以讓我同步 icloud 的檔案變動，同時自動備份到外接硬碟」這種小型的 script，到最近因應公司開發環節產生出的痛點，而開始著手製作的 Figma Plugin…

只能說：
跟 AI 真的是相愛相殺，他會幫你很多忙，同時也有時候會幫倒忙 😂

這次會分享自己如何使用 VS code + copilot 從 0 開始製作出一款 figma plugin（其實是兩個但因為核心原理很像所以挑一個講）

在開發之前，開發環境很重要。

就算只是個小 Plugin，開發環境還是不能隨便

為什麼會選 Figma Plugin 作為第一個實際做出來的產品，說實話就是因為相對簡單（笑）

Figma 只要右鍵選單點一點，選擇製作一個新的 plugin，基礎設定點一點按一按，他就之前幫你把最基礎的檔案建立好。我不需要去挑選要用什麼架構，基本上就是用 TypeScript 去編譯，用 html / css 來製作 UI（如果有）

會需要前期人工操作的就是：

安裝 VS code，然後用 VS code 或其他 IDE 開啟 plugin 的 folder
安裝 vs code 的 copliot 套件
安裝 node.js + npm
開啟 TypeScript 的編譯，讓所有在 ts 的改動都能夠被編譯成 js 才能在瀏覽器上執行。

一套 DOREMISO 霹靂卡霹靂拉拉就可以開始進入開發了…嗎？

專案的版控，也很重要。

沒用過 GitHub？別擔心，你沒有落後太多

GitHub 沒學過，不知道怎麼版控？沒關係，現在開始學也不遲！而且有了 ChatGPT，他可以用任何你自己擅長的領域用比喻的方式教會你怎麼執行各種 git 的操作（至少我是這樣子學會這個東西的）

Okay fine, my commit messages are a mess…but having version control still gives me so much peace of mind.

軟體開發我認為，不像我們設計師在 Figma 上面畫圖，有各種 page 可以藏一堆流程、架構還有可能已經不要的稿件屍體等等的，我隨時可以去只有我知道的那個神秘小角落把它抓回來。

開發基本上都會是在最新的版本進行開發。你每次改動，尤其是讓 AI 幫你改動，很高機率一不小心就直接陷入泥沼而且怎麼樣都爬不出來。這時有版控讓你回到前一版真的很方便。（當然衝突什麼的我們先不討論）

而且不一定要用 terminal 去操作 git，光是 GitHub 自己出的 GitHub Desktop，或是 Atlassian 出的 SourceTree，這些視覺化 Git 版控的 IDE 讓你不需要知道每個指令，還是可以輕鬆管好版控。

所有在 production 正式環境運作，比如說現在正在 Figma 大家可以操作的版本，會是主線 (Main)
今天要開發一個新的功能或者修 bug，會需要從主線拉分支 (Branch) 下來改動，才不會影響 production 的 codebase。我 branch 都開的隨意，比如說 proj-export-setting，就是這個 branch 要拿來修改輸出設定的 code。
在一個變更段落後提交 (Commit) 你的改動，比如說改了 UI、改了 csv 輸出的 format、比如說改善了所有 ux writing。
將所有已經 commit 的改動推送 (Push) 到雲端 repo (Remote Repository)
確定一切 ok、LGTM 的時候，將 branch 開 PR (Pull Request) 整併 (Merge) 回主線，同時還可以在 GitHub 去用 Release 管理版本號。

學會怎麼處理好開發環境、怎麼樣用 git 處理版本控制之後，終於迎來我們的重點！

出！一！張！嘴！（快樂）

接下來，出一張嘴時間到了。

專注於小任務 & 開好 spec & 說明清楚 User Story

簡單來說，把你腦袋的所有 Spec 用盡可能詳細的方式說給 AI 聽。

當今天公司做專案開發的時候，Spec 有漏時，有些工程師通常會跑來確認細節來對齊認知，有些會照著自己的想像，直到 QA 時才發現怎麼做出來這邊不一樣對吧 XD

現在跟 AI 對話時，基本上也是這樣。只是，他是個很擅長腦補的工程師，一不小心就會直接大歪特歪。所以基本上你提供的愈細節，他才能夠盡可能地完成你腦中的畫面。

由於開發一個產品，基本上會是由一個又一個小型可執行的模組組合起來，維護跟擴展性都會更好。所以在出一張嘴上，我盡可能都是以最小的模組去進行設計。

以上圖中我的想像為例，就是所有的標注都會在離最外層的 Frame 最近的一側進行標註，原因是我不希望標註會跨過整個 frame 進而遮擋到 UI 畫面。

🪄 Prompt 範例

我希望透過 plugin 的 command 指令 “annotate” 去觸發標註 keyName 的功能。

主要功能：選取一個 textNode 後，可以抓取他的 layerName 去進行標註。若沒有選取 textNode，請跳提示「請選取一個文字區塊來標註」

創造標注元件與排列方式：組成為：文字Label、一條 2px 的線段、一個 4x4 的圓形 vector。 Label 內文字的內容會抓取選取的 textNode 的 LayerName，整個 label 為 hug content 的 auto layout，padding 為 2px 4px。文字顏色為 #FFF，label 底色、線段、圓形 Vector 顏色為 #333。標註於左側時，auto layout 水平置中排列且 gap 為 0，由左至右為 label、水平線段、圓形 vector。右側則順序相反，其餘邏輯相同。標註於上緣時，auto layout 垂直置中排列且 gap 為 0，由上至下為 label、水平線段、圓形 vector。下緣則順序相反，其餘邏輯相同。圓形 vector 需貼齊 textNode 該側的中心點、且 label 與最外層父層的 layer 之間的 gap 為 60px。

對位方式：依照選取的 textNode 與最外層的父層 layer 之間的 gap 去計算。左側 gap 最小擇標註於選取的 textNode 左側，右側、上緣、下緣以此類推。若四邊 gap 等距，等於對齊右側。

創造元件&排列、對位邏輯請分別設成兩個獨立的 Utility。

以上 Prompt 大概提及了幾點：

你想做的功能是什麼，他怎麼運作？AC 是什麼？
使用者如何操作？有哪些回饋？
有沒有任何 edge case？
大概個 UI 呈現可能會長怎樣？

這些資訊都能夠有效地讓 AI 更全面理解你腦中的想像，然後在最短的來回中做出你想要的功能。

做好了一個模組，然後呢？

AI 也去給我開可行性會議！

由於我腦中的想像，這個 plugin 應該會有四個主要的功能，然後其中三個會需要 UI 介面跟使用者進行互動，另外一個單純使用 command 就可以完成。

但是超大的 scope 怎麼切？怎麼基於剛剛上面完成的 PoC 概念驗證去進行擴展？就需要 AI 去進行可行性評估。

🪄 Prompt 範例

接下來有幾個大功能需要實作：

我需要讓使用者可以選擇標註 label 內的小標籤資訊，且使用者需要手動輸入標註的 key Name，而不是抓文字區塊的圖層名稱。

標註完之後可能有數十筆資料，我需要另外一個 UI 互動去查看所有的標注資料，資料涵蓋 Key Name / 文案 / 標籤。而且可以修改 key Name & 標籤。

小標籤內容的定義為使用者自訂，需要讓使用者在開始標註前設定好。

請你依照剛剛完成的 PoC （自動對位與標註）來進行可行性評估，並在不改動基礎功能與邏輯的前提下，規劃好如何逐步擴展成第一版的 MVP。

在每個需要擴展功能的功能開發，都可以藉由這方式讓 AI 去依照現有的 codebase 去查看是否能夠妥善的擴展、同時讓 AI 評估哪些地方可能需要被切成更小的模組來更好維護，或者需要被重構之類的。

規模變大，測試變困難…

就算是個「簡單」的 Plugin，抓 bug 起來也是會嚇死人

雖然只是一個 figma Plugin，一開始可能會想說還好吧反正不太會壞掉吧？我錯了！大錯特錯！！！

在開始擴展功能，ts 跟 html 會有交互跟資料傳遞的行為時，各種奇怪的 bug 就如雨後春筍一樣冒出，我甚至不知道為什麼壞了或者是哪邊出了問題。這時才發現請 AI 幫忙處理 console log 或者幫忙寫 unit test case 有多重要。

於是後來才請 AI 整理整個 code base，並在每個資料傳遞或者動作的節點上加入 console log，並讓 console log 有足夠的資訊可以讓 AI 去判斷可能原因。

但是這並不夠…

有時 AI 就是覺得

「哪裡有 Bug？我復現不出來！我寫的 code 沒問題！！！」

這時你就是這個產品的 QA：

你要知道這個產品的每個功能的預期行為以及 AC 是什麼，
實際幫自己寫 test case ，並實際測試開發中的版本來體驗這次新增的功能。
紀錄每次的出錯，並重複幾次看看是否有成功復現。

這時，提供給 AI 的資訊就可以是：

🪄 Prompt 範例

剛剛在 console 跳出的 error message 為 OOOOXXXXX。
實際操作行為：開啟 XXXX 後在哪裡輸入 ZZZZ，選定 C 之後按下確認時，無法在 Figma 畫布上產生正確的原件。預期行為是能夠產生標註元件，但實際上出現結果為無法產出。且操作多次接成功復現。請協助除錯。

你提供的資訊越完整 — 發生了什麼、在哪裡發生、你預期的結果、實際的結果 — AI 就能越快抓到問題出在哪裡。

那 UI 的 bug 呢？嗯…設計師的鷹眼可不是叫假的 🦅👁️
直接截圖，跟 AI 說哪裡看起來怪怪的就好，像是：

「這個按鈕應該要垂直置中，但現在歪了 4px。」

當自己做的 AI 產品的 QA，說真的還蠻療癒的。除錯這件事，重點不再是「哪裡壞了」，而是想辦法讓你這個機器人隊友…更懂你一點。

需要先在 Figma 裡把 UI 設計好嗎？

劇透：這次我沒有。至少…這次沒有。

Figma 的 Dev Mode 現在可以接 MCP 了，聽起來超猛（雖然我自己還沒試過 🙈）。很想知道大家都怎麼用的。

但說真的，整個 plugin 專案，我一個畫面都沒有在 Figma 裡設計過。一個都沒有。

我給 AI 的東西基本上就是一堆只有我自己看得懂的 wireframe 😂

真正有幫助的是，我一開始就先定義好幾個 component token：

色彩 token
字體設定
按鈕樣式與 padding
輸入框的各種狀態與行為
等等

所以我請 AI 做各個模組的時候，它已經有足夠的資訊，可以做出接近我腦中畫面的東西。重點一直都是一致性跟模組化思維，不是要做出像素級精準的 mockup。

話是這麼說…但因為 MVP 階段我沒有花心思打磨 UI，有些畫面最後長得，嗯…是真的蠻粗糙的。

The current production version of the plugin. It works, but it's not exactly easy on the eyes

上面這張圖裡，我用表格呈現標註資料。技術上是可以動啦，但用了幾次之後發現：

資訊反而更難解讀，不是更好讀
表格很佔空間
Plugin UI 一開啟，整個 Figma 畫布被擋住一大半，根本沒辦法對照畫面

所以這禮拜初，我突然有個念頭：乾脆直接把 UI 整個翻新好了？

我跟 AI 快速跑了一次可行性評估，發現需要改動的地方主要是 UI 跟資料渲染那層，核心邏輯可以完全不動。於是我又進入「出一張嘴」模式 — 這次多加了一張超級隨便的 wireframe 當參考。

🪄 Prompt 範例

根據剛剛的可行性評估，我想把 UI 排版改成這樣：

• 把表格換成卡片

• 編輯 / 定位 / 刪除的邏輯不變

• 篩選器從下拉選單改成 chip 式的切換

• 把匯出跟搜尋移到畫面下方的浮動按鈕

（參考下圖）

先從第一個元件開始：卡片。新的卡片排版大概是這樣：

上排：標籤 + 3 個操作按鈕（編輯 / 定位 / 刪除）

中間：Key Name

下方：Content

點下「編輯」之後，卡片會切換成編輯模式：

上排：標籤的下拉選單 + 儲存按鈕

中間：Key Name 輸入框

下方：Content（還是只有預覽）

編輯模式時，其他卡片全部要 disable。

…

…以此類推。