不会Linux也能部署Vibe Coding？AI Agent分阶段协助上线指南

很多人用 AI 做出了一个能运行的产品，却在“发布到公网”这一步停住了。原因通常不是不会写代码，而是不知道服务器、DNS、进程、环境变量和证书之间怎样连接。面对一屏命令和报错，最容易出现的结果是让 AI 随便改配置，直到页面暂时能打开，却留下没有备份、密钥泄露或重启后失效的问题。

AI Agent 可以显著降低操作门槛，但它不是云平台账号的所有者，也不能替用户承担安全责任。更稳妥的工作方式是：让 Agent 负责观察、规划、执行和记录；用户负责确认目标、登录、授权、密钥和最终验收。

一、先把“让 AI 部署”改写成可验收任务

不要只对 Agent 说“帮我把网站部署上线”。这句话缺少平台、项目类型、域名、运行命令和验收标准，Agent 只能猜。

先准备一张部署任务卡：

项目目标：把当前目录的产品部署到公网
代码位置：当前工作区
部署平台：一台 Ubuntu 云服务器 / 其他平台（填写实际平台）
域名：example.com
项目类型：静态站点 / Node 服务 / 前后端分离
本地启动命令：npm run dev
生产构建命令：npm run build
生产启动命令：npm run start（如有）
构建输出目录：dist（如有）
需要的服务：数据库、对象存储、邮件服务（按实际填写）
不能做的事：不得删除数据，不得提交或打印密钥，不得修改业务逻辑
验收标准：HTTPS 可访问、刷新子路径不 404、核心功能完成一次闭环

这张任务卡的作用不是让非技术用户学习术语，而是把“成功”从一句模糊愿望变成几个可以检查的结果。项目类型、命令和输出目录都必须以仓库实际内容为准，不能照抄别人的 package.json。

二、第一轮只让 Agent 做检查

部署前先让 Agent 只读检查项目，不要一上来就执行安装或删除命令。可以使用下面的提示词：

请先只检查当前项目，不要修改文件，不要安装依赖，不要部署。
请输出：
1. 使用的框架、Node 版本要求和包管理器；
2. package.json 中的 build/start 脚本；
3. 构建输出目录；
4. 所有环境变量名称，并标出哪些可能是敏感信息；
5. 是静态站点、SSR，还是包含独立后端；
6. 部署前还缺哪些账号、权限和平台信息。
每个判断都引用对应文件路径和行号；无法确认的内容标记为“待确认”。

检查结果应该能回答三个问题：本地项目在生产环境如何启动、需要哪些外部服务、哪些值不能进入前端。若 Agent 说不清楚 build 产物或启动方式，先补充项目文档或让它在本地执行一次构建，再进入下一步。

本地构建是第一道门槛：

npm ci
npm run build

构建通过后，用本地预览命令检查生成结果。不同框架的预览命令不同，不要把开发命令当作生产命令。Agent 可以根据 package.json 选择命令，但应先把命令告诉你，再执行。

让 Agent 先产出一份部署计划

只读检查结束后，可以让 Agent 把结果整理成一份计划。提示词可以这样写：

基于刚才的检查结果，生成部署计划，不要执行。
计划必须包含：
1. 目标架构和请求链路；
2. 需要在本地执行的命令；
3. 需要在服务器执行的命令；
4. 需要我在云平台或域名平台手动确认的步骤；
5. 每一步的预期输出和失败信号；
6. 需要备份的文件和数据；
7. 发布失败时的回滚方法。
将不确定的内容列入“待确认”，不要用猜测补全。

读计划时，重点检查它有没有把静态站点和动态应用混为一谈，有没有把数据库、上传文件和前端代码当成同一种部署对象，有没有把密钥直接写进命令行。计划里如果出现“删除旧目录”“重置数据库”“开放所有端口”等高风险动作，应要求 Agent 改成备份后执行，或先给出只读检查。

三、让 Agent 按阶段执行，而不是一次性接管

部署任务适合拆成五个阶段。每阶段完成后保存输出，再决定是否继续。

阶段 1：准备服务器

让 Agent 给出服务器初始化计划，至少包括系统版本、普通用户、SSH 方式、开放端口、应用目录和日志位置。用户可以授权它执行安装命令，但要保留云平台控制台和 SSH 会话作为观察窗口。

可接受的最小结果是：服务器能登录，Nginx 或应用运行时已经安装，防火墙只开放业务所需端口。一般网站只需要 80、443 和管理用 SSH 端口；数据库端口不应因为“方便调试”而直接暴露公网。

阶段 2：准备域名

让 Agent 先输出需要添加的 DNS 记录，不要让它根据猜测修改域名：

请根据当前部署目标生成 DNS 变更表，只输出计划，不执行修改。
列出主机名、记录类型、目标值、用途、验证命令和回滚方式。
如果服务器 IP 或平台提供的 CNAME 尚未确认，请明确标记缺失信息。

用户确认后再执行变更。DNS 记录的修改通常发生在域名服务商控制台，Agent 可能只能给出指导，除非你明确提供了可用的管理接口或浏览器授权。变更后使用 Resolve-DnsName、dig 或平台提供的检查工具验证，不要仅凭控制台显示“已保存”判断成功。

阶段 3：部署应用

静态项目的核心动作是上传构建目录并配置 Web 服务器。动态项目则要额外配置依赖、环境变量、进程管理和反向代理。可以让 Agent 执行，但要求它先报告：

• 将修改哪些服务器文件；
• 将安装哪些软件包；
• 将监听哪个本地端口；
• 哪些环境变量需要用户提供；
• 失败时如何停止、恢复和回滚。

让 Agent 使用部署目录而不是临时目录。部署成功后，保留一份带时间戳的构建产物或提交版本，例如：

/srv/releases/2026-07-29-001/
/srv/current -> /srv/releases/2026-07-29-001/

这种目录结构不是所有平台都必须采用，但它能让回滚目标明确。任何“直接覆盖线上目录”的方案，都应该先确认是否有备份。

两条可直接使用的执行提示词

对于静态站点，可以在确认计划后使用：

请按已确认的计划部署当前项目的静态产物。
先执行 npm run build，并报告输出目录和文件数量；
再将构建产物上传到新的版本目录，不要覆盖上一版；
配置 Web 服务器时保留现有 HTTPS 和其他域名；
部署后只执行 nginx -t、HTTP/HTTPS 请求、首页和前端子路径刷新检查；
任何删除、域名变更、证书替换或需要我登录的步骤先暂停并说明原因。

对于 Node 后端，可以使用：

请先检查项目的生产启动脚本、监听端口和环境变量名称。
在服务器创建独立应用用户和版本目录，安装与 lockfile 匹配的依赖；
应用只监听 127.0.0.1，不要把数据库端口暴露到公网；
使用 systemd 或项目已有的进程管理方式启动，并配置失败自动重启；
先从服务器本机调用健康检查，再由 Nginx 转发到域名；
不要输出任何密钥值，部署失败时保留旧版本并给出回滚命令。

这两段提示词的重点是“分阶段”和“暂停条件”。Agent 不是越少停顿越好；涉及账号、数据和线上流量时，停下来让用户确认本身就是正确行为。

阶段 4：配置 HTTPS

HTTPS 申请前要先确认域名已经解析到正确地址、服务器的 80 或 443 端口可达、Nginx 配置中的域名与证书申请域名一致。让 Agent 先运行：

sudo nginx -t
curl -I http://example.com

再执行证书工具。证书申请和自动续期属于高影响操作，Agent 可以执行命令，但用户应查看申请的域名、证书到期时间和续期测试结果。Certbot 的官方文档是核对参数和续期方式的依据：Using Certbot。

阶段 5：执行验收

不要把“命令退出码是 0”当作产品上线。让 Agent 按验收表逐项执行：

请执行线上验收，不要修改配置。
检查：DNS、HTTP/HTTPS、首页、前端子路径刷新、静态资源、核心 API、登录、数据写入、图片上传、应用进程、Nginx 状态、证书续期测试。
每项输出：通过/失败、实际结果、证据命令、失败时的下一步排查方向。

浏览器端还要人工看一次。重点检查控制台是否有混合内容、跨域、资源 404、接口 401/403 或前端把敏感环境变量打包进去。

部署完成后留下交接记录

AI 帮你完成一次部署，并不代表下一次还能凭记忆复现。建议让 Agent 最后生成一份不含秘密的交接记录：

请生成 DEPLOYMENT.md，只记录部署事实，不记录密钥、Cookie、私钥和完整数据库连接串。
包含：项目提交、构建命令、生产启动命令、服务器系统、应用目录、域名、Nginx 配置位置、systemd 服务名、日志命令、健康检查 URL、备份位置、回滚步骤和待补齐事项。
对每项标注“已验证”或“未验证”，并附验证日期。

交接记录至少要让另一个人回答这些问题：网站由什么进程提供服务？重启后会不会自动恢复？日志在哪里？当前版本是什么？上一版在哪里？域名和证书由谁管理？数据库和上传文件如何恢复？如果这些问题答不上来，部署仍然只是一次临时演示。

四、哪些事情不能直接交给 AI

1. 账号登录和授权

扫码、短信验证、二次验证和云平台授权必须由账号所有者完成。不要把一次性验证码发进聊天，也不要让 Agent 代替你保管长期访问令牌。授权完成后，应检查授权范围和有效期。

2. 生产密钥

数据库密码、对象存储密钥、支付密钥和第三方 API Key 不应写进前端文件、提交到 Git 或直接粘贴到对话里。推荐使用服务器环境变量、平台密钥管理或部署平台的加密配置。Agent 可以告诉你变量名和配置位置，但不需要知道真实值。

3. 删除、迁移和升级

下面这些命令要先解释、先备份、后执行：

rm -rf
DROP DATABASE
docker compose down -v
npm audit fix --force

它们并不一定错误，但可能删除数据、改变依赖主版本或影响现有服务。让 Agent 说明目标、影响、备份位置和回滚命令，然后由用户确认。

五、遇到报错时怎样提问

只把一句“部署失败了”发给 Agent，信息通常不够。一次有效的排错请求应包括：

部署目标：example.com
最后一个成功步骤：Nginx 配置检查通过
失败步骤：申请证书
完整错误：粘贴原始输出，不要删掉错误码
最近修改：新增了 www.example.com 的 DNS 记录
限制：不要删除现有证书，不要修改业务代码
请先判断问题属于 DNS、端口、权限、配置还是证书验证；
然后给出只读检查命令，解释预期结果，再给出最小修复动作。

错误上下文越完整，Agent 越容易定位问题。日志中如果包含令牌、Cookie、邮箱或用户数据，应先脱敏。不要为了让错误消失而关闭 HTTPS、放宽数据库权限或把所有端口开放到公网。

六、参考资料与边界

Nginx 官方文档可用于核对静态文件服务和反向代理配置：Nginx Documentation。Let's Encrypt 官方文档用于理解证书的签发与续期：Let's Encrypt Documentation。如果网站使用中国大陆服务器，应按实际业务在工业和信息化部备案系统核对要求：ICP/IP 地址/域名信息备案管理系统。

Agent 适合处理重复的命令执行、文件检查、日志归纳和配置草拟，但不能替你判断合规责任、数据重要性或账号授权边界。平台差异也很大：托管平台可能隐藏服务器和 Nginx，VPS 则需要自己维护补丁、备份和监控，不能把本文的命令跨平台照抄。

结论

不会 Linux 并不意味着不能上线产品，关键是把部署拆成检查、计划、执行、验证和回滚五类动作。AI 可以帮助你理解命令、读取日志、生成配置并完成大量机械操作，但每次涉及域名、权限、密钥、数据和删除时，都应保留人工确认。

一个合格的部署结果不仅是浏览器能打开首页，还应该知道它运行在哪台服务器、由哪个进程提供服务、域名如何解析、证书如何续期、数据如何备份，以及失败时如何恢复。把这些信息记录下来，下一次上线才会真正变得简单。