来源信息

  • 文档类型：阅读笔记 · 整理日期 2026-10-07
  • 原文：《Getting the most out of Opus 5.5》 · 作者 Addy Osmani · 发布于 claude.dev · 发布日期 2026-09-22
  • 原文地址：https://claude.dev/blog/getting-the-most-out-of-opus-5-5/
  • 本文为阅读整理，观点与数据以原文为准；原文不提供的事实均已标注为整理者说明。

阅读范围

  • 已读取全文，包括六个主题及末尾检查清单。

提问与长任务

文章的起手建议是交代完整任务、完成标准和停下来询问的条件。对这版模型，泛泛要求“认真思考”未必有益；想调整投入应使用 effort。运行中可补充要求，设计请求则应列出具体不想要的视觉套路。

长任务需约定何时继续、何时等待人决定，破坏性操作仍保留权限检查。大规模审计可分给子代理，但主代理要核查证据。任务清单落在文件中，可在上下文压缩后保留进度。

验收与 Claude 应用

收尾先看待人决策或批准的事项，再查变更和发现。代码审查要求给出足以阻止合入的问题及复现证据；研究需标明未确认内容和查找范围。

应用侧建议直接提供图表原图，检查长文内部矛盾，明确要求交付成品文件。已定答案可声明暂不重审，以减少反复；持续推演的分析项目不宜这样做。

标记、速度与边界

文章描述被安全检查标记后可能转到旧模型，检查范围包含历史内容、文件与搜索结果；用户可查看切换提示并反馈误报。解释选择依据比索要内部推理过程更合适。

当时的 fast mode 是同模型的研究预览，强调交互速度，需额外用量且单价更高。本文未核实当前价格或开关行为；版本功能、早期测试反馈和模型间比较均不能当作普遍保证。末尾清单把提问、长任务、验收与标记处理汇合成检查点。

游戏开发应用建议

以下为整理者建议，非原文实测，也不表示已经实施。

  1. 给要塞 NPC 系统写清完成条件：资源占用可追踪、任务可打断恢复、关键场景可复现；把玩法选择留给人决定。
  2. 长任务清单分别记录实现、验证与待决策项，避免“代码写完”被误认为“玩法验收完成”。
  3. UI 设计附截图与具体约束；验收要求指出画面、数值和状态流之间的矛盾，并区分已验证与待人工试玩。

我的判断是，长任务自治需要清楚的交接接口。可先试一个小功能，观察是否准确识别阻碍、是否提供可复查证据，再扩大范围；不能仅凭运行时间长就判断完成质量。成本与速度也应结合任务成功率一起评估。

小结

先定义交付与停顿条件，再用证据验收；清单和明确交接能减少长任务中的误解。

参考来源

相关笔记