“开发工作即将迎来一次彻底重置，而大多数人还毫无准备。”

这是 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 会围绕如何帮助开发者“预热上下文”、搭建“反馈闭环”这两件事展开设计，因为这是让智能代理顺利完成任务的关键。而这套体验的界面，必然会和今天的代码编辑器大相径庭——我无法准确预测它会是什么样，但可以肯定的是，源码编辑器不再是核心。