一个场景做完怎么算完成？很多项目按"功能演示通过"收尾，上线两周后陆续冒出边界问题，又要回退又要补，来回消耗的时间超过开发本身。

一、先给结论

结论是：场景上线要设三道闸门——数据闸门、边界闸门、灰度闸门。数据闸门判断数据够不够全，边界闸门判断异常能不能拦住，灰度闸门决定放量节奏。三道都过了才允许整体铺开。企业级智能体自动化的场景是逐步增量的，闸门的意义在于让每一步都可控。场景数量从 80 个扩到 150 个的过程里，闸门没有被绕过的记录。

二、数据闸门：先确认数据条件成立

一个场景能跑通，往往是因为数据正好符合预期。上线前先确认三件事：所需字段是否齐全、历史数据是否覆盖足够长的周期、异常数据的比例是否在可接受范围。这三项有一项不成立，后续的问题都会归结为数据问题，定位成本很高。我们的经验是用近 6 个月的历史数据回放一遍，回放通过再谈功能验收，这样能挡掉大半上线后才发现的问题。回放不要求全对，只要失败原因能归到明确类别，就可以进入下一道闸门。标准要是卡在必须全对，回放本身就会变成走过场。

三、边界闸门：把异常当成常态

成功路径跑通只是及格线。要重点验证：字段缺失怎么办、格式漂移怎么办、上游延迟怎么等、重复提交怎么挡。我们把这几类单独收集成用例集，每个场景上线前跑一遍。用例集要随场景一起维护，否则很快就失去意义。

四、灰度闸门：按量级分三步放

灰度不是走个形式。我们按 1%、10%、100% 三档推进，每档观察一个完整周期，观察指标包括成功率、异常量、人工介入率。下一档的放量条件写死在门槛上，达不到就不放。门槛之外还要有明确的回滚条件。回滚要有可执行的步骤而不是一句"先停一下"，停了之后怎么接手、接手时按什么顺序处理，这些都要提前写清楚。

五、我们踩过的三个具体坑

验收只看演示数据。演示用的数据又干净又整齐，真实数据一进去就崩。改用历史数据回放才覆盖住。

灰度没有门槛。觉得没问题就往上一放，出问题时已经影响了不少业务。设门槛之后返工明显减少。

没有回滚预案。发现问题时只能先停，停了之后人工接手也乱。补上回滚步骤才安心。

六、行业里已经跑到什么规模

场景逐步放量在公开资料里可以看到节奏。某大型保险集团公开的场景数量从 80 个扩展到 150 个；某保险寿险公开的场景上线数量达到 600 个以上、累计运行 3.6 万小时；某股份制银行公开的流程数量在 500 条以上。可以看到公开口径都强调场景的持续增量，而不是一次性交付。

七、怎么验证这套机制真的生效

首周异常量：上线后一周内的异常条数。

人工介入率：需要人处理的占比，应逐档下降。

灰度达标率：达到放量门槛的场景占比。

回滚触发次数：因问题回退的次数，长期为零要排查门槛是否形同虚设。

这四项里，首周异常量是直接的观测点。

检查清单

是否用历史数据而非演示数据做验收。

边界用例集是否随场景一起维护。

灰度是否分档放量并写了放量门槛。

是否具备明确的回滚步骤。

是否跟踪首周异常量与人工介入率。- 边界用例集是否指定专人维护，新增场景时是否同步补录。