# AI IDE真的可以让一个人完成整个网站吗？

URL: https://caijiao.org/posts/128
Source: docs/posts/128.md
Description: JetBrains 调研显示 90% 的专业开发者每周至少用一次 AI 编码 agent。但"完成一个网站"里，能交给它的是代码，交不了的是"计算放哪一端""页面怎么拆"这类决定，而这三个决定恰恰最贵。

JetBrains 的调研里有个数字很扎眼：**90% 的专业开发者每周至少用一次 AI 编码 agent**。这个比例已经高到讨论"要不要用"没有意义了。

但"让一个人完成整个网站"这句话里，"完成"是被混着用的。写代码是一个动作，把一堆决定做对是另一个动作。AI IDE 把前者压到了很低的成本，后者它基本没碰过。

能不能完成，取决于你怎么划这条线。

## 能全交给它的那部分，我列个具体清单

这些事情我现在已经不自己写了，交给 AI IDE 出第一版，我审一遍就能用：

样板代码——页面骨架、表单组件、列表分页、CRUD 接口。这类代码结构固定，出错也容易看出来。

配置文件——Dockerfile、compose 文件、[Nginx](/nginx/) 的 server 块、CI 脚本。AI 对常见配置的记忆比大多数人强，尤其是那些写过一千遍的反代和 TLS 配置。

机械转换——把 SQL 结果映射成对象、把接口返回补成 TypeScript 类型、给老代码补错误处理。

一次性脚本——数据迁移、批量改名、格式整理。这些写完就扔，质量不重要。

调试的粗筛——把报错栈贴进去让它先猜一轮，能省掉一部分翻文档的时间。

这几项加起来，占一个人写网站总工作量的比例不低。它确确实实让一个人的产能上了一个台阶。

## 交不了的是三个决定，而且这三个决定最贵

**第一个：计算放在哪一端。**

这是工具站最关键的一个决定，也是 AI 最容易给错答案的地方。你让它"写一个 PDF 转换工具"，它默认会给你一个服务端接口——上传、处理、返回。这条路径能跑通，但成本随用户量线性上涨，还要处理文件清理。

正确的答案往往是另一个：**几乎所有处理在客户端跑，极少请求服务端**。10015.io 靠这条原则把 50 多个工具的成本压到几乎不动。AI 不会主动想到这个，因为它不知道你的成本结构。

![10015.io 官网首页截图](/images/2026-09/10015.io.png)

*10015.io 首页的标语是 All Online Tools in One Box，副文案里写明做站初衷：治书签栏的乱。*

这类活落地时要用 [WebAssembly](/webassembly/) 跑编解码器，配置上和纯 [JavaScript](/javascript/) 方案完全不同：文件不上传、结果不落盘、服务端只发静态资源。它属于必须先定的架构问题，改起来要动整条数据路径。

**第二个：页面怎么拆。**

一个工具站是 50 个独立 URL 的页面矩阵，还是一个单页应用里切 50 个 Tab？这个选择决定了它能不能被搜到、能不能长出入口。AI 给的默认答案是后者，因为那样代码更"整洁"。

**第三个：不做什么。**

AI 没有拒绝能力。你让它加功能，它就加。而一个人做站最核心的能力恰恰是拒绝——10015.io 那条"50 个工具才发文、128 个才做 v2"的门槛，AI 不会替你写。

## Data Fetcher 的 23000 美元 MRR，是哪种能力的产物

Andy Cloak 一个人在伦敦运营 Data Fetcher，一个 Airtable 扩展，600 个付费客户，MRR 23000 美元。

一个扩展能做到这个规模，产品判断的比例远高于代码量。选 Airtable 生态、选定"把外部数据拉进来"这个具体动作、定 MRR 级别的定价——这三件事和写代码的关系不大。

Cakedesk 也一样。Max Schmitt 一个人做桌面端发票应用，Electron 加 React 加 Node.js，2025 年发 12 个版本、卖出 239 份新授权。他收到 44 个功能请求只完成 13 个——这个筛选动作，AI 帮不上。

## 验收 AI 产出的三个具体动作

代码交上来之后，我固定做三件事，花的时间比生成多，但省下的返工更多。

第一件，关掉浏览器的 JS 再打开页面，看内容还在不在。这能直接验出它是不是又做成了前端渲染的空壳。

第二件，打开网络面板走一遍主流程，看有没有意外的上传请求。发现文件被传到服务器，说明架构方向被它带偏了。

第三件，看响应头。缓存头有没有设、压缩有没有生效、跨源隔离那两个头是不是由正确的那一层发出的。AI 写的应用层代码经常在这些地方和实际部署环境对不上。

这三件事的共同点是：都不是"代码对不对"的问题，是"运行起来是不是我以为的那样"。AI 能写对代码，但它不知道你预期的是什么。

## 我现在的分工方式

AI IDE 负责的是"已知怎么做，只是要花时间"的部分——样板、配置、转换、脚本、报错粗筛。这一层它做得比人快，而且不需要监督。

人来负责的是"还不知道该怎么做"的部分——架构方向（计算放哪端）、页面结构（拆成几个 URL）、成本结构（什么会随用户量涨）、以及取舍（哪些请求不接）。

剩下的中间层——业务逻辑的实现——两边一起做：它出草稿，我负责验证边界条件。

terrific.tools 做了 12 个月才拿到第一个完整变现月，广告 174.41 美元加桌面版 125 美元。如果 AI IDE 真能"完成整个网站"，这个时间应该能被压缩。它压缩掉的是写代码那部分，压不掉的是 12 个月里那些"要不要继续做下去"的判断。

有个判断可以现在就做：把你手上正在做的项目拆一遍，看有多少工作属于"已知怎么做、只是要花时间"。这部分是 AI 能替掉的，其余的不是。比值越高，AI IDE 对你的帮助越大——工具站和技术型站点通常偏高，需要大量产品判断的项目偏低。

用 AI IDE 做完一个站的概率确实提高了，但提高到什么程度，取决于你在那三个决定上花了多少时间——而不是你生成了多少行代码。