在昨天的 [Day 01 啟航篇] 中，我們確立了這 30 天的北極星目標：透過 Vibe Coding（氛圍編程） 的工作流，運用 Google AI 生態系從零打造一款多模態內容知識提煉平台 —— OmniVibe AI。

很多人對 Vibe Coding 有一個常見的誤解：「既然是靠自然語言寫程式，那是不是隨便丟一句『幫我做一個像 Notion 的 AI SaaS』，然後邊看程式碼邊碰運氣？」

答案是絕對不行。

在軟體工程中，垃圾進就只會垃圾出（Garbage in, Garbage out）。如果你的產品定義模糊不清，AI 生成出來的代碼就會像無頭蒼蠅一樣——今天幫你建了 SQL Schema，明天又改成 MongoDB；介面東拼西湊，邏輯前後矛盾。

在 Vibe Coding 的工作流中，一份精準的 PRD（產品需求文件，Product Requirement Document） 並不是給傳統工程團隊開會審查用的冗長官樣文章，而是給 AI Coding Assistant 的「全域系統提示詞（Global Context / System Prompt）」。

今天，我們就來示範如何透過自然語言與 AI 進行深度協商，在 30 分鐘內產出一份高含金量、邏輯自洽且能直接指引後續開發的 OmniVibe AI 核心規格書！

🛠️ 第一步：設計與 AI 協作梳理 PRD 的「引導式 Prompt」

要讓 AI 產出具備商業與工程落地性的 PRD，不能單純說「幫我寫 PRD」，我們必須為 AI 定義清晰的思考框架。

以下是我在構思 OmniVibe AI 時，丟給 AI 的結構化 Prompt：

你是一位資深的全端 AI 架構師兼產品總監（CPO）。我們即將展開一個 30 天的敏捷衝刺，使用 Google AI 生態系（Gemini 1.5 Pro/Flash、Google AI Studio、Google Stitch、Firebase 全家桶）打造一款具商業變現價值的 MVP SaaS 產品：「OmniVibe AI」。

【產品概念摘要】
OmniVibe AI 是一個專為「內容創作者、知識工作者、自媒體經營者」設計的「多模態知識提煉與全通路內容自動化產製平台」。用戶只要餵入長影片（YouTube/MP4）、長音訊（Podcast/錄音）或長 PDF 報告，系統透過 Gemini 的超長上下文與多模態能力，一鍵提煉精華並產出社群貼文矩陣、短影音腳本與結構化筆記。

請根據上述概念，以嚴謹的軟體工程規格，為我梳理出一份 MVP PRD，包含：
1. 目標用戶角色（Personas）與核心痛點
2. MVP 核心功能範圍（Must Have vs Nice to Have，務必收斂在 30 天內可落地）
3. 端到端用戶旅程與操作流程（User Journey & Flow）
4. 系統非功能性需求（安全性、效能、串流延遲、成本控制）

📋 第二步：OmniVibe AI 產品需求規格書（MVP 精華版）

經過與 AI 的多輪對話收斂（反覆挑戰它：「這個功能在 MVP 階段是不是太重了？」、「Gemini 處理 1 小時影片時前端體驗該如何設計？」），最終定稿的 PRD 核心框架如下：

1. 目標用戶角色（Target User Personas）

• 自媒體與知識型創作者（Alex，30 歲）：

• 日常痛點：每週錄製 1 集 45 分鐘的 Podcast 或訪談影片，要手工整理成 Threads、LinkedIn、IG 圖文貼文與短影音腳本，平均每集需耗費 4~6 小時。

• 核心期望：丟入影音檔案後，能快速產生符合不同平台語氣（Tone of Voice）的貼文矩陣與分段時間戳記。

• 產業分析師與研究員（Sarah，28 歲）：

• 日常痛點：每天需閱讀數十頁的英文研究報告或財報 PDF，傳統 AI 摘要工具常受限於上下文長度而丟失細節，或無法精確引用出處。

• 核心期望：支援長達百萬 Token 的整份文件輸入，產出結構清晰、具備時間軸或頁碼對照的重點決策摘要。

2. MVP 核心功能範圍（Feature Scope）

在 30 天鐵人賽的節奏下，「不做什麼」比「做什麼」更重要。我們嚴格劃分 MVP 必備功能與未來版本延伸：

1. 社群貼文矩陣（LinkedIn / X / FB）

2. 短影音口播分鏡腳本（Hook + Body + CTA）

3. Markdown 結構化筆記 | 自定義社群平台排程自動發文、語音自動合成 TTS |
| 互動體驗 | Gemini Server-Sent Events (SSE) 即時打字機串流生成 | 針對單一產出區塊進行 Inline AI 追問重寫 |
| 資料儲存 | Cloud Firestore（儲存歷史專案與生成紀錄） | 團隊多人協作工作區（Team Workspace） |
| 商業化機制 | Stripe 訂閱制整合（免費試用 3 次，升級 Pro 享有無限產出） | 企業 Token 按量隨選加購金流 |

3. 用戶核心操作流程（End-to-End User Flow）

我們將用戶在 OmniVibe AI 中的核心體驗濃縮為 5 步極簡閉環：

graph TD
    A[訪客進入 Landing Page] --> B[點擊 Google 一鍵登入]
    B --> C[進入 Dashboard：拖曳上傳多媒體檔案 或 PDF]
    C --> D[選擇輸出目標風格：如 Threads爆款文 / 專業報告摘要 / 短影音腳本]
    D --> E[點擊「開始提煉」：前端建立 SSE 串流連線]
    E --> F[Gemini 1.5 即時多模態解析與打字機回傳]
    F --> G[成果展示區：支援一鍵複製 / Markdown 匯出 / 存入專案庫]

1. 極速進入（Onboarding）：用戶使用 Google 帳號無縫登入，無需填寫繁瑣表格，初次登入自動贈送免費額度。
2. 多模態資產投遞（Ingestion）：拖曳影音或 PDF 到儀表板，檔案透過 Firebase Storage 進行安全上傳與分塊校驗。
3. 策略性 Prompt 套用（Transformation）：用戶選擇預設的高轉換範本（Template），系統在後端組裝好精密的 System Instruction 與結構化 JSON Schema。
4. 低延遲串流感知（Streaming）：利用 SSE 技術讓 AI 的生成過程具備「打字機動態效果」，大幅降低使用者等待大模型處理時的焦慮感。
5. 成果沉澱與資產化（Actionable Output）：支援線上即時預覽、單元複製、Markdown 下載，並即時持久化至 Firestore 專案庫中。

🛡️ 第三步：非功能性需求與技術邊界收斂

在與 AI 討論規格時，許多初學者會忽略「技術邊界」。在進入寫代碼之前，我們必須預先設定好以下防禦工事：

1. Token 上下文與成本平衡：

• 長影片分析直接呼叫 Gemini 1.5 Pro 成本較高，我們可以在初次粗篩時調用速度極快、價格親民的 Gemini 1.5 Flash；當用戶需要深度分析時，再由用戶切換為 Pro 模式。
• 評估引入 Context Caching 機制，避免使用者對同一份長文件重複提問時被重複計費。

2. 網路傳輸與長檔案處理：

• 超過 20MB 的多媒體影音如果直接走 Next.js API Route 會遭遇伺服器 Payload 限制與 Vercel/Cloud Run 的連線逾時。
• 決策：前端直接對接 Firebase Storage 取得 Signed URL 或直接上傳，後端僅接收 File URI 並轉交給 Gemini File API 處理。

3. 穩定性與結構化回傳：

• 拒絕「薛丁格的 AI 回應」！所有社群貼文、短影音分鏡腳本均採用 Gemini SDK 的 Structured Outputs (responseSchema) 強制約束回傳 JSON 格式，保證前端元件渲染 100% 不崩潰。

🎯 總結與明日預告

今天我們透過 Vibe Coding 的思維模式，成功把一個原本懸浮在空中的「想做一個全端 AI 產品」靈感，落實為具備清晰受眾、嚴格功能邊界、完整用戶旅程的 OmniVibe AI PRD 規格書。

有了這份明確的產品規格，明天開始當我們向 AI 下達寫代碼、建架構的指令時，AI 就能精準命中目標，不再產生幻覺或寫出用不到的冗餘邏輯！

👉 明天（Day 03），我們將進入【技術架構篇】：Google AI 生態系全景拆解！為什麼在這個全端 AI 時代，Gemini API 搭配 Firebase 全家桶會是獨立開發者與敏捷團隊的最強王炸組合？

敬請期待，我們明天見！🚀