AI

兩種帳單，兩種形狀 主機帳單是容量。你加 CPU、頻寬、儲存，指針跟著流量曲線走；看過一個月，下個月能猜到幾個百分點以內的誤差。 token 帳單是行為。兩個流量完全一樣的團隊，帳單可以差 20 倍——因為一個團隊每次請求帶 12,000 token 的檢索上下文，另一個只快取了 400 token 的系統提示、其餘什麼都不帶。同樣的使用者、同樣的功能，帳單天差地遠。 這不是定價的貓膩，而是計量方式決定的：你按 token 付費，而 token 數量是設計決策。 讓花費變跳的三個效應 1. 輸入通常遠多於輸出，兩者單價還不一樣。 在多數對話與檢索功能裡，輸入 token 是輸出的 5～20 倍，而輸出 token 的單價往往是輸入的幾倍。所以「我們只生成一小段回答」這句話，對成本沒有任何說明力。 2. 快取輸入是另一套費率。 供應商對重複出現的輸入給更便宜的價格——固定的系統提示、不變的長文件、大段指令。忽略快取，就等於每次請求都為同樣的 3,000 token 付全額。 3. 每次請求的上下文能差一個數量級。 一個每輪都追加對話歷史的摘要任務，等於每次都把整份紀錄重新送一遍。成本成長比輪數更快：第 20 輪很貴，是因為第 1 到 19 輪又在帳單上出現了一次。 重試與工具呼叫還會再加一個在任何用量圖表裡都看不見的乘數：一次失敗後重試的呼叫會計費兩次；每輪呼叫四個工具的 Agent，每輪計費五次。 槓桿，按收益排序 團隊的第一反應通常是去換模型。那很少是最大的槓桿。建議按這個順序試： 先砍上下文。 刪掉檢索到卻不影響答案的文件、限制回溯的歷史長度、把永遠不變的部分放進快取。這往往是單項收益最大的一步。 限制輸出長度。 直接要求形狀（「三條要點，不要前言」），而不是給一個寬鬆的 token 上限。模型生成的那 900 token 客套話，是你在付費。 不緊急的走批次。 夜間補數、回填、評測這類任務通常可以接受更慢但更便宜的路徑。 最後才換模型。 把摘要任務降級到更小的模型確實是省錢——但這是在前面三步已經壓小的那個數字上，再省一次。 上線前先估一遍 你需要每次請求的兩個數字：輸入 token 與輸出 token。功能已經上線，就直接從 API 回傳值讀，不要估。還沒上線，只能先猜： 每月成本 ≈ 每天請求數 × 30 × (輸入 ÷ 1M × 輸入單價 + 輸出 ÷ 1M × 輸出單價) 猜的時候有兩個坑：一是平均數會掩蓋最貴的那次請求（一份長文件的 p95 請求可能是中位數的 30 倍，而帳單正是它決定的）；二是多輪功能讓平均數失去意義，因為每一輪都拖著完整歷史。 ...

這是協作問題，不是技術問題 這個場景在各個團隊反覆上演：有人打開了 Agent，看著它做事，然後某一天發現唯讀開關不見了，或者在你還在看第一個 diff 的時候它還繼續在改。一小時後分支上有四十個改動，一半跟任務無關，沒人說得清 src/legacy/ 為什麼被動過。 接下來的抱怨總是同一句：我已經不認識這份程式碼了。 嚴格說，這不是 Agent 的 bug，而是一條從來沒被寫下來的規則，正在被一次次事故發現。 寫一段更長的提示詞沒有用 第一反應通常是寫更長的 prompt：「不要改無關檔案、不要刪測試、不要動部署設定」。它能撐過這個 session，然後就消失了。 提示詞是「每個 session、每個人」的；放在專案裡的檔案會被每一次 session、每一位同事、每一個你換用的 Agent 讀到——更關鍵的是，它可以像程式碼一樣被審查。團隊只需要在一個 PR 裡吵一次，而不是每次被 Agent 嚇到才吵。 四道護欄，按收益順序 1. 規則檔。 AGENTS.md（或 CLAUDE.md，或你的 Agent 從專案根目錄讀取的那個檔案）定義什麼叫「做完」：哪些指令才算驗證、哪些路徑不能碰、哪些事絕對不能自作主張。短到人也會願意讀。 2. 權限清單。 三份清單，結構比語法重要： 清單 放什麼 例子 allow 唯讀操作，加上專案本來就會跑的 test / lint / build Bash(pnpm test:*) ask 會改寫歷史、安裝套件、連網的行為 Bash(git push:*) deny 機密檔案、正式環境設定、部署流程、破壞性指令 Read(./.env) 沒有列到的一律回到「問人」。真正要避免的失敗模式是：權限寬到沒有人願意讀。 3. 保護路徑。 機密檔案、正式環境設定、資料庫 migration、CI 定義都要被明確點名，規則檔與 .gitignore 裡各寫一份。這一步把「判斷題」變成「機械檢查」——而只有機械檢查能扛得住截止日期。 4. 合併前的審查清單。 護欄判斷不了設計好壞，所以清單負責補位：diff 是不是超出這個任務該有的規模、有沒有刪掉或放寬測試、有沒有把錯誤悄悄吞掉、總結裡的數字是否都能對應到某次指令輸出。 護欄產生器 可以用一份短表單產出上面這四份檔案——指令、允許路徑、保護路徑、要強制的規則——並且跟著頁面語言切換中英文。 護欄做不到什麼 把邊界講清楚比誇大宣傳重要，因為誇大最容易讓團隊信錯東西： ...

一種沒人及時發現的失誤 請 AI 總結一條 CI pipeline，你會得到一段很整齊的話：lint 階段 42 秒、build 3.5 分鐘、整條 pipeline 16.4 分鐘、比上週快 18%。讀起來像一份報告。兩小時後才有人發現 build 從來沒花過 3.5 分鐘，而失敗率是從另一週抄來的。 這段話看起來沒有任何可疑之處。問題就在這裡：編造的數字和真實的數字，排版上完全一樣。 為什麼模型會這樣 AI 寫摘要時並不是在查你匯出檔裡的行，而是在生成「最像下一個詞」的內容——而「像」不等於「有出處」。兩種失誤最常見： 編造：那個位置需要一個數字，於是就生了一個。「失敗率 2.4%」會出現，是因為 pipeline 摘要裡通常有失敗率，而不是因為 2.4% 真的存在。 漂移：數字本身是真的，但在流轉中變了樣——被四捨五入兩次、秒與分鐘換算錯、從相鄰的行／週／專案串了行。 這兩種都能通過人工審閱，因為審閱看的是文字邏輯，不是算術。 五分鐘核驗流程 1. 留原始匯出，不要只留摘要。 把 CSV、日誌、SQL 查詢結果交給 AI。如果來源本身就是摘要，就沒有東西可以核對了。 2. 把每個數字都當成需要出處的斷言。 一條實用規則：沒有來源行號，就不進報告。 這跟新聞業要求引用出處是同一個道理，只是用在算術上。 3. 先對單位，再對數值。 1500 ms、1.5 s、0.025 min 是同一個時長。AI 摘要裡大量「看起來錯」的數字其實是單位或四捨五入造成的，而真正編造的數字就藏在這片雜訊裡。 4. 留出容差。 摘要裡保留三位有效數字的數值不可能和原始的 4183000 完全相等。設一個小的相對容差（1% 是合理預設值），超出容差的判定為「待核實」，而不是直接判錯。 5. 把「待核實」和「錯誤」分開。 待核實代表你貼的來源裡找不到它——它可能是對的，只是來自你還沒提供的資料；但在找到那個來源之前，它不能進報告。 AI 數字核驗器 把第 3～5 步自動化了：把 AI 回答和來源一起貼進去，它會抽出每個數字、正規化單位與倍數量詞、逐一比對，並把找不到出處的標紅，同時給出對應的來源行號作為證據。 標紅之後要做什麼 按影響從大到小處理，並替每個數字歸類： 現象 常見原因 處理方式 完全找不到，但量級合理 編造 刪掉，或要求提出出處 差幾個百分點 四捨五入、口徑不同、週期不同 確認統計週期再用 只在單位換算後才相符 摘要造成的偏差 可以用，但要寫清單位 對到相鄰但不同的行 串行 更正，並複查相鄰數字 這套方法的邊界 比宣傳更重要的是講清楚限制：核驗工具確認的是可追溯性，不是真實性。 ...