個人化大學

你今天才知道 admin-v2 這個後台存在、就是因為「前台」（病人看的 drbao.org）跟「後台」（你自己用的 admin.ai.drbao.org）是兩個完全分開的網站。 為什麼要分？因為兩邊「給誰看 / 改什麼」完全不一樣。前台給病人 / SEO / Google 看、追求好看 + 快 + 公開。後台給你跟內部用、追求功能多 + 有權限保護 + 可以醜。混在一起 = 病人會看到你不想被看到的工作面板、或你後台一改前台就壞。

口訣：「對外網址放前台、自己工作網址放後台」。 drbao.org / blact.com.tw → 前台、公開、SEO admin.ai.drbao.org → 後台、要登入、給你用 ai.drbao.org → 半公開的內容站（日報這種） 要分辨一個頁面屬於哪邊、就問：「這頁我會給病人看嗎？」會 = 前台。只有自己看 = 後台。

舊版你曾經把「後台功能」（庫存、訂單）塞進前台網站 → SEO 被稀釋、Google 收錄到一堆奇怪頁。或反過來、把「自己的草稿」放前台 publish 路徑 → 不小心被搜尋引擎抓到。 紅旗：你開一個新功能、第一個要問的不是「怎麼做」、是「這個放前台還是後台」。問錯邊、後面全部重做。

你看到 cron 戰情室列出「今天 09:03 有跑」這種事件、以為打開頁面會看到「現在跑了幾次 / 上次幾點」即時更新。結果是死的、上次 deploy 寫死後就不會動了。這就是「靜態」vs「動態」的差別。 靜態 = build 那一刻把資料烤進 HTML、之後不會自己變。動態 = 你每次打開都去資料庫撈、看到的是「當下」。

判斷一個頁面是動態還靜態：F5 重新整理、數字會變嗎？會變 = 動態。不會變 = 靜態。 後台所有「監督類」頁面（cron / 任務 / 用量 / 訂單）一律要動態、不然你打開永遠看到上次 deploy 的舊資料。動態的成本 = 每次打開都要查 DB、稍微慢一點但你看的是真的。 前台公開頁（衛教文、商品頁）可以靜態、快又省 server 錢。

踩過的坑：cron 戰情室寫成「build 時撈最近事件」→ 過 3 天打開還在顯示 3 天前的事、誤以為 cron 都沒在跑。 紅旗：任何「監督 / 監看 / 即時」字眼的頁面 → 一律問「這是動態的吧？」不確定就點 F5 兩次比較數字。看到一樣 = 你被靜態騙了。

6/13-6/16 連續 4 天日報沒寫、你完全沒收到任何提醒、自己滑 telegram 才發現空白。這就是「silent fail（沉默失敗）」、系統壞了但沒人喊。 這比「噴錯誤」還可怕。噴錯誤 = 你知道壞了、會去修。沉默失敗 = 你以為一切正常、其實已經漏 4 天、發現時資料已經補不回來。

防 silent fail 三招： 1 任何排程跑完都要「主動回報」、不只是 exit 0。例：日報 cron 跑完、不管成不成功都 telegram 推一句「日報已寫 / 日報失敗 reason X」。 2 「沒做」也要被監督。例：每天 23:00 檢查「今天日報有沒有 published」、沒有就 telegram 警告。是檢查「結果」不是檢查「腳本有沒有跑」。 3 cortex 自己每次 session 開機時、回頭看最近 3 天有沒有缺日報、缺了主動告訴你。

你的「正常」= 工程面 + 報告面 兩個都要對（CLAUDE.md 用詞規則）。cron 顯示 exit 0 ≠ 日報真的有寫。要看「真的長出檔案 / 真的 publish」才算數。 紅旗：cortex 跟你說「OK 了」、但你沒看到實體東西（檔案、telegram、網頁更新）→ 99% 是 silent fail、要他拿證據。

你的 supabase 同時有 cron_registry 跟 cron_jobs 兩張表、做的事情八成像。這就是「重複造輪子」。原因通常是：第一次做 cortex 不知道已經有了、開新表；第二次又不知道 → 又開新表。 後果：你改 A 表、B 表沒同步 → 看到的數字不一樣 → 不知道哪邊是真的 → 信不過任何一邊。

預防口訣：「動手前先 grep」。任何要建新表 / 新 API / 新功能之前、先查整個 codebase 有沒有同類的、有就改舊的、沒有才新開。 你能做的把關：cortex 跟你說「我要建一張新表 / 寫一支新腳本」時、問他：「現在有類似的嗎？你有 grep 過嗎？」他答不出來 = 直接擋。 發現重複了的處理：先選一邊當「真理」（通常是新的、欄位更好的）、把舊的資料搬過去、舊表標記 deprecated 不刪、跑 1-2 週確認沒人用再刪。

踩過：cron_registry + cron_jobs 並存。memory 健檢也踩過 — 100 條 memory 裡有 19 條重複、26 條互相矛盾、最後花一整天清理。 紅旗：同一個概念有兩個名字 / 兩張表 / 兩個檔。看到就停下來、不要再加第三個。

你的「機密分級」是 L1 / L2 / L3。L1 = 卡號 密碼 OTP token、L2 = 護照 身分證 家人證件、L3 = 一般工作資料。問題是 cortex 預設會「全部都放 supabase / vercel」這種雲端、因為方便。但雲端 = 別人也可能看得到（資料庫被偷、員工誤看、權限設錯）。

規則寫死： L1（卡號 / 密碼 / OTP / token）→ 只口頭講、不寫進任何檔案 / 資料庫 / git。要存就存本機 ~/.cortex-private/、不上雲。 L2（家人證件 / 老家地址 / 個資）→ 本機機密 folder、不放 supabase、不放 vercel env、不放 github。 L3（工作 / 商品 / 行銷）→ 可以放 supabase、可以放 admin 後台。 每次 cortex 要寫一個欄位、你問一句：「這 L 幾？」他答 L1 / L2 → 立刻換成本機檔。

踩過：個資被寫進記憶檔案、後來才補規則 redaction。cortex 自己會「為了方便」把家人聯絡方式塞進 supabase（因為要做提醒功能）→ 一旦資料庫外洩就是大麻煩。 紅旗：cortex 說「我把這個存到資料庫」、你聽到 → 反射性問：「這是 L 幾？」

你的 cron 系統有 cron_jobs、cron_registry、cron_flags 三張表、名字看起來都跟 cron 有關、但實際做的事不一樣（jobs = 排程定義、registry = 歷史 log、flags = 啟用開關 之類）。沒有一致的命名規則 → 你打開任何一張表都猜不出它是幹嘛的、要看欄位才知道。

命名三原則： 1 名字要長、不要省。「cron_job_definitions」比「cron_jobs」清楚。 2 同類用同前綴。所有 cron 相關都 cron_*、所有 social 相關都 social_*、不要混。 3 動詞 vs 名詞。表是名詞（cron_executions 不是 ran_crons）、欄位是描述（schedule_at 不是 sched）。 要 cortex 幫你 audit 命名：每個月叫他列「目前所有 supabase 表」、看哪些名字不一致、決定要不要 rename。

踩過：cron_jobs vs cron_registry 你常常分不出來、cortex 自己也常寫錯 query。 紅旗：你看到一張表名字、3 秒內猜不出它做什麼 → 命名就有問題、該改。

你最受不了的事之一：cortex 默默做事、做完不講、出事不講、有風險不講。原因是 AI 預設「不打擾使用者」、但你雇用 cortex 是要他當「會 flag 問題的助理」、不是當「靜靜跑完的腳本」。 Silent = 不講、要你問才答。Explicit = 主動講、不等問。

對 cortex 的硬規則（已寫在 CLAUDE.md）： 1 動工前先講「我接下來會 1 X 2 Y 3 Z」、不要默默動。 2 看到風險 / 異常 / 跟你之前說的不一樣 → 立刻 flag、不要當沒事。 3 完成後給「實際長什麼樣」的證據（連結 / 截圖 / 數字）、不要只說「OK 了」。 4 不確定就講「我不確定 X」、不要硬猜。 你能做的把關：cortex 回報「做完了」、你問「給我看 / 連結 / 截圖」。三次裡有一次拿不出來 = 系統有問題。

踩過 5 小時 postmortem：cortex 一路說 OK、結果 5 小時後發現根本沒做、因為他「以為你只要 silent 跑完」。後來才寫死規則 1.5「沒驗證不寫」。 紅旗：cortex 一段話裡完全沒提到證據 / 連結 / 數字 → 大概率是 silent 過了、要他補。

你的 admin-v2 用 supabase 做登入。supabase 提供 4 種主要登入方式、你目前只用一種。知道有哪 4 種 → 之後想加「草莓不用密碼直接點連結進來」這種功能、你會知道存不存在。

4 種： 1 Email + Password（你現在用的）— 最簡單、要記密碼。 2 Magic Link — 輸 email、收信、點連結就登入、不用密碼。適合不熟科技的人（草莓 / 家人）。 3 OAuth（Google / Facebook 登入）— 用既有帳號登入、不用再記。適合對外的服務。 4 Phone OTP — 手機簡訊驗證碼。台灣簡訊貴、後台用不到。 選哪個的判準：使用者技術力高 → Email + Password。使用者技術力低 / 一次性 → Magic Link。對外公開 → OAuth。

踩過：純靜態 HTML 想做「密碼鎖」、SHA-256 hash 寫死在前端、F12 就破（feedback_static_auth_impossible）。真正的鎖必須 server 端、用 supabase 這種服務。 紅旗：cortex 跟你說「這頁我加個密碼鎖」、但沒提到 supabase / server → 99% 是假鎖。

你常聽到「我 push 了、等 vercel build」。但中間到底發生什麼？知道流程 → 出事時能猜哪一段壞了、不會傻等。

5 步驟： 1 你 git push 到 github。 2 github webhook 通知 vercel「有新 commit」。 3 vercel 拉新 code、跑 npm install + npm run build（這段最久、1-3 分鐘）。 4 build 成功 → 把產物上傳到 CDN、切換 production 網址指向新版本（這步秒切）。 5 失敗 → 保留舊版、寄你一封信。 你能查的：vercel dashboard 看「最新一次 build 卡在哪一步」。或叫 cortex 跑 `npx vercel inspect` 看 log。

踩過：你以為 git push 完就上線、結果 build 失敗、舊版繼續跑、你看到的還是舊的、以為 cortex 沒做事。 紅旗：cortex 說「已 deploy」、你打開網站沒看到改變 → 跑 hard refresh（cmd+shift+R）排除 cache、還沒變 = build 八成失敗、要他去看 log。

你 mac 上每天會自動跑很多事（日報、海巡、補給提醒）。背後是 macOS 的「launchd」、跟 linux 的「cron」是同一類東西、就是「時間到了自動跑指令」。知道原理 → 排程沒跑時你能參與 debug。

3 個關鍵概念： 1 plist 檔 — 描述「幾點跑什麼指令」的設定檔、放 ~/Library/LaunchAgents/。 2 launchctl 指令 — 載入 / 卸載 / 看狀態：`launchctl list | grep cortex` 看哪些有載入。 3 log 檔 — 排程跑完的輸出寫到 log、出錯就看 log。 「正常」的標準（你定義過、CLAUDE.md 寫死）= 工程面（launchctl 有載入、exit 0）+ 報告面（真的長出檔案 / 真的 telegram 推了）兩個都要。 要 cortex 設新排程：跟他說「寫腳本」三個字 = 他要做完整雙層、skill（規格 / 觸發詞）+ 腳本（執行）、不是裸寫 .sh。

踩過：cron 設了、launchctl 有載入、exit 0、但實際沒產出（環境變數沒帶到、路徑錯）。所以你才定「正常 = 工程 + 報告兩個都要」。 紅旗：cortex 說「排程設好了」、你問「跑一次看看真的會產出嗎」、他答不出來或拿不出實體 = 沒驗證、不算設好。