我用了四个 AI 编程工具,三个月后发现自己问错了问题

导读

笔记本上装着 Claude Code、Codex、Gemini CLI、OpenCode，用了三个月，一直想找到”最好的那个”。后来发现这个问题本身就问错了。

适合正在纠结选哪个 AI 编程工具的工程师。

我装这几个工具的时候，心里有个预期：用一段时间就能分出胜负，找到值得长期用的那个。

三个月后，结论不是”哪个更好”，而是——这个问题从一开始就问错了。

我实际怎么用的

Claude Code 用得最多，主要两类场景：知识库维护和工具开发。

知识库维护是日常工作——整理笔记、更新文档、把零散内容串联成结构。这件事需要来回翻文件、改了这里看那里、发现不对了随时调整方向。CC 在这里很顺：读文件不提示，改一处我看一眼确认，不对就打断重来。这种”边做边看”的节奏和维护工作天然匹配。

工具开发也是类似的逻辑。写一段脚本，跑一下，看输出，改，再跑。CC 就在终端里，能看到实际的运行结果，有问题当场知道。

Codex 我装了图形界面版和 CLI 版。真正跑起来做过一个事情：生成一份 PPT 的大纲和内容框架。

大纲的质量还可以，把结构梳理得比较清晰。但用下来有几个地方别扭：不确定它实际理解了多少上下文，任务跑完之后不太好”继续往下聊”，感觉更像是提交了一个需求、等它交货、然后我验收。

后来我意识到，这其实是它正确的用法——只是那个 PPT 项目我一直想边做边改，这和它的设计不匹配。

问错的那个问题

我一直在问”哪个更好”，但这个问题预设了一件事：工具之间存在统一的好坏标准。

实际上不存在。

CC 适合的场景是：你需要全程参与，方向随时可能调整，需要看到真实的运行时状态。它的设计就是”人一直在回路里”。

Codex 适合的场景是：任务可以完整描述，你不需要盯着它跑，完成后你有能力审查结果。它的设计是”描述清楚，交给它，看交付物”。

这两种不是好坏，是两种工作节奏。用 CC 的方式用 Codex，或者反过来，都会很别扭——不是工具的问题，是工作节奏不匹配。

我现在的用法

不再想”默认用哪个”，而是先问自己：这个任务我需要全程参与吗？

需要 → CC。排查问题、迭代开发、需要看实时状态的工作。

不需要 → Codex 或其他。任务边界清晰、可以完整描述、完成后审查结果的工作。

Gemini CLI 和 OpenCode 也装着，偶尔用，还没找到它们明显优于前两者的场景。这不代表它们不好，只是我目前的工作节奏还没触到它们的强项。

给还在纠结的人

别急着找”最好的”，先把手头最常用的那个用透。

用 CC 的话，先把 CLAUDE.md 配好，把你的项目约定、常用命令写进去，它每次启动都会读——这比你每次重新解释上下文省很多摩擦。

用 Codex 的话，把 AGENTS.md 写清楚，任务描述越具体越好，任务结束后认真审查 diff，不要因为看起来对就直接合并。

工具的正确姿势，不是用得多就自然找到的。是先理解它为什么这样设计，再看自己的工作哪里匹配。

本文是个人使用经验，工具功能描述以官方文档为准（写于 2026-04-29）。这个领域变化很快，三个月后可能又有新答案。