這六期都建立在同一套 AI CRM 上——如果你想從頭把它做出來，而不只是讀懂它：

《AI 賦能全端開發：從零打造企業級智慧應用》：從 Spring Boot 後端、React 前端到資料庫與權限，一路加上 Spring AI、RAG 與 AI Agent，用一個專案走完整條路。

🎁 課程最後額外加碼「Cloudflare Tunnel 穿透實戰」：教你如何在免固定 IP、不開路由器 Port 的安全前提下，把公司內部或本機架設好的全套系統安全穿透到公網，讓外部客戶、主管或團隊直接連線體驗！

主題一｜事件即 Agent 的稽核軌跡

這是 EVENT 系列的最後一期。

前五期把事件的路鋪完了：解耦、非同步、送得出去、收得下來、回得了前端。系統現在跑得又快又穩。

然後客戶問了一句話：

「這份摘要是怎麼來的？」

你打開資料庫，看到 summary 欄位裡躺著一段文字。你知道它是 AI 產生的。除此之外，什麼都不知道。

三個你回答不出來的問題

它讀了什麼？ 摘要說「客戶近期互動頻率下降」——它是根據哪幾筆互動紀錄講的？如果那幾筆資料本身有問題，這句結論就是錯的，但你查不到它讀了哪幾筆。

它花了多少錢？ 這個月 LLM 帳單三萬塊。哪些功能花的？哪個客戶的操作最貴？有沒有哪個迴圈在默默重跑？帳單只給你一個總數。

為什麼這次跟上次不一樣？ 同一個客戶，上週的摘要說「關係穩定」，這週說「有流失風險」。是資料真的變了，還是你上週改了 system prompt？你想不起來，也查不出來。

三個問題有一個共通點：它們問的都是「過程」，但你只留下了「結果」。

回想 012 到 015 那個系列的主軸：不要滿足於 AI 給你一句話，要求它交出可以被審查的產物——可行性評估報告、選型分析、測試、稽核表。

那些都是在講「你怎麼要求 AI」。

現在把鏡頭轉過來：你的 Agent 每天自動跑幾千次，它自己交出了什麼可以被審查的東西？

答案通常是：一個結果欄位。跟「這個功能能不能做？」換來的那句「可以做」，本質上是同一種東西——沒得追蹤、沒得反駁、沒得改。

而修補的方法，跟前面五期一直在做的事情是同一招：把過程記成事件。