---
title: "導入 AI 後產出品質忽好忽壞？你少建了一間「廚房」"
url: https://stanleylin.tw/ai-quality-harness-engineering/
author: 林毓晟（Stanley Lin，史大）
published: 2026-08-08
updated: 2026-08-09
categories: AI 與自動化、數位轉型案例
description: "AI 產出忽好忽壞，問題常不只在模型。用版本、測試集、知識來源與回退機制，建立一間可追溯的 AI 品質廚房。"
---

# 導入 AI 後產出品質忽好忽壞？你少建了一間「廚房」

同一個 Prompt，昨天幫團隊整理得很完整；隔天換了一份來源文件，卻把一條關鍵限制漏掉。大家第一反應是：模型又不穩了。

團隊的第一個反應通常是再改一次提示詞，或乾脆換模型。

（曾在晶圓研發做良率提升六年半）這個場景對我並不陌生。製造現場不會只問哪台設備比較聰明，而會先查版本、條件、材料與測試。

我想把製造業的品質系統，翻譯成企業 AI 的「廚房」。

## 為什麼 AI 產出品質會忽好忽壞？

因為模型只是其中一個變因。提示詞、知識來源、輸入資料、工具權限與驗收條件只要改動，結果就可能不同，卻常沒有留下版本。

「AI 廚房」是管理原料、食譜、設備、出餐標準與退菜處理的工作環境。它不保證每次完美，但能讓差異有地方追查。

很多人以為 AI 不穩就要把 SOP 寫得更死，其實剛好相反。穩定來自可觀察與可回退，不是把每個情境硬塞進同一段指令。

如果你是老闆（或負責驗收的主管），一份錯誤內容流到客戶手上時，你能重現它當時用了哪些資料嗎？

## 製造業的版次管理怎麼對應到 AI？

Recipe 或 BOM 對應提示詞、知識庫與系統指令；變更管制對應版本與影響分析；品質驗證則對應測試案例、人工審核與回饋修正。

- **食譜**：系統指令、提示模板、輸出格式。
- **原料**：資料來源、更新日期、授權與適用範圍。
- **設備**：模型、工具、參數與連接方式。
- **品管**：測試集、檢查清單、審核人與採用紀錄。

每次改動只要記四件事：改了什麼、為什麼改、用哪些案例測、誰核准上線。這份紀錄會比「最新版 final 2」更有用。

可搭配[ERP、PLM 與 AI 治理](/ai-governance-plm-thinking/)，把版本管理拉回責任與生命週期。

## 一間可用的 AI 廚房要有哪三層？

第一層讓它能動，提供正確工具與上下文；第二層讓它能學，把失敗回寫環境；第三層讓它能換，避免流程綁死單一模型。

**能動**：輸入資料有格式、工具權限符合任務、輸出位置固定。

**能學**：遇到錯誤不只修成品，也更新測試、規則或知識來源，避免同一問題重複發生。

**能換**：把公司規則和模型設定分開。更換模型時，用同一組測試比較，不必把整條流程重做。

NIST 的 [AI 風險管理框架](https://www.nist.gov/itl/ai-risk-management-framework)強調治理、盤點、衡量與管理的持續循環。廚房就是把這個循環放進日常出餐。

## 主管該怎麼驗收 AI 產出？

先建立代表真實工作的測試集，再分成事實、格式、品牌語氣、風險與商業可用性五類檢查；高風險輸出必須由具權責的人核准。

測試集不要只有正確範例。加入缺資料、互相衝突、過期來源、敏感資訊與必須拒答的情境，才看得見流程邊界。

從 business owner 視角，檢查成本要和錯誤外流成本比較。設計階段多一次確認，通常比客戶看到後的重做、說明與信任修復更便宜。

## AI 廚房怎麼在一週內開始？

選一項高頻低風險任務，保存目前版本，挑十個真實案例建立基準，指定一位內容審核者，再記錄每次修改與結果差異。

一週後只回答三個問題：哪種錯誤最多、哪項規則最常需要人工補充、哪個資料來源最不可靠。下一版只改最關鍵的一項。

同時留下一組不參與調整的固定案例。每次改版都先跑它，才能知道新規則是真的改善，還是只把眼前案例修漂亮。沒有固定基準，團隊很容易把反覆修改誤認成持續進步。

再指定版本擁有者，定期清除過期來源與無人採用的規則，避免廚房愈整理愈擁擠。

再讀[端到端驗證缺口](/everyone-did-their-part-and-it-still-failed/)，確認品管不是只看系統說成功。你的 AI 現在是一個偶爾出好菜的廚師，還是一間知道如何穩定出餐的廚房？

## AI 的最小測試集，應該放哪十個案例？

不要只放十個容易答對的問題。測試集要同時包含正常資料、缺資料、過期資料、相互矛盾資料、敏感資料與必須拒答的要求。

每個案例旁邊寫兩件事：期待的輸出邊界，以及誰有權判定可用。這樣下一次換模型、改知識庫或調 Prompt，團隊才知道是在改善還是在漂移。

我會保留至少兩個「以前出過事」的案例，不讓它隨版本調整消失。因為最值得保留的測試，不是最好看的，而是曾經讓團隊付過代價的那一種。

如果你的 AI 今天產出漂亮，明天卻說不清為何不同，它少的往往不是智力，而是一份能守住底線的測試集。