先把核心想法說清楚
這個案例不是把原本的通知文字交給 AI 重寫。它改變的是系統如何發現問題、如何學習，以及如何把學到的做法變成下一版能力。
還不知道怎麼做
AI 整理資料、提出假設、解釋異常，幫助團隊看懂問題。
已經知道怎麼做
把穩定的算法、規則與限制做成可重播、可共用的工具。
繼續找下一題
AI 觀察人工修改與結果偏差，提出下一個改善候選。
為什麼「庫存低於 80 就通知」不夠？
固定門檻沒有錯。它簡單、穩定，而且很好測試。問題是它只能回答現在的庫存，不能完整回答未來的壓力。
- 最近銷售是不是正在加速？
- 去年同一時間是否特別熱賣？
- 下週是否有促銷或大型訂單？
- 供應商實際交期是否正在變長？
- 在途庫存是否真的會準時到？
- 人員為什麼經常修改系統建議？
商品 A：現在安全，不代表十天後安全
這些是方便說明的合成數字，不是補貨政策。重點是看同一筆資料如何因為加入時間與脈絡而得到不同判斷。
| 資料 | 示例值 | 它告訴我們什麼 |
|---|---|---|
| 現有庫存 | 120 件 | 高於固定安全庫存 80，所以舊系統不通知。 |
| 最近七日銷售 | 10 件／日 | 如果速度不變，大約可支持 12 天。 |
| 供應商交期 | 10 天 | 現在才採購，緩衝已經很小。 |
| 去年同期銷售 | 18 件／日 | 可能有季節性需求，但仍需驗證。 |
| 在途庫存 | 50 件 | 必須確認到貨時間與資料新鮮度。 |
| 下週促銷 | 有 | 可能提高需求，但影響大小尚未被證明。 |
真正的自我進化來自兩條迴路
一條讓每天的工作穩定運作；另一條從每天的工作中找出下一版能力。兩條缺一不可。
把今天的補貨工作做好
- 排程取得允許使用的資料。
- 工具計算風險與預測。
- AI 整理脈絡並解釋例外。
- 產生建議與進貨單草稿。
- 人類接受、修改或拒絕。
- 未來只有 access 與 control evidence 完整後，受控系統才可提交正式訂單。
把明天的系統做得更好
- 保存建議、修改與結果。
- AI 找出重複模式和缺口。
- 提出新的規則或工具候選。
- 在重播或 shadow 中比較。
- 負責人接受，團隊實作發布。
- AI 使用新工具，繼續觀察。
AI 很重要，但不是每件事都交給 AI
最好的系統會把工作交給最適合的角色。這讓結果更穩，也讓 AI 有空間處理真正未知的部分。
目前 AI 還不能被正式選定
能力不是一次完成，而是一層一層長大
固定安全庫存通知
可靠但被動，只在越過固定門檻後提醒。
AI 輔助探索
組合銷售、促銷、在途與交期，產生可解釋建議。
人類核准的草稿
AI 準備進貨單草稿，人類接受、修改或拒絕。
穩定方法工具化
把反覆被證明有效的計算與限制寫成共享工具。
AI 查漏補缺
使用工具處理日常工作，並尋找工具未涵蓋的新例外。
受治理的持續演進
每次能力提升都有證據、owner、版本、測試、發布與回復。
什麼時候可以把 AI 做法寫成正式工具？
不能因為 AI 做對一次就立刻固化。候選方法必須經過一個簡單但嚴格的提升檢查。
重複出現
同一種人工修改或例外在足夠多次決策中出現。
說得清楚
輸入、輸出、來源、owner 與失敗行為可以被定義。
可以重播
新方法能在相同資料上和舊方法公平比較。
涵蓋例外
正常、邊界、缺資料和衝突案例都有測試。
有人負責
政策或流程負責人接受它，不是 AI 自己宣布正確。
可以安全發布
有版本、監控、回復與退役方式。
可能沉澱出的共享工具
forecastDemand()、estimateSupplierLeadTime()、assessInventoryPressure()、recommendReplenishment()、preparePurchaseOrderDraft()
Dashboard、AI 與 workflow 應使用同一套工具與定義，不再各自算出不同答案。
第一個可落地切片：先證明非 AI baseline
選擇 10–30 個商品，先用安全庫存、庫存覆蓋天數與已接受的交期規則建立每日唯讀清單，同時保存人員判斷與修改理由。
- 允許使用的唯讀 snapshot
- 資料品質與新鮮度檢查
- 可重播的非 AI baseline
- 人工接受、修改、拒絕與理由
- 不提交的進貨單草稿
- 自動核准或提交進貨單
- 一次涵蓋所有商品與供應商
- AI 綜整與解釋實驗
- AI 自己發布規則或程式
- 未被證明的採購系統權限
- 把示例數字當成正式政策
如何知道這不只是一個漂亮 Demo？
真正的價值必須在相同條件下比較，而且必須看人類為什麼修改，而不只看 AI 有沒有產生答案。
自我進化不等於 AI 自己改正式系統
AI 不可以自行做的事
- 核准自己的補貨建議或進貨單。
- 新增供應商或變更付款條件。
- 在缺少企業政策時偷偷補出規則。
- 直接修改或發布正式程式、模型與語意定義。
- 跳過權限、稽核、冪等與失敗復原控制。
正確的演進順序是：AI 提議 → 證據驗證 → 負責人接受 → 開發與測試 → 版本發布 → 監控與回復。
下一個負責行動
由真實補貨流程負責人召集補貨人員、資料 owner 與 FDE delivery owner，選定 10–30 個商品，確認現況流程、來源權限、人工修改原因與四週 shadow 的接受門檻。
完成條件：流程負責人接受技術中立的目標流程；必要資料與權限有直接證據；交付團隊能重播第一個唯讀 shadow 工作包。
詳細內容請閱讀 操作方案提案；案例資料契約見 scenario.json。