我最近出于兴趣在开发一个通用 AI Agent。有一天我想把它的 UI 调整成更有拟物感的风格，第二天完成了第一版。Gemini 负责设计意向和 HTML 设计稿，Codex 负责把确定的方向实现到系统里。
优化之后的 Agent 界面
底部的输入框做成了类似打印纸的效果，把消息粘贴进去发送之后，Agent 会开始思考，过程和 Codex、Claude Code 这类产品类似。
界面里有几个我自己比较喜欢的设计：
- 左侧是多 Agent 的切换；
- 顶部是类似 Cursor 的多标签，用来切换多个话题；
- 输入框附近可以查看当天消耗了多少上下文；
- Agent 的头像是一枚小油滴，形状和颜色都可以调整。
自己做一个 Agent 的好处是，我可以方便地配置自己喜欢的模型，比如 DeepSeek、MiniMax，配了就能用。对 Agent 的交互有新想法时，也可以马上集成进自己的产品里。
任务完成后，界面里会出现一个产物交付的小卡片，点击就能直接预览生成的文件。下图就是 DeepSeek 参考我给它的 Markdown 生成的一个 HTML 文件。
设计文档是怎么得到的
这套 UI 不是 Codex 直接设计的。GPT 的设计能力没有那么强，我在之前的视频里也分享过，目前设计能力最强的模型是 Gemini 3.1 Pro，给它很少的提示词，它就能做出比较好的 UI 设计。所以我的流程是：Gemini 负责出设计，Codex 负责实现。
具体分成三步。
第一步是设计意向。我先跟 Codex 讨论想要的意向，Codex 会通过一个 Skill 调用 Gemini，让 Gemini 自己写提示词并返回一份文字版的设计意向。这次它给出的方向是「精密印字实验室」：纸张、墨迹、金油（后来就变成了左侧的小油滴）、机械键，还有类似打字机的复古字体排版。它会把系统里的每个资源映射成一种实体物质，这样后续无论换什么模型来实现，大方向上都有参考，不会偏得太远。
第二步是 HTML 设计稿。让 Gemini 参考这份意向，做一版 HTML 的模拟 UI 设计稿。第一版生成出来后，左侧已经有了类似 Agent 切换的结构。一次性生成的 HTML 总会有些乱，这个阶段只看整体风格是不是自己喜欢的。
如果大方向没问题，可以把这版 HTML 留下来，再让 Gemini 基于它做一次优化。下面这张是第二次优化之后的效果，到这一版我自己已经比较满意了。
第三步是设计规范。基于确定的 HTML 设计稿，让 Codex 把它对应到系统内的资源，写成一份设计规范。这一步不用给太多提示词，只要告诉 Codex 去做设计规范，让它充分读一遍系统里现有的代码模块，把配色、字体这些提取出来。有遗漏的地方再不断让它往规范里补充，这不是一步到位的过程。真实实现和设计稿之间一定会有差异，会遇到各种复杂情况，所以我的实现也没有一比一复刻，会有一些微调。
在 Codex 里调用 Gemini
在 Codex 里调用 Gemini，用的是我自己写的一个 Skill。打开 Codex 的侧边栏，点击 Plugins，搜索 Gemini Designer 就能看到。
这个 Skill 主要做两件事：
- 调用 Gemini 写设计意向、设计规范这类 Markdown 文件；
- 让 Gemini 生成 HTML 设计稿。
它需要对接一个外部的 API 服务，我用的是 ZenMux，大家想用 Gemini 官方或者任何其他平台都可以。Skill 在我的 GitHub 上也有：oil-oil/gemini-designer，把这个链接复制给 Codex，让它安装就可以了。安装完成后还需要配置一个第三方 API 的 Key。（这个仓库后来我改名为 grok-designer，换成了 Grok 模型，旧链接会自动跳转，安装方式是一样的。）
讲不清楚的效果，让 Gemini 描述给 Codex
即使有了设计规范，让 Codex 复现设计仍然很艰难。比如底部输入框的效果我就磨了很久：GPT 本身的设计技巧不够，不管是让它直接写 HTML，还是让它把实现路径用文字描述出来，它都做不到。
我的解决办法是单次使用 Gemini。打开 AI Studio，在这里使用 Gemini 是免费的。模型一定要选择 Gemini 3.1 Pro Preview，Gemini 3 Flash Preview 的设计能力是不如 3.1 Pro 的。
遇到一个讲不清楚的效果，比如「卡片插在一个凹槽里面」，我就在 AI Studio 里问 Gemini：想要营造卡片插在下方输入框里的感觉，要怎么跟 AI Agent 描述。它会返回非常详细的说明，包括用 CSS 实现这种效果的具体思路。口头描述讲不清楚、Codex 自己也想不到的时候，我就把这段文案复制给 Codex，让它照着改代码，效果就做出来了。
如果没有外部的 Gemini API，也可以麻烦一点：不让 Codex 直接调用 Gemini，自己在 AI Studio 里写提示词，让它生成 HTML 设计稿，再把设计稿复制到项目里保存成 HTML 文件，交给 Codex 参考，同样可行。
几个心得
做 UI 没有非常优雅、非常快的方式，总是需要磨。几个模型在设计这件事上的分工，我的经验是：
- GPT 的设计能力不强，设计方面的指令遵循性也没有那么好；
- 用 Claude 做前端的效果会比 GPT 好一些；
- Gemini 不适合驱动 Agent，上下文一长它就会做得很乱。它只适合出单次的 HTML 稿子，或者做大方向上的意向设计。不要让 Gemini 直接改代码，让它出稿子、其他 Agent 参考着实现，效果更好。
把 Gemini 配置进 Codex 还有一个好处：可以很方便地让它参考已有的 HTML 文件。单次调用虽然不是 Agent，但可以给它很长的上下文，比如把之前整个 HTML 全部交给它，让它参考这个文件出局部的设计。Agent 本身也是把大量上下文放进去、再无状态地响应一个新答案，只要 Skill 设计得足够好，就能方便地带上外部的设计文件。
想让 Gemini 做出好看的 UI 设计，主要有两点。第一，不要让 AI 写太长的提示词给 Gemini。想让它发挥最大程度的创意，就要尽量少给提示词，只给大方向上的参考，不限制它的发挥，它在质感上做得是很好的。第二，可以给它反向提示词。比如我做这个 Agent 时，聊到 Agent 它就容易做得很科技感、很现代，我会强调想要略微复古的质感；另外只要涉及 AI 调用，它就会很死板地使用各种新兴的、有科技感的图标和意象，把这些写进反向提示词里，能很好地规范它的方向。它的上限比较高，能把底子打好，之后让其他 AI Agent 去实现，效果就会很好。
设计过程中，我不会一直直接修改系统代码，而是先制作 HTML 预览稿。有工程师分享过 HTML 比 Markdown 更易读，因为设计过程里的很多内容需要由人直接查看。让 AI 直接修改系统设计会混入更多因素：调整样式可能影响业务代码，它也可能为了一个样式读取大量业务模块。先编写 HTML，方便我预览，也让 AI 只处理当前的设计问题。
我项目里已经积累了很多 HTML 设计稿，有些是 Codex 写的，有些是 Gemini 写的，都是为了在真正实现到系统里之前确定大方向。有了 HTML 设计稿之后，让 Codex 像素级还原的难度会大大降低：各种样式和属性已经在代码里写明了，它照抄就可以，这对它来说是比较简单的。