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

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

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

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

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

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

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

Claude 會返回一個設(shè)計優(yōu)化建議清單，供你選擇應用。

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

“”才是關(guān)鍵

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

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

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

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

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

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

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

所以，總結(jié)來說——如何在有限的上下文 token 數(shù)量內(nèi)產(chǎn)出最高質(zhì)量的結(jié)果，也就是所謂的上下文工程（context engineering），才是你真正要在編程代理工具中專注優(yōu)化的核心能力。

“預熱”代理（Priming the Agent）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“請先制定計劃并等待用戶確認后再開始實現(xiàn)?！?/blockquote>

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

建立“反饋循環(huán)（Feedback Loops）”

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

• 構(gòu)建

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

• 測試

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

• 修復 Bug

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

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

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

• 修復 UX 問題（Fix UX Issues）

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

Claude Code 不止能寫代碼

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

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

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

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

Claude 生成的 mock 數(shù)據(jù)驅(qū)動的 Context 應用截圖

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

高質(zhì)量自動化幾乎不再需要成本

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

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

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

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

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

• 構(gòu)建應用、代碼簽名、公證、打包成 DMG 文件

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

• 給版本打標簽，并發(fā)布到 GitHub

• 將調(diào)試符號上傳到 Sentry，以便解析崩潰日志

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

運行 Claude 生成的構(gòu)建 & 發(fā)布自動化腳本

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

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

未來的 IDE 會大不相同

這個項目中，我?guī)缀踔挥玫搅藘蓚€工具——Claude Code 和 GitHub Desktop（用于查看 diff）。

絕大多數(shù)時間里，我根本不需要傳統(tǒng)編輯器的那些常規(guī)功能：什么文件樹、源碼編輯器、擴展插件等等。我偶爾會打開 Xcode 做點手動修改，但次數(shù)很少，而且我?guī)缀鯖]用到 Xcode 的特色功能（比如 SwiftUI 預覽、界面調(diào)試器等）。

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

現(xiàn)在的 Cursor、Windsurf 和 Copilot 都是從 VS Code 起步，然后各自發(fā)展出不同方向，但它們本質(zhì)上只是把 AI 嵌進一個“AI 出現(xiàn)之前就設(shè)計好的”編輯器。VS Code 從結(jié)構(gòu)上看，其實和 20 年前的 JetBrains IDE 并無本質(zhì)區(qū)別。

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

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

我終于又能發(fā)布業(yè)余項目了

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

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

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

AI 產(chǎn)品爆發(fā)，但你的痛點解決了嗎？

2025 全球產(chǎn)品經(jīng)理大會

8 月 15–16 日

北京·威斯汀酒店

互聯(lián)網(wǎng)大廠、AI 創(chuàng)業(yè)公司、ToB/ToC 實戰(zhàn)一線的產(chǎn)品人

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

立即掃碼領(lǐng)取大會PPT

搶占 AI 產(chǎn)品下一波紅利