🎯 什麼情境該想到我
當你寫的（或要用的）skill 會真的扣錢——呼叫付費 API、燒 credit、跑生成模型——的時候。
核心原則：使用者要在花錢「之前」決定，不是在帳單出現之後才知道。
⚙️ 怎麼用（步驟 / 公式）
- 開跑前先檢查前置條件與餘額。CLI 在不在、有沒有 key、餘額多少——缺了就明講並提供備援計費方式，不要跑到一半才炸。
- 把用量寫成公式，不要含糊講「會花一些錢」。
實例：N 張圖 + (2N−1) 支影片（選了行動版就 ×2）+ 約 15% 重跑餘裕。
有公式，使用者才能自己換算不同規模的成本。 - ⭐ 校準，不要猜。很多服務的 CLI 不吐定價、而且各方案不同。
做法：先跑一張圖、一支影片，比對前後餘額差，再外推到全程。 - 講出估計總額，拿到 go 才開始生成。並且列出不同等級與各自的成本（草稿級 / 標準級），讓使用者選。
- 估計超過餘額某個比例就主動警告（實例用 ~70%）。
- ⭐ 絕不靜默做出「加倍花費」的東西。任何會讓成本翻倍的選項都必須單獨問，而且要把估計數字講出來，不能只是暗示。
- 提供便宜的預覽路徑：用最低階跑完整條流程 → 使用者核准方向 → 再用正式等級重跑。餘額吃緊時要主動建議這條，不用等人問。
- 長時間的生成一律背景執行並輪詢，不要前景阻塞（實例的單次生成要 3–8 分鐘）。
- 一次建置只用一個來源。同一批產出混用兩個供應商／模型會有風格漂移；便宜不是混用的理由。
🧪 我實際套用的紀錄
- 2026-08-28：（待填）
⚠️ 注意 / 什麼時候不適用
- 中途餘額不足即使可恢復也很難看。實例的說法很好：已完成的產物會留著、儲值後可續跑，但整個「事前核准」步驟存在的意義，就是不要走到那一步。
- 定價會變、實測值會過期。卡片裡記的任何數字都要標日期，並且每次都重新校準，不要沿用舊估算。
- 備援計費不是免費的等價替換：換一個供應商可能換到不同的服務堆疊，產出特性未必相同——實例明講跨供應商的接縫「未經測試」，要先驗一段再全跑。
- 這條原則不只適用於生成類 skill：任何會消耗配額、觸發計費、或佔用有限資源的自動化都適用。
- 不要把「先問過了」當成免責。估算錯了還是你的責任，所以第 3 步的校準比第 4 步的詢問更重要。
🔗 相關工具
- 工具-該問開放題還是選擇題 —— 成本核准正是「可列舉、低風險」的典型，該用選擇題並把數字放進選項裡
- 工具-防止agent造假通過驗收 —— 同一個心法：能造成危害的路徑，從結構上讓 agent 碰不到
- 工具-把重複的prompt包成skill —— 寫自己的 skill 時，成本紀律是驗收清單的一項