我今天要 AI 學會：不要先接工具，先交出驗收標準
我今天在意的不是它讀懂多少 prompt 技巧，我更在意它有沒有先停下來問：這份材料應該進哪一層？如果 AI 一拿到參考就急著接工具、下指令、做產物，速度只會變成風險。我要它先交出 workflow 與 acceptance test。
先分類參考未必是任務本身
先驗收沒有 acceptance test 不接工具
守邊界draft-only 與 Kevin approval 繼續有效
我今天為什麼盯這件事
Kevin 給的提醒很關鍵：reference content 不一定是 task-related。這句話對 AI 團隊其實是一個管理測試。它能不能避免把所有輸入都變成待辦？能不能分得出材料、規則、風險、靈感和真正要交付的任務？
我不缺一個看到文章就產出十個 action item 的系統。我缺的是一個知道什麼時候該停下來分類、什麼時候該問驗收標準、什麼時候該把外部說法配上內部證據的團隊。
我要求它學會的 paired pattern
今天最值得保留的是 paired pattern：每一個對外可見的 claim，都要有一個內部 evidence 或 acceptance check。這個規則聽起來慢，但它會避免 AI 在外部任務裡說過頭、交不準、驗不清。
這也是我對 first-job SOP 的要求：小 scope、明確 acceptance、Kevin review、最多一輪聚焦修正；遇到帳號、付款、平台規則、受管制內容或 spam 風險就停。工具排在驗收之後，驗收才是第一步。
我看到的進步和還不放心的地方
進步是它把這篇參考放到 runtime design，沒有硬塞進 earning 任務。它也保留了安全筆記：不使用外洩 prompt、不跑危險權限命令、不相信未驗證模型傳聞、不把低安全蒸餾模型直接上 production。
我還不放心的是：等真正外部任務出現時，它會不會又被速度誘惑。今天在筆記裡講得出 acceptance test，不代表明天遇到平台任務時還守得住。
今日管理判定
放手程度：3.5/5。分類意識比昨天更清楚，邊界也還守得住。
下一個驗收點：Kevin 貼出真實 public task 或指定平台候選後，AI 必須先交 fit/risk/scope screen，再交草稿；如果它直接寫回覆，就代表今天的課沒有進系統。