做 Python 脚本大概写了六年，从最早的 cron + 一堆 .py，到后来 FastAPI / Playwright / Pandas 混着打，最近一年多把 AI 编码助手塞进每天的工作流里。我一直对"CLI 式 AI 编码助手到底哪家更适合 Python 任务"这件事拿不准——因为 demo 看不出差距，做选型靠感觉又常常被账单打脸。
这周 Real Python 发了一篇《Gemini CLI vs Claude Code: Which to Choose for Python Tasks》，给了一个比较系统的对比框架。我按它的维度，把自己过去两个月攒的 28 个真实 Python 任务（不是 demo，不是算法题，是项目里真实提交过的改动）重跑了一遍，得到 4 组我觉得值得拿出来单独讲的数据。
先上结论（后面每条都展开）：
- 一次性脚本的首轮交付时间，两者差距在 30% 以内，但分布形态不同
- 多文件重构的一轮通过率，差距接近 1.5 倍
- 单任务平均 token 账单差距约 1.4 倍，但计费口径不对称
- 上下文窗口实际可用容量和标称值之间，有一条容易被忽视的分水岭
下面一条一条拆。
先把样本说清楚：28 个任务是什么
这类对比文最容易翻车的地方，是"样本不公开"。所以先把我的样本构成明摆在桌面上——数据洞察的前提是数据可核对。
| 任务类别 | 任务数 | 典型示例 |
|---|---|---|
| 一次性脚本 | 12 | 日志清洗、CSV 去重、批量重命名、一次性数据迁移 |
| FastAPI 接口开发 | 5 | 新增业务 endpoint、Pydantic 模型、鉴权中间件 |
| 多文件重构 | 5 | 模块拆分、依赖倒置、类型标注补齐 |
| 定时任务 / 自动化 | 3 | APScheduler 任务、Playwright 爬取 |
| 调试 / Bug 定位 | 3 | 异步死锁、Pandas SettingWithCopyWarning、依赖冲突 |
环境：macOS、Python 3.12、uv 管理依赖、同一仓库、同一分支策略。两个助手分别从各自的官方 CLI 入口调用，同一个 prompt 跑两遍，比较首轮产出（不做多轮纠偏）。
样本不完美的地方：28 个任务偏向我个人工作流（后端偏重、前端极少），如果你主要做 ML 训练脚本或 Jupyter 探索，这份数据的外推性需要打折。
接下来进入 4 组关键数据。
数据 ①：一次性脚本的首轮交付时间，差距 < 30%，但分布不同
一次性脚本是 Python 最常见的场景之一：写完即用，跑完即扔。
| 指标 | Gemini CLI | Claude Code |
|---|---|---|
| 中位首轮交付时间（n=12） | ~2.1 min | ~2.8 min |
| 最短 | < 1 min | ~1.2 min |
| 最长 | ~4.6 min | ~5.1 min |
| 首轮可直接运行比例 | 10/12 | 11/12 |
怎么读这张表：
- 中位值上 Gemini CLI 更快，原因我观察下来是它更早结束"计划阶段"直接动笔，对于"删 CSV 里重复行"这种明确任务非常合适
- 但注意"首轮可直接运行比例"——Claude Code 虽然慢 30% 左右，首轮通过率略高（11/12 vs 10/12）
- 最长那两个例子都是"要求脚本额外带 CLI 参数解析 + 日志"，Claude Code 会主动补
argparse和logging，Gemini CLI 常常只给最小实现
可量化的行动建议：如果你的一次性脚本里"写完丢进 cron 再也不改"的比例 > 60%，Gemini CLI 的分布更有利；如果一次性脚本经常第二天被别人捡去改，Claude Code 省下来的返工时间更值钱。
Real Python 原文在这一维度上的结论与本样本方向一致：Gemini CLI 在单文件、短任务上有节奏优势，Claude Code 在需要"完整可维护产物"的一次性脚本上更稳。
数据 ②：多文件重构的一轮通过率，差距接近 1.5 倍
这一组是我最关心的，因为多文件重构才是 AI 助手真正节省时间的场景——写一次性脚本本来也就 10 分钟。
| 指标 | Gemini CLI | Claude Code |
|---|---|---|
| 多文件重构一轮通过（n=5） | 3/5 | 5/5 |
首轮 mypy --strict 通过 | 2/5 | 4/5 |
| 首轮单测全绿 | 3/5 | 5/5 |
| 平均改动文件数 | 4.2 | 5.6 |
几个容易被忽视的观察：
- Claude Code 平均改动的文件数更多（5.6 vs 4.2），不是因为它瞎改，而是它更倾向于"顺手把 import 路径、
__init__.py、相关测试一并更新" - Gemini CLI 在"只改主文件，忘了
__init__.py或配套测试"这个反复出现的坑上栽了 2 次 - 有一个反例：Gemini CLI 在一次"把同步函数改成 async"的重构里，比 Claude Code 早 40 秒给出可用版本——它没有做额外的调用方扫描，结果正好这个任务调用方只有一处
可量化的行动建议：
- 重构任务涉及 > 3 个文件、或涉及类型签名变动时，Claude Code 的一轮通过率优势会直接折算成你省下的"第二轮修复时间"
- 如果团队内还在推
mypy --strict，这组数据值得单独贴到你们的工具选型文档里
数据 ③：单任务平均 token 账单，差距约 1.4 倍，但计费口径不对称
这一组我犹豫过要不要写，因为定价经常变动。但"token 成本"已经成为基础设施支出项，再绕不过去。
以我这 28 个任务为样本（本人账单口径，2026-04 采样）：
| 指标 | Gemini CLI | Claude Code |
|---|---|---|
| 单任务平均 token 消耗 | 较低基准 | 约 1.4 × 基准 |
| 分布集中度 | 标准差较大 | 相对集中 |
| 成本最敏感任务类别 | 多文件重构 | 多文件重构 |
为什么不贴绝对数字：两个助手的计费口径不完全对称（是否计入工具调用、prompt cache 折扣规则、实际计入计费的输出 token 边界，都存在差异）。绝对数字贴出来容易被当成"定价对比"，那是一篇单独的文章。
更该关注的是这件事：
- token 不是单独看的，要和数据 ② 的一轮通过率一起看
- Claude Code 单次贵，但一轮通过率高 → 返工成本和上下文重建成本更低
- Gemini CLI 单次便宜，但如果一个重构任务平均多跑 1.5 轮 → 总账单很可能反超
可量化的行动建议：用"月度实际账单 ÷ 月度成功交付任务数"算你的实际单任务成本，不要用官网贴的 token 单价估算。我自己的团队这样算完，两者的实际单任务成本差距从"看起来的 1.4 倍"压到了大约 1.1 倍。
数据 ④：上下文窗口的"标称值"和"实际可用容量"之间有一条分水岭
两边都号称"超大上下文"。但跑过真实项目你会知道——标称窗口和可用窗口是两回事。
我在一个真实项目上做了粗糙测试：把一个 60k 行左右的 Python 仓库分三档喂进去（不同比例），观察"助手在回答里准确引用远端文件"的能力。
| 仓库投喂比例 | Gemini CLI 准确率 | Claude Code 准确率 |
|---|---|---|
| ~15% | 高 | 高 |
| ~45% | 中 | 高 |
| ~80% | 明显下滑 | 中 |
| 100% | 基本失效 | 有降级但仍可用 |
要点：
- 两者都有"标称窗口远大于实际可用窗口"的特征，这不是哪家独有的问题
- Claude Code 在投喂比例 45%~80% 段的下滑更平缓，这对中大型 Python 项目非常关键
- 100% 投喂对两者都不现实——更值得投入的是做好分层索引、按需拉取的策略，而不是幻想"把整个仓库塞进去"
可量化的行动建议：如果你的项目 > 30k 行代码，不要依赖任何单一助手"把整个项目看进上下文"。把仓库拆成稳定底座 + 活跃模块两层喂给助手，成本和质量都更可控。这与 Real Python 原文里"优先喂关键文件而非整个仓库"的建议方向一致。
选型建议：按任务类型分，不要按品牌站队
把上面 4 组数据合起来，我会这样选：
- 一次性脚本占 > 60% → 优先 Gemini CLI，节奏优势在总时间上能体现出来
- 以多文件重构、类型系统、框架级改造为主 → 优先 Claude Code，一轮通过率的红利直接变现
- 团队既有存量项目 > 30k 行 → 优先 Claude Code，上下文窗口的实际可用容量更抗压
- 月度 AI token 账单已经成为显性预算 → 先算"单任务成本"，再选
- 刚入门、个人学习场景 → Gemini CLI 的学习曲线更平，Real Python 原文对这种读者也更友好
一个反直觉结论：两个助手的"平均质量差距"没有社交媒体上吹的那么大。真正拉开差距的是你的任务分布结构——这才是选型文档里应该写清楚的第一条。
FAQ
Q1：这套对比能外推到其他语言（Go、Rust、TS）吗？
结论性外推不建议。上面 4 组数据中，数据 ②（多文件重构）和数据 ④（上下文可用容量）与 Python 生态关联较弱，可以合理外推；数据 ①（一次性脚本节奏）和 Python 的"脚本语言属性"强相关，外推到 Rust 会明显失真。
Q2：一轮通过率这个指标怎么在团队里落地？
最简单的版本：在 PR 模板里加一行 "AI 辅助？Y/N；是否一轮通过？Y/N"。两周就能统计出你们实际的一轮通过率，拿到真实数据后再决定工具选型，比看任何博客都靠谱。
Q3：Gemini CLI 和 Claude Code 能共存吗？
能。我自己的工作流是：一次性脚本 + 快速探索用 Gemini CLI，多文件重构 + 长任务用 Claude Code。两者都认同"把文件粒度切小、把 prompt 写清楚"的习惯，所以切换成本很低。
Q4：为什么不把具体 token 单价贴出来？
因为两家定价都在动（prompt cache 折扣、工具调用计费规则会小步调整），把绝对数字写进文章，半年后就会误导读者。真正稳定的是"计费口径结构"和"按单任务成本评估"的方法论，这些我在数据 ③ 已经展开。
Q5：为什么样本只有 28 个？
因为这 28 个都是真实项目任务，不是我为了写文章专门构造的。构造样本很容易刷出好看的数字，但对选型没有参考价值。如果你想自己复测，不需要 28 个——从自己项目里挑 5 个最近提交过的真实任务，跑两遍就能看出差距。
最后留一个开放问题
我很好奇一件事：你们团队有没有专门为 AI 助手编排任务粒度？比如把一个大的重构任务主动拆成"助手能一轮吃下"的小块，再人工把结果拼起来。
我最近在跑的一套流程是：大任务先人工分拆 → 每小块丢给最合适的助手 → 人工做集成和最后一英里。初步数据看起来比"直接把大任务丢给某一个助手"的总时间更短，但样本还不够。
欢迎在评论里贴你们的做法和数据，这块我觉得 2026 年值得单独写一篇更大的样本对比。
