做了一个真实项目后，我现在基本固定用 Codex 写后端，Gemini 处理 UI
- 内容介绍
- 文章标签
- 相关推荐
最近拿 AI coding 真做了一个项目/功能，算是把自己的一套工作流试出来一点了。
先说结论：
我现在基本不太纠结“Codex 和 Gemini 谁更强”了，直接按分工用。
Codex主要写后端Gemini主要看 UI
这样跑下来，比我一开始想的“一个工具从头包到尾”稳定不少。
一开始我也试过让一个工具前后端一起做，但实际体验是：
- 要么后端逻辑还能看，UI 比较一般
- 要么页面看着还行，一到真实接口和业务细节就开始飘
后来我干脆分开用，反而顺很多。
Codex 这边，我现在主要拿来干这些事：
- 读现有代码，然后接着改
- 补接口、补 service、补一些联调时冒出来的碎逻辑
- 按项目原来的结构继续写，而不是重新起一套
我自己的体感是，后端开发很多时候不是单纯生成代码，而是得在已有工程里把东西补进去，而且尽量
别把原来的流程搞坏。
这类事情我目前还是更愿意交给 Codex。
Gemini 这边，我更多拿来处理 UI：
- 帮我先把页面结构整理出来
- 把比较模糊的 UI 想法先讲清楚
- 补一些交互状态，比如空状态、加载态、错误态
- 对一个区域怎么分块、信息怎么摆，先给个草稿
尤其是页面还没完全想明白的时候，先让 Gemini 帮我把第一版摊开，确实会轻松很多。
我现在比较粗暴的理解就是：
Codex更适合把东西做进去Gemini更适合先把东西想出来
当然这也不是绝对的，只是按我最近这个项目的体验，这样分工比较舒服。
不过翻车也挺真实的，主要是这几种情况：
- 上下文没给够，就让它直接大改
- 一个工具什么都想让它做
- UI 看着挺热闹，但其实不贴业务
- 后端第一版看着能跑，边界条件没补全
所以我现在基本就几个原则：
- 后端逻辑自己兜底
- UI 先看结构，再看颜值
- 不让一个工具一口气把所有事情都做完
- AI 更像推进器，不是最终裁判
至少按我现在的使用场景：
Codex 做后端，Gemini 处理 UI，这套分工我大概率会继续用。
也想问问大家：
你们现在会给不同模型明确分工吗？
还是更习惯一个工具从头用到尾？
--【壹】--：
我用的官方的，第三方的试试cc switch配置
--【贰】--：
一是太贵了，二是容易封
--【叁】--：
前端页面调整需要配合后端接口改动的话，怎么在两个cli里改，如果是各改各的怎么协同呢
--【肆】--：
我用的3.1pro
--【伍】--：
gemini用什么cli 比较便宜
--【陆】--：
有品，不过现在gpt-5.4的ui也算还能看了，如果是用脚手架、框架写的，不是从css开始手搓的，给它写也完全ok，毕竟组件是人家给你封装好的，调用就和写逻辑差不多，配合ui-ux-pro-max skill完全可堪一用
gemini幻觉太严重，价格也没什么优势，我现在是能不用就不用了
--【柒】--：
不用cc吗，个人感觉cc做从0到1的全栈开发还是挺强的
--【捌】--：
有稳定的gemini资源吗
--【玖】--：
我也是用的官方的，上面这哥们说的对，用ccs试试看
--【拾】--：
我认为codex的后端断层领先，但前端给我的感觉就是套了好几个类似的模板，不是说它直接“套模板”，而是相关的训练数据估计用的是较为雷同的数据集，导致其UI效果远不如claude、Gemini，甚至有时候还打不过国产的kimi、Deepseek、glm。
--【拾壹】--：
请问佬友，对于gemini api配置如何解决， 我买了好几点的api都不行
--【拾贰】--：
我跟佬友差不多，gemini搞UI绝对是一把好手，后端用codex、claude
--【拾叁】--：
最简单的：让另一个再读一遍改动
活用diff
--【拾肆】--：
怎么感觉一股浓浓的AI味，是我的错觉吗
--【拾伍】--：
UI处理使用什么版本的Gemini比较好呀 codex处理ui确实有点一言难尽
最近拿 AI coding 真做了一个项目/功能，算是把自己的一套工作流试出来一点了。
先说结论：
我现在基本不太纠结“Codex 和 Gemini 谁更强”了，直接按分工用。
Codex主要写后端Gemini主要看 UI
这样跑下来，比我一开始想的“一个工具从头包到尾”稳定不少。
一开始我也试过让一个工具前后端一起做，但实际体验是：
- 要么后端逻辑还能看，UI 比较一般
- 要么页面看着还行，一到真实接口和业务细节就开始飘
后来我干脆分开用，反而顺很多。
Codex 这边，我现在主要拿来干这些事：
- 读现有代码，然后接着改
- 补接口、补 service、补一些联调时冒出来的碎逻辑
- 按项目原来的结构继续写，而不是重新起一套
我自己的体感是，后端开发很多时候不是单纯生成代码，而是得在已有工程里把东西补进去，而且尽量
别把原来的流程搞坏。
这类事情我目前还是更愿意交给 Codex。
Gemini 这边，我更多拿来处理 UI：
- 帮我先把页面结构整理出来
- 把比较模糊的 UI 想法先讲清楚
- 补一些交互状态，比如空状态、加载态、错误态
- 对一个区域怎么分块、信息怎么摆，先给个草稿
尤其是页面还没完全想明白的时候，先让 Gemini 帮我把第一版摊开，确实会轻松很多。
我现在比较粗暴的理解就是：
Codex更适合把东西做进去Gemini更适合先把东西想出来
当然这也不是绝对的，只是按我最近这个项目的体验，这样分工比较舒服。
不过翻车也挺真实的，主要是这几种情况：
- 上下文没给够，就让它直接大改
- 一个工具什么都想让它做
- UI 看着挺热闹，但其实不贴业务
- 后端第一版看着能跑，边界条件没补全
所以我现在基本就几个原则：
- 后端逻辑自己兜底
- UI 先看结构，再看颜值
- 不让一个工具一口气把所有事情都做完
- AI 更像推进器，不是最终裁判
至少按我现在的使用场景：
Codex 做后端，Gemini 处理 UI，这套分工我大概率会继续用。
也想问问大家：
你们现在会给不同模型明确分工吗？
还是更习惯一个工具从头用到尾？
--【壹】--：
我用的官方的，第三方的试试cc switch配置
--【贰】--：
一是太贵了，二是容易封
--【叁】--：
前端页面调整需要配合后端接口改动的话，怎么在两个cli里改，如果是各改各的怎么协同呢
--【肆】--：
我用的3.1pro
--【伍】--：
gemini用什么cli 比较便宜
--【陆】--：
有品，不过现在gpt-5.4的ui也算还能看了，如果是用脚手架、框架写的，不是从css开始手搓的，给它写也完全ok，毕竟组件是人家给你封装好的，调用就和写逻辑差不多，配合ui-ux-pro-max skill完全可堪一用
gemini幻觉太严重，价格也没什么优势，我现在是能不用就不用了
--【柒】--：
不用cc吗，个人感觉cc做从0到1的全栈开发还是挺强的
--【捌】--：
有稳定的gemini资源吗
--【玖】--：
我也是用的官方的，上面这哥们说的对，用ccs试试看
--【拾】--：
我认为codex的后端断层领先，但前端给我的感觉就是套了好几个类似的模板，不是说它直接“套模板”，而是相关的训练数据估计用的是较为雷同的数据集，导致其UI效果远不如claude、Gemini，甚至有时候还打不过国产的kimi、Deepseek、glm。
--【拾壹】--：
请问佬友，对于gemini api配置如何解决， 我买了好几点的api都不行
--【拾贰】--：
我跟佬友差不多，gemini搞UI绝对是一把好手，后端用codex、claude
--【拾叁】--：
最简单的：让另一个再读一遍改动
活用diff
--【拾肆】--：
怎么感觉一股浓浓的AI味，是我的错觉吗
--【拾伍】--：
UI处理使用什么版本的Gemini比较好呀 codex处理ui确实有点一言难尽