每个 PR 一个可访问的链接：vibe 项目的预览环境实战

用 AI 写代码之后，你有没有遇到过这种对话："这个新功能我做好了，你看一下。"——"怎么看？""你把分支拉下来本地跑一下。"——"……算了你直接合并吧。"

这就是没有预览环境的 vibe 项目的日常：代码写得飞快，验证却靠"信任"。更糟的是，你想让朋友提意见、让客户确认需求、让自己在手机上看一眼真实效果，每一次都要走"合并→部署到生产→发现有问题→回滚"的惊险流程。

预览环境（preview deployments）解决的正是这个问题：每个分支/PR 自动部署出一个带独立 URL 的完整环境，代码 review 的时候，点开链接就能看、能点、能测。这篇指南讲透前端预览、后端预览、数据库分支、环境隔离和成本控制，让"每个 PR 一个链接"成为你项目的标配。

先建立直觉：预览环境不是 staging

很多人把 preview 和 staging 搞混。Staging 是"一个"长期存在的类生产环境，所有待上线代码都在里面排队；而 preview 是"每个 PR 一份"的、用完即焚的临时环境。PR #42 和 PR #43 各有一个独立链接，互不干扰；PR 合并或关闭后，环境自动销毁。

这个区别决定了用法：staging 回答"所有改动合在一起有没有问题"，preview 回答"这个改动本身长什么样"。对 vibe coder 来说，后者重要得多——AI 一天能给你吐 10 个 PR，你不可能每个都拉到本地跑，但你可以每个都点开链接看 30 秒。

前端预览：零配置，Vercel/Netlify/Cloudflare Pages 开箱即用

前端是预览环境最成熟的一环，基本零配置：

• Vercel：GitHub 仓库连上之后，每个 PR 自动生成 *.vercel.app 预览链接，并在 PR 页面评论里贴出来。环境变量可以按 environment 区分（Production / Preview / Development），给 Preview 单独配一套。
• Netlify / Cloudflare Pages：同样的 Deploy Previews 机制，Cloudflare Pages 对个人项目免费额度很慷慨。
• 密码保护：预览链接默认是公开的——任何人拿到 URL 都能看。如果你的 PR 里有未发布的功能，记得开 Deployment Protection（Vercel）或 Access Policy，给预览加一层密码。别让"未发布的新功能"变成"公开的 URL"。

实战建议：把预览链接当成 PR 模板的一部分。在 PR 描述模板里加一行"预览链接："，让 AI agent 提交 PR 时自动填上。review 的第一动作从"看 diff"变成"点链接"，很多 UI 问题在 diff 里根本看不出来。

后端预览：Railway / Render / Fly，按 PR 起服务

纯前端预览只解决了一半问题——你的 API 改了怎么办？几个主流 PaaS 都支持按分支部署：

• Railway / Render：开启 PR 自动部署后，每个 PR 起一套独立的服务实例，带独立域名。后端改了接口，前端 preview 直接指过去联调。
• Fly.io：用 fly deploy 配合 GitHub Actions，每个 PR 部署到独立的 app（命名如 myapp-pr-42），PR 关闭时自动销毁。

这里有个关键决策：后端 preview 要不要连真实数据？答案是：连，但连的是"分支数据"，往下看。

最难的一环：数据库分支

预览环境最容易翻车的地方是数据库。三个常见错误姿势：① 所有 preview 共用生产库——一个 PR 的 migration 把生产数据搞乱；② 每个 preview 连同一个 staging 库——PR 之间互相污染；③ 干脆不连库——preview 跑一半功能是坏的。

正确姿势是数据库分支（database branching），每个 PR 一份独立的数据：

• Neon：Postgres 分支是它的招牌能力，neon branches 按 PR 创建分支，秒级 copy-on-write，免费额度对个人项目够用。GitHub Actions 里 PR 打开时建分支、PR 关闭时删分支，整套可以自动化。
• Supabase：也有分支能力，但注意它的分支功能在付费档位，个人免费项目要算好账。
• 穷人版方案：如果不用分支数据库，给每个 PR 在共享 Postgres 里建独立 schema（pr_42），migration 跑到自己的 schema 里。隔离性不如真分支，但零成本、零新依赖，对 side project 完全够用。

一条铁律：preview 环境的数据库连接串，永远不许指向生产库。把这条写进你的 CI 检查里——让 agent 在部署脚本里加一行断言，连接串包含 prod 就直接失败。靠自觉不如靠拦截。

环境变量隔离：preview 用自己的钥匙

每个 preview 是一套完整环境，意味着它需要自己的第三方凭证：

• 支付走 Stripe test mode 的 key，千万别把 live key 配到 preview 里——测试支付跑到真实扣款，哭都来不及。
• AI 模型 API 用单独的 key 或子账号，方便按 PR 统计 token 消耗，也防止 preview 的调试流量污染生产用量统计。
• OAuth 回调地址：每个 preview 域名都要在 GitHub/Google OAuth 应用里加回调白名单，或者配一个通配符测试应用。

管理技巧：用 .env.preview 模板 + CI 注入 secret 的方式，而不是把 preview 的 key 写死在仓库里。Vercel / Railway 的 environment 级变量就是为这个设计的。

PR 评论机器人：让链接自己找上门

预览环境建好了，没人点开等于白建。标准动作是让 CI 在 PR 里自动评论：

# GitHub Actions 片段：PR 打开时评论预览链接
- name: Comment preview URLs
  uses: actions/github-script@v7
  with:
    script: |
      github.rest.issues.createComment({
        issue_number: context.issue.number,
        owner: context.repo.owner,
        repo: context.repo.repo,
        body: `🔍 Preview ready:\n- Frontend: https://myapp-pr-${context.issue.number}.vercel.app\n- API: https://myapp-pr-${context.issue.number}.fly.dev`
      })

Vercel / Netlify / Railway 自带这类评论，Fly 这类需要自己配的就用上面的片段。进阶玩法：评论里顺手带上"这个 PR 改了什么"的 AI 摘要——让 agent 在 CI 里生成一句话 changelog，review 的人点开链接之前先知道该看哪。

成本控制与自动清理：别让 preview 变成僵尸账单

Preview 是"用完即焚"的，焚不掉就会变成钱。三个控制点：

• 自动销毁：Vercel / Netlify 的 preview 随 PR 关闭自动清理；自己搭的（Fly app、Neon 分支、独立 schema）必须在 CI 里写 on: pull_request closed 的清理 job。这是整篇指南里最容易被 agent 漏掉的一行，review 时重点检查。
• 配额上限：给 preview 设并发上限（比如同时最多 5 个），超了就复用最早的。Neon 分支数、Fly 的机器数都有免费额度，超了就开始计费。
• 定期巡检：每周跑一次脚本，列出所有超过 7 天没更新的 preview 资源，手动确认后删除。自动化总有漏网之鱼，人工巡检是最后一道网。

讲清边界：preview 不是灰度发布

本站之前发过《别把新版本一把梭哈：vibe 项目的灰度发布与回滚实战》，有读者可能会问：preview 和 canary（灰度）是不是一回事？不是，泾渭分明：

• Preview：代码合并之前，给开发者、reviewer、客户看的验证环境，流量是"人"不是"用户"，目标是发现问题。
• Canary：代码合并之后，在生产环境里按比例放量的发布策略，流量是真实用户，目标是控制爆炸半径。

一句话：preview 回答"这个改动对不对"，canary 回答"这个改动上线后稳不稳"。两个都要做，但解决的是流水线上先后两个阶段的问题。先有 preview 挡住明显的错，再有 canary 兜住隐蔽的雷。

上线 checklist：发布前逐项打勾

• □ 前端每个 PR 自动出预览链接（Vercel/Netlify/Pages 三选一）
• □ 预览链接开了密码保护（有未发布功能时）
• □ 后端每个 PR 有独立服务实例（Railway/Render/Fly）
• □ 数据库按 PR 分支/独立 schema，连接串永不指向生产库（含 CI 断言）
• □ Preview 环境变量独立：Stripe test key、独立的 AI API key、OAuth 回调白名单
• □ PR 自动评论贴出前后端预览链接
• □ PR 关闭时自动销毁所有 preview 资源（CI closed 事件）
• □ preview 并发配额上限已设，超 7 天僵尸资源每周巡检

最后说说为什么这篇指南值得你认真做：AI 写代码的速度越快，"验证"就越成为瓶颈。你一天能让 agent 吐 10 个 PR，但你的眼睛一次只能看一个。预览环境的本质，是把"验证"从"拉分支本地跑"这种重动作，降级成"点开链接看 30 秒"这种轻动作。当生成成本趋近于零，验证成本就决定了你的迭代速度——而每个 PR 一个链接，就是把验证成本打到最低的那套基建。