OpenAI Sol 实测：字幕翻译工作流下的消耗与效率分析

最近趁着有时间，我拿自己的 Plus 账号好好测了一下 OpenAI 新发布的 Sol 模型，主要跑的是我平时常用的字幕翻译工作流。这里不聊虚的，直接说说实际使用中的消耗情况和体验感受，给想尝鲜的朋友做个参考。

Sol 模型测试截图

🧪 测试环境与工作流设定

首先说一下我的测试配置：使用的是推理强度设定为 Medium，没有开启 Fast 模式。

我跑的这个工作流其实就是一个比较复杂的 Skill 流程，主要包含以下几个步骤：

1. 前期准备：主代理派发子代理去联网搜索相关的热词和信息，把总结带回给主代理作为背景知识。
2. 规范化处理：主代理利用脚本对原始 STT 转录出来的 SRT 字幕进行第一轮规范化处理。
3. 分段翻译：将过长的字幕拆分，分发给多个子代理并行翻译。
4. 拼接与二次规范：主代理负责把翻译好的片段拼接起来，再用脚本进行一次规范化。
5. 最终审查：最后还有一个专门的审查子代理进行评估和修复，提交最终的翻译文件。

这个流程对模型的逻辑理解能力和指令执行能力要求都比较高，尤其是涉及到脚本处理和多轮交互。

Sol 的消耗速度示意

💸 消耗速度翻倍的体感

这是我这次测试最直观的感受——Sol 真的很吃额度。

在之前使用模型（比如 5.5 Medium）跑这套同样的工作流时，完成整个任务大概只消耗 30%~40% 的 5 小时额度。但是换成 5.6 Sol，同样 Medium 强度跑下来，直接干掉了 65% 的额度。

从体感上来说，Sol 的消耗速度几乎是以前的两倍。如果你也是重度工作流用户，或者是那种喜欢长时间挂机跑复杂任务的，这点一定要注意，别看着进度条没动多少，额度却已经见底了。

🐍 代码能力的提升与显示缺陷

虽然吃额度，但 Sol 的效果确实也没得黑，特别是在代码处理逻辑上。

在跑这个工作流的中间环节（规范化那一步），以前测试很多模型时，它们经常会犯傻。有的模型喜欢直接重写内容，聪明一点的模型会选择先复制一份再编辑。不管哪种方式，它们都需要在那“折腾”一会，效率不仅低，有时候还会破坏格式。

而 Sol 在这方面表现得非常“硬核”。在处理这些规范化任务时，它基本上都是直接调用 Python 脚本来处理数据，逻辑非常清晰，直接修改数据结构而不是在那做文本操作。这说明它在理解“工具使用”上确实比以前的模型聪明了不少。

不过目前也有个小问题：Codex CLI 对子代理的显示支持不太好，导致我在观察子代理执行 Python 代码的过程时，体验有点割裂。后续我可能会把这个环节迁移到 Pi 上去跑，看看可视化和监控效果会不会更好。

📝 总结与建议

总的来说，Sol 给我的感觉是一个“高耗能 but 高智商”的模型。

• 优点：逻辑推理强，代码执行路径更优，能直接上手写脚本处理数据，减少无效的文本瞎折腾。
• 缺点：Token 消耗速度显著增加，成本几乎是双倍。

如果你的工作流对逻辑准确性要求极高，且不差那点额度，Sol 确实能省不少心；但如果只是简单任务或者对成本敏感，建议还是得精打细算着用。