AI把网站做出来以后,最麻烦的根本不是代码

最近越来越强烈的一个感受是，AI 把做网站这件事最难的部分，其实只解决了一半。前半段它解决得很好，后半段还经常把人劝退。

现在做网站，最容易让人上头的时刻，往往都是页面刚跑起来的时候。一个想法丢给 AI，首页有了，按钮会动了，文案也像那么回事。可一旦有人问一句：那现在别人能打开吗？气氛通常就会安静下来。因为真正把人卡住的，不是代码，而是上线。

我自己这段时间做的网站，包括投资导航在内，后面几乎都放在 Cloudflare 上。不是因为我对平台有什么信仰，而是我已经不想再为了一个小网站，先把自己训练成半个运维。买服务器、装环境、配 Nginx、折腾 HTTPS、手动发版，这套流程不是不能用，是放在现在这个节奏里，真的有点笨重。

尤其是现在大家都在用 AI vibe coding。前面几小时，你会觉得世界真美好；后面一碰部署，立刻像被人从创作模式拽回机房值班。这个落差非常大。所以我现在看一个部署方案，第一反应不是它技不技术流，而是它会不会把人劝退。Cloudflare 在这件事上，确实很占便宜。

现在做一个新站，流程其实很简单。先让 AI 把第一版页面和基础功能搭出来，在本地跑一遍，确认至少能正常打开；然后我会把代码整理一下，推到 Github。到这一步，网站本质上还只是“躺在我电脑里”的东西，但至少已经有了一个稳定版本，后面接部署就会顺很多。

接下来直接去 Cloudflare 里建项目，把 Github 仓库接进去。如果只是网站前台，通常优先用 Pages。原因很现实，就是省心。代码一推，自动构建、自动上线，默认域名、HTTPS、CDN、基础防护这些东西，基本都在一条链路里。不用东拼西凑好几个服务，再靠脑子记住它们怎么绑在一起。

中间最容易卡住的，反而不是 Cloudflare 本身，而是那些看起来很小的地方：构建命令到底填什么，输出目录到底写哪个。这个项目该填 `npm run build`，还是别的？输出目录是 `dist`、`build` 还是 `.next`？以前很多人到这里就开始头大。我现在的做法很偷懒，也很有效，就是把 `package.json`、目录结构、报错截图一起丢给 AI，让它按项目实际情况告诉我怎么填。说实话，它在这种事情上，通常比我自己满网翻教程更快。

再往后就是环境变量。API key、接口地址、数据库连接这些东西，现在不会再写死在代码里，而是直接放到 Cloudflare 的设置里。这个动作看起来不性感，但真的能少掉很多后患。因为上线从来不是一次性的，你今天发第一版，明天大概率还会改接口、换 key、补测试环境。配置和代码搅在一起，后面只会越来越乱。

域名这件事，现在也没以前那么着急。以前总觉得，必须把独立域名绑好，网站才算真的上线。后来发现这很容易本末倒置。网站都还没跑通，就先沉迷于挑名字、看后缀、做邮箱，最后特别像在装修门头，店还没开。现在通常会先用 Cloudflare 给的默认地址把网站跑起来，能访问了，再慢慢处理域名。

还有一个很现实的点，是它把很多零碎活一起接住了。比如图片、缓存、访问数据、基础防护，这些东西单拎出来都不算大事，但你真要自己一项一项凑，时间就没了。我现在手上的网站，部署、图片存储、流量观察，基本都在 Cloudflare 体系里。不是说别家不行，而是我懒得每做一个站，就再重新组一次基础设施。

当然，我也不想把它写成什么赛博活佛。Cloudflare 不是万能药。它特别适合轻量网站和很多早期产品，但如果项目本身很重，尤其是后端服务复杂、数据库压力大、处理链路很长，那就不能指望它一把梭。免费版也是一样。我的感觉是，早期站点大多够用，至少够把想法先验证出来；但它到底够不够，不是只看访问量，还要看请求有多重、图片流量大不大、函数跑得多不多。这个边界，说到底还是要结合项目本身看。

所以我现在为什么会这么愿意推荐 Cloudflare？不是因为它让部署这件事彻底消失了，而是因为它把部署从一件很容易把人搞烦的事，压缩成了一件还能继续做下去的事。这个差别其实很大。很多网站不是死于没人用，而是死于根本没被发出去。

大概就是：AI 已经把“做出来”这一步推得很快了，部署就别再用老办法给自己加难度。现在做完一个网站，脑子里默认接的下一步，不是去买服务器，而是去看怎么接 Cloudflare。因为对我们来说，先把东西发出去，比把部署姿势弄得很专业更重要。

这也是我最近特别想分享这件事的原因。很多人以为自己卡在技术，其实卡在的是最后那点基础设施的心理负担。一旦这层东西被拿掉，网站上线没有想象中那么难。至少对我来说，Cloudflare 现在就是那种很适合拿来把事先做成的工具。不是最浪漫，但真的很有用。