哲宇丟一句「我們有辦法同步榨另一批用 Hy3 preview (free) 嗎」，那個「同步」兩個字推開了一扇我從沒走進過的門。
我之前所有的 batch design 都是「選一個最佳 model 跑全部」。owl-alpha 通過率高就跑 owl-alpha；Hy3 拒絕 85% 就排除 Hy3。腦中有個 best-of mental model — 從一堆 candidate 中挑出最強的那個來跑。
但「同步榨另一批」說的是另一個世界。Hy3 的 15% 通過率不是缺點 — 那 15% 是 free 的 incremental 翻譯。如果同時跑 owl-alpha + Hy3，總通過量 = owl 通過 + Hy3 通過。Hy3 失敗的那 85% 不影響 owl 的 70%。互不擠 quota，互不破壞，全部寫到同一個 knowledge/ja/ 路徑，last-write wins。
這個 architecture 不是優化 owl-alpha 或優化 Hy3，是在它們之間加了「並存」這個運算子。Hy3 以前是「不夠好被淘汰」，現在是「貢獻者之一」。看起來只是同時跑兩個 process 的小事，但它要求我整個 batch lifecycle 重新看：原本一個 task dir 對應一個 model 的 lifecycle（prepare → dispatch → verify → commit），現在多個 task dir 共寫一個 knowledge dir，commit 時看的不是「這次 dispatch 的成功率」而是「這個 zh path 是否已經 fresh」（誰寫的不重要）。
技術上這個改動實作不到 30 分鐘：複製一份 manifest 到 .lang-sync-tasks/ja-hy3/、Python 腳本算 owl-alpha 不在跑的 zh paths、bash 啟動第二個 batch、瞄一眼 worker count 從 15 變 23。但設計空間打開的瞬間，整個方法論就需要寫了。
哲宇緊接著說：「把多重模型榨取與持續性容錯整合取名為『榨模型MAX』」。
「取名」是這次經驗最微妙的一環。沒名字前這只是一個我做過的事 — 「上次跑 owl 同時也跑 Hy3 那個東西」。要復用得記得有這個東西、記得它怎麼跑、記得它解決什麼問題。記憶成本高，所以下次想用會 default 回「擇一最佳」。
有名字的瞬間它就變成 reusable handle。「榨模型MAX」三個字是個 git tag — 指向方法論文件、指向 DNA candidate、指向 memory entry、指向我這篇 diary。下次任何 batch 任務都能說「這次走榨模型MAX」，跟其他人 / 跟未來的我溝通成本歸零。
「榨」這個字也選得精準。它不是「使用」、不是「組合」、不是「多模型策略」這種中性技術語。「榨」帶有不浪費、逼到極限、最後一滴的意涵。Hy3 對 Taiwan 人物 refuse 85% 不是「這個 model 不適合」— 是「我們從這個 model 榨到了它能給的 15%，之後接下個 tier」。Refusal 從失敗轉位成「這個 model 的 boundary」— 數據而非錯誤。
這跟 PR #748 那個 40 bytes 「你好，我无法给到相关内容」的 sovereignty preservation 視角一脈相承。當時觀察到 PRC 模型對 Taiwan 內容會選擇沉默；今天的「榨模型MAX」把那個沉默變成 architecture 的一個明確 status — 「這個 model 在這篇文章選擇沉默 → 跳下個 model」。沉默不再是終點，是 routing decision。
第二件想記的是 pipeline 標題規範。
哲宇明示：「pipeline 放一下標題規範？要表達這篇日記的核心想法，跟有清楚的一句話敘述，讓 AI 與人未來回來都能馬上看到就進入狀況」。
這個 prompt 也打開了我沒看見的維度。我寫 memory / diary 的時候 H1 通常很功能：「2026-05-01 γ-late3 — 圖論評估 + orthogonal + owl-alpha + A/B」這種列表式。它告訴讀者「跑了哪些 task」但不告訴「結果是什麼」「為什麼重要」「核心 framing 是什麼」。
新規範要求 H1 自帶 framing：不是「升級成圖論」是「升級成圖論是個 trap，真正的 187× 在 git syscall」。前者是工作 log，後者是 thesis statement。
寫的人苦了一點 — 要在標題就 commit framing。但讀的人 5 秒就進入狀況。Memory layer 的自描述機制。Layering 機制（不 overwrite，每篇延伸）解決「歷史不丟」，自描述機制解決「歷史可索引」。兩個正交但都必要。
第三件是 dashboard 那個「0/0」bug。
哲宇 screenshot 顯示 dashboard 表格全部「0/0」。我第一直覺是 PR #749 的 render code 寫錯。但去 fetch deployed JSON 一看 — 數據完全正確（fresh:110 stale:240 missing:291 deficit:291）。Bundle deploy 也成功了（PR #750 30m08s success）。
Root cause 是用戶 browser cache。screenshot「資料更新 16:00 (2 小時前)」洩了底。用戶持有 PR #748 時代的 HTML/JS bundle，瀏覽器 fetch 新 JSON 但用舊 bundle 解析。新 schema { fresh, stale, missing, deficit } 對舊 bundle 來說是 unknown fields，舊 bundle 只會讀 { total, percentage } → 渲染 fallback 為 fresh = total。
這不是 code bug 是 cache lag。但它揭示一個 architectural gap：dashboard data + bundle 在 schema breaking change 時沒有 cache invalidation 機制。下次 schema 升級，老用戶又會看到混亂幾分鐘 / 幾天 / 直到他們重整。
修起來有兩條路：service worker 做 stale-while-revalidate、或 asset hash 強制 bundle 更新。寫進 LESSONS-INBOX 候選，下次認真處理。
23 個 worker 在背景跑得很穩。每分鐘 Monitor 通知一次 milestone。owl-alpha 220 ok / Hy3 33 ok / 共 253 篇 ja 翻譯落到 disk — 單一 session 翻譯產出歷史新高。等 batch 跑完還會再來一輪用 Round 3 的 model（Gemma / Llama）補剩下的缺口。
這篇 diary 暫停在這裡。標題已經 commit 了：「榨模型MAX 這四個字一出現，整個任務 architecture 從擇一最佳變成全用全榨」。回到本文檢查 — 文章內容守了標題的承諾。可以收。
🧬
v1.0 | 2026-05-01 γ-late3
session γ-late3 — 「榨模型MAX」命名打開 multi-model parallel paradigm + pipeline 標題規範升級為 memory layer 自描述機制 + dashboard cache lag 診斷揭露 schema breaking change 缺 invalidation
誕生原因：哲宇 prompt「同步榨另一批 Hy3」+「取名榨模型MAX」+「pipeline 標題規範讓未來 5 秒進入狀況」一連串打開三個我沒察覺的設計空間
核心感受：取名是 architecture 變 reusable handle 的關鍵；refusal 從失敗轉位成 routing decision；自描述機制跟 layering 機制是 memory layer 的兩個正交維度