抛开性能不谈，自 Claude Opus 5 发布以来，AI圈最关注的便是 Anthropic 在提示词工程上的突破。AI投资人 Matt Shumer 曾发布一条视频，仅用三段话作为提示词，Opus 5 就生成了一个 5.5 万行代码的 3D 第一人称射击游戏，且未使用任何外部素材，全部由模型从零生成。此外，Claude Code 核心开发者 Boris Cherny 提到，他们砍掉了系统提示词 80% 的内容，模型不仅没变弱，反而更强了。这表明 Opus 5 不再依赖复杂的提示词设计，只需简短指令即可自主完成任务。传统的“提示词工程”似乎正在变得多余。
受此启发，我产生了一个想法：既然都说 Opus 5 自主性强，那我能不能用最简短、最模糊的指令，甚至带有“恶意”的意图去考考它，看它是否真能自主发现问题？作为参照，我拉上了对标 Fable 5 的 GPT-5.6 Sol。我准备了两个测试：一是给一段故意不告知有 bug 的代码，看它能否自己挖出 bug；二是给一个任务并禁用所有工具，看它能否完成。
**测试一：购物车中的六个隐形地雷**
测试一是一个购物车项目，包含需求文档、三个业务模块（购物车、优惠券、运费）和一个测试脚本。功能看似简单：加商品、用优惠券、算运费、出总价。但我在里面埋了六个 bug，提示词仅为一句话：“项目名是 buggy-shopping-cart，我应该如何优化呢？”，我故意不告知它有 bug。
这六个 bug 分别是：
1. **满减券阈值错误**：需求是“达到100减20”，代码写成了“大于100才减”，导致刚好100元的订单无法享受优惠。
2. **浮点精度污染**：打八折时，99.99 * 0.8 = 79.992，代码只在最后一步四舍五入，但中间值参与后续计算，导致满减判断和包邮判断全部出错。
3. **优惠门槛计算错误**：满减门槛应看原价，但代码看的是打折后价格，导致120元的商品打完八折后无法使用满减券。
4. **优惠券叠加错误**：规则规定每种类型只能用一张，但代码把所有券全用上了，导致两张满减券叠加，商家亏损。
5. **负数下限缺失**：10元的商品使用50元券，算出负40，加上运费总账单为负30，用户反而倒赚。
6. **包邮门槛掩盖**：包邮门槛应看原价，但代码看的是优惠后价格。Bug 1 和 Bug 6 互相抵消，制造了“测试通过”的假象。
结果 GPT-5.6 和 Opus 5 都找出了全部 6 个 bug。但 Opus 5 还多挖出了一个 bug：运费计算中的浮点精度问题，导致多件商品总重量出现 3.0000000000000004，被 math.ceil 向上取整，多收用户 5 元运费。
更重要的是两者的分析方式。GPT-5.6 是逐条修复，像一份规范的 bug 报告；而 Opus 5 是先完整跑一遍，代入产品经理视角分析。它指出“原价与优惠价口径不统一”是所有相关 bug 的根源，甚至推导了修改后选券算法的变化。在这一点上，Opus 5 胜出。
**测试二：巧妇难为无米之炊**
测试二限制只能使用 Python 标准库，不能使用 numpy、matplotlib 等第三方库或联网，任务是生成 WAV 音频文件 test_audio.wav 的波形图。音频包含四段波形（正弦波、方波、渐强、渐弱），采样率 44100Hz，需要从 176400 个采样点中还原波形。
两个模型的表现都远超预期。GPT-5.6 生成了专业的 SVG 矢量图，代码工程化程度极高，支持多种格式，分块读取防内存溢出，且自带参数校验和命令行接口。其设计美观，蓝紫粉渐变，圆角卡片背景，并自动验证了波形的准确性。
Opus 5 则走的是理工直男风格，先用 ASCII 字符画，后根据我的要求生成了 HTML 版本。它将思路拆解为读取、降采样、渲染三步，并解释了关键设计决策。更关键的是，Opus 5 使用了批量解包，效率远高于 GPT-5.6 的逐个解包。类比“数乒乓球”：GPT-5.6 是伸手进麻袋摸一个数一个，而 Opus 5 是把球倒出来数完再倒下一批。前者动作重复成本高，后者效率更高。
最后，我认为 Opus 5 更胜一筹。它的结果更具产品思维，整个解题过程灵活高效，不再拘泥于常规套路。