AI 幫你改 Server 搞到帳單爆升 17 倍？2026 必學成本護欄

發佈日期：2026-05-22

帳單從 $60 跳到 $700：一個真實的教訓

2026 年 5 月，V2EX 上出現了一條帖子，標題沒有任何誇張成分：「AI 給我闖禍了。」

發帖者是一位獨立開發者。他讓 AI coding assistant 幫他修改服務器錄制數據的傳輸邏輯——這是一個聽起來很普通的任務，平時自己也能搞定，只是交給 AI 省事一點。AI 寫完代碼，他 review 了一下，看起來沒問題，就 deploy 了。

直到月底打開 AWS 帳單，他的心跳停了一拍。

正常月份：$40–60 美元。這個月：$700 美元。

事後排查，問題出在一個細節：AI 改的傳輸邏輯裡，遇到服務器報錯之後，沒有做冷卻重試（backoff retry）。每次傳輸失敗，代碼立刻重試，然後再失敗，再重試……無限循環，把 API calls、數據傳輸、Lambda 調用全部打爆。費用在帳單結算前都是滯後的，他壓根沒有察覺，直到已經損失了幾百美元。

這個故事不是特例。它代表了一類越來越常見的風險：AI 改 infra，成本失控。

為什麼 AI 特別容易搞出這類問題？

讓我們先弄清楚一件事：這不是 AI 「變壞」或「不負責任」，而是 AI 的工作方式與 infra 的成本結構之間存在天然的錯位。

1. AI 的目標是「跑通」，不是「省錢」

你叫 AI 幫你寫一段數據同步邏輯，它的目標是讓代碼能正確運行。重試機制屬於「健壯性」範疇，它可能寫了，也可能沒寫，但它不會主動思考「這段代碼在生產環境跑起來每個月要花多少錢」。

成本意識是隱性知識，不是功能需求的一部分，AI 不會自動加入 prompt 裡面沒有的考量。

2. 雲端服務的費用是滯後的

AWS、GCP、Cloudflare Worker 的帳單都是事後結算。你 deploy 完代碼，不會馬上看到費用飆升，要等幾小時甚至幾天才能在 Cost Explorer 看到異常。在這個窗口期裡，問題代碼可以靜靜地燒錢。

3. AI 寫的代碼「看起來正確」

上面那位開發者不是沒有 review 代碼，他看了，覺得沒問題。問題是：大部分 code review 關注的是邏輯正確性，而不是成本行為。一段沒有 backoff 的重試邏輯，功能上不算 bug，只是在極端情況下（比如服務器報錯）會瘋狂消耗資源。

這種問題很難在靜態 review 時發現，需要的是動態監控和護欄。

4. Agent 會自我強化失控行為

如果你用的是更強大的 AI Agent（而不只是 coding assistant），情況可能更糟。有研究記錄了 Cursor Agent 進入無法恢復的無限循環，反覆呼叫同一個 tool call 數百次——每次失敗，立刻再試。Agent 的本質是「自主完成任務」，在沒有硬性限制的情況下，它不會主動停下來。

真正的根本原因：沒有護欄

讓 AI 改 infra 代碼的問題，本質上跟「讓實習生改生產系統」差不多。實習生可能技術很好，但他不知道哪些地方是地雷，需要的是制度層面的保護，而不只是個人的謹慎。

對 AI 來說，這個「制度保護」就是成本護欄。

五條護欄：讓 AI 幫你改 infra 更安全

護欄一：AWS Budget Alert（必設，10 分鐘搞定）

這是最簡單、最直接的防線。在 AWS Console 設一個月度預算，超過閾值就發 SNS 通知到你的手機或 Slack。

AWS Console → Billing → Budgets → Create Budget
- 類型：Cost Budget
- 金額：你正常月份的 1.5 倍
- 警報：80% 時通知，100% 時通知
- 通知方式：Email + SNS（轉 Slack 最方便）

這條護欄能在帳單炸爆之前把你叫醒。成本：免費（前兩個 Budget 免費，之後 $0.02/budget/month）。

護欄二：要求 AI 必須寫 Exponential Backoff

你的 prompt 裡要明確說：

「所有網絡請求、API 呼叫、數據傳輸，如果遇到報錯需要重試，必須使用 exponential backoff，最大重試次數不超過 5 次，初始等待時間 1 秒，最大等待時間 60 秒。」

這是直接從技術層面堵死「無限重試」的漏洞。很多 AI 在你不提的時候會偷懶不寫，但你一旦加入 prompt，它基本上都能正確實現。

Python 範本：

import time
import random

def retry_with_backoff(func, max_retries=5, base_delay=1, max_delay=60):
    for attempt in range(max_retries):
        try:
            return func()
        except Exception as e:
            if attempt == max_retries - 1:
                raise
            delay = min(base_delay * (2 ** attempt) + random.uniform(0, 1), max_delay)
            time.sleep(delay)

護欄三：給 Lambda 和 EC2 設資源硬上限

如果你的代碼跑在 Lambda 上，要設：

並發限制（Reserved Concurrency）：防止無限擴展
函數超時（Timeout）：最長執行時間，防止單次調用跑太久
SQS 死信隊列（Dead Letter Queue）：重試超過上限的消息丟到 DLQ，不要繼續燒錢

如果跑在 EC2 / ECS，要設 CloudWatch Alarm 監控 CPU usage 和 Network Out，異常時自動告警甚至自動 scale down。

護欄四：使用預算感知的 Agent 框架

如果你用的是更高層的 AI Agent（不只是 coding tool），可以考慮在框架層加入預算控制。

開源工具 Paperclip 提供了 agent 層面的月度預算上限和自動節流機制——當 agent 的 API 消費超過設定金額，它會自動暫停，不讓 agent 繼續「燒」。對於有多個 agent 並行運行的複雜架構，這種框架層的控制比逐個去設 AWS Budget 更系統化。

核心概念：

月度預算上限：每個 agent 獨立設置，超限自動節流
Human approval gates：高風險操作要人工確認才執行
不可變 Audit Log：所有 tool call 留下記錄，事後可追溯

護欄五：在 AI 改完 infra 後，強制做成本審計

每次讓 AI 改完跟網絡、存儲、計算相關的代碼，加一個 checklist：

□ 這段代碼有沒有重試邏輯？如果有，有沒有 backoff + 上限？
□ 有沒有可能觸發大量 API 呼叫的 loop？
□ 數據傳輸量預估是多少？有沒有流量費用？
□ 如果這個函數被高頻呼叫，月費用大概是多少？
□ 有沒有設 timeout？有沒有設 concurrency limit？

這個 checklist 可以直接貼給 AI，讓它自己回答。如果 AI 的回答裡有「不確定」或「沒有考慮到」，那就是需要補加護欄的地方。

成本估算要養成習慣

除了護欄，還有一個更根本的習慣改變：在 deploy 之前，養成做費用估算的習慣。

AWS 有 Pricing Calculator，可以根據你的使用量算出月費用。在讓 AI 修改 infra 邏輯的時候，可以直接問 AI：

「這段代碼如果每天被呼叫 10,000 次，在 AWS 上大概每月費用是多少？」

AI 不一定算得很精確，但它能給你一個數量級的判斷，讓你知道「這個方案大概是 $5 的量級還是 $500 的量級」。

一位工程師分享過一個慘痛經歷：他讓 AI 幫他建了一個支援 ticket 系統，接入了 Claude API via Bedrock，效果很好，解決時間縮短了 42%。但他沒有估算 API 成本，結果月費從 $8,000 跳到 $27,000——三倍多。功能是好功能，只是他在選方案的時候沒有做成本測算。

一個快速的心智模型

用 AI 改 infra，可以用以下三個問題快速判斷風險：

這段代碼會不會被高頻觸發？（定時任務、每次請求、每條消息……）
如果觸發出錯，會怎樣？（靜默失敗、重試、無限循環？）
費用是按量計費還是固定？（Lambda 按次收費、EC2 按時間收費，邏輯不同）

如果第 1 題答案是「會」，第 2 題答案是「重試」，那你必須確認有 backoff + 上限，同時有監控告警。這個組合才是安全的。

Actionable Checklist

以下是給使用 AI coding tool 的開發者的完整護欄清單：

即刻行動（今天可以搞定）：

設 AWS Budget Alert，閾值為正常月費的 1.5 倍
在常用 AI 工具（Cursor、Claude Code 等）的 system prompt 裡加入重試規範
給現有 Lambda 函數檢查並設定超時和並發上限

每次 AI 改 infra 前：

在 prompt 明確要求 exponential backoff + 最大重試次數
問 AI 預估月費用（10,000 次/天的場景）
要求 AI 在代碼裡加入 error logging，方便事後追蹤

每次 deploy 後：

打開 AWS Cost Explorer，看接下來 24 小時的費用趨勢
確認 CloudWatch 有對應的 Alarm
跑一次負載測試，模擬高頻呼叫 + 服務器報錯的場景

長期架構：

考慮引入 agent 預算控制框架（如 Paperclip）
建立 infra 變更的 review checklist，不讓 AI 改完直接上線
定期（每月）做費用審計，把異常帳單當作學習材料

結語

讓 AI 幫你改 server 代碼，這件事本身沒有問題。問題是很多開發者在用 AI 的時候，把它當成了一個「不會出錯的高級員工」，忘記了它同樣需要制度層面的保護。

$700 的帳單教訓，換來的應該是一套護欄，而不只是以後不再信任 AI。AI coding tool 的效率紅利是真實的，但要安全地享用這個紅利，你需要把護欄建好。

成本護欄不是反對 AI，而是讓 AI 幫得更放心。

參考資料：V2EX 帖子「AI 給我闖禍了」 · Paperclip Agent 框架 · 如何防止 AI Agent Reasoning Loop 浪費 Token