折腾笔记：解决 Codex 模型降智，我魔改了一个 CC Switch 版本

最近在折腾 LLM（大语言模型）的路由和代理工具时，遇到了一个比较头疼的问题：Codex 模型变“笨”了。

简单来说，就是当我使用 CC Switch 这款强大的路由工具来分配请求时，原本聪明的 Codex 模型开始出现“降智”现象。回答质量断崖式下跌，推理能力直线下降，简直像是喝了假酒。

问题出在哪？

经过一番排查，发现社区里有一个叫 CodexCont 的项目专门解决这个问题。原理大概是针对 Codex 模型的 reasoning（推理）特性进行某种“续写”或特殊处理，保持其连贯性。

尴尬的事情来了： 我既想用 CC Switch 做路由分发，又想用 CodexCont 来保智商。但这俩家伙在一起打架，同时开启的情况下，CodexCont 没法正常工作。这就好比你戴了两副眼镜，反而看不清路了。

魔改思路：既然打架，那就合体

既然两个工具同时在运行会冲突，最直接的办法就是把它们变成一个。

我基于 CC Switch v3.16.5 的源码进行了魔改，把 CodexCont 中解决降智的核心逻辑直接内置到了 CC Switch 的内部。这样，CC Switch 在处理 Codex 请求时，就能自动应用增强逻辑，无需再依赖外部脚本来“续写”或干预。

经过测试，这个“缝合怪”版本效果不错，既保留了 CC Switch 灵活的路由能力，又完美解决了 Codex 变傻的问题，推理能力恢复正常。

关于开源发布的小建议

很多小伙伴在开发完好用的工具后，在分享这件事上比较犹豫，担心会被判定为“推广”。其实，只要你是纯技术分享，流程非常简单。

针对这类工具类的开源项目，如果想在社区发布，建议如下操作：

1. 合规发布： 在发布时附带明显的开源推广标签，并使用社区规定的发布模板。
2. 完善文档： 这是一个好习惯。在你的 GitHub 项目 README 中，清晰介绍你的魔改思路和功能点。
3. 双向引流： 在 README 中挂上项目的讨论链接（比如你最早发帖讨论问题的那个帖子），这样不仅能证明项目的活跃度，也能让遇到同样问题的人找到归宿。

写在最后

技术圈的发展往往就是建立在这种“发现问题 -> 分析冲突 -> 魔改优化 -> 开源共享”的循环之上的。Codex 本身是个强大的模型，有了好的路由和增强逻辑，才能在实际应用中发挥最大效力。

如果你也受困于模型的各种“小脾气”，不妨试试深入研究一下工具底层，有时候自己动手改一行代码，比找十篇教程都有用。