作者 | Indragie Karunaratne

編譯 | 蘇宓

出品 | CSDN（ID：CSDNnews）

“開發工作即將迎來一次徹底重置，而大多數人還毫無準備。”

這是 Reddit 上一篇爆火帖子的標題，也是一位資深程序員在深入使用 Claude Code（搭載 Opus 4、Max 模式）之后，得出的明確判斷。他寫道：

• 它已經能完成 100% 的編碼工作。不是協助，不是輔助，是直接全權代勞。而現在才剛過半年的時間。

• 過去我們說“Python 開發”、“React 工程師”，這種角色定義已經過時了。今后我不會再按語言招聘，我會招能解決問題的人——無論用什么技術棧。語言的門檻已經不復存在。

• 現在再問“我應該學哪種編程語言？”這個問題，幾乎沒有意義了。真正有價值的技能，是系統設計、架構、DevOps、云原生能力——那些原本就把初級和高級工程師區分開的部分。這才是未來的核心競爭力。

• 至于設計這份職業？已經岌岌可危了。Figma Make（還在測試版）就已經能自動生成品牌識別、UI 和美觀的上線級網站，背后還是 Claude Sonnet 和 Opus 驅動。說實話，我已經在想：一年后我是否還需要設計師？

• 幾個月前，花 40 美元用 Cursor 都讓我覺得貴。現在我為 Claude Max 付 200美元/月，反而覺得超值。如果保持當前能力，我甚至愿意花 500 美元。等到 Opus 5 出來，它可能直接突破天花板。

• 上周，我完成了一件拖了 10 年的事：用一周時間做出了一個上線級桌面應用。代碼審查通過，結構清晰，構建包上線到 Launchpad。UI/UX 和性能？甚至比很多同類產品還強。只用一周時間。

• 生產力已經爆炸式提升。以前幾個月才能完成的項目，現在一周內就能搞定。下一代人類，將把這種“高生產力”當成一種進化優勢。

這番言論一出，在開發圈激起了廣泛討論，有人附議，有人質疑。但與此同時，另一位開發者 Indragie Karunaratne 選擇不談趨勢、不談理論，而是直接投入實戰。

他親手用 Claude 構建出一款完整的 macOS 原生應用——Context。這不是小打小鬧的 Demo，而是一個真正上線的軟件，項目總計約 2 萬行代碼，其中他本人手寫的不到 1000 行，Claude 生成代碼的比例高達 95%。

從功能實現、UI 構建、Bug 修復，到測試、打包、上線，Claude 幾乎貫穿了整個開發流程。與此同時，他也用這次完整實踐，親身驗證了另一個問題：

每月 200 美元的 Claude Max，真的值嗎？

接下來，我們就一同走進他的開發旅程。這不是一場炫技展示，而是一份詳實記錄：關于工具選擇、效果評估、代碼質量把控，以及如何最大化釋放 AI 編程代理能力的一線經驗。以下為第一人稱自述——

編碼工具選型：從 Copilot 到 Claude Code

我第一次接觸 AI 編程工具，是在 VS Code 中試用了 GitHub Copilot。

在我看來，GitHub Copilot 是 AI 編碼領域領域的首個產品，當時我試用完就覺得相當驚艷：雖然 GitHub Copilot 本質上只是一個自動補全工具，但效果遠超預期——不像傳統編輯器那樣只能補全符號名或函數名，它能夠基于上下文補全整個函數實現。

雖然你依然得自己完成大部分工作，但它確實顯著提升了開發效率。

隨后，AI 編程工具的發展突飛猛進：Cursor 橫空出世，推出了“Agent 模式”；新競爭者如 Windsurf 也紛紛加入戰局。幾乎所有產品都開始轉向“代理式（agentic）”開發模式——不再依賴單次 LLM 響應進行補全，而是讓大模型在一個循環中調用各種工具，來完成更復雜的任務：分析代碼庫上下文、讀取網頁與文檔、編譯程序、運行測試、修復失敗構建或測試、不斷迭代等。

不過由于當時我沒有開發任何業余項目，也就沒深入使用這些新工具。

直到 2025 年 2 月，一個意料之外的新選手出現了：Claude Code。它不像其他產品那樣基于 VS Code 魔改，而是一個完全面向終端的 IDE。它沒有傳統的代碼編輯功能，也沒有臃腫的 UI 或五花八門的功能，而是把“代理循環”放在了舞臺中央——一個文本輸入框，僅此而已。

它不是在原有 IDE 上加點 AI 功能，而是直接用 AI 取代了 IDE。

我一開始對這種用戶體驗是否理想還有些疑慮，但這種思路相較于現有工具足夠“清奇”，于是我決定：值得一試。

開啟一個新的“副項目”，初嘗 Claude Code

像很多日常工作繁忙的工程師一樣，我也有一整片“業余項目墓地”——很多項目都只做出了原型，最終卻沒能發布。

前期原型還好做，但最后那 20% 的完善、打磨和發布，實在太耗費時間和精力，以至于我已經有 6 年沒有真正發布過一個副項目了。

既然說要體驗新工具，那就開始吧~就在這時，我開始上手試用 Claude Code，并研究它對 MCP（Model Context Protocol，模型上下文協議）服務器的支持。

這里簡單解釋一下，MCP 是由 Anthropic 設計的一種開放標準，目的是讓 AI 代理能夠訪問工具和外部上下文，以完成具體任務。比如說，Sentry 的 MCP 服務器就暴露了一些工具，可以讓代理獲取帶有堆棧信息的問題報告、調試上下文，甚至調用 Sentry 自家的 bug 修復代理。

不過，開發和調試 MCP 服務器的體驗非常繁瑣：它們和客戶端之間通過標準輸入/輸出流，或者通過帶 Server-Sent Events（SSE）的 HTTP 通信——這樣服務器就能實時向客戶端推送響應。這跟用命令行工具調用 API、或用 curl 發送請求可不是一回事。

雖然有官方提供的 MCP Inspector 工具可以測試服務器功能，但作為一名 macOS 和 iOS 的老開發者，我更想嘗試構建一個原生應用來解決這個問題。

我覺得這不僅是一次深入了解 AI 代理機制的好機會，說不定還能產出一個真正有用的產品。

Claude Code 還挺擅長寫代碼

先說結論：Claude Code（尤其是搭載最新版的 Sonnet 4 和 Opus 4 模型）真的很會寫代碼。

雖然它算不上是“前 1% 的頂級程序員”，但我認為它的輸出已經明顯優于大多數普通開發者。只要你提供一個清晰的功能描述，Claude 就可以完成以下工作：

• 找出項目中與該功能相關的已有源碼，并進行閱讀

• 理解代碼風格和設計模式

• 閱讀你額外提供的文檔或技術規范

• 生成實現該功能所需的代碼

• 編寫測試來驗證功能行為

• 構建項目并運行測試

• 在出現編譯或測試失敗時，自動修復并反復嘗試直到通過

• 查看截圖或控制臺日志，識別 bug 并修復（這一點后面還會詳細講）

Claude 正在為我的應用編寫 Swift 代碼

最令人驚訝的是：它完成這些工作的速度遠超人類開發者。想象一下你剛招來一名對項目毫無了解的新員工，幾分鐘內他就能交付一整個功能模塊——Claude 就是這種感覺。

Claude Code 對 Swift 的掌握一般，但在 SwiftUI 上表現不錯

我決定用 Apple 最新的開發技術來構建這款應用：Swift 6.1和macOS 15.5 上的 SwiftUI。我很好奇 Claude 在寫 Swift 方面的表現——畢竟，相較于 Python 或 JavaScript 這類主流語言，訓練數據中包含的 Swift 代碼明顯少得多。

好消息是，Claude 能夠比較熟練地使用大多數Swift 語言特性，尤其是 Swift 5.5 之前的內容——也就是 Swift 并發機制（Swift Concurrency）引入之前的版本。

Swift Concurrency 本身就是一次語言級的劇烈變革，連很多人類開發者都難以掌握。Claude 在這里也容易出錯，尤其是在選擇現代框架和舊 API 之間切換時會混淆——它經常會選用過時的 Objective-C API，即便已經有更現代的 Swift 替代方案，或者會在本該使用 SwiftUI 的地方使用 AppKit / UIKit。

不過它生成的 SwiftUI 代碼表現還不錯：通常能準確還原預期的 UI 功能，只是初始版本在美觀性上稍顯粗糙，但稍加迭代就能變成設計良好、可用性強的界面。

我的 macOS 應用 Context 的界面截圖

Claude 在生成 UI 代碼時經常會遇到的一個問題，其實是 Swift 本身的問題：UI 相關的類型表達式有時太復雜，編譯器就會報出臭名昭著的錯誤：

“The compiler is unable to type-check this expression in reasonable time.”

解決辦法是將 body 函數拆分成多個更小的表達式塊。幸運的是，Claude 在重構這類代碼時非常擅長，不會破壞功能——有時它甚至會在看到編譯器錯誤后自動這么做。

你還可以通過創建一個 CLAUDE.md 文件來給 Claude 提示，指導它使用現代 API，從而避免常見陷阱。以下是我為 Context 項目寫的部分內容（https://github.com/indragiek/Context/blob/main/Context/CLAUDE.md）：

* 所有功能盡量使用 SwiftUI 實現，除非某個特性僅在 AppKit 中可用。
* UI 設計要符合 macOS 的平臺習慣，遵循 Apple 的 Human Interface Guidelines。
* 圖標使用 SF Symbols。
* 使用最現代的 macOS API。本應用無需考慮舊版本兼容性，因此可以直接面向最新版系統。
* 使用最新的 Swift 語言特性和編程習慣，目標版本為 Swift 6，優先使用 Swift 并發（async/await、actors）和宏。

哪怕只是像這樣輕量級的規則，也已經能顯著改善 Claude 的輸出。如果你愿意投入更多，可以參考 Peter Steinberger 的 agent-rules 倉庫（https://github.com/steipete/agent-rules），其中提供了許多通用編碼指南，也包括專門針對 Swift 的優化規則。

如果你想親自評估 Claude 寫出來的代碼質量，也可以看看我的項目中的以下兩個示例文件：

• OAuthClient.swift（https://github.com/indragiek/Context/blob/main/ContextCore/Sources/ContextCore/OAuthClient.swift）：OAuth 2.1 協議的實現

• JSONOutlineView.swift（https://github.com/indragiek/Context/blob/main/Context/Context/JSONViewer/JSONOutlineView.swift）：使用 SwiftUI 渲染 JSON 樹狀結構視圖，支持節點展開/折疊

你只需說一句：“讓它更好看點”

如果 Claude 生成的 UI 第一次看起來不夠美觀，你只需告訴它：“讓它更好看一點 / 更優雅一點 / 更易用一點”，通常都能獲得意外驚喜的好結果。你也可以更系統地操作，比如先讓它：

“請列出一些改進這個 UI 設計的建議”

Claude 會返回一個設計優化建議清單，供你選擇應用。

當你發現 UI 有 bug，或有想要微調的地方，你也可以直接截一張圖，拖進 Claude Code，或者粘貼（?+V）進去。雖然目前這個流程還算不上完全自動化，但它已經非常實用了，而且不受前端平臺限制，通用性很好。

“”才是關鍵

隨著主流 AI 的興起，業界很快提出了一個新概念：提示詞工程（prompt engineering）。它的核心理念是：你需要精心設計提示詞，才能從模型中獲取最優結果。這個觀點在早期可能確實有道理，但根據我的實際經驗，對于現在的新一代模型來說，提示詞工程已經不是重點。

當下的模型在理解不完美輸入方面已經有了顯著提升——一方面因為模型本身更強大，另一方面也因為它們采用了“思維鏈（Chain of Thought, CoT）”提示策略。現在你就算給模型模糊的描述、不完整的句子、甚至拼寫語法錯誤，它依然能大致理解你的意圖，并將問題拆解為合理的解決步驟。

你在使用 Claude Code 或類似工具時，真正需要反復應對的限制，其實是“上下文窗口”（context window）。

Anthropic 最新的兩個模型——Sonnet 4 和 Opus 4——都擁有200k tokens 的上下文長度，意味著它們一次最多能處理大約 200k token 的文本。但你每輸入一個 prompt、模型每回應一句，都在消耗這個上下文容量；而一旦臨近尾部，模型的表現往往會變差。

Claude Code 中的“上下文壓縮提示器”

為了解決這個問題，Claude Code 還貼心地顯示了一個“上下文剩余容量指示器”——一旦快要用完，它就會自動進入“壓縮（compaction）”流程。這一步的意思是：模型會對當前對話內容進行總結，再用這個總結信息來初始化一個新的上下文窗口，以便你繼續使用。

但壓縮并不完美：它可能遺漏之前對話中的關鍵細節，或者因為壓縮邏輯本身不夠精細，將一些錯誤信息“繼承”到新的上下文中。

所以，總結來說——如何在有限的上下文 token 數量內產出最高質量的結果，也就是所謂的上下文工程（context engineering），才是你真正要在編程代理工具中專注優化的核心能力。

“預熱”代理（Priming the Agent）

我把這類操作稱為“預熱（priming）”代理：不是一上來就讓代理執行任務，而是先讓它讀取一些額外的上下文信息，這樣生成的結果通常會更準確、更符合預期。

默認情況下，Claude 會自動讀取 CLAUDE.md 文件中的內容——包括用戶級別和項目級別的兩個版本。但你也可以通過提示詞，主動引導它去讀取某些文檔或源碼文件，以補充任務相關的上下文。

以下是我最近用過的一個例子，我讓 Claude 閱讀一些現有源碼和線上規范文檔：

請閱讀 DXTTransport.swift、DXTManifest.swift、DXTManifestView.swift、DXTConfigurationView.swift、DXTUserConfiguration.swift、AddServerFeature.swift 和 AddServerView.swift，了解 DXT 包添加服務器的實現方式。
然后閱讀 manifest.json 格式的文檔，鏈接如下：  
https://raw.githubusercontent.com/anthropics/dxt/refs/heads/main/MANIFEST.md
閱讀完這些內容后，請總結你所學到的信息。

Claude 會調用Search 和 Read 工具查找并讀取這些源碼文件，再用Fetch 工具下載 GitHub 上的 Markdown 文檔。讓它生成總結的這個步驟非常關鍵，因為總結能迫使模型真正“思考”它理解了什么，而這個總結會被保留在上下文中，進而提升它接下來處理任務的表現。

當你的代碼依賴第三方庫，或者使用了模型知識截止時間之后發布的新 API 時，預熱尤其重要。這類信息模型本身可能并不了解，所以你得手動補充。

現在也有一些專門工具，比如Context7和llm.codes，它們的作用就是將文檔格式化成適合語言模型讀取的純文本內容，從而方便“喂”給 Claude 使用。

代理不會讀心，它們需要「規范說明（Spec）」

當你讓 Claude 構建某個功能時，一份詳細的功能說明文檔（spec）是引導模型的關鍵。如果你不愿投入精力編寫清晰的需求說明，Claude 就無法幫你完成任何稍微復雜一點的功能。

我們經常能在 AI 產品演示中看到一句話就生成“完整應用”的場景，但那通常只能做出個原型而已。如果你希望產出真正可用的功能，就必須提供一份明確、具體的說明文檔。

這個文檔并不需要措辭優雅、結構工整——你甚至可以用語音隨口說幾句（雖然我個人還是更喜歡打字，但其實怎么說都行）。

下面是我曾提供給 Claude 的一個示例，用來讓它為我的應用實現對 Anthropic 的 DXT 包格式的支持：

看起來像是寫了很多，但我打完這段說明的速度，遠比我親自實現這個功能要快得多。

用「Ultrathink」讓它先計劃再動手

Claude 有個常見的問題：它常常會在沒有足夠背景信息的情況下就直接動手實現功能，結果就是生成的代碼質量很差。

為了解決這個問題，另一種有效的“預熱”策略是：明確讓 Claude 啟用“深度思考”模式，并先制定一份計劃。你可以通過一組“魔法關鍵詞”來激活這個模式：

"think" < "think hard" < "think harder" < "ultrathink"

這些詞不是普通的建議，它們是明確的觸發信號，會讓模型進入不同程度的深度推理狀態。其中 "ultrathink" 會消耗最多的 token，但也是效果最好的。

如果你希望 Claude 在動手寫代碼前先跟你確認方案，可以在 prompt 中明確指出：

“請先制定計劃并等待用戶確認后再開始實現。”

總的來說，我非常推薦你閱讀 Anthropic 官方的文章：《Claude Code：面向代理式編程的最佳實踐》（https://www.anthropic.com/engineering/claude-code-best-practices）。本文中提到的許多技巧都來自那篇文章，對于想要充分發揮 Claude Code 或任何編程代理能力的人來說，這篇文章幾乎是必讀的參考資料。

建立“反饋循環（Feedback Loops）”

Claude 最強大的地方在于：它可以獨立驅動反饋循環——也就是說，它能修改代碼、測試改動、分析失敗原因，然后嘗試下一輪迭代。要實現這個閉環，以下幾個核心步驟必不可少：

• 構建

Claude 需要知道如何編譯你的應用。它能直接用 swift build 編譯 Swift 包，這沒問題。但對于我的 macOS 應用目標，它經常搞不清該如何正確調用 xcodebuild。為此，我使用了XcodeBuildMCP，它為模型提供了一套簡化的構建與運行工具，解決了這個問題。

• 測試

Claude 應該能構建并運行你的測試，并讀取測試輸出。對于 Swift 包，它能很好地配合 swift test 使用。我還沒有測試過它能否運行應用級或 UI 測試，但我猜想那也可能需要 XcodeBuildMCP 的輔助。

• 修復 Bug

Claude 本身就擅長調試問題，比如通過添加 debug 日志。但問題在于：它無法像真實用戶那樣交互操作應用，從而讓應用進入能輸出這些日志的狀態。

因此，你需要手動操作應用，把控制臺輸出的日志復制粘貼給 Claude。這種方式仍然可行，但意味著如果你沒有提前寫好單元測試或 UI 測試，Claude 就無法實現完全自動化修復。

像playwright-mcp這樣用于瀏覽器應用的自動化測試工具確實存在，但對于原生開發，目前我還沒見過同樣穩定可靠的方案。

• 修復 UX 問題（Fix UX Issues）

前面提到過，你可以通過粘貼截圖的方式，讓 Claude 迭代 UI 設計。雖然可以用工具（如 Peekaboo）自動截圖，但你仍然得手動操作應用，把它引導到合適的狀態才能截到你想看的畫面。

Claude Code 不止能寫代碼

Claude Code 是一個封裝了通用大模型的智能代理，因此在構建應用的過程中，你還可以用它來完成一些非編程任務，比如編輯文案內容、規劃功能版本，或者請它建議如何改進應用的可用性或功能布局。

我自己覺得很實用的一點是：在還沒有數據源時，Claude 能快速生成高質量的模擬數據。在構建 Context 應用時，我雖然開始寫了一個 Swift 的 MCP 客戶端庫，但我更想先跳到 UI 層做些原型設計。

如果沒有 Claude，生成一組“看起來像樣”的假數據會非常繁瑣，以至于我可能會直接放棄。但 Claude 能在幾秒內就生成非常不錯的 mock 數據。

我分享給朋友們的首批 UI 截圖，其實背后就是這些 mock 數據在驅動。雖然不是真實數據，但效果足以讓人直觀感受到應用最終的樣子。

Claude 生成的 mock 數據驅動的 Context 應用截圖

特別是在 MCP 生態尚未完善的早期，大多數服務器只使用了規范中的“工具”部分，其他功能基本沒用到。但我還是需要在 UI 上驗證這些特性能否正確展示——這時，mock 數據的重要性就更不言而喻了。

高質量自動化幾乎不再需要成本

發布流程中最痛苦的“最后 20%”之一，就是構建一套自動化發布流程。尤其是在 macOS 上，你需要應對代碼簽名、軟件公證、打包等一系列復雜流程。

在過去的項目中，我通常會反復試驗，手動配置 fastlane，再寫一點簡陋的 Python 腳本來勉強實現自動化。但這一次完全不一樣。

我花了幾個小時迭代，讓 Claude 幫我生成了一個發布腳本，能夠完成以下操作：

• 檢查當前環境是否配置正確，所需工具是否已安裝

• 從 Git 提交記錄中生成變更日志，并與手寫的日志內容合并，再生成 HTML 格式的發布說明

• 構建應用、代碼簽名、公證、打包成 DMG 文件

• 生成 Sparkle 的 appcast 文件，實現對現有用戶的自動更新推送

• 給版本打標簽，并發布到 GitHub

• 將調試符號上傳到 Sentry，以便解析崩潰日志

當腳本功能完善之后，我只用一句簡單的提示詞，就讓 Claude美化了 CLI 輸出界面，最終效果如下：

運行 Claude 生成的構建 & 發布自動化腳本

這個腳本有2000 行 Python 代碼。如果讓我自己從頭寫，我只會實現最核心的幾個步驟，絕不會花精力做到如此完善、界面美觀。

現在，每次發布版本，它都能為我節省十幾甚至幾十分鐘的手動操作。而實現這一切，我只花了幾段自然語言說明，再配合 Claude 調試它運行中遇到的問題就搞定了。

未來的 IDE 會大不相同

這個項目中，我幾乎只用到了兩個工具——Claude Code 和 GitHub Desktop（用于查看 diff）。

絕大多數時間里，我根本不需要傳統編輯器的那些常規功能：什么文件樹、源碼編輯器、擴展插件等等。我偶爾會打開 Xcode 做點手動修改，但次數很少，而且我幾乎沒用到 Xcode 的特色功能（比如 SwiftUI 預覽、界面調試器等）。

而這還只是現在的“最差版本”AI 編程代理。我不禁設想：未來的 IDE 很可能跟今天的 IDE 完全不同。

現在的 Cursor、Windsurf 和 Copilot 都是從 VS Code 起步，然后各自發展出不同方向，但它們本質上只是把 AI 嵌進一個“AI 出現之前就設計好的”編輯器。VS Code 從結構上看，其實和 20 年前的 JetBrains IDE 并無本質區別。

我也看到像 Warp 這樣的項目，嘗試從“現代終端模擬器”轉型為智能代理式開發環境。但即使我很喜歡 Claude Code，我也不認為“命令行終端”會是未來開發體驗的最佳形式。

我相信：未來的 IDE 會圍繞如何幫助開發者“預熱上下文”、搭建“反饋閉環”這兩件事展開設計，因為這是讓智能代理順利完成任務的關鍵。而這套體驗的界面，必然會和今天的代碼編輯器大相徑庭——我無法準確預測它會是什么樣，但可以肯定的是，源碼編輯器不再是核心。

我終于又能發布業余項目了

對我來說，這次旅程最令人興奮的，不是最終發布了哪個應用，而是：我終于又能“過把寫代碼的癮”，并真正發布打磨好的副項目了。

感覺就像是我每天多出 5 個小時一樣——而這一切的“代價”，不過是每月 200 美元。

原文鏈接：https://www.indragie.com/blog/i-shipped-a-macos-app-built-entirely-by-claude-code

AI 產品爆發，但你的痛點解決了嗎？

2025 全球產品經理大會

8 月 15–16 日

北京·威斯汀酒店

互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人

12 大專題分享，洞察趨勢、拆解路徑、對話未來。

立即掃碼領取大會PPT

搶占 AI 產品下一波紅利