API7.ai創始人溫銘：燒了幾百億Token，我用AI重寫了生產級網關，總結出6條經驗

### 從數百億 Token 的實戰中，他提煉出用 AI 重寫生產級閘道的六大心法

API7.ai 創辦人溫銘近日在一場內部技術分享中，揭露了團隊如何耗費巨量 Token，利用大型語言模型（LLM）從頭改寫自家生產級 API 閘道的真實歷程。他並不只是談論概念，而是帶來了六條從燒錢與踩坑中淬煉出的具體經驗。這個案例不僅展現 AI 輔助軟體開發的極限，更為所有嘗試用 AI 改造核心基礎設施的團隊，點亮了方向。

#### 背景：為什麼要重寫一個已經很穩定的閘道？

API7.ai 是知名開源專案 Apache APISIX 背後的商業公司，其閘道產品在業界以高效能與高穩定性聞名。按照一般邏輯，成熟軟體不該輕易重寫；然而溫銘觀察到，過去三年大型語言模型的生成能力飛躍，使得「自然語言驅動」的程式碼生產模式可能徹底顛覆傳統開發流程。團隊決定大膽實驗：用 LLM 重新生成閘道的核心邏輯，目標是讓未來的新功能開發與維護，都能以「對話＋自動生成」取代人工逐行編寫。這個決策背後，是對 AI 能力能否勝任生產級複雜系統的終極檢驗。

#### 第一條經驗：Token 消耗的邊際報酬遞減，必須設定明確的「停止點」

溫銘坦言，團隊最初「燒了幾百億 Token」並非事先規劃，而是陷入反覆調整提示詞與補償錯誤的迴圈。他發現，當提示詞超過一定長度或迭代次數過多時，模型產生的程式碼品質增加極為有限，甚至會開始「忘」掉原本的要求。因此，他總結的第一條規則是：**為每一次生成任務設定 Token 預算與迭代上限**，若超過三次修正仍無法達到正確性標準，就必須人工介入或重新拆解問題。這避免了無限浪費運算資源。

#### 第二條經驗：AI 擅長「複製既有模式」，但不擅長進行邊界條件推理

在閘道這種高並發、低延遲的系統中，邊界條件（如極端輸入、記憶體耗盡、時間戳溢位）往往是最容易出錯的環節。溫銘觀察到，LLM 對於已經在訓練資料中出現過的程式碼模式（例如 HTTP 請求解析、路由匹配）可以生成得非常漂亮，但對於需要**嚴格邏輯推理的邊界處理**，例如無窮迴圈預防或資源釋放順序，模型生成的程式碼經常遺漏關鍵保護。因此團隊建立了一套自動化測試用例，專門針對這類邊界條件進行驗證，並要求模型在生成時明確輸出「異常處理段落」，作為檢驗強制要求。

#### 第三條經驗：讓 AI 先寫測試，再寫實作，提升正確率

傳統開發順序是先寫功能再補測試，但溫銘的團隊反其道而行。他們指導 LLM **先根據給定的規格與輸入輸出範例，生成單元測試與整合測試**，直到這些測試正確描述預期行為後，才讓模型開始產出實作。這個做法有兩個好處：一方面測試程式碼結構相對單純， LLM 錯誤率較低；另一方面，測試為實作提供了明確的「驗收標準」，大幅減少後續人工審查的負擔。一旦實作通過所有測試，團隊才會將其視為初步可接受。

#### 第四條經驗：人機協作不是完全取代，而是角色互補

溫銘明確指出，在目前技術水準下，