編按：Vibe coding 的便利性正在改變產品開發方式。許多企業已開始導入這項 AI 技術，加速產品「從無到有」的過程——但目前多半僅限於單一部門使用：產品經理用來快速製作原型，工程師用來提升編碼效率。
但更大膽的問題是：非工程人員能否直接用 AI「完成整個產品」，最後只需工程師協助上線？
Portaly 執行長林啟維近期與團隊實測了這套做法，並成功推出了一項產品。以下是他的實戰心得：
過去一季，我們開發團隊嘗試「全 AI 產品開發」之路，意思是，PM 透過 Lovable／Firebase 等工具開發、並且直接讓工程師接手到 production。
2025 年，vibe coding 是全球軟體業主流，工程團隊已經大量使用 AI coding 工具 Cursor／Claude 輔助、加速產出；而非工程人員（PM／Designer），則使用 AI 工具 Lovable／V0 產出小型 prototype、甚至小型的 workable app。
問題來了：
- 工程團隊透過 AI 加速自身的產出，但 vibe coding 工具實際上有機會跨出工程圈嗎？
- 非工程團隊透過 AI「模擬」了工程師的產出（也就是 vibe coding 最早的定義），產出結果是否有真正 production（落地應用）的價值？
美國電腦協會 ACM 訪談中提到：
「Vibe coding 能夠協助原本軟體開發者遠大於非開發者；對於領域專業知識愈完整，AI 工具的賦能會愈高。」 （Baumann said vibe coding will empower software engineers more than it levels the playing field for non-technical coders）
假設 vibe coding 最終會造成軟體產業革命，我們期待 AI 應用價值能夠達成最大化：「除了工程師加速以外，非工程背景者（PM／Designer），也能夠透過 AI 大量參與、協助開發本身，而非止於前期的企劃或設計。」
過去一季我們團隊嘗試的「全 AI」流程，就是希望演練 AI 時代的開發模式： PM 打造產品原型→工程師完成落地。
本文內容比較長，將分享我們使用 AI 的開發流程，包含其中的 PM／Engineer 分工，以及使用的工具使用、Prompt 撰寫方式⋯⋯一切都在實驗中，可能半年後又會大翻新，有些用語可能不精準、方法可能不是最佳解，如果有其他想法歡迎分享討論。
先從工具開示選擇
想要帶領 PM 與工程師協作，首先要辨認合適的工具。
如果以「目的」而論，我們可以將 vibe coding 工具分成幾個類別：
-
Coding AI 工具：撰寫、管理程式為主，通常不會做 UI 或者做得很簡陋；例如 Cursor／Claude／Windsurf／GitHub Copilot。
-
Product AI 工具：一句話生成「可執行」的產品、App，包含美美的介面，但程式很難管理；例如 Lovable／V0／Firebase Studio。
-
混合型工具：同時兼具程式碼管理＋介面生成，甚至可與雲端伺服器無縫接軌；例如 Firebase Studio。
過往的開發流程中，AI 在哪些地方介入最有價值？
網路上有非常多非工程師用 AI 打造 Prototype 的案例，但真正的挑戰在於非工程師與工程師的「溝通」，也就是在哪邊接手、如何接手。
傳統的 MVP 開發流程：（簡易版）
- PO／PM（產品企劃）撰寫User Story／Storyboard，描述需求、進行用戶訪談。
- PM大量蒐集外部相關產品案例，繪製出 Wireframe、User Flow。
- Tech lead 技術主管參與可行性討論，再修正產品。
- UIUX designer 使用 Figma 繪製設計稿。
- Front-end（前端工程師）把介面刻出來。
- PM 測試，確認介面與操作無誤。
- Back-end（後端工程師）建立資料庫 schema、開發 API、整合前後端。
- PM 測試，確認資料、API 串接無誤。
- 工程師部屬到雲端。
其中步驟 4 和 6，有時候是很資深的前端、或者全端工程師就可以同一人自行完成。
傳統開發過程最困難的就是 0⇒1 的無中生有，尤其將全新的產品介面從設計稿刻出來變成前端畫面、並同步生成手機RWD的版本。
Portaly 團隊的 AI 開發流程是什麼樣子？
這是我們團隊使用 AI 打造 MVP 的流程：
1. PO／PM（產品企劃）使用 AI 協助討論 User Story、產品目的
這邊我使用的是 Claude 的 Extened Thinking 功能，他會用大量問答的方式幫我釐清產品的目的、聚焦，並且提供非常完整的論述。
好的產品開發者的產業直覺與專注性是關鍵，所以第一次的 prompt 非常重要。
自己的目標、方向要先想清楚，不能仰賴AI幫忙判斷產業趨勢，另外最好也有上網 survey 過相關的資訊，選擇覺得關聯性最高的提供 AI 閱讀，讓他想法跟自己同步。
以我們為例，我們想開發一個協助網紅與品牌端合作的工具。我的 prompt 如下：
We are an influencer saas called Portaly, we have over 200k users using our link in bio. The link in bio product is built for creators facing followers, now we want to build a 2nd product: a media kit for influencers. This will help them face brands as their audience. Our purpose:
- Help creators better present themselves ...
- Help creators build trust …
- Use portaly as a … You may read through this reference article first or feel free to search online: …”
小訣竅：一旦與 AI 討論的目標聚焦，同一個討論串也可以很快產出使用者訪談的題目、Story Board 等元素。
2. PM 用 AI 建立 Prototype 取代 Wireframe
簡單來說，過去繪製手稿、流程圖的提案方式，可以直接被 AI 產品工具取代。
這個階段我們使用的是 Lovable，主要原因在於它的設計模板、元件在目前產品界中是最領先，可以打造出的 UIUX 與視覺完成度非常高。
值得一提的是，由於這次的產品想法太過完整，我決定不要直接寫 prompt 跟 lovable 溝通，而是透過上面的 Claude 討論串，由 AI 幫我產出跟 AI 溝通的對話。
我的 prompt 如下：
“For the MVP, I will use lovable to build an interface. Provide me a set of prompt for the phase 1.”
小訣竅：Claude 的討論串中，我特別請 AI 把產品拆成不同的功能迭代階段。這樣可以讓 AI 盡可能提出有趣的發想，但同時保持第一版 MVP 的輕便性。
3. PM 與團隊確認原型方向，選定最佳版本
一旦可以產出一個版本的 prototype，就可以快速、大量產出多個版本，再決定最終的樣式。
Lovable 進行 prototyping 的成本變超低，快則一個下午之內，我決定拉其他團隊成員一起參與。
完成 prototype 的隔天，我花了半小時將這個流程演練給PM、實習生，但不提供他們 prompt。
讓他們回去用自己的想法執行一次，再針對產出結果互相比稿。
視覺與操作介面的比稿，遠比過去紙本的 Wireframe 或透過 PPT 的提案說明方式更有效率。
一般開發過程常見的方式是「參考其他產品」拼湊出來第一版設計；現在可以做到「參考自己的產品」組合出第一版。
小訣竅：Lovable 本身也有解析影像的能力，建議可以將網路找到的其他產品元素截圖貼上去，提升設計的精準性。
4. 將 Lovable 產出匯出／重建至 Firebase Studio
決定好產品的樣貌，終於要進入製作（什麼？前面還不是製作！）。
Lovable 提供非常好的視覺、介面設計工具。問題在於，過去我們將 Lovable 部署至我們的雲端（Google Firebase）花費非常高的工程成本。
大約半年前，Google 推出了自己的 AI 產品工具：Firebase Studio。
Firebase Studio 可以做到的是一鍵直接部署到 Google 雲端服務（GCP），不用額外的程式搬遷。也就是從 AI 工具到實際產品上線，幾乎不需要額外工程成本。
實際的作法是，我們透過 prompt＋截圖的方式，把最終版本的版面、功能、元件、配色搬移到新的 AI 系統中。
小訣竅：為何不直接用 Firebase 來做產品？坦白說，Firebase 直覺產出的介面真的頗單調……產品功能有了，但品質還是有些距離。
5. Firebase Studio 中的資料處理
這一步是透過讓 Product AI 產出的成果，可以交付給工程師接手的關鍵。
為了讓工程師好串接 API，我們特別要求 AI 使用 localStorage 作為臨時資料層。工程師接手後，只需將 localStorage 的讀寫邏輯替換成真實的 API 呼叫，前端介面幾乎不需修改。
這個做法有幾個優點：
- 資料會保存（可以測試完整流程）
- 無需任何雲端設定（立即可用）
- 工程師接手時容易替換。
一個簡單的 prompt 可以寫：
請使用 localStorage 儲存所有資料，不要連接任何後端 API。
小訣竅：值得注意的是，這套流程完全跳過 Figma 操作，沒有設計稿。
6. 工程師接手資料庫與 API 串接，並且優化 code
從這一步開始，工程師就可以想像成接手了一個 Junior 前端所寫的「介面」。
可以假定這個 Junior 只會依照稿件刻出畫面，但不知道怎麼接 API。
比較不一樣的是，過去我們開發流程在每一個環節都會有 code review，但因為前面全部都是 AI 寫出來的， 我們決定放棄人工 review 的過程。
這個步驟另一項任務是 code 優化。
過去使用 Lovable 或 Firebase 下 prompt 的時候，會隨著產品複雜性而愈來愈久。原因就是它們重新寫了太多內容。
AI 工具傾向將所有程式碼集中在單一檔案中，缺乏模組結構；工程師將程式碼拆解為多個獨立模組，讓每個功能職責明確。
模組化結構能讓 AI 在後續修改時更精準地修改特定功能，加速迭代效率。
實測的成果，可以將每次 5－10 分鐘的更新，簡短至 30 秒以內。
最後第 7 步，也就是後續的工作內容不變：PM 測試、工程師部屬到雲端。
「全 AI 產品開發」需要多久時間？
上述這一套 Prototype 建立的過程，前後花了 4 周時間。
期程大概分成：
－第 1 周：產品研究、企劃、提案。 －第 2 周：用 AI 將產品刻到 Firebase，並且不斷修正。 －第 3 周：交付給工程師串接資料、更新 code。 －第 4 周：測試、修正、上線。
總體來說，這是一段非常迷惘的摸索過程。
最主要的原因是，這是我們非常不熟悉的流程，過去工程與非工程團隊明確的任務分隔，透過 AI 讓這個接力的界線變得模糊。
其次是，非工程師有非常多知識要學習！除了要理解工程管理的細節有哪些，包含資料儲存、code 撰寫方式（管理效率），也要建立對於 AI 工具能做到什麼、不能做的什麼的敏感度。
對工程師來說，要思考的是如何與 AI 撰寫的 code 共存，以達成時間效率最大化。可能會對成果非常不滿意、或對於沒辦法 code review 提心吊膽。
本來以為「全 AI 產品開發」，最難的路已經走過，殊不知，後面兩個月開始迭代，才真的面臨更大的挑戰。
