你的 AI 助理每天早上花 4 分鐘幫你巡檢，聽起來很貼心——直到你發現它用了 15% 的月額度，只為了做「檔案有沒有變」這種機器就能判斷的事。

Situation｜情境：每天早上，AI 在幫你做小學數學

你是一人公司的老闆。你買了 AI 助理課程，學會了讓 Agent 幫你管理專案。每天早上你對它說「開工」，它就開始幫你巡檢：讀 Git 狀態、掃描任務檔、比對規則有沒有改、檢查通知有沒有逾期。

聽起來很智慧，對吧？

直到有一天你打開用量儀表板，發現光是「開工」這個動作，每天就吃掉你 15% 的 API 額度。你一個月花在 AI 上的錢，有將近五分之一只是在問：「檔案變了沒？」

更讓你心寒的是，你發現這 15% 的消耗幾乎全部來自「讀檔案」和「比對差異」。AI 真正用來幫你思考、判斷、做決策的額度，反而被擠壓到所剩無幾。這就好像你請了一位時薪三千的策略顧問，結果他每天早上前兩個小時都在幫你掃描辦公室有沒有灰塵。

Task｜任務：你要的是效率，不是一個很會讀檔案的機器人

問題很明確：巡檢是機械活，但你正在用最貴的工具做它。

LLM（大型語言模型）擅長的是閱讀理解、判斷、決策。但「這個檔案上次的 hash 是多少，跟現在一樣不一樣」——這是 md5sum 一行指令就能做的事。讓 GPT-4 或 Claude 去做這種比較，就像請一位時薪三千的顧問幫你算 Excel 加總。

你需要的不是更聰明的 AI，而是把機械活還給機器。

這裡有個關鍵的認知翻轉：多數人以為「AI 能做的越多越好」，但實際上，AI 做得越多，它用來「真正思考」的空間就越少。每一次它花 token 去讀取一個檔案、比對一段 hash、掃描一則通知，都是在消耗它最寶貴的資源——context window。當 context 裡塞滿了原始檔案內容，真正需要深度思考的任務反而被邊緣化了。

你要做的不是讓 AI 更努力地讀檔案，而是讓它讀的每一個字都有價值。

Action｜行動：三刀下去，開工流程重寫

第一刀：寫一個 Bash 腳本取代 LLM 巡檢

start-work.sh——一個 100 多行的 Bash 腳本，做以下機械檢查：

  • git fetch 檢查遠端同步
  • git status 抓未提交變更
  • git log -n 3 看最近 commit
  • 檔案 hash 比對（md5sum）偵測規則檔變動
  • find + 時間戳掃描逾期任務
  • grep 篩選超過 48 小時的舊通知

這些操作零 LLM 呼叫。腳本跑完直接輸出結構化摘要，人類或 AI 一眼就能掃完。

這一步的核心洞察是：這些操作中的每一個，都有對應的 Unix 工具可以完成，而且速度比 LLM 快幾個數量級。git status 的輸出就是機器 readable 的結構化資料，根本不需要一個語言模型來「理解」它。把這些從 LLM 手裡拿走，等於是在每次開工時幫你省下了大量無意義的 token 消耗。

第二刀：規則檔加版本戳，有變才讀

以前每次開工，AI 都要重新讀 4 份規則檔（團隊共識、通訊協議、ROADMAP、AGENTS）。每份規則檔都不短，加起來的 token 消耗相當可觀。

改成：每份規則檔底部加一個 hash 戳（類似 <!-- hash: abc123 -->），腳本比對上次的 hash。沒變就不讀。這一個小改動，讓 AI 開工時的規則檔讀取量從「每次都全讀」變成「有變才讀」，重複閱讀的 token 消耗大幅下降。

這招的精髓在於：你不是在「減少」AI 的工作，而是在「消除不必要的重複」。規則檔在兩次開工之間通常不會變動，但每次都要重新讀一遍，等於是在做完全相同的功課。加上版本戳之後，腳本用幾毫秒就能判斷「有沒有變」，有變才把檔案丟給 AI，沒變就跳過。這是典型的「機械判斷先行，語言模型善後」的模式。

第三刀：通知歸檔從 7 天改 48 小時

團隊專區的通知區會膨脹。原本 7 天才歸檔一次，結果板頭從 18KB 膨脹到 56.5KB——AI 每次讀板頭就要吃更多 token。

改成 48 小時歸檔，板頭穩定在 18.8KB 左右。不是減肥，是控制進食量。

這一步教會我們一個重要的觀念：資料量的控制不是一次性的工作，而是需要設定一個「持續機制」。如果你只是偶爾手動清理一次，板頭很快就會再次膨脹。但如果你把歸檔週期從 7 天縮短到 48 小時，板頭就會維持在一個穩定的體積範圍內。這就像房間的整理——每天花兩分鐘把東西歸位，比每個月大掃除一次更有效率，也更省力。

Result｜結果：數字說話

指標改善前改善後變化
開工耗時~4 分鐘~1 分鐘大幅縮短
LLM 額度消耗~15% / 次近零額度幾乎全額回收
板頭體積56.5KB18.8KB穩定控制

一個月省下的額度，夠你多跑好幾次完整的專案討論。更重要的是，你的 AI 助理終於把 context window 留給了真正需要它的任務：閱讀你丟給它的文件、分析專案的現況、幫你做出下一步的判斷。

Teach｜教訓：機械活下放，判斷留給模型

這件事的核心教訓只有一句話：

「有沒有變」是機械問題，「變了怎麼辦」才是 AI 的價值。

md5sum 比對、時間戳計算、grep 篩選——這些是 Python/Bash 的主場。LLM 懂的是「這三個任務都逾期了，根據優先序應該先處理哪一個」。把前者從 LLM 手裡拿走，後者才有空間發揮。

很多人用 AI 的方式是「把所有東西都丟給它」。但最高效的方式是：讓適合的工具做適合的事。腳本做機械，模型做判斷，人類做決策。

這個觀念其實不只適用於開工流程。你生活中的很多自動化場景都可以用同樣的邏輯去思考：這件事的核心是「判斷」還是「機械執行」？如果是機械執行，有沒有更便宜、更快的工具可以做？把判斷留給 AI，把執行交給腳本，這才是人機協作的正確分工。

Apply｜應用：你可以明天就做的事

如果你也有自己的 AI 助理（不管是 Claude、ChatGPT、還是自建的 Agent），試試這個測試：

  • 記錄你的 AI 每天花多少時間在「巡檢」上（讀檔案、比對狀態、掃描變動）
  • 把這些機械動作寫成腳本（哪怕只是幾行 shell）
  • 讓 AI 只接收腳本的輸出結果，而不是自己從頭掃一遍

你會發現，AI 的回應品質反而更好——因為它的 context window 裡裝的是「有意義的摘要」，而不是「原始的檔案內容」。

更進一步，你可以把這個邏輯延伸到其他日常工作：每天早上收到的 Email 摘要、每天要查的數據報表、每週要跑的專案進度檢查——凡是「重複性高、規則明確」的工作，都適合先用腳本處理，再把結果餵給 AI 做後續的分析和決策。

Reflect｜反思：效率的假象

我們很容易掉進一個陷阱：看到 AI 在動，就覺得它在做事。

它讀了 10 個檔案、比對了 hash、掃描了大量通知——看起來很忙。但這些都是「假動作」。真正有價值的那個判斷（「根據優先序，今天應該先處理 X」），可能只佔了極小部分的 token 消耗。

效率不是「讓 AI 做更多事」，而是「讓 AI 只做它該做的事」。

這讓我想到一個更根本的問題：我們對「效率」的定義是什麼？很多人以為效率是「在更短的時間內做更多的事」，但真正的效率是「把有限的資源用在最有價值的地方」。對 AI 助理來說，最有價值的資源就是它的 context window 和 API 額度。如果你把這些資源花在機械檢查上，那你就是在用最貴的工具做最便宜的事。

Connect｜連結：這只是起點

這個優化是我們團隊「一人公司 + AI Agent」運作模式的一小步。我們持續在探索：怎麼讓 AI 真正成為生產力工具，而不是另一個需要管理的雜務來源。

如果你對「AI Agent 團隊協作」「一人公司自動化」有興趣，我們正在把這些實戰經驗整理成系統化的課程。不是教你怎麼用 ChatGPT，而是教你怎麼建立一個能自己跑的 AI 團隊。

本文數據來自真實專案運作記錄。所有內部資訊已去敏處理。