問題的開始：追蹤號碼進來了，整理卻是手工作業
B2B 業務中，每天有數十個追蹤號碼抵達。原本的方式是在 Google 試算表中手動貼上，檢查配送狀態，然後用彩色標記筆塗色。
「每天重複同樣的工作，AI 做不了嗎？」
這個想法成了起點。
Claude Code 的初次相遇：超越 OCR
最初很簡單。從 PDF 追蹤號碼影像中提取數字就好。Claude Code 接收圖像，數字跳出來了。認為這是成功。
但下一個問題不同了。
「這個號碼能自動判斷是配送中還是已送達嗎？」
Claude Code 提出了有趣的建議。不需要追蹤 API，而是利用試算表的條件式格式(Conditional Formatting)，根據號碼長度、發行日期模式、數字範圍，自動以顏色標示「預期狀態」。
「這是...魔法嗎？」
實際執行：不是 30 分鐘，而是 2 小時
最初計畫是 30 分鐘。複製貼上代碼就可以了。
現實不同。
第一個錯誤：本機 Windows 環境與 Google 試算表 API 連接的權限問題。
第二個錯誤：條件式格式規則過於複雜，試算表開始卡頓。
第三個錯誤(成功)：告訴 Claude Code「太笨重了，簡化一下」，AI 將規則從 30 個縮減到 5 個。速度恢復了。
2 小時後，追蹤號碼清單變成了這樣。
紅色 = 配送預定
黃色 = 配送中
綠色 = 配送完成
灰色 = 異常數據
意外發現：AI「學會了」錯誤
有趣的事發生了。
第 3 天，號碼中出現異常模式。通常追蹤號碼是 13~15 位，但有一個 14 位的號碼一直被標為黃色(配送中)。人類會認為「可能是錯誤」。
Claude Code 不同。追蹤那個號碼，發現實際是配送公司系統更新延遲。AI 設定的規則打破了人類的刻板印象(「14 位 = 錯誤」)。
隔天調整了自動化規則。3 週後，著色準確率達到 96%。
更大的變化：夢幻團隊機器人的協作
原本一個人的自動化現在擴展到多個代理。
• 第一個機器人：提取號碼
• 第二個機器人：預測配送狀態並著色
• 第三個機器人：標記異常數據
• 第四個機器人：自動生成週報
有趣的是這些機器人開始互相「對話」。一個機器人標記的數據被另一個接收並重新驗證，結果記錄在試算表中。非開發者的團隊領導只需每天早上查看結果。
結論：自動化的下一個階段
最初認為「只需提取追蹤號碼」。
現在不同了。
自動化進化經過 3 個階段。
1 階段：消除重複工作(提取號碼)
2 階段：自動化判斷標準(著色)
3 階段：模式學習與例外處理(96% 準確度)
Claude Code 與 Windows 環境的組合創造的不是簡單的「節省時間」。它是讓小團隊像大團隊一樣運作的可能性。
下一個實驗？讓語音輸入添加追蹤號碼。非開發者完全可以做到。