AI发展 2026年05月08日

Claude Code 很快,但不一定让你的产品更好

by BLL

Claude Code 很快,但不一定让你的产品更好

我现在每天都在用 Claude Code。不是尝鲜,是真干活那种用。写新功能、改老逻辑、跑测试、甚至有时候让它帮我理一段我自己三个月前写的代码——说出来不怕丢人,有些地方我自己都忘了当时为什么那么写。

用下来的整体感受是什么呢?快,确实快。但快和好,不是一回事。

这个区别,我最近越想越觉得重要,所以想展开聊聊。


写得快了,review 反而更累了

先说一个很直接的体感。

自从团队里开始用 AI coding,PR 的数量明显上来了。这当然是好事,但随之而来的一个问题是:review 变得更累了。

以前一个 PR 可能改 30 行,你一眼就能看懂意图。现在很多 PR 改 200 行,里面夹着一堆"模型觉得你可能需要"的东西——多加了几个 edge case 处理,多封装了一层你没要求封装的抽象,甚至有些变量命名很像模型自己的偏好而不是项目的约定。

这种代码能跑吗?能跑。测试能过吗?大部分能过。但你会觉得哪里不对劲,就像有人帮你收拾了房间,东西都在,但摆的位置不是你习惯的那样。

我后来意识到问题出在哪:AI 非常擅长"往上加东西",但不擅长判断该不该加。

这其实是一个很老的工程原则了。代码行数不是资产,是成本。你多写一行,就多一个可能出 bug 的地方,多一个未来要维护的地方。真正成熟的工程文化,从来不是比谁写得多,而是比谁写得少、写得准。

AI 把"写"这件事的成本压到了接近零。但维护成本一点都没降。


资深的人更快,新手反而更危险

还有一个我观察到的现象。

团队里比较资深的工程师,用 Claude Code 确实如虎添翼。因为他们本来就知道自己要什么,模型给出来的东西,他们能一眼判断"这段可以、这段不行、这里换个思路"。AI 对他们来说更像一个打字速度无限快的助手,核心判断还是自己做。

但新手就不一样了。模型给什么,他们很容易先接着,觉得"能跑就行"。表面上产出变多了,但你去 review 会发现,很多代码他们自己也解释不清为什么这么写。时间一长,他们对代码的真实理解反而被冲淡了。

图1:工程师产出按资历分布,AI 时代呈现 K 型分化。

这个分化是真实存在的。AI 不是一把所有人都往上抬的电梯,更像一条 K 型曲线——上面的人确实走得更快了,下面的人反而可能被甩得更远。


如果 Claude Code 真那么强,Anthropic 自己为什么没有一骑绝尘?

这是我最近一直在琢磨的一件事。

道理很简单:如果 AI coding 真的能让工程效率翻倍,那 Anthropic 作为最先吃到红利的团队,应该在产品迭代上把所有人甩开才对。效率是可以复利的,今天快一点,明天就应该领先更多。

但现实并没有这样。Claude Code 出来之后,OpenAI 很快跟上了 Codex,Cursor 一直在跑,其他工具也没掉队。并没有出现一种"用了 Claude Code 就碾压一切"的局面。

这说明什么?说明代码生产速度,可能从来就不是瓶颈

真正卡住一个产品好不好的,是产品判断、设计取舍、对复杂度的控制力。这些东西跟你用什么 IDE、什么 agent 没有太大关系。


加功能容易,克制才难

我自己有一个特别深的体会。

用 Claude Code 之后,"加一个功能"变得太容易了。以前可能要想半天、写半天的事情,现在二十分钟就能出一个能跑的版本。这种速度感是真的让人上瘾的。

但问题是,做产品这件事,最难的不是"加",恰恰是"不加"。

你看 Linear 和 Jira 的差距在哪?不是 Linear 堆了更多功能,恰恰相反,它比 Jira 少了很多东西。差别在于有人对"项目管理软件应该是什么感觉"这件事有一套非常清楚的判断,然后花了很多年的克制去执行。

这种审美和判断力,靠 token throughput 堆不出来。

图5:真正决定产品高度的,是想法能不能持续推到边界。

再举个更具体的例子。你让 AI 帮你加一个 Slack 集成,它大概率能帮你搞出来。但紧跟着你就要想:Teams 要不要支持?邮件通知呢?移动端推送呢?企业策略兼容呢?

每一个功能背后都拖着一条尾巴。AI 只管帮你把头做出来,尾巴是你自己的事。

图3:代码不是越多越好,产品表面积会像分形一样膨胀。


那 Claude Code 到底有什么用?

说了这么多,我不是要唱反调。我现在离了 Claude Code 真的会觉得效率打折,这也是事实。

它最大的价值,我觉得是把"从 0 到能跑"这段路压缩了

以前你要验证一个想法,可能要搭半天环境、写一天 boilerplate。现在你一个小时就能看到一个粗糙但能跑的东西,这对于快速试错是实实在在有帮助的。

但它帮你做出来的是一台卡罗拉,不是法拉利。卡罗拉当然也是好车,能开能用。但如果你的目标是法拉利——那决定胜负的不是"能不能多堆一点零件",而是"哪些东西不要,哪些东西坚持删掉"。

图6:卡罗拉适合大多数人,法拉利不靠"写更多代码"来变快。


写在最后

我现在的用法大概是这样的:需要快速出原型、处理重复性工作、理解不熟悉的代码时,Claude Code 是第一选择。但涉及到核心架构决策、功能取舍、产品方向这些事情,我不会交给它。

不是因为它不够聪明,而是因为这些事情本来就不是"写代码"能解决的。

AI 让写代码的成本趋近于零,这意味着真正值钱的东西变了。以前是"谁能写出来",现在是"谁知道该写什么、不该写什么"。

用一句话总结的话:Claude Code 让你更快到达目的地,但不帮你选方向。

方向选错了,跑得越快,偏得越远。