作者 | Indragie Karunaratne
編譯 | 沈建苗
審校 | 云昭
出品 | 51CTO技術棧(微信號:blog51cto)
Claude Code 出來之后,很多人都在說“一個人 + AI 就可以獨立寫應用了”。
但真正有人用它從頭到尾打造一個完整的 macOS 原生 App,還詳細記錄全過程的,幾乎沒有。
今天要分享的這篇文章,正好填補了這個空白。
最近兩天,小編刷到一篇“神文”,直接驚呆!
一位 macOS 老程序員,用 AI 工具 Claude Code,硬是靠一個人之力寫出了完整的原生 App,還自動打包上線發布!
全文不僅細節拉滿,更重要的是總結了 AI 編程的 14 個關鍵技巧,可謂句句干貨,錯過可惜!推薦每一個搞開發的朋友都認真讀一遍。
我用 Claude 搞定了一款macOS應用
2萬行代碼,自己只手敲一千行
我最近發布了一個 macOS 原生應用 Context,用于調試 MCP 服務器。這款應用由 Apple 的 SwiftUI 框架驅動,旨在打造一款貼合平臺風格的開發者工具。
雖然我從 2008 年就開始做 macOS 應用,但這次完全不同:Context 幾乎是由 Claude Code 獨立完成的。在整個 2 萬行代碼中,我手寫的代碼不超過 1000 行。過程中當然仍需要技巧和反復調試,但 Claude 的編程能力確實大大提升了效率。
接下來,我將詳述這段開發之旅,包括工具選擇、Claude 的優劣勢,以及如何最大化生成代碼的質量,特別適合你也想用 AI 構建原生應用的場景。
1. 從 Copilot 到 Claude Code:AI 編碼工具的演變
我的第一次 AI 編程體驗是使用 GitHub Copilot,那時它剛集成進 VS Code,主要作為智能補全工具。雖然功能相對簡單,但已經比傳統編輯器智能許多,可以根據上下文補全整個函數。
后來,行業飛速發展:Cursor 的 Agent 模式興起,Windsurf 等競爭者紛紛跟進,AI 工具從“補全”逐步進化為“代理開發”,可以循環調用工具、分析代碼、讀取文檔、構建項目、跑測試并自動修復。
2025 年 2 月,Claude Code 橫空出世。它不是一個 VS Code 插件,而是一個純終端的 IDE,沒有文件樹,沒有 UI,只有一個文本框供你輸入提示詞。說它是 IDE,不如說是“AI 開發代理終端”。
它把智能體循環(agentic loop)放在首要位置。這種“沒有用 AI 增強 IDE,而是取代 IDE 的做法”足夠新穎,雖然一開始我對這種 UX 體驗存疑,但值得一試。
2. 又一個 Side Project 的開始
跟許多上班族程序員一樣,我有一大堆做了一半就爛尾的 Side Project。通常原型很快能做出來,但最后 20% 的打磨太耗精力,結果我已經 6 年沒成功發布過項目。
這一次,我想嘗試支持 MCP 的原生應用。MCP 是 Anthropic 提出的開放標準,用于讓 AI agent 訪問工具或上下文。雖然官方有 MCP Inspector 工具,但體驗一般,而我一直想做一個像樣的 macOS 原生版本。
于是,項目 “Context” 就此啟動。
3. Claude Code 真的是會寫代碼
我必須說,搭載 Sonnet 4 和 Opus 4 的 Claude Code,代碼生成能力非常強。雖然稱不上頂級工程師,但比平均開發者強不少。
只需描述你想要的功能,它就能:
- 找出項目中相關的源代碼;
- 理解代碼風格和設計模式;
- 閱讀文檔或說明;
- 編寫功能代碼并生成測試;
- 編譯、運行測試,自動修復編譯錯誤;
- 甚至可以識別日志、截圖中的 Bug,并嘗試修復。
而且這一切速度驚人。就像你招了個新員工,零背景,卻能幾分鐘交付一個完整功能。
4. Swift 一般,SwiftUI 很行
我用的是 Swift 6.1 和 macOS 15.5,Claude 寫 Swift 的表現中規中矩,但對 SwiftUI 的掌握不錯。
尤其 Swift Concurrency(并發機制)上線后,語言復雜度暴增,就連人也容易出錯。但 Claude 能識別大多數常用語法和 API,雖然有時會混用過時的 Objective-C 或 UIKit,但通過一定指引可以有效避免。
比如,你可以寫一個 CLAUDE.md
文件作為項目規范,告訴 Claude:
- 盡量用 SwiftUI,只有必要時才用 AppKit;
- 遵循 Apple 人機交互指南;
- 使用 SF Symbols 圖標;
- 使用最新 Swift 特性,包括 async/await、actors 和宏。
* Aim to build all functionality using SwiftUI unless there is a feature that is only supported in AppKit.
* Design UI in a way that is idiomatic for the macOS platform and follows Apple Human Interface Guidelines.
* Use SF Symbols for iconography.
* Use the most modern macOS APIs. Since there is no backward compatibility constraint, this app can target the latest macOS version with the newest APIs.
* Use the most modern Swift language features and conventions. Target Swift 6 and use Swift concurrency (async/await, actors) and Swift macros where applicable.
僅這些簡單規則,就能極大提升代碼質量。
而且,你還可以更進一步:例如,Peter Steinberger 的代理規則庫包含可以添加到代理中的規則,既可以作為一般編碼指南,也可以更具體地編寫更好的 Swift 代碼。
地址:https://github.com/steipete/agent-rules
5. “把 UI 做得更漂亮”——Claude 真的能聽懂
Claude 生成的 UI 首版可能有點粗糙,但你只需說一句“請讓它更漂亮一些”,它就能自動優化。
更穩妥的方式是先讓它“列出提升 UI 美感的建議”,再逐項調整。甚至你可以直接把截圖粘貼到 Claude 中,它就能據此優化 UI,平臺無關、方法通用。
6. 真正關鍵的是:上下文工程,而非提示工程
過去我們講 Prompt Engineering,但現在我更看重的是 Context Engineering(上下文工程)。
因為 Claude 的上下文窗口是有限的(目前 Opus 4 和 Sonnet 4 是 200k tokens),一旦對話過長,Claude 就需要“壓縮”上下文,即用總結代替原始細節。這一步很容易丟失關鍵信息。
Claude Code 會提示你當前的上下文使用情況,超過限制后會自動觸發壓縮。要保證輸出質量,就必須學會如何合理安排上下文,讓 AI 讀懂足夠的信息再動手。
7. Priming:讓 Claude 吃透文檔再開始
我通常會在 Claude 開工前,讓它先讀相關源代碼和在線文檔,并生成一份總結:
Read DXTTransport.swift, DXTManifest.swift, DXTManifestView.swift, DXTConfigurationView.swift, DXTUserConfiguration.swift, AddServerFeature.swift, and AddServerView.swift to learn how adding servers from DXT packages is implemented.
Then read the documentation for the manifest.json format here: https://raw.githubusercontent.com/anthropics/dxt/refs/heads/main/MANIFEST.md
After reading these sources, summarize what you've learned.
Claude 會自動調用 Search 和 Fetch 工具,抓取源碼和 Markdown 文檔,然后生成總結供后續任務使用。
這種“預熱”方式特別適合你用的是新 API、三方庫或模型不知道的內容。
8. AI 不是讀心術,它需要規范說明
要讓 Claude 構建新功能,你必須提供清晰的需求說明(spec)。
它并不會憑一句“做個登錄頁面”就寫出完整功能。你可以隨意寫,哪怕語氣像你自言自語,Claude 都能理解。
我給 Claude 的某個功能 spec:
請為 Context 添加對 DXT 包格式的支持。用戶可以點擊“Add Server”,然后選擇本地的 manifest.json 文件……
雖然看起來很多,但比自己寫代碼快多了。
9. “Ultrathink”:魔法詞匯讓 Claude 深度思考
Claude 很容易“太快動手”,寫出低質量代碼。你可以在提示詞中使用“think harder”或“ultrathink”等關鍵字來激活,讓它先思考再動手。
這些詞不是簡單的形容,而是觸發模型不同程度“延遲思考模式”的觸發器。
用法示例:
請 ultrathink 并制定一個詳細的計劃,在我確認之前不要開始實現。
推薦閱讀:Anthropic 官方發布的 《Claude Code 最佳實踐指南》。
10. 建立 Feedback Loop,Claude 才能自主迭代
Claude 最強的地方是能“自己犯錯自己修”。要做到這一點,必須幫它建立如下幾個循環:
- 構建循環:告訴它如何編譯項目,Claude 原生支持
swift build
,但對xcodebuild
不了解,可以使用 XcodeBuildMCP; - 測試循環:使用
swift test
跑單測;UI 測試目前支持有限; - Bug 修復循環:你得提供運行日志或控制臺輸出,它才能判斷出錯位置;
- UI 優化循環:貼圖+優化提示詞,Claude 就能迭代視覺效果。
注意:目前還無法讓它“像人一樣”使用 App,需要你提供交互狀態。
11. 不只是寫代碼,更有趣的應用:模擬數據
由于Claude Code是封裝通用模型的智能體,因此在迭代應用程序本身時,你仍可以用它來幫助完成非編程任務,比如編輯文案,甚至通過向模型征求改進應用程序功能方面的建議來規劃功能版本。
我發現一個很有用的方面是,在將真實數據導入應用程序之前,它能夠生成模擬數據(mock data)。在構建Context時,我部分構建了實現Swift MCP 客戶端庫的方法,但想改弦易轍,做一些 UI原型設計。
畢竟,生成逼真的模擬數據的過程通常太繁瑣了,我永遠不會去嘗試,但Claude在幾秒鐘內生成了非常棒的模擬數據。
結果非常 nice,我引入UI時與朋友們分享的應用程序的首批截圖基于模擬數據,但它看起來足夠逼真,你可以很好地了解應用程序在從真實的MCP服務器渲染數據時的樣子。
對于MCP來說,模擬數據尤為重要,因為當時大多數MCP服務器除了工具之外并不使用規范中的大多數功能,但我仍然需要一種方法為這些功能驗證 UI。
12. 自動化發布現在幾乎免費
macOS 應用發布流程復雜(簽名、notarization、DMG 打包、Sparkle 更新等),過去我都會寫 Python 腳本慢慢配。
這次,我用了幾小時就讓 Claude 自動寫了個完整腳本,功能包括:
- 檢查環境依賴;
- 生成 changelog 和發布日志;
- 編譯、簽名、打包;
- 生成 Sparkle 更新 feed;
- 打標簽并發布到 GitHub;
- 上傳 Sentry 的調試符號。
而這些,只花了我幾段自然語言提示。
13. 未來的 IDE 會截然不同
我突然意識到,整個項目我幾乎只用了兩個工具:
- Claude Code:主要開發環境;
- GitHub Desktop:查看 diff。
絕大多數時候,我幾乎沒用 VS Code/Xcode 這些傳統 IDE 編輯器功能:文件樹、源代碼編輯器、擴展程序等等。我偶爾會用 Xcode 手動編輯,但這種情況很少見,而且我也沒有用到大多數 Xcode 特有的功能(SwiftUI 預覽、View Debugger 等等)。
我不得不想象,未來的 IDE 可能和現在完全不一樣。
我現在相信:
未來的 IDE,核心是讓開發者“構建上下文 + 搭建反饋回路”,而不是手寫代碼本身。
這對于幫助代理成功完成任務至關重要。這方面的用戶體驗將會非常不同——我無法準確預測,但我認為源代碼編輯器不會成為核心。
Cursor、Windsurf 和 Copilot 都是從 VS Code 起步的,并在各個方面有所差異,但它們都將人工智能融入到了一個人工智能尚未出現的編輯器中。
從根本上來說,VS Code 與 20 年前的 JetBrains IDE 看起來并沒有什么不同。我也看到像 Warp 這樣的項目試圖從現代化的終端仿真器轉型為代理式開發環境,但我也不認為終端一定是理想的用戶體驗。
雖然我喜歡 Claude Code ,但終端式體驗不一定是最優解,但傳統 IDE 的形態一定會被徹底顛覆。
14. 我終于又能發項目了!
最讓我興奮的不是這個 App,而是我終于又能把 Side Project 做完并發布了!
這種感覺就像是:自己可以每天多出 5 小時,而每個月只是多花了 200 美元。
注:我與 Anthropic 無任何利益關系,此文也非推廣內容。只是實話實說,我真的很喜歡 Claude Code。
參考鏈接:
https://www.indragie.com/blog/i-shipped-a-macos-app-built-entirely-by-claude-code