
在 AI 辅助编程里,很多人其实都在做同一件事:在不同模型之间来回切换。Claude Opus 更擅长推理,Gemini 在前端生成上很猛,GPT 系列在架构和整体把控上更稳。问题是,工具层面大多还是单模型工作流,Cursor 或 Windsurf 这类产品也不例外。你只能接受一个模型的长处,同时吞下它的短板。
Oh My Open Code(OMOC)想改的就是这个局面。它不是把 OpenCode CLI 再包一层皮,而是直接把它改造成一个多模型协作的编排系统。思路有点像 Oh My Zsh 之于终端:核心能力没变,但默认体验和可扩展性被彻底拉高了。
从'一个全能模型'换成'分工明确的小团队'
这个项目最有意思的地方,不是它用了多少模型,而是它承认一件事:没有哪个模型适合把所有活都干完。
Gemini 3 Pro 适合做前端,但碰到复杂后端逻辑时,偶尔会飘;Claude Opus 4.5 推理和调试很强,但拿它去反复翻文档,成本会很难看;GPT 5.2 在架构判断上通常比较稳,可在代码风格上又会有自己的坚持。手工在这些模型之间搬运上下文,效率不差,体验很差。
OMOC 的做法是引入一个编排器(Orchestrator),让主控智能体负责分发任务,而不是自己把所有代码都写完。
Sisyphus:更像工程经理,不是码农
在 OMOC 里,主控智能体叫 Sisyphus(西西弗斯),通常由 Claude Opus 4.5 驱动。它的职责不再是逐行写代码,而是先判断任务类型,再把活拆给合适的模型。
这个分工挺实际。前端改动交给更擅长界面生成的模型,后端逻辑交给更强的推理模型,架构规划和任务拆解则由主控来把关。这样做的好处很直接:模型不必样样精通,系统整体反而更稳定。
我更愿意把它理解成一套'路由规则 + 协作协议',而不是传统意义上的 AI 编程助手。真正省心的地方,不在于它替你写了多少代码,而在于它少让你做那种低价值的中转工作。
这套东西怎么落地
OMOC 的价值主要体现在两层。
一层是任务编排。它把'谁来想、谁来写、谁来修'拆开,让不同模型做自己更顺手的部分。另一层是工作流稳定性。单模型方案一旦卡住,通常只能硬等它自己绕出来;多模型协作至少给了系统一个换手的机会。
当然,这也不是没有代价。协作层一复杂,配置和调试就会更费劲,特别是你要同时关心模型能力、上下文传递和任务边界的时候。它更像一个适合重度使用者的方案,不是开箱即用的轻量工具。
如果你已经习惯在多个模型之间来回切换,OMOC 会让这件事变得更体系化;如果你只是想要一个能补全代码的 IDE,它可能有点重。


