設定

語言

30 天內用 Claude Code 打造生產級 AI Platform:真實故事

L
LemonData
·2026年2月27日·3581 次瀏覽
30 天內用 Claude Code 打造生產級 AI Platform:真實故事

那是週二凌晨兩點,我意識到計費系統向用戶收取了雙倍費用。這個 bug 已經在正式環境運行了六個小時。Claude Code 在那天下午生成了支付對帳邏輯,而我審查了它、測試了它,然後發布了它。程式碼看起來很完美,通過了每一項測試,但它從根本上就是錯誤的。

這是構建 LemonData 的故事:274 個 API 路由、46 個資料庫模型,以及使用 AI 編碼助手編寫的超過 10 萬行程式碼。這不是那種經過修飾的「看 AI 讓你變得多高效」的故事,而是真實的故事,包含了失敗、凌晨三點的除錯環節,以及我質疑 AI 輔助開發是否真的是個好主意的時刻。

理想與現實:AI 輔助開發的真相

AI 編碼助手的宣傳非常誘人:你描述你想要的,AI 把它寫出來,你審查並發布。理論上,一名開發者現在可以完成整個團隊的工作。

但在實踐中呢?前兩週的感覺非常棒。Claude Code 理解我的程式碼庫,生成完整的特性,跨文件進行重構。我發布功能的速度比我職業生涯中任何時候都快。快速關閉 Issue 帶來的多巴胺讓人陶醉。

接著,裂痕開始出現。

同一個函式出現在三個不同的文件中,實現方式略有不同。配置值被硬編碼在隨機的地方。型別定義在不同套件之間相互矛盾。程式碼庫增長迅速,但也變成了一個「能跑但我不確定為什麼」的程式碼迷宮。

至於那個計費 bug?Claude 生成了一個看起來非常合理的對帳函式。但它沒有考慮到我們非同步支付確認流程中的競態條件(race condition)。AI 無法得知那個邊緣案例,因為我沒有明確告訴它,而同樣部分由 AI 生成的測試套件也沒有覆蓋到這一點。

不斷出現的七種模式

在使用 Claude Code 構建一個月後,我開始記錄一份清單。不完全是 bug,而是模式。同樣類型的失敗不斷發生,這不完全是 Claude 的錯,或者至少不全是。它們是 AI 優先考慮「現在能用的程式碼」而非「明天還能用的程式碼」的必然結果。

1. 一致性問題

Claude 會根據它正在處理的文件、最近看到的範例,或者似乎只是隨機的變化,而以不同的方式實現相同的邏輯。一個 API 端點會返回 { data: users },另一個則返回 { users }。兩者都能運作,但互不匹配。除錯變成了考古工作。

2. 複製貼上問題

當複製程式碼更快且不會冒著破壞現有功能的風險時,AI 為什麼要創建共享工具?每當我要求一個與現有功能相似的新特性時,我會得到一個全新的實現,而不是重構後的共享解決方案。三週後,我有五個不同的「格式化貨幣」函式散落在程式碼庫各處。

3. 型別偏移問題

一個新的狀態值被添加到一個文件中,但沒有添加到 enum 定義中。一個欄位在 API 回應中是可選的,但在前端型別中是必填的。TypeScript 捕捉到了其中一些問題,但沒能捕捉到語義上的不匹配——即型別在技術上正確但在邏輯上不一致的情況。

4. 配置分散問題

資料庫 URL、API 金鑰、特性旗標和速率限制最終會出現在對當前任務方便的任何地方。有時在環境變數中,有時在配置文件中,有時是硬編碼。尋找定義某個值的所有地方變成了一場尋寶遊戲。

5. 測試覆蓋率幻象

AI 生成的測試往往會徹底測試正常路徑(happy path),而完全遺漏邊緣案例。計費 bug 就是一個完美的例子:測試套件完美地覆蓋了正常的支付流程,但它從未測試過當兩個支付確認在同一毫秒內到達時會發生什麼。

6. 靜默失敗問題

Claude 會添加 catch (error) { console.log(error) } 區塊來吞掉異常。在開發環境中,這看起來沒問題,因為錯誤會出現在控制台中。但在正式環境中,關鍵失敗被靜默記錄後就被遺忘了。

7. 文件斷層

Claude 能寫出優秀的程式碼註釋,但它寫出的架構文件卻很糟糕。它可以解釋一個函式的作用,但無法解釋為什麼系統要這樣構建,或者是什麼約束導致了特定的設計決策。

CLAUDE.md 解決方案

轉折點出現在第三週,我在專案根目錄創建了 CLAUDE.md,這個文件包含了 Claude 需要知道的每一個慣例、約束和架構決策。

這不是寫給人看的文件,而是寫給 AI 看的文件。

## API Response Format
Always use: { success: true, data: T } or { success: false, error: string }
Never return raw data without the wrapper.

## Currency
Internal storage: USD. Display: formatCurrency(amount, currency, rate).
Never hardcode exchange rates. Never store CNY directly.

## Error Handling
Never use catch(e) { console.log(e) }.
Always use the logger: logger.error('context', { error }).

效果立竿見影。Claude 開始一致地遵守慣例。當它生成的程式碼違反規則時,我可以指向 CLAUDE.md 中的特定行,它就會自我修正。

但單靠 CLAUDE.md 是不夠的,我需要自動化強制執行。

構建安全網:AI 生成程式碼的 CI 閘道

我們構建了一個 CI 流水線,其中的閘道在傳統程式碼庫中可能顯得過於偏執,因為它們的存在是為了在用戶發現之前捕捉 AI 生成的 bug:

  • 跨整個 monorepo 的型別檢查
  • 驗證不存在重複實現的 SSOT 審計
  • 資料庫 enum 與 TypeScript enum 之間的同步檢查
  • API 回應格式驗證
  • 針對計費、權限和身份驗證程式碼的安全閘道

核心見解很簡單:Claude 是一個放大器,而不是替代品。它放大了你的生產力,但也放大了你的錯誤。如果你沒有強大的慣例,Claude 會發明它自己的慣例,而且它們不會是一致的。如果你沒有自動化檢查,Claude 的 bug 會比人類的 bug 更快到達正式環境。

計費 bug 不再可能發生。不是因為 Claude 變得更聰明了,而是因為流水線現在要求明確處理非同步競態條件,並由一個檢查支付流程中適當鎖定機制的閘道進行驗證。

「AI 原生開發」的真正含義

當我說 LemonData 是「AI 原生基礎設施」時,我並不是指我們在現有產品中添加了 AI 功能。我的意思是,整個開發過程都是由與 AI 編碼夥伴合作的現實所塑造的。

我們的文件比通常情況下更詳細,因為 Claude 需要明確的上下文,而人類隊友可能會推斷出這些上下文。我們的型別系統比必要的更嚴格,因為 Claude 會利用任何歧義。我們的 CI 流水線擁有在傳統程式碼庫中顯得偏執的閘道,因為它們是為了在用戶之前捕捉 AI 生成的 bug。

結果是,這個程式碼庫實際上比我處理過的大多數程式碼庫都更容易維護。不是因為 AI 寫的程式碼比人類好,而是因為為 AI 輔助開發而構建迫使我將通常只存在於資深開發者腦中的所有慣例和檢查都明確化了。

關於 AI 原生作為一種哲學的更多內容,請參閱 什麼是 AI 原生?

如果你想了解更具實踐性的「我該如何開始應用這個?」的一面,兩篇最好的後續閱讀是 Agent 優先的 API 設計指南遷移指南。前者解釋了 API 的形態,後者展示了一旦工作流程為模型切換而設計,團隊改變方向的速度可以有多快。

給使用 AI 編碼助手的開發者的建議

如果你正準備使用 Claude Code、Cursor 或任何 AI 編碼助手開始一個專案:

  1. 在第一天就創建你的 CLAUDE.md,不要像我一樣等到第三週。
  2. 自動化慣例強制執行。不要依賴 AI 記住規則。
  3. 像審查初級開發者寫的程式碼一樣審查 AI 程式碼。它速度快且能力強,但缺乏上下文。
  4. 手動測試邊緣案例。AI 生成的測試覆蓋了正常路徑,而不是競態條件。
  5. 從一開始就集中管理配置。分散問題會迅速惡化。
  6. 使用嚴格的 TypeScript。這是你對抗型別偏移的最佳防禦。
  7. 儘早構建 CI 閘道。它們在第一週內就能回本。

我會再做一次嗎?

絕對會。但我會在第一天就從 CLAUDE.md 開始,而不是第三週。我會記住,10 倍的生產力乘數也包含了 10 倍的錯誤後果乘數。

我們構建的平台——300 多個 AI 模型、統一的 API、多貨幣計費和 13 種語言的國際化——如果由傳統團隊來做,可能需要數月時間。我們在 30 天內就發布了。Bug 是真實存在的,但速度也是真實的。

AI 輔助開發並非魔法。它是一種新型的工程學科。就像所有學科一樣,它會回報那些尊重其約束的人。

常見問題

一名開發者真的能用 Claude Code 構建生產級平台嗎?

是的,但有前提條件。AI 以驚人的速度處理程式碼生成和重構,但你仍然需要強大的架構判斷力、自動化質量閘道,以及仔細審查一切的紀律。如果你不小心,10 倍的速度也意味著 10 倍快的 bug。

什麼是 CLAUDE.md?

CLAUDE.md 是一個專案級別的指令文件,AI 編碼助手會讀取它以獲取上下文。它包含 AI 應該遵循的編碼慣例、架構決策和約束。把它想像成你的 AI 隊友的入職培訓文件。

如何防止正式環境中出現 AI 生成的 bug?

自動化 CI 閘道至關重要:型別檢查、SSOT 審計、enum 同步驗證以及特定領域的安全閘道。核心見解是 AI 同時放大了生產力和錯誤,因此你需要自動化檢查來捕捉被放大的錯誤。

AI 輔助開發適合計費和支付系統嗎?

適合,但要格外小心。支付程式碼需要明確的競態條件處理、適當的鎖定機制和徹底的邊緣案例測試。AI 生成的測試往往覆蓋正常路徑,因此你必須手動測試失敗場景和並發操作。


LemonData 讓你通過單個 API 訪問 300 多個 AI 模型免費開始使用 並以 1 美元的額度測試平台。

Share: