https://blog.911015.com/ai/ Recent content in AI 观察 on Go Home Hugo -- gohugo.io en-us https://blog.911015.com/ai/claude-code-33k-tokens.html Mon, 01 Jan 0001 00:00:00 +0000 https://blog.911015.com/ai/claude-code-33k-tokens.html 导语 这篇文章来自 systima.ai 的博客，标题叫《Claude Code vs OpenCode Token Overhead》。作者在同样的模型、同样的机器、同样的任务下，把这两个编程助手拆开看了个底朝天。 结论很简单：Claude Code 每轮对话前自己先吃掉 33k tokens，OpenCode 只用 7k。但在复杂的多步骤任务中，Claude Code 的总消耗却比 OpenCode 更低。 你以为的“省”，和实际上的“省”，是两码事。 作者做了一件很多人想过但没做过的事：在 API 层面拦截了 Claude Code 和 OpenCode 的每一次请求，逐层分析 token 花在了哪里。 先说最扎眼的数字。 在用户还没输入任何内容之前，Claude Code 光是系统指令、工具定义、内置脚手架，已经烧掉了大约 33,000 个 token。OpenCode 是 7,000 个。差距接近 5 倍。 这 33k 是怎么堆出来的？拆开来看： 工具定义占了最大头：Claude Code 内置了 27 个工具，包括后台代理编排、任务管理、推送通知这类“平台级”功能。光是这些工具的定义（tool schemas）就占了大概 24k tokens。OpenCode 只内置了 10 个经典编码工具，工具定义只占 4.8k。 系统 prompt 本身也有差距：去掉工具定义后，Claude Code 的系统 prompt 还有 26,891 个字符，约 6.5k tokens；OpenCode 是 8,811 个字符，约 2k tokens。 换句话说，OpenCode 的整个“启动成本”还没到 Claude Code 的工具定义的零头。 https://blog.911015.com/ai/chinese-models-85-percent-code.html Mon, 01 Jan 0001 00:00:00 +0000 https://blog.911015.com/ai/chinese-models-85-percent-code.html 一个一线开发者的日常：Kimi 完成大部分代码，我负责 review 和 debug 导语 Stratechery 那篇《Who’s afraid of Chinese models?》在 Hacker News 上吵了三百多条评论，标题挺唬人，但作者 Ben Thompson 其实在说经济账：AI 的智能正在变成商品，竞争核心是谁的成本结构更好。我没那么宏观，我就是个写代码的。每天用 Kimi 写 85% 以上的代码，我负责 review 和 debug。说真的，我不怕中国模型——我每天都在用，而且用得挺顺手。 “中国模型？能干活就行” 选 Kimi 不是因为爱国，也不是因为恐惧。说实话，我根本没多想产地。当时试了几个模型，Kimi 效果不错，价格也合适。算下来每百万 tokens 输入才 3 美元，比某些竞品便宜将近一半。更关键的是，它写出来的代码功能基本能跑通，review 时我主要看是不是符合预期。 这种选择纯属性价比。Ben Thompson 在文章里说，智能最终会成为可互换的商品，用户不在乎 token 来自哪个模型，只看最终产出。我这一年的实践完全验证了这点。你问我会不会因为某天 Kimi 某个任务不如西方模型就切换？会啊，谁选性价比低的？忠诚度在商品市场里不值钱。 85% 的数字是怎么来的 我主要做后端开发，日常需求就是写 API、处理数据、调业务逻辑。现在玩法变了，我不再一行行敲代码，而是把需求用自然语言描述给 Kimi，它生成代码块，我 review 后合并。粗略统计，最近一个月，所有新增代码行数里超过 85% 是 AI 生成的。我的角色从“写代码”变成了“审代码 + 修 bug”。 这个转变好不好？有些日子觉得轻松，但有些日子也挺烦。AI 能干 85% 的活，但 15% 仍然需要人的工程眼光。返修的主要原因我总结了两类：性能问题和代码风格。 返修最多的那两样 先说性能问题。Kimi 经常写出 O(n²) 的循环，或者没必要的数组拷贝。明明我 prompt 里写了“注意性能”，它还是给你整个双层 for 循环去查字典。我得肉眼优化成哈希表或者提前 break。这到底是模型能力问题还是我 prompt 不够细？我试过把需求拆得非常碎，比如“时间复杂度 O(n) 以内，避免字符串拼接”，它有时候能听进去，有时候还是犯老毛病。说明模型对性能的“直觉”还不够，得靠人的经验兜底。