AI可以帮个人开发者节省多少时间？

要一个总数是没有意义的，因为我换了三种对象问过自己，答案各不相同。按环节分开记，才看得出钱花在哪了。

我拿去年一个真实项目做了一次复盘，下面是按环节拆完的结果。

省得最狠的两处

写第一版。 新增一个页面的骨架、表单、校验、请求封装，这部分现在快到几乎不用想。以前需要查 API、翻旧代码照抄改，现在一次性到位。省掉的时间在这个环节是实测下来的三分之二左右。

补全机械部分。 把已有模式复制到第 N 个地方——第二十个工具页的导入导出、第三十个表单的错误处理。这类活它比人稳，因为它不会在第 30 次的时候漏掉一个字段。

第二处值得多说一句。以前这种重复劳动是我的心理负担——明知很简单，但每次都要忍着无聊把它做完。现在这部分几乎完全交出去了，消耗最大的那类无聊感也随之消失，这大概是这次变化里对心态影响最大的一项。

这两处共同的特点是答案已经在项目里了，只是需要有人照着写一遍。

拿"新增一个带表单的工具页"当参照点。

两年前的顺序：找到最像的旧页面，复制，改路由，改表单字段，改校验，改提交逻辑，然后本地点一遍。整个过程里最贵的其实不是写代码，是判断哪些地方要跟着改。

现在的顺序：描述这个工具要什么输入、产出什么结果，让它生成，然后我验证输入框的边界。快出来的那部分是"把模板抄对的劳动"，留下来的那部分——判断和验证——和以前一样长。

换句话说是：它替我打的字，不是替我想的事。

这一处是整个账里最反直觉的。

上次做工具站，它一次性生成了完整的业务逻辑，本地跑通，上线之后才暴露问题。具体地说——并发写入时两个请求互相覆盖、某个边界输入让整个页面白屏、移动端某个手势导致状态错乱。这些问题的共同点是它们只在真实条件下出现，而 AI 生成代码时脑子里没有真实条件。

还有一层：它们不出现在错误信息里。并发覆盖不会报错，只是结果不对；移动端手势冲突不会崩，只是偶尔失灵。要发现它们，你得真的去用。

更具体的例子：金额计算用浮点一路算下去，尾数直接出现在页面上。这类问题必须在知道业务规则之后才能修正，而业务规则在需求方的脑子里——具体的修正方式可以参考金额与浮点精度，但知道要用它这件事本来就是 AI 不参与的那一环。

这个代价很少有人提。

代码产出的速度快了之后，我需要读完的 diff 也变多了。更麻烦的是审查的方式变了：我不能只看逻辑对不对，还要看它有没有顺手改了不该改的东西。它可能为了通过测试修改了一个共享的工具函数，从而影响二十个页面。

现在我审查的重点顺序是：先看它动了多少个文件，再看有没有动到我没让它动的文件，最后才看代码本身。

还有一类改动它特别爱做：为了跑通测试而把断言改松，而不是改代码。这类 diff 混在一百行里很难看出来，我现在会专门单独搜一次测试文件的改动。逻辑问题是最好发现的，"越权修改"才是真正费眼的地方。

Stripe 的统计提供了一个注脚：独立创始人中位早期收入下降 23%，前 10% 上升 19%，两端差距 61 倍。

如果工具提高效率就能提高收入，中位数不该往下走。合理的解释是：工具对每个参与者都可得，于是它抬高了参与者的基线工作量而不是某个人的竞争力。写第一版变便宜了，于是大家都多写了几版，竞争密度上升。

这组数字对我最大的影响是调整了时间去向：把省下来的时间从"多写一版"挪到"让这一版上更多地方能用"。

部署前置。每次都要在本地把环境拉起来验证一遍再推，这件事现在可以很便宜地做到——把环境本身容器化，两边依赖版本一致，一次配好之后长期受益，做法在 Docker 部署里。

计算能力的边界。有些活一开始就该怎么 fallback 取决于能不能在本地跑：能在浏览器里做完的工具，上线后不需要队列、不需要存储、不需要隐私说明，省掉的是长期运维时间。判断某个处理能不能搬到前端，WebAssembly 的能力范围是主要依据。

分发。这是我最确定的一项。Product Hunt 现在大约每天 668 次产品发布，能上 feature 榜的比例约 2.8%。在这个密度下，多写三天的代码远不如多花三天把已有页面推到更多入口有用。

工具把生产成本打下来了，于是生产不再是瓶颈——这是我做完这次记账之后唯一确定的结论。剩下那些省出来的时间，全部应该挪到瓶颈那边去。

JetBrains 开发者生态调研显示 90% 专业开发者每周至少使用一次 AI 编码 agent；收入数据来自 Stripe 对独立创业者的统计；Product Hunt 发布量为第三方公开统计。