制品、运行、业务与责任四层验收
一句话收获：系统可交付需要制品完整、运行可控、业务成立和责任清楚。
这个场景在解决什么问题
目标（goal）是理解四层验收（制品、运行、业务、责任）为什么不能互相替代。观察方式是让同一系统依次通过四层检查，并在每一层展示否决条件。值得单独学，是因为很多人把"文档写完了"或"程序跑起来了"当成"交付完成"，但真正可交付必须四层都过。
先理清这条判断链（文字版）
先验收制品是否完整，再验收运行是否可控，接着验收业务结果是否成立，最后验收责任是否清楚。这四层层层递进、各管一段，谁也不能替代谁。判断链是：
- 检查 Spec、代码、配置、接口、测试、部署材料等制品是否完整。
- 检查启动、调用、停止、恢复、证据记录等运行机制是否可控。
- 重新读取对象、状态、结果，检查真实业务条件是否成立。
- 确认谁有权放行、谁能否决、失败由谁处理、谁能接管。
逐层详解
第 1 步：制品验收
原文：检查 Spec、代码、配置、接口、测试和部署材料。
白话：先验收"交付物全不全"——Spec、代码、配置文件、接口定义、测试用例、部署材料这些制品是不是都在、是不是齐。
类比：像交房时先点清单——钥匙、说明书、保修卡、水电卡是不是都给你了，东西齐不齐和能不能住是两回事。
举例：验收一个报销 Agent，先核对 Spec 文档、代码仓库、配置文件、接口文档、测试用例、部署脚本这些制品是否齐全且版本一致。
为什么重要：制品是系统可复现的基础——制品不齐，系统就没法在别处重新搭起来、复现出来。
怎么验证（证据点）：
- 文件完整：该有的文件都在。
- 版本一致：各文件版本对得上。
- 依赖明确：依赖什么、版本多少，写得清楚。
别踩的坑（边界）：文档齐全不证明系统能运行——制品齐了只说明"料备齐了"，不代表系统跑得起来。
落地检查：制品验收只回答交付物是否完整——落地时记住，这层只问"东西全不全"，别的先不管。
第 2 步：运行验收
原文：检查启动、调用、停止、恢复和证据记录。
白话：验收系统能不能"受控地运转"——能不能正常启动、被调用、被停止、出错后能恢复、运行过程有证据记录可查。
类比：像新车交付后先试驾——能不能打着火、正常开、刹车、熄火，出了问题仪表盘有没有记录。
举例：验收报销 Agent，实际测试它能否正常启动、被正确调用、能被安全停止、故障后能恢复、每次调用都有日志轨迹可查。
为什么重要：运行机制决定系统能否受控工作——能不能受控地跑起来、停下来、恢复，决定了系统可不可用。
怎么验证（证据点）：
- 服务可用：服务能正常提供服务。
- 错误可恢复：出错后能恢复。
- 轨迹可查看：运行轨迹能查得到。
别踩的坑（边界）：运行通过不证明外部业务结果成立——系统跑得好，不代表外面真实业务真的成立了（比如钱真的退了）。
落地检查：还需要业务权威状态——跑通了还不够，还得看外部权威系统里的业务状态对不对。
第 3 步：业务验收
原文：重新读取对象、状态和结果，检查真实业务条件。
白话：回到外部权威系统里，重新读取业务对象、它的状态、最终结果，看真实的业务条件是否真的成立。
类比：像点外卖"已送达"不能看骑手 App 显示，而要看你手里真的拿到饭了——业务结果要在真实世界坐实。
举例：验收退款功能，不只看系统日志"退款成功"，而是回到支付系统里重新读取这笔订单的真实状态，确认钱真的退到用户账上了。
为什么重要：业务完成位于外部权威系统——业务到底做没做成，得看外部权威系统（支付系统、订单系统）说了算，不是内部系统自说自话。
怎么验证（证据点）：
- 对象正确：操作的对象是对的。
- 状态正确：对象状态在权威系统里正确。
- 证据支持：有证据支撑业务成立。
别踩的坑（边界）：业务结果出现不证明过程合规——结果对了，不代表过程没越权、没违规。
落地检查：过程权限和责任仍需检查——业务结果成立后，还得回头查过程是否合规、责任是否清楚。
第 4 步：责任验收
原文：确认谁有权放行、谁能否决、失败由谁处理、谁能接管。
白话：最后验收"责任"——谁有权放行上线、谁有权力一票否决、失败了由谁负责处理、紧急时谁能接管，这些要一一确认清楚。
类比：像飞行前的责任分工——谁有权签放飞、谁能叫停、出事谁处置、特殊情况谁接管，责任不明确不能起飞。
举例：验收报销 Agent 上线前，明确：产品负责人有权放行、财务负责人能否决上线、系统失败由运维值班处理、紧急故障由指定人员接管。
为什么重要：责任要与技术权力和证据能力一致——谁担什么责，要跟他的技术权限、掌握证据的能力匹配，不能脱节。
怎么验证（证据点）：
- 决定权明确：谁有决定权，写得明明白白。
- 接管可执行：接管动作是可执行的，不是空头承诺。
- 轨迹可追溯：决策轨迹能追查。
别踩的坑（边界）：写有责任人姓名不证明其具备接管能力——名单上写个名字，不代表这个人真有能力和权限接管。
落地检查：责任验收以实际判断和接管能力结束——落地时责任验收的终点，是确认责任人有真实的判断能力和接管能力，而不是名单上有名字。
落地可行性小结
本场景涉及的技术栈：制品管理（Spec、代码、配置、接口、测试、部署材料，对应版本控制和 CI/CD 交付物）、运行监控（启动/停止/恢复/日志轨迹，对应服务治理和可观测性）、业务核验（外部权威系统状态读取，对应对账/接口回查）、责任机制（放行/否决/接管，对应审批流程和值班/接管制度）。落地动作：把四层验收做成上线前的固定关卡，逐层过、逐层记录否决条件；业务验收一定要读外部权威系统而非内部日志；责任验收落到具体人和具体可执行的接管动作。常见坑：一是拿"文档齐全"当"能运行"；二是拿"内部日志"当"业务成立"；三是名单有名字就以为具备接管能力。检查点：四层是否都独立完成、业务验收是否读权威源、接管是否可执行。
回顾
- 制品验收只回答"交付物是否完整"，不证明系统能运行。
- 运行验收管启动/停止/恢复/记录，但不证明外部业务成立。
- 业务验收要读外部权威系统，结果成立不等于过程合规。
- 责任验收落到谁放行、谁否决、谁处理、谁接管，名字在列不等于具备接管能力。