公司幾個星期前辦了一場為期一天的虛擬 AI Day，還要求我們能把手上工作放下的就先放下，儘量騰空參與當天的活動和講座，好好一起學習 AI。
對我這種平時就愛鑽研 AI 工程的工程師來說，這簡直就是個名正言順地「不務正業」的好機會。
大約一個月前，公司就開始邀請世界各地不同辦公室的同事提交示範素材，要求只有一個：
任何跟 AI 有關的都可以分享，但不能純空談 (吹水)，必須要有演示，而且最好是能讓觀眾跟著動手做的
活動開始 2 星期前就收到了 AI Day 的日程表，裏面列出了所有環節的內容簡介、時間、難易度，著我們把有興趣的主題加到自己的日程表中。
由於我自己有在學 AI 工程，自問對這領域有點基礎，於是我果斷省略了大部份入門級的課題，把日曆留給了幾個看起來比較「硬」的題目：
AI 使用的量化管理
AI 驅動的日誌分析
Claude Code
我想跟你聊聊我在聽完這 3 個環節後的想法，有些是技術上的，有些則是職場生存上的。
管理層的新玩具
第一個引起我注意的課題是母公司開發的 AI Hub，本來以為是所有已核准可使用的 AI 工具大集合 (然後我能從此平台找能「免費」試玩的 AI 工具)，但實際上是個 AI 工具使用率數據庫，美其名為 AI Hub，其實只是個監控平台。
它記錄了所有員工使用 AI 工具的情況，把頻率和次數轉換成積分。比如說，今天我跟 Gemini 聊了一會兒，得一分，用 GitHub Copilot 寫了幾行程式碼，得三分。
平台上每個人都能看到同組隊友的分數，而主管可以看到小組所有人的數據。
官方的說法是這叫遊戲化學習，鼓勵大家多把 AI 用在日常工作中。但我當時看著那個分數排名，心裏想的是卻另一件事：
管理層看到這些數據時，在想什麼？
雖然目前這只是個鼓勵性質的工具，而且公司一直沒要求我們使用 AI 工具，只是透過不同方式鼓勵我們多用。
但我們都明白，一旦數據被量化，它就很容易變成表現評核的參考指標。雖然沒直接說出來，但假如在平台上的分數不高，說不得自己已經默默地被貼上「不求進步」的標籤。
開發 Agent 的一個小瓶頸
接下來我選的課題是一個連接到 ServiceNow 平台的 AI 日誌分析技術分享。
能看的其實不多，整體上的設計和技術和我之前導入到 CI 的 Agent 差不多，不過有其中一個細節讓我有種「茅塞頓開」的感覺。
他們在處理海量日誌時，不會直接把所有日誌塞給模型做分析 (這等於在放火燒錢)，他們採用的其中一個方法是先餵一小部份日誌讓模型生成一個 Regex，然後利用此 Regex 去掃描剩餘的、值得關注的日誌片段。
這不禁令我回想起之前在設計 Agent 時，有時候會太依賴 LangGraph 流程圖帶來的確定性，反而規限了模型的能力。
我大可以在其中一個節點叫模型去生成程式碼，在下一個節點去執行它們。
(其實現在多人用的 Agent 都是這樣，只是習慣了從用家的角度去看，真正動手開發 Agent 時卻忘了這設計)
感覺就像你給了工匠一堆材料，但不是一昧叫他搬磚，而是告訴他先想辦法做一台小推車，然後再搬。
這種「動手生成工具再執行」的思路，比單純讓模型去讀文字要高效得多。
(關於這部分的技術細節，我之後也許會在 AI 開發筆記的系列中講得更多，這裏就不展開了)
聽了一會就跑了的課題
最後我上的是關於 Claude 的環節。
這原本是我最期待的，但聽了一半我忍不住退場了。
不是因為 Claude 本身不好，而是分享的方式太像在中學上課：
怎樣安裝 Claude？Fetch 指令是什麼？怎麼生成 Agent Team？
在這個資訊爆炸的年代，這些功能說明的教學網路上一抓一大堆，YouTube 上講得更好、更詳盡的多不勝數 (而且還能調 1.5-2 倍速)。
我更想聽的反而是使用 Claude 的心得，比如說 Claude 在什麼情況下會翻車？跟 GitHub Copilot 比它有什麼優缺點？
於是在聽了 30 分鐘後，實在忍不住按下了退出鍵，然後回去看另一小組怎樣用 Copilot SDK 開發一個個人專案管理系統的分享。
下一步
不知道是不是個別公司的情況，我看到自己公司裏使用 AI 工具的情況正在普及，大家開始熟悉怎樣用 AI，也慢慢將 AI 導入到日常工常流程之中。
不過，當要驗證 Agent、SKILL 的表現時，大家的評價還停留在：
結果看起來不錯 (The result looks promising)
我試過幾次，它給出的分析挺像樣的 (It handled a few cases I threw at it)
整體的氛圍對了，比原本手動處理快很多 (The vibe is right and it’s much faster than doing it manually)
雖然這些評價聽起來很振奮人心，但回頭一看，做出來的東西大部分其實都只是概念驗證 (POC)，要推到生產環境、或正式讓其他人用，實在沒什麼底氣。
歸根究底，是因為我們缺乏一套系統化的評估機制去驗證工具的表現。這也是我在學習 AI 工程時接觸不多的範疇 (因為感覺確實枯燥無味，就像軟體開發工程師不愛寫測試案例一樣)，但如果想要說服別人這是一套安全可靠的工具，最終還是得用數據說話。
所以我的下一步，就是考慮如何建立一套屬於我們的 Evals 系統。
職場小挑戰
AI 火了這麼久，我相信大家都見識過 AI 的實力，甚至已經動手做過一些 AI 小工具。
不過，當你看著自己或同事做出來的成果時，你有問過自己：
它的表現只是看起來很好嗎？
它的表現背後有一套數據或系統化的驗證方法支持嗎？
這次的挑戰，想請你在去 Google 或者是直接轉身去問 AI 之前，先給自己三分鐘，試試寫下 3 個你覺得可以用來評估一個 Agent 能力的方向。
不用急著去找教科書上的標準答案，純粹從你平時被 AI 坑過的經驗出發就好。當你開始試著寫出這 3 個方向時，你其實就在幫自己的工具跨出本地 POC 的第一步，準備去建構那套枯燥、但真正值錢的防禦工事了。