大概 22 年的时候，群里突然出现一段话：你是砍柴的，他是放羊的。你陪他聊了一天，他的羊吃饱了，你的柴却一根没砍。
随即大家都以“砍柴的”自居，把对方当成“放羊的”。不过，大家的共识也很一致：砍柴的陪不起放羊的。
直到 AI Coding Agent 出现以后，我突然发现，自己也能像放羊的一样去砍柴了。
这一切当然得益于 AI。过去是“古法编程”，大事小事都得自己动手，一行行写、一遍遍改。现在我可以把需求交给 AI，让它去读代码、改文件、跑测试，自己则坐下来陪放羊的人聊天。等他的羊吃饱了，AI 那边的代码可能也写完了。
终于，砍柴的人也可以摸鱼了。
为了更多的摸鱼时间，提升摸鱼性价比，我陆续用过不少 AI 编程工具，比如 Claude Code、Cursor 和 Codex。用得多了以后，我发现一个挺有意思的现象：即使底层使用同一个模型，换一个 Agent，实际表现也可能完全不同。有的更擅长理解和修改现有代码，有的适合跟着开发者一点点排查问题，还有的更适合把任务丢过去，让它自己跑完再回来验收。
今天就借这个话题，聊聊 Claude Code 和 Codex，以及它们分别适合把什么样的工作交给 AI。
区别
我接触 Claude Code 和 Codex 不算早。等我真正开始同时使用它们时，两边的产品能力已经比较完善，所以从使用方式上看，差别并没有想象中那么明显。于是，我专门查了一些资料，也重新梳理了自己的使用过程。
不少文章习惯把 Claude Code 归为本地工具，把 Codex 归为云端工具，放到现在已经不太准确。Claude Code 支持终端、IDE、桌面端和 Web 端，Codex 也有 CLI、IDE 扩展和 Codex Cloud，两者都能在本地或云端完成任务。
这里的云端任务不是 SSH 登录服务器，而是选定代码仓库、提交需求，由平台创建隔离环境，自动拉取代码、安装依赖、修改文件并运行测试。即使关闭电脑，任务也可以继续执行，完成后再查看 Diff 和测试结果。
所以，两者的差别不再是“在哪里运行”，而是更偏向怎样工作。我的使用感受是：Claude Code 更适合边做边沟通，Codex 更适合把边界清楚的任务交出去，完成后再集中验收。
当然，这并不是绝对界限。Claude Code 也能运行远程任务，Codex 也可以在本地反复交互，只是各自最顺手的场景有所不同。
Claude Code
对于 Claude Code（后面使用 CC 缩写代替）的使用，来自于同事的推荐。
因为自古法编程的时候，我都是远程 SSH 登录到服务器，然后使用 Vim 打开文件，开始编辑开发。直到某一天，同事给我推荐了 CC，说可以像 Vim 一样 geek，至此，我开始接触 CC。
Claude Code 与终端工作流的结合比较自然。它可以直接使用项目里的编译脚本、测试命令和 Git 工具，也可以通过 CLAUDE.md 保存项目约束。再往后，还能用 Skills 固化重复流程，用 Hooks 在修改后自动执行格式化、静态检查或测试，用 MCP 接入内部文档和其他系统。这些能力单独看都不算新鲜，放在一起却很实用。
因为一个 Agent 是否好用，很多时候并不取决于它第一次生成的代码有多漂亮，而取决于它写错以后，能不能利用项目现有的工具发现问题，并继续修正。
比如排查一个偶发的并发 Bug，我会先让 Claude Code 阅读线程模型和关键调用链。它给出几个怀疑点后，我再结合线上日志排除其中一些方向，让它继续追踪对象生命周期，尝试编写测试复现问题。整个过程不是给出一句提示词然后等待最终答案，而是人和 Agent 不断交换信息，把问题范围一点点缩小。
我更愿意把复杂重构、疑难 Bug 和历史项目梳理交给 Claude Code。不是因为它一定能够一次做对，而是这些任务本来就需要不断修正判断。开发者没有退出整个过程，Agent 也不需要假装自己已经完全理解需求。
这种方式的问题也很明显。复杂任务很容易被拉成长对话，消耗大量上下文。项目规则如果没有提前写清楚，同一个要求可能还要反复强调。看起来是 Agent 在自动工作，实际上开发者依然要投入不少注意力。
所以 Claude Code 能不能帮你摸鱼，还要看任务本身。如果问题没有想清楚，它更像一个陪你一起查问题的同事，而不是接到任务就能独立干完的外包团队。
Codex
对 Codex 的使用体验，不是单次生成代码有多快，而是可以同时推进几件事。
传统开发中，即使几项工作彼此独立，也经常因为只有一个人在操作而被迫串行：先修 Bug，再补测试，最后更新文档。使用 Codex 后，这些任务可以同时开始，各自在独立环境里读取仓库、修改代码并运行验证。任务完成后，我再集中查看 Diff、执行摘要和测试结果。
以前我会一直盯着一项工作，从分析、修改到验证全部串行完成。现在，一部分边界清楚的工作可以先交出去，我只需要在任务说明和最终验收时介入。这种方式比较适合重复性强、验收标准明确的任务，例如补充单元测试、修复静态检查问题、批量迁移接口、更新依赖和整理文档。
但我不会把一个描述模糊的核心需求直接扔给 Codex。异步执行有一个很现实的问题：如果方向错了，它也可能非常认真地把错误方案做完。任务越大，回来以后越难 Review，前面节省下来的时间，最后可能全部花在返工上。
所以使用 Codex 时，我反而会把需求写得更细。比如让它给一个接口增加本地缓存，不能只说“加个缓存”，还要告诉它缓存的 TTL 是多少，是否需要保证多线程安全，接口失败时能不能写入缓存，是否允许修改公开接口，能不能增加第三方依赖，以及需要补充哪些测试。这些约束说清楚以后，Codex 才真正适合异步执行。否则所谓“把任务交给 AI”，很可能只是把写代码的时间换成了 Review 和返工的时间。
同一个模型，不同 Agent
像很多人一样，我最开始也以为，AI 编程工具好不好用，主要取决于背后的模型。只要选择同一个模型，Claude Code、Cursor 和 Codex 的表现应该不会相差太多。真正用起来以后才发现，并不是这样。
模型负责理解和推理，外面的 Agent 则决定这个模型如何工作。它会读取哪些文件、一次提供多少上下文、怎样搜索调用关系、什么时候执行命令、测试失败以后是否继续修改，这些都会影响最终结果。
比如排查一个 Bug，有的 Agent 只盯着报错附近的几行代码，很快给出修改；有的会顺着调用链继续往下查，把配置、线程模型和对象生命周期一起看完。前者速度快，后者更容易找到真正的问题，但也会消耗更多时间和上下文。
修改完成后的处理也不一样。有的生成代码后就停下来，等开发者自己验证；有的会继续编译、运行测试，根据错误再次修改，直到结果能够交付。
这也是为什么同一个模型放在 Cursor、Claude Code 和 Codex 中，实际使用感受会不一样。除了工具提供的能力不同，它们组织上下文、调用工具和推进任务的方式也不同。所以只看模型名称，很难判断一款 AI 编程工具是否适合自己。
模型决定它能不能想明白，Agent 决定它会不会把事情做完。
经验之谈
如果需要阅读大量历史代码、排查复杂问题，而且过程中随时可能改变判断，我通常会先用 Claude Code。它适合贴着本地环境一点点往下查，我可以随时补充信息、纠正方向，必要时直接接管。
如果任务边界已经明确，可以拆成几块独立执行，我更愿意交给 Codex。比如补测试、改文档、批量修改和升级依赖，这些任务不需要一直盯着，完成后集中检查结果即可。
所以，Claude Code 和 Codex 不一定非要二选一。复杂问题用 Claude Code 跟着查，边界清楚的任务交给 Codex 去执行。怎么选，最终还是看手里的活更适合哪种方式。
写在最后
接着回到文章一开始的那个故事：砍柴的人不能停下来聊天，因为没人替他干活。现在 AI 可以帮我们读代码、改文件、跑测试，“砍柴”这件事终于可以交出去一部分了。
但这不意味着开发者真的可以什么都不管。哪些需求需要自己想清楚，哪些判断不能交给模型，哪些任务可以异步执行，最后如何验收结果，这些仍然是开发者的工作。AI 可以替我们砍柴，却不能替我们决定要砍哪片林子。
以前选择编程助手，我们关心的是谁补全得更准、生成代码更快。现在再看 Claude Code 和 Codex，真正需要考虑的是：哪些任务适合有人在旁边一起推进，哪些任务可以定义清楚以后直接交出去。把这件事想明白以后，砍柴的人才真的有时间摸鱼。
发表于 昨天 22:59
|
查看: 2|
回复: 0
