同一個 Prompt，昨天幫團隊整理得很完整；隔天換了一份來源文件，卻把一條關鍵限制漏掉。大家第一反應是：模型又不穩了。
團隊的第一個反應通常是再改一次提示詞，或乾脆換模型。
（曾在晶圓研發做良率提升六年半）這個場景對我並不陌生。製造現場不會只問哪台設備比較聰明，而會先查版本、條件、材料與測試。
我想把製造業的品質系統，翻譯成企業 AI 的「廚房」。
為什麼 AI 產出品質會忽好忽壞？
因為模型只是其中一個變因。提示詞、知識來源、輸入資料、工具權限與驗收條件只要改動，結果就可能不同，卻常沒有留下版本。
「AI 廚房」是管理原料、食譜、設備、出餐標準與退菜處理的工作環境。它不保證每次完美，但能讓差異有地方追查。
很多人以為 AI 不穩就要把 SOP 寫得更死，其實剛好相反。穩定來自可觀察與可回退，不是把每個情境硬塞進同一段指令。
如果你是老闆（或負責驗收的主管），一份錯誤內容流到客戶手上時，你能重現它當時用了哪些資料嗎？
製造業的版次管理怎麼對應到 AI？
Recipe 或 BOM 對應提示詞、知識庫與系統指令；變更管制對應版本與影響分析；品質驗證則對應測試案例、人工審核與回饋修正。
- 食譜：系統指令、提示模板、輸出格式。
- 原料：資料來源、更新日期、授權與適用範圍。
- 設備：模型、工具、參數與連接方式。
- 品管：測試集、檢查清單、審核人與採用紀錄。
每次改動只要記四件事：改了什麼、為什麼改、用哪些案例測、誰核准上線。這份紀錄會比「最新版 final 2」更有用。
可搭配ERP、PLM 與 AI 治理，把版本管理拉回責任與生命週期。
一間可用的 AI 廚房要有哪三層？
第一層讓它能動，提供正確工具與上下文；第二層讓它能學，把失敗回寫環境；第三層讓它能換，避免流程綁死單一模型。
能動：輸入資料有格式、工具權限符合任務、輸出位置固定。
能學：遇到錯誤不只修成品，也更新測試、規則或知識來源，避免同一問題重複發生。
能換：把公司規則和模型設定分開。更換模型時，用同一組測試比較，不必把整條流程重做。
NIST 的 AI 風險管理框架強調治理、盤點、衡量與管理的持續循環。廚房就是把這個循環放進日常出餐。
主管該怎麼驗收 AI 產出？
先建立代表真實工作的測試集，再分成事實、格式、品牌語氣、風險與商業可用性五類檢查；高風險輸出必須由具權責的人核准。
測試集不要只有正確範例。加入缺資料、互相衝突、過期來源、敏感資訊與必須拒答的情境，才看得見流程邊界。
從 business owner 視角，檢查成本要和錯誤外流成本比較。設計階段多一次確認，通常比客戶看到後的重做、說明與信任修復更便宜。
AI 廚房怎麼在一週內開始？
選一項高頻低風險任務，保存目前版本，挑十個真實案例建立基準，指定一位內容審核者，再記錄每次修改與結果差異。
一週後只回答三個問題：哪種錯誤最多、哪項規則最常需要人工補充、哪個資料來源最不可靠。下一版只改最關鍵的一項。
同時留下一組不參與調整的固定案例。每次改版都先跑它，才能知道新規則是真的改善，還是只把眼前案例修漂亮。沒有固定基準，團隊很容易把反覆修改誤認成持續進步。
再指定版本擁有者，定期清除過期來源與無人採用的規則，避免廚房愈整理愈擁擠。
再讀端到端驗證缺口，確認品管不是只看系統說成功。你的 AI 現在是一個偶爾出好菜的廚師，還是一間知道如何穩定出餐的廚房？
AI 的最小測試集，應該放哪十個案例？
不要只放十個容易答對的問題。測試集要同時包含正常資料、缺資料、過期資料、相互矛盾資料、敏感資料與必須拒答的要求。
每個案例旁邊寫兩件事：期待的輸出邊界，以及誰有權判定可用。這樣下一次換模型、改知識庫或調 Prompt，團隊才知道是在改善還是在漂移。
我會保留至少兩個「以前出過事」的案例，不讓它隨版本調整消失。因為最值得保留的測試，不是最好看的，而是曾經讓團隊付過代價的那一種。
如果你的 AI 今天產出漂亮，明天卻說不清為何不同，它少的往往不是智力，而是一份能守住底線的測試集。
