不要把 AI Demo 當正式系統：測試成功，離上線還有一大段距離

很多人第一次看到 AI demo，會覺得很驚豔。

AI 能寫文章。
AI 能回答客服。
AI 能看圖片。
AI 能整理資料。
AI 能幫忙寫程式。
AI 能自動建立檔案。
AI 能串接工具。

看起來好像只要把它接上去，小企業的很多問題就能自動解決。

但真正踩過現場後會發現：

Demo 成功，不等於正式系統可上線。

Demo 是乾淨的。
正式環境是混亂的。

Demo 通常只有一個任務。
正式環境會有很多例外。

Demo 只要證明「可以做」。
正式系統要證明「可以穩定、可控、可追蹤、可回復」。

這中間差很遠。

---

Demo 為什麼看起來總是很順？

Demo 通常會選擇最容易成功的情境。

例如：

• 一個乾淨的問題
• 一份完整的資料
• 一張清楚的圖片
• 一個明確的任務
• 一次簡單的流程
• 一個沒有權限衝突的環境
• 一個沒有舊資料干擾的案例

這種情境裡，AI 很容易表現得很好。

它可以快速理解。
快速回應。
快速產出。
快速讓人覺得有價值。

但正式使用時，現場通常不是這樣。

小企業的真實現場常常是：

• 資料在不同地方
• 圖片品質不穩
• 客人需求講不清楚
• 舊資料和新資料混在一起
• 帳號權限不一致
• 網站後台流程不固定
• 人工判斷還沒有標準
• AI 不知道哪些事不能做
• 出錯後不知道誰負責

這就是 demo 和正式系統最大的差別。

---

第一個落差：資料沒有 demo 那麼乾淨

AI demo 裡，資料通常是整理好的。

但小企業現場的資料很少這麼乾淨。

可能在：

• LINE 對話
• Email
• Google Drive
• 桌面資料夾
• 手機相簿
• Excel
• Word
• 網站後台
• 舊電腦
• 員工個人帳號
• AI 聊天紀錄

這些資料可能版本不同、命名不同、格式不同、時間不同。

AI 如果拿到錯資料，就會產出錯結果。

這時候問題不是 AI 不聰明。

問題是：

你給它的資料來源不清楚。

所以正式上線前，必須先問：

• 哪份資料是正本？
• 哪份資料不能用？
• 哪份資料已過期？
• 哪些資料可以給 AI？
• 哪些資料不能給 AI？

沒有資料整理，就不要急著談 AI 上線。

---

第二個落差：權限沒有 demo 那麼單純

Demo 裡通常不會遇到複雜權限。

但正式系統一定會。

例如：

AI 可以看哪些資料？
AI 可以改哪些檔案？
AI 可以發文嗎？
AI 可以刪除嗎？
AI 可以接觸客戶資料嗎？
AI 可以拿到後台帳號嗎？
AI 可以使用 API key 嗎？
AI 可以進正式站台嗎？

如果這些沒有先定義，AI 很容易越界。

它不是故意的。

它只是照著任務往前做。

你說「幫我整理舊系統」，它可能把不該帶出的資料也整理出來。
你說「幫我發文」，它可能不清楚哪些文章可以發。
你說「幫我測試」，它可能不小心碰到正式環境。

所以正式上線前，一定要先定義權限邊界。

AI 可以做什麼，不可以做什麼，要寫清楚。

---

第三個落差：API 成本不會在 demo 裡暴露

Demo 通常跑幾次就結束。

所以看不出真正成本。

但正式上線後，AI 可能每天都在跑。

客服每天有人問。
文章每天要生成。
圖片每天要處理。
資料每天要整理。
工具每天要呼叫。

這些都會變成 API 成本。

如果流程沒有控制，AI 可能不是省錢，而是持續燒錢。

尤其是圖片、長文章、多輪對話、多 agent 協作，很容易讓成本上升。

所以正式系統要先設成本邊界。

例如：

• 每次任務最多幾輪
• 每篇文章誰負責審
• 哪些內容不丟給 Hermes 重讀
• 哪些規則寫進文件，不每次重複貼
• 哪些任務只做本機檢查
• 哪些情況停止，不繼續生成

省 API 不是少用 AI。

是不要讓 AI 做錯位置的事。

---

第四個落差：失敗回退在 demo 裡常常沒有測

很多 demo 只展示成功。

但正式系統最重要的是：

失敗怎麼辦？

例如：

文章發錯了怎麼辦？
網站改壞了怎麼辦？
AI 回覆錯了怎麼辦？
圖片生成失敗怎麼辦？
API 中斷怎麼辦？
發文到錯分類怎麼辦？
草稿被誤發怎麼辦？
權限誤給太大怎麼辦？

如果沒有回退方案，就不算正式系統。

正式系統要知道：

• 怎麼停止
• 怎麼回滾
• 怎麼恢復上一版
• 怎麼確認網站正常
• 怎麼留下紀錄
• 怎麼避免下次再發生

AI 系統不能只會成功。

也要會安全失敗。

---

第五個落差：人工接手常常沒設計

AI 很適合處理前段。

例如：

• 整理需求
• 初步回答
• 建立草稿
• 分類資料
• 提醒風險
• 產生檢查清單

但很多事情仍然需要人工接手。

例如：

• 客戶正式下單
• 內容是否能公開
• 是否涉及價格
• 是否涉及敏感資料
• 是否可以發佈
• 是否需要回滾
• 是否修改網站設定
• 是否進正式環境

如果沒有人工接手點，AI 可能會一路往前做。

這就是風險。

正式流程要先定義：

哪一步一定要停下來等 Boss？

這比 AI 能不能自動做更重要。

---

第六個落差：責任歸屬不清楚

Demo 裡通常不用管責任。

正式系統不行。

如果 AI 發錯文，誰負責？
如果 Hermes 改錯檔，誰負責？
如果 ChatGPT 流程設計錯，誰負責？
如果 Boss 沒確認就發布，誰負責？
如果 API 成本暴增，誰負責？

這些都要分清楚。

後來我們把三方角色分成：

• ChatGPT：寫主文、做治理分析
• Hermes：寫自己的執行視角、做本機機械檢查
• Boss：審全文、下發行命令

這樣比較清楚。

Hermes 不審 ChatGPT 主文。
ChatGPT 不代替 Boss 批准。
Boss 保留最後發行權。

這不是形式。

這是在避免責任混亂。

---

正式上線前要問的問題

小企業如果想把 AI demo 變成正式系統，至少要先問這些問題：

資料

• 資料來源在哪裡？
• 哪份是正本？
• 哪些資料不能給 AI？
• 有沒有敏感資料？

權限

• AI 可以讀什麼？
• AI 可以寫什麼？
• AI 可以發布嗎？
• 誰能批准？

成本

• API 成本怎麼控？
• 有沒有任務上限？
• 有沒有停止條件？

失敗

• 出錯怎麼回滾？
• 有沒有測試紀錄？
• 誰負責處理？

人工接手

• 哪一步一定要人工確認？
• 哪一步不能全自動？
• 哪一步需要 Boss 命令？

這些問題沒回答前，不要急著上線。

---

小企業應該怎麼做？

最務實的做法是分階段。

第一階段：只做內容與流程整理

先讓 AI 幫忙：

• 寫文章
• 整理主題
• 做分類規劃
• 產生 SOP
• 建立檢查清單

這時候不給 AI 發布權限。

第二階段：半自動

AI 產出內容，人負責貼文和確認。

例如現在我們使用 GitHub 後台貼文。

ChatGPT 寫文章。
Boss 貼到 GitHub。
Cloudflare Pages 自動部署。
Boss 人工確認網址。

這樣很安全，也很快。

第三階段：受控自動化

等流程穩定後，再讓 AI agent 做本機檢查、build、git status、健康檢查。

但仍然不一定給它完整發布權。

第四階段：有限自動發布

只有在 gate 完整、回滾清楚、測試紀錄穩定後，才考慮讓 AI 在指定範圍內自動發布。

這才是比較安全的路線。

---

Demo 可以鼓勵，但不能當保證

Demo 的價值是讓人看到可能性。

它可以證明：

AI 也許能做。
流程也許能接。
工具也許有用。

但它不能證明：

正式環境一定穩。
成本一定可控。
權限一定安全。
資料一定正確。
使用者一定照流程走。
AI 一定不越界。

所以 demo 是開始，不是結束。

看完 demo 後，真正要做的是把它拆成：

• 資料需求
• 權限邊界
• 流程步驟
• 安全限制
• 測試紀錄
• 回滾方式
• 人工接手點

這樣 demo 才能走向正式系統。

---

結語：不要被 demo 成功騙了

AI demo 成功很重要。

但不要被 demo 成功騙了。

小企業導入 AI，最危險的不是 AI 完全不能用。

而是 AI 看起來很好用，於是太快被接進正式流程。

真正的問題常常在 demo 之外：

• 資料混亂
• 權限不清
• 成本失控
• 回滾不足
• 人工接手不明
• 責任分工模糊
• 測試紀錄缺失

所以不要問：

「這個 demo 能不能跑？」

要問：

這個流程能不能安全地每天跑？

如果答案還不清楚，就先不要全自動。

先整理資料。
先定義權限。
先建立測試。
先保留人工把關。
先把流程跑穩。

AI 很有用。

但 demo 成功，只是第一步。

正式系統要的是可控、可追溯、可回復。