我不怕中国模型：85% 的代码 AI 写，剩下的靠人的工程眼光
一个一线开发者的日常：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) 以内，避免字符串拼接”，它有时候能听进去，有时候还是犯老毛病。说明模型对性能的“直觉”还不够，得靠人的经验兜底。
再说代码风格。这个更头疼。风格是团队规范、项目约定，非常本地化。Kimi 可能没学过你们 repo 的历史提交，它生成出来的代码要么缩进对不齐，要么变量命名风格不一致。我有个同事写 Python 喜欢 snake_case，Kimi 偶尔冒出 camelCase。这些不算 bug，但合并之前我得手动改。未来 AI 能不能自动适配风格？技术上应该可以，比如训练时加入 repo 历史做 context。但至少目前，这块还得人工把关。
人的判断力还没被替代
那 15% 的返修率，说多不多，说少不少。至少说明一点：在“智能成为商品”的大趋势下，工具能解决大部分体力活，但高阶的工程判断——比如性能取舍、代码可维护性、架构一致性——仍然需要人的经验。这不是贬低 AI，而是说角色变了。以前我花 80% 时间写代码，20% 时间测试；现在反过来，80% 时间在 review 和 debug，20% 时间写 prompt 和调优。但整体产出效率翻倍了。
我不怕中国模型，也不怕任何模型。因为我知道，AI 只是把重复劳动包了，真正的价值在于你能否判断它干得好不好。就像 Ben Thompson 说的，智能最终会变成基本商品，但用智能的人，还得有脑子。
附：讨论原文在 Stratechery，链接在此：Who’s afraid of Chinese models?
来源：
