昨天把 Persona 拆完後，有一件事變得很明顯。
同樣都是拿筆電去咖啡廳，深度工作、開會、臨時處理事情，在意的條件其實差很多。
所以今天要開始碰一個後面一定躲不掉的問題：

這些「適不適合工作」的資訊，到底要怎麼變成真的可以存、可以篩選的資料？

第一個最明顯的例子就是 Wi-Fi。
「有 Wi-Fi」大概是咖啡廳最沒用的資訊之一。
因為有 Wi-Fi，跟 Wi-Fi 能不能拿來工作，根本是兩回事。
今天先來處理這個坑：

到底什麼才叫「適合工作」？

先不要問 Gemini，我自己列一次

這次我沒有一開始就叫 Gemini 幫我設計欄位。
不然很容易得到一張超完整的表，從插座一路列到空氣品質，最後每間店要填三十幾個欄位。
所以我先自己把會在意的東西全部倒出來。

• Wi-Fi：有沒有、穩不穩
• 插座：有沒有、數量多不多
• 噪音：安靜／普通／吵
• 座位：桌面夠不夠放筆電
• 久坐：適不適合待兩三個小時
• 會議：能不能正常講電話或開線上會議
• 營業時間
• 低消
• 限時
• 廁所
• 交通與距離

一開始先不管資料拿不拿得到。
想到什麼就先寫什麼。

📸 圖片 1｜我自己列的超長欄位清單

列完之後第一個感覺就是：

這也太多了。

如果每間店都要人工填二十幾個欄位，這個網站可能還沒上線，我自己就先不想維護。
而且很多看起來很簡單的欄位，真的想下去都會開始出問題。

例如：

• 「Wi-Fi 穩定」到底誰測？
• 「安靜」是什麼時間的安靜？
• 「適合久坐」是店家規則，還是客人的感覺？
• 「插座很多」到底幾個才叫很多？

做到這裡，我開始覺得今天真正麻煩的不是「還缺什麼欄位」。
而是：

哪些欄位值得我養。

欄位列完了，下一步不是加，是刪

這時候我才把剛剛那份清單丟給 Gemini。
不是叫它補更多，而是叫它從兩件事幫我排：

1. 使用者找店時到底在不在意
2. 這份資料到底好不好取得、好不好維護

我用的 Prompt 是：

我要建立「咖啡廳工作友善度」資料欄位。

候選條件有：
Wi-Fi、插座、噪音、座位舒適度、久坐、線上會議、
營業時間、低消、限時、廁所、交通。

請不要全部保留。

請用兩個角度排序：
1. 對使用者選店的重要程度
2. 這個資料是否容易取得與維護

最後分成：
- MVP 一定要有
- 有資料再放
- 第一版先不要

我特別加了「請不要全部保留」。
因為 AI 很容易把「這個也有價值」一路加到最後，結果每個欄位都有價值，每個欄位也都得做。

📸 圖片 2｜Gemini 排完後的欄位取捨

最後 Gemini 大概把欄位拆成三組。

先留

• 插座
• Wi-Fi
• 限時／久坐

有資料再補

• 低消
• 線上會議
• 噪音

第一版先不要自己養

• 營業時間
• 交通
• 座位舒適度
• 廁所

第一眼看起來滿合理。
尤其插座、Wi-Fi、限時／久坐被排在前面，跟 Day 02 找到的真人討論也接得上。
但我往下看，很快就發現一個問題。
Gemini 還是把真實世界想得有點太整齊。
例如它認為插座跟限時相對好維護，因為大概就是「有／沒有」、「限幾小時」。
但前面明明已經看過：

• 有插座，但只有部分座位有
• 平日不限時，假日限時
• 客滿才限時
• 可以久坐，但需要再點一杯

所以這兩個欄位根本沒那麼 Boolean。
這也是我沒有直接照這張表開始建資料庫的原因。
排序可以拿來參考，但資料最後怎麼表示，還是得回到真的店家規則。

有些資料很想要，但現在養不起

Gemini 排完之後，我還是得自己再砍一次。
因為「這個資訊很有用」跟「我有辦法長期維護」完全是兩回事。
最明顯的就是 Wi-Fi。

如果每間店都能顯示：

下載 187 Mbps
上傳 82 Mbps
Ping 12ms

看起來超讚。
問題是我下一秒就要開始處理：

• 誰測的？
• 幾點測的？
• 用哪台設備？
• 店裡當時有多少人？
• 換 Router 後怎麼辦？
• 半年前的結果還算不算？

一個「網速」欄位突然就長成另外一個 Side Project。
那就先不要。
第一版我比較願意接受比較粗的資訊：

• 有沒有 Wi-Fi
• 有沒有人回報使用起來穩定
• 最後什麼時候更新

至少資料沒有那麼漂亮，但我知道自己在講什麼。
不要做出一個看起來很科學，其實半年沒更新的 187 Mbps。

📸 圖片 3｜我人工刪掉／降級的欄位

這張我反而覺得比「最後留下哪些欄位」更重要。
因為做到這裡，我開始知道哪些東西不是沒用，只是現在不值得做。
像：

• 即時網速
• 精細噪音分貝
• 即時客滿程度
• 桌椅人體工學
• VPN／Port 網路檢測

都很有趣。
但第一版先不要把自己搞死。

真正麻煩的是，很多資料根本不是 Yes / No

Day 02 就已經踩過這個坑。
最簡單的例子是「不限時」。
如果資料庫寫：

unlimitedTime = true

看起來很乾淨。
但現實可能是：

• 平日不限時
• 假日限時兩小時
• 客滿才限時
• 久坐要再點一杯

那這個 true 到底是什麼意思？

插座也是。

powerOutlet = true

到底是每桌都有？
還是全店只有牆角兩個？

噪音更麻煩。

noise = quiet

週一下午可能真的很安靜。
週六下午可能完全不是同一家店。
所以我現在比較傾向一個做法：

欄位先保持簡單，但不要假裝它是永遠正確的。

例如噪音先存：

noiseLevel:
- quiet
- normal
- loud
- unknown

再搭配：

updatedAt
source
note

這樣至少之後看到一筆 quiet，我知道它從哪裡來、多久以前更新，而不是把它當成店家的永久屬性。

開始把中文需求變成真的欄位

做到這裡，才真的開始有一點「要開發了」的感覺。
因為前面寫的「插座」、「噪音」、「不限時」都只是需求名稱。
接下來得決定它們真正長什麼樣。

例如噪音：

noiseLevel: quiet | normal | loud | unknown

插座先不要只用：

powerOutlet: true

我比較想留成：

powerOutlet:
- none
- limited
- many
- unknown

限時也一樣：

timeLimitType:
- none
- always
- conditional
- unknown

如果規則比較複雜，再用 note 補：

平日不限時，假日客滿時限 2 小時

現在看起來只是幾個很小的 enum。
但後面做 Filter、Firestore Schema，甚至讓 Gemini 把「我想找可以坐一下午的店」轉成搜尋條件時，都會直接用到這些東西。

📸 圖片 4｜最後留下的 Cafe 工作欄位表

目前第一版，我會先把重心放在：

• Wi-Fi
• 插座
• 限時／久坐
• 噪音
• 是否適合開會
• 資料來源
• 最後更新時間

營業時間、地址、交通這些店家基本資訊，後面再看 Google Places 能不能接手。
至於廁所、桌椅舒適度、即時網速、即時客滿，先放著。
不是永遠不做。
只是現在做下去，很容易從「我要做咖啡廳地圖」變成「我要經營一間資料公司」。
Day 05 做到這裡，我真正留下來的不是一張超完整 Schema。
而是開始知道：

哪些資料值得存，哪些資料雖然很想要，但現在先不要碰。

欄位都已經砍成這樣了，功能清單當然也不可能全部留下來。
Day 06 就來處理下一個更痛苦的問題：

30 天的 MVP，到底還能剩多少？