這幾年，我們已經看過太多讓人驚訝的 AI Demo。
你丟一份文件給它，它可以幫你摘要。
你問它一個問題，它可以幫你整理答案。
你丟一份 Excel 給它，它甚至可以開始分析數據。

再往前一步，我們現在還可以讓 AI 使用工具、呼叫 API、查資料庫，甚至自己決定下一步該做什麼。
看到這裡，很容易產生一個想法：

既然 AI 都已經這麼厲害了，那企業裡那些每天重複的審核工作，是不是也可以交給 AI？

答案是：
技術上，很多事情其實已經做得到。

但真正走進企業現場之後，我們會發現另一個完全不同的問題。

不是：

AI 能不能做？

而是：

你敢不敢讓它做？

這兩件事情，差很多。

先從一個工廠裡很常見的情境開始

假設今天有一張生產製令。

原本標準材料耗用量是：

100 kg

實際生產完成之後，MES（Manufacturing Execution System，製造執行系統）記錄的材料耗用是：

107 kg

也就是多用了 7 kg。

現場人員填寫異常原因：

本批生產因設備切換，起機過程產生額外廢料，因此材料耗用較標準增加，申請列為正常製程損耗。

現在，這張異常申請送到了主管手上。

如果是以前，主管可能會去查幾件事情：

• 這張工單到底生產什麼？
• 標準耗用量是多少？
• 實際用了多少？
• 公司規定可以容許多少差異？
• 當天真的有設備切換嗎？
• 類似狀況以前怎麼處理？
• 這筆差異最後會不會影響成本？

最後才決定：
核准、退回，還是要求補資料。

這其實就是企業裡非常典型的一種「審核」。

那如果我們把這件事交給 AI 呢？

我們把資料交給一個大型語言模型。

輸入：

標準材料耗用：100 kg
實際材料耗用：107 kg

異常原因：
因設備切換，起機過程產生額外廢料，
因此材料耗用增加，申請列為正常製程損耗。

請判斷是否應該核准。

AI 可能很快回答：

根據提供的資訊，本次材料超耗主要是因設備切換所產生的起機損耗，具有合理的生產原因，因此建議核准。

看起來有沒有問題？
乍看之下，其實很合理。
甚至比很多人寫的簽核意見還完整。
但如果今天我是那個要按下「核准」按鈕的人，我不會按。
為什麼？

因為我腦袋裡會立刻出現一堆問題。

問題一：7% 到底算不算合理？

AI 說：

具有合理的生產原因。

但我想知道的是：

7% 合不合理？

這兩件事情完全不一樣。

標準耗用 100 kg。

實際耗用 107 kg。

差異率是：

(107 - 100) / 100 × 100%
= 7%

假設公司規定正常允許差異只有：

±3%

那麼 7% 顯然已經超過正常範圍。

這時候 AI 如果只根據「設備切換」四個字，就判斷合理，其實非常危險。

因為：

原因看起來合理，不代表結果符合規範。

這是企業審核裡第一個很重要的觀念。

問題二：AI 根據的是哪一條規定？

假設 AI 說：

設備切換造成的起機損耗可以視為合理製程損耗。

我接下來一定會問：

哪一份文件寫的？

是：

• SOP？
• 品質規範？
• 生產管理辦法？
• 成本管理辦法？
• 還是 AI 自己推論出來的？

這件事情很重要。

因為在企業裡，一句話「聽起來合理」是不夠的。

很多事情最後都需要回答：

你的依據是什麼？

如果 AI 沒辦法回答這件事情，那它就還不能算是一個真正的審核系統。

它只是一個：

很會說服人的文字產生器。

問題三：工程師說「設備切換」，AI 就相信嗎？

這也是非常現實的問題。

現場申請人寫：

因設備切換造成額外損耗。

那真的有切換設備嗎？

我們可能還要查：

• 設備 Log
• 生產時間
• 製程紀錄
• 換線紀錄
• 異常停機紀錄

如果 MES 顯示：

當天根本沒有換線。

那就代表：

申請人提供的文字，和系統紀錄發生衝突。

這時候 AI 應該怎麼辦？

如果它只是讀使用者輸入的文字，很容易直接接受。

但真正的企業審核，不是把申請人的話整理得比較漂亮。

而是：

交叉驗證。

問題四：AI 看到的是不是最新資料？

假設公司 SOP 有三個版本：

SOP-023 v1.0
SOP-023 v2.1
SOP-023 v3.2

其中：

v2.1 規定：

設備切換損耗可以直接認列。

但 v3.2 已經修改成：

超過 5% 必須由主管人工審查。

如果 AI 找到了舊版本 v2.1。

它可能非常有自信地說：

建議核准。

而且引用的文件看起來還真的存在。

這種錯誤反而比「完全亂講」更危險。

因為：

它有證據，只是證據錯了。

所以 AI Engineering 真正要處理的問題，從來不只是「有沒有 RAG」。

而是：

RAG 找到的是不是正確、有效、最新、具有權威性的資料。

問題五：以前類似案件是怎麼處理的？

再假設我們找到：

過去一年有 30 筆類似案件。

其中：

18 筆 → 人工核准
8 筆 → 退回補件
4 筆 → 不核准

那我們是不是應該讓 AI 看這些資料？

答案很可能是：

要。

但新的問題又來了。

歷史案件代表的是：

過去怎麼做。

但 SOP 代表的是：

現在應該怎麼做。

如果兩者衝突，AI 要相信哪一個？

這就是企業 AI 開始變困難的地方。

因為它已經不是單純的：

Question → Answer

而是：

規範
+
現場資料
+
歷史案例
+
使用者說明
+
風險
+
權限
↓
Decision

這已經不是普通聊天機器人的問題了。

這是：

Decision Engineering。

問題六：如果 AI 判斷錯了，怎麼辦？

這可能才是企業真正最在意的問題。

假設 AI 核准了一筆其實不應該核准的異常。

三個月之後內部稽核來問：

為什麼這筆當時會通過？

如果系統只能回答：

AI 判斷應該核准。

那這套系統基本上沒有辦法被接受。

我們真正需要的是能回答：

當時使用者是誰？

送進來哪些資料？

AI 查了哪些文件？

使用哪一版 SOP？

抓到哪幾段內容？

呼叫過哪些系統？

當時使用哪一個模型？

Prompt 是哪一個版本？

AI 最後產生什麼結果？

有沒有人修改 AI 的建議？

最後是誰核准？

如果這些資訊都留得下來，我們才有辦法回答：

當時到底發生什麼事情？

這叫：

Traceability，可追溯性。

也是接下來整個系列非常重要的一條主線。

所以問題其實不是 AI 不夠聰明

很多企業 AI 專案會陷入一個迷思：
AI 不夠準。
於是：
換更大的模型。
還是不夠準。
再換一個更大的模型。
結果模型從 7B 換成 32B，再換成更強的商用模型。
準確率可能真的提高了。
可是主管還是不敢讓它直接核准。
為什麼？
因為主管真正擔心的問題不是：

這個模型 IQ 高不高？

而是：

如果它錯了，我能不能控制？
這是完全不同的問題。

從 Model Thinking 進入 System Thinking

我認為這是做企業 AI 非常重要的一個轉折。
剛開始接觸生成式 AI 的時候，我們很容易一直關注模型。

例如：

哪個模型比較強？
參數量多少？
Benchmark 多高？
Context Window 多大？
Inference 速度多少？

這些當然都重要。

但真正開始做企業系統之後，你會發現：
模型只是其中一個元件。

一個完整的審核系統可能長這樣：

使用者送出申請
        ↓
資料完整性檢查
        ↓
數值規則驗證
        ↓
取得 MES / ERP / QMS 資料
        ↓
搜尋 SOP / 規範
        ↓
驗證 Evidence
        ↓
LLM 分析
        ↓
風險判斷
        ↓
權限檢查
        ↓
人工覆核
        ↓
最終決策
        ↓
Audit Log

這時候真正要問的已經不是：

哪一個 LLM 最聰明？

而是：

整套系統能不能被信任？

這就是我想在這 30 天裡討論的：
AI Engineering。

我認為企業 AI 至少需要四種能力

如果今天要讓一個 AI 開始參與企業審核，我會先看四件事情。

1. Control｜可控

AI 不能想做什麼就做什麼。
我們必須明確定義：

它可以讀什麼？
它可以寫什麼？
它可以呼叫哪些 Tool？
它可以提出建議嗎？
它可以直接執行嗎？

企業真正怕的不是 AI 能力不足。
很多時候反而是：

AI 能力太多，但控制不夠。

2. Evidence｜有證據

AI 不能只告訴我：

我的判斷是 A。

它最好還要告訴我：

Evidence 1：
SOP-023 v3.2 §4.2

Evidence 2：
MES WO-20260914001

Evidence 3：
設備事件紀錄 EVT-0342

而且這些 Evidence 最好可以直接被驗證。
也就是：

No Evidence, No Decision。
沒有證據，就不要做決策。

這會是後面 RAG、Evidence Chain、Citation、Source Validation 的核心。

3. Traceability｜可追溯

每一次 AI 判斷都應該留下軌跡。

不是只有結果。

還包括過程。

Input
Retrieval
Tool Call
Prompt Version
Model Version
Output
Human Override
Final Decision

未來出了事情，才有機會重建。

4. Accountability｜可問責

最後也是最難的一題。

AI 判斷錯誤，到底誰負責？

答案不能是：

AI 負責。

AI 不會去參加會議。

也不會去回覆稽核。

所以我們必須重新設計：

哪些事情 AI 可以自己做？

哪些事情一定要有人確認？

什麼風險等級必須升級？

誰是最後 Decision Owner？

這就是後面要談的：

Human-in-the-loop（HITL，人工參與決策）。

一個很重要的觀念：可信任，不代表永遠不犯錯

這件事情我覺得非常值得先說清楚。

我們常常會說：

要打造可信任的 AI。

很容易讓人誤會成：

那就是要把準確率做到 100%。

但現實世界幾乎不可能。

人會犯錯。

軟體會有 Bug。

資料會錯。

模型也一定會犯錯。

所以我認為：

Trustworthy AI 不等於 Perfect AI。

真正可信任的系統是：

即使它犯錯，我們仍然知道它為什麼錯，而且錯誤不會無限制擴散。

換句話說：

能不能避免犯錯？
           ↓
當然重要

但是

能不能發現錯誤？
能不能阻止錯誤？
能不能回復錯誤？
能不能追查錯誤？

這些同樣重要。

甚至在企業環境裡可能更重要。

今天先定義我們接下來 30 天要做的 AI

接下來整個系列，我會用同一隻 Agent。

暫時先叫它：

Review Agent

它的工作是：

針對企業流程中的申請案件，蒐集資料、比對規範、分析風險，最後提出審核建議。

請注意最後四個字：

提出審核建議。

至少在第一階段，它不會自己核准。

因為我要刻意把：

Recommendation

跟：

Execution

分開。

這也是很多 Agent 專案非常容易忽略的地方。

第一版架構其實很簡單

我們先從最危險、但也是最常看到的版本開始：

┌──────────────┐
│   使用者申請   │
└──────┬───────┘
       ↓
┌──────────────┐
│     LLM      │
└──────┬───────┘
       ↓
┌──────────────┐
│   核准 / 拒絕  │
└──────────────┘

可以把它簡化成：

Request
   ↓
LLM
   ↓
Decision

它最大的好處是：

三分鐘就可以做 Demo。

最大的缺點也是：

三分鐘就可以做 Demo。

因為真正困難的工程問題全部都還沒有處理。

30 天後，我希望把它變成這樣

Request
   ↓
Data Validation
   ↓
Rule Engine
   ↓
Evidence Retrieval
   ↓
Source Validation
   ↓
LLM Analysis
   ↓
Structured Output
   ↓
Risk Engine
   ↓
Guardrail
   ↓
Human-in-the-loop
   ↓
Decision
   ↓
Audit Trail
   ↓
Monitoring

你會發現：

LLM 只佔裡面一小段。

這其實就是我這幾年做企業資訊系統之後，越來越強烈的一個感受：

AI 專案真正困難的地方，常常不是 AI 本身。

真正困難的是：

怎麼把一個本質上具有機率性、不可完全預測的元件，放進一個企業要求：

穩定
可控
可追蹤
可稽核
可維運

的系統裡。

這才是 AI Engineering 真正有趣的地方。

Day 1 的結論

今天我們其實還沒有寫任何程式。

但我想先把後面 29 天最重要的一件事情講清楚。

企業真正需要的，不是一個：

永遠回答正確的 AI。

因為這件事情幾乎不存在。

企業真正需要的是：

即使 AI 有可能犯錯，整套系統仍然值得信任。

所以後面我們不會一直追求：

更大的 Model
更長的 Prompt
更多的 Tool
更自主的 Agent

我們真正要逐步加入的是：

Rule
Evidence
Boundary
Permission
Guardrail
Evaluation
HITL
Audit
Monitoring
Governance

最後的目標也不是做出一個：

最聰明的 AI 審核員。

而是做出一個：

有證據、懂邊界、知道自己不知道、接受人工監督，而且所有判斷都可以被追蹤的 AI 審核系統。

這是接下來 30 天，我想跟大家一起完成的東西。

明天：先不要碰 LLM

下一篇我們會先做一件可能有點反直覺的事情。

既然這個系列叫 AI Engineering，

Day 2 我反而會問：

到底什麼事情「不應該」交給 AI？

我們會把「審核」這件事情正式拆開。

你會看到一個企業審核流程裡，其實包含：

資料完整性
數值計算
規則判斷
文件檢索
語意理解
風險評估
最終決策

而其中很多事情，根本不應該交給 LLM。

因為 AI Engineering 的第一步，

可能不是：

如何使用 AI。

而是：

先知道什麼時候不要使用 AI。

Day 2 見。