能用腳本解決的事就別叫模型加班
看到 r/openclaw 週榜那篇，拿 12 年前的 i5-4460S 跑 Telegram bot，信件用 Python 加 IMAP 先濾，圖片 PDF 丟 Tesseract，語音用本機 Piper，整套居然可以把 API 帳單壓到接近 0，老電腦突然變成省錢神器 XD
我覺得重點不在老 PC 多會撐，重點是很多人把 LLM 放在流程最前面，叫它每 5 分鐘重新理解一次世界，然後再花 token 做早就有規則可判斷的事，這不就是請諸葛亮每天幫你分垃圾信嗎 www
我現在會先問三個問題
第一，輸入和輸出能不能用明確規則描述，像寄件者黑名單、HTML 轉純文字、檔案副檔名、音檔轉 wav，答案如果大部分時間都固定，先寫 script
第二，錯一次的代價高不高，垃圾信誤刪可能還好，發錯信、刪掉發票、把客戶的 PDF OCR 成亂碼就麻煩，這種就要保留人工確認，或讓 LLM 只做最後判斷
第三，模型到底需要哪一段上下文，常見做法是整封信連簽名檔、追蹤碼、HTML 樣式一起塞進去，模型先花力氣清垃圾，真正要回答的內容反而被埋掉，先 preprocess 再送，通常比換更大的模型划算
一個比較實際的流程大概長這樣
IMAP 收信 → 過濾寄件者與附件 → HTML 轉純文字 → 去重
有效內容才交給 LLM → 需要時才通知
我會先拿最近 100 封信做 dry run，不直接刪，記錄規則判斷和人工判斷的差異，漏掉一封重要信就回頭調 whitelist，連續幾輪誤判率壓到能接受再開自動動作。OCR 也一樣，純文字文件可以全自動，表格和手寫字就先標成待確認。那篇提到 Tesseract 約 3 秒完成，我覺得這種數字比模型回覆快不快更值得看，因為本機處理還少一個網路和服務商故障點
當然也別走到另一個極端，規則寫到最後變成一千行沒人敢改的怪物，遇到語意模糊、需要跨文件推理、或使用者真的在問開放問題，LLM 就該上場。我的分工原則很土，能測試、能重跑、能用同一份輸入得到同一份輸出的，先交給腳本，只有需要猜意思的地方才花 token
Agent 不一定要更聰明，很多時候只是要少做幾件蠢事而已，這句我先卡位 XD
作者：島民No.9527