我用 Claude Code 打造專屬的 AI Agent,讓它替我把分散的數據整理成儀表板、把重複的行政變成會自己跑的流程。
以下畫面為去識別化的示範版本,所有數字與內容均為示意,不含任何真實客戶或個人資料。
廣告成效在一個後台、訂單在另一個系統、任務在 Notion、行程在行事曆。每天光是把它們各自打開、抄下來、拼成一張能做決策的表,就去掉大半時間——而且抄完隔天又過期了。
用 Claude Code 打造專屬的 AI Agent:讓它自己去串接各系統的 API、把資料抓回來整理、算出我真正要看的指標,再產出成儀表板。該做什麼決策,變成畫面上直接看得到的一行,而不是腦袋裡要記的一件事。
能力(會做什麼)、流程(什麼時候做)、記憶(依據什麼判斷)分開放。這是維護成本能不能壓下來的關鍵。
部署走掛載式設定:核心資料夾集中一處、版本控管,換一台電腦拉下來跑一次掛載腳本再跑健檢就還原完成。從「重建一整天」變成 5 分鐘。
把廣告後台的花費、訂單、成效透過 API 拉進來,算成每天要盯的幾個關鍵數字,並依數據給出加碼/暫停/換素材的建議。

這張不是示意圖,是系統本人。做法是餵一份結構相同、內容全假的資料進去再截圖——所以版面、欄位、圖表都是真的,數字與名稱全部是合成的,畫面上也沒有任何馬賽克。
社群、廣告、銷售三邊的數字收在同一頁,每個數字旁邊都標明它的口徑與涵蓋範圍。

「本月全通路營收」後面特地標了資料來源與口徑。同一份報表裡「營收」可以指三件不同的事,不標清楚就會被拿去算出錯的結論。
接搜尋主控台與網站分析,看關鍵字機會與自然流量的實際貢獻,用來決定資源要往搜尋還是往廣告放。

這一頁的結論後來改變了預算配置:自然搜尋的單一訪客貢獻約是付費社群的 4 倍,所以資源往搜尋與品牌經營傾斜,而不是一路加廣告預算。
每天早上把行事曆、待辦、重點信件、待繳款整理成一頁——不用逐個 App 打開,一頁看完今天要面對什麼。

左上那塊「昨晚你給今天的自己」是前一晚寫下的三件事,隔天早上自動帶到這裡——把反思跟執行接成一個閉環,而不是兩份各自躺著的筆記。
還不能用的東西先自動化,只會放大錯誤。
這三件事比「我做了幾個模組」更值得寫。
自動排程一啟動就報「未登入」,但我自己在終端機跑同一個指令完全沒事。查下去才知道,是作業系統刻意把背景程序和使用者的鑰匙圈隔離開——這是安全設計,不是故障,所以沒有「修好」這個選項。
解法:改用可長期使用的授權 token。而且刻意挑了不會誤觸 API 計費的那一種——這個選擇有實際金額風險,我先把計費架構查證清楚才動手。
排程環境沒有人可以回答「要不要存檔?」,於是整趟就卡在那裡白跑。這種錯誤在手動測試時永遠不會出現,因為手動測試時我就坐在旁邊。
解法:做一次全鏈路模擬,抓出兩個只在自動環境才會發生的錯誤(一個停下來問存檔、一個自作主張改了檔名導致下游抓不到),然後寫成通則:給排程用的模組,輸出規格必須寫死三件事——直接寫檔、不要問、檔名前綴固定。
外部服務的授權每 7 天必定過期。我一度以為改某個設定就能根治,一週後被現實推翻。回去查官方規則才確認:以我的帳號類型,這個限制無解——要真的解掉,得走一套對個人來說不划算的驗證流程。
解法:不假裝它不存在,改成承認限制、降低痛感——寫一支一鍵重新授權的腳本,再讓監控程式在它失效時主動通知我該跑哪一支。
另外學到一件事:監控只看檔案更新時間會被騙,因為服務掛掉時檔案照樣被寫入。後來改成檢查內容裡的錯誤紀錄,才抓得到真的壞掉。
不是買現成工具,是自己用 AI 從零把它們串起來。
做專案最花時間的,往往不是決策本身,是「把散在各處的資訊收集、整理、對齊」的那段前置工。我做的,就是讓這段前置工自動化——把該做什麼變成畫面上看得到的一行,讓時間留給真正需要判斷的事。
這跟我做系統導入的內核是同一件事:把「靠人力硬撐」的流程,變成「系統會自己跑」的流程。差別只在,這次連建工具的人,都可以是 AI。