如何为您的应用设置预发布（Staging）环境

要设置预发布环境，请将应用的第二份副本部署到独立的私有网址，为它配置独立的数据库和测试 API 密钥，并尽可能使其配置与正式环境保持一致。然后，每一项重要改动都先发布到预发布环境，走一遍关键流程，确认无误后再发布到正式环境。

如果您对这个概念还不熟悉，请先阅读什么是预发布环境。本指南侧重实际的搭建步骤，面向的是使用 AI 工具构建应用的人，而不是专业运维团队。

开发、预发布与正式环境

大多数小型应用需要三个环境，即使第一个环境只是您构建工具中的预览：

预发布环境的意义在于，它的行为与正式环境一致 —— 相同的代码、相同的技术栈、相同类型的配置 —— 但在那里出现的错误不会伤害任何人。

第 1 步：确定预发布环境必须与什么保持一致

只有当问题能在正式环境出现之前就在预发布环境中暴露时，预发布环境才有用。请保持以下各项一致：

• 相同的代码，并以相同的方式发布。
• 相同的技术栈和版本：框架、运行时、数据库类型。
• 相同类型的配置：相同的环境变量名称，但使用测试值。
• 相同的服务：如果正式环境同时有网页应用和 API，预发布环境也应当两者都有。

两者在规模（使用较小的机器没有问题）和数据上可以不同。

第 2 步：创建副本

最简单的做法：将同一项目再部署一次，使用不同的网址，例如 staging.yourapp.com 或 yourapp-staging.example.com。

具体做法取决于您的托管平台：

• 提供内置预览或预发布部署功能的平台，可以为 Git 分支自动创建预发布环境。
• 不提供该功能的平台：使用同一份代码创建第二个应用或项目，并单独部署。
• 代码存放在 Git 中：保留一个 staging 或 main 分支，并将其部署到预发布环境；正式环境则从发布版本部署。请参阅如何在 AI 构建的应用中使用 Git。

第 3 步：为预发布环境配置独立数据库

这一步能保护您。如果预发布环境与正式环境共用一个数据库，那么一个删除记录的测试就会删除真实的记录。

• 为预发布环境创建单独的数据库。
• 用种子数据填充它：由 AI 为您生成的、看起来真实的虚假记录。
• 如果确实需要正式环境数据的副本，请先删除或打乱其中的姓名、邮箱以及任何个人信息。

编写一个种子脚本，为空数据库填充逼真的测试数据：20 位客户、50 个处于不同状态的订单，以及两个管理员用户。使用明显虚构的姓名和 example.com 邮箱地址。

在信任这套配置之前，请确认每一份副本分别连接到哪个数据库。直接询问：

这个应用连接的是哪个数据库，这个设置来自哪里？请告诉我变量名，不要显示密码。

第 4 步：使用测试密钥和独立的配置

在预发布环境中，所有与外部服务通信的部分都应使用测试凭据：

• 支付使用测试模式（例如 Stripe 的测试密钥），确保不会真正扣除任何银行卡的费用。
• 邮件发送到沙盒，或只发送到您自己的地址，确保客户永远不会收到测试邮件。
• AI 及其他付费 API 使用单独的密钥，并设置较低的消费上限。
• Webhook 指向预发布环境的网址，而非正式环境。

两个环境中的变量名称保持一致，只更改其值。这样代码无需知道自己运行在哪个环境中。关于这一点的更多内容，请参阅如何妥善保管 API 密钥。

第 5 步：保持预发布环境私密

预发布环境不应对公众开放：

• 将其置于登录、密码保护之后，或仅允许团队邮箱名单中的人员访问。
• 通过 noindex meta 标签或 X-Robots-Tag 响应头，阻止搜索引擎收录。
• 不要在公开网站上链接到它。
• 让它看起来与正式环境有所不同：例如带有醒目颜色的「STAGING」横幅，可以防止您在错误的标签页中进行测试。

当环境变量 APP_ENV 为 "staging" 时，在每个页面顶部添加一条醒目的黄色横幅，内容为「STAGING — 仅限测试数据」。在这种情况下，同时添加 noindex meta 标签。

第 6 步：建立发布流程

只有每次都使用预发布环境，它才能发挥作用。一个简单的流程如下：

1. 在开发环境中进行修改，并在预览中检查。
2. 将修改发布到预发布环境。
3. 走一遍关键流程：注册、登录、主要功能、支付，以及此次修改涉及的任何内容。
4. 如果出现问题，修复后再次发布到预发布环境。
5. 将同一版本发布到正式环境。
6. 快速检查正式环境：同样的流程，简要走一遍。

请将关键流程写成一份简短的测试脚本。应包含哪些内容，请参阅如何在上线前测试您的应用。

第 7 步：谨慎处理数据库变更

数据库结构的变更 —— 例如添加列或重命名表 —— 正是预发布环境发挥价值的地方。

• 所有结构性变更都先在预发布环境中执行。
• 检查现有数据是否完好保留，而不只是检查新功能能否运行。
• 在正式环境执行相同变更之前，先备份正式环境的数据。请参阅如何备份您的应用数据库。
• 优先选择只添加而不重命名或删除的变更，这样在回滚时旧版本仍然可以正常工作。

示例提示词

如果我们在正式环境中执行这次数据库变更，现有数据会发生什么变化？是否有任何内容会被删除或重命名？

将所有与环境相关的设置 —— API 地址、密钥、邮件发件人、网站自身的地址 —— 改为从环境变量读取，并在预发布环境和正式环境中使用相同的变量名。列出这些变量。

根据这个应用的功能，写一份简短的清单，列出每次发布前我应该在预发布环境中测试的流程。

常见错误

• 共用数据库。 这是危害最大的错误。预发布环境必须始终拥有自己的数据库。
• 在预发布环境中使用正式密钥。 会产生真实的扣费，并向真实客户发送真实邮件。
• 预发布环境与正式环境产生偏差。 版本或设置不同，预发布环境就无法再发现问题。
• 公开且可被索引的预发布网站，它会与您的正式网站一起出现在搜索结果中。
• 对「小改动」跳过预发布环境。 小改动同样会引发故障。
• 在错误的标签页中测试。 醒目的横幅可以解决这个问题。

检查清单

• 预发布环境运行与正式环境相同的代码、技术栈和服务。
• 预发布环境拥有独立的数据库，使用测试数据或经过脱敏的数据。
• 支付、邮件和付费 API 在预发布环境中使用测试密钥。
• 各环境的变量名称一致，只有值不同。
• 预发布环境置于登录或密码保护之后，并且未被索引。
• 处于预发布环境时，页面会显示横幅提示。
• 每次发布都先进入预发布环境，并附有需要检查的流程清单。
• 数据库变更先在预发布环境执行，发布前已备份正式环境数据。

在 Mythex 上设置预发布环境

Mythex 的发布功能为每个应用提供一个线上网址，没有单独的预发布环境开关。实际上您有两种选择：

• 将预览作为发布前的检查。 每个项目都运行在私有云工作区中，并提供实时预览。/test 会让智能体像用户一样点击操作，分享链接则可以让客户或团队成员在不发布的情况下审阅预览。请参阅预览与代码。对于许多个人项目来说，这已经足够。
• 将第二个项目用作预发布环境。 在 Pro 版中，导出项目并将其导入到一个新项目中，为该项目配置独立的数据库和测试密钥等机密信息，并使用其自己的标识（slug）发布。在发布正式项目之前，先发布到这个项目。

无论采用哪种方式，在进行任何有破坏性的测试之前，请先询问智能体预览和已发布的应用分别使用哪个数据库，并使用检查点来回滚有问题的变更。关于更广泛的应用上线方法，请参阅如何将 AI 原型推向生产环境。

常见问题