@newaccount 人总是自我趋向于自我解释和修正。需求完成不了 => 怀疑自己 => 看到社区说模型不行/降智 => 怀疑模型。反正不能是自己的问题。

太真实了，现在天天都有人发各种模型降智水帖，说到底还是自己的流程不对，或者说一直都是许愿式开发，只要发现和之前预期不一样，或者稍微说点胡话，就开始发帖吐槽。但实际情况是，会用的人不会发帖夸他完成的好，能看到的帖子全是降智帖。
降智可能确实会影响一些，就像 JDK 版本，新版 SDK 在某些场景可能会有更好的体验，但确实很少很少一部分。正常的开发流程熟悉和掌握之后，这些偏差很容易就修正了。对于完成工作来说，没有任何实质影响。

你指的监控是投票制？那还有啥可信度？

https://i.imgur.com/wtd9TwW.png

不是，我一字长蛇阵都能拿下？

不行啊这个 jev ，17 手拿下 Jev 大师
https://i.imgur.com/dp3nCUf.png

不过无法使用自动审批了。
https://i.imgur.com/1Yt7Nfq.png

@lscho 信息密度太大 +1 ，现在是真看不了这种博客。我感觉我的博客（ https://blog.1874.cool/）还挺简洁的，不过博客站点更多是服务自己，记录自己的实践经验，如果持续坚持写下去，其实外观倒没那么重要。

目前 Sol 和 Terra 是 V2 的 SubAgent 协议，Luna 还是 V1 版本的，具体体现为：使用 Sol 或者 Terra 时，通过提示词是无法分配 Luna 的子 Agent 去干活的

https://github.com/openai/codex/blob/main/codex-rs/models-manager/models.json#L447

具体可以看这份文件，当 Luna 的 multi_agent_version = v2 时，就能在使用 GPT5.6 时随意指定其他 GPT5.6 模型了

@Wanex 你这话就不太对了，Fast 根据楼上哥们算下来可能有 5 倍左右的消耗，这个 Fast 即使对比到国内相同消费水平的模型，月卡订阅用户如果也能开 5 倍消耗，也用不起吧。

如果不开 Fast 吐槽下是能接受的，开 Fast 吐槽就说不过去了，我 Pro 5x 都不经常开 Fast ，没意义，又不赶时间。

我是觉得 为什么 OpenAI 不把 Plus 的 Fast 权限收回，否则这个 Plus 额度根本就用不起 Fast 。

@Pernalin 谢谢指正，具体我没试过到底多少倍，但我很少开，只有之前明确重置前实在用不完开过。如果是这样的消耗，那 UP 这个消耗也确实正常，如果不用 Fast 可能能多 5 轮对话哈哈哈

@BuffDog #32 你都自己说了懒，懒值得被忽略吗？懒就是你现在问题的核心原因。

至于你说的切换上下文的消耗，直接暴露了你用 AI 还不熟练。中途切换模型最应该考虑的是「模型降智」的问题。从高切低，会导致低模型处理相同任务能力明显不如高模型。从低切高，也会存在低模型的上下文可能会误导高模型的判断。更好的做法是高模型做规划，低模型做机械执行。

至于上下文消耗，你都开 Fast 2.5 倍消耗了，还在意这点上下文消耗？你这前后还是矛盾啊

@BuffDog #24 我感觉这两种都能接受，就像我前面说的，VibeCoding 时代，人的代码时间是被大量解放的，我对模型的处理时间要求没那么严格，我更喜欢多线程处理独立任务，时间不作为我的考量标准。

至于 80%还是 90%，这个我无法去实际评测，只要是能满足我需求的模型就是好模型。

如果我用低模型能解决，我就认为是 100%。况且一个问题的解决如果只想一次对话就解决的话，那就是我所说的许愿式开发，我认为现阶段 AI 做不到，即使用低模型多几轮对话也能解决问题，我也会认为它是合格的，我个人的期望值没有那么高。

@BuffDog #20 强推理模型是这样的，考虑的很多，边界问题处理的很多。如果是想简单处理，要么提示词要求一下，要么换低一级的模型。

@BuffDog #19 降智是另一个问题，尽量避免 许愿式开发 是解决降智的最佳手段，最后还是做好规划再行动。

@Nzelites #17 我觉得不该开 Fast 的权限，这玩意是真耗，感觉远不止 1.5 倍。

Sol 偶尔用用其实还行，但从他这个打包处理时间来看，我感觉他这个不像是正常的打包逻辑，一般意义的打包，就是运行一个打包命令等待输出了，不至于处理 17 分钟，应该有其他逻辑在里面。

我感觉这里面的罪魁祸首是 Fast 模式。

@BuffDog 懒得切的话，那你其实适合 Pro 5x 甚至 20X ，如果按你的使用习惯，一般的 GLM5.3 可能都不够用。Plus 的定位不适合这么铺张浪费。

我感觉现在 AI 的其中一个痛点就是：无法根据任务的复杂度，智能选择不同的模型来处理问题，目前只能人手动识别。

但目前不管是 AI 算力还是成本永远都是有限的，无法做到用一个模型就能平衡成本、速度、最优解决问题。

很多人处于一个强度焦虑：担心用低级模型无法解决这个问题。所以就导致一个普遍现象：无论任何问题都尽量使用最新最强最快模型来解决这个问题，但这样的使用成本就水涨船高了。

目前识别任务的复杂度，选用更合适的模型，更多还是还是靠人工识别，但我希望未来 AI 会朝这个方向发展吧。

--------------------------------------
当然，目前人工识别其实也有非常多优化路径：我见到的最多的方案，就是用更强的模型写好架构、规划和执行方案，用低一级的模型机械执行。打包这个动作就适合用低一级的模型去解决。

不过最后还是提一句：Fast 模式我是感觉不适合常驻使用的，除非真的赶时间或者马上重置了故意消耗额度，Fast 的消耗远不止 1.5 倍消耗，还是尽量少用。

Vibe Coding 时代，人的代码时间已经被大量解放了，我本人是宁愿选择 多线程 去处理更多独立任务，而不是单独要求当前任务尽快处理完成。

@luckycoding 想问下 codex voice 我好像无法在项目中使用，好像只能在全局临时聊天中使用吗？