五個 AI 工具實測：誰能寫出 Production-Ready 的後端服務？

同樣一份規格文件，丟給五個不同的 AI 工具，讓它們各自從零實作一個 FastAPI 後端服務。結果差距大到出乎意料——從 95 分到 63 分，有的直接服務啟動即壞，有的則交出幾乎 production-ready 的程式碼。

這是一個有身分驗證、非同步資料庫、AI 蒸餾、Git 同步排程的完整系統：Knowledge Bus——一個讓多個 AI coding session 共享 pattern 與架構決策的輕量 HTTPS 服務。

評測方法論

統一輸入：所有受測工具拿到的是同一份 knowledge-bus.md 規格文件，配合同一個 prompt，在各自的工具介面（Codex、Gemini、Claude Code、Copilot）獨立執行，不給予額外提示或人工修正。

評測者選擇：為什麼用 Claude Sonnet 4.6，而不是 Opus？

Opus 對我來說成本太高，只保留給超複雜問題（架構設計、深度除錯）。從零開始的程式碼開發，Sonnet 的 CP 值最高——速度夠快、品質足夠、token 配額不會消耗太快。既然 Sonnet 是日常 coding 的 daily driver，評測目標自然就是「找出最接近 Sonnet 品質的外部工具」，而不是去對齊一個平常用不到的標準。用 Opus 評測會提高標準杆，讓所有工具都顯得平庸；用較弱的模型評測則無法識別細節差異。Sonnet 作為評測者，結果才能直接回答「這個工具能否替代 Sonnet 完成相同工作」。

為什麼單獨測 Unit test 速度：光寫好程式碼還不夠，能針對不同情境考慮到邊界案例、寫出完整測試，才是真正的獲勝關鍵。Unit test 是最能區分「會寫 code」和「真的理解系統」的維度。

Unit test 開發速度測量：同步貼上單元測試實作的 prompt，其他工具約 10 秒完成任務，Gemini Flash Preview 約需 1 分鐘，因此定調為 3x。這是實測觀察值，非主觀感受。

公平性限制：每個工具只跑一次，不重試、不挑選最好的輸出。實際使用中重跑可能得到不同結果，本評測反映的是「第一次就能交出什麼」的基準能力。

評測題目：Knowledge Bus v1.6

Knowledge Bus 這個開發專案主要在解決一個實際問題：Claude Code Web Sandbox VM 各個 session 彼此封閉，設計決策無法跨專案流通。這個服務讓多個 sandbox session 可以透過 HTTPS 即時互相溝通查詢同一個知識庫，跨 private repo 共享程式碼、pattern 與架構決策，甚至可以與 Codex、Gemini 等其他 AI agent 溝通。

技術棧要求

必要 Endpoint

安全要求：所有 endpoint 須驗證 X-KB-Token header，/raw/ 須防止 ../ path traversal，Token 不得進入任何 git history。

受測工具

評分標準

總分排名

A. 程式完整度

Endpoint 覆蓋率

所有模型都完成了大部分 endpoint，但有幾個值得注意的缺失：

• GPT-4.1：缺少 POST /repo/register 和 POST /sync/{project}，也就是整個 repo 管理功能都不見了
• GPT-5.4：額外實作了 GET /repos 和 GET /health（加分項），顯示有 production 思維

有一個缺失是全員共享的：所有 5 個專案均未實作 session-start.sh / session-end.sh hooks。這是 spec 明確要求的項目，但沒有任何模型交出來。

DB Schema 完整性

其他完整度項目

推測所有模型都優先產出 Python 程式碼，對 bash hooks 的優先順序較低，或在 context 長度限制下被截斷。

B. 程式品質

這一項是拉開差距的關鍵維度。

Pydantic v2 API：最明顯的分水嶺

# 已棄用（Pydantic v2 會警告，未來版本會 break）
payload.dict()

# 正確（Pydantic v2）
payload.model_dump()

只有 GPT-5.4 使用了正確的 .model_dump()。其他四個模型都用了 Pydantic v1 的 .dict()，在 Pydantic v2 環境下會有 deprecation warning，未來版本會直接 break。

GPT-4.1 的 Fatal Bug

# main.py（錯誤）
@asynccontextmanager
def lifespan(app: FastAPI):   # ← 缺少 async
    await init_db()           # ← 這行永遠無法執行
    scheduler = start_scheduler()
    yield

# 正確應為：
async def lifespan(app: FastAPI):

影響：APScheduler 永遠不啟動，資料庫初始化失敗，服務啟動即壞。這是個直接讓服務無法運行的 fatal bug，不是小問題。

安全細節的差距

Path traversal 防護大家都做了，但只有 GPT-5.4 進一步防了 project name 注入、加了 DB indexes、做了更完整的 distill 錯誤處理。

C. 單元測試

這一維度的最大意外：Gemini 的測試品質最好，甚至超過了總分第一的 GPT-5.4。

測試檔案概覽

Gemini 的 conftest.py 設計

@pytest.fixture(scope="session")
async def async_client(tmp_path_factory):
    db_path = tmp_path_factory.mktemp("db") / "test.sqlite"
    repos_dir = tmp_path_factory.mktemp("repos")
    # 環境完全隔離，測試不污染彼此
    async with AsyncClient(app=app, base_url="http://test") as client:
        yield client

Gemini 交出了 5 個測試檔、pytest-asyncio + async fixtures、完整的環境隔離。這是業界最佳實踐，顯示對 pytest 生態系的深度熟悉。

GPT-4.1 的測試現況

# test_database.py — 只測 DB 初始化，沒有任何 API 測試
class TestDatabase(unittest.TestCase):
    def test_init_db(self):
        asyncio.run(init_db())
        self.assertTrue(os.path.exists("db/kb.sqlite"))

用的是 unittest 而非 pytest，只測資料庫建立，所有 API endpoint 的測試一個都沒有。

各模型測試覆蓋對比

值得注意：DELETE /commons、POST /repo/register、POST /sync/{project} 這三個寫入端點，沒有任何模型寫了測試。

D. DevOps 部署

這一維度差距最大，GPT-5 Mini 幾乎全部缺失。

GPT-5 Mini 沒有 Dockerfile、沒有 docker-compose、沒有 nginx config，也就是說你拿到這份程式碼完全無法部署。Mini 模型容量有限，在規格文件很長的情況下，很可能沒有完整解析部署章節。

所有有 Dockerfile 的專案均包含 FROM python:3.11-slim、安裝 git/curl/Node.js/@anthropic-ai/claude-code、mkdir -p db repos、CMD ["uvicorn", "main:app", ...]。GPT-5.4 額外優化：apt 安裝有 && rm -rf /var/lib/apt/lists/* 清理，image 更小。

所有專案共同缺失：均未使用 multi-stage build，這會讓最終 image 明顯偏大。

成本效益分析

表面 CP 值

看費用，Gemini 完勝，Copilot 也不錯。

修正開發速度後的真實 CP 值

Gemini 開發速度是其他工具的 3 倍慢。如果你的時間有價值，這個隱性成本不能忽略。

Bug 修正的隱性成本

拿到高分的程式碼，後續需要手動修正的地方就少。GPT-5.4 的程式碼拿到之後大約 1 小時就能修完上線，GPT-4.1 的程式碼可能要花半天重寫。

差異原因分析

GPT-5.4 為什麼最好：

1. 訓練資料時效：GPT-5.4 是最新模型，Pydantic v2 的 .model_dump() 在訓練資料中已取代 .dict()，因此自然使用正確 API
2. 架構感知：能自行判斷需要 serializers.py 做 tag 解析抽象，不是單純照抄 spec
3. 安全意識：主動加 project name 注入防護，超出 spec 要求
4. 完整性驅動：主動加 /health、/repos、DB indexes，顯示有 production 思維

Gemini 測試最好但速度慢：Flash Preview 對 pytest-asyncio 生態極為熟悉，conftest.py 設計是業界最佳實踐。速度慢的根本原因在單元測試階段觀察到：測試多次 fail，Gemini 採線性執行策略——每次只修當前失敗的那個，缺乏宏觀規劃、無法一次產出整體修正方案。這種逐步推進的方式雖然最終品質不差，但來回次數多，整體等待時間拉長。

Copilot 兩個模型都墊底：

1. GPT-4.1 的 async bug：async/await 在 FastAPI lifespan 上的正確用法是近期版本才確立，訓練資料可能使用舊 pattern
2. GPT-5 Mini 缺 DevOps：Mini 模型容量有限，在 spec 很長的情況下可能沒有完整解析部署章節
3. Copilot 產品定位：以 IDE 內程式碼補全為主，對「生成完整專案」這類任務的優化低於 Codex

為什麼所有人都沒做 session hooks：Spec 的 session hooks 章節在文件後段，且與 FastAPI 主體程式碼分離。推測所有模型都優先產出 Python 程式碼，對 bash hooks 的優先順序較低，或在 context 長度限制下被截斷。

結論與建議

評測範圍說明：本次評測僅針對低成本 LLM 工具（月費 $0–$20）。如果公司預算足夠，建議直接上 Claude Max $200 方案——用量上限是 Pro 的 20 倍，大幅降低碰到配額限制的機率，不在本次比較範圍內。

完整工具比較表

時間有限、品質要求高：用 Codex（$20）。95 分，後續只需約 1 小時修正，是這次評測中最接近 production-ready 的結果。

有大量非緊急背景任務：Gemini（免費）值得用。90 分，品質接近 Codex，但採線性執行策略、開發速度慢 3x，不適合需要快速迭代的場景。

Claude Code Pro 的定位：本次用的是 Claude Haiku（消耗較少 token），若用 Sonnet 評分預期更高，但同月費下 token 配額也更少。Codex $20 的 token 配額遠高於 Claude Code Pro $20，故在「能做多少工作」這個維度上 Codex 佔優。

Copilot 目前不建議用於完整專案生成：兩個模型都只有 63~64 分。Copilot 雖然也提供 Claude Sonnet/Haiku 和 GPT-5.4 選項，但這些模型非常吃 token，實測很快就用盡配額。既然 Copilot $10 加差額就等於 $20，不如直接訂閱 Claude Code Pro 或 ChatGPT，能用完整配額的旗艦模型，CP 值更高。

無論選哪個模型，以下項目都要手動補齊

1. session-start.sh / session-end.sh 的 Claude hook 腳本
2. DELETE /commons/{pattern_id} 的測試
3. POST /repo/register 和 POST /sync/{project} 的測試
4. Dockerfile 改用 multi-stage build
5. nginx 加 limit_req rate limiting

AI 工具可以加速開發，但「知道哪些地方沒做好」這件事，目前還是得靠人來把關。

如果給更詳細的 spec，表現會更好嗎？

不一定，而且可能對低分模型反而更差。

GPT-5.4 影響有限：它已經超出 spec 自行補加 /health、DB indexes、serializers 抽象，靠的是本身的 production 直覺，不是靠 spec 詳細。給更多細節邊際效益低。

Gemini、Claude Haiku 可能有幫助：主要失分在「沒做到但 spec 沒明說的細節」，例如 DB indexes、.model_dump()。如果 spec 明確寫出這些要求，它們應該能照做，分數可以往上補。

GPT-5 Mini、GPT-4.1 可能反而更差：這兩個模型已經在長 spec 下出現截斷問題——GPT-5 Mini 缺整套 DevOps，GPT-4.1 缺兩個 endpoint。spec 加長只會讓截斷更嚴重，核心功能反而更容易被犧牲。

根本問題不在 spec 詳細度：GPT-4.1 的 fatal bug 是 def lifespan 少了 async，這是訓練資料落後的問題，再詳細的 spec 也修不了。

更有效的做法可能是把 spec 拆成多輪：先給架構 prompt，再給安全要求，再給 DevOps，避免長 context 截斷，讓每個模型在能力範圍內發揮最佳表現。但拆多輪本身也是成本——撰寫更詳細的 spec 需要時間，多輪互動需要等待。如果模型夠強（如 GPT-5.4），一次給完反而最省事。

選工具的決策流程

flowchart TD
    A[任務需要快速上線？] -->|是| B{預算 $20？}
    A -->|否| C{可接受 3x 等待時間？}
    B -->|是| D[✅ Codex / GPT-5.4<br/>95分，最少後續修正]
    B -->|否| E[⚠️ Copilot<br/>先驗證 spec，手動補 DevOps]
    C -->|是| F[✅ Gemini（免費）<br/>90分，適合背景任務]
    C -->|否| G[Codex 或 Claude Code Pro<br/>視 token 配額而定]

本次評測的最大教訓：工具的品質差距，在第一次交付後才真正浮現——不是看它能不能跑起來，而是看它距離 production-ready 還差多少手工。