Theo 如何用 Opus 5.5 处理较长的编程任务

我越用 Opus 5.5，就越欣赏它写出的代码、协作方式，以及持续处理长任务的能力。我会解读 Addy Osmani 写的一份 Anthropic 指南，看看如何更好地使用它，并补充自己工作中的例子和不同看法。

指南称模型可以更长时间独立工作、清楚说明做了什么，并在回复前思考。第一条建议是交代完整任务、说明什么算完成，并指出何时需要停下询问。我把同样的思路称作扩大提示范围：让代理更早参与、走得更远。

例如，不要只说开始做一个功能。可以描述期望行为、要求一张有助于验证的截图，并说明需要准备拉取请求。明确终点能给代理一个具体目标，但结果仍需要审查。

指南还建议删除多余的“仔细思考”指令，并在长任务结束后首先查看代理需要用户做什么。以我的经验，它往往会清楚报告，但有时我仍需要主动询问遗漏的状态。

我自己的一个任务在 max 推理档位运行了六个半小时，却没有达到预期。我切到 high，询问工作状态，然后明确要求继续；大约十分钟后，它取得了有用进展。这只是一个案例，并非对不同档位的受控比较。

接着我想把工作移到另一台机器。我没有手动完成所有配置，而是描述目标机器、连接信息所在位置、所需仓库和环境，以及希望新任务如何在 T3 Code 中显示。

我要求代理检查配置并报告失败，也明确授权了我预期需要的特定环境变量处理，同时要求它不要用浏览器或电脑控制请求打断我正在使用的电脑。访问凭据和远程机器仍须符合用户实际授予的权限及保障措施。

提示还给了它一个退路：如果某件事不按预期工作，可以向我求助。我希望代理继续处理常规步骤，但遇到真正的不确定性时应说出来，而不是无休止地尝试，或假定所有有风险的操作都已获授权。

配置花了约 17 分钟，远程任务也出现了，但我随后发现它只完成了重写计划的阶段零。我发了后续消息，要求它继续完成剩余阶段，最后提供可测试的链接。目标清楚也不能保证代理会正确执行每一步。

指南中的简化示例是一项迁移：说明哪些端点需要迁移、哪些测试必须通过，以及代理何时应当求助。有用的结构包括目标、可验证的完成定义，以及代理无法解决问题时的停止条件。

我也不喜欢添加笼统的“更努力思考”指令。我认为模型本来就会推理，并能调整投入。我把不同档位解释为推理上限、把 max 解释为施加更高下限，这只是我对表现的理解，并非经过验证的内部机制。

在我的 Skate Bench 测试中，x-high 平均每次回答使用 338 个 token、耗时约六秒；max 平均约 5000 个 token、50 秒。画面中的分数从 78% 升至 79%；我估计 max 的费用约为 13 倍。这些结果仅针对该基准和此次运行。

我承认，更高推理投入可能有助于某些困难或容易误导的问题，但我个人会避开 max，通常选择 high 或 x-high。我觉得 x-high 稍慢，有时会更注意细节。其他任务的权衡可能不同，应进行测量，而不是把我的偏好当成规则。

长时间任务重新开始的代价很高。如果代理工作时我发现遗漏的要求或方向错误，可以发送后续消息进行引导。目的是补充上下文，同时保留原任务；仍值得检查代理是否记住了全部要求。

我说，旧模型有时会在接收引导后只完成最新要求，忘记其余内容。新模型在把插入的消息融入持续任务方面，给我的感觉更好。这是我的使用体验，不能据此证明其具体训练方法。

设计工作方面，我在 Which AI 展示站上觉得 Fable 的默认示例更好看，而 Opus 对具体方向的响应较好。笼统地要求“不要千篇一律”，可能只是换来另一种默认风格。这些评价很主观，不能建立普遍的设计排名。

指南建议明确列出要避免的模式，例如特定背景、标题处理方式或按钮形状，然后检查结果并继续迭代。我常常在截图上画箭头，要求改进相关区域，以便为模型提供视觉上下文。

对于长任务，要告诉代理希望在哪些地方停止。指南给出的 CLAUDE.md 示例是：不需要输入时继续工作；真正被决策阻塞时，或在删除数据、强制推送等破坏性操作之前停下。应按项目和实际审批要求调整这条规则。

我在自己的配置里加入了类似规则。指南也承认，协作或结对编程可能需要更频繁的交流。合适的自主程度取决于任务、用户意愿和操作后果。

对于大型审计、迁移或审查，将工作拆给子代理可以帮助它们在独立上下文中探索不同区域。我发现明确说明是否允许或希望委派很有用；代理不一定会自行启动子代理，而并行工作仍需协调。

长任务结束后，先查看尚未解决的决定或审批请求，再读改了什么、发现了什么。指南建议采用一致的总结格式。我经常询问旧任务的当前状态，以及它需要我做什么。

我最常问的问题之一是：今天合并这项变更有什么风险？我会询问最坏的合理后果，以及审查者检查了什么。回答有助于我决定关注哪里，但模型的信心不能替代证据或适当的人工审查。

我也喜欢让不同模型家族审查实现。以我的经验，OpenAI 模型能深入细节，有时会发现 Claude 遗漏的问题，但也可能报告更多价值不高的发现。在我自己的比较中，Opus 5.5 的审查能力也有所提高。

我的小型 T3 Code 评估让模型寻找改进点，并由评审组评价这些发现。画面中的结果显示，Astra 和 Grok 4.7 各有八项得到支持的发现；Opus 5.5 有五项，Opus 5 有四项得到支持、两项未解决。这些是我的测试设置下的结果，并非适用于所有仓库的独立排名。

要让代理区分已确认的发现和无法验证的事项。适当时，为它提供相关测试、可运行环境或浏览器访问权限；同时让它报告缺失的凭据、硬件、主观判断或其他障碍。检查通过也不能证明所有行为都正确。

指南还介绍了消息被安全防护标记后的情况：应用可能根据设置切换模型或暂停。我最近遇到的标记较少。这类行为和设置可能变化，出现标记本身也不能证明一个合理请求不安全。

指南提醒不要要求查看隐藏的推理轨迹。如果想理解一项变更，可以询问其理由、证据和局限。我也建议附上相关截图或图表：一张展示错误的图片可以为代理提供原本需要很多文字才能描述的上下文。

我的实用清单是：定义完成状态，提供验证所需工具和上下文，明确代理何时应当停下，并检查结果。信任可以让代理走得更远，但应配合适合任务的检查和边界。