近幾年 Vibe coding 大行其道，身邊的設計師、PM 也都開始用這類的工具加速產品開發的流程，這些工具對設計師來說最大的好處是加速溝通的效率，可以填補在靜態 Prototype 、Wireframe 難以呈現的流程或動畫，甚至是細微的體驗。但如果要拿這個 Prototype 變成一個實際可交付的工具，那又是另外一回事了，接下來我分享一個失敗的案例（？）
結論在前，使用各種 Prototype AI 工具，從 v0、Bolt 到 Cursor，都一樣，使用前需清楚認清自己要達成的結果是什麼，否則很容易陷入假性的「有魔法」般的產出。
套一句，在 Generative AI 2025 演講聽到的：
“小心你許下的願望” (Be careful what you wish for)
有一陣子我把 AI 當成「工具」，有時也發現它並不是全能，甚至只用最基礎的功能（像是翻譯）時，對我來說並沒有一種非用不可的急迫或焦慮感。
的確有些工作流程，會想說「啊…這邊要是有 AI 幫我該有多好」、有沒有什麼「魔法」可以幫我做我不喜歡或感到疲乏無聊的流程，該有多好。
因為萌生這些想法，我開始嘗試做第一個工具：在 Figma 內嵌入 HackMD 的筆記
實際的功能是：貼上 HackMD 的筆記網址，就能在設計稿內渲染需求文件，我就能在 Figma 內同時瀏覽需求文件又可以設計。
AI 做工具跌坑之路 – 在 Figma 內渲染 HackMD 筆記
這整個專案是從今年 1、2 月開始，我是用 GitHub copilt 幫我撰寫。在過程當中請 AI 依據 Figma 當時最新的 Widget API 文件，然後我跟他許願：
貼上 HackMD 的筆記網址，就能在設計稿內渲染 HackMD 的筆記，我就能在 Figma 內同時瀏覽需求文件又可以設計。
使用最新的 Figma Widget API
接著就是， 各 種 坑。
首先，我的錯誤是我沒有完全做過 Figma 的工具的經驗，所以當出錯時，我會反覆問 AI 為什麼出錯、修正錯誤，同時看文件，然後文件看不懂時候又回去讀一開始的 API 文件。
後來才知道，使用 Widget 渲染出的任何元件，基本上都要用 Figma 的工具「畫」出來，而 Figma 畫布內顯示的所有物件就是用 Canvas 的技術。
因此，文字、按鈕、形狀，都要看 Figma 的 Widget 有沒有對應的 API 可以畫出來。
但即使是 Figma 可支援的 API ，也不像寫網頁 CSS 那樣彈性，例如尺寸無法使用 calc() 這種語法來做計算。
雖然我所要渲染的內容並沒有很複雜(基礎還是文字或圖片)，但要從 HackMD 的 Markdown 格式再到 Figma Canvas ，過程就讓花了很多時間解渲染列表、清單、Check list 等格式。
我想像的流程：
我後來評估，讀取 HackMD API 對我來說相對進階，且如果公開文章是可以渲染成功，那麼之後再研究串 API。
之後將專案分享給工程師看，工程師才發現我在程式碼內「手刻」了一個 Markdown parser …在 Markdown 格式判斷 部分，其實可以用開源套件處理。
在工程師改過之後（感恩工程師大大 yukai），就有很多部分可以順利渲染了，但部分文件元素會遇上一些技術限制而無法被正常渲染，像是上傳到 HackMD 的圖片會因為跨域的關係而無法被渲染、使用 Mermaid 語法所畫的流程圖，也會因為是 SVG 組成，而無法被渲染等，總而言之如果要實現「完全的」將 HackMD 文件在 Figma 內渲染，那工程會相當浩大，也不值得這麼做，因為最快的方式還是：將 HackMD 文件截圖然後貼進 Figma 。
繞了一大圈，我也才知道自己「許的願」有多大。
附上這個實作的專案程式碼： HackMD-viewer
使用 GitHub copilot
專案日期: 2025/02~03
呼應到前面提到的：
“小心你許下的願望” (Be careful what you wish for)
我以為 AI 可以解決很多問題、可以幫我創造我腦中想的工具，但很快地發現當我自己都沒有釐清我的目的是什麼的時候，AI 只是產生更多無用的程式碼，看似完美但不實用的回應。
並不是所有流程都需要 AI，也不是所有流程都能透過 AI 簡化，像是如果要讓 AI 修改 UI 樣式達到設計師理想的樣子，可能會花費大量的時間，還不如設計師在 Figma 產出或者直接改 Code。
AI 也有不擅長的部分，例如複製貼上、統計圖表、計算，有明確的對錯、數值，它可能會回覆看似正確的假資料。
而要如何解決這個不擅長的部分，應該要請 AI 寫一個這種統計的公式或自動化工具，讓這些「工具」或「公式」來幫忙得出你想要的結果。
Take away
踩過幾次坑後，我調整了跟 AI 合作的流程，但也讓自己多使用 AI，畢竟多用 AI 才會知道還有哪些限制、該如何優化或怎麼互動才能得出我想要的結果。
如果我要讓 AI 實作工具或功能，我一律先跟 AI 討論，像是以下的 Prompt：
我想做一個 {{做什麼事情}} 工具。
請先閱讀這個需求後，跟我討論不確定的地方，不要先寫程式。
以下是功能需求：
- 我可以...
- 我可以...
依據上面的需求，我需要再提供哪些資料？以及其他可能會有哪些限制與風險？在我看過它的實作規劃，有哪些功能需要確認，這個過程幫助我省下很多時間，包含根本不用做這個工具或是限縮範圍等。
這讓我想到這個環節就跟工程師溝通需求一樣，有 80% 討論確認需求，就能減少後期調整程式修 bug 的時間。
而我也在這個過程當中，也學習到更多如何釐清我的需求、如何規劃，最後看到 AI 真的能幫我完成工具，優化流程，也讓我感到滿滿的成就感。
下次再來分享實作 Prototype 的經驗，或其他 AI 使用心得！
