# AI IDE会不会改变个人开发者的工作方式？

URL: https://caijiao.org/posts/180
Source: docs/posts/180.md
Description: 变的地方不是打字速度，是一个人敢碰的代码面：伦敦的 Andy Cloak 一个人做到 MRR 23000 美元、600 家付费客户，Max Schmitt 一个人维护 Electron+React+Node 三层仓库。但 Stripe 统计里独立创始人中位收入反而降了 23%。

已经变了，只是变的地方和外界的说法不太一样。JetBrains 的调研给了一个很不客气的数字：90% 的专业开发者每周至少使用一次 AI 编码 agent。普及到这个程度之后，"会不会改变"已经是个过期问题，值得问的是**它改变了哪个变量**。

我的答案是：不是产出速度，是**一个人敢碰的代码面**。

这个词有点抽象，落到具体感受上是：同样一段时间里，我能同时盯住的模块数量比以前多了一截，而且不会因为切换上下文把某个细节忘掉——因为细节可以随时要它补齐。

我自己的体感是：以前接一个陌生模块的顺序是"读文档 → 找示例代码 → 试错"，现在变成"先让它把模块读懂，我再读它的解释"。顺序反过来之后，认识一个陌生领域的时间从几天压到几小时。

## 一个人能维护多大的仓库，这条线被推开了

看两个具体的人。

Andy Cloak 在伦敦一个人做 Data Fetcher，一个跑在 Airtable 上的扩展，做到 MRR 23000 美元、600 家付费客户。他的工作里有一部分是完全不适合交给 AI 的——Airtable 生态的 API 边界、权限模型、客户数据接入，这些要对着文档踩。

Max Schmitt 在德国，一个人维护 Cakedesk：Electron + React + Node.js，一次性付费 €69 不做订阅，2025 年 239 份新授权、约 €16000 毛收入。

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

*Cakedesk 首页的应用预览里能看到 Overview、Clients、Invoices、Proposals 几个模块和月度柱状图。*

这两套东西的共同点是**跨栈**。桌面壳、渲染层、Node 后端、打包分发，每一层的技术习惯都不一样。三年前一个自由职业者维护这样的仓库，一半时间耗在"这个 API 怎么用来着"上。现在这层摩擦被削掉了大半，于是"一个人能不能扛三层"从值得犹豫的问题变成了默认可以。

## 伴随而来的代价：面积变大之后，瓶颈挪了位置

Cakedesk 2025 年收到 44 个功能请求，完成 13 个。

一个每天能多产出几千行代码的人，为什么会卡在 13 这个数字上？因为**功能数量的上限从来不由写代码的速度决定**。一年 44 个请求，平均九天一个，看起来跑得动；但真实情况是每上一个功能都要照顾打包体积、跨平台回归、旧用户的迁移路径。这些东西写不出来快。

这个上限的实际表现是这样的：一周能长出好几个页面，但每上一个都要照顾跨浏览器兼容、边界输入、移动端手势，这些后续维护不会因为代码是 AI 写的就变少。Cakedesk 面对的打包链路更苛刻：Electron 每加一个原生依赖，就要重新过一遍三个平台的签名流程。

所以 13 这个数字不是产能不足，是**每上一个功能要付的固定成本在那儿**。顺着这条看，AI 提升的是产能，而产能对这个上限的影响很有限。

## 落到工作习惯上的三处变化

一是开始写更严一点的输入校验和边界测试。以前这类代码看心情写，现在变成了必须项——因为它产出的东西在本地永远"看起来是对的"。

二是更愿意把一段逻辑重写一遍而不是打补丁。以前改一处要半小时，现在重写一遍也差不多，而重写出来的东西干净得多。

三是敢于把以前不敢碰的中间层交出去重构。之前这类活要留出整周时间，现在一个下午能跑完且随时可回滚，于是默认选项从"能用就行"变成了"顺手理清"。

这三个变化都不是效率层面的，它们改的是"什么活值得做"的判断线。我自己 tool 站上的情况也一样：页面能一天长好几张，但每张都要配输入校验、错误提示和浏览器兼容，产出速度上去的同时维护债也同步上去——多出来的那部分没有人替你背。

## 宏观数据不支持"工具普及让个人更容易成功"

Stripe 的统计有一组很扎心的数字：独立创始人中位早期收入下降 23%，而前 10% 上升 19%，两端差距达到 61 倍。

如果 AI IDE 真的在整体上抬高了个人开发者的成功率，中位数不应该往下走。这组数字说的是：**工具对每个参与者都可得，所以它不构成优势**。赢家靠的是别的东西，可能是渠道，可能是已经在某个生态里的位置。

中位数往下走还有一层解释：工具的普及降低了进入门槛，涌进来的人变多了，而这个市场的总需求没有同步扩大。中位数是被新进入者拉下来的，不是老人变差了。

Data Fetcher 长在 Airtable 生态里，这个位置本身解释了它的 MRR。不是因为代码写得好。

## 落到我自己仓库里的三条实际改变

存储选型更敢偷懒了。一个人没有 DBA，需要的是**备份即复制文件**的方案。单文件数据库加 WAL 模式扛得住工具站的读写量，具体边界在[轻量存储](/sqlite/)里能查到，比装一套需要运维的数据库实在。

部署面压到最薄。一个人维护不了编排系统，我做工具站是把静态产物丢到一台机器上，用 [nginx 静态服务](/nginx/)配 `try_files` 加长缓存就收工。AI 生成 deployment 配置的时候经常默认你会用复杂的容器编排，这部分可以明确砍掉。

产品形态上更偏向入口集合而不是单个应用。Tool 类产品的维护成本和页面数量关系不大、和功能复杂度关系很大，这也是为什么[在线工具集合](/tool/)这种形态特别适合一个人做长期的那一类。

每天打开 IDE 之前先想清楚今天哪一段是要自己判断的，剩下的交给它——这是我这一年最大的工作方式变化，跟工具本身没什么关系。

---

*Data Fetcher 与 Cakedesk 数据来自作者公开总结（2025 年）；开发者使用率来自 JetBrains 开发者生态调研；收入分布数据来自 Stripe 对独立创业者的统计。*