上一篇文章，剛好寫到和我名字一樣的第二十六篇，也談了一個很實際的問題：如果微光每件事都要等我親自處理，能夠持續照顧的範圍就會有限。

除了人的心力，還有另一種需要分配的資源。

AI 角色要回應，需要模型處理；整理資料、執行工具與保存紀錄，也需要運算和儲存。功能越多、互動越頻繁，這些使用就會慢慢累積。

因此，我不能只問「這件事能不能讓 AI 做」，還要問：值得讓它用什麼方式做？

這篇先整理我看待時間與費用的方向，不列出尚未核對的實際帳單，也不把某種模型選擇說成已經適用於微光的所有角色。

角色多，不代表每個角色都需要一整套獨立系統
前面談到角色分工時，我希望不同角色能在日常裡形成自己的位置。

但角色上的獨立，不一定要對應到完全獨立的底層服務。

名字、語氣與職責可以不同，背後仍然可能使用同一個模型服務，或共用查詢規則、帳務處理與資料整理的能力。需要隔離的記憶、權限和身分，則另外維持清楚界線。

因此，我想把「成員遇見幾位角色」和「背後需要維護幾套系統」分開考慮。

這樣在增加角色時，才不會習慣性地把所有東西再複製一份。真正需要不同的地方保留差異，能共用的部分則減少重複維護。

有些事情，不需要模型重新想一次
如果有人查詢自己的金幣餘額，數字應該來自帳戶資料，不需要 AI 推測。

如果一項任務有明確的截止時間，也可以直接查出目前規則，再決定是否需要角色補充說明。

這類事情可以先用程式取得確定的結果。需要自然語言解釋、整理或對話時，再讓模型參與。

我不想因為角色是 AI，就讓每個按鈕、每次查詢都經過一次生成。

有些結果用清楚的固定格式呈現，反而更快，也更不容易讓人誤會。若確實需要角色口吻，可以把已確認的結果交給模型表達，但不能讓表達改變原本的數字與條件。

先分清楚哪些步驟需要推理，哪些只是讀取與驗證，比直接挑一個便宜模型套在所有地方，更值得先做。

不同工作，可以有不同的模型需求
有些對話需要理解較長的背景，有些只需要整理一小段文字。創作一段角色互動，和判斷必填欄位是否齊全，也不是同一種工作。

因此，我不一定要讓所有事情使用相同的模型。

但也不能只看價格，把便宜的安排給所有「看起來很簡單」的工作。

有些輸入很短，後果卻很重要。例如，一個是否符合資格的判斷，可能影響成員能不能領取獎勵。它不會因為只需要回覆幾個字，就自動變成低風險工作。

我想依照實際需求，確認模型能不能理解常見情境、遇到不確定時會怎麼處理，以及需要哪些程式檢查。

品質符合要求之後，再比較費用與速度。不能因為換用較低成本的模型，就順便降低原本答應使用者的標準。

便宜一次，不一定代表整件事比較省
模型單次呼叫的費用，只是成本的一部分。

如果第一次回答沒有抓到重點，成員需要再解釋一次；第二次仍然不正確，可能最後還要由我查資料、重新處理。

帳單上的單次價格比較低，整件事花掉的時間卻可能更多。

因此，我比較想看完成一件事需要多少投入。

包含呼叫次數、等待時間、重試，以及後續人工確認。有些工作值得使用表現較好的模型，因為少一輪誤解，就可能讓流程順利很多。

反過來，若簡單工作用較輕量的方式已經能穩定完成，也不必為了統一而全部使用同樣昂貴的處理方式。

這需要用實際工作來比較，不能只從模型介紹推定。

不是每次回應，都要帶上整段歷史
角色要理解背景，通常需要把相關內容提供給模型。

但如果每次說話，都附上整段聊天、完整世界觀與所有功能介紹，處理的資料就會越來越多。費用與等待時間可能增加，不相關的內容也可能讓回答偏離重點。

我希望每次提供的是當下用得到的背景。

成員在問某個任務，就查那個任務目前的規則。接續作品討論，就帶上相關進度，不必同時加入所有角色故事。

這和第十四篇的記憶設計也有關。留下哪些資訊，以及什麼時候使用，都會影響成本與回答品質。

不過，縮短內容也不能只追求字數少。若摘要把必要條件刪掉，模型反而更容易誤判。需要保留原文時，也應該能回到來源確認。

省下背景，不應該省掉判斷所需的依據。

有些等待，其實可以換一種安排
成員正在和角色聊天時，回應速度會直接影響感受。如果每一句都等很久，對話就容易中斷。

但整理活動回顧、彙整一段期間的資料，通常不需要在每一則訊息出現時立即執行。

這些工作可以依照需求集中處理，避免同樣的內容被反覆整理。前提是把時效說清楚，不讓人以為看到的是即時結果。

需要等待的工作，也應該先確認收到，提供能查詢的狀態，而不是讓畫面長時間沒有反應。

我想把即時回應留給真的需要即時的事情。其他工作則使用適合的節奏，減少不必要的呼叫，也避免所有工作同時搶著使用資源。

設上限，是為了讓服務可以持續
如果完全沒有使用界線，一段意外的重試、一個不斷觸發的流程，就可能持續消耗資源。

所以，我認為系統需要有明確的限制。例如，單次工作最多嘗試到哪裡、多久沒有結果就停止，以及什麼情況需要由人確認才能繼續。

這些限制不只是為了控制費用，也能避免出錯之後一直重複做同一件事。

對成員有影響的使用限制，則需要另外說清楚。不能讓人投入到一半，才突然發現有一個從未說明的門檻。

達到上限時，也不能偷偷換成未經確認的處理方式，卻繼續聲稱結果和原本一樣可靠。可以延後、縮小可執行的範圍，或停止並說明，但仍然需要保留原本的重要界線。

觀察使用，不等於保存所有聊天
要知道資源花在哪裡，需要有一些使用紀錄。

例如，哪一類功能呼叫較多、通常要等多久、失敗後是否經常重試，以及一次工作最後有沒有完成。

這些資訊能幫助我找到真正需要改善的部分。

但為了看成本，不一定需要把每段私人對話都收進統計。很多情況下，功能類型、用量、時間與結果狀態，就足以先看出問題。

如果發現某個流程費用突然增加，我想先查它是不是重複處理、帶入太多資料，或卡在重試，而不是先判定某位成員使用太多。

使用紀錄應該幫助我維護系統，不是讓大家因為擔心被檢視，就不敢正常使用。

我想省下的是浪費，不是值得發生的互動
討論費用，很容易最後只剩下怎麼減少呼叫、縮短回答，以及限制使用。

但如果一位成員真的透過角色理解了問題，或因為某次互動開始分享自己的作品，那也可能正是我願意投入資源的地方。

我不想讓角色為了省一點處理，就把原本需要耐心的解釋變得敷衍。也不想讓成員每次開口，都覺得自己正在增加負擔。

需要調整的，是背後不必要的重複、錯誤的安排，以及沒有帶來幫助的工作。

當這些部分處理得比較好，就能把資源留給真正值得的互動。

對我來說，控制時間與費用，是讓微光可以持續的一部分。

我希望自己知道資源花在哪裡，也能說明為什麼願意花在那裡。這樣，下一次想增加一位角色或一項功能時，就不只是在問能不能做。

也能進一步問：做了之後，我是不是有能力繼續把它照顧好？