从前端失控到先理解再动手

我第一次明确把前端从 Codex 主线里拆出来，是因为项目页面开始失控。

Codex 在后端、数据结构、命令执行和严谨收口上很强。可一到前端视觉，它经常会做出很奇怪的东西。不是单纯配色不好，而是页面会出现像演示稿一样的说明文字，信息层级也容易变得像临时汇报页。

这种问题在正式项目里很刺眼。项目页面要服务真实使用，而不是像 AI 在解释自己做了什么。

第一次拆分

最早的办法是让 Gemini 或 Antigravity 来处理前端方向。

这一步确实有用。Gemini 对视觉气质、页面结构和前端表达更敏感，能帮我摆脱 Codex 那种过度说明的页面风格。但直接让 Gemini 动手也会有问题。它有时没有完整理解项目代码，容易漏改、误改，或者改到一半报错。

所以问题不只是“哪个模型前端更强”。更准确地说，是 Gemini 动手前需要先理解项目上下文。

先理解，再动手

后来我把流程改成 Codex 主导。

Codex 先整理相关代码、业务目标、页面边界和不能改的部分，再把这些上下文交给 Gemini。Gemini 先复述理解或给出方向，确认没有跑偏以后，再进入前端方案或具体修改。最后仍由 Codex 检查 diff、运行构建和收口。

这个变化很大。之前是我在两个工具之间传话。后来变成 Codex 可以通过 Gemini CLI 维持持续会话，直接把上下文喂进去，再把结果带回当前项目。

现在留下的原则

这段经历最后留下来的不是某个固定工具，而是一条原则：前端不是让另一个模型随便重写，而是让更适合前端的模型在足够上下文下工作。

Codex 负责工程边界和验证。Gemini 或 Antigravity 负责视觉方向和页面气质。Claude Code 可以作为审查和对照视角，但不强行作为主入口。

对我来说，这就是跨模型协作从临时求助变成工作流的开始。