推出4个月就狂赚3亿？！百万用户应用CTO弃Copilot转Claude Code：200美元拯救我的137个应用

刚刚，Anthropic 公司对外披露截止到 7 月 6 日的最新数据：其四个月前推出的 AI 编码助手 Claude Code 已吸引 11.5 万名开发者，且单周处理代码量达 1.95 亿行，堪称 AI 编码市场中增长最快的开发者工具之一。不过，也有行业观察人士指出，在统计周期内处理的 1.95 亿行代码需谨慎解读，因为单个代码变更在达到生产质量前可能经历多次迭代与修正。

“哪个初级工程师每年能赚 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 的市场壁垒。”

此外，Indragie 热衷于以开发各种应用来作为副业，在他的存储库中“躺着”137 个尚未交付的项目。这次尝试了 Claude Code 后，他激动地表示：“这次体验中最令人兴奋的部分并不是我开发的应用本身，而是我又能够随时随地编程、发布完善的副业项目了。这就像每天多给了我 5 个小时，而相应的每月只需要支付 200 美元。”

在一篇博客中，Indragie 详细阐述了其使用 Claude Code 完成的全部开发历程，包括功能代码编写、UI 界面生成、模拟数据生成甚至发布脚本，以及各款 AI 编码工具的优缺点与如何运用它们来最大限度提高代码生成质量——特别是构建一款原生应用的情况下。

“智能体不会读心术”，Indragie 强调了“上下文工程”的重要性，同时建议，在要求编码智能体构建一项功能时，可以提供一份详细的规范来引导模型。“AI 产品演示往往会突出展现用一句话提示词创建完整应用程序的效果，但如果大家想要的不只是粗糙的原型，那就需要真正设置一套规范。”

以下是全文内容（经 AI 前线 进行不改变原意的整理和编辑）：

我最近发布的 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 美元。