五层现场验收怎样逐层否决
一句话收获：上层偶然成功不能替下层补票，每层都保留独立否决权。
这个场景在解决什么问题
目标（goal）是完成环境、技术、功能、业务、运营与责任这五个维度的验收——不只是"功能跑通了"，而是从底层环境一路验到运营责任，每一层都算数。
观察方式（observation）是：同一套系统，依次进入五层检查。同一套系统，先看环境和技术，再看功能，再看业务，再看运营和责任，一层一层往下过。
这个场景值得单独学，是因为验收最容易犯的错是"混层"：功能测试通过了，就以为业务也 OK 了；或者某一层偶然成功，就替下面一层"补了票"。正确做法是每层都保留独立的否决权——只要有一层不成立，整体就不能验收通过。
先理清这条判断链（文字版）
验收是五道关卡，同一套系统依次闯关，每关都能独立否决：
- 先验环境与技术：检查依赖、网络、证书、服务、接口、数据链，底层不成立就停；
- 再验功能：正常、边界、异常任务都按 Spec 跑一遍，确认输入和失败处理都符合预期；
- 然后验业务：重新读取对象、状态、权限、证据，拒绝"模型假装完成"的假象；
- 最后验运营与责任：验证告警、停止、恢复、回滚、放行、否决、接管，确认能长期运营、责任清楚。
一句话：底层环境 → 功能行为 → 业务事实 → 运营责任，五层逐层否决，任何一层不过就整单不过。
逐层详解
第 1 步：环境与技术
原文：检查依赖、网络、证书、服务、接口和数据链。
白话：验收第一层，先看地基牢不牢：依赖装没装全、网络通不通、证书有效没效、服务起没起来、接口通不通、数据从源头到消费能不能走通。这些都是底层，先确认。
类比：像验收一栋楼先验地基和管线——墙再漂亮，地基不牢、水电不通，房子也不能交付。
举例：验收一个 Agent 系统，先确认：依赖库版本都对、内网各服务间网络互通、内部证书没过期、推理服务和 API 都起来、各接口能连通、数据从数据库到知识库到模型的链路能跑通。这层过了，才谈得上后面。
为什么重要：底层不成立时上层结果不可持续。地基有问题，上面功能测出再多"通过"都是空中楼阁，换台机器、换个环境就崩。
怎么验证（证据点）：
- 环境匹配：环境配置与目标一致；
- 服务就绪：各服务真正就绪；
- 数据链通：数据链路能走通。
别踩的坑（边界）：服务启动不证明功能可用。服务起来了只说明进程活着，不代表功能真的对，还要往下验。
落地检查：继续执行冻结任务。底层过了，就用一套"冻结"（固定不变）的任务去验功能，避免任务变来变去没法对比。
第 2 步：功能验收
原文：正常、边界和异常任务按 Spec 运行。
白话：第二层验"行为对不对"。把正常任务、边界任务、异常任务都按 Spec（规格说明）跑一遍，确认系统该处理的处理了、该失败的失败得干净、该停止的能停下来。
类比：像考试不只考正常题，还考难题、错题——只会做"标准答案"的题不算会，边界情况和错误输入也能正确应对才算真会。
举例：功能验收时，用一套按 Spec 定义的测试任务：正常任务（标准输入得到标准输出）、边界任务（输入刚好卡在临界值）、异常任务（输入明显非法/缺失）分别跑，确认正常路径、异常路径、停止路径都符合预期。
为什么重要：功能验收确认系统按预期处理输入和失败。功能验收关心的不是"能不能跑"，而是"遇到各种输入和失败时，行为是否符合规格"。
怎么验证（证据点）：
- 正常路径：正常输入得到正确结果；
- 异常路径：异常输入被正确处理（报错、降级或拒绝）；
- 停止路径：该停的时候能停。
别踩的坑（边界）：功能测试通过不证明真实业务状态改变。功能对了，不代表它真的在权威系统里改变了业务状态——可能只是"看起来做完了"。
落地检查：进入外部业务验收。功能过了，接着去权威系统里验"业务事实是否真的变了"。
第 3 步：业务验收
原文：重新读取对象、状态、权限和证据，拒绝模型假完成。
白话：第三层验"结果是不是真的"。不要相信模型说"我完成了"，而是回到权威业务系统里，重新读取对象、状态、权限、证据，看业务事实到底变没变、改没改对。模型"假装完成"是不算数的。
类比：像发快递不能只看"已签收"三个字，要回到物流系统里查包裹实际到了哪个网点、谁签的字，以系统里的真实状态为准。
举例：Agent 说"已帮你创建工单"，业务验收时不能只信这句话，要回到工单系统里重新查：工单对象建了没、状态是不是"已创建"、当前用户有没有权限、有没有留痕证据（操作日志）。这些都对，才算业务真完成。
为什么重要：业务事实位于权威系统。模型的回答只是"声称"，真正的业务事实存在权威业务系统里，验收必须以权威系统为准。
怎么验证（证据点）：
- 对象正确：业务对象真实存在且正确；
- 状态正确：业务状态真的变成了预期值；
- 证据支持：有操作日志/留痕等证据支撑。
别踩的坑（边界）：业务结果出现不证明系统可长期运营。一次业务结果对了，不代表系统能长期稳定运营，还得看监控、回滚、接管这些运营能力。
落地检查：继续检查监控、回滚和接管。业务过了，接着验运营层面的能力。
第 4 步：运营与责任
原文：验证告警、停止、恢复、回滚、放行、否决和接管。
白话：第四层验"能不能长期跑、出了事谁负责"。要验证告警会响、系统能停、能恢复、能回滚、能放行新版本、能否决坏版本，以及责任能清清楚楚移交给别人。
类比：像交付一台车，不只是"今天能开"，还要确认仪表盘会报警、刹车能停、能重启、有备用方案、说明书写了责任人——这样以后才敢长期用。
举例：验收运营层时，故意触发一个告警看它响不响；演练停止/恢复/回滚流程；演练上线 Gate 的放行与否决；最后让接管者按材料独立接管一遍。这些都通过，运营与责任这一层才算过。
为什么重要：企业交付最终要求可持续运行且责任清楚。企业要的不只是一次能用的系统，而是能长期稳定运行、出问题有人负责、有人能接手的系统。
怎么验证（证据点）：
- 监控可用：告警、监控能正常触发；
- 回滚演练：回滚流程演练通过；
- 接管通过：接管者能独立接管。
别踩的坑（边界）：文档写有责任人不证明能力已经移交。文档里写了"负责人是谁"是一回事，这个人真正具备接管能力是另一回事，两者不能划等号。
落地检查：用实际接管任务结束验收。验收要收在"一次真实的接管任务"上，而不是停在文档层面。
落地可行性小结
这个场景涉及的技术栈和真实落地要点：
- 环境与技术：依赖、网络、证书、服务、接口、数据链的检查，落地时可做成一份"环境验收清单 + 自动化检查脚本"。
- 功能验收：用冻结（fixed/frozen）的测试任务集，按 Spec 定义正常/边界/异常路径，落地上常见坑是测试集不稳定、Spec 没写清失败行为。
- 业务验收：回到权威业务系统（工单、订单、数据库等）重新读对象、状态、权限、证据，核心是"以权威系统为准，不信模型声称"。
- 运营与责任：告警、停止、恢复、回滚、放行/否决、接管，落地时要演练而不是只写文档，责任矩阵要落到"谁能真的干这件事"。
- 常见坑：用功能通过代替业务通过；用"文档写了责任人"代替"能力真移交"；上层偶然成功替下层补票。
- 落地动作：五层分别设独立的通过/否决标准，每层留独立证据，任何一层不过就整体否决，不让上层偶然成功替下层补票。
回顾
- 验收分五层：环境与技术、功能、业务、运营与责任，每层保留独立否决权。
- 上层偶然成功不能替下层补票，功能通过不等于业务通过。
- 业务验收要回到权威系统重新读对象、状态、权限、证据，拒绝模型假完成。
- 运营与责任要真演练（告警、停止、恢复、回滚、放行、否决、接管），文档写了责任人≠能力已移交。