根据你的需求选择正确的模型可以事半功倍。
各家模型有长有短，哪怕是曾经的五边形战士 Claude 大人如今也变的人模鬼样。
在预算充足的情况下最好的组合依然是御三家。
Claude+Codex+Gemini 完美的职责分配，正如 OhMyOpenCode 的架构理念，Claude 编排，Codex 后端，Gemini 前端。
在预算不充足的情况下我也推荐你至少保底拥有一个 Codex 的订阅，无论是中转还是官订。
其次 Gemini 可以用 Google 的 Stitch 工具替代，Claude 则使用 GLM/Kimi 替代。
说说为什么我一定要使用 Codex 来承担大部分的实际开发吧，Codex 的编码能力虽然经常出现防御性设计和兜底原则，但是经过长时间的使用我依然觉得，在编码能力上，Codex 的性价比和性能兼备，完全可以当作苦力黑奴来使用。
OpenAI 本身有一个 Claude Plugin 支持在 CC 中用自然语言让 Codex 来打黑工，可以大幅度的节省 Token 开销。如果是小项目开发完全可以和 Claude 自然语言对话，然后把实施方案转交给 Codex 落地，Claude 负责 review。但是一定要记住规则怪谈，不要让 Codex 碰你的任何 CSS/JS/PHP 等和前端展示层有关的任何代码，如果你不想品尝新鲜美味答辩。
虽然国产模型还有很长一段路要走，但是现在发展阶段中的 Kimi/GLM 不仅可以承担编排任务/规划的职责，还可以顺手把前端工作搞定。选择错误的模型，不仅浪费你的时间和 Token，还会造成你的心智负担压力加大。后期返修重构更是苦不堪言。所以请根据你的工作/业务需求，选择正确的模型。
排名不分先后顺序
前端模型推荐
-Kimi k2.5/2.6
-GLM 5.1
-Gemini 3.1
-Claude Opus 4.6/Sonnet 4.6
-（小米家的模型听说也不错，但是没用过）
后端推荐模型
-GPT 5.4
-Claude Sonnet 4.6
-Claude Opus 4.6
-GPT 5.2
通用推荐模型
-Claude Opus 4.6
模型缺点/踩过的坑
GPT 非常喜欢做过度防御性设计和兜底原则，代码质量上唯一我不喜欢的地方。20 行能实现的代码非要写 200 行。不过对于长期推进的项目来说也算是好事。
GPT 的前端非常灾难，4 张卡片并列还会加上各种小字+开发者描述。任何 Skill 和提示词都无法攻克的模型底层问题。
GPT 的输出内容问题非常大，主要分为两个方向。互联网黑话、语癖、天天中彩票预料污染/输出结构混乱问题，通过 Agents.md 列举正反例可以尽量解决。将输出结构改为 4 段，开头一句话总结，第二结构分析问题所在，第三结构分析如何修复，最后总结给出执行方案。其余口癖可以参考其他佬的教程。这里不过多赘述。
Claude Opus 4.7 的幻觉率非常高，需要经常手动 compact 避免写狗屎，并且由于蒸馏导致口癖奇怪，消耗也高，非特殊情况不推荐使用。
Claude Cli 非必要不坚持使用最新版，A/最喜欢作妖，时不时给你整点缓存爆炸或者各种奇怪的问题非常影响体验。
Gemini 除了前端非必要情况最好不要参与后端代码的编码。
Kimi 的工具调用非常狗屎，经常出现 400 错误 （在码字的时候已经发布 2.6 了 不确定是否改善这个问题，待定）
GLM 的模型可能不错，营销真的是一坨狗屎，懒得喷，严重超兽高峰期基本不可用并且涨价不给退款。兜底推荐小黄鱼随便买点天卡凑合用。
Deepseek 在我没有看到 V4 之前不予评价。（快发布啊啊啊啊啊啊啊啊）
Plugin/SKill/MCP 推荐
不推荐安装大量的 Skill 和 MCP，原因很简单，LLM 的本质就是在海量的数据中，根据你的提示词去推测应该输出什么内容，海量的 Skill 并不会给你带来非常大的提升，最终还是要依赖模型本身的能力和你的提示词准确性。譬如 GPT 如何改装都无法抢救的答辩前端水平。有文献提到过最稳妥的 Skill 数量应该控制在 10 个以下。对于真正的生产力来说，无论是 OpenClaw 还是 Superpowers、GSD、Oh-My-xxxxx 全家桶，各种稀奇古怪的影响你工作流的插件可能你根本不需要他。
如果你是和我一样的改装狂人，觉得原版纯净的 LLM 就是不喜欢，我一定要和别人不一样，那么我只会推荐你安装通用型轻量化的 Skill。这是我每个月大概烧 8000 刀 Token 总结出来的血与泪。
全栈推荐
Trellis 框架
andrej-karpathy-skills
前端推荐
由于过于海量，未必适合每个人，放到结尾做资源统一管理。
如何 『正确』 的 VibeCoding
虽然我是计算机相关专业毕业，但是从业基本和互联网不沾边 （进厂拧螺丝/淘宝店客服/剧本杀店打工/游戏陪玩/酒吧营销/KTV 陪酒），也是去年才回归老本行。之前的知识早就忘的一干二净。我相信大部分人的开发之路都是，一个 Idea 丢给 AI，开始疯狂的产代码，写到后期难以维护，疯狂陷入 Debug/Review 和重构。
在你创建任何一个项目的时候应该为技术栈选型。Vue/TypeScript/Go/Rust/Electron/Python 等多种语言，你可以一行代码都看不懂，但是你至少应该理解这些语言不同的优势点在哪？什么适合你的项目？如果你完全不了解建议在立项之前先和 AI 咨询你的需求，先确定好你的项目技术栈。
接下来是工程架构问题，我个人最常用最常见的两个词 「模块化」「前后端分离」，宛如金字塔结构，将你的项目拆分为前端/后端/服务层等不同区块，每个区块当中不应该出现大量文件在单页堆积。
将你的项目拆分为尽量可读可维护的工程结构。不仅美观且对于 AI 来说，无论是阅读还是改动都不需要塞入大量上下文，改动也不需要改一处同步修改十几个文件。
举个例子，一份 index 页面中承担表单展示+注册业务+美化渲染+css 样式，同时还承担后端的鉴权。不仅为你的项目带来了高危生产漏洞，同时本身几十行就能实现的代码，硬是被体量堆积成了 2000 行的单页超大屎山。
善用 Github 或者任意代码备份方式。
如果你真的专注于提升生产力，为什么你应该拥有一个官方订阅兜底？
相信很多佬都注意到了，从 Cursor 的超额无限账单、Kiro 的 awsq、OpenAI 的注册机/卡订阅，始终有一批佬热衷于薅羊毛 （非贬低无恶意）。在各大公司相继学习 「AI 提效」 的环境下，我之前水过一帖发现，事实上大部分公司压根不会报销或者报销额度极低。预算问题确实导致了无法用 Token 堆积来提高自己的生产力。但是难道这不是悖论吗，假如你为了提高生产力转而耗费时间去维护注册机想尽办法薅羊毛，这不是变相的耗费自己的时间，为何不是冲一个相对便宜的官方订阅兜底呢。尽管薅羊毛本身也是一种学习过程就是了。。我也开过自用的 Team 号池。同时也感谢站内各位分享思路的大佬！
引用 Neo 的一句话
还想写点什么但是一时半会想不起来了，后面想到再编辑吧，看来确实老蹬了，文笔也不是很好请见谅，也欢迎大家分享交流自己学习 AI，开发过程中遇到的问题，