Sonnet 5.5

模型性能与基准测试

• 许多人认为 Sonnet 5.5 在代理式编码方面大致与 Opus 5.5 持平：Terminal-Bench、FrontierCode、CursorBench 分数都很强；有时略胜，有时略逊。
• 有人认为这些基准已经“benchmaxxed”，过度强调特定任务；也有人指出外部社区基准（Pac-Man 游戏、ArtificialAnalysis）显示，在最大努力下 Sonnet 5.5 仅略落后于 Opus 5.5。
• Terminal-Bench 的差距部分归因于 Sonnet 相比 Opus 更少触发安全回退，这也引出了护栏如何扭曲分数的问题。

成本、定价与定位

• 反复出现的抱怨是：在 high/xhigh/max 努力级别下，Sonnet 5.5 的成本往往与 Opus 的 low/medium 相近，甚至更高，但结果只是相似或略好；不少人质疑 Sonnet 为什么要存在于曲线的那一段。
• 在 low/medium 努力级别下，Sonnet 5.5 看起来比 Sonnet 5 便宜约 30% 且更快，也比 Opus 更便宜；一些人认为这才是它的真正定位。
• 许多人将它与更便宜的模型（OpenAI Luna、中国模型如 DeepSeek/GLM/MiMo）作负面对比，认为 Anthropic 在“够用就好”的工作上，在 $/速度 方面落后“10–100 倍”。
• 即将推出的 Haiku 5.5 预计将瞄准低成本、高吞吐量档位，但有人认为除非定价接近 Luna，否则它已经“DOA”。

使用场景与 harness 模式

• 一个常见建议模式是：用 Opus/Fable 作为编排器，用 Sonnet 作为子代理来做体力活（总结、重构、网页抓取），以节省 token 并提高并行度。
• 也有人说子代理的开销和缓存未命中可能抵消节省；还有人干脆在订阅下对所有事情都用 Opus。
• 有人建议将 Sonnet 5.5 用于产品侧 API 调用（解析用户文本、简单任务），而不是那种 Opus 或开源模型占优的重型开发 harness。

安全性、网络安全护栏与 CVP

• 对“cyber”护栏的强烈不满：授权安全工作、老旧 C/C++ 代码、蓝牙、WAL、编译器等，都会经常触发降级到旧模型。
• 几位评论者表示 Cyber Verification Program 并没有实质放宽护栏，主要影响事后执行，而不是实时拦截。
• 有人认为 Anthropic 的安全立场削弱了编写安全代码的能力，并把用户推向无审查的开源/中文模型。

模型行为与 UX

• Sonnet 5 被普遍描述为性价比差（冗长、说教味重、弱于开源模型）；而 5.5 则被认为有了显著改进，更快、更平衡，但在某些人眼里“感觉”仍不如 Fable。
• 对最大努力下过长的推理和巨大的 token 消耗表示抱怨；同时也称赞低努力级别下的速度。
• Anthropic 的营销图表被批评为令人困惑，或在 Sonnet 与 Opus 的对比中对 Sonnet 不利；Fable 的基准测试缺席也被点名。

中文模型与小模型 vs 前沿实验室

• 许多人反馈 GLM 5.3 Flash、DeepSeek v4.1 Flash、Qwen、MiMo 的性价比非常好，尤其适合 cyber 任务和“体力活”。
• 关于中文模型是否真的接近前沿水平，还是只是“性价比不错”，争论不断；一些人认为它们落后前沿大约 6–12 个月，但在经济上已经足够关键，另一些人则认为前沿模型仍然明显更强。

AI、工作与生存性担忧

• 有一个关于“vibe coding”的长子线程：让代理生成大部分代码 vs 人类保持深入理解。
• 有人接受并行代理群并容忍较低理解度；也有人担心系统将难以维护，以及人类能动性和工作意义的流失。
• 更广泛的担忧包括工资压制、K 型分化，以及如何应对 AI 驱动的不确定性；反方则认为理解问题领域和数据结构仍然重要，这限制了纯“vibe coding”的可行性。

Bug、鹈鹕与基准测试文化

• 反复出现的“骑自行车的鹈鹕”SVG 测试显示，Sonnet 5.5 在最大努力下会撞上 128k 输出 token 上限并无响应，暴露出一个实际 bug；较低努力级别则工作正常且成本低。
• 有人觉得这个反复出现的测试被过度曝光；也有人认为它是一个有用、直观且能揭示成本的基准测试传统。