作者 | 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
