2023 年我接手一个烂尾项目，客户 IT 总监见面第一句话是：“上一家供应商的阶段验收报告写了 40 页，PPT 改了三版，结果上线当天批次追溯跑不通。”那 40 页里，32 页在讲项目背景和组织架构，真正写结论的只有 2 页，上面孤零零一句话，“本阶段各项功能已按计划完成”。没有环境快照，没有测试数据，没有遗留问题台账。这个项目后来返工 4 个月，直接成本超支接近 30%。
从那以后，我把阶段验收当成实施交付里最值得较真的一个环节。这篇文章不谈教科书定义，只讲我在 60 多个实施项目里反复验证过的做法：阶段验收怎么做，实施团队流程怎么优化，一个项目从 0 到 1 的每个阶段到底该留下什么、该卡住什么、该放过什么。
一、核心结论：阶段验收是“风险结算点”，不是签字仪式
先把结论摆出来，后面所有内容都是围绕这三条展开的论证。
第一，阶段验收的本质是结算风险，不是展示成果。验收会开得再热闹、PPT 做得再漂亮，如果没有把“这个阶段还剩哪些不确定性”变成一份有责任人、有截止日期的清单，这场验收就是无效的。成果展示解决的是“甲方领导开不开心”，风险结算解决的是“下个阶段会不会塌”。
第二，决定阶段验收质量的只有三个可量化指标：验收标准前置率、证据完整度、遗留问题闭环率。前置率指的是验收标准在阶段启动前就写完并双方确认的比例；证据完整度指的是六类交付证据的实际覆盖率；闭环率指的是遗留问题在约定周期内关闭的比例。这三个数字低于某个阈值，后面一定出问题，跟团队有多努力没关系。
第三，阶段验收做得扎实，终验周期能压缩 40% 以上，但投入不是越多越好。我在自己的项目样本里观察到，验收投入占总工时 15% 左右时性价比最高，超过 25% 后边际收益急剧下降，团队会被文档工作拖垮，反而没人做真实交付。
二、背景和真实场景：为什么“从 0 到 1”的阶段最容易失控
先看一个真实场景的时间线，它几乎是所有失控项目的共同剧本。
1. 一个典型的阶段验收现场
项目启动第 45 天，实施团队内部判断“功能开发完成度 90%”。第 46 天，项目经理通知客户：“下周三开阶段验收会。”第 47 天，实施团队开始通宵补文档。第 50 天，验收会如期召开，客户业务部门负责人临时出差，来了三个关键用户。
会上演示了 12 个功能模块，其中 3 个用的是演示数据而非真实迁移数据。客户提了 17 条意见，其中 9 条被记为“后续优化”，8 条被记为“需要确认”。会议纪要里写着“本阶段总体通过，遗留问题待双方进一步沟通”。没有人签字。
三周后，这 17 条意见变成了 31 条，客户内部又多讨论了几轮。项目正式验收被无限期推迟，实施团队一边做第二阶段，一边返工第一阶段。这个剧本我至少见过二十次。
2. 0 到 1 阶段失控的三个结构性原因
（1）需求理解处于“半成品”状态。0 到 1 阶段的特征就是双方对需求的理解都在演化，甲方在第一次看到系统之前，说不清自己真正要什么。此时如果验收标准按“初始需求文档”来写，几乎必然在验收会上被推翻。
（2）关键用户尚未建立使用习惯。阶段验收时，业务用户往往只见过两次系统。他们对系统的判断标准其实是“像不像我现在用的那个”，而不是“符不符合验收标准”。这会带来大量基于习惯而非基于需求的返工意见。
（3）实施团队和销售团队的承诺存在时间差。合同和售前方案里写的“支持灵活配置”，在实施阶段常常被理解成完全不同的东西。阶段验收就是这两个理解的第一次正面碰撞。
三方视角的错位，我在项目复盘里做过归类：甲方项目经理关心的是“进度可控、不出事”，甲方业务负责人关心的是“我的活别变多”，实施团队关心的是“赶紧签完签下一阶段”。三个诉求没有一个直接指向“系统是否真的可用”。这就是阶段验收会最容易跑偏的根因。
三、拆解六个常见误区
下面这六条，是我在项目复盘中见得最多、代价也最大的误区。每一条都配一个我见过的真实后果。
1. 误区一：把验收会开成汇报会
汇报会的逻辑是“我讲你听”，验收会的逻辑是“你验我证”。这两件事的结构完全不同。汇报会需要的是漂亮的时间轴和成果图，验收会需要的是可操作的测试步骤和可核对的原始数据。
我见过一个项目，验收会议程写了 90 分钟汇报 + 15 分钟答疑，结果客户从头到尾一句话没说，散会时丢下一句“我们内部再评估一下”。这个“再评估”持续了两个月。
2. 误区二：验收标准写成“满足业务需求”
“系统应支持灵活的审批流程配置”，这句话没有任何验收价值，因为“灵活”和“配置”都可以被无限解释。真正能用的验收标准应该是这个样子的：
【可验收标准示例】
场景：三级审批流配置
前置条件：测试环境 T2，管理员账号，流程设计器正常可用
操作步骤：
新建审批流，设置两级审批（部门经理 → 财务）
新增第三级条件审批（金额 > 500000 元时触发 CFO 审批）
保存并发布
验证用例：
单据金额 490,000 元：应只走两级审批
单据金额 510,000 元：应完整走三级审批
审批被驳回后重新提交：流程应回到第一级重新开始
判定标准：3 条用例全部通过，且执行时间不超过 5 分钟
证据要求：用例执行录屏 + 审批记录截图 + 环境版本号
两段文字的长度差不多，但后者的验收成本可能是前者的十分之一。因为前者会引发无限轮讨论，后者只需要判定“3 条用例过没过”。
3. 误区三：阶段做完才开始谈验收标准
这是最贵的误区。验收标准必须在阶段启动会上双方逐条过一遍，并且明确写进会议纪要。我在项目里定过一条硬规则：任何阶段如果没有在启动时确认验收标准，该阶段不得进入正式开发排期。
这条规则一开始被团队抱怨“太死板”，但执行两个季度后，阶段返工率从 27% 降到了 11%。原因很简单：想不清楚验收标准的阶段，本质上需求也没想清楚，早暴露比晚暴露便宜得多。
4. 误区四：遗留问题用口头承诺处理
“这个我们下个版本一定加上”，这句话在验收会上出现的频率极高，也是后期扯皮的主要来源。遗留问题必须进台账，台账必须有四个字段：问题描述、责任方、承诺完成时间、影响范围。
缺任何一个字段，这个问题在两周后就会变成“我们没说过”或者“这不在范围内”。
5. 误区五：把“客户没提意见”当成验收通过
沉默不是认可。在很多组织里，业务用户不提意见是因为提了也没用，或者因为不想在会上当“坏人”。真正的通过信号只有三个：书面签字、明确的条件验收结论、或者关键用户完成了真实业务场景的操作验证。
6. 误区六：验收文档集中在会前突击
突击补文档必然导致两个后果：一是证据是事后造出来的，经不起追查；二是团队通宵后状态极差，验收会上表现失常。正确的做法是文档随阶段推进同步生成，验收会只是“取出来、核对、确认”，而不是“现写”。
四、专业判断逻辑：什么样的阶段验收才有效
讲完误区，接下来是我自己的判断框架。它由四块组成：验收标准怎么定、证据链要什么、验收分几个时机、尺度怎么把握。
1. 验收标准三要素：可观测、可复现、可判定
可观测指的是标准必须指向一个能被看见的结果，而不是一种感受。“界面友好”不可观测，“列表页在 1920×1080 分辨率下无横向滚动条”可观测。
可复现指的是任何人按照步骤都能得到同样结果。这要求标准里必须写清前置条件：哪个环境、哪个账号、哪批数据。
可判定指的是结论只有两个状态，通过或不通过，不存在“基本通过”。一旦允许“基本通过”，这个阶段就会带着不确定性进入下一阶段。
2. 证据链六件套
验收会上客户最常问的一句话是“你怎么证明”。六个类别的证据基本上能覆盖 95% 的追问场景。
| 证据类别 | 具体内容 | 缺失时的典型后果 |
|---|---|---|
| 环境与版本快照 | 环境地址、版本号、构建号、部署时间 | 客户复现不了，质疑“是不是只在你机器上能跑” |
| 配置变更记录 | 参数配置清单、变更时间、变更人 | 上线后出问题无法回溯是哪次配置导致的 |
| 测试执行记录 | 用例清单、通过率、缺陷趋势曲线 | 无法证明“测试过”，只能靠口头保证 |
| 数据校验报告 | 迁移记录数、金额勾稽、抽样比对结果 | 财务类项目最致命，账不平就是验收失败 |
| 培训与关键用户确认 | 签到表、考核成绩、确认邮件 | 上线后用户不会用，责任无法界定 |
| 遗留问题与风险台账 | 问题描述、责任方、截止日期、影响范围 | 问题无限期挂起，成为终验的定时炸弹 |
我在一个 400 人规模制造企业的项目里做过对比：使用统一平台管理交付过程后，这六类证据的自动生成率从平均 45% 提升到 90% 以上，验收准备时间从人均 32 小时压缩到 9 小时。
3. 阶段验收的四个时机
很多人把阶段验收理解成一个时间点，其实它是一组时间点。我自己的做法是拆成四个。
- 预验收（内部）：对客验收会前 5-7 天，由实施团队内部或质量角色完成自检，输出自检报告和未达标项清单，不达标的直接推迟对客会议。
- 正式验收（对客）：按验收标准逐条核对，当场形成结论。结论只有三种：通过、条件通过、不通过。
- 条件验收：带条件通过时，必须附一份整改清单，明确整改项、责任人、完成时间，以及“条件未完成时的处理方式”。
- 终验：整体交付前的最后一次验收，重点是跨阶段遗留问题的总清理，而不是重新验收所有功能。
把预验收独立出来，是我认为投入产出比最高的一条流程优化。它把“在客户面前暴露问题”变成了“在自己团队里暴露问题”，心理成本低得多，也更容易被团队接受。
4. 验收尺度怎么定：不是越严越好
这是我想强调的一个反常识判断。把每个阶段的验收标准都拉满，是新人最容易犯的错误。
验收严格程度是有成本的。每增加一条验收标准，就意味着测试、取证、复核的工作量增加。如果标准数量超过了这个阶段真正承载的风险，团队就会把精力全部消耗在“证明自己没问题”上，反而没人去解决真正的问题。
我的判断逻辑是：按“失败后果的可逆性”来定尺度。失败后果不可逆的环节（比如财务数据迁移、生产环境切换、权限体系设计），验收标准必须拉满，宁可延期；失败后果可逆的环节（比如报表样式、非关键字段的校验规则、操作便捷性），用条件验收放行，把问题挂进台账，等下个阶段一起处理。
五、案例与数据观察：一家 400 人制造企业的阶段验收改造
下面这个案例是我参与过的真实项目，数据做了脱敏处理。
1. 项目背景与改造前的状态
客户是一家年营收 20 亿左右的制造企业，IT 与研发相关人员超过 400 人。项目内容是把原有的库存、生产、质量三条业务线系统做整合升级，分四个阶段实施，总周期 11 个月。
改造前，他们的阶段验收靠三样东西：Word 版验收报告、钉钉群里的沟通记录、以及实施顾问的本地电脑。问题出在第二阶段：客户质疑某项质量检验规则没有按需求实现，实施顾问翻出了三个月前的聊天记录，客户方已经找不到对应需求单，双方僵持了两周。
2. 我们做了什么
核心动作只有一件事：把阶段验收的证据链，从“人的记忆和本地文件”迁移到统一的项目管理平台上。这个项目最终选用的是 PingCode，主要原因是它能私有化部署在客户内网，满足制造业对数据不出厂的要求。
具体落地上，我们做了四件事：
- 把每个阶段的验收标准，转成平台上的验收任务。一条验收标准对应一个任务，任务里写清前置条件、操作步骤、判定依据。验收会不再是演示，而是逐条打开任务核对。
- 把需求、任务、缺陷、用例、版本建立关联。客户问“这条检验规则为什么是这个逻辑”，能直接沿着缺陷单追溯到最初的需求条目和变更记录，不用再翻聊天记录。
- 用里程碑管理四个阶段的关键节点。每个里程碑下挂验收清单，未完成的项在平台上直接可见，管理层看板上写的是“还有 6 项未闭环”，而不是“进展顺利”。
- 把遗留问题全部转成缺陷单。每张缺陷单必须填责任人和截止日期，逾期自动标红。验收会的结论从“会后沟通”变成了“台账上现在是 14 条，其中 5 条本周到期”。
补充一个细节：这个客户原本用的是 Jira，历史数据里有三年的需求和缺陷记录，直接关系到验收时能不能追溯到早期变更。迁移过程中，历史 Issue 的状态映射、关联关系和附件都做了保留，验收时可以直接查到两年前的一条需求变更。这一点对长期项目特别关键，验收证据的价值，很大程度上取决于你能往前追溯多久。
3. 改造后的数据变化
四个阶段跑完，我们对比了前后数据。为了更直观，我把改造前第一、二阶段和改造后第三、四阶段的关键指标放在一起。
| 指标 | 改造前（阶段一、二） | 改造后（阶段三、四） | 变化 |
|---|---|---|---|
| 验收准备人均耗时 | 32 小时 | 9 小时 | -72% |
| 验收会当场达成结论比例 | 38% | 81% | +43 个百分点 |
| 遗留问题按期闭环率 | 44% | 87% | +43 个百分点 |
| 阶段验收至下一阶段启动间隔 | 21 天 | 8 天 | -62% |
| 因验收争议导致的返工工时 | 286 人时 | 63 人时 | -78% |
需要说明的是，这些改善并非全部来自工具。验收标准前置、预验收独立、遗留问题台账化这三条流程规则，贡献了至少一半的效果。工具的作用是把流程规则固化下来，让规则不依赖某个人的自觉性。这两者必须配套，单独上工具不改流程，效果通常不到预期的一半。
六、不同情况下的行动建议
阶段验收的做法不能一刀切。下面按四种常见情况给出具体建议。
1. 私有化定制大项目：验收标准必须前置到合同级
这类项目周期长、金额大、返工成本极高。我的建议是在合同附件层面就定义清楚阶段验收的判定方式，包括每个阶段的验收清单模板、验收不通过时的处理流程、以及验收延期的责任划分。
执行上，预验收必须是强制环节，且预验收人不能是本阶段的开发负责人，要有独立角色。同时，考虑到这类项目通常对数据安全有硬要求，验收证据的存放位置要提前约定好，留在客户内网的私有化平台上，比散落在顾问个人电脑里要安全得多，也更容易追溯。
2. 标准化产品实施：用模板化验收清单降低边际成本
这类项目单个阶段的价值不高，如果每个项目都从头设计验收标准，成本会失控。正确做法是沉淀一套标准验收清单模板，按行业分类维护，项目上只做增量调整。
我的经验是，一个成熟的实施团队应该维护 3-5 套标准模板，覆盖 80% 的验收场景，剩下 20% 做定制。这样验收准备时间能压缩到人均 8 小时以内。
3. 无平台或平台能力弱的团队：先做“最小证据链”
不是所有团队都能立刻上平台。没有条件的情况下，我建议先做最小可用的证据链：一份共享的验收台账表格、一个统一的文件命名规范、一条“所有遗留问题必须有责任人”的硬规则。
这三件事的成本几乎为零，但能解决掉大约 60% 的验收争议。文件命名规范尤其重要，我见过太多项目因为找不到“哪个版本的测试报告”而在验收会上耗掉两个小时。
4. 甲方配合度低的项目：把验收拆小、频率提高
如果甲方关键用户经常缺席、意见反复，硬开大会只会消耗双方。这时候应该把阶段验收拆成多个小验收，每次只验一个业务域，时间控制在 60 分钟以内，参与人只需要该业务域的关键用户。
小验收的结论同样要书面化。累计若干个小验收通过后，再合并成一个阶段验收结论。这样既降低了对甲方时间投入的要求，也避免了“一次性验收失败”带来的心理障碍。
七、不同情况下的取舍
阶段验收里没有免费的午餐，下面四组取舍是必须做选择的。
1. 严格验收 vs 交付速度
严格验收能降低后期返工，但会拉长当前阶段周期。我的判断标准是看这个阶段的问题是否可逆。不可逆的环节（数据迁移、生产切换、权限设计）宁可延期也要卡死；可逆的环节（界面细节、报表格式、非关键校验）用条件验收放行。
把这两类混在一起处理，是最常见的失误，要么整体卡死导致进度崩盘，要么整体放行导致上线事故。
2. 文档厚度 vs 证据质量
40 页报告和 4 页报告，客户更信任哪个？答案取决于报告里有没有原始数据。我现在的做法是：验收报告正文控制在 6 页以内，其余全部作为附件，原始测试记录、截图、台账导出、日志片段。正文只写结论、未达标项和遗留问题。
厚文档的问题在于，它把关键信息稀释了。客户翻到第 30 页才发现问题，那时候会议已经接近尾声。
3. 平台化管理 vs 轻量落地
平台化管理的收益在项目数量多、周期长、人员流动大的时候才体现得明显。如果团队只有三五个顾问、项目周期两个月，强行上平台可能得不偿失。
我的经验分界线是：同时进行的实施项目超过 5 个，或者单个项目周期超过 6 个月，平台化的收益就开始超过成本。低于这个规模，共享台账加规范命名可能更实用。
4. 一次性验收 vs 分阶段条件验收
一次性验收的心理压力小，但对客户配合度要求高。分阶段条件验收更灵活，但管理成本高，且容易变成“永远在整改”。
折中方案是我最推荐的：每个阶段只开一次正式验收会，但结论允许是“条件通过”，条件是附带一份有明确截止日期的整改清单。这样既有明确的阶段结论，又不会因为个别小问题卡住整个项目。
八、总结与下一步
回到最开始那个烂尾项目。它真正的失败原因不是技术，而是把阶段验收当成了一次汇报演出，而不是一次风险结算。40 页报告里没有一条可执行的验收标准，没有一个环境版本号，没有一份遗留问题台账，所以问题只能留到上线当天。
我的独特判断可以浓缩成三句话。第一，阶段验收的质量取决于前置程度，而不是现场表现。标准在阶段启动时就该写完，验收会只是核对。第二，验收证据必须自动沉淀，不能依赖人的记性。谁能往前追溯得更久，谁在争议中就更有底气。第三，验收严格程度要按失败可逆性分配，不是越严越好。把有限的管理精力放在不可逆的环节上。
如果你正准备做下一个项目的阶段验收，我建议从这三件事开始：
- 把当前阶段的验收标准逐条改写成“可观测、可复现、可判定”的形式，改不出来的条目直接标为待澄清。
- 在对客验收会前 5 天做一次内部预验收，输出未达标项清单，不达标的推迟会议而不是硬上。
- 建立一份遗留问题台账，四个字段缺一不可，并在下次验收会开场时先过一遍上一阶段的台账。
这三件事不需要采购任何工具，也不需要审批流程，本周就能开始。真正的分水岭不在于你用了什么平台，而在于你是否愿意在项目最顺利的时候，仍然坚持把不确定性写下来、派给人、定下时间。
常见问题解答（FAQ）
1. 阶段验收到底验什么？验收标准应该什么时候定？
我带过好几个实施项目，每次到阶段验收就变成一场汇报会，客户听完说“整体不错，继续推进”，然后就过了。后来复盘才发现，从头到尾就没有一条能判定通过与否的标准，出问题时双方各说各话。
验收标准必须在阶段启动前就定下来，写进阶段启动会纪要或项目章程的附件里，包含三类内容：一是可交付物清单，明确文档、配置、数据、环境等具体产物，标注版本和交付形式；
二是验收判据，每条都要能用一句话判定通过或不通过，比如“10个核心业务场景在测试环境跑通，无阻断级缺陷”，不要写“满足客户需求”“符合业务预期”这类无法判定的词；三是验收方式，说清是现场演示、抽样检查、文档评审还是试运行若干天。
我一般要求单个阶段的验收判据不超过8条，超过8条通常说明阶段划分太粗，应该拆阶段而不是堆判据。实操上，阶段启动会上要和客户方业务负责人逐条过判据，当场确认口径，会议纪要当天发出并请对方回复“确认”。这一步多花一小时，后面能省两周扯皮。
2. 阶段验收和最后的客户终验有什么区别，人手紧的时候能不能合并？
我们团队人一直不够，很多时候想着反正最后都要终验，中间阶段就让客户口头点个头算了。结果到终验时客户翻脸，说这个功能不是他要的、那个流程没按他的习惯做，前面几个月的口头确认一条都不认。
两者不能合并，因为判定人、依据和后果完全不同。阶段验收是过程控制手段，判定人通常是双方项目经理加业务接口人，依据是本阶段约定的交付物和判据，后果只有两种：可以进入下一阶段，或者整改后复验。
终验是合同履约节点，判定人往往要上升到客户方分管领导甚至验收委员会，依据是合同和需求规格说明书，后果涉及付款和质保期起算。把阶段验收省掉，等于把所有风险堆到最后一刻集中爆发。
如果合同里只写了终验、客户组织流程也不支持中途正式签字，我的做法是在项目内部建立“阶段确认单”机制：每个阶段结束时发一份确认单或确认邮件，写清本阶段完成项、遗留项、下一阶段启动的前提条件，请客户接口人回复确认。它不具合同效力，但在后期出现范围争议时是最有用的证据。
只要客户流程允许，还是尽量把阶段确认写进合同附件。
3. 阶段验收没通过怎么办？项目卡在那里推不动怎么处理？
上次阶段验收，客户一口气列了17条问题，里面有几条明显是新增需求，但对方坚持要算进本次验收范围，双方在会上就僵住了，项目停了快两周。遇到这种情况到底该硬扛还是先让步？
核心动作是先把问题分类，再谈结论，不要在验收会上争论“这算不算需求”。我一般当场把所有意见分成四类：缺陷，即不符合已确认判据的；遗漏，即判据里有但没做的；变更，即判据里没有的新要求；理解偏差，即双方对同一条判据解释不同。分完之后，缺陷和遗漏进整改清单，明确责任人和完成时间；
变更走变更流程，评估工时和工期影响，必要时签补充确认；理解偏差当场对齐口径并形成书面解释。如果确实无法整体通过，用“带条件通过”：把不影响下一阶段启动的部分先确认，遗留项列为限期整改项，约定复验时间和范围，复验只验遗留项，不重验全部，这样项目不会停摆。
要避免的是无限期挂起，一旦超过约定复验时间两周仍未闭环，就必须升级到双方项目发起人层面处理，否则拖的是整个项目的工期和人力成本。
4. 阶段验收怎么留痕和沉淀，才能不靠某个人盯着？
我们做了三年实施，验收资料散在各个人的电脑和聊天记录里，负责的PM一走，接手的人连上一阶段验收结论是什么、遗留了什么都不知道，只能重新问客户，特别被动。
把验收做成“一套模板+一个台账+一个归档规则”就能解决大半。模板固定四份：阶段验收清单，逐条列判据和结果；验收会议纪要，记录参与人、结论和遗留项；遗留项跟踪表，包含编号、描述、责任人、期限、状态；阶段确认单或确认邮件记录。
台账建议放在某项目管理平台里，按项目再按阶段建任务，每条判据对应一条任务，状态只保留未开始、进行中、通过、不通过四种，遗留项挂成子任务，超期自动提醒，避免靠人肉记忆。
归档规则是每个阶段结束后三个工作日内，把上述四份文件放到项目共享目录的统一路径，命名遵循“项目名_阶段名_文件类型_日期”，同时把结论摘要写进项目周报。
我实际观察到的效果是，坚持这套做法的团队，单次阶段验收耗时从3到5天压到1到2天，返工集中在遗留项而不是全盘推倒重来，人员交接时新人看台账就知道项目走到哪一步、还欠什么，接手成本明显下降。
文章包含AI辅助创作：阶段验收怎么做？实施团队流程优化：项目阶段从0到1，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/329551
读者评论
验收标准前置确实有效，但中小项目里最难的是客户业务部门不愿在启动会投入时间，标准经常由实施方单方起草，最后只走邮件确认。15%工时投入听起来合理，可人手紧时，前置做扎实就意味着开发延期，销售和客户都不接受。更想知道合同范围模糊、客户内部还没定流程时，前置率怎么保证？
从测试角度看，六类证据里环境快照和测试记录最实用，但平台自动生成率不能只看工具，得看团队是否真在平台上执行用例和提缺陷，否则只是把纸质补录变成电子补录。数据校验报告在财务项目里尤其难，抽样规则和差异容忍度谁确认，往往比脚本本身更影响验收。
作为甲方IT，我不太看验收PPT，只关心关键用户能否用真实迁移数据走通核心场景。文章说沉默不是认可很对，但现实是业务部门怕担责，条件验收结论没人愿意签字。还有遗留问题台账，责任方写实施方容易，写业务方常被删掉。验收会至少应禁用演示数据，否则上线后扯皮更多。