失誤：用手工無法發現的「隱藏模式」
上週我們的團隊看著 Google 試算表裡堆積的 2,000 筆訂單記錄，不禁思考「為什麼配送延遲總是在下午 3~5 點的訂單上發生？」用試算表的篩選和排序功能很難正確找出這個模式。數據量很大，但人眼的處理速度跟不上。
用 Claude Code 自動化時段別分析
1. 確認數據結構
首先整理了 Google 試算表中訂單數據的結構。
訂單ID | 訂單時間 | 配送完成時間 | 配送地區 | 是否延遲
001 | 2024-01-15 15:30 | 2024-01-16 09:00 | 首爾 | O
002 | 2024-01-15 16:45 | 2024-01-17 11:00 | 釜山 | O
003 | 2024-01-15 10:20 | 2024-01-15 18:30 | 首爾 | X
2. 撰寫 Claude Code 提示詞
在 Windows 環境的主要設備上打開 Claude Code，並給出以下指示。
請讀取 Google 試算表 CSV 檔案（orders_2024.csv）。
從訂單時間中提取小時時段（0~23），
計算各時段的平均配送延遲時間（小時）。
將結果保存為 time_delay_analysis.json。
3. 執行代碼並發現模式
執行 Claude Code 生成的腳本後，得到了以下結果。
{
"hourly_analysis": [
{"hour": 15, "avg_delay_hours": 28.5, "order_count": 145},
{"hour": 16, "avg_delay_hours": 26.3, "order_count": 152},
{"hour": 17, "avg_delay_hours": 24.8, "order_count": 138},
{"hour": 10, "avg_delay_hours": 4.2, "order_count": 180},
{"hour": 11, "avg_delay_hours": 3.8, "order_count": 172}
]
}
驚人的是，下午 3~5 點的訂單比上午訂單的延遲時間平均多出 20 小時以上。
4. 查找根源並採取行動
用這份數據與實際的配送團隊溝通後才發現，下午 3 點以後的訂單會轉到隔日提取系統。這是用手工作業很容易被忽略的「系統結構上的差異」。
5. 設置自動化重複
現在已在 Windows 設備的工作排程器（Task Scheduler）中註冊了 Python 腳本，使其每週一早上自動執行此分析。
import schedule
import time
def run_analysis():
# 調用由 Claude Code 生成的分析函數
analyze_orders_by_hour()
print("分析完成：時段別配送延遲模式已更新")
schedule.every().monday.at("08:00").do(run_analysis)
while True:
schedule.run_pending()
time.sleep(60)
核心心得
1. **數據量越大，隱藏的模式越容易存在。** 用手工作業絕對無法發現。
2. **Claude Code 在分析前，數據結構的定義最為重要。** 正確的 CSV 或 JSON 格式是必需的。
3. **發現後的動作才是最關鍵。** 找到模式後，必須與實際業務問題的解決相連結，才有實質意義。
非開發者團隊也能按照這 5 個步驟，發現自己的「隱藏數據模式」。