寫程式情境下，AI 中轉站的軟體工程評測指南

把 AI 中轉站（API Gateway / Aggregator）放進軟體工程的座標系來檢視，它的本質是一個具備狀態機解析與上下文排程能力的應用層（L7）代理閘道。

從 IDE 的單行自動完成，發展到以 Claude Code CLI、OpenAI Codex CLI 為代表的終端機 Agent 協作，以及 Specification Driven Development（規格驅動開發） 的開發範式，程式開發情境對 API 代理層的要求已經徹底改變。暫且撇開網路穩定性、高並行壓力測試這類通用閘道指標，單純從「程式碼生成與軟體工程」這個使用情境出發，評估 AI 中轉站的核心在於：這個代理層會不會破壞程式碼語法、中斷 Agent 的互動狀態機、丟掉長上下文的相依關係，或是剝除開發端送出的最佳化協定。

針對寫程式與軟體開發情境，AI 中轉站的專業評測應聚焦在以下四個核心工程維度：

一、程式碼語法與特殊字元的高保真度（Syntax & Escape Integrity）

程式碼生成對字元和格式的精確度極度敏感。程式碼不只是一般文字，它包含嚴格的縮排、換行字元、跳脫字元，以及內嵌的 JSON/XML 結構。

1. 特殊字元與跳脫字元零損耗（Zero-Loss Escaping）

• 底層原理：以串流傳輸（SSE）輸出程式碼 Chunk 時，程式碼中含有大量的 \n（換行）、\t（縮排）、\"（雙引號跳脫）、正規表示式中的 \\d 或 JSON 字串。中轉站如果在分塊組裝或原樣轉發時做了不當的 Unescape 或編碼轉換（例如 UTF-8 多位元組字元被截斷），用戶端收到的程式碼就會直接出現語法錯誤。
• 評測方法：
• 跳脫字元壓力測試：要求模型生成含有極端跳脫字元的程式碼（例如複雜的正規表示式、內嵌巢狀 JSON 字串的 Python 程式碼、含有 C++ 指標與巨集定義的程式碼）。
• 驗收標準：把中轉站轉發的串流資料直接寫入檔案，再用本機 Lint 工具（例如 eslint、flake8）或 AST 解析器（例如 Babel / Tree-sitter）做語法解析。AST 解析成功率必須是 100%。

2. 縮排與換行格式保持（Whitespace & Indentation Preservation）

• 底層原理：Python、YAML 等語言靠縮排來表達作用域（Scope）；不同作業系統的換行字元（\n vs \r\n）也會直接影響 Git 的 Diff 比對。
• 評測方法：送出含有深層巢狀邏輯（例如位於 8 層 loop 內的 Python 函式）的程式碼重構請求。
• 驗收標準：比對原始輸出與中轉站轉發輸出中的空格和 Tab 數量，位元組層級的一致率必須達到 100%，嚴禁中轉站自動「美化」或「壓縮」空白字元。

二、Agent 工具鏈與結構化輸出解析（Tool Call & Schema Fidelity）

現代的程式開發 Agent 在寫程式時，不再只是輸出 Markdown，而是頻繁發起 Tool Call（例如 read_file、edit_file、run_terminal_command）。

1. JSON Schema 結構嚴格原樣轉發（Structured Output Fidelity）

• 底層原理：Agent 修改本機程式碼時，會輸出含有 path、old_str、new_str 等欄位的結構化 JSON。如果中轉站破壞了 Tool Call 的序列化格式，或是丟掉某些巢狀欄位，Agent 端就會解析失敗，拋出例外而崩潰。
• 評測方法：
• 多工具巢狀呼叫測試：設計一個需要多個檔案連動修改的 Agent 任務（例如同時對 5 個 TypeScript 檔案進行介面重構），擷取中轉站轉發的 Tool Call 內容。
• 驗收標準：中轉站轉發的 Tool Call 結構必須與上游官方 API 完全一致，不得出現欄位缺漏、資料型別改變（例如 string 變成 number）或 JSON 提前截斷。

2. 多輪對話狀態鏈的連續性（Multi-turn State Continuity）

• 底層原理：Agent 解決一個複雜的 Bug，通常需要 10~30 輪互動：讀取檔案 -> 嘗試修改 -> 執行測試 -> 報錯 -> 再次修改。中轉站必須完整轉發 role: "assistant" 中帶有的 tool_use，以及 role: "user" 中帶有的 tool_result 所組成的長對話鏈。
• 評測方法：實際執行一段 10 輪以上的 Agent 除錯流程。
• 驗收標準：確認在第 N 輪互動時，中轉站仍完整保留並轉發前 N-1 輪的所有 Tool Call ID 與狀態節點，沒有出現歷史 Context 遺失或狀態錯亂。

三、程式碼長上下文與快取協定（Context Depth & Prompt Caching）

軟體工程情境的典型特徵是 Context 非常龐大——一個中大型專案的程式碼庫上下文（Codebase Context）動輒 100k~200k Token。

1. Prompt Caching 協定直通（Cache Control Pass-Through）

• 底層原理：在規格驅動開發（SDD）或大型專案開發中，專案的 Architecture Spec 和共用的 Base 程式碼是固定不變的。Agent 會在 Request 中加上 cache_control 標記，讓模型伺服器端重複使用 KV Cache。中轉站如果剝除了這個 Protocol 標記，每次只是微調一行程式碼，都得重新 Prefill 幾十萬 Token。
• 評測方法：連續送出帶有 cache_control 標記、長度 100k Token 的工程上下文。
• 驗收標準：
• 請求端：側錄封包，確認中轉站送往上游的 Request 中，cache_control 欄位沒有被剝除。
• 回應端：檢查回傳的 usage 結構中，是否精準回傳了 cache_read_input_tokens 計數。

2. 長上下文的真實性（Needle in a Codebase）

• 底層原理：驗證中轉站是否為了節省成本，暗中用 RAG 裁剪程式碼、壓縮 Prompt 或偷換成小模型，導致大型模型對程式碼的全域掌握能力下降。
• 評測方法：
• 跨檔案相依查找：在一個 150k Token 的程式專案中，把一個不起眼的介面定義放在 File A（開頭），把呼叫放在 File B（結尾），中間塞滿大量無關的程式碼，再詢問模型該如何修改這個介面。
• 驗收標準：比對中轉站回傳的程式碼修改結果與官方 API 直連的結果。如果中轉站因為裁剪了 Context 而漏掉跨檔案的變數關聯或型別定義，即可判定上下文遭到破壞。

四、程式碼生成完整性與指令保護（Output Horizon & Instruction Protection）

寫程式情境最怕程式碼中斷，例如一個 500 行的演算法模組，生成到第 300 行時無故截斷。

1. Max Output Tokens 上限支援（Max Output Horizon）

• 底層原理：重構單一檔案或生成完整模組時，需要模型一次輸出 4k、8k 甚至 16k Token 的純程式碼。中轉站的代理緩衝區（Buffer）或逾時控制邏輯如果不夠完善，長程式碼輸出到一半就會直接中斷。
• 評測方法：要求模型生成一個超長且沒有冗餘邏輯的完整程式碼模組（例如手寫一個包含數百個列舉與轉換邏輯的 Parser）。
• 驗收標準：中轉站轉發的回應主體必須能達到模型支援的最大 max_tokens 上限，而且結尾的 finish_reason 必須明確是 "stop"（正常結束）或 "length"（達到長度上限），嚴禁無故提前 EOF。

2. System Prompt 零竄改（System Prompt Integrity）

• 底層原理：程式開發 Agent 會在 System Prompt 中注入極為嚴格的程式碼規範（例如「必須使用 TypeScript 嚴格模式」「所有函式都必須寫 JSDoc」）。有些中轉站會注入自己的全域 Prompt，甚至自動裁剪 System Prompt。
• 評測方法：注入含有特殊 Code Style 限制的 System Prompt，要求模型生成程式碼。
• 驗收標準：檢查生成的程式碼是否 100% 遵守 System Prompt 中的限制，並透過封包擷取比對 Raw Request，確保中轉站沒有對 System Prompt 做任何位元組層級的竄改。

總結：程式開發情境評測 Checksheet