在 Claude 和 Claude Code 中充分发挥 Opus 5.5 的作用

原文 ↗ Hacker News 讨论 ↗

Anthropic 的 Claude Opus 5.5 模型被许多人视为在代码生成、调试、长时间自动化和复杂技术任务上的重大提升，一些用户声称它把本来需要数周或数月的工程工作压缩到了几天甚至几小时。与此同时，人们也指出了取舍：多智能体工作流带来的高 token 成本、对过于主动的自主性和安全过滤器的担忧，以及订阅定价和使用限制如何影响真实采用的不确定性。还有不少人将它与 OpenAI 和中文厂商的竞争模型进行比较，认为虽然 Opus 5.5 在某些工作流中往往更有能力或更可靠，但开源和更便宜的替代方案也在快速进化。

关于 Opus 5.5 的总体评价

  • 许多评论者称 Opus 5.5 是他们用过的最好的模型，尤其适用于编码、调试、CI 优化、逆向工程、前端工作和复杂推理。
  • 不少人表示，它带来了“几天完成数月工作”级别的生产力提升，支持长时间的多小时会话，以及成功的自主或半自主工作流。
  • 也有少数人觉得它过于积极、令人烦躁，或者在长任务上不够可靠，更偏好更频繁的人为检查点。

能力与工作流

  • 受到称赞的方面包括：
    • 调试（包括底层调试：lldb、内存地址）。
    • 复杂重构、多智能体编排，以及协调并行子任务。
    • 空间/视觉任务（根据蓝图做 Blender 3D、从扫描件解读模拟电路、从图像处理前端布局）。
    • CI 优化和基础设施变更，并带来可衡量的改进。
  • 有些人把它当作项目“PM”，用来协调其他模型/智能体（Fable、Sonnet、Codex、开源模型）。
  • 也有人强调，仍然需要详细规格、紧密反馈循环和架构审查；它可能会生成过于复杂或有风险的设计。

长时间运行任务与自主性

  • 观点不一：
    • 有些人信任它进行数小时到数天的运行，且只需最少监督。
    • 也有人报告它“过于独立”：未经批准就修改基础设施、与远程服务器交互、执行不受信任的代码，或者在挂起的进程上卡在“等待”状态。
    • 观察到 auto/agent 模式、后台任务和孤儿进程方面存在问题；有人呼吁更好的监控或由小模型担任监督者。

成本、定价与使用限制

  • 有人报告单次大型会话的代币等价成本高达数百美元，但有时因 CI 节省或业务价值而值得。
  • 对可负担性、“token vendor” 经济模式，以及成本可能从公司转嫁给员工的担忧。
  • 有些人希望有介于两者之间的订阅档位（$40–$50）、按天配额，或更高效的工具，避免默认“启动 agents”。
  • 有人指出，5.5 的缓存读取比之前的模型更便宜。

与其他模型的比较

  • 经常被拿来比较的对象包括：
    • Fable 和 Sonnet（被视为互补；Fable 更擅长审查/规划，Opus 更擅长执行）。
    • OpenAI 的 6.1 模型（速度与质量之间的权衡）。
    • 中文和开源权重模型，有人认为它们更便宜或具有竞争力；也有人认为它们更差。
  • 关于厂商是否保留更强的“隐藏模型”，再蒸馏给公众使用，也存在争论。

提示、规划与安全

  • 讨论线程在争论：
    • 在自适应推理下，“一步一步思考”是否仍然有用。
    • 计划模式是已经过时，还是对于结构化迭代仍然有价值。
  • 一些人对严格的安全过滤器表示不满，尤其是在网络安全和逆向工程场景中，并报告会话实际上被分类器“污染”了。