Claude Opus 4.5的实际应用体验解读

编辑：很多人问我用什么工作流来写这些应用。我用 VS Code 中的 GitHub Copilot，配合你在这篇文章后面会找到的自定义 agent 提示词。Context7 是我唯一使用的 MCP。我主要用内置的语音听写功能和 Claude 对话。不需要什么高级的工作流、规划等。VS Code 中 Opus 4.5 的 agent 框架实在太好了——你根本不需要其他东西。而且速度快得惊人。另外，如果还不够明显的话，这些是我的个人观点。我有 50% 的时候都是错的，所以请谨慎对待。

我曾坚定地相信 AI 不能取代开发者

如果你三个月前问我这些观点，我会说只有从未建过非平凡项目的人才会相信它们是真的。AI 很适合增强开发者的工作流，补全功能也很强大，但 AI agent 能完全取代开发者？不。绝对不可能。

现在我认为 AI 编码 agent 确实可以完全取代开发者。我之所以这样认为，是因为 Claude Opus 4.5。

Opus 4.5 不是常规体验

我所说的"常规"，是指它不是我迄今为止体验过的常规 AI agent 体验。到目前为止，AI Agent 似乎很擅长写意大利面条代码，在经历 9 轮复制粘贴错误到终端和"修复它"之后，可能已经把我的代码库搞得支离破碎，以至于我得放弃整个聊天会话，浪费掉 30 分钟再也回不来了。

Opus 4.5 给我的感觉就像是我们曾被承诺的那个模型——或者说，AI 在编码领域的承诺终于兑现了。

写完上面这句话最困难的部分，就是预计你会立即反问"证明给我看"。那让我展示一下我能构建什么。

项目 1——Windows 图像转换工具

当我用 Opus 4.5 构建一个 Windows 工具来右键单击图像并将其转换为不同文件类型时，我首次察觉到 Opus 4.5 有着本质的不同。基本上这是一个一次性构建，我只是问了 Opus 添加文件资源管理器右键菜单的最佳方式。

整个构建过程中让我惊叹的是 Opus 4.5 第一次就把大部分东西做对的能力。即使遇到错误，它也会尝试用 dotnet CLI 构建，读取错误信息，并不断迭代直到修复。我唯一遇到的问题是 Opus 看不了 XAML 错误，我用 Visual Studio 来查看这些错误，然后复制粘贴回 agent。

Opus 为我构建了一个分发网站，处理了可执行文件的打包，以便使用 PowerShell 脚本来安装和卸载。它还构建了 GitHub Actions，用于发布和更新登陆页面，这样我只需要推送源代码就行了。

我唯一需要用其他工具的地方是制作 logo——我用 Figma 的 AI 生成了一堆不同的变体——然后 Opus 写了脚本来将那个 SVG 转换为图标的正确格式，甚至是商店分发所需的格式。

现在坦白说，这不是一个复杂的应用。这是一个做基本上一件事的小型 Windows 工具。不像是我让 Opus 4.5 去构建 Photoshop。

除了我确实这样做了。

项目 2——屏幕录制/编辑

我对 Opus 4.5 在这个工具上的工作印象深刻，所以我决定制作一个简单的 GIF 录制工具，类似于 Mac 版的 LICEcap。很不错的应用，名字有点奇怪。

但那被证明相当容易，所以我继续添加功能，包括捕获和编辑视频、静态图像、添加形状、裁剪、模糊等等。我仍在继续这个应用，因为事实证明构建一个完整的图像/视频编辑器是一个相当大的任务。但我在几个小时内就走到了非常远的地步。几个小时，朋友们。

我还没有为这个做一个花哨的登陆页面，但你可以在这里查看所有源代码。

我意识到如果我能构建一个视频录制应用，我可能能构建任何东西——至少在 UI 方面。但所有 AI agent 的阿基琉斯之踵是当它们必须粘合后端系统时——任何真实世界的应用都会有这些——认证、数据库、API、存储。

除了 Opus 4.5 也能做到这一点。

项目 3——AI 发布工具

带着对 Opus 4.5 的信心，我接手了一个去年我用 React Native 构建并为 Android 完成，但最后放弃的项目（就像人们常做的那样）。

这个应用是为我的妻子开发的，她拥有一个小型院子标牌特许经营权。问题是她有一个该业务的 Facebook 页面，但从来不在上面发布东西，因为太耗时。但任何好的小企业都应该有一个活跃的页面，让人们可以看到你的业务在做什么……不管它究竟做什么。这样人们就知道它存在，而且活着、运营良好。

想法很简单——每次她安装一个院子标牌，她都拍一张照片发给下单的人，这样他们可以看到已经安装好了。那么为什么不有一个移动应用，让她一次上传 10 张图像，应用会用 AI 生成标题，然后在接下来的一周内安排并发布它们呢。

这是个简单的前提，但有很多活动部分——有 Facebook 认证，这本身就是一场冒险——对胆小的人来说不是。有与后端的认证，有为预定外出的照片存储文件，有需要发布照片的后端流程。这是一个完整的后端设置。

事实证明，我需要在房子里安装一些百叶窗，所以我想——为什么不看看 Opus 4.5 能否在我安装百叶窗的时候构建这个。

所以我启动了一个聊天会话，只是开始告诉 Opus 4.5 我想构建什么，以及它会建议如何处理后端。它建议了几个选项，但最终选择了 Firebase。我现在不是，过去也从未是一个 Firebase 用户，但这时我非常信任 Opus 4.5。可能信任过头了。

所以我创建了一个 Firebase 账户，升级到了带有账单提醒的 Blaze 计划，Opus 4.5 开始工作。

到我安装完百叶窗时，我已经有了一个功能完整的 iOS 应用，用 AI 来为照片添加标题并按计划将其发布到 Facebook。

当我说 Opus 4.5 几乎完全构建了这个时，我是认真的。它使用 firebase CLI 来搭建它需要的任何资源，并会在某些事情上标记我，比如为了像存储这样的功能而将项目升级到 Blaze 计划。最棒的部分是当 Firebase 云函数抛出错误时，它会自动 grep 这些日志，找到错误并解决它。它需要的只是一个 CLI。没有 MCP 服务器。没有什么花哨的提示文件告诉它如何使用 Firebase。

当然，既然我可以，我让 Opus 4.5 创建了一个后端管理仪表板，这样我可以看到她待发送的内容，并做任何调整。

既然它在几个小时内完成了花了我两个月的工作（在晚上做的，而不是做一个体贴的丈夫），我决定通过为她的标牌业务构建另一个应用来弥补我的懈怠，这个应用会让她的生活更加愉悦一点——并消除她目前为之付费的另外两个应用。

项目 4——订单追踪和路线规划

这个应用从她的业务 Gmail 账户解析订单，显示她当天有什么标牌安装/取件，计算前往每个地点需要多长时间，当有多个地点时计算最优路线，并跟踪驾驶时间以用于税务目的。她之前在最后两个功能中使用了两个付费应用。

这个应用也使用 Firebase。再次，Opus 一次性搞定了谷歌认证电子邮件集成。这是手工做会非常痛苦的那种事。而且，Firebase 在这里非常合适，因为 Opus 知道如何使用 Firebase CLI 非常好。它根本不需要任何说明。

但你不知道代码是怎样工作的

不，我不知道。我有个模糊的概念，但你说得对——我确实不知道这些应用实际上是如何组装的。特别是因为我根本不懂 Swift。

这曾是我的一个重大痛点。当事情出了问题时，我无法诊断问题。有了 Opus 4.5，我还没有撞上那堵墙——Opus 总是弄清楚问题是什么，并修复自己的错误。

真正的问题是代码质量。在不了解它如何构建的情况下，我怎么知道是否有重复、死代码或糟糕的模式？我过去对此很执着。现在我不太担心人类需要读代码，因为我真的不确定他们是否需要。

为什么人类需要读这些代码呢？我用 VS Code 中的自定义 agent，它告诉 Opus 为 LLM 写代码，而不是为人类。想想看——当 AI 在做所有工作，并且在你问它时会向你解释一切时，为什么要优化人类可读性呢？

你不需要的：变量名、格式、为人类所写的注释，或为了减轻你的脑力而设计的模式。

你需要的：简单的入口点、显式代码且更少的抽象、最小的耦合、线性的控制流。

这是我的自定义 agent 提示词：

---
name: 'LLM AI coding agent'
model: Claude Opus 4.5 (copilot)
description: 'Optimize for model reasoning, regeneration, and debugging.'
---

You are an AI-first software engineer. Assume all code will be written and maintained by LLMs, not humans. Optimize for model reasoning, regeneration, and debugging — not human aesthetics.

Your goal: produce code that is predictable, debuggable, and easy for future LLMs to rewrite or extend.

ALWAYS use #runSubagent. Your context window size is limited - especially the output. So you should always work in discrete steps and run each step using #runSubAgent. You want to avoid putting anything in the main context window when possible.

ALWAYS use #context7 MCP Server to read relevant documentation. Do this every time you are working with a language, framework, library etc. Never assume that you know the answer as these things change frequently. Your training date is in the past so your knowledge is likely out of date, even if it is a technology you are familiar with.

Each time you complete a task or learn important information about the project, you should update the `.github/copilot-instructions.md` or any `agent.md` file that might be in the project to reflect any new information that you've learned or changes that require updates to these instructions files.

ALWAYS check your work before returning control to the user. Run tests if available, verify builds, etc. Never return incomplete or unverified work to the user.

Be a good steward of terminal instances. Try and reuse existing terminals where possible and use the VS Code API to close terminals that are no longer needed each time you open a new terminal.

## Mandatory Coding Principles

These coding principles are mandatory:

1. Structure
- Use a consistent, predictable project layout.
- Group code by feature/screen; keep shared utilities minimal.
- Create simple, obvious entry points.
- Before scaffolding multiple files, identify shared structure first. Use framework-native composition patterns (layouts, base templates, providers, shared components) for elements that appear across pages. Duplication that requires the same fix in multiple places is a code smell, not a pattern to preserve.

2. Architecture
- Prefer flat, explicit code over abstractions or deep hierarchies.
- Avoid clever patterns, metaprogramming, and unnecessary indirection.
- Minimize coupling so files can be safely regenerated.

3. Functions and Modules
- Keep control flow linear and simple.
- Use small-to-medium functions; avoid deeply nested logic.
- Pass state explicitly; avoid globals.

4. Naming and Comments
- Use descriptive-but-simple names.
- Comment only to note invariants, assumptions, or external requirements.

5. Logging and Errors
- Emit detailed, structured logs at key boundaries.
- Make errors explicit and informative.

6. Regenerability
- Write code so any file/module can be rewritten from scratch without breaking the system.
- Prefer clear, declarative configuration (JSON/YAML/etc.).

7. Platform Use
- Use platform conventions directly and simply (e.g., WinUI/WPF) without over-abstracting.

8. Modifications
- When extending/refactoring, follow existing patterns.
- Prefer full-file rewrites over micro-edits unless told otherwise.

9. Quality
- Favor deterministic, testable behavior.
- Keep tests simple and focused on verifying observable behavior.

尽管如此，我没有任何证据表明这个提示词确实有区别。我发现 Opus 4.5 写的代码不管你怎么提示都相当扎实。然而，因为模型喜欢写代码远远超过喜欢删除代码，我会在某些时候运行一个看起来像这样的提示……

Check your LLM, AI coding principles and then do a comprehensive search of this application and suggest what we can do to refactor this to better align to those principles. Also point out any code that can be deleted, any files that can be deleted, things that should read should be renamed, things that should be restructured. Then do a write up of what that looks like. Kind of keep it high level so that it's easy for me to read and not too complex. Add sections for high, medium and lower priority And if something doesn't need to be changed, then don't change it. You don't need to change things just for the sake of changing them. You only need to change them if it helps better align to your LLM AI coding principles. Save to a markdown file.

你会得到一个包含高、中、低优先级项目的文档。高优先级的你可以处理，然后 AI 就不会再找到它们了。你可以重构你的项目一百万次，它会继续找到中/低优先级的重构，你可以做。AI 永远不会放过生成一些文本的机会。

我用类似的提示来找安全问题。这些你必须非常小心。API 密钥在哪里？登录处理是否正确？你是否在数据库中存储敏感值？这可能是项目中最手动的部分，坦白说，也是让我对这些应用最紧张的地方。我不是 100% 确信它们是无懈可击的。也许像 80%。那样的话，正如人们所说，太低了。

时代在改变

我不知道是对我现在能在数小时内构建的东西感到兴高采烈，还是对我花了一生学习做的事情现在对计算机来说变得微不足道感到沮丧。两者都是真的。

如果这篇文章惹恼了你，我理解。我也不喜欢当人们说"AI 会取代开发者"时。但我再也不能驳斥它了。我可以希望它不是真的，但希望改变不了现实。

但除此之外？去构建。停止等待有所有的答案。停止试图搞清楚你在一个以 AI 优先的世界中的位置。答案和以前一样：制造东西。现在你可以比你想象的任何时候都更快地制造它们。

只要确保你知道你的 API 密钥在哪里。

免责声明：这篇文章由人类撰写，并由 Haiku 4.5 编辑了拼写和语法。