「我該吃什麼」API 替代方案是一種在瀏覽器內運作的本機工具，會從一個小型編輯池中回傳單一經篩選的餐點構想，無需呼叫外部餐飲服務、不將偏好傳送至伺服器，也不需要 API 金鑰。What Should I Eat Generator（我該吃什麼產生器）正符合這個定義：它完全在頁面內執行，從固定的 24 個原創餐點構想中抽取，絕不聯繫外部端點。你選擇一個餐點時段、一種食物心情，以及一個選填的大致時間限制;瀏覽器會篩選該池，回報剩下多少符合條件的構想，並使用 Web Crypto 隨機挑選一項，且不會立即重複。沒有註冊流程、沒有權杖、沒有速率限制，也沒有遙測——只有你輸入的篩選設定，以及你剛剛抽到的那一項構想。這讓它在你想要「送出一個請求、拿回一個構想」的 API 風格體驗，卻不想承擔整合真正的餐點推薦 API 之營運成本時，成為一個實用的替代方案。
為何本機工具適合作為「我該吃什麼」API 替代方案
真正的餐點推薦 API 通常會要求帳號、配額，以及明確記錄的請求格式。即使是輕量級的版本，仍預期會有網路往返和一套主觀的綱要。對於一時的猶豫不決——「就告訴我該吃什麼」——這種額外負擔反而比問題本身還大。
像 What Should I Eat Generator 這樣的本機產生器，讓你享有「篩選請求、單一回應」的 API 風格模式，卻不必負擔基礎架構。每一個步驟都在你的瀏覽器內進行:
- 無需配置或輪換 API 金鑰。
- 無需為了配合廠商綱要而設計請求主體。
- 不會在伺服器端記錄你的餐點偏好。
- 無需監控每次呼叫的成本或每月配額。
這個工具也會保持庫存的可見性。產品規格清楚描述正好 24 個構想，以四個餐點值和三個心情值交錯組合，每個組合各兩個構想。這種透明度正是黑盒 API 的反面:你可以在信任抽籤之前，先審視這個池子。
如果你想深入了解為何這個工具從不將資料傳送到任何地方，本機與隱私說明會逐步說明整個資料流程。
What Should I Eat Generator 的運作方式
介面簡潔，步驟明確。請把它們視為你實際會點擊操作的合約:
- 選擇一個餐點、食物心情和大致時間限制，或將任何篩選條件留空以擴大構想池。
- 挑選一個食物構想，並檢視其標題、簡短指引、時間預估，以及符合條件的池數量。
- 在複製或使用該構想之前，請確認食材、過敏原、飲食需求、食品安全，以及合適的食譜。
每個步驟都很重要。將篩選條件留空會擴大構想池，當沒有構想打動你時特別有用。檢視符合條件的池數量，可以讓你知道篩選條件實際上有多嚴格——數量為 1 代表下一次抽籤是確定的，數量為 12 代表仍有真正的多樣性。第三步是多數人會略過的步驟，也是產品規格反覆強調的一點:菜名並不能證明食材、過敏原或烹飪安全性。這個產生器是一個起點，而不是裁決。
24 個構想編輯池一覽
這個池子是經過結構化設計的，而不是爬取而來的。四個餐點值——早餐、午餐、晚餐和點心——與三個心情值——清爽、舒適、紮實——交錯組合。每十二個組合中，各包含正好兩個原創構想。這樣總計有 4 × 3 × 2 = 24 個構想，而產品規格會描述每個餐點的編輯組合:
- 早餐從水果和優格，到馬鈴薯薯餅都有。
- 午餐包括沙拉、湯品、麵食、碗餐和三明治。
- 晚餐涵蓋塔可、義大利麵、米飯、炒菜和烤馬鈴薯。
- 點心構想包括水果、餅乾、爆米花、吐司小點、對折起司玉米餅，以及 pantry 點心mix。
心情作為實用的介面類別，而非營養宣稱。清爽偏向清爽農產品和明亮的搭配，舒適偏向溫暖熟悉的食物，紮實偏向更豐盛的份量形式。時間標籤(10、15、20、30 或 45 分鐘)是篩選器所用的大致規劃預估;它們假設常見食材和基本廚房設備皆已備妥，並排除採買、解凍、醃製、清潔整理和被打斷的時間。
| 心情 | 早餐感覺 | 午餐感覺 | 晚餐感覺 | 點心感覺 |
|---|---|---|---|---|
| Fresh(清爽) | 以水果或優格開始的輕食 | 沙拉和穀物碗 | 清淡的義大利麵或米飯餐盤 | 新鮮水果、吐司小點 |
| Cozy(舒適) | 溫暖的馬鈴薯薯餅 | 湯品和溫熱麵食 | 炒菜和舒適的義大利麵 | 餅乾和爆米花 |
| Hearty(紮實) | 較豐盛的早餐形式 | 三明治和豐盛的碗餐 | 塔可和烤馬鈴薯 | 對折起司玉米餅、pantry mix |
這張表格用於指引每個心情篩選傾向呈現的內容。由於餐點標籤描述的是某個構想可能適合的時機，而不是規則，因此早餐捲餅確實可能合理地出現在晚餐，點心 mix 也可以成為午餐的一部分。
隨機步驟實際在做什麼
「API 替代方案」只有在隨機步驟確實公平時才有意義。產生器從 crypto.getRandomValues 取得一個未帶正負號的 32 位元值，然後使用拒絕抽樣，使得每個符合條件的位置最終機率相等。
池大小為 5 時的逐步推算範例:
- 2^32 = 4,294,967,296。
- floor(4,294,967,296 / 5) = 858,993,459。
- 接受上限:858,993,459 × 5 = 4,294,967,295。
- 隨機字介於 0 到 4,294,967,295(包含)，因此只有單一值 4,294,967,295 會被拒絕——約佔抽籤的 0.000000023%。
- 被接受的字會透過取餘數對應到位置 0..4，每個位置恰好獲得 858,993,459 個值，因此每個位置的機率相等。
若被接受的值會對應回前一次抽到的構想，而又存在其他符合條件的項目，則該 ID 只會在下一次立即抽籤中排除。後續的抽籤仍可能再次抽到它。產品測試會驗證未帶正負號的隨機邊界、拒絕重試、在 128 次嘗試內的有界失敗，以及避免立即重複。
這個工具不會做的事
了解其限制也是善用這個工具的一部分。這個產生器不會:
- 為任何構想標示為素食、純素、無麩質、清真、猶太潔食、低鈉、糖尿病友善、孕婦安全或過敏原安全。像「炒菜」或「起司玉米餅」這類標題，並不能確立你會使用哪些食材、過敏原、處理器具或替代品。
- 提供食譜、食材清單或烹飪方式。輸出僅是一個方向和一個粗略的時間標籤。
- 計算營養、熱量或巨量營養素。
- 排名在地餐廳、查詢外送 app 的可用性，或比較價格。
- 檢視瀏覽紀錄、位置、儲藏室內容，或先前的餐點。
- 上傳任何東西。剪貼簿存取權僅在你按下「複製構想」時才會要求。
對於醫療規定的飲食、嚴重過敏、嬰兒餵食、孕期疑慮或吞嚥問題，請依賴合格的建議與經過驗證的食材資訊，而不是一個隨機產生的一般提示。
在實際決策中加以運用
最佳的使用情境是一般低風險的猶豫不決:你想要一個廣泛的構想、了解自己的限制，並且會自行做出真正的飲食決定。若想從 API 風格的工作流程中獲得最大效益:
- 從三個篩選條件全部開啟開始，以查看完整的 24 個構想池。
- 一次收緊一個篩選條件——先餐點，再心情，最後時間——直到符合條件的池數量落在仍感覺有多樣性的範圍內(大致為 4 到 12)。
- 將結果視為一個對話的起點。確認餐點時段和大致費力程度符合，然後從你平常就信任的來源選擇一份你信賴的食譜。
- 依據用餐者的情況，確認食材和過敏原，遵循安全的儲存與烹飪指引，並調整份量。
- 若建議不切實際，再抽一次或放寬其中一個篩選條件。
這個流程讓隨機步驟保持實用，同時把真正的飲食決定交還給你——那才是它應該在的位置。