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

URL: https://caijiao.org/posts/130
Source: docs/posts/130.md
Description: "效率提升几倍"是没法验证的问法。按任务类型拆更实在：样板、配置、转换能全交，架构决定交不了。Cakedesk 一年发 12 个版本，瓶颈本来就不在写代码上。越接近架构决定，它帮上的忙越小。

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

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

## 能全交给它的（我审一遍就提交）

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

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

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

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

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

## 只能让它起草的（我要重写或大改）

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

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

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

## 交不了的（只能自己来）

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

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

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

## 不同阶段，能帮的比例不一样

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

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

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

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

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

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

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

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

![Cakedesk 官网首页截图](/images/2026-09/cakedesk.app.png)

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

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

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

## 一项被忽略的新成本

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

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

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

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

## 我的实际分配

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

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