在日常的开发与创作中，我主要同时搭配 Codex（搭载 GPT-5.6）、Kimi 和 Grok 这三款模型。它们在能力长项、响应速度和计费成本上各不相同，经过一段时间的实际摸索，我形成了一套分工协作的工作流。

Codex 与 GPT-5.6：日常最高频的主线 Agent

最近这段时间我使用频率最高的依然是 Codex。

Codex 本身的客户端工程做得很扎实，界面简洁，整体运行非常流畅。哪怕是在一个包含了大量交互的超长会话中，或者左侧列表堆积了许多对话记录，它依然能保持其他 AI Agent 很难企及的响应流畅度。

而且 Codex 一直保持着克制的产品设计。尽管经过了多次版本迭代，主界面依然非常清爽，产品思路很像苹果：可以为 Agent 包装丰富的能力，但绝不激进地把所有入口全部堆砌在主界面上。

很多功能被设计得很隐蔽。比如在新建话题时可以通过输入「@」直接继承之前的上下文；或者当单次生成多张图片时，界面会出现一个「Canvas」按钮，点击就能打开类似之前 Manus 那样的画布视图。如果我们平时没有一次性生成多张图片，可能根本不会注意到这个功能。如果把这些入口全部陈列在左侧边栏，整个客户端就会显得非常臃肿。

我一直很认同一种设计理念：系统想传达的内容越多，用户真正能够接收的往往越少。把最核心的重点清晰呈现出来，把高阶能力留给用户在使用中按需发现，反而能提供很好的掌控感。

加上 Codex 搭载的 GPT-5.6 综合逻辑能力很强，这个 Agent 客户端与模型的组合，就成了我日常最核心的主力。不过 GPT-5.6 虽然稳健，与另外两款模型相比，依然有着很明显的短板。

Kimi：目前最强的前端设计能力

Kimi 刚推出高阶版本的时候，我为了体验大参数量国产模型的真实水平，先订阅了一个 99 元的套餐。当时我做了一个简单的测试，让它生成单文件 HTML 网页，很快发现这个模型的原生审美与前端设计能力非常突出。

后来 Design Arena 的设计榜单公布，Kimi K3 确实排在第一名，这与我实际测试下来的直观感受完全吻合。

最近我上线的两个新项目——我的个人主页以及 VibeHub，它们整体的设计框架和视觉基调都是让 Kimi 搭建的。它的原生创造力很强。比如想要设计一个新页面时，可以让 Kimi 先直接出三版不同风格的单文件 HTML，我们再从中选定一个主基调，或者提取出设计规范。它生成的这三版设计，在排版细节和质感上明显优于其他模型。

在我看来，Kimi 搭配官方的 Kimi Code，是目前综合表现最优秀的前端设计组合，视觉把控甚至超过了 Fable 5。在处理一些复杂的全栈编程任务时，它的稳定感也很足，综合水准与 GPT-5.6 Sol 基本相当。

但 Kimi 也有两个很现实的限制：一是输出速度偏慢，有时 TPS 只有 20 到 30；二是使用成本相对较高，计费水平已经快要接近海外一线大模型。不过因为这项设计能力确实稀缺且难以替代，在做前期的设计探索与界面构思时，我依然会优先选用它。

Grok 4.5：速度极快的中端甜点模型

另一款重要的补充模型是 Grok。

Codex 搭配 GPT-5.6 Sol 时，偶尔会让人感到困扰的一点是速度偏慢，而且上下文窗口存在实际限制。模型本身理论上支持 100 万 tokens，但在客户端日常使用中，有效窗口通常在 20 多万 tokens。

GPT-5.6 Sol 本身极其严谨，喜欢在动笔前读取大量文件。如果我们把思考深度设为 Extra High，它会先大范围扫描工作区以确定方向，然后再深入精读具体文件。经常出现的情况是：等它读得差不多、准备开始动手修改代码时，刚好触发了上下文压缩。

一旦触发压缩，模型只能保留一份摘要，之前的细节丢失后，它又不得不重新回磁盘读取具体的代码文件。这就把一个本该快速完成的简单修改拉长到了几十分钟。如果再遇到算力紧张，即使开启 Fast 模式，耗时也会大幅增加。

而 Grok 从 4.5 版本开始，已经达到了非常实用的工程水准。在我看来，它很像一个速度强化版的 Claude Sonnet 级中端甜点模型。它最大的优势就是响应极快，TPS 能稳定在 90 到 100。

当我们下发明确具体的任务时，Grok 不会有过度防御的心理负担。比如后端接口的细微改动、前端 CSS 样式的微调，或者在不改动业务逻辑的前提下重构页面代码结构，这类目标单一明确的活，它执行起来非常敏捷。而且实际测试下来，它的前端审美相当在线，微调样式时通常不会破坏原有的设计规范。

三个模型共同的短板：文案表达

在这个多模型组合里，它们目前都有一个共同的不足：文本表达能力都不算理想。

GPT 写的文案语言结构偏晦涩，不仅仅是常见的 AI 腔调，有时句子还会缺少关键主语，单个词语虽然通顺，连成整段后却很难流畅阅读。

Kimi 则是非常典型的模板化 AI 味。句式结构完整规范，也能让人读懂，但一眼看过去就能辨认出机器生成的痕迹，不适合直接作为对外发布的内容。

Grok 的文案风格更接近早期的 ChatGPT 翻译腔，语气机械，词语搭配偶尔显得生硬。

因此，目前处理正式文案时我依然需要人工重写或寻找其他方案。虽然 Claude Opus 4.6 的文字润色能力很强，但通过 API 调用的价格过高，性价比有限。

在 Codex 中把 Kimi 与 Grok 作为子 Agent 调用

在工具链层面，我通常搭配它们各自的第一方工具使用：Kimi 配合 Kimi Code，Grok 配合 Grok Build。第一方客户端往往最契合对应模型的特性。

但 Kimi Code 和 Grok Build 本质上都是命令行工具，在终端黑底白字的窗口里操作，体验和交互没有桌面版 Codex 直观。

为了把三者融合起来，我在 Codex 里开发了两个开源 Skill：kimi 用于对接 Kimi Code，grok 用于对接 Grok Build。

它们的底层机制很轻量：由 Codex 在后台拉起本地命令行，启动对应的 Agent CLI 并派发具体任务；子 Agent 执行完成后把结果写入本地临时文件，再由 Codex 读取并返回给主会话。

这样一来，Kimi Code 和 Grok Build 就成了 Codex 里的专业子 Agent。在日常开发中，我不需要在不同的终端窗口之间来回切换，绝大部分时间只要在 Codex 的主窗口里对话，由 Codex 自动把前端设计或快速代码重构的任务派发给对应的子模型执行。

使用 Agent Island 监控多模型额度

在多模型高频切换的情况下，监控各个模型的用量就变得非常重要。我目前在 Mac 顶部菜单栏使用的是开源工具 Agent Island。

安装 Agent Island 之后，它能自动读取各个订阅套餐的额度消耗，直接呈现在菜单栏中。它的界面清爽，还提供了一套热力图来展示不同模型的额度消耗走势，支持设置用量预警。

因为 Grok 的订阅额度不算充裕，我需要时刻注意它的 5 小时限额和周限额状态，避免任务执行到一半因配额耗尽而中断。目前 Agent Island 原生还不支持国产模型，无法直接抓取 Kimi 的剩余配额；不过我已经向该项目提交了支持 Kimi 订阅的 PR，后续合并后就可以在顶部栏统一监控国产与海外模型的额度了。