五个 AI CLI 半年实测小记：Claude Code、Codex 与 Kimi

起因

去年底开始，我把五个 AI CLI 接入了日常工作流：Claude Code（Anthropic）、Codex CLI（OpenAI）、Kimi Code CLI（月之暗面）、GLM 系 CLI（智谱）、Gemini 3（Google，跑在它的 Antigravity 平台上——平台名字比较新，其实就是 Google 的智能体开发环境）。最早是见哪个流行用哪个，一个工具从头用到尾，结果频繁踩坑：A 写的东西 B 不知道，互相覆盖，有一次差点把没提交的配置直接覆盖掉。后来我停下来做了一次彻底的梳理——不看任何评测文章，只看自己三个月的工作日志，统计每类任务实际交给了谁、返工了几次。这篇就是那次梳理的结果，加上后来半年多迭代出来的协作规则。

先把版本账摊开：这大半年我实际用的是什么

我写工作日志有个习惯，每个时期用的是什么版本都记着。既然要谈真实体验，就把这大半年的版本演进先摊开——很多人聊工具体验从来不提版本，等于聊了个寂寞，因为你的印象很可能是"Sonnet 4.6 时代"的，而模型三个月前已经换了人。

时期	Claude Code	Codex CLI	GLM CLI	Kimi	Gemini
2025 底（起步）	Sonnet 4.6（4.5 基本跳过）	GPT-5.1-Codex-Max	GLM-4.6 → 4.7	K2	Gemini 3 刚发布（随 Antigravity）
2026 春	Opus 4.6~4.8 → Sonnet 5	GPT-5.5	GLM-5 → 5.1	K2.5 → K2.6	Gemini 3.1 Pro
2026 夏（现在）	Fable 5（Mythos 同源）/ Opus 5	GPT-5.6 Sol	GLM-5.2 → 5.3	K2.7 Code → K3	Gemini 3.1 → 3.7 Flash

这张表本身就有信息量：一，换代速度比大多数人跟进的速度快——GLM 从 4.6 到 5.3 用了不到一年，Claude 从 Sonnet 4.5 到 Fable 5 也差不多；二，换代并不总是一帆风顺——Fable 5 六月初上线三天就因问题被撤回，七月初才恢复，不少人的主力当场断供。这事给我的提醒是：同一个模型，不同订阅档位、不同接入通道的可用性可能完全不同。评估一个订阅套餐时，额度和价格 之外，“新模型翻车时你有没有备用通道”也是个容易被忽略的维度——多养一个工具的另一个理由；三，换代对"脾气"的影响真实存在但有延续性，比如 Codex 系的执行力强、验收环节要盯退出码这个特点，从 GPT-5.1-Codex-Max 到 GPT-5.6 一直都在。所以下面谈分工逻辑，是跨版本仍然成立的那些东西。

核心分工：按"脾气"路由，不按排名

评测文章喜欢给工具排名，但真实用起来，排名几乎不重要，脾气匹配才重要。我这套阵容的路由大概是这样：

• 深度推理和跨文件改动 → Claude Code：上下文长、出错时会主动交代"我为什么这么做"，归因质量直接决定修复速度；架构分析和复杂改动的第一人选。从 Sonnet 4.6 用到 Fable 5，这个定位没变过。
• 目标明确的小范围修改和跑测试 → Codex CLI：给它文件范围、验收标准和允许改动的边界，效率最高——但它有个毛病，报"完成"之前你最好亲眼看到退出码（后面细说）。GPT-5.1-Codex-Max 时代就是这个脾气，到 GPT-5.6 依然。
• 材料整理、跨文档归纳 → GLM CLI：任务收窄后很稳，输出结构听话不发散；GLM-4.6 到 5.3 一路用下来，长上下文是越换越能打。
• 联网调研、行情摸底 → Kimi：让它带着来源 URL 回报告、营销水分标出来，是我做决策前摸行情的固定动作。
• 多方案候选和快速原型 → Gemini 3（Antigravity）：适合"同一个问题给我三个思路"的场合，浏览器操控和多智能体并行是它的特色。
• 格式转换、批量重命名这类机械活：谁闲着谁干，甚至并行派给两个，谁先交用谁的。
• 编外客串 → DeepSeek：偶尔点名用一个，发挥稳定。没进主力阵容的原因很实在：它是按量计费、没有订阅套餐，而上面五家的订阅额度已经够用——个人组队，额度结构和模型能力一样是入选条件。

判断脾气匹配有个笨但有效的办法：拿同一类任务分别派给两三个工具各做三次，记录返工率。我就是这样确认"归纳类任务别交给爱自由发挥的工具"的——比任何榜单都准，因为那是你自己的任务分布。

踩过最大的坑：不是工具笨，是它们互相不知道

早期最痛的问题：多个工具同时工作，没有统一的规范。A 按自己的理解重命名了文件，B 找不到路径直接报错；A 改了配置没说，B 把配置又改了回去。这类事故的共同点是人觉得"这 obviously 不能碰"，但工具之间没有任何通道知道这件事。

解法说来简单：把所有工作区约定写进一份每个工具启动时必读的规则文件。哪些目录绝对不动、改完必须跑什么验证、报告必须带什么信息——全部显式写下来。规则文件本身要短，只留红线，长了我发现工具反而会漏读关键条目。

工具不会自动知道"这里不能碰"，只有显式写下来它才会遵守。

最有用的一条规则：任务先冻结，再动手

我交付质量提升最明显的一次改变，不是换了更强的工具，而是改了派任务的方式。以前我的指令常是一句话："帮我把这个报表弄好。"结果拿到的东西方向就偏，来回改三四轮。

后来我强制自己派任何非琐碎任务前，先花两分钟写一个任务卡，六个字段：背景、输入文件、目标产物、禁止事项、输出路径、验收标准。就这六项，把"我以为它懂了"的空间压到几乎为零。实测同一类任务的往返次数从三四轮降到一轮，多数时候一轮通过。

其中"禁止事项"最值钱。工具最擅长把任务"做完"，但你对"哪里不能碰"的隐性知识，不写它就永远不知道。

第二个大坑：它汇报"成功"时，要看到退出码

有一件事花了我半个月才真正长记性：一个工具汇报任务"全部通过，25 项测试 PASS"，我信了，继续往上盖。后来翻原始执行记录才发现，真实结果是退出码非零、还带着一个解码异常——汇报里的"PASS"是它自己脑补的。出事的正是前面说的"效率最高"的那位，这不是打脸，是提醒：工具越快，你越要盯它的验收环节。

从那以后我定了一条铁律：任何"成功"的声明必须附带真实的退出码和原始输出，不接受转述。管道命令必须校验首段的退出码，出错修完必须完整重跑，禁止"局部通过推整体完成"。这听起来偏执，但你只要被咬过一次，就会明白这是省时间的规则，不是浪费时间的规定。

会犯错的模型，同样会把错误汇报得理直气壮。

现在的日常形态

如今这套东西跑顺之后，我的角色变了：我不再亲手写大部分代码和文档，而是维护规则文件、写任务卡、做验收。五个主力加一个偶尔客串的 DeepSeek，像一个小作坊，各干各的长项，我在中间做调度和质量闸门。

下一个想解决的问题：任务路由本身能不能也沉淀成规则——哪类任务自动走哪条线，减少我凭感觉判断的比例。有了结果再写一篇。