写在前面

Claude Opus 5 这次最醒目的数字，不是某个榜单多拿了几分，而是一个更像真实工作的案例：4 句话提示，模型自己跑了 8 小时，产出约 7 万行代码，完成一个网页版 3D 游戏浏览器，让 420 万格地图在 6 秒内加载，并保持 60fps。

这组数字听起来很适合做发布会烟花，但开发者真正该盯住的是另一个变化：模型开始承担“持续推进任务”的责任。它不只是写一段函数、补一个单测、解释一个报错，而是在一个较长时间窗口里自己拆步骤、检查结果、返工修正，把任务往交付方向推。

这不等于四句话就能解决所有工程问题。更准确地说，前沿模型正在把一部分项目管理、质量复核和中间决策吸进模型内部。人的角色不会消失，但会被迫往上移：你要说清楚目标、素材、禁区、验收标准，以及哪一步必须由人确认。

8 小时案例的关键不只是“写得多”

Anthropic 首席产品官 Mike Krieger 分享的这次实测很有画面感。他小时候喜欢《运输大亨》，于是让 Opus 5 为旧存档做一个网页版 3D 浏览器，目标是走进地图里，看列车照常运行。

提示词只有四句话。8 小时后，模型不仅写出了约 7 万行代码，还让 420 万格世界在 6 秒内加载、保持 60fps，并且额外补上了没有被明确要求的昼夜循环。

这不是严格对照实验，也不能直接推出“所有复杂项目都能这么跑”。但它足够说明一个方向：如果任务目标清楚、边界明确、评价标准可执行，模型可以在更长的时间里自己寻找下一步，而不是等人把工作拆成一串小指令。

以前用 AI 做复杂项目，人最累的部分往往不是写提示词，而是当一个很烦的项目经理：拆任务、盯进度、查漏项、退回返工、重新组织上下文。Opus 5 展示的是另一种协作形态：模型开始自己承担一部分“我要把这件事做完”的过程管理。

它变强的地方，是会先补工具和测试台

这次发布里有三个案例特别适合开发者看。

第一，模型看不到图时，会先给自己造“眼睛”。任务要求根据机械零件图重建 FreeCAD 3D 模型，但不直接提供看图工具。Opus 5 先从原始像素写出视觉处理流程，再继续完成重建。

第二，修 bug 时不只盖住表面。面对一个流行开源包管理器的真实问题，它不只是找到根因，还补上社区原修复遗漏的边缘情况。

第三，没有真实数据时，会先造测试台。为一家交易公司接入新交易所行情时，现场没有可用的实时 feed，模型自己搭建测试工具，验证解析逻辑。

这三个例子背后是同一个能力：模型不再只等你提供完美上下文，而是会为了完成目标主动补齐中间条件。缺工具，造工具；缺数据，造测试；发现边缘情况，补验证。

对工程团队来说，这比“更会写代码”重要得多。代码本身只是交付物的一部分，真正决定项目能不能跑起来的是工具链、测试、边界条件、验收标准和回滚路径。

提示词没有消失，只是从遥控变成验收书

很多人看到“四句话”会得出一个过度简单的结论：以后提示词不用写细了。这个理解有点危险，像看到厨师刀快，就决定菜谱可以随缘。

更合理的变化是，提示词从“逐步遥控”变成“目标、边界和验收书”。

过去你可能这样用模型：先写页面，再写接口，再写测试，再修一个报错，再补一个边缘情况。每一步都由人拆开。现在更有效的方式是给模型一个完整任务包：目标是什么，已有代码在哪里，哪些文件不能动，性能指标是多少，安全禁区是什么，最终必须通过哪些测试。

这会把开发者的能力重心从“会不会问问题”推向“会不会定义工作”。你给的不是命令流水账，而是一份小型 PRD、工程约束和验收协议。

这种变化会影响不止程序员。老师可以给课程目标、学生水平和验收标准，让模型产出教案、练习和分层讲解，再要求它自查难度曲线；内容团队可以给受众、事实边界和引用规则，让模型完成资料整理、结构、初稿和核对；创业团队则要重新审视那些只靠“把多个模型代理包装起来互相检查”的产品，因为底层模型正在吞掉一部分中间层价值。

成本不能只看 token 单价

Opus 5 的 API 定价和 Opus 4.8 相同：每百万输入 token 5 美元，每百万输出 token 25 美元。Fast 模式大约快 2.5 倍，价格翻倍。开发者还能在 low、medium、high、xhigh、max 五档 effort 中选择：要更省 token，还是让模型多想一会儿。

独立评测机构 Artificial Analysis 给出的对比更有意思：Opus 5 max 在 Intelligence Index 得分 61，和 Fable 5 的 60 基本持平；但完成一项评测任务的平均成本是 2.03 美元，并不是所有较低 effort 档都更划算。

所以，团队评估这类模型时别只盯每百万 token 多少钱。真实工程成本应该看“成功一次多少钱”：

• 一次任务需要跑几轮？
• 返工次数是多少？
• 人工接管点在哪里？
• 最终有没有通过测试和验收？
• 失败后能不能定位原因并复用经验？

便宜但总失败的模型，往往最贵。贵一点但能稳定把任务推进到可验收状态的模型，反而可能更省。

官方 API 和订阅路径仍然是最直接的方式，但国内团队常见的麻烦是账号、支付、网络和 endpoint 管理。只是想先把 Claude、GPT、Gemini 这类能力接进已有工程系统，可以看 Code80，用真实订阅账号转 API，换 endpoint 就能跑通原型和评测链路。

别急着神化：事实问题仍会自信犯错

Opus 5 在长任务上更像执行者，但这不代表它在所有问题上都更可靠。

同一份 Artificial Analysis 报告里还有一个不太舒服的结果：在 AA-Omniscience 事实知识评测中，Opus 5 的准确率比 Opus 4.8 提高了 7 个百分点；但它在不确定时更愿意回答，幻觉率反而上升 14 个百分点，达到 50%。

这个结果并不矛盾。一个模型可以更会规划、更会写代码、更会使用工具，同时仍会在事实缺口上给出听起来完整但不成立的答案。尤其是医疗、法律、财务、新闻、公司信息和安全问题，仍然需要一手来源和人工检查。

Anthropic 也明确说明，Opus 5 在高风险双用途能力上仍落后于 Mythos 5。网络安全等特定请求可能被分类器拦截，或者回退到 Opus 4.8。自动回退可以让流程不中断，但不会替团队承担验收责任。

这就是长任务 Agent 的吊诡之处：它越能干，越需要明确护栏。你可以让它连续工作 8 小时，但不能让它连续 8 小时自由访问生产密钥、客户数据和外部网络。

现在最值得做的实验

别先问“Opus 5 是不是最强”。更好的问题是：它能不能在你的流程里稳定交付？

挑一个真实、可回滚、已有人工答案的任务。比如重构一个内部工具、迁移一个小模块、补全一个测试薄弱的服务、做一份性能诊断报告。给模型四类信息：

• 目标：最终要交付什么。
• 素材：允许读取哪些文件、文档和日志。
• 禁区：哪些目录、命令、数据和外部访问不能碰。
• 验收：必须通过哪些测试、指标和人工检查。

然后记录耗时、token、失败轮次、人工接管点和最终通过率。多跑几次，你会比任何排行榜更快知道它适不适合你的团队。

Claude Opus 5 到底适合放在哪

Opus 5 适合处理目标清楚、上下文充分、验收标准明确的长任务，比如多文件重构、复杂代码理解、测试生成、工具链搭建、技术方案草稿和数据分析流程。它不适合被当成完全无人值守的生产操作者，也不适合在事实敏感领域直接给最终结论。

如果你已经在用 Claude Code、Codex 或其他 AI 编程工具，一个可行的组织方式是：让模型处理可回滚改动，让 CI 做第一轮验收，让人类负责最终判断。模型负责推进，人负责边界。

国内团队如果要试 Claude 或 GPT 的长任务 Agent，建议先从隔离仓库和低敏数据开始，把账号链路、endpoint 管理和模型评测拆开处理；但权限、日志和回滚设计必须自己补上。

常见问题

四句话真的够做复杂项目吗？

只在目标足够清楚、上下文足够完整、验收标准足够明确时才可能有效。随便写四句话，模型并不会凭空知道你的工程边界。

Opus 5 和普通代码补全最大的区别是什么？

普通补全偏向局部生成，Opus 5 展示的是长时间任务推进能力：自己拆步骤、补工具、做验证、发现遗漏并返工。

长任务 Agent 上生产最危险的点是什么？

权限。尤其是文件系统、网络、密钥、数据库和发布动作。模型能连续执行越久，越需要沙箱和审计。

评估模型成本看什么？

看成功一次的总成本，而不是 token 单价。包括任务轮次、返工次数、人工接管时间、测试通过率和失败可复用性。