敢扔才敢验：给 agent 搭一个可丢弃的验收环境

先说结论：验收环境的第一要求不是“像生产”，而是“敢扔”

很多人给 AI agent 验收成果时，第一反应是把东西部署到一个“尽量像生产”的环境里跑一遍。这个方向没错，但漏掉了最关键的一条标准：这个环境能不能在不心疼、不请示、不留后遗症的前提下，随时整个扔掉重建。如果答案是“不能，因为里面有真实数据”“不能，因为别人也在用”“不能，因为重建要半天”，那它就不是验收环境，而是一个披着验收外衣的第二个生产环境。Agent 在里面每动一下，你都要提心吊胆；它一旦把数据改坏了，你修环境的时间比审它代码的时间还长。

可丢弃的验收环境，讲的就是一句话：给 agent 一个专门用来“搞砸也没关系”的地方。代码、数据、凭证、外部服务全部隔离，验收完就销毁，下一次验收从一张干净的快照重新开始。你的主力分支不动，你的真实用户数据不动，你的线上服务不知道这回事。Agent 可以放开手脚跑迁移、造数据、点冒烟流程，而你只需要看结果、做判定，不用在它身后收拾残局。

这篇指南不讲怎么写测试用例，也不讲怎么评审代码，它只讲一件事：怎么从零搭出这样一个环境、怎么用它做验收、什么时候判定通过、什么时候直接扔掉重建。文末附一张可以直接复制的验收检查表。

边界说明：这篇指南不是什么

为了避免和站内已有的邻近指南混淆，先把边界划清楚。本文只讲验收环境的搭建与判定，不讲以下内容：上线前检查清单与首周监控讲的是“已经决定上线之后”的事——发布窗口、回滚预案、上线后第一周盯哪些指标，那是上线后的工作；本文讲的是上线之前、在一个可以扔掉的环境里验证“这东西到底能不能用”。合并前代码评审讲的是“审代码”——逐行看 diff、判断逻辑与安全问题；本文不审代码，只看“在隔离环境里跑起来之后表现如何”。密钥轮换讲的是“已经泄露或到期的密钥怎么换”，离线冲突讲的是“断网后数据怎么合并”，移动端适配讲的是“界面在不同机型上怎么摆”，加载状态讲的是“等待时给用户看什么”，登录设备会话讲的是“多设备登录怎么管”，文件版本历史讲的是“文件改了几版怎么找回”，反馈分流讲的是“用户反馈先分给谁”，故障报告讲的是“一个 bug 怎么写清楚”，任务验收清单讲的是“任务做完没的判定条目”——这些都不重叠。本文唯一的主角，是那个可以随时销毁重建的验收环境本身，以及用它做判定的方法。

一、为什么不能在主分支上验收：五类典型翻车

第一类翻车叫“验收改了生产数据”。Agent 为了验证“删除订单”功能，顺手删了几条真实订单；为了验证“退款流程”，给真实用户退了款；为了验证“导入功能”，把测试文件导进了生产库。事后恢复不是不可能，但你要先发现、再定位、再从备份里挑出来，成本远高于当初搭一个隔离环境。更糟的是，有些改动当时看不出来——比如它把一批用户的状态字段悄悄改了一个枚举值，三个星期后另一个功能才暴露问题。

第二类翻车叫“验收污染了共享状态”。主分支上的环境往往不止你一个人在用：同事在联调、演示账号在给客户看、定时任务在跑。Agent 一跑迁移，表结构变了，别人的联调当场断掉；它一造数据，演示账号里多出一堆乱码订单，客户演示时当场穿帮。你以为只是在验收一个功能，实际上是在别人的工作台上做实验。

第三类翻车叫“验收结果不可复现”。在主分支上跑通过一次，不等于这个功能真的对了——因为它可能依赖了主分支上恰好存在的一条旧数据、一个手动改过的配置、一个别人随手留下的文件。换一台机器、换一个时间再跑，就失败了。验收的意义恰恰在于“可复现”：同样的代码、同样的种子数据、同样的步骤，每次都应该得到同样的结果。在脏环境里，你永远不知道通过的那一次是靠实力还是靠运气。

第四类翻车叫“回滚没有按钮”。主分支上的改动一旦跑了迁移、改了数据、调了第三方服务，就很难干净地退回去。数据库迁移一般只写“往前走”的脚本，不写“往回走”的脚本；第三方服务发出去的短信、扣掉的费用、创建的外部资源，根本收不回来。验收变成了一条单行道：只能往前，不能反悔。而验收的本质恰恰是“允许说不”——如果没有低成本的反悔手段，验收人就不敢说不，最后只能硬着头皮放行。

第五类翻车叫“凭证与权限跟着跑偏”。在主分支上验收时，agent 往往顺手就用上了真实凭证：真实的支付密钥、真实的邮件服务、真实的云存储桶。一旦它在验收里触发了真实扣费、真实群发、真实删除，损失就是真金白银。更隐蔽的风险是，agent 可能把真实凭证写进日志、写进它生成的测试文件、写进它留下的临时脚本里，之后这些文件又被提交、被分享，凭证就这样一路扩散出去。

二、可丢弃验收环境的四个要素

要素一：隔离的分支或 worktree。验收用的代码必须从主力分支上切出来，单独存在。最轻量的做法是 git worktree：主仓库不动，另开一个目录检出验收分支，agent 只在这个目录里改、只在这个目录里跑。重一点的做法是单独的部署单元：一个独立的容器、一个独立的子域名、一个独立的数据库实例。判断标准只有一条：把验收分支整个删掉，主力分支和线上服务必须毫发无损，连一条日志都不应该多出来。

要素二：种子数据与可重放的 fixtures。验收环境里的数据必须是“造出来的、写成脚本的、每次重建都一模一样的”。不要从生产库导一份真实数据过来——那既不安全，也不可重放。正确的做法是写种子脚本：造 3 个管理员、20 个普通用户、50 条订单，其中特意包含边界情况——金额为零的订单、超长的用户名、已退款又重复退款的订单、跨时区的下单时间。种子脚本要进版本库，和代码一起评审、一起改。每次重建环境，先跑迁移、再跑种子，得到的数据集应该是确定性的：同一份脚本跑两次，订单号、时间戳、状态分布都应该对得上，至少在可比的字段上对得上。

要素三：一次性凭证与沙箱密钥。验收环境里出现的所有密钥都必须是“只能在这个环境里用、用完就废”的。支付走沙箱模式，邮件走捕获服务（只收不发），短信走模拟网关，云存储走隔离桶。给 agent 的凭证要单独发、单独记、单独吊销：验收一结束就吊销，绝不复用。还有一条铁律：验收环境的凭证绝不允许和生产凭证出现在同一个配置文件、同一个环境变量文件里。混放一次，误用就是迟早的事。

要素四：快照与回滚按钮。环境在“刚建好、刚跑完种子、还没开始验收”那一刻，要打一个快照。数据库快照、容器镜像、配置文件，三样齐了才算。验收过程中不管被 agent 折腾成什么样，一条命令就能回到快照：数据库恢复、容器重启、配置还原。回滚按钮必须是“一键”的——如果回滚需要你手动执行十条命令、查三篇文档，那它在关键时刻一定没人用。快照还要定期验证：每个月至少手动恢复一次，确认快照本身没有坏掉。一个从来没恢复过的快照，和没有快照是一回事。

三、从零搭建的步骤清单

第一步，定名字和寿命。给环境起一个带日期和任务号的名字，例如 accept-20261027-order-refund，写明创建人、用途、预计销毁时间。名字里带日期的好处是，三个月后你在资源列表里看到它，一眼就知道它早该死了。没有写明寿命的环境，最后都会变成没人敢删的“准生产环境”。

第二步，切隔离分支或建 worktree。执行 git worktree add ../accept-order-refund -b accept/order-refund，确认主工作目录的 git status 是干净的，确认验收目录里没有生产配置文件、没有真实密钥文件。这一步要亲手检查，不要只信 agent 的汇报。

第三步，准备隔离的基础设施。数据库新建一个空库，名字和生产库区分开；对象存储新建一个桶；域名或端口单独分配。把这三样写进环境说明书，放在任务单的开头，让任何接手的人五分钟内能找到环境在哪、怎么连、怎么毁。

第四步，写并跑种子脚本。先跑迁移，再跑种子，然后抽查：用户数对不对、边界订单在不在、时间分布合不合理。抽查要看具体记录，不是只看“脚本退出了 0”。抽查出问题，先修种子脚本，再重建环境，不要在脏数据上将就着验收。

第五步，发一次性凭证并记入清单。沙箱支付密钥、捕获邮箱、模拟短信网关、隔离桶的读写密钥，一样一样列出来，标明有效期和吊销方式。清单本身不要含密钥明文——只写“已发放、发给谁、何时吊销”，密钥走安全的传递通道。

第六步，打快照并验证回滚。快照打完，立刻做一次破坏性演练：故意删几条种子数据、改一个配置，然后执行回滚，确认数据恢复到快照状态。这个演练只要五分钟，但它能证明你的“后悔药”是真的，不是摆设。

第七步，把验收任务交给 agent，并在任务单里写明三句话：只在这个环境里操作；不许碰生产配置、生产数据库、真实凭证；验收结束或环境异常时先停下汇报，不要自己修环境。环境本身的维护是你的事，不是 agent 的事——让它修环境，等于让考生自己改考场。

第八步，验收结束就销毁。判定做完，无论通过还是不通过，先销毁环境、吊销凭证，再写验收结论。顺序不能反：先写结论、后想起来销毁的环境，最后往往都不会被销毁。销毁后在任务单里记一笔：何时销毁、由谁销毁、快照是否保留（一般不保留，除非要复现一个已确认的 bug，而复现用的快照要单独命名、单独说明保留理由和期限）。

四、可复制的验收检查表：构建、迁移、种子、冒烟、回滚五关

把下面这张表直接贴进任务单，验收时逐项打勾。任何一关标“不通过”，都先停下，不要带着疑问进入下一关。

第一关，构建。验收分支能否从干净状态完整构建？构建命令是否和文档里写的一致？构建产物里有没有混入生产配置？通过标准：一条命令、零手动干预、构建成功；失败标准：需要手动改配置、需要从别的机器拷文件、构建警告里出现真实域名或真实密钥字样。

第二关，迁移。迁移脚本能否在空库上从头跑到尾？能否重复跑（幂等）或明确报错而不是静默坏掉？通过标准：空库建表完整、迁移记录齐全、重复执行行为可预期；失败标准：中途报错、表结构缺字段、迁移后旧数据格式被静默改写。

第三关，种子。种子脚本跑完后，数据量、边界记录、时间分布是否和预期一致？通过标准：抽查的三类边界记录都在，数量对得上；失败标准：种子跑完只有默认的一条测试数据，或者边界记录缺失——那说明种子脚本根本没有覆盖验收要测的场景。

第四关，冒烟。走一遍最核心的用户路径：注册、登录、下单、支付（沙箱）、退款、查看订单。每个步骤都要在验收环境里真实走通，而不是只看接口返回了 200。支付必须走沙箱，退款必须能在种子数据里查到状态变化。失败标准：任何一步需要你手动在数据库里改状态才能继续——那说明流程本身就有断点。

第五关，回滚。故意制造一次脏状态，然后执行回滚，确认环境回到快照。通过标准：回滚后冒烟流程能重新走通，种子数据和快照一致；失败标准：回滚后仍有残留数据、配置没有还原、回滚命令本身需要手动修补才能跑。

五、种子数据的三条纪律

纪律一：不用真实用户数据。真实数据里有姓名、电话、地址、购买记录，哪怕你觉得“只导一小部分没关系”，一旦进了验收环境，它就会被 agent 读、被日志记、被快照存，扩散面立刻失控。需要“像真实”的数据时，用程序生成：按真实数据的分布造假名、假地址、假订单，但绝不复制真实记录。分布可以学，记录不能抄。

纪律二：可重放。种子脚本必须是确定性的，或者至少是“可解释的”：随机部分要固定随机种子，时间部分要用相对时间（例如“下单时间为今天减 3 天”），而不是写死的绝对日期。否则你今天验收通过的场景，下周重建环境就变了，复现 bug 时对不上号。种子脚本改了，就要像改代码一样走评审——因为种子变了，验收结论的基准就变了。

纪律三：覆盖边界。种子数据里必须有正常情况之外的记录：金额为零、数量为负（如果业务允许出现）、超长文本、跨时区时间、已删除用户的历史订单、同一用户短时间内重复提交。验收最容易漏的从来不是“正常流程跑不跑得通”，而是“边界情况会不会把系统带偏”。边界记录要单独列一张清单，验收时逐条确认它们被处理成了预期状态，而不是被静默忽略。

六、验收通过与不通过的判定标准，以及“脏了就扔”的纪律

通过的标准要事先写好，不能验收完了再现编。建议写成三条：五关检查表全部通过；冒烟路径里没有需要手动干预的步骤；回滚演练成功且耗时在可接受范围内（例如十分钟以内）。三条缺一不可：前面四关通过但回滚失败的环境，不能算通过——因为它意味着你一旦放行，就没有后悔的余地。

不通过的情形要分两类处理。第一类是“功能没做对”：冒烟失败、边界处理错误、迁移报错——这类结论写清楚失败的关卡、复现步骤、种子数据版本，然后把任务打回去改，环境保留到问题复现清楚为止，但要标明保留期限。第二类是“环境本身脏了”：agent 在环境里改了不该改的配置、导入了来源不明的数据、凭证疑似外泄、快照对不上——这类不要修、不要抢救，直接销毁重建。修脏环境的工夫，往往比从快照重建更长，而且修完你也不敢保证它真的干净了。判断原则很简单：如果你需要花超过十五分钟去“确认环境到底被改了什么”，那就直接扔掉重建。十五分钟不是精确的科学数字，它是一个纪律：用它逼自己不要在脏环境上恋战。

还有一条容易被忽略的纪律：验收过程中发现的任何问题，都要记到“环境版本”上。问题是在哪一份种子、哪一次快照、哪一个分支提交上复现的，写清楚。否则开发改完再来验收，你用新环境跑了一遍说“好了”，却不知道当初的问题到底是在旧环境还是新环境里消失的，结论就站不住。

七、成本与时间预算：何时值得搭，何时用轻量版

完整版验收环境（独立数据库、独立存储桶、快照回滚、沙箱外部服务）适合三种情况：改动涉及资金、订单、用户数据等不可逆操作；改动涉及数据库迁移或第三方服务配置；改动会被很多人用、出错影响面大。完整版第一次搭建大约需要半天到一天，但搭好一次之后，后续复用同一套脚本，每次重建只需要十几分钟——成本主要在第一次。

轻量版适合两种情况：纯界面文案改动、纯前端样式调整，或者一次性的小修小补。轻量版可以简化为：worktree 隔离分支加本地数据库加种子脚本，不用独立云资源，不用完整快照，但三条底线不能省：不用真实数据、不用真实凭证、能一键删掉重建。轻量版不是“将就版”，它是“把完整版里最贵的两项（云资源与快照服务）换成人工可承受的替代品”，底线一分不能少。

判断用哪一版的方法，是问自己一个问题：如果 agent 在这个环境里把最坏的情况做出来（删库、群发、扣费），损失我能不能在十分钟内讲清楚并且接受？讲不清楚、接受不了，就上完整版。反过来，如果一个环境搭了三天、验收只用十分钟，那也是浪费——这时候应该反过来检讨：是不是把“像生产”做得太过了，验收环境只需要“足够隔离、足够真实”，不需要“和生产一模一样”。

预算上建议这样记账：搭建成本记一次，复用成本每次记，销毁成本记为零（销毁应该是自动化的）。如果你的销毁还需要手动操作，那说明环境设计本身就有问题——先修销毁流程，再谈验收流程。一个不能一键销毁的环境，迟早会变成没人敢动的遗留环境。

八、验收前先填的环境说明书（模板）

环境名称、任务号、创建人、预计销毁时间；代码分支与提交号；数据库、存储桶、域名或端口；种子脚本版本与边界清单；一次性凭证清单（不含明文）与吊销方式；快照时间与回滚命令；五关检查表。把这张说明书贴在任务单最前面，agent 和接手验收的人都不用再问“环境在哪、怎么用、怎么毁”。说明书本身就是验收环境“可丢弃”属性的证明：如果连说明书都写不出来，这个环境大概率是删不掉、讲不清的。

最后再提醒一句：验收环境不是为了让 agent 更舒服，而是为了让你更敢说不。一个好的验收环境，应该让你在看到问题时能毫不犹豫地说“不通过、重建、再来”，而不是因为“环境重建太麻烦、数据不好恢复”而勉强放行。敢扔，才敢验；敢验，agent 的产出才值得信任。