# AI现在到底能不能独立完成一个网站？

URL: https://caijiao.org/posts/178
Source: docs/posts/178.md
Description: 拆成三个可验收的子问题就有答案了：决定做什么它做不了（Cakedesk 2025 年 44 个功能请求只完成 13 个），改到能上线它能做一半，上线后自己发现问题它基本做不到。JetBrains 调研里 90% 的人每周用 agent，恰恰说明人还得在场。

"独立完成一个网站"这句话没法直接回答，因为它把三件难度完全不同的事捆在了一起。**决定做什么**、**改到能上线**、**上线后自己发现并修掉问题**——这三件事的自动化程度差得很远，混在一起问，得到的答案永远是"看情况"。

我的答案是：一件做不了，一件做一半，一件基本做不到。

动手之前我给三件事各定了验收条件：给一份真实的需求清单，看它能不能排出顺序；给一个跨栈仓库，看它能不能改到可以直接发布；故意制造一个线上异常，看它能不能定位到根因。

## 决定做什么这件事，实测下来它完全不参与

这一点我没有一开始就信。为了验证，我把那份真实的需求清单原样丢给它，只问一句"按什么顺序做"。

它给的顺序很整齐，理由也写得通。问题在于那个排序的依据全是"实现难度"——先做容易的。**而真人排顺序的依据是"哪件事能让付款的人留下来"**，实现难度在这套标准里是最不重要的那个变量。

最能说明问题的是 Cakedesk。作者 Max Schmitt 是德国的自由职业者，一个人做这款 Electron + React + Node.js 的桌面应用，一次性付费 €69、没有订阅，2025 年卖出 239 份新授权，毛收入约 €16000。

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

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

同年他收到 44 个功能请求，完成了 13 个。

那 44 个请求全部写出来这件事，AI 现在就能做，大概一天就能堆完。难的是那 13 个是怎么选出来的——哪个请求来自已付费用户、哪个只是路过的人随口一提、哪个看起来小但会把 Electron 的打包链路拖垮。**排序的依据不在代码里**，而在"提这个需求的人值多少钱、他在什么场景下卡住"这些信息里，而这些信息 AI 摸不到。

## 改到能上线：能，但卡在两处工程细节

跨栈仓库是最容易看出边界的。Electron + React + Node.js 这种三层结构，AI 生成单个模块的速度确实快，出问题的是两层之间的接缝。

一处是本地状态持久化。Electron 主进程里塞个单文件数据库是最省事的方案，但 AI 生成的代码基本不考虑写并发和崩溃后的恢复——多线程写要靠 WAL 兜住，备份就是关机时复制一个文件。这些取舍在[轻量存储](/sqlite/)里能系统过一遍，比事后救火划算。

另一处是打包和分发。桌面应用跑起来和能发出去是两件事：asar 打包会把原生模块的路径搞乱、`node_modules` 会被整包塞进镜像导致体积翻几倍、CI 上签名的环境变量顺序错一步就出不来产物。[Docker 部署](/docker/)里那套多阶段构建的思路，AI 生成版本几乎从来不会主动用。

这里还有一处不属于任何单一层：跨平台环境下的资源路径。Electron 打包之后的安装目录结构和开发环境完全不同，`__dirname` 指到的位置取决于安装包有没有解开。它写代码时跑的是开发环境，写出来的路径在生产包里几乎必然出错，而这类错误在本地一次都不会出现——这正是它们能一路活到用户手上的原因。

这两处的共同点是：**它们都不属于"功能"，而属于"让功能在别人的机器上成立"**。AI 的注意力集中在功能上。

## 上线之后能不能自己兜住，基本不能

这一项决定了我不会把一个站完全托管给它。用户在 Safari 上某个版本点了没反应、某搜索引擎某天没抓某个目录、某个表单在特定输入下 500——这些信号的共同点是**得有人先看一眼才知道它是个信号**。

JetBrains 的调研里有一个数字：90% 的专业开发者每周至少使用一次 AI 编码 agent。普及率已经高到这个程度，如果"上线后自动运营"成立，这个数字旁边应该躺着一堆无人值守的产品。实际上没有。大家在用它写代码，而且还得自己盯着线上。

## 三件事里，第三件最容易看清楚差别

同样是"网站某处不动了"，人和 AI 各能做到哪一步，摆在一起看就很清楚。

用户在某个浏览器版本上点了导出没反应。它能做的是读懂你给的报错栈，推测三四种可能成因，给出每一种的验证方法。这部分通常有用。

它做不到的是：**这条反馈来自一个还没付费的试用用户，而这个导出功能在正式授权里很常用**——要不要优先修，取决于提反馈的人是谁。这类信息在邮件往来和付款记录里，模型看不到。

前面那个 90% 的比例，恰恰是这一点的注脚：几乎没有哪位开发者把"判断先修哪个"也交了出去。不是能力问题，是信息来源问题。

而网站某处不动了，十有八九不是服务挂了，是某段前端逻辑在特定条件下抛了异常——这类问题的定位过程需要读运行时状态、复现路径和调用栈，具体做法可以参考[前端调试](/javascript/)里的排查顺序。

## 边界落在哪：它是产能，不是判断力

一个人现在可以维护比三年前大得多的代码面——这是真的变了。但变大之后，瓶颈从"写不完"挪到了"不知道先写哪个"，而后者才是决定项目生死的地方。

我对自己的分工是这样的：需求排序、选择克制、看线上异常这三件事自己来；把选中的需求翻译成代码、补测试、写迁移脚本这三件交给它。

---

*Cakedesk 数据来自作者 Max Schmitt 公开的 2025 年度总结；开发者使用率数据来自 JetBrains 开发者生态调研。*