项目辛辛苦苦Vibe Coding出来了，你知道该让它“上线”了。
可项目要怎么上线、第一步该干什么，很多人心里一点数都没有。
一天一个 vibe coding 小技巧，今天讲：从项目只有你自己能打开，到它真正具备上线条件，这一路到底该怎么走。
其实我部署篇的排序，本身就是按这条路来的——服务器、域名、备案、环境、测试、独立数据库，一期接一期，连起来就是上线前完整的一条线。
可大家是一期一期零散看的，单看每节好像都懂，真要自己从头走一遍，谁先谁后、哪件必须提前，照样心里没数。
所以这一篇，我就把这条线从头到尾给你捋一遍，顺带把每一步为什么绕不过去，也一起讲清楚。
因为要讲的东西比较多，我拆成上下两篇。
上篇讲上线之前：手续什么时候交、地基什么时候定、代码上线前怎么体检。
下篇讲上线那一刻和之后：三种部署方式怎么选、怎么把项目安全地推上去、推上去之后怎么管住它。
先看整体。
上线之前，其实有四步要走：定这个项目给谁用、把要排队的手续交出去、拍板三个地基、代码过一遍体检。
这四步全部走完，你才算真正具备上线条件。
下面一步步说。
一、第一步：先定这个项目给谁用
你让 AI 把项目跑起来的时候，它会给你一个地址，一般长这样：localhost 冒号 3000，或者 127.0.0.1 冒号 3000。
你在浏览器里输进去，项目就出来了，看着跟正式网站没两样。
但这个地址只有你这台电脑打得开。
因为 localhost 和 127.0.0.1 指的都不是某一台具体的机器，而是“我自己这台”。
所以你把它发给朋友，他输进去，浏览器找的是他自己的电脑，当然什么都没有。
从这儿往外是一层层放大的：先是同一个网络里的设备，再是公司内部这个圈子，最后是外面任何人都能打开，最后这层才叫公网。
这里插一句，因为有人会踩：网上有种叫内网穿透的工具，能临时给你这个本地地址生成一个外网能打开的链接，发给朋友看一眼确实能开。
但那个只能叫演示，不叫上线——链接是临时的，你电脑一关就没了，速度也不由你控制。
你要是拿它当上线，等于把自己的笔记本变成了全世界的服务器，家里网一断，产品就没了。
部署上线要解决的，就是把项目从“我自己能打开”，挪到“外面的真实用户能稳定访问”。
这件事之所以要第一个定，是因为它决定后面所有事的规模。
只给公司内部几个人用，很多手续和风险都用不着操心；可只要是给外面的真实用户用，服务器、域名、备案、安全，一件都躲不掉。
而它还牵着紧接着的一步：要给外面的人用，你就得有一台一直在线的机器来跑项目。
服务器你就理解成一台永远开着、永远联网、放在机房里的电脑。
自己那台笔记本顶不了，它会关机、会断网，也没有一个稳定的对外地址。
而这台机器你打算放在哪，还决定了一件更要紧的事：你上线之前，必须先去办哪几样手续。
二、第二步：要等别人审的手续，最先交出去
上线前的事，其实分两种。
一种是你自己能推的，比如地基怎么定、代码怎么测，你想快就能快。
另一种是交上去就只能等别人审的，比如备案、软著。
后面这种，才是真正决定你哪天能上线的东西，所以它必须第一个启动。
而要不要办，是接着上一步一路推下来的：用户在哪，决定你的服务器放哪；服务器放哪，才决定要不要备案。
服务器在我国大陆，又要用域名对外提供服务，那就得先办 ICP 备案，也就是大家平时说的网站备案。
它审的不是你网站做得好不好，是几样东西对不对得上：这个域名是不是你的，这台服务器是不是你在这家云厂商买的，你这个主体——个人还是公司——身份是不是真的。
说白了，就是给“这个名字、这台机器、这个人”三者之间，做一次实名登记。
这事得人工核对，所以它没法快，也没法绕。
也正因为是登记，你后面换服务器、换云厂商，这个对应关系变了，还得再走一次接入手续。
不少人换完厂商发现网站打不开，就是漏了这一步。
而不办的后果很直接：云厂商会把没备案的域名直接拦掉，用户根本打不开。
为什么是云厂商拦你？
因为备案是通过它提交的，它就是你的接入商，你的域名没备案却指向它的机器，责任在它身上。
所以它宁可先把你这个域名的对外访问关掉。
这一点很重要：你服务器好好的、程序也在跑，域名就是打不开，很多时候不是技术问题，是这道闸门没开。
备案要等多久？短的几天，长的两三个星期，第一次办通常更慢。
所以正确的做法是：你一买好服务器、确定要用域名对外提供服务，就先把备案提上去，让它在后台审，你这边接着开发。
而既然要登记的是域名和服务器的对应关系，域名就得在这一步之前先拿到手。
这里有个常见的误会：不少人觉得“我不做网站，只做小程序、只做 App，那就不用买域名了”。
这是错的。
小程序和 App 要连你自己的后端，那个后端接口按规定也得挂在已备案的域名下面，平台才认。
而域名这边，有两处会卡你的时间。
第一，在大陆的域名商买域名，通常要做实名认证，认证不通过，后面想备案根本走不了。
第二，域名买回来，它还连不上你的服务器，你得亲手把这两样牵到一起，这一步叫解析。
具体就是在域名商后台加一条记录，把你服务器的公网 IP 填进去，这种记录叫 A 记录——以后 AI 让你“去加一条 A 记录”，说的就是这件事。
而解析不一定马上生效，有时几分钟，有时要等上几个小时。
这个“要等”，很多人以为是自己配错了，其实是机制决定的。
全世界的人访问一个域名，不可能每次都跑去问一遍它的老家——老家就是你刚才配解析的那个地方，那里记着这个名字到底指向哪台机器。
所以从你家路由器，到你的宽带运营商，一路上都存了一份“这个名字对应哪台机器”的小抄，直接照着小抄回答你。
这份小抄有到期时间，没到期，它就一直照旧答。
这个到期时间是有名字的，叫 TTL，在你配解析的那个页面上就能看见，通常是 600 秒这种。
这个数你记着有用：以后你要换服务器，就提前把它调小，等新的生效以后再调回来，切换那天的等待时间会短很多。
你改完解析，只是把老家那份改了，路上这些小抄还是旧的，得等它们各自到期，重新去问一次。
所以会出现一个很坑人的现象：你自己这边已经能打开了，换成家里人的手机，还是打不开，或者打开的还是旧页面。
这跟开头那个“只有你能打开”不是一回事——那次是地址只指你自己这台机器，这次是解析已经改好了，只是路上的小抄还没到期。
这时候你要做的是等，而不是回去把解析反复改一遍，越改越乱。
手续这边还有几件特别容易漏的。
网站正式开通以后 30 天内，还要去办公安联网备案。
这两件事经常被当成一件，其实是两条线上的两个部门：ICP 备案走的是通信管理局那条线，管的是你能不能对外提供服务，所以它在开通之前；公安联网备案走的是公安那条线，管的是已经在提供服务的这个站登记到位了没有，所以它在开通之后。
前一件办完，不代表后一件就免了。
App 和小程序也各有自己的备案；上安卓应用市场，App 备案号和软著都绕不开。
软著更要趁早：最快也得小半个月到一个月，走普通流程或者中途被要求补材料，拖上两三个月很常见。
你把这几件的时间摊在一起算一下，就知道为什么它们必须最先扔出去。
备案短的几天、长的两三个星期；软著小半个月到两三个月；App 备案还要再排，上应用市场还有一轮审核。
这些时间你一天都省不掉，因为它不取决于你，取决于对面什么时候看到你这份材料。
而它们能不能和你的开发同时跑，才是你唯一能决定的事。
同时跑，你写代码的这一个月，它们在后台一起走完了；等做完了才想起来交，就是产品做好了摆在电脑里，一天都不能给人用，你干等一两个月。
同样的一个月，一个是并行，一个是纯亏——这就是这一步的全部价值。
还有一个动作比这些都更早，就是给产品起名。
因为备案要用这个名字、软著要用、上架应用市场要用、注册商标也要用，这几处的名字还得对得上。
所以起名的时候，就先去应用商店和商标网站搜一遍，看有没有重名、有没有近似的。
发现有，哪怕只差一个字，也直接换一个，别硬上。
等手续全办出去了再想改名，等于推倒重来。
三、第三步：三个地基，趁手续在审的时候拍板
手续交出去了，接下来是你自己能推的这条线。
第一件事不是写代码，是先把三个地基定下来。
这三个决定有个共同点：AI 图省事时给你的默认做法，恰好都是错的那一边；而它们全是越晚改越贵，上线以后再动，等于把地基重铺一遍。
第一个地基，数据库用哪种。
它常会给你用 SQLite，特点是整个数据库就是一个文件。
要是你做的只是个小工具、没有用户系统，用它问题不大。
可你的产品要存账号、要多人同时用，它就撑不住了。
那这个“撑不住”，到底是撑不住什么？
它整个库就是一个文件，往里写东西的时候，得先把这个文件锁上，同一时刻只允许一个人写。
你一个人测，永远发现不了问题。
几十个人同时提交，后面的就得排队，排不上的直接报错。
用户看到的就是“提交失败”，你在自己电脑上却怎么都复现不出来。
这就是它最坑的地方：它不是不能用，是人少的时候一切正常，等你真有人用了才开始出问题——恰好是你最不想出问题的那一天。
而且它还有两处天生的短板：给不了不同的人不同的账号和权限，也没法让另一台机器连过来用它。
所以你以后想把数据库单独拆出去、或者加第二台服务器，它根本没这个能力。
结论很简单：要做的是带用户系统的正经产品，一开始就让 AI 用 MySQL 或者 PostgreSQL。
这句话你现在就可以拿去用：“这个项目会有用户注册和多人同时使用，请用 MySQL，不要用 SQLite。”
一句话的事，但它省掉的是你上线以后把整个数据层搬一次家。
第二个地基，数据库放在哪台机器上。
默认情况下，AI 会把你的程序和数据库全塞在同一台服务器上。
挤在一起会带来三个后果，越往后越难受。
第一，同生共死。
这台机器要是没了，程序不怕，重新部署一遍就有了。
要命的是数据——用户、订单、聊天记录，很多时候是再也找不回来的。
第二，想升配就得全停。
哪天数据库内存不够了，你要加内存，整台机器得关机重启，网站只能跟着一起停。
第三，互相拖后腿。
它们抢的是同一份内存、同一块硬盘。
程序那边一忙，数据库跟着变慢；数据库在跑备份，网站也跟着卡。
一个出问题，另一个一起被拖下水，你查半天还分不清到底是谁的毛病。
所以这个决定的判断标准，不是数据有多大，而是你丢得起丢不起、停得起停不起。
想拆出去有两种做法：自己再备一台机器装数据库，或者直接用云厂商托管的那种数据库。
你不想自己维护，托管的那种通常更省心，安装、监控、自动备份，厂商都替你做了。
要是你现在就打算先让程序和数据库混着跑，那有一条最低要求必须做到：让 AI 帮你配好自动备份，把备份存到这台服务器之外，还要真的做一次恢复验证。
不然备份文件和数据库躺在同一台机器上，机器一出事，备份也一起没。
第三个地基，图片和视频这些文件放在哪。
如果你的项目会有大量图片、音视频，别让它们堆在自己服务器的硬盘上。
一开始就放到对象存储里去——就是云厂商专门用来存文件的那种服务，你把文件传上去，它给你一个网址，你自己的服务器上只留这个网址。
堆在自己硬盘上，会在三个地方咬你。
一是搬不动。
你哪天换服务器、或者加第二台机器分担压力，文件还躺在旧那台上，新机器看不见，用户那边就是一片打不开的图。
二是备份被撑爆。
数据库本身可能只有几百兆，图片视频动不动几十个 G，混在一起，备份就从“几分钟一次”变成“根本没法定期做”。
三是带宽全走你自己。
每个用户看图、看视频，流量都从你这台机器出去，几个人同时看，正常的页面请求也跟着卡。
还有一种更要命的做法，你得专门叮嘱 AI 别干：把图片本身塞进数据库的字段里。
那会让数据库迅速膨胀、查询变慢、备份彻底没法做。
数据库里只该存那条链接，文件本身放到对象存储去。
四、第四步：上线前的体检，顺序不能换
地基定了，代码也写完了，可它还不能直接往上推。
上线前代码这边还有三件事，而且顺序是死的。
第一件，你自己先把每个功能从头到尾走一遍，这叫功能闭环。
走的时候盯住三点。
一是别只看有没有反应，页面弹个“成功”太容易了，你得回到数据里看那条记录是不是真写对了。
二是专门走歪路，故意喂它错东西：不登录就操作、金额填成负数、把订单号改成别人的、必填项留空。
这时候你要的不是它能用，是它能拦住你，拦不住就是个口子。
三是这次没碰到的地方，也要回头点一点。
这一条叫回归，在 AI 写代码的时候格外重要。
因为 AI 改东西，很爱顺手动一动你没让它动的地方，或者为了让这处能跑，把公用的那段逻辑改了。
结果这个功能好了，另一个上周还好好的功能悄悄坏了，而你根本想不到去点它。
所以每次改完，之前能用的那几条主流程，你都得再走一遍。
而你不看代码，也有办法知道该重点走哪几条，改完就追一句：
“这次改动动了哪些公共的地方？可能连带影响哪些原来已经做好的功能？列出来，我要重新点一遍。”
它列出来的那几条，就是你这次回归的重点。
这句话我自己每次让 AI 改完东西都会问，因为它会把你自己根本想不到的那条路给点出来。
第二件，指挥 AI 再查一遍。功能要查，但重中之重是安全。
为什么不能反过来，先让 AI 查？因为你自己没走通，就说不清要它查什么，它查完你也判断不了查得全不全。
功能这边一句话带过：让它优先测一出错就会动到钱、动到权限、动到数据的地方，再把这些检查存成能一条命令重跑的测试，以后每次改完都追问一句“所有测试重跑了吗”。
安全这边我要多说两句，因为这是上线前最该做、又最多人漏掉的一步。
你自己走的那一遍，是当好人在页面上点。
可真想搞你的人根本不走你的页面。他用工具绕开页面，直接对着后端发请求，你在页面上做的那些限制，对他一点用都没有。
所以你得让 AI 换个身份：别当那个帮你写功能的助手了，让它当攻击者，把你的每个接口挨个试探一遍。
拿别人的订单号能不能查到别人的数据，普通账号能不能调管理员才能用的功能，提交的时候偷偷多塞一个字段把价格改成 0 认不认，登录接口能不能被人无限次地刷。
这些都得让它真打一遍，不能只回你一句“已检查，没问题”。
具体每一类怎么问、发现问题以后按什么顺序处理，我之前专门做过一整期，就叫《Vibe Coding 项目上线前的全方位安全审计》，提示词都能直接抄，这里就不重复了，但上线前你一定去看一遍。
这儿只留一条纪律：AI 查出问题，先让它列清单，别让它顺手就改。
一边查一边改，特别容易为了堵一个小洞，把好好的功能改坏，最后你连它动了什么都不知道。
第三件，让 AI 把那些任务做完就没用、却一直杵在项目里的代码清掉，我给它起了个名字，叫墓碑代码。
里面最危险的是临时测试接口——它们往往没有权限校验，跟着上了线就是个明晃晃的口子，别人能直接拿它操作你的数据。
清理之所以必须排在最后，是因为要等功能写完、测试通过、你自己也用过确认没问题，才动手删，删早了反而耽误事。
交代的时候还要说清楚：正式的测试代码，还有你有意留在关键功能上、准备上线后排查问题用的运行日志，都不许一起删。
那是你上线以后排查问题的保护网，图省事甩一句“把测试和日志都清了”，等于亲手把它拆了。
所以这件事的话得这么说：
“上线前请把项目里的临时接口、调试用的路由、写死的测试账号和演示数据全列出来，先别动，列成清单等我确认；正式的测试代码和关键功能的运行日志要保留。”
关键是“先列出来、别直接删”——让它一次性删干净，它顺手把有用的东西一起带走，你还不知道少了什么。
这三件走完，还剩最后一道关：把所有该查的项汇成一张总清单，临上线前从头到尾过一遍。
那张清单本身有十来项，这里只把最要紧的一条拎出来——开发和上线，必须是两套环境。
因为环境不分开，你让 AI 试错的每一下，动的都是真实用户和真实数据。
那“两套环境”到底是怎么分的？很多人第一反应是把代码复制两份，这是错的。
真正的做法是：代码只有一份，靠代码外面的一份配置，来决定它连哪个数据库、用哪把密钥、对外是哪个地址。
所以切换环境，切的是那份配置，不是改代码——同一份代码，在你电脑上连测试库，在服务器上连正式库。
需要各用各的，主要是四样。
第一，数据库。你本地那个库可以随便清空重建，正式库一条都不能乱动。
第二，各种密钥。支付、短信、AI 接口，尽量用测试用的那一套，别拿正式密钥在本地反复试——试的每一条短信、每一次调用都在真花钱。
第三，对外地址。本地就是开头说的那串 localhost，线上是你的正式域名，两边不能在代码里写死成同一个。
第四，调试开关，这一条最容易漏。
开发的时候，程序出错会给你一个很详细的报错页面，好排查。
这个页面要是跟着上了线，外人访问出错时，就能看到你的文件路径、用了什么框架、有时候连数据库信息都印在上面。
那等于把你家的结构图贴在门口，所以正式环境必须把它关掉，只往日志里记，不往页面上显示。
还有一条同样重要：那份生产环境的配置不进代码仓库，它只待在服务器上。
这条我得说重一点。
那份配置里装的是数据库密码、支付密钥、短信密钥，等于你项目的一整串钥匙。
它一旦跟着代码被推到公开的仓库上，就不是“可能被人看到”的问题了——网上有专门的程序全天在扫这种文件，几分钟就能扫到你。
而且你后面把它删掉也没用，仓库的历史记录里还留着。
配置文件叫什么名字，各种技术栈不一样，所以别自己猜，上线前追这一句：
“我这个项目的配置文件是哪个？它有没有被排除在提交之外？历史提交里有没有传过密钥？”
这是上线前最便宜的一次检查。
五、最后
上线前这一路，就是两条线拧在一起：一条要等别人审，一条你自己能推。
要等别人审的，越早交越好，晚交一天就是白等一天。
你自己能推的，先拍三个地基，再让代码过体检，顺序反了都要返工。
而这两条线上的四步，其实没有一步是要你会写代码的。
定给谁用、什么时候交手续、数据库用哪种放哪儿、上线前查哪几项——全是决定，不是技术。
而这些决定，AI 不会替你做，它只会按默认的、最省事的那条路往下走。
所以真正卡住大多数人的，从来不是不会敲命令，是没人告诉过他这些事有先后，也没人告诉过他做错了什么时候会疼。
现在你知道了，那你就比昨天多了一件事：你能在它给你默认方案的时候，问出那句“为什么”。
下篇讲后半段：三种部署方式到底怎么选，怎么把项目安全地推上去，以及推上去之后怎么管住它。
