Codex、Cursor等AI开发工具到底能帮多少忙?

“帮我写了 80% 的代码”“效率提升三倍”——这类说法我看了很多,共同问题是没法验证。80% 是按行数算还是按文件数算?如果那 80% 全是样板,帮忙有限;如果剩下的 20% 是架构决定,那才是关键。

换个问法就有答案了:按任务类型拆,每一类交给它多少。

能全交给它的(我审一遍就提交)

样板代码。表单、列表、分页、CRUD 接口、错误边界。这类代码结构固定,写错了也很容易在 review 时看出来。

配置文件。Dockerfile、compose、CI 脚本、反向代理的 server 块。它见过的配置比任何个人都多,尤其是那些标准组合。我这边 Docker 的多阶段构建它一次就写对了。

机械转换。把 SQL 结果映射成对象、给遗留代码补类型标注、把回调改写成 async/await。这类改动范围明确、验证简单。

一次性脚本。数据迁移、批量重命名、日志整理。写完就丢,质量要求低。

这四类加起来,在我的实际工作里大约占写代码时间的一大半。这一层它帮的忙是实打实的。

只能让它起草的(我要重写或大改)

业务逻辑的核心路径。它能给出合理的结构,但边界条件经常漏——空值、超长输入、并发下的状态。我会把它当草稿,逐条对边界。

数据库相关的代码。表结构设计它给的版本通常能跑,但索引该建在哪、事务边界划在哪,它考虑得比较浅。SQLite 这种"一个文件、单写者"的库,它不会主动提醒你写操作是串行的。

报错排查。贴栈进去让它先猜一轮是划算的,能省掉一部分翻文档的时间,但真正定位往往还是要自己看。

交不了的(只能自己来)

架构方向。计算放在浏览器还是服务器、页面是 50 个独立 URL 还是一个 SPA、数据存哪——这些决定影响的是成本结构和能不能被搜到,AI 的默认答案几乎总是语料里最常见的那种,而不是最适合你项目约束的那种。

取舍。哪些功能不做、什么时候发版、什么时候才推广,它没有立场,也不会拒绝。

验证。页面在关掉 JS 之后还有没有内容、响应头有没有发对、搜索能不能抓到——它不会主动去查,你得下指令,而且得自己确认结果。

不同阶段,能帮的比例不一样

同一个工具在项目不同阶段的作用差别很大,这一点很少有人提。

从 0 到能跑。 帮忙最大。脚手架、页面、接口全是标准化产出,它能一次给出可用版本,这个阶段的时间确实被压缩了。

从能跑到能用。 帮忙中等。边界条件、错误处理、状态管理,它给的草稿能省掉打字时间,但每一处都要你自己过一遍。审查成本在这个阶段最高。

从能用到能上线。 帮忙骤降。部署配置、缓存策略、索引和收录、指标达标——这些不是"生成代码"的问题,是"确认什么必须为真"的问题。它能给配置片段,但不能替你确认结果。

上线之后。 帮忙最小。判断哪个渠道有效、哪个功能该砍、什么时候推广,这些和 AI 没有交集。

按整段时间平均算出来的"效率提升"没有意义,因为阶段之间的差别是数量级的。

两个反证:瓶颈本来就不在写代码

Cakedesk 的 2025 年数据很能说明问题。Max Schmitt 一个人做桌面端发票应用,一年发了 12 个版本,收到 44 个功能请求、完成 13 个,卖出 239 份新授权,毛收入约 16000 欧元。

Cakedesk 官网首页截图
Cakedesk 官网首页截图

Cakedesk 首页第一屏放了三条五星评价和一段演示视频,再往下才是应用截图。

12 个版本听起来不多。如果写代码是瓶颈,AI 工具应该能把这个数字推到 30 个以上。它没有——因为 44 个请求里该完成哪 13 个,本身就是主要工作量,而这事 AI 帮不上。

Product Hunt 上每天约 668 次发布、feature 率约 2.8%。发布的门槛低到这个程度,说明"做出来"早就不是瓶颈了。10015.io 把上 Product Hunt 的时机推到 64 个工具之后,卡的也不是产能。

一项被忽略的新成本

AI 工具带来了一项以前没有的开销:审查成本

生成速度快了,产出量也就跟着涨,而每一份产出都需要人来判断它对不对。我自己踩过一次:它给的一段 JavaScript 代码里,边界处理写得很完整,但把一次计算放在了服务端——功能正确,成本结构错了。这类问题在 diff 里非常隐蔽,因为它不是 bug。

所以"帮了多少忙"的完整算式是:生成节省的时间,减去审查新增的时间。任务越接近样板,这个差值越正;越接近架构决定,越负。

还有一项不太被提起的代价:它会让人跳过理解。 一段能跑的配置被接受之后,你就不会再去看它为什么这么写。等到某天它和别的部分冲突,排查成本远高于当初自己写的那几分钟。我自己对 Docker 和 nginx 那部分的理解,就是在反复排查这类冲突里补上的——如果一开始就自己写,反而不用补。

我的实际分配

JetBrains 的调研里 90% 的专业开发者每周至少用一次 AI 编码 agent,这个数字和我的体感一致——高频使用,但主要在样板、配置和排查这三层。

真正有效的用法是把任务先分类,再决定交给它多少:能全交的别自己写,只能起草的别直接提交,交不了的那部分把精力全放上去。一个人做站时,第三类决定成败,而它恰好是 AI 唯一帮不上忙的那一类。