一次跨模块重构前的模型选择笔记

一个修改横跨权限校验、数据缓存和后台任务时，困难往往不在代码量，而在这些部分是否遵守同一组约束。此时值得考察 Claude Opus 5.5；如果只是补充字段校验，选择更重的推理路径未必有收益。下面以 Claude Sonnet 5.5 为参照，比较不同任务该怎样分配。这里没有实测排名，也不预设某个模型必然更准确。

§ 先区分任务长短与决策深度

长文件不一定需要深推理，短问题也可能藏着复杂依赖。更有用的判断是：需要同时维护多少约束，错误是否容易发现，以及决定能否撤回。

• Claude Opus 5.5：适合优先纳入高约束任务的候选，例如梳理隐含前提、比较迁移方案、解释跨模块影响。是否值得使用，仍要看它能否找到可验证的遗漏。
• Claude Sonnet 5.5：可作为边界清楚任务的对照，例如局部修复、按既定规范补测试。若验收结果相同，就没有必要仅因任务重要而升级。

§ 跨模块重构：先比较计划，再比较补丁

假设要把权限判断从控制器移到服务层，同时保留旧接口行为。给两个模型相同的代码、调用关系和兼容要求，先要求列出必须保持的不变量，不要立即修改。

• Opus 的观察点：是否识别后台任务绕过控制器的路径、缓存中的权限状态，以及失败后的回滚边界。更长的说明本身不算优势。
• Sonnet 的观察点：是否已经覆盖这些约束，并给出足够小、容易审查的改动。如果两份计划等价，应继续比较实际耗时与费用，而不是文风。

深度真正付费的地方，是少一次遗漏造成的返工，而不是多生成几页设计说明。

§ 故障排查：比较证据链，而非结论语气

面对偶发超时，把日志、时间线、最近变更和已排除因素一起提供，并要求区分事实、假设与待验证项。

• Opus 的观察点：能否把多个表象串成可检验的解释，并提出能够区分竞争假设的下一步检查。无法验证的复杂故事不应获得更高评价。
• Sonnet 的观察点：能否用较短路径定位明显问题。如果一条错误配置已经足以解释现象，继续展开推演可能只会延迟修复。

两个模型都不应因表达笃定而被直接采信。生产操作仍需权限控制、人工确认和回滚准备。

§ 日常修改：让验收标准决定是否升级

对于格式调整、明确的类型修复和已有范式下的测试补充，可以先让 Sonnet 执行，再用编译器、测试和人工审查验收。只有出现反复失败、约束冲突或解释不一致时，再考虑交给 Opus。

升级时应附上失败记录与尚未解决的问题，而不是原样重发提示。否则，更换模型也可能只是重复同一轮探索。反过来，如果任务涉及不可逆的数据迁移，即使补丁很小，也值得先做更充分的方案审查。

§ 把比较放进同一条调用链

通过 Vana API，可以在同一接入环境中切换这两个模型，减少更换客户端带来的变量。其统一入口为 https://api.vanaapi.com，兼容 OpenAI 接口，也支持 Anthropic Messages 和 Gemini 原生协议，可配合 Claude Code 或 OpenAI SDK 使用。

比较时仍需核对各模型支持的参数与功能，固定代码版本、上下文、工具权限和输出要求。先用默认配置比较实际可用性，再在双方支持的范围内调整推理相关设置；不要假定同名参数代表相同的计算投入。

§ 用总任务成本判断深度是否划算

Vana API 按实际令牌计费，无月费。具体价格应以调用时的信息为准，也不能仅凭模型名称推断延迟。可以创建一个 Vana API 账户，从几项有明确验收标准的真实任务开始记录。

• 质量：测试通过之外，是否遗漏约束，是否引入新的维护负担。
• 时间：同时记录响应等待、人工审查和返工时间。
• 费用：累计所有重试与复核调用，而非只看第一次请求。

如果 Opus 能稳定减少关键遗漏，或明显缩短人工收尾时间，它的深度才转化成了收益。如果 Sonnet 已能可靠完成验收，就把额外预算留给真正存在不确定性的环节。模型选择应跟随任务证据，而不是固定的等级顺序。