随着大模型越来越智能，我已经开始将写代码的 70% 工作交给 AI 进行处理了，需要提到的一点是，这是实际工作中的 70%，前一段时间这种比例可能连 10% 都不到。我只敢用 AI 生成一些类似于验证手机号等工具函数，真实的带有业务逻辑的代码，我还是需要自己写的。

然而随着我对于 AI 的了解程度越来越高，我开始在更多场景进行使用，并且在这些场景都得到了非常好的结果。

主力用 Claude Code

我的主力依然是 Claude Code，模型就用的 Anthropic 的 Claude Sonnet 模型，我个人用了一些其它的模型，比如 Qwen Coder、智谱的模型，但在读取上下文进行创建的时候写出来的代码有些许的问题。

所以在试用过这些模型后都逐渐放弃，也可能随着它们新模型的发布后，效果已经好了很多，但是我现在却是没有心思再去尝试它们。

至于主力为什么没有换成最近大火的 Codex，虽然我也付费了 Codex，但是 Codex 的工具链非常不完善，不能自定义 / 命令，总之体验上比起 Claude Code 差了很多，而最近我又将主力编辑器换回了 WebStorm，但随着我工作使用 AI 的比例变多，我逐渐发现 WebStorm 对于 AI 的支持已经逐渐无法满足我了，所以我现在会将 VSCode 也打开，因为它对于 AI 的支持已经非常完善了。

WebStorm 上面虽然也有 Claude Code 插件，但是我工作时使用的是 Windows 电脑，在 WebStorm 上的 Claude Code 插件是有问题的，经常无法和 WebStorm 进行连接，就算连接了，使用一段时间也会断开连接，而且 WebStorm 使用侧边栏的形式打开一个 AI 窗口是不太友好的，会大大压缩工作空间。

说回 Claude Code，它的优点非常明显：命令遵循率高，只要全局提示词给的恰当，它不会出现额外的修改；上下文完善，使用简短的提示词也可以完成需求；最重要的一点是它的速度很快，通常任务会在 1-2 分钟之内就完成。

辅助用 Codex

没有将 Codex 当主力的原因是因为它太慢了，虽然最近推出了代码专用的模型，如果不涉及代码上下文，那么它的生成速度也很快，1-2 分钟就能完成；如果涉及到上下文，那么生成时间在 10 分钟以上是家常便饭，有时候我去上个厕所接个水回来，都还要等好一会儿代码才能生成出来。

但它有个非常明显的优点，Codex 几乎不需要全局提示词进行规范，它几乎不做提示词之外的工作，在之前的 Claude 模型中，如果不用全局提示词进行限制，那么它可能会给你额外生成测试文件、测试用例、文档说明等等。

而 Codex 则不会，它只会生成你需要的代码，并且你即使不给它任何的项目说明，它在生成代码之前都会先探究一遍你项目的技术栈、已有哪些方法、代码规范等等，同时它对于复杂任务的处理是优于 Claude Sonnet 模型的。

用一句话来说，如果你觉得这个需求复杂，那么选用 Codex 就对了，它的表现优于 Claude Sonnet。

听说它的额度给的很大，但实际上我用它用得少，所以也没有触发它的额度上限。

使用场景

经过上面的介绍，那么 Claude Code 和 Codex 的使用场景就非常明显了。

Claude Code 适合于日常任务，因为它快，效果也不错。

Codex 适合于复杂任务，因为它思考链长，速度慢，但生成的代码质量高，能满足复杂任务的需求。

这里再说一些具体的场景：

Claude Code

对于 Claude Code，我工作中的具体场景是：

架构搭建

在搭建架构的时候，会做很多配置，比如 Tailwind CSS、Vite、路由、请求、全局变量、TS 配置文件等等，这些任务一般都是简单繁琐，同时人工配置的话很容易漏掉某一项，并且还需要查阅相关文档才能进行配置。

而使用 Claude Code，你只需要说：“帮我引入 Tailwind CSS”。

Claude Code 就会根据你当前项目类型自动帮你引入 Tailwind CSS，并且会自动配置好相关的配置文件，你无需再去查找相关文档。

引入插件也是类似，只需要一个简单的提示词，它就能快速帮你引入，不再像过去那样要查很多文档。

代码重构

代码重构也是 Claude Code 的强项，因为代码重构一般来讲只涉及到单个文件，所以 Claude Code 重构起来也非常得心应手，比如删除文件中的冗余代码、将 CSS 转为 Tailwind CSS 等等。

尤其是转换 Tailwind CSS 这个功能，我个人是原子化 CSS 的推崇者，使用原子化 CSS，在修改 UI 的时候可以快速定位进行修改，在传统 SASS 写法中，可能这个类名是层层嵌套的，比如用了非常多的 &__ 这种写法，修改 UI 的时候找起来是灾难，不光如此，当这段代码要复制到其它地方进行使用时，由于 CSS 嵌套问题，复制起来也是灾难，而原子化 CSS 则没有这个问题。

最关键是传统 CSS 还需要想各种命名，而自从用了原子化 CSS 后，这些痛点就不复存在。

所以我在修改老页面的时候，如果看到还是使用的传统 CSS，而我又恰好要修改这个页面的 UI，那么我就会用 Claude Code 将传统 CSS 转为原子化 CSS，再进行 UI 修改，这样无论是在当前的修改上，还是后续的维护上，都会变得更简单。

DOM 生成

写页面就离不开写 div，当一个页面的样式复杂时，可能写页面都需要花上好几个小时，最近我重点优化了我这一部分工作流，将页面大部分都交给 AI 进行生成。

现在很多的设计图工具都提供了页面代码，比如 Figma、蓝湖，我公司用的是蓝湖，它的页面代码不尽人意，而且蓝湖也不像 Figma 那样可以自行开发插件。

蓝湖一般都是给出 HTML + CSS，而你的项目可能是使用的 Vue + Tailwind，那么你就可以将 HTML + CSS 发给 AI，然后再来一段精心调整过的提示词，它就会根据你提供的代码输出符合你当前项目的代码，直接可用。

但缺点还是有的，一些样式上还是需要你进行调整，不过工作量大概已经完成一半了。

再接着说，页面完成了接下来就是交互，比如页面上面有轮播、输入框、某些地方需要使用已有的组件等等。

这个时候你就可以将对应的 DOM 代码选中，通过 Ctrl+Alt+K 一键将对应代码的位置传入 Claude Code 窗口，然后配上对应的提示词：这里换成 xxx 组件、这里换成使用 JSON 数据进行渲染、这里换成轮播组件等等。

亲测，Claude Code 能够完美地实现这些需求，响应时间也非常快，通常在 1-2 分钟之内就能完成。

经过这一套流程下来，界面也完成得差不多了。

接口对接

我最近将接口对接也交给了 AI，比如我需要对接一个接口，我只需要在提示词中说：在 xxx 页面使用 xxx 接口做 xxx，后端接口返回的字段为 xxx，贴上后端给的接口文档中的返回字段，这个 AI 就会将接口进行引入，然后请求接口，最后将 DOM 里面的静态文字换成对应的接口返回的数据。

这个替换的准确率非常高，通常不会有字段需要修改，这也特别适合做后台系统，根据表头将后端返回的字段填入渲染。

在接口对接上面 AI 远远做得不止这些，如果你在全局规则上面写了使用某个 hook 调用接口，比如 useRequest 这种 hook，那么你在后续的提示词中即使你不说使用 useRequest，它在生成代码的时候会自动参照这个规则使用 useRequest。

逻辑生成

写代码时，有时候会遇到一些很简单但却又容易有遗漏的逻辑处理，比如 JSON.parse() 的错误处理，有时候会忘记写 try catch，而交给 AI 的话它会将各种异常情况都考虑进去，写出健壮的代码。

再比如递归，有时候写递归写着写着自己就绕进去了，而 AI 则会将递归的边界条件、递归的终止条件都考虑进去，写出正确的递归代码，可能自己写需要半个小时或者更久，而 AI 只需要 1-2 分钟就能写出健壮的正确的代码。

上面这些场景已经覆盖了我 90% 的生成代码的场景了，剩下的一部分场景更复杂的任务，我会交给 Codex。

Codex

轮到 Codex 了，使用 Codex 的时候主要是一些复杂任务，比如 BUG 修改、更复杂的逻辑生成。

BUG 修改

有时候会遇到一些难以查找原因的 BUG，一部分原因是用 AI 写了一个自己不太熟悉 API 的插件，然后自己修改后发现跑不起来了，这时候要自己找问题可能很麻烦，而交给 Claude Code Sonnet 由于它的思考链太短，所以不一定能解决，这个时候就交给 Codex。

Codex 会有一个很长的思考链，最终解决你的问题，当然这是理想的情况，实际上大部分问题还是得自己去解决。

也就是说，使用 Claude Sonnet 解决不了的问题就试试 Codex，如果 Codex 也解决不了，那么只有自己解决。

复杂逻辑生成

有时候有一些复杂需求，比如你脑子中有一个想法，但是不知道如何实现，这时候就可以交给 Codex，它会在你的想法基础上，生成出对应的代码，它可以根据简短的提示词生成出逻辑完整的代码。

还有就是涉及到多个文件修改的，它会层层参考所有的文件，最终生成出符合你需求的代码。

额度问题

这里说一下，在我使用 Claude Code 时，我个人是 20 美元的套餐，我在实际的使用中是会经常清空上下文的。

当我觉得这两个任务没有关联的时候就会清空上下文，这样会节约出大量的额度，所以到目前为止我没有触发过额度上限。

最后

最近 Anthropic 已经将 Opus 4.5 下放给了 Pro 套餐用户，所以现在 Pro 用户也能使用 Opus，但在我个人的工作流里面，我发现 Sonnet 已经够用了，所以我也没有去尝试 Opus，因为我担心我的套餐承受不住 Opus。

AI 已经承担了我大部分工作，并且我还在不断优化我的工作流，让 AI 承担更多的工作，从 2025 年 2 月份接触 Cursor 到现在，我的工作流已经发生了翻天覆地的变化，这一年几乎颠覆了我之前写代码的方式。