Opus 4.5 不是正常的 AI Agent 体验

原文来源：Burke Holland — 一位资深开发者用 Claude Opus 4.5 在几小时内完成了过去需要数月才能交付的四个完整项目，并由此彻底改变了对 AI 能否替代开发者的看法。

如果你三个月前问我，那些声称 "AI 将取代开发者" 的 CEO 言论是否可信，我会毫不犹豫地回答：只有从未真正构建过复杂软件的人才会相信这种鬼话。AI 辅助编程确实能提升效率，代码补全也很强大，但说 Agent 能完全替代开发者？不可能，绝对不可能。

今天，我的看法彻底变了。我认为 AI 编码 Agent 确实有能力替代开发者，而让我改变想法的正是 Claude Opus 4.5。

Opus 4.5 不是正常的 AI Agent

我说的"不正常"，是指它完全颠覆了我此前使用 AI Agent 的所有体验。在此之前，AI Agent 给我的印象是：擅长写出意大利面条式的混乱代码，然后在九轮复制粘贴终端报错、输入"修复它"的循环之后，把我的代码库毁到需要直接丢弃整个对话会话的地步——三十分钟就这样白白浪费了。

Opus 4.5 给我的感觉，像是终于有人兑现了 AI 编程的承诺。它不是那种"理论上很美好"的演示，而是真正交付了可用的成果。

写下这句话最困难的地方在于，我知道读者的第一反应一定是"证明给我看"。好，让我展示我用它实际构建了什么。

项目一：Windows 图片格式转换工具

我第一次意识到 Opus 4.5 与众不同，是在用它构建一个 Windows 桌面小工具时。这个工具的功能很简单：在文件资源管理器中右键点击图片，就能将其转换为不同的文件格式。我只是问了 Opus 最佳实现方式，然后它基本上一遍就完成了整个构建。

整个过程中最让我震惊的是，Opus 4.5 大部分时候都能一次做对。如果遇到编译错误，它会自动使用 dotnet CLI 构建项目，读取错误信息，然后迭代修复。唯一需要我介入的地方是 XAML 界面错误——Opus 看不到这些可视化错误，我需要用 Visual Studio 查看后把报错信息贴回对话里。

但这还没完。Opus 还帮我搭建了分发网站，处理了可执行文件的打包，编写了 PowerShell 安装和卸载脚本。甚至连 GitHub Actions 的自动发布流程和网站更新都一并搞定了——我只需要推送源代码，剩下的全自动完成。

唯一需要借助其他工具的地方是 Logo 设计，我用 Figma AI 生成了几种变体。但随后 Opus 又编写了脚本，把 SVG 转换成各种格式的图标文件，甚至包括应用商店分发所需的规格。

诚然，这算不上什么复杂应用。它只是一个做一件小事的 Windows 工具，跟 Photoshop 完全不在一个量级。

但接下来，我"真的"让它做了类似 Photoshop 的事。

项目二：屏幕录制与视频编辑器

图片转换工具的成功让我信心大增，我决定挑战一个 GIF 录屏工具，类似 Mac 上的 LICEcap。结果这太容易了，于是我继续叠加功能：视频录制与编辑、静态图片处理、添加图形、裁剪、模糊效果……虽然一个完整的图像视频编辑器确实是浩大工程，我还在持续完善中，但仅仅几个小时我就做出了相当可观的成果。

这个项目目前还没有精致的落地页，但全部源代码已经公开在作者的 GitHub 上。

做到这里我意识到：如果视频录制应用都能做，那 UI 层面我几乎可以构建任何东西了。但所有 AI Agent 的阿喀琉斯之踵在于后端系统的整合——任何真实世界的应用都需要认证、数据库、API、存储。这些才是硬骨头。

但 Opus 4.5 连这些也能搞定。

项目三：AI 自动发帖助手

带着对 Opus 4.5 的信心，我捡起了一个去年用 React Native 开发、在 Android 上基本完成但 iOS 版本最终放弃的项目。

这个应用是给我妻子做的。她经营一家小型庭院标牌加盟生意，有个 Facebook 商家页面，但从不发帖——因为太耗时。然而任何好的小企业都需要活跃的社交页面，让客户看到业务动态，知道这家店真实存在且运营良好。

想法很简单：每次她安装完庭院标牌都会拍照发给客户确认。那何不做个移动应用，让她一次上传十张照片，AI 自动生成文案，然后排期在未来一周分批发布？

听起来简单，实则涉及大量组件：Facebook 认证本身就是个坑，后端认证、照片文件存储、定时发布的后端任务调度——这是一个完整的前后端全栈项目。

那天我正好要在家安装百叶窗，于是心想：不如让 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 Server，不需要复杂的提示词文件告诉它怎么用 Firebase。

当然，既然能做，我又让它搭了一个后端管理面板，让我能看到待发布的内容并做调整。

既然它用几小时完成了我此前两个月晚上加班才做到的事，我决定"将功补过"——再为妻子的生意做一款应用，替代她目前在付费使用的另外两款工具。

项目四：订单追踪与路线规划

这款应用能解析她生意邮箱里的订单，展示当天需要安装或回收的标牌任务，计算每个地点的预计耗时，多地点时自动规划最优路线，还能记录驾驶时间用于报税。此前她需要付费订阅两款独立应用来完成路线规划和里程追踪。

这个应用同样基于 Firebase。Opus 4.5 又一次一次性搞定了 Google 邮箱认证集成——这种工作手工做极其繁琐痛苦。Firebase 在这里再次大放异彩，因为 Opus 对 Firebase CLI 的使用驾轻就熟，完全不需要额外指导。

"但你根本不懂代码怎么工作的"

你说得对，我确实不太懂。我大概知道个轮廓，但说实话，我不了解这些应用具体是怎么组装起来的。尤其我还完全不懂 Swift。

这曾经是我的一个巨大心理障碍。以前遇到问题时我无法诊断，只能干瞪眼。但使用 Opus 4.5 以来，我还没遇到过它解决不了的墙——它总能自己找出问题并修复自己的 Bug。

真正的疑问是代码质量。如果不理解实现细节，怎么知道有没有重复代码、死代码或者糟糕的设计模式？我以前对此非常纠结。但现在我越来越不担心人类是否需要阅读这些代码了，因为我真的不确定人类还有没有必要读。

为什么人类需要读这些代码？我在 VS Code 里用了一个自定义 Agent 提示词，告诉 Opus 写代码是给 LLM 看的，不是给人类看的。想想看：既然 AI 在做所有工作，而且你问它时它会解释，那为什么要为了人类可读性而优化？

你不需要的是：变量命名规范、格式化风格、面向人类的注释、为了照顾人类大脑而设计的模式。

你真正需要的是：简单的入口、显式而非抽象的代码、最小耦合、线性控制流。

以下是我使用的自定义 Agent 提示词核心思想：

你是一个 AI 优先的软件工程师。假设所有代码都将由 LLM 而非人类编写和维护。优化目标是让模型易于推理、重新生成和调试——而不是人类审美。

始终使用 #runSubAgent。上下文窗口有限，尤其是输出容量。你应该始终以离散步进工作，每一步都用 #runSubAgent 执行，尽量避免在主上下文窗口中堆积内容。

始终使用 #context7 MCP Server 读取相关文档。每次使用某种语言、框架或库时都这样做。永远不要假设你知道答案，因为这些技术频繁变化，你的训练日期已经过去，知识很可能已经过时。

每次完成任务或学到关于项目的重要信息时，更新 .github/copilot-instructions.md 或项目中的 agent.md 文件，记录新信息或需要同步的变更。

在将控制权交还给用户之前，始终检查你的工作。运行测试、验证构建等。永远不要向用户返回未完成或未验证的工作。

做终端实例的好管家。尽量复用现有终端，并用 VS Code API 关闭不再需要的终端。

说实话，我没有证据证明这个提示词起了多大作用。我发现 Opus 4.5 不管你怎么提示，写出来的代码本身就已经相当扎实。但因为模型喜欢写代码远胜于删代码，我偶尔会运行这样的提示：

检查你的 LLM AI 编码原则，然后对整个应用做全面搜索，建议如何重构以更好地对齐这些原则。指出可以删除的代码、可以删除的文件、应该重命名的东西、应该重组的结构。然后写一个高层概览文档，分高、中、低优先级。如果某样东西不需要改，就不要改。不要为了改而改，只有当改动有助于对齐原则时才改。保存为 Markdown 文件。

你会得到一份分优先级的文档。高优先级的问题处理掉之后，AI 就不会再反复提。你可以无限次重构，它永远能找出中低优先级的改进项——AI 永远不会放过生成文字的机会。

我用类似的提示来查找安全问题。这部分必须非常谨慎：API 密钥放在哪里？登录处理是否正确？敏感值是否存入了数据库？这大概是整个过程中最需要人工介入的部分，也是目前让我对这些应用最不放心的地方。我不是 100% 确信它们坚不可摧，大概只有 80% 的信心。而正如人们所说，这远远不够。

时代正在改变

我不知道自己该为几小时就能构建过去难以想象的东西而兴奋，还是该为花费毕生精力学习的技能现在被计算机变得如此 trivial 而沮丧。两种感受都是真实的。

我理解如果这篇文章让你感到愤怒。我明白——我也不喜欢听人说"AI 将取代开发者"。但我再也无法对此嗤之以鼻了。我可以希望这不是真的，但愿望改变不了现实。

但除此之外呢？去构建吧。别再等待所有答案都清晰。别再试图在 AI 优先的世界里找到自己的位置。答案和过去一样：做东西。而且现在你建造的速度远超以往任何时候。

只是别忘了看好你的 API 密钥。