“开发工作即将迎来一次彻底重置，而大多数人还毫无准备。”
这篇在 Reddit 上广为流传的热帖标题，同时也是一位经验丰富的程序员在深度体验 Claude Code（配备 Opus 4、Max 模式）后所形成的坚定观点。他在帖子中提到：
该言论一经提出，便在业界引发了热烈的讨论，各方意见不一，既有赞同者，也有提出疑问的人。然而，与此同时，开发者Indragie Karunaratne却选择了另一种做法，他选择不探讨行业趋势，也不空谈理论，而是直接投身于实际操作之中。
他亲自运用 Claude 工具打造了一款完整的 macOS 本地应用程序——Context。这并非简单的演示版本，而是一款真正投入使用的软件产品。整个项目累积代码量约为两万行，而他亲自编写的代码不足一千行，Claude 生成的代码占据了高达 95% 的比例。
在功能实现、用户界面构建、错误修正等环节，Claude 涵盖了开发流程的各个环节。同时，通过这次全面的实践，他亲自证实了另一个关键点：
每月 200 美元的 Claude Max，真的值吗？
现在，让我们共同踏进他的研发历程。这并非单纯的技艺展示，而是一份详尽的记载：涵盖了工具的挑选、效果的评定、代码品质的监管，以及如何充分挖掘 AI 编程助手潜能的实际经验。以下是以第一人称进行的叙述——
在编码工具的选择上，我们考虑了从 Copilot 到 Claude Code 的多种可能性。
初次接触 AI 编程辅助工具，我选择了在 VS Code 环境下尝试使用 GitHub Copilot。
在我看来，GitHub Copilot 作为AI编码领域的先驱之作，一经试用便给我留下了深刻的印象：尽管GitHub Copilot本质上仅是一个自动补全工具，但其表现却远超我的期待——它不仅能像传统编辑器那样补全符号名或函数名，还能根据上下文完整地补全函数的实现。
尽管你仍需独立完成大部分任务，然而它确实极大地提高了开发的速度。
紧接着，AI编程领域的工具进步神速：Cursor应运而生，推出了“Agent”模式；同时，众多新竞争者，如Windsurf，也纷纷加入了这场竞争。众多产品纷纷采纳了“代理式”的开发策略——它们不再仅仅依赖于LLM的单次回应来完善内容，而是借助大型模型在循环中调用多样化的工具，以执行更为繁复的任务：诸如解析代码库的背景信息、浏览网页与文档、编译软件、执行测试、修正失败的构建或测试过程，以及持续进行迭代优化。
当时我并未涉足任何业余项目开发，因此并未对这些新颖的工具进行深入研究。
直至2025年2月，一位出乎意料的全新竞争者横空出世：Claude Code。这款产品并非像其他同类那样通过VS Code进行魔改，而是打造了一个纯粹面向终端用户的集成开发环境。它摒弃了传统的代码编辑功能，去除了繁杂的用户界面和繁多的功能选项，将“代理循环”这一核心概念置于核心位置——仅仅是一个文本输入框，别无其他。
这并非是在现有的集成开发环境上添加人工智能的辅助功能，而是直接用人工智能技术替换了整个IDE。
起初我对这种用户界面设计的优劣持有一定的疑问，然而，与现有的解决方案相比，这种想法显得格外新颖独特，因此我下定决心：不妨尝试一下。
开启一个新的“副项目”，初尝 Claude Code
与众多工作日程紧凑的工程师相似，我同样拥有一片“业余项目荒芜之地”，其中众多项目仅止步于原型阶段，最终未能得以推出。
早期阶段的原型制作相对容易，然而，在接近尾声时对那最后的20%进行完善、精雕细琢以及最终发布，却异常耗费时间和精力，这一状况持续已久，以至于我已有6年未曾成功推出任何副项目。
既然我们计划尝试新的工具，那么就动手吧。恰在此时，我着手开始使用 Claude Code，并对其对 MCP（即模型上下文协议）服务器的兼容性进行了探究。
这里简要说明，MCP 是由 Anthropic 开发的一种开放性规范，旨在使人工智能代理能够获取工具和外部信息，以便执行特定任务。以 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便能胜任以下任务：
Claude 正在为我的应用编写 Swift 代码
最为令人称奇的是，它执行这些任务的速度大大超越了人类开发者所能达到的水平。试想，若你招募了一名对项目一无所知的新手，他仅需短短几分钟就能独立完成一个功能模块——这正是 Claude 所体现出的能力。
Claude Code 在 Swift 方面的技能水平尚可，不过他在 SwiftUI 领域的表现相当出色。
我选择采用苹果公司最新推出的开发工具来打造这款应用，即Swift 6.1和macOS 15.5操作系统中的SwiftUI框架。我对Claude在Swift编程领域的表现充满好奇——毕竟，在训练数据中，Swift代码的比重相较于Python或JavaScript等主流编程语言要低得多。
好消息传来，Claude 在运用Swift语言的各种特性方面表现得相当熟练，特别是对于Swift 5.5版本之前的功能——即在Swift并发机制（Swift Concurrency）被引入之前的那些特性。
Swift 并发编程代表了语言层面的重大转变，这一变革之深刻，以至于即便是众多人类开发者也感到难以驾驭。Claude 在此也常犯错误，特别是在于现代框架与旧版API之间进行切换时容易产生混淆——它往往会选择已经过时的Objective-C API，即便有更为先进的Swift替代方案可用，亦或是在本应采用SwiftUI的场景中误用了AppKit或UIKit。
不过，该工具生成的 SwiftUI 代码质量尚可：它通常能够精确地实现预期的用户界面功能；尽管其初始版本在外观上略显简陋，但经过一番改进后，便能够转变为既美观又易于使用的界面。
我的 macOS 应用 Context 的界面截图
在 Claude 编写 UI 代码的过程中，他常常遭遇的一个难题源自 Swift 语言本身：与 UI 相关的类型表达式往往相当复杂，导致编译器频繁出现那些广为人知的错误。
编译器无法在合理的时间内对该表达式进行类型检查。
解决之道在于将body函数细分为若干更细小的代码片段。值得庆幸的是，Claude在对此类代码进行重构时技艺高超，能够确保功能不受影响——而且，它甚至能在发现编译错误时自动执行这一操作。
您可以通过建立一个名为 CLAUDE.md 的文档来向 Claude 提供指引，使其能够正确运用最新的 API，以此规避一些常见的错误。以下是我为 Context 项目所编写的相关内容（链接：https://github.com/indragiek/Context/blob/main/Context/CLAUDE.md）。
在实现各项功能时，应优先采用 SwiftUI 进行开发，除非该特性在 AppKit 中独有。
UI设计需与macOS系统操作规范相契合，同时严格依照苹果公司制定的《人机界面指南》。
* 图标使用 SF Symbols。
本应用依托于最前沿的 macOS API，无需顾虑与旧版系统的兼容问题，故能直接针对最新系统版本进行开发。
即便仅仅如此轻便的规则，亦能显著提升 Claude 的输出效果。若你希望增加投入，不妨查阅 Peter Steinberger 维护的 agent-rules 代码库（网址：https://github.com/steipete/agent-rules），那里收录了众多通用的编程准则，以及一些特别为 Swift 语言设计的优化策略。
若您希望亲自对 Claude 生成的代码品质进行评判，不妨查阅我项目中的这两个示例文件：
你只需说一句：“让它更好看点”
若 Claude 生成的用户界面初次呈现不够赏心悦目，你大可指示：“请让它更具美感/更显高雅/更便于操作”，往往能收获超出预期的满意效果。此外，你还可以采取更为细致的操作步骤，例如：
“请列出一些改进这个 UI 设计的建议”
Claude 会返回一个设计优化建议清单，供你选择应用。
若你察觉到用户界面存在错误，或者希望对某些细节进行细致调整，你完全可以直接截取一张图片，将其拖拽至 Claude Code 中，亦或将其粘贴（+V）至相应位置。尽管目前这一操作流程尚未实现完全自动化，但它的实用性已相当显著，并且它不依赖于特定的前端平台，具备很高的通用性。
“”才是关键
随着主流人工智能技术的蓬勃发展，行业内部迅速提出了一种新的理念——提示词工程。这一理念强调，为了从模型中获取最佳效果，必须对提示词进行精心设计。在早期阶段，这一观点或许确实具有合理性。然而，依据我的亲身实践，对于当前的新一代模型而言，提示词工程的重要性已经不再突出。
当前模型在处理不理想输入信息的能力上有了明显进步——这既得益于模型自身功能的增强，也得益于它们所采用的“思维链（Chain of Thought, CoT）”提示方法。即便面对含糊不清的描述、不完整的语句，甚至拼写和语法上的错误，模型仍能大致捕捉到你的意图，并将问题分解为一系列合理的解决步骤。
在使用 Claude Code 或其他类似工具的过程中，你将不断面临一个关键的限制，那就是所谓的“上下文窗口”。
Anthropic 推出的两款新模型，即 Sonnet 4 和 Opus 4，均具备200k tokens的语境处理能力，这表示它们最多可以一次性处理约200k tokens的文本内容。然而，每当输入一个提示或模型回应一句，都会减少这一语境容量；当接近语境的末端时，模型的表现通常会出现下滑。
Claude Code 中的“上下文压缩提示器”
为了应对这一挑战，Claude Code特别设计了一个“上下文容量剩余指示器”——当容量即将耗尽时，系统会自动启动“压缩”机制。这个过程涉及：模型对当前对话内容进行归纳总结，并利用这些总结信息来创建一个新的上下文窗口，确保用户可以无缝地继续对话。
然而，这种压缩并非毫无瑕疵：它有可能疏漏掉之前对话中的重要细节，亦或是由于压缩逻辑本身不够严谨，导致某些错误信息被延续至新的语境之中。
总结而言，关键在于——在有限的上下文token数量限制下，如何实现产出最优质的结果，这便是我们所说的上下文工程（context engineering），它才是编程代理工具中需要着重提升的核心技能。
“预热”代理（Priming the Agent）
此类行为我将其命名为“预训练（pre-training）”代理机制；并非直接让代理执行任务，而是先让其浏览一些额外的背景资料，通常这样做能确保输出的结果更加精确、更贴近我们的期望。
Claude在默认设置下会自行检索CLAUDE.md文件内的资料，这其中包括了用户和项目两个层级的版本。不过，用户还可以通过输入特定的提示词，手动指定它去查阅特定的文档或源码文件，以此增强与任务相关的背景信息。
这是我近期使用的一个案例，我要求 Claude 阅读了一系列现成的源代码以及网络上的规范文件。
请查阅 DXTTransport.swift、DXTManifest.swift、DXTManifestView.swift、DXTConfigurationView.swift、DXTUserConfiguration.swift、AddServerFeature.swift 以及 AddServerView.swift 这几个文件，以掌握 DXT 包中添加服务器功能的实现细节。
随后，查阅该manifest.json格式的文件，具体链接如下：
请勿访问该链接，该地址指向的文件为MANIFEST.md，位于anthropics/dxt仓库的main分支上。
阅读完这些内容后，请总结你所学到的信息。Claude 将运用 Search 和 Read 工具对源码文件进行搜索与读取，随后使用 Fetch 工具从 GitHub 上下载 Markdown 文档。这一生成总结的过程至关重要，它促使模型深入思考并理解自身所掌握的知识，且该总结将保留在上下文中，从而有效提升模型在后续任务中的表现。
若你的程序引用了外部库，或是采纳了在模型知识更新截止日期之后推出的新接口，那么进行预热就显得格外关键。因为这类信息模型可能并不具备相关知识，因此你需要亲自进行信息的补充。
目前市面上存在一些特定的工具，例如Context7与llm.codes，这些工具的主要功能是将文档内容进行格式化处理，转换成便于语言模型直接读取的纯文本，进而便于将处理后的文本输入到Claude系统中。
代理不会读心，它们需要「规范说明（Spec）」
在 Claude 帮助构建特定功能的过程中，一份详尽的功能说明文档（spec）对于指导模型至关重要。然而，若您不致力于撰写明确的需求描述，Claude 将无法协助您实现较为复杂的功能。
在AI产品的展示环节，我们常常目睹仅需一句话就能生成“完整应用”的演示，然而，这类成果往往仅限于一个基础的原型。若想得到真正实用的功能，务必提交一份详尽且明确的说明文件。
这份文件并不要求语言华丽、格式严谨——你甚至可以随意口头表达（尽管我个人更偏爱键盘输入，但无论哪种方式都是可以的）。
以下是一个我向 Claude 提供的案例，旨在使其应用能够对 Anthropic 的 DXT 压缩格式进行兼容处理：
看似文字量颇丰，然而，我完成这段说明所用的时间，却远远不及我亲自去实现这一功能所需的时间。
用「Ultrathink」让它先计划再动手
Claude 存在一个普遍的困扰：它往往在缺乏充足背景资料的情况下便急于动手实现功能，导致所产出的代码质量不尽如人意。
为应对这一挑战，我们可采取一种高效的“热身”方法，即让 Claude 开启“深度思维”模式，并预先拟定一份行动指南。你可以借助一系列“神秘关键词”来启动这一模式：，
"think" < "think hard" < "think harder" < "ultrathink"
这些词汇并非寻常的提议，它们充当着明确的触发器，能够使模型达到不同层次的深度推理状态。特别是“ultrathink”这一词汇，虽然它所消耗的token量最多，但其效果却是最为显著的。
若你期望 Claude 在着手编写代码之前先与你进行方案的核实，那么你可以在提示信息中明确表达这一要求。
“请先制定计划并等待用户确认后再开始实现。”
总体而言，我强烈建议你阅读Anthropic发布的文章，即《Claude Code：面向代理式编程的最佳实践》（链接：https://www.anthropic.com/engineering/claude-code-best-practices）。本文所阐述的众多方法均源自那篇著作，对于希望充分挖掘 Claude Code 或其他编程助手潜能的读者而言，该著作堪称不可或缺的参考指南。
建立“反馈循环（Feedback Loops）”
Claude的显著优势在于其能够自主运作反馈循环——换言之，它具备修改代码、检验变更效果、剖析失败根源，并尝试进行新一轮迭代的本领。为了构建这一完整的闭环，以下几项关键步骤是不可或缺的：
Claude需要掌握编译应用的方法。Swift包可以通过swift build直接编译，这一点毫无问题。然而，针对我的macOS应用目标，它往往难以准确调用xcodebuild。为此，我采用了XcodeBuildMCP，这套工具为模型构建和运行提供了简化方案，成功解决了这一问题。
Claude理应具备构建与执行测试的能力，同时还能解析测试结果。在Swift包的运用上，它与swift test配合得相当出色。至于是否能够执行应用级或UI测试，我尚未进行过验证，不过我推测这或许还需借助XcodeBuildMCP的支持。
Claude 在调试方面有着出色的能力，例如通过添加调试信息。然而，问题在于：它不能像实际用户那样与应用程序进行交互，导致无法使应用程序达到能够生成这些日志的状态。
因此，您需亲自进行操作，将控制台显示的日志信息手动复制并粘贴至 Claude。尽管这种方法依然有效，但它要求您事先准备好单元测试或用户界面测试，否则 Claude 将无法完成自动化的修复过程。
确实存在一些适用于浏览器应用的自动化测试工具，例如playwright-mcp，然而，在原生开发领域，我尚未发现与之相当稳定且可信的解决方案。
先前已述，您能够借助截图功能对 Claude 的界面进行迭代设计。尽管存在诸如 Peekaboo 这样的工具能够实现自动截图，但您仍需亲自操作应用程序，确保其处于恰当的状态，以便截取到所需的画面。
Claude Code 不止能写代码
Claude Code 作为一款集成了通用大型模型的智能助手，在应用开发过程中，你不仅能借助它执行编程任务，还能利用其完成诸如文案编辑、功能版本规划等非编程工作，甚至可以请求它就如何提升应用的使用便捷性或优化功能布局提出建议。
我个人的一个实用体会是：在没有数据源的情况下，Claude 能够迅速产出高品质的仿真数据。在开发 Context 应用过程中，尽管我着手编写了一个 Swift 的 MCP 客户端库，但我更倾向于先进行 UI 层的原型设计。
若非 Claude 的存在，制作出一组外观合格的人工数据将变得异常复杂，这甚至可能导致我选择放弃。然而，Claude 能够在短短几秒钟内迅速生成质量上乘的模拟数据。
我向朋友们展示的最初版用户界面截图，实际上是由这些模拟数据所支撑。尽管这些并非实际数据，所呈现的效果却足以让人直观地预览到应用最终的形态。
Claude 生成的模拟数据驱动的应用程序截图展示在眼前。
在 MCP 生态体系尚不健全的初期阶段，大部分服务器仅采纳了标准中的“工具”模块，而其他诸多功能则鲜少被启用。然而，我仍需在用户界面中核实这些特性是否能够准确呈现——在这种情境下，模拟数据的必要性便显得尤为突出。
高质量自动化几乎不再需要成本
发布流程中最为折磨人的“尾声20%”之一，便是搭建一套自动化的发布机制。特别是在macOS平台上，必须处理代码签名、软件认证、打包等多个繁琐环节。
在以往的项目执行过程中，我常常会进行多次实验，手动对fastlane进行配置，并且额外编写了一些简陋的Python脚本，以此勉力达到自动化的目的。然而，这次的情境却截然不同。
我投入了数小时进行反复试验，借助 Claude 的协助，成功编撰了一个发布脚本，该脚本能够执行以下任务：
脚本功能一旦完备，我仅需输入一个简洁的指令，Claude便能够对CLI的输出界面进行美化，呈现出的最终效果是：
运行 Claude 生成的构建 & 发布自动化脚本
该脚本包含了两千行的Python代码。若由我亲自重新编写，我只会着重完成其中的关键环节，而不会投入精力去实现如此周全、界面亦十分精美的效果。
现在，每当推出新版本，我都能减少十几分钟甚至更多的时间进行手动操作。这一切的实现，仅仅通过几段自然语言说明，再加上对 Claude 在运行过程中遇到的问题进行调试，便轻松解决了。
未来的 IDE 会大不相同
在这个项目实施过程中，我主要依赖了两种工具——Claude Code 和 GitHub Desktop（它主要用于查看代码差异）。
在绝大多数情况下，我并不依赖传统编辑器的常规操作，诸如文件目录浏览、代码编辑以及插件扩展等功能。虽然偶尔我会启动 Xcode 进行一些手动调整，但这样的情况并不多见。而且，我对于 Xcode 的特殊功能，如 SwiftUI 预览和界面调试器等，使用得更是寥寥无几。
这仅仅是当前“最糟糕”的AI编程助手水平。我不禁想象，未来的集成开发环境或许将与现今的截然不同。
Cursor、Windsurf 和 Copilot 均源自 VS Code，随后各自走上了不同的道路。然而，它们的核心特性不过是将人工智能技术融入了一个在“人工智能出现之前”就已经设计好的编辑器中。从结构上分析，VS Code 与二十年前推出的 JetBrains IDE 并无根本性的差异。
我也留意到了诸如Warp这样的项目，它们正试图将自身从“现代终端模拟器”的角色转变为智能代理式开发环境。尽管我对Claude Code颇感兴趣，但我并不认同“命令行终端”将成为未来开发体验的最优选择。
我坚信，未来的集成开发环境（IDE）在设计时将重点考虑如何协助开发者“预热上下文”以及构建“反馈闭环”，这两点对于智能代理高效完成任务至关重要。这种全新的体验界面将与现今的代码编辑器有着显著的不同——虽然我无法精确描绘它的具体形态，但可以断言，源码编辑器将不再是其核心组成部分。
我终于又能发布业余项目了
对我来说，最让人兴奋的并非是最终推出了哪个应用，而是我得以再次沉浸在编写代码的乐趣之中，并且能够将经过精心打磨的副项目真正推向市场。
这感觉仿佛我每天额外拥有了五个小时——而为此所付出的“代价”，仅仅是每月仅需支付200美元。
我成功发布了这款完全由Claude Code构建的MacOS应用程序。
AI 产品爆发，但你的痛点解决了吗？
2025 全球产品经理大会
8 月 15–16 日
北京·威斯汀酒店
互联网巨头企业、人工智能领域的初创公司、专注于ToB和ToC领域的实战派产品从业者
12 大专题分享，洞察趋势、拆解路径、对话未来。
立即扫码领取大会PPT
抢占 AI 产品下一波红利
