去年，我們交付了一個價值 200 萬美元的平台。整個工程團隊？一位資深架構師和 Claude Code。沒有海外團隊。沒有一大批承包商。只有一個人，他知道自己在構建什麼，與能夠實際編寫生產代碼的 AI 配對。

我寫這篇文章不是為了炒作 AI。我在炒作周期中吃過足夠多的虧。我寫這篇文章是因為這個項目上發生的事情從根本上改變了我對團隊組成、項目估算以及當你將深厚的架構知識與 AI 輔助開發配對時實際可能發生的事情的思考方式。數字不會說謊 — 我們在不到 5 個月內達到了傳統 6-8 名工程師大約 18 個月才能達到的里程碑。

讓我詳細告訴你具體是怎樣的。

目錄

項目：我們實際在構建什麼

我不能說出客戶的名字 — 保密協議 — 但我可以描述該平台。這是一個 B2B SaaS 產品，處於物流領域。多租戶架構。即時追蹤儀表板。跨組織、團隊和單個用戶的複雜基於角色的訪問控制。與 14 個不同的第三方 API 集成（航運公司、支付處理器、海關數據庫）。面向客戶的門戶和內部管理系統。

在典型的代理機構設置中，你會配置一名技術主管、2-3 名資深開發人員、幾名中級開發人員、一名專職 DevOps 人員，也許還有一名 QA 工程師的那種項目。客戶從另一個代理機構獲得的原始估算是 320 萬美元，20 個月，9 人團隊。

我們提議 200 萬美元、5 個月、一位架構師。他們認為我們瘋了。老實說？我也有點這麼認為。

為什麼是一位架構師而不是整個團隊

關於小團隊的反直覺之處在於：9 人項目上的溝通開銷是巨大的。Fred Brooks 在 1975 年寫過這個，時至今日仍然成立。有 9 名工程師，你有 36 個潛在的溝通通道。會議倍增。合併衝突成為日常儀式。總有人在等待其他人的拉取請求審查而被阻止。

有一位架構師，整個系統狀態存在於一個人的腦海中。沒有在拉取請求中解釋你的方法所帶來的上下文切換稅。沒有委員會設計。沒有兩小時的衝刺規劃會議。

但是一個人只能打字這麼快。一個人只能在工作記憶中容納這麼多文件。一個人在下午 6 點會累，在晚上 8 點會犯錯誤。

這就是 Claude Code 的切入點。不是作為架構師的替代品，而是作為力量倍增器。架構師做出每一個決定。Claude Code 以相當於 4-5 名開發人員的速度執行。

架構師的角色

我們的架構師 — 我們叫他 Marcus — 有 15 年的經驗。他以前在這個規模上構建過系統。他在這個項目上的工作是：

  • 系統設計和架構決策
  • 定義模塊邊界和數據契約
  • 編寫關鍵路徑代碼（認證、支付處理、數據管道編排）
  • 審查和完善 Claude Code 生成的所有內容
  • 基礎設施和部署架構
  • 安全審計

他不做什麼：寫樣板 CRUD 端點、從設計構建 UI 組件、為直接的邏輯編寫單元測試、創建數據庫遷移或搭建新的服務框架。Claude Code 處理所有這些。

Claude Code 如何真正融入實際工作流

讓我具體說明「使用 Claude Code」在日常實際工作中的樣子，因為市場營銷材料不會捕捉現實。

Marcus 會以結構化的方式開始每天的工作定義。不是含糊不清的提示，比如「為我構建一個用戶管理系統」。相反，他會創建我們開始稱之為「架構簡報」的東西 — 詳細的文檔，指定：

  1. 模塊的責任和邊界
  2. 具有精確字段類型和關係的數據模型
  3. API 契約（端點、請求/響應形狀）
  4. 業務規則和邊界情況
  5. 錯誤處理期望
  6. 需要與哪些現有模塊集成

然後他會將這些按塊提供給 Claude Code。典型的會話看起來像這樣：

# Marcus 會使用 Claude Code CLI 在項目目錄中工作
# 首先，建立上下文
claude "閱讀 /src/modules/shipment/ 和 /src/lib/database/schema.ts。
在我們構建發票模塊之前，我需要你理解現有的模式。"

# 然後，帶有架構簡報的實際構建指令
claude "按照 /docs/briefs/invoicing.md 中的架構簡報構建發票模塊。
遵循與發貨模塊完全相同的模式用於服務層、存儲庫層和路由處理程序。
使用現有的錯誤處理中間件。為服務層中的所有業務邏輯編寫測試。"

Claude Code 然後會生成模塊 — 通常是 15-30 個文件，包括類型、架構、服務、存儲庫、路由處理程序、中間件和測試。Marcus 會審查輸出、進行更正並進行迭代。整個中等複雜模塊的周期耗時約 2-3 小時，而不是資深開發人員需要的 2-3 天。

迭代循環

這是關於 AI 輔助開發的不為人所知的事情：第一次輸出很少是生產就緒的。它大約 70-80% 完成。但剩下的 20-30% 是架構師的專業知識最重要的地方。

Marcus 養成了一種節奏：

  1. 生成 — Claude Code 生成初始實現
  2. 審查 — Marcus 讀遍每個文件，標記問題
  3. 完善 — 反饋給 Claude Code 的具體更正
  4. 加固 — Marcus 手動處理安全關鍵部分
  5. 測試 — 運行生成的測試，添加 Claude 遺漏的邊界情況

這個循環通常在每個模塊中經歷 2-3 個周期。到項目的第三個月，Claude Code 生成的第一次代碼更接近 85-90% 生產就緒，因為代碼庫已經建立足夠的模式供其遵循。

技術棧和架構決策

我們刻意選擇了堆棧以最大化 AI 輔助的生產力：

  • Next.js 14（應用程序路由器） — 用於客戶門戶和管理儀表板
  • Node.js 配 Fastify — 用於 API 層（與 Next.js 分離）
  • PostgreSQL — 主要數據庫
  • Redis — 快取、會話管理、實時發布/訂閱
  • Drizzle ORM — 類型安全的數據庫訪問
  • Turborepo — 單一倉庫管理
  • Vercel — 前端部署
  • AWS（ECS Fargate） — API 和背景工作程序

我們選擇 Next.js 是因為模式已經確立，Claude Code 在應用程序路由器約定上有深度的訓練數據。這比人們想象的重要得多。如果我們選擇了像基於 Rust 的後端配 HTMX 這樣的奇特東西，AI 輸出質量會大幅下降。你可以在我們的 大規模 Next.js 開發方式中了解更多。

Drizzle ORM 是這個項目上相對於 Prisma 的有意選擇。Claude Code 生成更好的 Drizzle 架構，因為它們只是 TypeScript — 沒有自定義 DSL 可以搞錯。另外，當你快速生成大量架構更改時，遷移故事更簡單。

// 示例：Claude Code 在第一次通過時生成了這個發票架構
// 需要最少的更正
import { pgTable, uuid, varchar, decimal, timestamp, pgEnum } from 'drizzle-orm/pg-core';
import { relations } from 'drizzle-orm';
import { shipments } from './shipments';
import { organizations } from './organizations';

export const invoiceStatusEnum = pgEnum('invoice_status', [
  'draft', 'pending', 'sent', 'paid', 'overdue', 'cancelled', 'refunded'
]);

export const invoices = pgTable('invoices', {
  id: uuid('id').primaryKey().defaultRandom(),
  organizationId: uuid('organization_id').notNull().references(() => organizations.id),
  shipmentId: uuid('shipment_id').references(() => shipments.id),
  invoiceNumber: varchar('invoice_number', { length: 50 }).notNull().unique(),
  status: invoiceStatusEnum('status').notNull().default('draft'),
  subtotal: decimal('subtotal', { precision: 12, scale: 2 }).notNull(),
  taxAmount: decimal('tax_amount', { precision: 12, scale: 2 }).notNull().default('0'),
  totalAmount: decimal('total_amount', { precision: 12, scale: 2 }).notNull(),
  currency: varchar('currency', { length: 3 }).notNull().default('USD'),
  dueDate: timestamp('due_date', { withTimezone: true }).notNull(),
  paidAt: timestamp('paid_at', { withTimezone: true }),
  createdAt: timestamp('created_at', { withTimezone: true }).notNull().defaultNow(),
  updatedAt: timestamp('updated_at', { withTimezone: true }).notNull().defaultNow(),
});

export const invoiceRelations = relations(invoices, ({ one, many }) => ({
  organization: one(organizations, {
    fields: [invoices.organizationId],
    references: [organizations.id],
  }),
  shipment: one(shipments, {
    fields: [invoices.shipmentId],
    references: [shipments.id],
  }),
  lineItems: many(invoiceLineItems),
}));

Claude Code 做得好的方面

讓我們具體說明。以下是 Claude Code 真正加速開發的地方：

樣板和 CRUD 操作

這是顯而易見的。生成 REST 端點、請求驗證架構（我們使用了 Zod）、響應序列化器、基本服務方法 — Claude Code 在幾分鐘內就完成了這些。在整個項目中，我們估計有大約 180 個 API 端點。其中大約 140 個是標準 CRUD 或查詢操作，Claude Code 在最少修改的情況下生成。

測試生成

Claude Code 在整個項目中編寫了大約 2,400 個測試。它們都完美嗎？不。大約 15% 需要大量的返工。但有 85% 的測試套件生成和工作是一個巨大的時間節省器。Marcus 將他的測試精力集中在集成測試和 Claude Code 無法預期的棘手邊界情況上。

UI 組件開發

客戶門戶有大約 60 個獨特的頁面視圖。對於每一個，Marcus 會提供 Figma 設計參考和 API 契約，Claude Code 會生成 React 組件、數據獲取的 hooks（我們使用了 TanStack Query）、使用 React Hook Form + Zod 的表單處理，以及加載/錯誤狀態。輸出始終很好 — 第一次生成時也許 75% 的像素精確度。

數據庫遷移和架構演變

隨著需求的演變（它們總是會的），Claude Code 平穩地處理架構遷移。描述你需要的更改，它生成遷移文件、更新架構、更新受影響的查詢，並調整 TypeScript 類型。過去需要 45 分鐘的仔細重構會議變成了 10 分鐘的審查和批准周期。

文檔

Claude Code 生成了 API 文檔、內聯代碼註釋、README 文件，甚至操作手冊文檔。Marcus 會審查和調整，但基線輸出真的很有用。我們最終得到的文檔比我見過的 90% 的項目都更好，只是因為生成它的成本很低。

Claude Code 失敗的地方以及我們的應對方式

這一部分比成功故事更重要。如果你計劃以這種方式使用 AI，你需要知道牆在哪裡。

多個依賴項的複雜業務邏輯

發貨路由引擎 — 需要同時考慮航運公司可用性、成本優化、海關要求、交付窗口和容量限制 — 超出了 Claude Code 能處理的範圍。它會生成看起來可信的東西，但有微妙的邏輯錯誤，可能花費真金白銀。

Marcus 手工編寫了這個模塊。花了大約兩週。這正是有資深架構師而不是試圖通過 AI 解決所有事情所合理的那種工作。

安全關鍵代碼

我們從未在沒有逐行審查的情況下相信 Claude Code 處理認證流程、支付處理或加密。好東西 — 它有時會生成在技術上可用但缺少邊界情況的 JWT 驗證，比如令牌過期時鐘偏差，或在使用 ORM 之前沒有適當清理輸入進行數據庫查詢。

經驗法則：如果這段代碼中的錯誤可能會損失金錢或洩露數據，人類編寫它，另一個人類審查它。

長程架構一致性

到第三個月，代碼庫足夠大，Claude Code 有時會「忘記」之前建立的模式，即使提供了上下文。它可能在一個模塊中使用與另一個模塊不同的錯誤處理方法。Marcus 必須警惕捕捉這些不一致。

我們通過維護一個活的「約定」文檔來減輕這一點，該文檔包含在每個 Claude Code 會話中。把它想象成一個風格指南，但用於架構模式。

性能優化

Claude Code 生成有效的代碼，但並不總是生成快速的代碼。執行 N+1 獲取的數據庫查詢。不必要地重新渲染的 React 組件。加載超過需要的 API 端點。

Marcus 在審查時間的約 20% 上花費在性能優化上。不是交易破壞者，但需要預算的東西。

經濟學：成本分解和投資回報率

這是每個人都想看到的部分。真實數字。

成本類別 傳統團隊（估計） AI 加速（實際）
工程師工資（18 個月 / 5 個月） $1,890,000 $175,000
Claude Code API / 訂閱 $0 $12,400
基礎設施（開發/分段） $48,000 $8,200
項目管理 $216,000 $0*
QA / 測試 $180,000 $22,000**
設計（承包） $120,000 $95,000
DevOps / 基礎設施設置 $96,000 $35,000
總計 $2,550,000 $347,600

Marcus 使用 Linear 進行任務追蹤的自管。沒有 PM 開銷。

*在最後 6 週內簽約了 QA 專家。

Claude Code 成本分解為大約每月 $2,500。這是 Max 計劃（訂閱 100 美元/月）加上擴展會話的 API 成本。某些天 Marcus 在繁重生成會話期間會消耗 150-200 美元的 API 調用。大多數日子是 40-80 美元。

該項目按 200 萬美元計費。我們的總交付成本低於 35 萬美元。讓我讓你計算邊際值。

速度比較

里程碑 傳統時間表 AI 加速時間表
架構與設計 6 週 3 週
核心平台（認證、多租戶、基礎 API） 10 週 3 週
功能開發（所有模塊） 32 週 10 週
集成（14 個第三方 API） 12 週 4 週
測試與 QA 8 週 3 週
部署和加固 4 週 2 週
總計 72 週 25 週

考慮使用 AI 加速開發的團隊的經驗教訓

經過這個項目，我一直在思考這對我們未來如何構建軟件意味著什麼。以下是我會告訴任何考慮這種方法的團隊或代理機構的內容。

你仍然需要一位資深架構師。也許現在比以往任何時候都更需要。

AI 不會消除專業知識的需要 — 它放大你帶來的任何專業知識（或缺乏）。使用 Claude Code 的初級開發人員會以更快的速度交付初級質量代碼。使用 Claude Code 的資深架構師會以以前不可能的速度交付資深質量代碼。

最壞的可能情況是一個認為自己是資深開發人員的中級開發人員使用 AI 生成他們無法適當評估的代碼。這就是你如何得到看起來表面上很好但在負載下崩潰的代碼庫。

到處都採用約定優於配置

你的代碼庫的模式越可預測，AI 的表現就越好。我們在每個模塊中使用了相同的文件結構、命名約定和代碼組織。這種一致性在 Claude Code 學習匹配現有模式時帶來了巨大的紅利。

如果你在使用 無頭 CMS 架構，對內容類型、API 路由和組件結構有嚴格的約定會使 AI 生成的代碼的可靠性大幅提高。

投資於架構簡報

Claude Code 輸出的質量與 Marcus 架構簡報的質量直接相關。含糊不清的指令產生含糊不清的代碼。帶有明確數據模型、業務規則和集成需求的詳細簡報生成接近生產就緒的代碼。

我們估計 Marcus 花費了約 30% 的時間編寫架構簡報和審查輸出，而傳統團隊會花費在實際實現上的 70% 時間被 Claude Code 處理。

AI 輔助開發改變定價模型

如果你是一個代理機構，這是不舒服的對話。當一位架構師能夠交付過去需要 8 人團隊才能做到的事情時，你如何定價？我們相信基於價值的定價 — 客戶為結果付費，而不是小時數。無論需要 1 個人還是 10 個人來構建它，該平台的價值都是 200 萬美元。

如果你有興趣了解這種方法對你的項目可能如何工作，我們的 定價頁面詳細介紹了我們在這個新現實中如何思考項目範圍。

並非每個項目都適合這個模型

這是因為：

  • 需求清晰（物流是一個成熟的領域）
  • 我們有一位真正的資深架構師
  • 技術棧是主流的（良好的 AI 訓練數據）
  • 客戶信任我們在沒有微觀管理團隊規模的情況下交付

有模糊需求的項目、大量 R&D 組件的項目，或專門領域的項目（醫療設備、具有監管要求的金融工具）需要更多人類判斷，應相應配置人員。

對於使用像 Astro 這樣的框架構建的項目，其中生態系統更新且 AI 訓練數據更薄，與 React/Next.js 項目相比，你會看到 AI 工具帶來的加速更少。

常見問題

Claude Code 實際上每月要花多少錢進行大量開發使用？

在這個項目中，我們平均每月花費 $2,500。Claude Max 訂閱是 $100/月（或 2025 年初為更高級的 $200/月），API 使用取決於你生成的代碼量。繁重的日子會在 API 成本中消耗 $150-200。輕度審查和完善日子是 $40-80。Anthropic 還推出了 Max 計劃，每月 200 美元，包括可能降低可變成本的重要使用。

初級開發人員能夠以相同的方式使用 Claude Code 嗎？

不能，這一點很重要。Claude Code 放大你現有的技能水平 — 它不會替代架構知識。使用 Claude Code 的初級開發人員會更快地生成代碼，但他們不會捕捉資深工程師立即發現的微妙錯誤、安全問題、性能問題或架構不一致。你需要有人能夠評估輸出，而不只是接受它。

代碼質量如何 — AI 生成的代碼是否可維護？

這完全取決於你給它的限制。我們生成的代碼通過了與手寫代碼相同的 linting 規則、類型檢查和代碼審查標準。訣竅是在項目早期建立強大的模式，以便 AI 有好的例子可以遵循。我們維護了一個活的約定文檔，包含在每個 Claude Code 會話中。在啟動後六個月，維護該平台的團隊沒有報告任何異常的維護負擔。

這種方法對於前端繁重的項目是否有效？

有效，但有注意事項。Claude Code 在生成 React 組件、表單處理、數據獲取 hooks 和狀態管理代碼方面表現出色。在從設計生成像素完美的 CSS 佈局方面可靠性較低 — 你會需要更多的迭代周期來實現視覺拋光。我們發現它在後端代碼的 85-90% 相比之下，在第一次傳遞 UI 生成上約 75% 準確。

當只有一個開發人員時，你如何處理代碼審查？

Marcus 自己審查了 AI 生成的每一行代碼。我們還在項目期間邀請了一位簽約安全專家進行了兩次重點審計會議（第 12 週和第 22 週）。在最後階段，QA 專家加入了六週。缺乏同儕代碼審查是真正的風險 — 我們使用自動化工具減輕了它（TypeScript 嚴格模式、激進規則的 ESLint、具有覆蓋閾值的 Vitest）和外部審計。

當 Claude Code 生成錯誤代碼時會發生什麼？

它經常發生。第一次通過很少完美。我們將這一期望融入了工作流 — 生成、審查、完善、加固。大多數錯誤在 Marcus 的審查周期中被捕捉。自動化測試套件（也主要是 AI 生成但由人類審查）捕捉回歸問題。關鍵見解是調試 AI 生成的代碼比從頭寫入正確的代碼要快，因為你是從大多數正確的東西開始的。

這僅對於全新項目是否可行，還是對現有代碼庫也有效？

Claude Code 實際上對現有代碼庫效果很好，因為它可以閱讀和理解現有的模式。在這個項目中，後期模塊受益於以早期模塊作為參考。此後，我們在現有客戶項目上針對功能添加使用了 Claude Code，獲得了良好的結果。關鍵是為它提供足夠的現有約定和模式的上下文。如果你的代碼庫不一致或文檔不足，AI 生成的添加將繼承這種不一致。

你會再做一次嗎？

絕對會。我們已經在做了。另外兩個項目現在使用這種模型運行 — 一個有單個架構師，另一個有兩名工程師用於更複雜的系統。經濟學太引人注目了，不能忽視。但我想明確一點：這不是關於替代開發人員。它是關於改變資深架構師輸出的比率。你仍然需要人類的專業知識。你只是需要更少的人類打字。如果你在考慮一個項目並想探索這個模型可能看起來像什麼，聯繫我們 — 我們很樂意談論它是否適合。