在這次的範例當中，我選擇了一個最近我煩惱的主題，也就是：我覺得我對外部的資訊吸收的太少了。我太多時候寫文章都是「寫我自己想寫的」，有時候會中，但整個文章的觸及就會忽高忽低。而且我寫的領域太狹隘了，「靈感」需要廣泛、寫作內容再跟我有關就好。所以我們的起手式還是我在前文說的那句 prompt：
我想和你協作一份 PRD。請你像專業產品經理一樣，引導我一步步建立這份文件，從黃金圈理論的『Why』開始，透過一問一答的方式幫我釐清邏輯， 直到最後我們能整理出清楚的架構。於是 Gemini 就開始引導啦，詳細完整的對話全記錄可以在這裡來觀看。
不過這次的 PRD 搭建有兩個關鍵點是我覺得值得跟大家分享的
讓 AI 幫你想你想不到的事情
其實這是 vibe coding 最大的價值，或許你有聽說過：人賺不到認知以外的財富。相對專業的工程師，我們對於「技術」的認知其實並不那麼的全面。就像我原本很樂觀的以為：啊要找熱門主題，就請 LLM 幫我抓就好了啊。
但是 Gemini 這時候就很「委婉」的跟我說：其實這是不準的（他是沒有講啦，你們可以去看看他的講法是什麼）。並且幫我列出了可以替代的方案，甚至在我的要求下幫我找到了免費的解決方式。也讓我多認識了 Apify 這個工具
開 PRD 的時候要明確技術棧
未來我會跟各位分享我把做好的產品放上網路給人使用的過程，目前我主要的兩個存放位置，一個是直接放在 Replit 上，另一種是會放在 Cloudflare 的 Worker/Pages 上。不同的存放位置其所支援的程式語言就不完全相同，一開始要先講清楚，避免開了一個 Cloudflare 不支援的語言，前面花的時間就白費了。
延伸閱讀：你學好了這件事情有什麼新的工作機會嗎？
最終跟 Gemini 聊了約半個小時，得到了一份這樣的 PRD，當你看完也懂了之後。下一步我們就要拿著這份 PRD 去找 Replit 搭建我們的服務了吧！
# PRD：社群熱點雷達 (Social Hotspot Radar) v1.0
**文件版本：** v1.0
**最後更新：** 2025-11-02
**產品負責人 (PM)：** Yu-Ting Chiu (黑大)
---
## 1. WHY (我們的存在理由：目標)
### 1.1 Introduction (市場現況/問題)
* **目前使用者遇到的問題 (Problem Statement)：**
* 許多專業領域的內容創作者（KOL / 專家），其內容產出習慣偏向「**由內而外**」（寫自己想寫的）。
* 這導致其內容與「**由外而內**」（大眾想看的）的即時市場需求產生脫節，進而影響內容的「**破圈**」傳散效率。
* **當前解決方案的痛點 (Pains)：**
1. **資訊源受限：** 創作者依賴個人有限的資訊源（如：過去的課程、FB 動態回顧），導致錯過正在發酵的外部熱門話題。
2. **工具過重：** 市面上的專業社群監聽工具，對於「個人創作者」而言過於昂貴、功能過於笨重，不符合「輕量、快速」的需求。
* **我們看到的機會 (Opportunity)：**
1. **輕量級爬蟲技術成熟：** 以 Apify 為代表的「Scraper-as-a-Service」技術，其免費方案已足夠支撐 MVP 的核心抓取需求。
2. **一體化開發平台：** Replit 提供了「Web 伺服器 + DB + Cron」的一體化環境，能以極低成本快速實現後台與排程。
3. **MVP 策略：** 我們可以組合上述工具，打造一個「零成本啟動、極致輕量」的解決方案，完美切入「個人專家」這個尚未被滿足的市場缺口。
### 1.2 Objectives (我們的成功定義)
* **商業目標 (Business Goal)：**
* 輔助「小黑先生」的帳號在 2026 年底前達成 10 萬粉絲的目標。
* **產品目標 (Product Goal)：**
* **P1 (價值):** 成為「小黑先生」最高效的「**外部靈感來源**」，確保他不錯過任何具「破圈」潛力的行銷話題。
* **P2 (體驗):** 打造「**零摩擦 (Zero-Friction)**」的體驗。使用者**不需**主動登入儀表板，價值（Email）必須在每日 8:00 AM **主動**推送到他面前。
* **P3 (效率):** 確保使用者能在 **10 分鐘內**完成「閱讀摘要 -> 點擊原文 -> 決定主題」的決策流程。
---
## 2. WHO (我們的服務對象：人)
### 2.1 Target Group (目標客群)
* **MVP 核心受眾 (Persona 0)：**
* **角色：** 知識型 KOL / 領域專家 (以「小黑先生」為原型)。
* **領域：** 專注於特定專業領域（如：數位行銷、SEM、Meta 廣告、電商）。
* **行為：** 每日有穩定產出內容的需求，主力發布平台為 Facebook / Threads。
* **痛點：** 重度依賴「內部知識庫」，渴望「即時的外部市場訊號」。
### 2.2 Stakeholders (利害關係人)
* **1. 使用者 (User):** 「小黑先生」。他是產品的唯一使用者與最終決策者。
* **2. 開發者 (Developer):** (Replit 上的開發執行者)。本 PRD 必須為其提供清晰、可執行的技術規格 (見 4.3)。
---
## 3. HOW (我們的體驗設計：故事)
### 3.1 Persona (使用者畫像) / User Story 1: "小黑先生"
* **背景 (Who)：** 「小黑先生」，一位行銷領域的專家型 KOL，主力經營 Facebook 和 Threads。
* **情境 (Where/When)：** 每日早上 8:00 - 9:00 的「黃金發文一小時」，他需要在通勤或喝咖啡時，快速決定今天的發文主題。
* **核心痛點/需求 (Why)：**
1. **(痛點)** 靈感常來自「歷史動態回顧」，缺乏「當下」的市場熱點。
2. **(需求)** 需要一個「高破圈潛力」的靈感素材庫。
3. **(需求)** 他**不**需要 AI 自動寫作，他需要的是「高品質的原文素材」以便進行「二次轉譯」。
### 3.2 User Journey (用戶旅程)
我們有兩個關鍵旅程：
* **旅程 A：每日熱点獲取 (核心體驗)**
1. **[7:00 AM] (系統):** Replit Cron 觸發 Apify 爬蟲，抓取 FB/Threads 熱文。
2. **[7:15 AM] (系統):** 資料排序 (依分享數) 並存入 Replit DB (供快取)。
3. **[8:00 AM] (使用者):** 「小黑先生」在信箱中收到「每日熱點摘要」Email。
4. **[8:01 AM] (使用者):** 打開 Email，快速掃描 3-5 篇「分享數最高」的文章標題。
5. **[8:05 AM] (使用者):** 點擊 1-2 個最相關的連結，閱讀原文。
6. **[8:10 AM] (使用者):** 決定今日主題。
7. **[9:00 AM] (使用者):** (後續) 完成轉譯並發布貼文。
* **旅程 B：關鍵字管理 (低頻操作)**
1. **[某天下午] (使用者):** 發現近期「AI 廣告」很紅，想加入監控。
2. **[1:30 PM] (使用者):** 登入 Replit 上的「設定管理中心」。
3. **[1:31 PM] (使用者):** 在輸入框打上 "AI 廣告"，按下「新增」。
4. **[1:32 PM] (使用者):** 點擊 "AI 廣告" 旁邊的「立即測試」按鈕。
5. **[1:33 PM] (使用者):** 系統從 Replit DB (7:00 AM 的快取) 回傳了 2 篇相關貼文。
6. **[1.34 PM] (使用者):** 確認關鍵字有效，滿意地關閉頁面。
### 3.3 Aha! Moment / MOT (關鍵時刻)
* **"Aha! Moment" (Wow! 時刻):**
在「旅程 A」的第 4 步。當「小黑先生」打開 Email，**第一眼就看到一篇「分享數極高」且「他完全沒想到」的完美主題**，瞬間解決了他當天的「發文焦慮」。
---
## 4. WHAT (我們的具體實現：規格)
### 4.1 [Aspect 1: Epic 1 - 每日熱點摘要 (Email)]
* **F-1.1 (排程):** 必須在每日 8:00 AM (GMT+8) 準時或之前送達。
* **F-1.2 (Email 內容):**
* **標題:** `[社群熱點雷達]: 您 YYYY/MM/DD 的熱點摘要`
* **內文:** 極簡純文字或輕量 HTML。
* **欄位:** 必須包含 1. `原文標題` (可點擊) 2. `原文連結` 3. `分享數` 4. `留言數`。
* **F-1.3 (排序邏輯):** 列表必須嚴格依據「**分享數 (DESC)**」為第一排序，若平手則依「**留言數 (DESC)**」為第二排序。
* **F-1.4 (資料範圍):** 內容必須是「過去 24 小時內」發布，且符合使用者設定的「關鍵字」。
### 4.2 [Aspect 2: Epic 2 - 設定管理中心 (Web)]
* **F-2.1 (介面):** 必須是一個單一頁面 (Single Page Application)，佈局參照下方 **[附錄 A]** 的線框圖。
* **F-2.2 (關鍵字 CRUD):** 必須提供「新增輸入框」、「刪除按鈕」及「目前列表」，並即時連動 Replit DB。
* **F-2.3 (推播開關):** 必須提供一個「開啟/關閉」的 Toggle 按鈕，狀態存入 Replit DB，`F-1.2` 的排程必須讀取此狀態。
* **F-2.4 (立即測試):**
* **[重要]** 此功能**不得**觸發即時爬蟲。
* 必須**立即**查詢 `F-1.4` (旅程 A) 存入 Replit DB 的**快取資料**。
* 必須在 3 秒內將快取結果回傳至介面的 `[ 區塊 3 ]`。
### 4.3 [Aspect 3: 技術/營運規格]
* **F-3.1 (平台):** 專案必須在 **Replit** 上開發與託管。
* **F-3.2 (資料庫):** 必須使用 **Replit DB** 儲存所有使用者設定（關鍵字、推播狀態）與爬蟲快取結果。
* **F-3.3 (爬蟲):**
* 必須透過 API 呼叫 **Apify** (或同等級服務) 執行。
* **嚴禁**在 Replit 容器中直接運行 Playwright/Puppeteer (因 IP 易被封鎖)。
* **成本控制:** MVP 階段必須使用 Apify 的**免費方案 ($5 Credit/月)**。
* **F-3.4 (Email):** 必須使用 **SendGrid** (或同等級) API 服務，金鑰存於 Replit Secrets。
* **F-3.5 (認證):** `[設定管理中心]` 必須有簡易認證 (建議使用 Replit Auth 或環境變數中的靜態密碼)。
---
## 5. 待辦/風險 (Open Questions)
* **風險 1 (成本):** Apify 的 $5 免費額度可能在關鍵字過多或抓取頻繁時耗盡。
* **待辦:** 需在爬蟲腳本中加入用量監控與日誌，以便在額度接近時發出告警。
* **風險 2 (爬蟲失效):** Facebook / Threads 更改前端 HTML 結構，導致 Apify 爬蟲失效。
* **待辦:** 需建立一個「健康檢查」機制。例如：如果連續兩天抓到的
