05 交付、验收与供应商

管理者先看结论

交付不是“做完了代码”，而是把范围、证据、责任和接管能力写成结果。管理者只盯三件事：问题是否写成用例；项目是否按发现、需求、原型、架构、开发、测试、UAT、上线、观察、交接；源码、账号、数据、文档和回滚是否归企业。

AHAX 判断：默认采用增量交付，而不是一次性大包。因为一次性大包最容易把需求、原型、开发、测试和接管混在一起，最后“看起来都做了”，但没有一项能被第三方复测。

管理者要问什么	应写成什么证据	谁来确认
这是不是当前真问题	问题说明书、流程图、角色表、数据表、异常表	业务负责人
这期到底交什么	阶段范围、原型边界、变更单、阶段退出条件	业务负责人 + 项目经理
怎么证明做成了	可执行验收用例、测试记录、UAT 记录、上线观察记录	业务负责人 + 测试/实施
企业能不能接管	账号移交单、源码清单、部署/回滚脚本、备份恢复记录	企业管理者 + IT

这章适合老板、业务负责人、采购和项目经理一起看。目标是把每一步都写到能验、能改、能停。

适用与不适用

先做需求发现，再做原型边界，再进开发，是这章的默认路径。若企业连问题、责任、数据和异常都没说清，就不要急着进代码阶段。

需求发现要先问什么

发现项	要写成什么	最低要求	退出条件
问题说明	发生频率、损失表现、影响对象	能描述“谁在什么情况下损失了什么”	说不清损失，就先停在问题说明
流程	现有步骤、手工点、跨部门交接	能画出从开始到结束的主流程	流程画不出，不能进原型
角色	使用者、审批者、复核者、维护者	每个角色都有动作和责任	角色不清，不能进开发
数据	字段、来源、口径、主数据归属	关键对象有唯一责任系统	数据口径不统一，不能冻结
异常	重复、缺失、超时、回退、冲突	至少列出主要异常分支	异常没写，验收就会失真

原型边界要冻结什么

原型冻结的是“要让谁做什么、看到什么、留下什么痕迹”，不是先冻结配色和动效。原型边界至少要落到这些点：

原型该定什么	原型不该定什么
页面结构、字段、状态、权限入口	最终视觉稿、营销口号、动效细节
主流程、异常分支、提示文案	未确认的 KPI、收益承诺、排期口径
需要保留的日志、导出和记录	还没定的外部接口和临时技巧
手机、桌面、后台各自承担什么	把所有终端做成同一种界面

什么时候不该直接进开发

• 业务负责人没有书面确认问题说明。
• 角色、流程、数据口径仍在反复变。
• 原型想同时承担展示、运营、审批、留资和报表全部职责。
• 采购还没问清源码、账号、数据和回滚归属。
• 项目方只会说“先做出来看看”，却说不出退出条件。

AHAX 判断：如果第一版需求里没有异常分支，那不是需求简单，而是后面一定会返工。

方案对比

这章的“方案对比”不是比较谁家 PPT 更好看，而是比较交付方式、验收证据和供应商可接管性。对管理者来说，最有用的比较是：一次性交付、分阶段交付、先原型后开发，哪一种更适合当前边界。

交付方式	适合什么情况	优点	风险
一次性交付	范围小、边界清、接口少	管理简单，文件少	容易把需求、原型和开发混成一团
分阶段交付	需求会收敛，但仍有不确定性	每阶段都能验收和止损	需要更强的阶段管理
先原型后开发	角色多、异常多、认知差异大	先对齐边界，再写代码	若原型只看“好不好看”，会误导开发

AHAX 判断：对于大多数业务系统，分阶段交付优于一次性大包；对于高不确定项目，先原型后开发优于边画边做。

供应商评分表（AHAX示例，可复算）

评分是让采购和业务在同一口径上比较。单项按 1–5 分评分，权重总和为 100%；权重是 AHAX示例，不是行业标准。

总分 = Σ(单项得分 / 5 × 权重)，总分保留 1 位小数。

维度	权重（AHAX示例）	看什么证据	低分信号
业务理解	20%	能否复述业务问题、角色和损失	只会讲技术，不会讲场景
范围拆解	15%	能否把第一期与后续期拆开	“都能做”但说不出边界
原型沟通	10%	是否能把异常和状态画清楚	只给漂亮页面，不给流程
项目透明度	15%	周报、看板、里程碑、风险是否公开	进度只有口头说法
测试与安全	15%	测试计划、缺陷记录、权限与审计	只说上线，不说怎么验
交付资产	10%	源码、文档、脚本、账号、备份是否可移交	只给成品，不给接管资料
退出机制	10%	能否说明换供应商、停用、回滚	不愿谈退出，只谈合作
协作响应	5%	问题响应、会议纪要、确认时效	回消息慢、结论反复改

售前问题

售前要问什么	为什么要问	你要看什么证据
第一阶段边界是什么	防止范围扩张	一页纸范围说明
哪些内容明确不做	防止夹带	不做清单和变更规则
谁每天使用，谁复核	防止演示化	角色和责任表
需求如何转成验收用例	防止只写名词	用例模板和样例
历史数据怎么迁移	防止数据断层	样本导入和校验记录
第三方账号归谁	防止失联	企业邮箱或企业主体账号
源码和部署资料怎么交	防止无法接管	交付清单和脚本目录
变更如何计价	防止后加价	变更单和计费原则
停用或换供应商怎么退	防止锁定	退出条款和演练记录

AHAX 判断：如果供应商不愿意把“不做什么”说清楚，通常不是能力不足，而是边界不可控。

实施

实施阶段要把交付拆成可复核的节点，而不是只在末尾看一个总验收。下面这张表就是项目节奏本身。

阶段	主要产出	企业责任	退出条件
发现	问题说明书、流程图、角色表、数据清单	提供样本、确认损失、指定业务负责人	问题和范围能被书面描述
需求	需求说明书、优先级、约束条件、验收草案	确认第一期做什么、不做什么	需求可写成验收用例
原型	页面、状态、字段、异常分支、提示语	审核业务路径和边界	角色、流程、异常都对齐
架构	系统边界、接口、数据流、权限模型	确认主数据和接口责任	关键对象有唯一责任系统
开发	代码、配置、构建脚本、说明文档	按里程碑确认样本和规则	核心功能可演示且可回放
测试	测试计划、缺陷单、回归记录、修复记录	提供测试数据，确认修复优先级	缺陷闭环到可接受水平
UAT	业务场景复测、签字记录、异常处理记录	业务负责人按脚本复测	真实使用者确认可上线
上线	发布单、回滚方案、上线公告、监控看板	决定上线窗口、停投或切换	上线可回滚、可观察
观察	运行日志、告警、工单、问题清单	监控业务结果，确认异常处理	关键故障稳定收敛
交接	账号移交、备份、恢复、文档、培训	接管企业账户和运维资料	企业能独立操作和恢复

变更控制怎么写

变更控制的目标不是阻止变化，而是让变化变成可评估、可批准、可追溯。任何变更都要补四样东西：影响、责任、验收和退出。

变更类型	常见触发	必补材料	退出条件
新增	新角色、新流程、新字段	变更说明、影响评估、更新后的验收用例	影响评估不清，不进当前期
替换	旧接口、旧页面、旧规则被替换	替换说明、回滚路径、对比样本	无法回滚，不允许替换上线
延期	业务未就绪、依赖未到位	延期原因、临时方案、责任人	临时方案不可执行，先停
加预算	范围扩大、迁移更复杂	预算差异、增加内容、审批记录	预算无法解释，不加钱
不做	风险高、收益低、当前不必要	不做原因、替代方案、复评时间	不能写清不做原因，就别改范围

AHAX 判断：没有变更单的项目，最后通常不是“按时交付”，而是“按时失控”。

风险与应对

交付风险的核心不是某一个 bug，而是供应商、账号、数据和回滚都不在企业手里。资产归属和退出机制要在合同和交接里提前写好。

资产归属与接管

资产	合同建议	AHAX判断
源码	写明企业获得可编译、可部署、可审计的源码和构建脚本	只交压缩包，不等于企业能接管
域名与 DNS	域名注册主体、解析权限、证书管理应可移交给企业	域名不归企业，网站就不算真正接管
云与主机	云账号或租户管理员权限应由企业掌握	供应商代管可以短期存在，但不能成为默认状态
第三方账号	CRM、统计、广告、短信、支付、IM 等账号应以企业主体控制	用个人邮箱开通的账号，后期极难退出
数据库	数据库账号、schema、备份、导出和迁移脚本要写入交付	只有能看不能导，等于没有接管
接口	接口文档、字段说明、鉴权方式、错误码、Webhook 规则都应交付	没有接口文档，后续对接成本会翻倍
文档	架构图、部署图、运维手册、培训材料、FAQ、联系人	文档缺一项，运维就多一层人肉依赖
部署/回滚	部署脚本、环境变量、发布步骤、回滚步骤、演练记录	不能回滚的上线，不应算完整交付
SBOM/依赖	依赖清单、版本锁定、许可说明、漏洞修复基线	不知道依赖，就不知道怎么补丁和退出
备份	备份策略、备份位置、恢复验证、恢复责任人	只说“有备份”不算证据，必须能恢复

退出机制与供应链风险

风险	影响	负责人	早期信号	应对	退出
供应商失联	交付停滞，问题无人处理	企业管理者	交付迟缓、响应断续	把账号、文档和脚本提前收回	无法响应时，启动接管切换
核心开发离场	知识断层，返工增加	项目经理	关键问题总是同一人回答	强制文档化和评审留痕	关键知识无法移交，暂停扩展
第三方服务不可迁移	停服后无法替换	技术负责人	SDK 绑定强、数据导出弱	先看替代方案，再签集成	替代不了就缩小依赖范围
开源组件风险	漏洞、许可、兼容性问题	技术负责人	依赖过旧、补丁滞后	SBOM、版本锁定、修复窗口	无法修复时，降级或替换
账号控制争议	无法登录、无法导出、无法审计	企业管理者	账号在个人邮箱、个人手机号	全部转企业主体并启用 MFA	不可转移的账号不进入正式上线
回滚路径缺失	出问题时无法恢复	实施负责人	只有“上线成功”，没有回滚演练	上线前先做回滚演练	不能回滚就不能切换生产

AHAX 判断：退出机制不是悲观预案，而是项目是否真的可控的证明。能退出，才说明企业有选择权。

验收

验收必须区分技术测试和业务接受。测试在证明系统“按设计工作”，UAT 在证明业务“按场景能用”。两者不是一回事，不能互相替代。

测试层与UAT的区别

层级	关注点	证据	谁签字
单元测试	函数、模块、规则是否正确	测试代码、覆盖率、日志	开发
集成测试	接口、鉴权、数据流是否通	联调记录、接口日志、失败样本	技术负责人
系统测试	主流程、异常、权限、回归	测试用例、缺陷单、修复记录	测试负责人
安全测试	权限、输入校验、会话、导出、审计	安全测试记录、整改记录	安全/技术
UAT	业务负责人能否按真实场景完成任务	业务脚本、签字单、异常说明	业务负责人

AHAX 判断：WSTG 可以作为 Web 安全测试参考，但不能替代 UAT，也不能替代合同验收。

可执行验收用例格式

验收用例必须写到第三方照着就能复测。最小格式是：

用例编号：
环境/版本：
前置数据：
角色：
步骤：
预期结果：
通过标准：
异常分支：
证据：

字段	必填内容	说明
环境/版本	测试环境、应用版本、配置基线	环境或版本不同，结果不可直接比较
前置数据	样本记录、权限、配置状态	没有样本就无法复测
角色	谁在操作、谁在复核	角色不同，结果可能不同
步骤	每一步点什么、填什么	步骤越具体，争议越少
预期结果	系统留下什么状态、日志或导出	不能只写“正常”
通过标准	可判断的数值、状态或证据条件	标准必须让第三方得出同一结论
异常分支	重复提交、无权限、网络中断、数据缺失	异常不写，现场必吵
证据	截图、日志、导出文件、录屏、签字	证据要能复查，不靠口头

验收证据与交接清单

证据 / 清单项	交接时要拿到什么	通过标准
代码与构建	源码仓库、构建脚本、依赖锁定文件	企业能重新构建和发布
账号与权限	域名、云、第三方平台、分析/广告/短信账号	企业能独立登录和管理
数据与备份	数据库导出、迁移脚本、备份文件、恢复记录	能恢复，且恢复结果可复核
部署与回滚	部署手册、回滚手册、环境变量说明	出问题能按文档退回
文档与培训	架构图、接口文档、运维手册、培训记录	新接手的人能继续维护
验收记录	UAT 用例、签字单、缺陷关闭清单	验收不是“感觉通过”
观察期	上线后运行日志、告警、问题单、修复单	观察期内问题有闭环

AHAX 判断：验收不是签字结束，而是确认企业能够在不依赖单个个人的情况下继续运行。

学习方法

这一章最值得做的作业，是把项目写成项目章程和交接清单。写不出来，就说明范围和接管还没收敛。

学习作业

作业	产出	目的
项目章程	问题说明、目标、范围、角色、里程碑、风险、验收口径	让管理层知道这项工作为何存在
交接清单	账号、源码、数据、文档、备份、回滚、联系人、观察期安排	让企业知道如何接管和退出
验收用例集	至少覆盖主流程和主要异常	让业务和测试用同一套脚本

作业步骤

1. 先写问题说明，再写功能清单。
2. 把流程、角色、数据和异常分别画出来。
3. 用一个真实场景写 3 条验收用例，含异常分支。
4. 列出所有账号、域名、云、数据库、接口和文档。
5. 把交接清单拿给业务负责人和 IT 各看一遍，确认谁接、谁管、谁能退。

AHAX 判断：如果一张项目章程写不出交接和退出，那这份章程还不够像企业文件，只像项目口头说明。

参考来源

主张	来源	发布机构	发布日期	URL	核验日期	使用边界
采购需求和履约验收在政府采购语境下属于结果管理环节，采购人负责组织确定需求并书面确认。	《财政部关于进一步加强政府采购需求和履约验收管理的指导意见》	财政部	2017-06-02	https://www.mof.gov.cn/gkml/caizhengwengao/2017wg/wg201702/201706/t20170602_2614096.htm	2026-07-15	只可作为政府采购方法参考，不能外推为商业项目统一法定节奏。
政府采购需求管理强调采购人组织确定需求、编制采购实施计划并实施风险控制。	《政府采购需求管理办法》	财政部	2021-04-30（通知页 2021-05-10）	https://gks.mof.gov.cn/guizhangzhidu/202105/P020210510621177265265.pdf	2026-07-15	只可作为需求管理方法参考，不能写成商业软件统一条款。
GB/T 45802-2025 页面可见的是标准号、发布日期、实施日期、现行状态及等同采用关系。	全国标准信息公共服务平台的 GB/T 45802-2025 标准页	国家市场监督管理总局 / 国家标准化管理委员会	2025-05-30	https://std.samr.gov.cn/gb/search/gbDetailed?id=36DE96AA3EACCD71E06397BE0A0A23D9	2026-07-15	只可支持需求工程标准元数据，不可写成全文或强制验收模板。
SSDF 是可并入各类 SDLC 的高层安全开发实践集合。	NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1	NIST	2022-02	https://csrc.nist.gov/pubs/sp/800/218/final	2026-07-15	只可用于安全开发方法参考，不是中国法定验收标准。
面向软件采购的联邦指南说明了应向软件生产者询问哪些问题。	Software Supply Chain Security Guidance Under Executive Order (EO) 14028 Section 4e	NIST	2022-02-04	https://csrc.nist.gov/pubs/other/2022/02/04/software-supply-chain-security-guidance-eo-14028-s/final	2026-07-15	只可作为供应链安全询问框架，不可直接照搬为商业采购法规。
SBOM 是描述软件构件及其供应链关系的正式记录。	Software Security in Supply Chains: Software Bill of Materials (SBOM)	NIST	2022-05-03（页面更新 2024-11-01）	https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-supply-chain-security-guidance-20	2026-07-15	只可支持依赖透明和可追溯性，不能替代验收或整改结论。
OWASP WSTG v4.2 覆盖 Web 应用安全测试主题，如身份、认证、授权、会话和输入校验。	OWASP Web Security Testing Guide v4.2	OWASP Foundation	页面可见版本 v4.2	https://owasp.org/www-project-web-security-testing-guide/v42/	2026-07-15	只可支持 Web 安全测试，不可替代 UAT、合同验收或法律判断。

边界说明

• MOF 只作政府采购方法参考，不作商业软件统一制度。
• GB/T 45802-2025 只支持需求工程元数据，不作法定模板。
• NIST SSDF、EO 14028 材料和 SBOM 只支持安全开发与供应链透明。
• OWASP WSTG 只支持 Web 安全测试，不替代 UAT 或合同验收。

最后核验：2026-07-15

上一章 | 返回专题总览 | 下一章