面向设计师的开发、测试和生产：2026 年指南

大多数设计师都是通过在错误的环境中搞砸事情来了解开发、测试和生产环境的。Loom 被发送出去，工程师皱起了眉头，Slack 论坛上出现了“等等，这是哪个 URL？”这样的问题。这就是全部的入职流程。

这才是你第一天就应该得到的解释。没有为了术语而术语，没有故弄玄虚，只有三个环境，每个环境的使用者，以及作为设计师你应该在这些环境中做什么。

如果你曾经在查看错误的标签页时问过“这个上线了吗？”，那么这篇文章就是为你准备的。

为什么需要三个环境

软件面临着实体产品所没有的问题。一旦发布，它就会立即同时推送给所有人。没有工厂车间，没有测试市场，也没有默认的缓慢推广。一个糟糕的改动可能在刷新页面的时间内影响到一百万用户。

三个环境的存在是为了让团队在用户发现错误之前有一个可以犯错的地方。开发环境允许你犯很多错。测试环境允许你犯一些小错。生产环境则不允许你犯任何错误，因为有真人用户在监督。

你可以把它想象成同一篇文章要经过三轮编辑。初稿比较粗糙，校样基本完善，印刷版杂志已经由十个人阅读过。出于同样的原因，没有人会直接发布初稿，也没有人会直接把设计稿投入生产环境。

跳过某些阶段的团队通常是因为规模小、速度快或者鲁莽。有时三者兼具。这种结构的存在是为了让团队在不放慢速度的情况下，能够克服鲁莽行为并不断成长。

三环境速查表

在深入探讨之前，这里有一份速查表，你可以截图保存，以后就不用再问了。

| 环境 | 目的 | 受众 | 数据 | URL 模式 | 部署触发条件 | 审核风格 |

|---|---|---|---|---|---|---|

|开发 | 自由构建和调试 | 一位工程师，有时是你 | 虚假数据或已植入种子数据，经常出现问题 | localhost:3000 或 yourname.dev.app | 本地代码更改 | 结对编程，屏幕共享 |

| 预发布 | 用户测试前的最终检查 | 内部团队、设计师、QA | 真实、匿名、更新 | staging.app.com 或 pr-123.app.com | PR 合并或手动推送 | 异步审查、Loom、Figma 对比 |

| 生产 | 真实环境 | 客户，全世界 | 真实、敏感、不可逆 | app.com | 带标签的发布版本或主分支合并 | 监控，发布后 QA |

如果你只能记住一行数据，那就记住数据行。开发环境使用虚假数据，预发布环境使用真实数据，生产环境使用一旦篡改就会被告上法庭的数据。请相应地对待这三个环境。

开发环境：工程师的居所，故意制造故障的地方

开发环境指的是工程师在笔记本电脑或个人云沙箱中运行的任何环境。它通常被称为本地主机（localhost）。它运行在他们的机器上，连接到一个虚拟数据库，并且一次只能供一个人使用。你几乎看不到这个环境，这没错。

当工程师说“它在我的机器上运行正常”时，他们指的是开发环境。一半情况下，它在那里运行正常是因为数据是虚拟的，网络速度很快，而且没有其他事情发生。另一半情况下，它在那里运行正常是因为他们五分钟前才完成，还没有在任何类似真实环境的情况下进行测试。

开发环境也是新组件首次出现的地方。如果你在 Figma 中交付了一个卡片设计，它第一次以实际代码形式出现是在某个工程师的开发环境中。他们可能会通过本地主机发送屏幕截图或 Loom 消息给你。他们展示的是粗略版本，而不是最终版本。

你不会审查开发环境中的代码以追求像素级的精细度。您需要审核开发版本，以确认其结构、行为和意图。请将像素级细节保存到测试环境中。

测试环境：彩排

测试环境是团队在客户体验之前进行自我测试的地方。

它运行在真实的基础设施上，使用真实的数据，URL 通常以“staging”开头，并带有您的常规域名。

团队中的任何人都可以查看测试环境，但客户无法查看。

测试环境是您进行大部分设计评审的地方。您需要将其与 Figma 文件进行比较。您需要在真实设备上体验整个流程。您需要找出那些在 Figma 中看起来正常但在代码中却显得奇怪的问题：行高、焦点状态、名称长度达到 40 个字符时的行为、以及完全没有数据时的行为。

测试环境通常会尽可能地模拟生产环境。相同的数据库结构、相同的第三方服务测试模式、相同的功能开关、相同的身份验证流程。测试环境与生产环境越接近，产品发布时遇到的意外就越少。如果团队让测试环境与生产环境脱节，最终会导致一些原本可以免费发现的 bug 被发布出去。

测试环境也是检验工程师是否理解了你的设计意图的地方。通常情况下，他们理解得没错。但另一半情况下，真正的对话就此展开。

生产环境：真实用户体验

生产环境就是用户实际访问的网站。当客户在浏览器中输入网址时，他们看到的就是这个网站。它运行在真实的基础设施上，处理着真实的数据，资金流动真实，每一次更改都会产生真实的后果。当你点击访问时，你正在与你的用户所访问的同一个系统进行交互。

在这个环境中，你不再是设计师，而是访客。你不能在生产环境中随意点击来测试想法，也不能尝试各种功能。你不能以虚拟用户的身份登录来查看会发生什么，因为在生产环境中没有虚拟用户，只有真实的用户和真实的记录，而你可能会不小心弄坏它们。

生产环境用于监控、部署后的抽查以及对已上线内容进行截图。如果需要测试某些内容，请返回预发布环境。如果预发布环境无法满足您的需求，请申请预览。切勿直接访问生产环境。

衡量任何团队成熟度的标准在于他们对这条规则的遵守程度。初级团队会频繁地访问生产环境，而高级团队则会将其视为洁净室。

单个变更的生命周期

单个设计变更在最终呈现给用户之前，需要经过所有环境。了解这一生命周期是区分令工程师头疼的设计师和令工程师满意的设计师的关键所在。

以下是变更的实际流程：

1. 您在 Figma 中提交设计稿，包括注释、状态和边界情况。

2. 工程师将变更拉取到他们的开发环境并在本地构建。

然后，该变更对团队公开：

3. 他们提交一个拉取请求，该请求会启动一个带有唯一 URL 的预览部署。

4. 您查看预览，留下评论，提出修改建议，然后批准。

最后，它终于可以交付给用户了：

5. PR 合并，变更发布到预发布环境，进行最后的团队审核。

6. 预发布环境审核通过后，变更发布到生产环境，用户即可看到。

第三步和第四步是新的强大功能。预览部署意味着您无需等待预发布环境即可看到代码中的成果。工程师推送分支的那一刻，您就能立即看到。这曾经是奢侈品，现在已成为基本要求。

如果您的团队还没有预览部署，那么这是他们可以添加的最有影响力的功能。赶紧争取吧！

预览部署改变了一切

十年前，设计评审意味着要么飞奔到工程师的办公桌前，要么等到下周二预发布环境推送。如今，每个现代托管平台都会为每个拉取请求分配一个专属 URL。 Vercel 称之为预览部署，Netlify 称之为部署预览，Render、Cloudflare 和 AWS Amplify 也都提供类似功能。

实际意义在于：每个分支、每个 PR、每个正在进行的更改都有一个实时可点击的 URL，您可以立即查看，无需等待。工程师推送分支后，预览会在两分钟内构建完成，然后机器人会自动将 URL 添加到 PR 中。您只需点击、查看、评论，然后继续下一步。

预览部署将设计评审周期从几天缩短到几分钟。此外，由于预览 URL 本身就是一个可交互的 Loom 视频，因此也大大减少了对 Loom 视频的需求。如果您之前没有使用过预览部署，请让您的工程师指出任何未完成 PR 中的机器人评论。链接就在那里。

关于预览部署，您需要了解以下几点：预览部署使用预发布或测试数据，绝不会使用生产数据。预览部署是临时的，会在 PR 关闭后被移除。每个分支都有自己的 URL，因此您可以同时打开十个分支来测试十个不同的功能。

环境变量、配置以及“测试模式”的由来

每个环境运行相同的代码，但与不同的服务通信。开发环境使用测试数据库，预发布环境使用预发布数据库，生产环境使用真实数据库。每个环境使用的第三方工具版本也不同：开发和预发布环境使用 Stripe 的测试模式，生产环境使用 Stripe 的实时模式。电子邮件发送器、分析工具、身份验证工具以及所有外部依赖项也是如此。

团队管理所有这些信息的方法是使用环境变量，也称为配置或密钥。这些变量是一些命名值，例如 DATABASE_URL 或 STRIPE_KEY，它们会根据不同的环境而变化。Doppler、Vercel env vars、AWS Secrets Manager 或 1Password Connect 等工具可以管理这些变量。

作为设计师，这很重要：当您在测试环境中看到 Stripe 显示测试卡号时，这是测试环境的 Stripe 密钥在起作用。当您在开发环境中看到自己的开发头像，但显示的却是完全虚假的信用卡时，这是开发环境从一个虚假数据库中提取数据，但使用的是真实的 Clerk 身份验证。当某些功能在测试环境中运行正常，但在生产环境中却出现问题时，90% 的情况下都是由于缺少或使用了不同的环境变量造成的。

您无需管理这些环境变量。您只需要知道它们的存在，这样当工程师说“等等，那使用的是生产环境的 Stripe 密钥，不要点击那个按钮”时，您就能明白他们的意思。

数据一致性：您实际看到的内容

每个环境中的数据决定了您可以测试什么，不能测试什么。这是设计师最常忽略的地方。

开发环境通常使用种子数据，包含少量虚假用户、虚假产品，以及所有虚假数据，这些数据通常每天早上都会更新。用户名称可能很滑稽，地址可能来自斯普林菲尔德，头像可能是灰色的小方块。不要尝试用这些数据来评估空状态或极端情况，因为它是为确保正常流程运行而构建的。

预发布环境通常使用匿名化的生产数据或精心策划的真实数据集。数据包含真实的形状、长度和极端情况，但姓名和电子邮件地址已被清除。在这里，您可以实际看到您的设计在名为 Christopher Hassan-Williamson III 的客户或包含 63 个条目的订单上的实际效果。这是唯一可以进行真正设计质量保证的地方。

生产环境使用真实数据，正因如此，您才不应该随意修改它。您可以查看快照和仪表板，但绝不能将生产环境用作测试场地。

设计师在不同环境中的角色

要清晰地理解你在每个环境中的工作，最有效的方法是给自己设定不同的角色模式。

在开发环境中，你是团队成员。你通过屏幕共享进行快速检查，确认工程师是否理解设计，并尽早发现重大的结构性问题。在开发环境中，你不会进行任何修改，因为工程师仍在进行构建。

在预发布环境中，你是设计质量保证人员。你需要将设计与 Figma 文件进行比较，检查状态，并编写待办事项清单。在这里，你可以进行认真的评审，留下结构化的评论，并批准或阻止变更。预发布环境是你的专属领域。

在生产环境中，你是访客。你需要验证变更是否已发布，截取屏幕截图，并查看分析数据（如果这是你的职责）。在生产环境中，你不会随意点击测试或“快速尝试一下”。

牢记这三种角色模式，你将成为工程团队合作过的最轻松的设计师之一。

设计师常犯的错误

我见过设计师犯过所有这些错误。我自己也犯过其中一些。虽然这些错误都不是什么大问题，但它们都会拖慢团队进度，损害工程师的信任。

经典错误：

• 将开发环境的 URL 发送给客户。 开发人员在别人的笔记本电脑上操作，客户点击链接后出现连接错误，然后问你们到底有没有在发布任何东西。

• 报告来自过期 CDN 缓存的“在线错误”。 你查看的是六小时前缓存的版本，强制刷新页面后问题就解决了。

下一批错误源于对哪些内容已上线、哪些内容已在测试环境中修复的混淆：

• 为已在测试环境中修复的问题提交错误报告。 你查看了生产环境，发现是旧版本，于是慌忙提交了一个 Slack 错误报告。而修复程序已经在测试环境中运行一周了。

• 没有索要预览链接。 你等了三天，等着它上线测试环境，而工程师本可以在推送后立即分享预览链接。

最后两条是关于尊重测试环境和生产环境之间的界限：

• 通过生产环境点击链接来“测试”某些东西。 你现在是真正的用户，要承担实际后果，所以请停止这种行为。

• 问“上线了吗？”而不是查看部署日志。 大多数团队都有一个 Slack 频道，会发布每次部署的信息，所以请收藏该频道。

一旦你知道这些错误，它们都可以通过一行代码轻松解决。这些错误本身并不愚蠢，只是没人告诉你而已。

如何提出你的需求

这些错误的另一面是礼仪。设计师和工程师之间关于环境的沟通主要在于具体明确。模糊的请求会浪费时间，而具体的请求则不会浪费时间。

错误示例：“嘿，你能把新的卡片设计推送到某个地方让我看看吗？”

正确示例：“嘿，你能把你的卡片设计分支推送过来，完成后把预览链接发给我吗？”

错误示例：“首页更新上线了吗？”

正确示例：“PR 412 已经上线生产环境了吗？还是还在测试环境？”

错误示例：“网站上好像出了点问题。”

正确示例：“在生产环境中，/pricing 页面上的价格卡片底部边框缺失。我强制刷新页面，问题依旧。截图已附上。”

每个示例的模式都一样：说明环境，说明更改，并提供证据。工程师会竭尽全力满足设计师提出的这类请求。而对于那些不这么做的设计师，他们会默默地感到不满。

功能开关：生产环境中的测试环境

还有第四个概念，它以一种有用的方式打破了开发/测试/生产环境的模式：功能开关。功能开关是代码中的一个开关，它指示“向用户 X 显示此新功能，但不向用户 Y 显示”。团队使用功能开关将代码发布到生产环境，同时仅向一小部分用户（通常是内部员工）公开新功能。

LaunchDarkly、Statsig、ConfigCat 和 Vercel 自带的功能开关等工具都支持此功能。新设计在技术上已上线，但只有启用了内部功能开关的用户才能看到它。其他用户看到的仍然是旧版本。

这一点对您很重要，因为“这个功能是否已上线？”这个问题的答案会变得模糊不清。代码可能已经上线，但功能可能尚未上线，因此您可能需要请工程师为您的帐户启用该功能开关。或者他们可能会说“功能已上线，只是被一个功能开关隐藏了，我们将在周二对所有人启用它。”

功能开关是成熟团队持续发布代码而不影响任何用户的秘诀。它还可以让您以低风险的方式，在真实的生产数据上，使用真实用户进行类似于预发布环境的评审。

每种环境能教会你什么关于团队的信息

一个团队如何处理这三种环境，几乎可以反映出其工程成熟度的方方面面。你可以将本文作为快速了解任何新客户或新职位的参考。

没有预发布环境的团队就像是在快速推进，然后祈祷好运。他们最终会遇到一个导致客户流失的 bug，然后才会着手搭建预发布环境。

有预发布环境但没有预览部署的团队则处于中间状态。评审速度缓慢，从“完成”到“设计师可以查看”的周期以天计算，你会花费大量时间等待。

拥有预览部署、真正的预发布环境、受监控的生产环境和功能开关的团队，其运作水平正是你所期望的。反馈循环短促，错误能够及早发现，发布当天也不会出现恐慌。一旦你体验过这种水平的工作，其他水平的工作就会让你感到疲惫不堪。

三种环境，三个受众群体，三组数据，一个连接它们的生命周期。这就是全部概念。其他一切都只是附加工具。

你无需了解如何部署代码或管理 Vercel 帐户。你只需要知道你正在查看哪个环境，你在该环境中拥有哪些权限，以及如何获取正确的 URL。做到这些，你就能成为工程师真正想合作的设计师。

将部署日志添加到书签，索取预览链接，然后停止对生产环境进行任何操作。