剛剛，Anthropic 公司對外披露截止到 7 月 6 日的最新資料：其四個月前推出的 AI 編碼助手 Claude Code 已吸引 11.5 萬名開發者，且單週處理程式碼量達 1.95 億行，堪稱 AI 編碼市場中增長最快的開發者工具之一。不過，也有行業觀察人士指出，在統計週期內處理的 1.95 億行程式碼需謹慎解讀，因為單個程式碼變更在達到生產質量前可能經歷多次迭代與修正。
Menlo Ventures 的投資人 Deedy Das 稱，這一使用統計資料彰顯出 Claude Code 巨大的商業潛力。初步測算顯示，按當前的使用者採用模式，基於開發者每年為使用該服務支付約 1000 美元的假設，該工具的年化收入預估約達 1.3 億美元。也就是說， Claude Code 推出不過 4 個月就賺了 4300 萬美元（合約人民幣 3.08 億元）。
“哪個初級工程師每年能賺 1300 萬美元？這簡直是 Soham 級別的生產力。”不少網友都對 Claude Code 的盈利能力表示驚歎。據瞭解，Claude Code 支援開發者透過自然語言指令執行編碼任務，同時無需手動選擇上下文即可感知整個程式碼庫的全域性資訊，透過其終端原生設計及與 Anthropic 最先進語言模型 Claude Opus 4 的整合，與競爭對手形成差異化優勢。
同時，許多開發者提到，目前他們正從其他 AI 編碼助手切換到使用 Claude Code。一位開發者指出，“這不只是模型的功勞。真正讓 Claude Code 如此出色的，是其提示詞質量、工具整合和上下文管理能力。使用 Claude Code 至今，我幾乎沒見過一次工具呼叫失敗的情況，而 Cursor 卻經常出錯。一次性完成複雜的功能需求，簡直像變魔術一樣。Anthropic 的優勢在於，他們完全瞭解模型的工作原理，因此能精準最佳化提示詞和工具，讓其在編碼任務中表現卓越。”
另一位開發者則將 Claude 與 GitHub Copilot 對比：“Claude Code 的商業模式屬於典型的 SaaS 模式，分層訂閱計劃既能從獨立開發者處盈利，也能服務企業團隊；而將通用型 AI 與編碼專用 AI 捆綁的模式，相較於單功能程式設計助手更能提升使用者留存率。其終端優先的整合方式對高階使用者而言是一大優勢—— 儘管 Copilot 在整合開發環境（IDE）領域佔據主導地位，但 Claude 正瞄準那些習慣命令列操作、追求模型推理透明性與安全性的工程師群體。該市場的總體規模極為龐大，即便按當前定價僅獲取少量份額，其年化經常性收入（ARR）也有望突破 5000 萬至 1 億美元。真正的增長突破口在於團隊 / 企業版訂閱的向上銷售以及開源工作流帶來的網路效應 —— 若使用者採用率持續攀升，Claude 甚至可能撼動 Copilot 的市場壁壘。”
值得一提的是，近日，一款由 Sentry 工程總監、前 Specto 聯合創始人兼 CTO Indragie Karunaratne 純用 Claude Code 構建的 macOS 應用 Context 引發熱議，在這個專案的 2 萬行程式碼中，僅有不到 1000 行是手工編寫的。Indragie 在 2019 年領導一個工程師團隊構建了移動應用可觀測性平臺 Specto ，該系統成功部署到數百萬臺移動裝置的生產環境中，後於 2021 年 11 月被 Sentry 收購。
此外，Indragie 熱衷於以開發各種應用來作為副業，在他的儲存庫中“躺著”137 個尚未交付的專案。這次嘗試了 Claude Code 後，他激動地表示：“這次體驗中最令人興奮的部分並不是我開發的應用本身，而是我又能夠隨時隨地程式設計、釋出完善的副業專案了。這就像每天多給了我 5 個小時，而相應的每月只需要支付 200 美元。”
在一篇部落格中，Indragie 詳細闡述了其使用 Claude Code 完成的全部開發歷程，包括功能程式碼編寫、UI 介面生成、模擬資料生成甚至釋出指令碼，以及各款 AI 編碼工具的優缺點與如何運用它們來最大限度提高程式碼生成質量——特別是構建一款原生應用的情況下。
“智慧體不會讀心術”，Indragie 強調了“上下文工程”的重要性，同時建議，在要求編碼智慧體構建一項功能時，可以提供一份詳細的規範來引導模型。“AI 產品演示往往會突出展現用一句話提示詞建立完整應用程式的效果，但如果大家想要的不只是粗糙的原型，那就需要真正設定一套規範。”
以下是全文內容（經 InfoQ 進行不改變原意的整理和編輯）：
我最近釋出的 Context，是一款用於除錯 MCP 伺服器的原生 macOS 應用。我希望打造一款實用型的開發者工具，確保它在 macOS 平臺上順手易用，並由蘋果的 SwiftUI 框架提供支援。
我從 2008 年起就一直在為 Mac 平臺開發軟體，但這次的情況有點特殊：Context 幾乎 100% 由 Claude Code 構建而成。引導 Claude 構建軟體仍然需要一定技巧而且得多選幾次，但對於這個擁有 2 萬行程式碼的應用來說，粗略估算我親自手寫的部分還不到 1000 行。
我對 AI 編碼工具的初次體驗，始於嘗試整合在 VS Code 中的 GitHub Copilot。作為同類工具中的先驅，它當時讓我頗為驚豔：儘管初期只是自動補全功能，但效果出奇地高效——不同於傳統編輯器僅能補全符號名稱或函式簽名，它能基於上下文補全整個函式實現。這極大提升了生產力，但仍感覺大部分編碼工作需手動完成。
隨後，行業發展突飛猛進：Cursor 迅速崛起並加入 Agent Mode，Windsurf 等新競品也紛紛入局。所有產品都傾向於“智慧體”開發模式——不再依賴 LLM 一次性響應來實現自動補全，而是透過 LLM 迴圈呼叫各類工具完成更復雜的任務：收集程式碼庫上下文、讀取網頁與文件、編譯程式、執行測試、針對構建 / 測試失敗進行迭代等。
此前我並未深入嘗試這些新工具，因為當時沒有積極推進副業專案。但在 2025 年 2 月，一個意想不到的競爭者橫空出世：Claude Code 不像其他工具那樣是 VS Code 的分支，而是一款設計為完全在終端中使用的 IDE。它沒有傳統的程式碼編輯功能，也沒有充斥大量特性的複雜 UI，而是將“智慧體迴圈”置於核心位置——僅有一個輸入提示詞的文字框，別無他物。它並非用 AI 增強現有 IDE，而是直接取代了 IDE。
我最初並不完全相信這種使用者體驗是理想的，但相較於現有工具，其理念足夠新穎，讓我決定必須一試。
和許多從事高強度正職工作的工程師一樣，我有一大堆從未交付的副業專案。構建可執行的原型並非難事，但完成最後 20% 的工作往往需要耗費大量時間和精力，以至於六年來我都沒能釋出一個副業專案。
此時，我開始嘗試使用 Claude Code 及其對 MCP（模型上下文協議）伺服器的支援。Anthropic 將 MCP 設計為一種開放標準，使智慧體能夠訪問工具和其他上下文來完成特定任務。例如，Sentry MCP 伺服器提供了一些工具，允許智慧體獲取包含堆疊跟蹤和其他有用除錯上下文的問題，甚至可以呼叫 Sentry 自己的 bug 修復智慧體。
然而，構建和測試 MCP 伺服器的過程十分繁瑣：MCP 伺服器透過標準輸入 / 輸出流或使用伺服器傳送事件（SSE）的 HTTP 與客戶端通訊，使伺服器能夠將響應流式傳輸給客戶端。這不像呼叫 CLI 或使用 curl 向服務傳送請求那麼簡單。
雖然有一個名為 MCP Inspector 的官方工具允許開發人員測試伺服器功能，但作為一名長期的 macOS 和 iOS 開發人員，我想嘗試構建一個原生應用來解決這個問題。我認為這將是一次拓展 AI 智慧體邊界的絕佳學習體驗，並且希望最終能開發出一個有用的產品。
首先必須說明，Claude Code（搭配最新的 Sonnet 4 和 Opus 4 模型）在程式碼編寫方面確實表現出色。它當然算不上頂尖 1% 的程式設計師，但我認為 Claude 的輸出質量顯著優於普通開發者的平均水平。
當你描述想要實現的功能時，Claude 能夠：
-
定位並讀取專案中與該功能相關的現有原始碼 -
理解程式碼風格和設計模式 -
讀取你提供的額外文件或規格說明 -
生成實現功能的程式碼 -
生成測試用例驗證功能行為 -
構建程式並執行測試 -
針對編譯錯誤和測試失敗進行迭代，直至構建和測試透過 -
檢視截圖或控制檯日誌，定位並修復 bug
真正令人驚歎的是，它完成這一系列工作的時間僅為人工實現的一小部分。試想一下，讓一個對專案毫無背景的新員工在幾分鐘內交付完整功能，這就是 Claude 的效率。
我決定使用最新的蘋果開發技術構建應用：基於 macOS 15.5 的 Swift 6.1 和 SwiftUI。由於模型訓練資料中的 Swift 程式碼遠少於 Python 或 JavaScript 等通用語言，我很好奇 Claude 在編寫 Swift 程式碼時的表現。
好訊息是，Claude 能夠熟練使用 Swift 5.5 版本前的大多數語言特性（Swift 併發機制在 5.5 版本引入）。Swift 併發機制是對語言的重大變革，即便對人類開發者而言，正確使用也頗具難度。當 Claude 在現代框架和遺留框架之間做選擇時容易混淆：它經常在有更現代的 Swift 替代方案時仍嘗試使用遺留的 Objective-C API，或用 AppKit/UIKit 替代 SwiftUI。
不過，Claude 生成的 SwiftUI 程式碼執行效果相當不錯：通常能準確呈現 UI（儘管樣式稍顯粗糙），經過進一步迭代可最佳化為設計精良、易用的介面。
在生成 UI 程式碼時，Claude 經常遇到一個本質上是 Swift 語言自身侷限的問題：UI 程式碼的型別表示式往往過於複雜，導致編譯器丟擲可怕的錯誤——“編譯器無法在合理時間內完成此表示式的型別檢查”。解決方法是，將檢視主體重構為更小的表示式。值得慶幸的是，Claude 非常擅長在不破壞實現的前提下完成此類重構，甚至有時在輸出中看到編譯錯誤時會主動進行最佳化。
你可以透過建立 CLAUDE.md 檔案提供使用現代 API 的基本說明，幫助 Claude 避開常見陷阱。以下是我為 Context 專案編寫的 CLAUDE.md 檔案片段：
即便這套規則集所需投入相對較低，也能產生不錯的效果，但你還可以更進一步：例如，Peter Steinberger 的 agent-rules 程式碼庫中包含了一系列規則，你可以將這些規則新增到你的智慧體中，既可用於通用編碼規範指導，也能更具體地幫助編寫更優質的 Swift 程式碼。
如果 Claude 沒能一次性生成擁有良好設計的 UI，你可以直接要求它“做得更漂亮 / 優雅 / 易用些”。我發現只要這麼輕鬆一提，就能得出意想不到的效果。當然，大家也可以更有條理地提出要求，比如讓它“提出一些關於如何讓 UI 更美觀的建議”，而它會生成一份設計調整清單以供選擇。
如果從中發現了 UI 錯誤或者需要調整的 UI 元素，則可以截圖並直接將影像貼上到 Claude Code 當中。未來應該會有更好的自動化方法，但目前無論面向哪種前端平臺進行構建，我的這種方法都能良好起效。
隨著主流 AI 的出現，業界迅速定義了一門新學科：提示詞工程。提示詞工程的理念在於，使用者應當精心設計提示詞，才能讓模型生成最優質的輸出結果。這事之前或許是正確的，但根據我的個人經驗，在使用較新模型時，專注於提示詞工程反而沒啥必要。
如今的模型在處理不太完美的輸入和理解使用者意圖方面表現得很好。這不光是因為模型本身更強了，還因為它們融合了思維鏈（CoT）提示。也就是說，我們可以用模糊的描述、不完整的句子以及糟糕的拼寫和語法來提示模型，並保證它仍能相對準確地理解要求，並將問題拆分成一系列執行步驟。
在使用 Claude Code 或其他類似工具時，我們隨時會遇到的限制就是上下文視窗。Anthropic 家的兩款最新模型（Sonnet 4 與 Opus 4）都擁有 20 萬 token 的上下文視窗，意味著它們可以一次處理相當於 20 萬 token 的文字。每次提示和回覆都會消耗更多上下文，而模型在上下文視窗接近耗盡時，效能往往也會下降。
Claude 甚至會提供一個指示器，顯示剩餘的上下文配額，之後開始“壓縮”對話。所謂壓縮，就是對當前對話進行總結，並使用該摘要生成一個新的上下文視窗，以便使用者可以繼續提示。壓縮過程並不完美，可能會遺漏先前對話中的重要細節，或者使用先前錯誤中產生的低質量上下文來生成新的上下文。
使用有限上下文標記生成最高質量的輸出，或者說“上下文工程”，是有效應用編碼智慧體的核心挑戰。
我設定了一個所謂“啟動”過程，在此期間我不會讓智慧體直接執行任務，而是讓它先讀取額外的上下文，以增加生成高質量輸出的機率。
預設情況下，它會讀取使用者範圍和專案範圍內的 CLAUDE.md 檔案內容，大家也可以要求它讀取特定的文件或原始碼以獲取關於特定任務的上下文。下面是我要求它讀取某些現有原始碼及來自 Web 的規範性資訊的提示詞：
在此之後，Claude 會使用“搜尋”和“閱讀”工具查詢並閱讀原始檔，並使用“獲取”工具從 GitHub 下載 Markdown 檔案。如果要求總結，則 Claude 會嘗試思考從原始碼處獲取的內容，並將結論與上下文聯絡起來以提高後續任務效能。
在程式碼合理使用到第三方依賴項，或者引入可能比模型知識的截止日期更晚的新 API 時，啟動過程就顯得尤為重要。Context7 和 llm.codes 等工具可以解決將文件格式化為模型可用純文字格式的問題。
在要求 Claude 構建一項功能時，提供一份詳細的規範對於引導模型至關重要。如果不加努力，Claude 將無法構建任何重要功能。AI 產品演示往往會突出展現用一句話提示詞建立“完整應用程式”的效果，但如果大家想要的不只是粗糙的原型，那就需要真正設定一套規範。
這套規範不用寫得太好，甚至可以用語音轉錄的方式把自己的想法一股腦灌輸進去（我個人更喜歡打字，但確實是各種方式都行）。以下是我寫給 Claude 的一份規範示例，要求它為我的應用構建一項新功能：
看起來內容不少，但仍要比我親自編寫程式碼來實現功能快得多。
Claude 會傾向於缺少充分背景知識的情況下貿然進入實驗階段，因此導致結果質量低下。因此我設定了另外一種智慧體啟動策略，即要求 Claude 使用其擴充套件思維模式並首先制定計劃。擴充套件思維由下面這組神奇的關鍵詞啟用：“思考、認真思考、更努力地思考、極致地思考”。這些表述不僅僅是對模型的建議，更是能夠啟用不同層次擴充套件思維的特定語句。極致思考會消耗最多 token，但也能產生最佳結果。如果需要迭代計劃，也可以在提示詞中明確強調，在使用者接受現有計劃之後再進一步加以實施。
總的來說，我強烈建議大家閱讀 Anthropic 釋出的《Claude Code：智慧體編碼最佳實踐》（https://www.anthropic.com/engineering/claude-code-best-practices）一文。我在此前討論的許多技術，都在這篇文章中有所涉及，建議大家將此作為充分運用 Claude Code 乃至一切其他編碼智慧體的必讀文章。
Claude 最重要的功能，在於它能夠獨立驅動反饋迴圈，使其得以變更、測試變更並收集失敗的上下文資訊，進而嘗試下一次迭代。其中的核心迴圈包括：
-
構建：Claude 應當知曉如何編譯你的應用。Claude 已經掌握了透過 swift build 編譯 Swift 包的能力，但對於我設定的 macOS 應用開發目標，它往往找不到正確的 xcodebuild 呼叫。XcodeBuildMCP 能夠為模型提供一套簡化工具來構建並執行應用，最終順利解決了這個問題。
-
測試：Claude 應當能夠構建並執行指定的測試，並檢視測試結果。同樣的，Claude 可以透過 swift test 為 Swift 包提供開箱即用的測試功能。我還沒有測試過它能否執行應用程式 /UI 測試，但嚴重懷疑同樣需要藉助 XcodeBuildMCP 才能實現。
-
修復 bug：Claude 已經知曉如何透過新增除錯日誌來除錯錯誤。可問題在於，它無法像使用者那樣直接跟應用互動，從而引導應用發出正確的日誌記錄。也就是說，我們必須手動與應用互動，並將日誌從控制檯複製 / 貼上到 Claude 當中。這樣做雖然也不麻煩，但意味著問題解決無法自主進行，除非我們預先編寫單元測試或者 UI 測試來封裝整個操作過程。目前市面上已經出現了一些自動化解決方案，例如面向瀏覽器應用的 playwright-mcp，但我不清楚是否存在面向原生應用且經過充分測試的同類方案。
-
修復使用者體驗問題：之前我提到過，大家可以將截圖貼上到 Claude 中，要求它對 UI 問題進行迭代。也許這裡可以使用 Peekaboo 之類的工具來自動截圖，但同樣存在需要手動操作應用才能使其達到理想狀態的問題。
由於 Claude Code 是一款封裝了通用模型的智慧體，因此在迭代應用本身時，我們還可以使用它來協助完成各種非編碼任務。例如編輯方案，甚至透過向模型徵求應用功能改進建議來規劃版本更新。
我還發現另外一個有用的小功能，就是在將真實資料匯入應用之前，它能夠生成模擬資料。在構建 Context 時，我先是構建了一個 Swift MCP 客戶端庫的實現。但接下來我想換個方向，做點 UI 原型設計。一般來說，生成逼真的模擬資料往往過程繁瑣，我壓根不想沾邊。但 Claude 在幾秒鐘內就生成了質量極高的模擬資料。我在 UI 中與朋友們分享的首批應用截圖，就是基於模擬資料製作而成，而且看起來足夠逼真，能讓大家準確理解應用從真實 MCP 伺服器渲染資料時的呈現效果。
特別是對 MCP 來說，模擬資料尤其重要。因為目前大部分 MCP 伺服器除工具之外，並沒有使用到規範中的多數功能，而我們肯定還是需要對這些功能的 UI 進行驗證。
釋出流程最後 20% 的痛苦部分，在於自動化應用的釋出流程，特別是在 macOS 上。我們需要處理程式碼簽名、程式碼公證和打包等複雜操作。在之前的專案中，我會在此階段除錯並設定 Fastlane，再圍繞它構建一系列基礎 Python 自動化框架。但這次有了 Claude，一切都不一樣了。
經過幾個小時的迭代，我讓 Claude 編寫了一份釋出指令碼。此指令碼負責執行以下操作：
-
檢查環境是否已正確設定並安裝有正確工具。 -
從 git 提交生成變更日誌條目，並將其與手寫的變更日誌條目合併，進而生成 HTML 版本說明。 -
構建應用，進行協同設計、公證，並將其打包成 DMG 檔案。 -
生成 Sparkle 應用廣播，以便向現有使用者自動釋出更新。 -
標記版本並將結果釋出至 GitHub。 -
將除錯符號上傳至 Sentry 以實現崩潰報告符號化。
在指令碼執行完全正常之後，我使用一條簡單的單行提示詞來美化 CLI 輸出，並最終得到如下結果：
這是 2000 行 Python 程式碼，如果是我手動編寫，哪怕是完成了自動化步驟的部分，我也沒那個精力再具體調整輸出美觀度。有了這套指令碼，我能在每次版本釋出時省下幾十分鐘的手調時間。只需幾段自然語言規範，Claude 就能除錯並修復我在執行指令碼後發現的問題。
在為這個專案工作時，我突然意識到，自己自始至終使用的兩款工具就只有 Claude Code 和 GitHub Desktop。絕大多數時候，我不需要任何典型的編輯器功能，比如檔案樹、原始碼編輯器、擴充套件程式等等。我偶爾會使用 Xcode 手動編輯，但這種情況殊為少見，而且我也沒用上 Xcode 的多數特有功能（SwiftUI 預覽、檢視偵錯程式等）。
考慮到未來的編碼智慧體只會越來越強，所以我猜測未來的 IDE 也將與如今我們熟悉的樣子截然不同。
Cursor、Windsurf 和 Copilot 都始於 VS Code，並各自找到了自己的發展路線。但目前來看，它們只是粗糙地把 AI 融入到在設計上並未考慮到 AI 元素的傳統編輯器。從本質上講，VS Code 跟 20 年前的 JetBrains IDE 並沒有多大區別。我們還看到 Warp 這樣的專案嘗試從現代化終端模擬器轉型為代理式開發環境，但儘管我非常喜歡 Claude Code，但也不覺得終端就一定代表著理想的使用者體驗。
我相信，未來的 IDE 將專注於幫助開發者預置智慧體的上下文並設定反饋迴圈，這對幫助智慧體成功完成編碼至關重要。這方面的使用者體驗將決定 IDE 的市場支援率——我無法準確預測具體會如何，但原始碼編輯器的地位恐怕將逐漸下降。
對我來說，這次體驗中最令人興奮的部分並不是我開發的應用本身，而是我又能夠隨時隨地程式設計、釋出完善的副業專案了。這就像每天多給了我 5 個小時，而相應的每月只需要支付 200 美元。
參考連結：
https://ppc.land/claude-code-reaches-115-000-developers-processes-195-million-lines-weekly/
https://www.indragie.com/blog/i-shipped-a-macos-app-built-entirely-by-claude-code
宣告：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。
🔥GenAl 應用發展的主要制約因素取決於資料質量，而非演算法。面對 GenAl 時代的資料挑戰，騰訊雲提出 Data+Al 下一代資料智慧平臺解決方案，並結合騰訊雲前沿技術探索與客戶實踐，為企業構建 GenAl 時代的高價值資料資產提供實用指南。立即掃碼或點選【閱讀原文】免費下載《Data+Al 下一代數智平臺建設指南》白皮書，解鎖企業數智化升級最優路徑。