前六天都在處理同一件事：這個產品到底要做什麼，又有哪些東西現在先不要碰。
今天開始把這些決定收成一份後面真的會拿來開發，而且做完還能驗收的文件。
也就是 PRD。
我不打算寫那種三十頁、開會時每個人都說有看，實際上沒人真的看完的文件。
這個專案目前就我一個人，所以 PRD 對我來說只有兩個用途：

• 讓後面的 Gemini CLI 知道現在到底在做什麼
• 防止我做到一半又突然覺得「這個好像也可以順便做」

前六天已經砍掉夠多東西了，今天不要再讓它們長回來。

先把前六天收成一包

我沒有一開始就叫 Gemini 直接寫 PRD。
先自己把 Day 01～06 的結論整理成一份短短的 Context，大概分成幾塊：

• Problem：現在找工作咖啡廳到底麻煩在哪裡
• Target User：主要有哪些工作情境
• MVP：這 30 天確定要做什麼
• Non-goals：哪些東西已經決定先不做
• Data Fields：插座、Wi-Fi、限時等資料要怎麼表示
• Open Questions：目前還沒有答案的坑

這份東西不用漂亮，重點是不要漏掉前幾天已經做過的決定。

📸 圖片 1｜丟給 Gemini 前整理好的 Context

整理完之後，我才把它丟給 Gemini。

PRD 不用很厚，至少要讓明天的我看得懂

我希望這份 PRD 至少回答幾件事：

• 產品到底在解什麼問題
• 第一版先服務誰
• MVP 有哪些功能
• 明確不做什麼
• 使用者最基本的流程怎麼走
• 需要哪些資料
• 每個功能做到什麼程度才算完成

其中我最在意的其實不是「要做什麼」。
而是：

不做什麼。

AI Coding 最大的誘惑就是「反正叫它多做一個好像很快」。
會員中心好像很快，推薦頁好像也很快，順便加個通知好像也還好。
結果過幾天打開 repo，已經不知道這些東西當初為什麼會存在。
所以 Non-goals 我反而想寫得比 Features 更明確。

把前六天塞進一份不准加戲的 PRD

我給 Gemini 的 Prompt 是：

根據我提供的 Day 01～06 產品結論，
幫我整理一份「給一人開發 Side Project 用」的精簡 PRD。

不要寫企業簡報語氣。
不要補不存在的市場數據。
不要新增我沒有提供的功能。

文件只需要：
- Problem
- Target User
- Core User Journey
- MVP Features
- Non-goals
- Data Needed
- Acceptance Criteria
- Open Questions

每個 Acceptance Criteria 請寫成可以實際測試的句子。
如果資料不足，放進 Open Questions，不要自己補答案。

我特別加了兩句：

不要新增我沒有提供的功能。

以及：

資料不足就放 Open Questions。

因為 PRD 最怕的不是少寫一段，而是突然多出一堆根本沒人決定過的需求。

📸 圖片 2｜產 PRD 的 Prompt＋Gemini 第一版輸出

第一版出來後，我沒有直接存檔收工。
我先看三個最容易出事的地方。

第一個：MVP Features 有沒有偷偷長東西

Day 06 才剛砍完功能，如果 PRD 裡突然又冒出「即時回報」、「排行榜」或「完整會員系統」，我就直接刪。
PRD 不是重新 Brainstorm 的地方。
它的工作只是把已經做過的決定寫清楚。
而這次 Gemini 還真的把「現場微回報」又塞回來了。
理由看起來很合理：咖啡廳狀況會變，讓使用者回報就能保持資料新鮮。
問題是 Day 06 才剛處理過這個坑。
一顆「現在有位子」的按鈕，背後馬上會長出：誰能回報、要不要登入、多久失效、多人回報衝突怎麼辦、亂填怎麼處理。
所以第一刀很簡單：

現場微回報從 MVP 拿掉。

更有趣的是，被砍掉的功能跑回來了，原本確定要做的「地圖」跟「地點搜尋」反而沒有被明確寫進 MVP Features。
如果我後面真的叫 Gemini CLI「照 PRD 實作」，它做出一個只有列表跟 Filter、沒有地圖的網站，也不能算它做錯。
所以這兩項我反而要補回去。
這時候我才很有感：

PRD 寫進去的東西，AI 真的可能幫你做；沒寫進去的，它也真的可能當作不存在。

第二個：Non-goals 有沒有真的寫出來

我希望看到的不是一句：

未來可能擴充更多社群功能。

這種等於沒寫。
我要的是很明確的：

• 第一版不做排行榜
• 不做積分商城
• 不做即時空位／插座回報
• 不做複雜社群留言板
• 不做自動爬 Google 評論
• 不做個人化推薦

之後如果我又手癢，就先回來看這段。
不過這裡也要分清楚「核心 MVP 不做」跟「30 天後段會做」。
像 Google 登入、收藏、自然語言搜尋、情境推薦，還在整個 30 天 Backlog 裡，只是不是找店流程的前置條件。
不然 PRD 寫著「收藏不做」，Day 22 又開始做收藏，文章自己先打架。

第三個：Acceptance Criteria 能不能真的驗收

這個我覺得最重要。
例如寫：

使用者可以方便地找到適合工作的咖啡廳。

完全沒辦法驗收。
什麼叫方便？怎樣叫找到？
Gemini 這版還自己補了一條「手機瀏覽器 3 秒內載入完成」。
3 秒聽起來很合理，但我現在根本還沒定義要用什麼網路、什麼裝置、量哪個效能指標。
這種數字看起來很精準，其實只是多了一個沒有根據的 KPI。
所以我寧可先改成真的能操作測試的句子，例如：

當使用者選擇「有插座」後，
列表中不應出現 powerOutlet = none 的店家。

或是：

使用者點選店家卡片後，
可以看到 Wi-Fi、插座與限時／久坐資訊。

再例如：

使用者不需登入，
即可看到咖啡廳列表與主要工作條件。

這種之後真的可以一條一條勾掉。

📸 圖片 3｜Acceptance Criteria 修改前後

Data Fields 也不能因為寫進 PRD 就變簡單

Gemini 對 Wi-Fi 的描述是：

• 穩定快速
• 普通
• 差

看起來很好懂，但 Day 05 才剛踩過這個坑。
「穩定快速」到底是誰判斷的？昨天很快，不代表今天下午五點也一樣快。
所以我還是沿用前面定下來的方向：資料先保持簡單，但要保留來源跟更新時間。
例如 Wi-Fi 至少要知道：

• 有沒有 Wi-Fi
• 是否有人回報使用起來穩定
• source
• updatedAt

限時也一樣。
Gemini 寫成「不限時／限時 X 小時／嚴格限時」很整齊，但現實可能是：

平日不限時，假日客滿時限兩小時。

所以最後還是要回到 Day 05 的做法，用狀態加備註，不要硬把真實世界壓成 Yes / No。

最後存成 PRD.md，不是存完就忘了

人工修完之後，我會把最後版本存成：

PRD.md

然後直接放進專案 repo。
它不是今天寫完就封存的報告，而是後面 Gemini CLI 每次開始做功能前都要先讀的東西。
我甚至希望後面的 Coding Prompt 可以很偷懶地寫：

先讀 PRD.md。
今天只實作 Cafe Card。
不要新增 PRD 以外的功能。

或者更保險一點：

先閱讀 docs/PRD.md。

告訴我你理解的：
1. 核心使用者任務
2. Must-have 功能
3. Non-goals
4. 這次修改不能超出的範圍

先不要修改程式碼。

如果它連 PRD 都理解歪，至少這時候還沒開始動 code。

📸 圖片 4｜最後的 PRD.md

Day 07 最後，我要的不是一份很正式的文件

今天真正留下來的，不是一份看起來很完整的 PRD。
而是一份後面真的可以拿來擋我的文件。
什麼要做、什麼先不要做、哪些資料要存、做到什麼程度才算完成，先寫清楚。
因為等真的開始 Coding 之後，最容易發生的不是「不知道要做什麼」。
而是每天都突然想再多做一點。
PRD 至少可以在我又想加戲的時候，提醒一下六天前的自己到底砍了什麼。
不過文件有了，下一個問題也來了。
文字裡寫「搜尋 → 篩選 → 看店家 → 導航」很順，不代表真的操作時也會順。
Day 08 就把這條路畫出來。
看看一個人在路上想找咖啡廳時，到底要按幾次才找得到店。

開始規劃 User Flow。