產品經理也能Vibe Coding！Portaly創辦人分享全AI產品開發實戰法則

過去一季，我們開發團隊嘗試「全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開發流程：（簡易版）

1. PO／PM（產品企劃）撰寫User Story／Storyboard，描述需求、進行用戶訪談。
2. PM大量蒐集外部相關產品案例，繪製出Wireframe、User Flow。
3. Tech lead技術主管參與可行性討論，再修正產品。
4. UIUX designer使用Figma繪製設計稿。
5. Front-end（前端工程師）把介面刻出來。
6. PM測試，確認介面與操作無誤。
7. Back-end（後端工程師）建立資料庫schema、開發API、整合前後端。
8. PM測試，確認資料、API串接無誤。
9. 工程師部屬到雲端。

其中步驟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:
1. Help creators better present themselves ...
2. Help creators build trust …
3. 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溝通的對話（agent溝通？）。

我的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測試、工程師部屬到雲端。

這套流程花多久時間？

上述這一套Prototype建立的過程，前後花了4週時間。

期程大概分成：

－第1週：產品研究、企劃、提案。
－第2週：用AI將產品刻到Firebase，並且不斷修正。
－第3週：交付給工程師串接資料、更新code。
－第4週：測試、修正、上線。

總體來說，這是一段非常迷惘的摸索過。

最主要的原因是，這是我們非常不熟悉的流程，過去工程與非工程團隊明確的任務分隔，透過AI讓這個接力的界線變得模糊。

其次是，非工程師非常多知識要學習！除了要理解工程管理的細節有哪些，包含資料儲存、code撰寫方式（管理效率），也要建立對於AI工具能做到什麼、不能做的什麼的敏感度。

對工程師來說，要思考的是如何與AI撰寫的code共存，以達成時間效率最大化。可能會對成果非常不滿意、或對於沒辦法code review提心吊膽。

本來以為「全AI產品開發」，最難的路已經走過，殊不知，後面兩個月開始迭代，才真的面臨更大的挑戰。