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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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