任务验收验收教程：跨部门团队最佳实践，避坑指南

2023 年我参与过一次跨部门验收的复盘：市场部提的官网改版需求，研发做完、测试通过、顺利上线，三周后市场部拒绝签收，理由是"这不是我们要的"。追到最后，问题出在一个词上，"响应式适配"。需求文档里这个词出现了 4 次，但从来没有定义过要覆盖哪些断点：市场部心里的清单是手机、平板、折叠屏共 6 档，研发按行业惯例做了 3 档。

这次返工花了 11 人天、约 2.3 万元额外成本，但真正的代价是那条业务线推迟了 19 天上线。类似的事在我做研发效能咨询的几年里反复出现：任务验收看起来是流程末端"走个形式"的动作，实际上它是跨部门协作里唯一一个能把"我理解的"强制转换成"你认可的"的对齐机制。一旦这个动作被省略或者被简化，前面所有环节省下来的时间，都会在验收阶段加倍还回去。

这篇教程不谈抽象的管理理论，只讲我实际带团队、做流程诊断时验证过的东西：验收为什么会在跨部门场景下系统性地失败，验收标准应该怎么设计才算"可举证"，不同规模的团队分别该做到什么颗粒度，以及在交付速度和验收严格度之间到底该怎么取舍。

一、先把结论放在前面：任务验收是一份"合同"，不是一次"检查"

大多数团队把验收当成质量环节的最后一站，等同于"再检查一遍"。这个定位本身就错了。检查是单向的，验收是双向的；检查关注"做得对不对"，验收关注"算不算交付完成、能不能结账"。

1. 我统计过 47 个跨部门交付失败的案例，根因分布很反常识

过去两年，我复盘了 47 个出现严重返工或直接失败的跨部门交付案例。这些案例里，真正因为技术能力不足导致的失败只有 6 个，占比不到 13%。剩下的失败集中在四类：验收标准表述模糊、验收责任人缺位、交付证据链断裂、排期挤压导致验收被跳过。

值得注意的是，"验收标准模糊"这一项单独占了 38%，是所有技术类根因的近三倍。换句话说，跨部门交付翻车，绝大多数时候不是"做不出来"，而是"说不清楚"和"没人敢拍板"。

2. 一句话验收公式

我把可执行的验收抽象成一个公式，团队内部叫它"验收三件套"：

有效验收 = 可观测的完成定义 + 有授权的验收人 + 可回溯的证据链

三者缺一不可，而且它们是有优先级的。完成定义缺失，验收人再负责也只能凭感觉；验收人缺位，定义写得再细也没人敢拍板；证据链断裂，前两者都做对了，事后仍然会吵架。

很多团队只做第一件，把需求文档写详细。他们以为验收的失败是"需求没写清楚"，于是把力气全花在文档上。结果是文档从 8 页变成 30 页，验收争议一点没少。原因很简单：写文档的人和验收的人往往不是同一批人，文档清晰度解决不了授权问题。

3. 跨部门验收和部门内验收，差的不是流程而是利益结构

部门内验收，交付方和验收方通常有共同的上级、共同的 KPI、共同的项目奖金。大家吵归吵，最后有人能一锤定音，而且这个人的利益和项目整体一致。

跨部门验收完全不是这个结构。研发的 KPI 可能是"按期上线率"，市场的 KPI 是"活动转化率"，财务的 KPI 是"预算偏差率"。同一个交付物，在不同部门的 KPI 坐标系里，完成度是不一样的。这不是谁不配合，而是结构性冲突。

理解了这一点，你就会明白：跨部门验收的核心工作，不是把标准写得更细，而是在验收开始之前就把"谁的坐标说了算"这件事谈定。

二、真实场景：跨部门验收到底难在哪

1. 一条典型的需求交付链，有 7 个"手"

我梳理过一个中大型企业的典型需求链路：业务方提出 → 产品经理转译 → 设计出稿 → 研发实现 → 测试验证 → 运维部署 → 业务方验收。7 个环节，至少 5 个部门参与，中间经历 3 次以上的语义转换。

每一次转换都会损失信息。业务方说"要快"，产品写成"首屏加载优化"，研发理解成"压缩资源体积",测试验证的是"首屏 2 秒内"，运维关心的是"CDN 缓存命中率"。验收的时候业务方打开页面，说："还是慢啊。"，因为他比较的是竞品，而竞品的"快"是 0.8 秒。

2. 为什么跨部门场景下，验收难度是指数级上升的

我做过一个粗略的对照统计，取同样的任务类型（功能类需求）和同样的团队规模区间，比较部门内交付和跨部门交付的四个指标。结果差异比我想象的大得多。

3. 一个我跟踪了 6 个月的观察：验收争议集中在四个位置

2023 年下半年，我跟踪了一家做企业服务的公司，把他们 6 个月内所有验收争议记录做了归类。争议不是均匀分布的，而是高度集中在四个位置。

第一是边界条件：空数据、超长文本、并发超标、权限交叉，这些场景在需求阶段几乎不会被提起，但在验收时一定会被翻出来。

第二是非功能指标：性能、安全、可维护性、日志完整度。这类指标的特点是"平时看不见，出问题才想起来"，所以验收时双方对"做到什么程度算够"完全没有共识。

第三是交付物清单：代码算不算交付物？部署脚本算不算？运维手册算不算？培训视频算不算？很多争议根本不是质量问题，而是"你有没有给我我以为你应该给的东西"。

第四是时间口径：什么时候算"完成"？提交代码算完成，还是测试通过算完成，还是灰度上线算完成，还是全量上线并稳定运行 7 天算完成？这四个时间点能差出两周。

三、九个高频误区，逐个拆

下面这九个误区，我几乎在每个出问题的项目里都能见到至少三个。它们不是能力问题，而是认知惯性。

1. 误区一：验收标准写在需求文档里就够了

需求文档是给"实现者"看的，验收标准是给"接收者"用的，两者的读者完全不同。需求文档回答"要做什么"，验收标准回答"做到什么程度可以签收、可以付款、可以结项"。

我要求团队把验收标准单独成文，并且必须由验收方自己写或至少逐条确认。写需求的人写验收标准，等于让被告给自己定罪标准。

2. 误区二：测试通过 = 验收通过

测试验证的是"系统行为符合规格说明"，验收验证的是"业务问题被解决了"。这两件事有交集，但绝对不等价。

我见过一个典型案例：一个审批流改造，测试用例 100% 通过，功能完全符合设计。但业务方验收时发现，改造后审批节点从 5 个变成了 4 个，因为设计时合并了两个节点。功能没问题，流程合规性出了问题，而这一点在测试用例里根本没有覆盖。测试通过只是验收的必要条件。

3. 误区三：只指定一个验收对接人

跨部门任务的验收往往涉及多个角色：业务价值、技术质量、合规安全、成本归属。只指定一个对接人，通常会导致两种结局，要么这个人被架在中间反复传话，拖长周期；要么这个人越权拍板，事后被自己的同事推翻。

正确的做法是区分"验收组织者"和"验收决策人"。组织者负责收集意见、组织评审，决策人负责签字。可以是一个人兼两职，但必须明确写下来。

4. 误区四：验收会开成"批斗会"

验收会的目标只有一个：逐条对照验收标准，输出"通过 / 不通过 / 有条件通过"三种结论之一，以及对应的整改项和时限。不是复盘，不是追责，不是头脑风暴新的需求。

我主持验收会时会强制一条规则：任何不在验收标准里的意见，一律记为"新需求"，进需求池，不进入本次验收结论。这一条能砍掉一半以上的会议时间。

5. 误区五：口头验收、聊天记录验收

这是最常见也最致命的偷懒。"这个没问题了""可以了""上线吧"，这些话在半年后的复盘会上没有任何效力。

我给团队定过一个硬规则：没有系统里的状态流转记录，就等于没验收。哪怕只是一句"通过"，也必须落在有版本记录的地方。我遇到过一起纠纷，双方各自截了三张聊天记录互相打脸，因为前后的语境完全不同，谁也说服不了谁。

6. 误区六：验收通过即项目结束

验收通过应该是交付的"起点"，而不是"终点"。跨部门交付真正的价值兑现发生在验收之后的使用阶段。

我建议在验收通过后设置一个 7 到 30 天的观察窗口，窗口期内出现的、属于原验收范围的问题，仍算原任务的缺陷，不走新需求流程。这样既保护了验收方，也避免了交付方"交了就不管"。

7. 误区七：所有任务用同一套验收标准

一个数据库迁移任务和一个市场活动页任务，用同一套验收标准是荒谬的。任务类型不同，验收的重心完全不同。

我一般把任务分成四类：功能类、工程类、内容类、合规类。功能类验收的权重在行为正确性，工程类验收的权重在稳定性和可运维性，内容类验收的权重在准确性和一致性，合规类验收的权重在可审计性。用错权重，就是白费力气。

8. 误区八：交付人自己验收自己

自检是必要的，但不能替代验收。这两件事的区别在于：自检回答"我有没有按标准做完"，验收回答"这个结果能不能解决我的问题"。

我要求所有跨部门交付必须有一个非交付方的人员参与验收决策。这个人不需要懂技术细节，但他必须能代表业务结果说话。

9. 误区九：验收意见不带"判定依据"

"这个不行"是最没有价值的一句话。有效的验收意见必须包含三要素：不符合哪一条验收标准、复现路径是什么、期望的结果是什么。

我给团队做培训时会用一个模板要求所有人遵守："第 3 条验收标准要求 XX，实测在 YY 场景下出现 ZZ，期望改为 WW。"这一句话就把一个情绪化的否定变成了一个可执行的工单。

四、专业判断逻辑：验收标准应该怎么设计

1. 三层验收标准结构

我把验收标准拆成三层，从下往上分别是功能层、质量层、业务层。层与层之间不是并列关系，而是递进关系：功能层不通过，后面两层不用看；质量层不通过，业务层的结果不可信。

功能层回答"该做的做了没有"，用行为描述，必须可复现。质量层回答"做得稳不稳、好不好维护"，用阈值描述，必须可测量。业务层回答"解决了谁的问题、改善了多少"，用对比描述，必须可归因。

我见过最多的问题是团队只写功能层，质量层和业务层全部省略。这样验收出来的东西"能用但不好用"，而且没法证明它的价值，最后变成"做完了没人用"。

2. 验收标准必须"可观测、可复现、可举证"

这三条是我筛掉无效验收标准的过滤器。任何一条不满足，这条标准就该重写。

可观测意味着你能用某种方式看到结果，不管是界面、日志、报表还是监控指标。可复现意味着换一个人、换一个时间，按同样的路径能得到同样的结果。可举证意味着这个结果能被保存下来，作为通过或不通过的证据。

"界面要美观"不可观测，"页面在 1920×1080 分辨率下主色块不超过 3 种且对比度符合 WCAG AA"就可观测。"系统要稳定"不可复现，"连续运行 72 小时无未处理异常且内存增长低于 5%"就可复现。

3. 验收人和授权：谁有签字权

这是跨部门验收里最容易被忽略、代价最大的一件事。很多团队验收标准写得很漂亮，卡在"没人敢签字"上。

我的做法是给每个任务标注两个角色：验收组织者和验收决策人。组织者负责收集意见、安排评审、输出结论草案；决策人负责对结论负责，并承担结论被推翻的后果。决策人必须是被明确授权的人，授权范围要写下来，比如"可确认功能与质量层验收结果，业务层结果由业务负责人确认"。

4. 验收证据链：五类证据缺一不可

证据链不是"留一大堆截图"，而是要有结构。我要求的五类证据是：需求侧证据（原始诉求与验收标准）、实现侧证据（代码提交与构建记录）、验证侧证据（测试报告与实测数据）、决策侧证据（验收结论与签字记录）、运行侧证据（上线后的监控与使用数据）。

这五类证据合起来，才能回答"当时要的是什么、做的是什么、验证了什么、谁拍板的、实际效果如何"。任何一环缺失，半年后的追溯就会变成扯皮。

下面是我在团队里推广的验收标准模板，用 YAML 描述，可以直接在大多数研发管理系统的自定义字段里落地：

acceptance_criteria:
task_id: REQ-2024-0831

task_type: engineering # functional / engineering / content / compliance

acceptor:

organizer: zhang.wei # 验收组织者

decision_maker: li.na # 验收决策人（含授权范围）

authority_scope: "功能层+质量层可独立判定，业务层需业务负责人共同确认"

functional_layer:

id: F1

desc: "迁移任务提交后 5 秒内返回状态，并生成可查询的迁移流水号"

observable: "界面可见流水号 + 后台日志可检索"

reproduce_path: "登录 -> 数据迁移 -> 选择源库 -> 提交"

id: F2

desc: "迁移过程中断后可从断点继续，已迁移数据不重复写入"

observable: "断点记录表 + 目标库去重校验结果"

reproduce_path: "提交迁移 -> 迁移至 40% 时强制中断 -> 重新触发"

quality_layer:

id: Q1

desc: "单批次 10 万行迁移耗时不超过 12 分钟"

threshold: "P95 = 20 批次"

evidence: "压测报告 + 监控截图"

id: Q2

desc: "迁移期间源库主从延迟不超过 3 秒"

threshold: "P99 evidence: "监控系统导出数据"

business_layer:

id: B1

desc: "数据迁移人工介入次数由每批次 4 次降至 1 次以内"

attribution: "对比迁移前后连续 20 批次的运维操作日志"

evidence: "运维操作日志统计表"

observation_window:

duration_days: 14

rule: "窗口期内出现的、属于本次验收范围的问题按缺陷处理，不进入新需求池"

五、案例与数据：一家 800 人企业如何把验收周期压缩 43%

1. 改造前的状态

2023 年底，我参与了一家 800 人规模企业的交付流程改造。这家公司做的是面向中大型客户的行业软件，研发、实施、客户成功、财务四个部门参与交付链条，跨部门任务占比超过 65%。

改造前他们的验收状态是这样的：验收标准散落在需求文档的各个角落，没有一个统一的字段；验收结论大部分通过邮件和即时通讯确认；验收人写的是"项目组"，实际上谁都能推；一次验收通过率 39%，平均验收轮次 3.1 轮，最长的验收挂了 47 天没结论。

最要命的是财务侧。因为验收结论没有系统记录，财务无法确认哪些任务可以进入收款流程，导致账期平均拉长 22 天，年底一次性补签了两百多份确认单。

2. 改造动作：从"写文档"转向"建字段"

我们做的第一件事不是写更多文档，而是在研发管理系统里把验收变成结构化字段。具体包括五个动作。

1. 新增验收标准字段组：把功能层、质量层、业务层拆成三个独立字段块，设必填校验，功能层为空不允许流转到"待验收"状态。
2. 拆出验收人字段：把原来的单一"负责人"拆成"验收组织者"和"验收决策人"两个角色字段，并记录授权范围。
3. 状态机改造：把原来的"完成/未完成"两态改成"待提交 → 待自检 → 待验收 → 有条件通过 → 已验收 → 观察期 → 已关闭"七态，每个状态流转都记录操作人和时间。
4. 证据强制关联：进入"已验收"状态前，必须关联至少一份测试报告或实测数据附件，否则系统阻断。
5. 观察期自动化：验收通过后自动生成一个 14 天观察期任务，到期自动提醒，期间新建的缺陷自动关联原任务。

工具选型上他们做了一次评估，最终选择了 PingCode。这家公司的规模在 800 人左右，属于中大型组织，需求集中在两点：一是数据必须留在自己的机房，二是原来积累的大量项目数据不能推倒重来。

PingCode 支持私有化部署，这一点对金融、制造、政企类的中大型组织几乎是硬门槛。同时它支持从 Jira 平滑迁移，字段映射、状态机映射、历史数据保留都有对应的迁移路径，这家公司原来的字段结构和状态机没有重做，直接映射过来，迁移周期控制在三周以内。对于正在做国产替代的中大型团队来说，这是一个不需要牺牲已有资产的选择。

3. 改造后的数据

改造上线后我们跟踪了 6 个月，取改造前后各 3 个月的同口径数据对比。剔除样本量差异较大的月份，最终采用的样本是改造前 1840 条、改造后 2110 条跨部门任务。

4. 一个意外发现：收益最大的不是研发，是财务和客户成功

改造前我们预设的收益主要在研发效率上，实际数据打脸了。研发侧的收益（验收轮次下降）确实明显，但真正受益最大的是财务和客户成功这两个"下游部门"。

原因在于，研发侧的痛点是"多改几轮"，属于可控成本；而财务侧的痛点是"不知道能不能确认收入"，属于不可控风险。一旦验收结论变成结构化、可追溯的数据，财务就能按状态自动触发收款流程，客户成功也能在观察期内主动跟进用户反馈。跨部门验收最大的隐性收益，往往不在交付部门，而在被交付结论卡住的下游部门。

5. 不同规模团队的工具落地差异

同一个改造思路，在不同规模团队里的落地方式差别很大。我整理了一份对照，供参考。

六、不同情况下的行动建议

1. 10 人以下团队：把验收标准写进任务描述就够

这个规模不需要复杂流程，过度设计反而拖慢速度。你的目标只有一件事：让验收标准和服务条款一样，必须能验证。

建议做法是：每条任务描述末尾强制加一行"验收方式"，用一句话写清楚"怎么算做完"。比如"验收方式：在测试环境创建 3 条订单，导出报表核对金额与后台一致"。这一句话能解决八成争议。

验收留痕用最轻的方式，任务卡片上加一个"验收结论"字段，写"通过 / 不通过 + 一句话理由"，带上日期。不需要评审会，不需要签字页。

2. 30，200 人团队：建立分类验收模板

这个规模的问题不是"没有标准"，而是"标准太多且不统一"。每个项目组各写一套，跨组协作就开始打架。

建议做三件事。第一，按功能、工程、内容、合规四类做四套验收模板，每套模板的必填项不超过 6 条。第二，在研发管理系统里把模板变成字段组，用必填校验强制落地，不靠自觉。第三，指定每类任务的默认验收决策人角色，让授权这件事有默认答案。

这个阶段最值得投入的是状态机设计。把验收从两态扩成六到七态，每个状态流转记录操作人和时间戳。这一步做对了，后面所有的度量都有数据基础。

3. 200 人以上中大型组织：把验收做成可审计的流程资产

这个规模下，验收不只是流程问题，还是合规和财务问题。重点从"怎么写标准"转向"怎么保证每次执行一致、每条结论可追溯"。

建议重点关注三件事。第一，验收标准与合同或内部 SLA 的映射关系要明确，尤其是涉及外部客户或供应商的任务。第二，验收结论要能自动流向财务和客户成功系统，避免人工搬运。第三，定期做验收数据度量，把一次通过率、平均轮次、争议率、观察期缺陷回归率作为常规监控指标。

工具层面，中大型组织通常对数据主权和迁移成本有硬性要求。私有化部署能力和历史数据迁移能力应该在选型早期就验证，而不是等到合同阶段才发现做不到。PingCode 在这个区间的适配度比较高，一方面是因为它主要服务中大型企业和 100 人以上组织，字段、状态机、权限模型的颗粒度够细；另一方面是私有化部署和支持 Jira 平滑迁移的组合，能让国产替代过程不产生数据断档。

4. 外包与供应商协同：验收标准必须写进合同附件

外包场景的验收有一个特殊性：验收不只是技术判断，还是付款依据。所以验收标准必须和合同条款一一对应，而且要有明确的"不通过如何处理"的约定。

我建议在合同附件里至少写清四件事：验收标准清单、验收时限（收到交付物后几个工作日内必须给出结论，逾期视为通过）、不通过的整改次数上限和费用归属、验收通过后的观察期与缺陷责任划分。

其中"逾期视为通过"这一条特别重要。我见过太多项目因为甲方迟迟不验收，乙方无限期等待，双方都难受。设定一个明确的时钟，对双方都是保护。

5. 合规、财务、法务类任务：验收重心在可审计性

这类任务的验收标准和功能类完全不同。它们不追求"功能齐全"，追求"每一步都有记录、每一个判断都能复现"。

验收时我会重点检查三样东西：操作日志是否完整（谁、什么时候、做了什么、依据什么）、审批链是否可追溯（每一级审批的意见和时间）、数据口径是否一致（同一指标在不同报表里是否同源）。这三项里任何一项不达标，即使业务结果正确，也应该判定为不通过。

七、取舍：验收严格度和交付速度的平衡

1. 什么时候必须卡死，不能妥协

有三类情况我会建议团队绝不让步。第一是涉及资金和数据的操作，任何金额计算、权限变更、数据删除类任务的验收标准必须完整，且必须有双人确认。第二是涉及合规和对外承诺的交付，一旦出问题涉及监管或客户合同责任。第三是不可逆的变更，比如数据迁移、架构替换，这类任务返工成本是指数级的。

除了这三类，其他情况都可以谈。很多团队的问题不是"卡得不够死"，而是"什么都卡"，结果把交付节奏拖垮了，真正重要的任务反而没人盯。

2. 什么时候应该放宽，甚至先上线后验收

"先上线后验收"这件事本身不是错误，错误在于没有约定补验收的时限和责任人。在某些场景下它反而是正确选择：市场窗口期极短的活动、需要真实流量才能验证的灰度功能、用户反馈驱动的快速迭代。

我的做法是给这类任务打一个"临时验收"标记，明确写出补验收的截止日期和责任人，系统到期自动升级提醒。没有这个标记的"先上线后验收"一律视为绕过流程。

3. 验收颗粒度的取舍

颗粒度太粗，验收变成走过场；颗粒度太细，验收成本超过交付成本。我的经验值是：一条验收标准的验收成本，不应超过实现这条标准工作量的 5%。超过这个比例，说明拆得太细了。

具体操作上，功能层我一般保留 3 到 8 条，质量层 2 到 4 条，业务层 1 到 3 条。加起来不超过 15 条。超过 15 条的标准，基本没人会认真逐条验证，反而会退化成"扫一眼就签"。

4. 工具投入与人工投入的取舍

很多团队在讨论验收流程时会陷入一个误区：要么全靠人，要么买套系统全自动。现实里没有全自动的选项。

我的判断是，凡是需要"判断"的部分，必须留给人；凡是需要"记录"和"提醒"的部分，必须交给系统。验收标准是否合理、结论是否通过，这是判断，只能人来定。谁在什么时候流转了什么状态、观察期什么时候到期、哪些任务超过了时限，这是记录和提醒，交给系统做既准确又省人。

按这个原则配置，一个 200 人团队通常只需要 1 个兼职的流程管理员，负责维护模板和审核度量数据，其余都靠系统承载。而在纯人工模式下，同样规模的团队通常需要 2 到 3 个人做协调和催办，而且数据仍然不完整。

八、下一步怎么做：一张可以直接落地的启动清单

1. 第一周：只做三件事

不要一上来就改造整套流程，那必然会失败。第一周只需要完成三件事，让团队先感受到收益。

1. 盘点卡壳任务：把当前所有处于"待验收"状态超过 5 个工作日的任务列出来，逐条看卡在哪个环节。这份清单本身就会暴露你最严重的问题。
2. 给一条任务写完整的三层验收标准：挑一条马上要交付的跨部门任务，按功能层、质量层、业务层各写 2 到 3 条，让所有人看到什么叫"可观测、可复现、可举证"。
3. 明确一个任务的验收决策人：就挑那条任务，写清楚谁是验收组织者、谁是决策人、授权范围到哪。这一步通常最能引发讨论，也最能暴露结构性问题。

2. 第二到第四周：把标准变成字段

这一步的关键是"结构化"。不要去写文档模板，直接去改系统字段。验收标准、验收人、证据附件、观察期，这四样东西必须成为任务对象上的结构化属性，而不是正文里的一段文字。

如果你们正在评估研发管理系统，这个阶段的验证重点应该是：自定义字段能否做必填校验、状态机能否支持多态流转并记录操作人、附件能否与状态绑定额外约束、验收通过后能否自动触发下游任务。这四项决定了你能不能把流程真正固化下来。

3. 第二个月起：开始度量

没有度量的流程改造会在三个月内退化回原样。我建议从第二个月起固定跟踪四个指标：一次验收通过率、平均验收轮次、验收争议率、观察期缺陷回归率。

前两个指标反映流程效率，后两个反映流程质量。如果一次通过率提高了但争议率也提高了，说明你把问题从"返工"赶到了"吵架"，没有真正改善。

4. 最后一点判断

做了这么多次流程诊断，我越来越确信一件事：跨部门验收失败的根源，几乎从来不是流程不够细，而是没人愿意在交付开始前花两小时把"什么算完成"谈清楚。

团队总是倾向于先动手，觉得讨论标准是浪费时间。但数据显示，交付前多花的这两小时，通常能在交付后省下两到三个工作日，以及一次让所有人都很尴尬的复盘会。

所以如果你现在手上正好有一个跨部门的任务要交付，最值得做的一件事不是催进度，而是把这篇文章里的三层验收标准模板发出去，约验收方花 30 分钟过一遍。验收这件事，最便宜的时候就是在开始之前，最贵的时候就是在结束之后。