01 · 核心心法一句話講完整個機制
「抓取」是每天累積的，「選題」是出刊前才做的，中間靠一個有記憶的池子隔開。
它不是「抓 → 評分 → 出刊」一次跑完的直線，而是一條有狀態、會累積、會回饋的流水線。每天默默把料倒進池子、去掉重複的；等到出刊前，才對池子做真正的選題判斷；選完的決定再回頭餵養 AI 編輯，讓下一次的初選更貼近總編的品味。
02 · 全流程總覽從原料到一期
↓
↓
↓
其餘合格 → 庫存 backlog（帶保鮮期）→ 下期重新競爭 / 餵 IG / 月報
03 · 兩條進料線兩種取材角度
The Pass 的原料來自兩個方向。既有的是「從食物找 AI」，朋友推薦補上的是「從 AI 前沿找食物」——兩者互補。
食物 → 找 AI
抓到「某餐廳導入了 AI」
特性已落地、有人味、在地
來源The Spoon、Eater、식품외식경제
AI 前沿 → 找食物
抓到「某新 AI 能力將改變餐飲」
特性早、技術、全球
來源Ben's Bites、Synced、HF Papers
Stream B 是「低產量、高價值的礦」，不是「穩定溪流」。撈到的前沿研究（如 Inverse Cooking）必須先翻成人話——「拍一張阿嬤的菜，AI 還原失傳食譜」——翻不出人味就砍。
另一種分法：內容源 vs 主題源（提案）
除了 A/B 進料線，來源還可分兩種「成熟度」：內容源（RSS，故事就在來源裡、可直接寫）vs 主題源／線索源（IG／YouTube／手動雷達，只給一個題目、選上後要再做一次研究／查證才有料寫）。完整流程與架構見 → 研究階段（從線索到故事）。
🆕 Phase 1 已實作（scout，實驗中）：查詢式進料（AI 搜尋 × 在地語言／跨區主題）已能撈 RSS 名單看不到的在地題、併進同一條篩選線——目前只負責「找題」，研究／綜述是 Phase 2。
04 · 抓取與去重pipeline 的「記憶」
抓取頻率：統一每日一次
RSS 成本極低，一週出 2 期，每日抓一次全部 active 來源已足夠有餘。不為不同來源排不同 cron——那是還沒需要就先增加的複雜度。等接了有 rate limit 的 API、或有即時性極強的來源時再差異化。
去重分兩層
① 完全相同（同一篇）
用文章 URL 當唯一鍵。抓到已看過的直接丟，只有新文章進池子。
② 同則新聞、不同來源
例如 Chef Robotics 融資被 The Spoon 和 TechCrunch 同時報——URL 不同但同一件事。靠標題語意相似度去重，避免選到兩篇幾乎一樣的。
初期可用一個 JSON 檔當 seen store，正式版接 Supabase。
05 · Opus 全程評估不靠關鍵字，整池交給強模型
去重後的每一篇都直接交給 Opus 做一次完整判斷——先過硬閘門、再打五面向，同一個模型、同一次呼叫。不先用關鍵字粗篩、也不用便宜模型墊一關。
為什麼不先用關鍵字省錢？因為關鍵字會漏也會誤判（曾有
tail→ai假陽性、也漏掉沒寫「AI」的食品科技如培養肉），而真正決定成本的是每日去重後的新篇數（通常 ≤25），不是 feed 大小。池子既然夠小，就值得用最強的模型整池全看——最一致、最不漏稿。
- 主題落在「飲食／餐飲／食物及相關」領域嗎？食物優先·廣義含上游（食材／農業）、中游（加工／物流）、下游（餐廳／外送／零售）、橫切面（法規／設備／行銷／永續），以及「人」的故事——主廚／經營者／從業者／生產者（「先找到人」的核心料）——不是只有「食物本身」。AI／科技非必要（加分不是門檻）；只擋「跟飲食完全無關」的（純無人機政策、跟飲食無連結的純 AI 研究、
tail→ai誤判） - 事實可查嗎？不是謠言 / 純炒作稿？
- 在這期時效窗內嗎？
- （Stream B 限定）翻得成人話嗎？翻不出人味的純技術規格 → 砍
過閘門的文章，Opus 在同一次回應裡打「五面向」分數（見下節）、指派 best-fit 編輯（Mise / Passe）、並寫一句 hook 主理由。一篇文章＝一次 Opus 呼叫，省去多一次往返。
成本上限怎麼控？靠去重把池子壓小，而不是靠關鍵字。若哪天單次抓取異常爆量，再加一個純數量上限當成本斷路器即可——絕不退回會誤判的關鍵字粗篩。
06 · 五面向評分把編輯品味寫成規則
過閘門後，每篇拆成五個面向各打 0–5 分，再加權加總。不是一個總分，而是一個剖面——讓總編一眼看出「它強在哪」。
「事實扎實」權重低，因為它比較像及格門檻（不及格在硬閘門就砍），而非加分項。權重可調——這份 rubric 就是把編輯品味寫成 AI 看得懂的規則，會隨 memory 演化。
順便決定格式：編輯路由
每篇標一個 best-fit 編輯：Mise（有具體的人 / 處境 → 長文）、Passe（事實夠硬夠新 → 快訊）、Fumet（能引出好問題 → 提問）。
07 · 評分範例用真實抓到的新聞跑一遍
| 新聞 | 五面向 | 判斷 |
|---|---|---|
| AI Is Breaking the Recipe Blog Model. AllSpice Thinks It Can Also Save It | 驚喜5 在地2 人味3 可談5 扎實4 | 高分 AI 同時是兇手和救星，張力勾得出好問題 → Fumet/Mise |
| HealthifyMe AI image recognition for Indian food | 驚喜3 在地5 人味3 可談3 扎實4 | 中高 印度在地是亮點 → Passe |
| Chef Robotics eyes commercial kitchens with $14.75M raise | 驚喜2 在地2 人味1 可談2 扎實4 | 偏低 融資產業稿，正是 tone 要避開的 → 一句帶過或不收 |
| 38 Best Restaurants in Paris | — | 硬閘門砍掉 根本沒 AI，是 available 之類誤中 |
08 · 誰決定？AI 提案，總編拍板
永遠不純看分數自動出刊。純分數解不了三件事：
- 一期是一個「組合」，不是排行榜。不能 6 篇全融資、全韓國；編輯要輪替、節奏要有起伏；兩篇講同件事會互相打架。
- 有些低分但你非選不可。突發、呼應你這週在做的事——策略理由只有人知道。
- 分數只是品味的代理。邊界案例永遠需要人。
提案
不只給排序清單，而是組好一整期推薦——已平衡五面向 + 組合層級（多樣性、編輯輪替、跟上期會不會太像、保鮮期）。
拍板
approve / 換 / 否決 / 撈庫存。最後一定是你說了算——你是總編，符合品牌「我們是 AI 編輯，總編是人」。
每篇附的說明
- 🔢 五面向分數拆解——看「它強在哪」
- 💡 一句主理由（the hook）——「為什麼是這篇」，例：「AI 同時是殺死食譜部落格的兇手和救星」
- 🧑🍳 建議編輯 + 切入角度
- 沒選上但接近的，附一句 「為什麼這次沒選 / 進庫存」，方便翻盤撈庫存
分數告訴你「有多好」，主理由告訴你「故事是什麼、鉤子在哪」——你真正拿來決定的是後者。
09 · 庫存與回饋沒選上的不浪費，選上的會學習
庫存 backlog：合格但沒選上的
20 篇合格、一期只出幾篇 → 剩下的不丟，進有時效的庫存。為什麼值得：
- 帶「保鮮期」自動淘汰：到期就丟，不讓庫存塞滿舊聞（目前統一 30 天；未來想分型——融資稿短、常青題長）。
- 下期重新競爭：庫存舊合格篇跟新抓到的一起排序——你永遠選的是「當下最好的」。
- 平滑淡季：料少的週，庫存就是緩衝，不開天窗。
- 餵其他格式：沒選上長文的變快訊、IG carousel、月報精選——好料一篇不浪費。
- 經營訊號：每週穩定 20 篇合格卻只出幾篇 → 該提高頻率或拉高標準。
怎麼運作：每期四步
| 步驟 | 做什麼 |
|---|---|
| ① 清過期 | 保鮮期到的先丟掉（食物新聞會餿） |
| ② 合併競爭 | 庫存倖存者 ＋ 本期新評分的，一起依分數排序成候選池 |
| ③ 選一期 | 選題會從合併池挑出本期出刊的 |
| ④ 結算 | 出刊的移出庫存；這期又沒選上的留／加回庫存，存檔 |
三個關鍵設計：① 保鮮期到自動淘汰；② 重進不續命——一篇待在庫存又沒選上，保留它原本的進庫存日、不因「又參賽一次」就重設保鮮期，免得永遠選不上的「殭屍題」賴著不走；③ 出刊就離場。
資料怎麼存（架構）
庫存存成一個人眼可讀的 JSON 檔（data/backlog.json），不是資料庫——現在資料小、出刊前手動跑一次，一個檔就夠。存取介面已抽象，等之後排程自動化、或團隊要線上看，再換 Supabase，邏輯不動、只換儲存那層。
✓ 已實作（src/lib/backlog.ts），scripts/test-backlog.ts 三期模擬驗證跨期迴圈（庫存舊篇打贏新篇出刊、過期自動淘汰）。v1 是單一保鮮期；分型保鮮期是下一步精修。回饋循環（回寫編輯 Memory）仍待儲存層。
回饋循環
你每次終選（選了哪些、否決了哪些、自己加了哪些）= 最好的訓練訊號 → 回寫三位編輯的 Soul + Memory → 初選越來越貼你的品味 → 你修正越來越少。Phase 1 盯得緊，之後放手更多，否決權永遠在你手上。
10 · 待修與優先序從概念落到可實作
先修兩個 bug（篩選站穩的前提）
| Bug | 問題 | 修法 |
|---|---|---|
| 去重失效 | 文章 id 用 ...-${Date.now()}，同一篇每次抓都產生不同 id，去重根本無效 |
改用 URL 當穩定唯一鍵 |
| AI 假陽性 | scoreRelevance 用 includes("ai")，誤中 tail / available / again，把純餐廳清單判成 AI×食物 |
改詞邊界 \bai\b，或移除裸 "ai" |
實作優先序
- 修兩個 bug（去重、
"ai"substring） - 建 seen store + 去重（先 JSON 檔，後 Supabase）
- Opus 評估 prompt（整池每篇：硬閘門 + 五面向 + 編輯路由 + 主理由，同一次呼叫）
- 初選組裝（組合層級平衡）+ 拍板介面
- 庫存 backlog + 保鮮期
- 終選回寫 memory