版本管理版本状态全流程：管理层协同管理与一文讲清

版本管理最容易失控的时刻，通常不是团队没有版本号，而是同一个版本在不同人的表格里处于不同状态：研发认为“已提测”，测试认为“缺少环境”，产品认为“功能还没冻结”，管理层却在会上听到“本周可以上线”。版本管理真正要解决的，不是给版本贴标签，而是让每个角色基于同一组事实，判断版本现在在哪里、下一步由谁推进、什么条件下可以继续。

一、核心结论：版本状态不是标签，而是协作契约

1. 状态必须同时回答三个问题

我判断一个版本状态体系是否可用，通常先看它能不能回答三个问题：当前版本处于哪个阶段；进入下一阶段必须满足什么条件；如果条件不满足，谁负责处理。只写“进行中、已完成、已发布”，却没有准入条件和责任人，状态就只是看板上的颜色，不是管理机制。

因此，版本状态应被设计成一组协作契约。状态代表事实，入口条件代表门槛，退出条件代表交付结果，责任人代表推动者。管理层看到状态后，应能据此判断风险和资源，而不是再开一轮会核实“这个完成到底是什么意思”。

核心结论是：状态少而清楚，门槛明确且可验证，例外有路径，历史可追溯。与其设计十几种看似精细的状态，不如先把需求承诺、研发执行、测试验证、发布准备、上线观察这几个关键交接点管好。

2. 状态流程建议从“承诺”走到“验证”

对于有产品、研发、测试、运维和业务参与的团队，我通常建议先采用一条可落地的主流程：规划中、已承诺、开发中、待测试、测试中、待发布、发布中、已发布、已关闭。暂停、取消和回滚不应被塞进主流程里伪装成正常阶段，而应作为异常状态或结果状态单独处理。

这套流程不是要求所有组织照抄。小团队可以合并“待测试”和“测试中”；发布频率高的团队应把灰度和全量发布拆开；受监管业务则需要增加审批、证据留存和变更窗口。关键不是状态名称完全一致，而是每次交接都能找到清楚的进入条件。

3. 管理层关注的不是状态数量，而是决策信号

管理层最需要的并非每个任务的细枝末节，而是能够改变决策的信息：版本是否仍有按期发布的把握；关键依赖是否失控；风险是否需要跨部门协调；是否应削减范围、增加资源或调整窗口。状态体系应该把这些信号显性化，而不是让管理者从几百条任务里自己推断。

版本管理也不等于项目管理的全部。它只负责一个重要切面：把一组需求、缺陷、代码变更、测试结果和发布动作绑定到同一交付对象上。一个版本可以关联多个项目，也可以只是一个产品的一次迭代；范围应由业务边界决定，不应被工具中的字段结构反向绑架。

二、背景与真实场景：为什么“看起来完成”仍可能无法发布

1. 典型冲突发生在跨角色交接处

在中大型组织里，版本不只是研发团队的内部安排。产品需要确认范围，研发需要评估容量，测试需要准备环境，运维需要核对发布窗口，业务方还要安排培训或客户沟通。每个团队都有自己的工作节奏，但版本只有一个最终结果：能否在约定范围和时间内安全交付。

一个常见场景是：版本看板显示开发任务完成率接近百分之百，测试团队却还没拿到稳定构建包；另一种场景是测试通过，但数据库变更方案、监控告警或回滚脚本尚未确认。此时，“开发完成”与“可以上线”之间存在真实的交付缺口。

如果状态定义只覆盖研发内部，那么管理层看到的进度会系统性偏乐观。不是团队在故意报喜，而是每个角色都用自己熟悉的口径表达“完成”。版本管理的价值，正是把这些口径统一到可验收的阶段门槛上。

2. 版本不是一条直线，而是带分支的状态机

理想流程看起来像一条线，真实流程却会发生退回、暂停、拆分、取消和回滚。例如，测试发现严重缺陷，版本从测试中退回开发；外部依赖延迟，版本进入暂停；业务优先级变化，部分需求从本版本移出；上线后出现故障，版本进入回滚或热修复处理。

这些情况不应被当作流程失败而隐藏。成熟的管理方式不是假设项目永不偏离，而是让偏离有记录、有责任人、有重新进入流程的条件。若团队为了让看板“好看”而把阻塞事项留在原状态，管理层收到的就不是进度，而是经过修饰的叙述。

下面的示意数据呈现一类常见的交付路径变化。它是用于解释流程管理的情景模拟，不代表行业统计。重点不是某个比例是否适用于你的团队，而是开发完成之后仍有多道需要明确验收的交接。

3. 规模越大，版本状态越需要跨团队共识

人数增加后，口头同步的成本会快速上升。一个由十几人组成的小组，站会里就能问清关键事项；当多个产品线、共享服务团队和区域业务共同参与，一个版本可能同时依赖多个团队的交付。此时，每个人都知道“自己做完了什么”，却不一定知道“整体是否已经具备交付条件”。

对于 100 人以上的组织，版本状态通常要同时服务执行团队和管理层：执行团队需要看到任务级阻塞和责任人，管理层需要看到里程碑、风险与决策请求。以 PingCode 这类面向中大型企业及 100 人以上组织的研发管理平台为例，使用价值不应只看能否建立版本字段，还应看需求、迭代、缺陷、测试与发布信息能否关联起来，并支持不同角色使用一致的口径协同。

工具能提供记录和视图，但不能替团队决定什么叫“可发布”。如果组织没有统一门槛，换任何平台都只会把分歧从会议室搬到系统里。因此，流程定义要先于自动化配置，工具落地则要服务于已经明确的协作规则。

三、常见误区：状态越多，不代表管理越细

1. 把“完成率”当成版本健康度

任务完成率是一个方便但危险的指标。它只反映已登记工作中有多少被标记为完成，不说明工作是否覆盖完整范围，也不说明测试质量、发布准备和线上结果。若团队把完成率当作唯一进度指标，最容易出现“任务都关了，版本却仍不能上线”。

我更愿意把完成率与关键门槛一起看：范围冻结率、提测准入率、严重缺陷数量、发布检查项完成率、关键依赖按期率。单个指标容易被误读，多项指标之间的矛盾反而能暴露真实风险。比如完成率很高但提测准入率低，问题可能不在研发效率，而在测试交接或构建稳定性。

2. 把状态当成工作量分类

“开发中”不是所有未完成工作的收纳箱。需求尚未澄清、等待第三方接口、代码正在实现、评审未通过，都是完全不同的问题。如果都被放在同一状态，管理者无法知道应该协调产品、研发、供应商还是架构团队。

解决办法不是无限增加状态，而是保留少量主状态，并使用阻塞原因、风险等级、下一步动作和责任人补足信息。状态回答“在哪一阶段”，阻塞原因回答“为什么没有推进”，责任人回答“谁推动解阻”。把这三个维度混成一个状态字段，通常会导致状态爆炸。

3. 把“已发布”当作“已成功”

部署完成只是技术动作，不等于业务成功。发布后可能有错误率升高、关键流程转化下降、客户反馈集中或数据迁移异常。若版本一上线就标记关闭，团队失去追踪线上结果的窗口，也容易把发布故障排除在项目复盘之外。

对风险较高的版本，应明确观察期和关闭条件。低风险内部工具可以用较短观察周期；涉及支付、权限、数据迁移或大范围客户的变更，则应按业务风险设置更严格的监控和复核。观察期不是形式主义，而是发布决策的一部分。

4. 为每个角色创建一套状态口径

产品称“已完成”可能意味着需求范围已定，研发称“已完成”可能意味着代码合并，测试称“已完成”可能意味着验收通过，运维称“已完成”可能意味着发布记录归档。若每个角色都维护自己的状态，跨部门报告就只能靠人工翻译。

不同角色可以拥有不同视图和权限，但底层状态定义应一致。产品负责人看需求和范围，测试负责人看验证项，管理层看里程碑与风险；这叫按角色呈现同一事实，不是为每个角色制造不同事实。

5. 用审批数量制造控制感

状态变更审批并非越多越安全。若每次从“开发中”改为“待测试”都需要多人逐级批准，团队会绕开系统或集中补录，数据最终失真。审批应该放在真正改变风险和承诺的节点，例如版本范围冻结、生产发布批准、重大变更或回滚决策。

日常状态流转更多适合依赖可检查的条件和自动校验。例如，缺少测试报告时不允许进入“待发布”；没有回滚方案时，高风险变更不能通过发布准备检查。把审批留给管理判断，把规则校验交给流程，通常比凡事签字更有效。

四、专业判断逻辑：如何设计一套可执行的状态体系

1. 先定义版本对象，再讨论状态名称

版本状态混乱，往往是因为团队还没说清楚“这个版本究竟是什么”。它可能是某个产品的月度迭代、一个客户项目的交付包、一组微服务的联合发布，也可能是移动端应用的商店版本。对象边界不清，需求、缺陷、代码和发布动作就无法形成稳定关联。

我建议先写清四项定义：版本包含哪些产品或服务；范围由哪些需求和缺陷组成；版本计划由谁维护；什么事件代表版本完成。若一次发布跨多个系统，应明确主版本与子版本的关系，避免一个子系统已上线就把整体版本误标为完成。

2. 用入口条件和退出条件定义状态

一个状态不是一句描述，而是一组可检查的事实。以下表格提供一个起点，组织可以根据发布风险和研发模式调整，不必把每条检查项都配置成系统硬门槛。

退出条件要尽量写成可观察的动作或证据，而不是“相关人员确认无误”。比如“测试完成”可以定义为关键用例通过、阻断缺陷为零、剩余缺陷有负责人和处置期限。这样做不是不信任专业人员，而是让跨团队协作不依赖每次重新解释。

3. 将主状态、风险状态和结果状态分开

状态体系最好至少区分三种信息。主状态描述生命周期阶段；风险状态描述当前健康度，如正常、关注、阻塞；结果状态描述最终结局，如已发布、取消、合并到其他版本或回滚。把“阻塞”当成生命周期阶段，容易造成解除阻塞后不知道回到哪里；把“取消”当作普通完成，也会掩盖计划变化。

例如，一个版本可以处于“测试中”，风险状态为“阻塞”，阻塞原因是共享测试环境不可用，责任人是环境平台主管。管理层一眼能看出它走到哪个阶段、为什么停住、需要谁行动，而不是只看到一个含糊的“暂停中”。

4. 设定清晰的异常路径

异常路径至少要覆盖暂停、范围变更、取消、延期、紧急发布和回滚。每条路径都应回答：谁可以发起；需要记录哪些原因；原计划如何更新；是否需要重新评估容量、测试和审批；异常解除后回到哪个状态。

尤其是范围变更，不能只在版本备注里补一句“临时增加”。新增事项会影响容量、测试组合、发布风险和其他承诺。若版本中途变化，建议记录变更前后范围、发起人、决策时间、影响评估及是否调整发布日期，避免复盘时只剩下“感觉工作量变大了”。

5. 依据风险分层设置门槛

门槛并不适合一刀切。内部低风险文案调整、影响单一业务线的功能、涉及核心交易或大规模数据迁移的变更，应该有不同的检查强度。风险分层可以考虑用户影响范围、数据可逆性、依赖数量、故障影响时长和监管要求。

下表是一个建议基准，不是通用行业标准。团队可以先用它讨论风险，再用历史事故和变更结果校准分级，避免所有发布都走最重流程，也避免高风险变更与普通更新使用同一套轻量检查。

五、案例与数据观察：一份版本台账怎样变成决策依据

1. 情景案例：问题不是开发慢，而是交接定义缺失

下面用一个匿名化的情景模拟说明判断方法，不将其包装成某家企业的真实统计。设想一个约 160 人的产品研发组织，多个团队共用测试环境，每两周计划发布一次。过去管理会上常出现“开发基本完成”，但版本仍反复延期，团队初步归因于估时不准。

把版本的阶段时间拆开后，问题可能呈现为另一种结构：开发时间并非唯一瓶颈，等待测试环境、提测材料返工、依赖团队响应和发布窗口冲突，才是计划偏差的重要来源。若只继续压缩开发排期，短期看板数字可能更好，实际交付却未必提前。

以下数据为情景模拟，目的在于展示如何从周期构成中找改进点。正式使用时，应从团队自己的系统记录中提取时间戳，并定义统一的统计口径，例如起算点、暂停时间是否剔除、版本拆分如何计入。

2. 先查分布，再决定改哪条流程

总平均周期容易掩盖少数极端版本。比如大部分版本按期完成，少数跨团队版本因为依赖等待而拖延；此时统一增加研发人力，可能既不能解决依赖，也会提高并行工作量。建议同时看中位数、分位数和延期版本构成，尤其关注高分位周期，以发现长尾阻塞。

按期率也需要明确口径。计划日期是否允许基线变更？被业务主动取消的版本算不算延期？范围缩减后按期发布是否算达成？若这些边界未统一，不同部门会用各自算法汇报，数字看似精确，实际不可比较。

3. 用变更记录解释计划为什么偏离

在情景案例中，假设连续六个版本里有三个发生计划发布日期调整。若团队只统计“延期三个”，管理层知道结果，却不知道要采取什么措施。若进一步记录调整原因，例如外部依赖、范围变更、环境等待、缺陷返工和发布窗口冲突，就能判断问题是否集中在少数可治理环节。

下图使用假设数据展示原因分类方式。真实团队不应为了填满分类而强行归因；应允许“未明”暂时存在，并通过复盘补齐证据。分类价值在于找到下一步调查方向，而不是把责任简单归到某个部门。

4. 看状态停留时间，找到流程的“拥堵段”

与其只看版本当前状态，不如计算各状态停留时间。开发中停留时间长，可能是任务拆分不合理、依赖阻塞或容量不足；待测试停留时间长，可能是测试资源或提测质量问题；待发布停留时间长，则可能与审批、窗口或发布准备有关。停留时间是诊断线索，不是直接的绩效排名。

建议至少观察每个状态的中位停留时间、较长尾部版本数量、超时版本占比和超时原因。若只看平均值，个别极端情况会扭曲结果；若只看中位数，又可能看不到高风险长尾。两者结合，才能兼顾常态表现与异常版本。

5. 管理层看板应减少“解释型汇报”

一个有用的版本看板，不是把所有字段都摆出来，而是让管理者迅速回答四个问题：计划是否可信；当前最大风险是什么；谁在处理；需要何种决策。若会上仍要逐条询问“这个为什么红、红了多久、谁负责”，看板就没有把协作信息组织好。

可以将版本视图分成三层：第一层是管理层的里程碑、健康度和决策请求；第二层是团队负责人关注的依赖、阻塞和阶段周期；第三层是执行者的任务、缺陷、验收项和证据。三层数据应来自同一套记录，只是展示粒度不同。

六、不同角色如何协同：让状态变更带着责任前进

1. 管理层：负责取舍，不代替团队更新状态

管理层不应成为每一次状态变更的审批节点。其职责是设定目标优先级、明确资源边界、处理跨部门冲突，并对重大范围和风险做取舍。管理层需要看到的不是“所有任务都按计划”，而是偏差出现时是否及时暴露、是否有明确选项、是否有人负责推动。

当版本有延期风险，汇报不应只说“可能延期”，而要说明影响范围、原因证据、已尝试措施、可选决策及其代价。例如：保持范围可能需要调整日期；保持日期可能需要削减低优先级需求；保持两者都不变则需要补充资源，并说明新增资源何时能产生效果。

2. 产品负责人：管理承诺边界和范围变化

产品负责人的核心动作不是不断把需求塞进版本，而是维护版本目标、优先级和验收标准。进入“已承诺”前，应确认需求是否足够清楚、业务价值是否明确、关键依赖是否已识别。范围变化时，需要判断它是否值得挤占现有承诺，并与研发和测试一起评估影响。

产品负责人还要避免把未完成的需求描述包装成“暂时不影响排期”。如果验收条件尚未确定、关键流程仍在讨论，团队就应记录为待澄清，而不是提前进入开发并在后期通过返工支付成本。

3. 研发负责人：为交付条件负责，而不只为代码负责

研发负责人需要推动任务拆解、技术依赖确认、构建可用性和提测材料准备。若代码完成但部署脚本、配置说明或数据迁移方案缺失，版本仍未达到团队定义的交接条件。研发负责人也应及时报告技术风险，不要等到测试阶段才暴露早已存在的依赖问题。

对跨服务版本，建议明确每个子团队的交付状态和集成负责人。主版本不能只依赖各团队口头承诺“差不多完成”，而应通过可运行的集成构建、接口验证或替代方案，确认依赖在目标环境中的表现。

4. 测试负责人：管理验证范围与风险，而不只是执行用例

测试负责人应在版本承诺阶段参与风险识别，明确测试范围、环境需求、关键验收路径和时间窗口。若测试在版本后半段才知道需求变化，团队会把测试排队误判成测试效率问题，实际根因可能是计划阶段缺少测试输入。

测试结论也不宜只有“通过”或“不通过”。应区分关键路径是否通过、未解决缺陷的严重性、已知限制和建议的发布范围。业务负责人和管理层据此决定是否接受残余风险，而不是把专业判断压缩成一个无法解释的颜色。

5. 运维与业务角色：提前进入发布准备

运维不应等到测试通过后才第一次看到版本。对于涉及基础设施、配置、数据迁移和容量变化的发布，部署方式、监控指标、应急联系人和回退条件需要提前设计。业务方则应在发布前准备客户沟通、运营安排、培训和支持渠道。

提前协同不代表所有角色从规划阶段就参加每场会议。更高效的做法是根据风险和依赖设置检查点：低风险版本采用轻量确认，高风险版本提前评审关键方案。这样既避免信息过晚，也减少不必要的会议负担。

6. 用责任矩阵避免“大家都负责，所以没人负责”

建议每个关键阶段只设置一个最终责任人，参与者可以有多位，但对交付结果的最终推动者必须明确。下表是角色分工示例，组织可按产品与发布模式调整。

七、行动建议：按组织成熟度逐步落地

1. 小团队：先把交接说清，不急着建复杂审批

团队人数较少、系统依赖简单时，先建立六到八个主状态即可。重点是明确版本负责人、范围冻结时间、提测条件、发布条件和异常处理方式。先用一份精简版本模板跑两三个周期，再根据实际卡点增加字段，比一开始配置几十个状态更稳妥。

小团队可以采用低成本的复盘方式：每个版本结束后记录计划与实际周期、最大偏差、返工原因、线上问题和一个最值得改进的动作。不要一次列出十几个改进项，优先选一个能在下个版本验证的改动，例如提测材料检查或依赖承诺日期。

2. 多团队组织：统一定义，保留团队差异

多个团队协同时，应先统一状态语义、版本标识、关键时间戳和风险分类，再允许不同团队保留适合自身的子流程。统一的是跨团队交接契约，不一定是所有团队内部完全相同的工作方法。

例如，移动端团队可能需要商店审核阶段，后端团队可能有灰度与逐步放量阶段。它们可以在团队内部使用不同子状态，但都应映射到组织层面可理解的“待发布、发布中、已发布”阶段，并明确主版本的整体完成条件。

3. 高风险业务：为控制点投入更多成本

涉及资金、隐私、核心交易、医疗或关键基础设施的版本，应把风险分级、审批责任、回退策略和证据留存纳入流程设计。发布前要确认的不只是“测试通过”，还包括影响范围、故障检测方式、止损阈值、数据恢复策略和事件响应联系人。

但高风险不等于所有变更都采取同一套重流程。可以根据影响范围和可逆性区分标准变更、常规变更和重大变更，对低风险重复操作采用预先授权，对不可逆或高影响变更执行专项评估。这样才能兼顾安全与交付效率。

4. 选择管理工具时：先验收流程，再比较功能

选工具时，我会先拿真实版本案例做一轮走查，而不是从功能清单开始。选一个跨团队、有延期风险、含缺陷和发布动作的版本，检查工具是否能呈现范围、状态、责任人、阻塞原因、测试结果与发布信息之间的关联。

可以按以下步骤进行评估：

1. 挑选两个真实版本：一个正常交付，一个曾经延期或发生回滚。

2. 分别模拟产品、研发、测试、运维和管理层的查看路径。

3. 检查状态变更是否有记录，范围变化是否能追溯，阻塞是否能关联责任人。

4. 确认管理视图能否从版本总览下钻到具体问题，而不需要重复录入数据。

5. 评估权限、审计、集成、部署方式和数据治理要求是否符合组织实际。

6. 用小范围试点验证团队是否愿意持续维护数据，再决定是否扩大使用。

评估 PingCode 等研发管理平台时，建议把“版本状态能否建立”作为基础能力，而不是最终标准。更值得验证的是需求、迭代、缺陷、测试和发布能否连成可追溯链路；不同角色是否能共享同一事实；管理层是否能基于风险和依赖进行决策；平台是否适合组织的权限、部署和治理要求。

5. 先设观测基线，再谈自动化优化

在自动化之前，至少连续记录几个版本周期的关键节点时间、范围变化、阻塞原因、测试结论和发布结果。若没有基线，就很难判断流程调整究竟缩短了等待，还是只是改变了状态填写方式。

建议从少量指标起步：承诺范围变更率、版本按期率、各状态中位停留时间、提测一次通过率、发布失败率、回滚率和线上问题关闭时间。指标不必全部用于绩效考核，更多时候它们是定位系统性问题的诊断工具。

八、不同情况下的取舍：没有一种流程适合所有版本

1. 快速迭代与充分审批如何平衡

快速迭代的收益是缩短反馈周期，代价是需要更成熟的自动化测试、监控和回退能力。审批密集可以提高可见性，却可能延长交付周期并诱发线下绕行。我的判断是：审批应集中在高风险决策点，日常流转应尽可能依赖明确规则和自动校验。

如果团队尚未具备可靠监控和快速回滚能力，贸然追求高频发布并不明智；如果发布风险较低、验证自动化成熟，仍把每次变更都放进多层会议审批，也是在用管理成本抵消工程能力。流程强度应随风险和可逆性变化，而不是随组织层级机械增加。

2. 统一流程与团队自主如何平衡

统一流程让管理层可以比较和协调，但过度统一会忽视不同产品、技术栈和发布机制的差异。团队自主可以贴合实际，却可能让跨团队依赖变得不可读。比较稳妥的边界是：组织统一核心定义、关键门槛和数据口径；团队自主细化内部工作方式和低风险状态。

如果某团队确实需要额外状态，应说明它解决的业务问题，以及如何映射到组织级状态。若一个新状态不能改变责任归属、决策方式或风险判断，它很可能只是增加了维护成本。

3. 精细指标与数据负担如何平衡

更多数据并不必然带来更好管理。若每次状态更新都要求填写大量字段，团队会延迟更新、随意选择或在月底集中补录。优先采集能够直接支持交接和决策的信息：负责人、下一步、阻塞原因、关键日期和验证证据。

指标应分层使用。团队可以保留更细的工程数据，管理层只看能触发行动的汇总信号；同一个指标也要清楚标注口径和时间范围。不要为了形成排行榜，把不同复杂度、不同风险的版本硬放在同一个序列里比较。

4. 手工管理与自动化规则如何平衡

人工判断适合处理例外和需要业务权衡的情形；自动化适合重复、明确、可验证的规则。比如，系统可以提醒版本超过目标日期、关键缺陷未关闭或提测材料缺失；是否削减范围、接受残余风险或更改发布时间，则需要有权责的人员作出判断。

自动化规则上线前，先确认数据可靠。若负责人字段经常为空、状态更新不及时，自动提醒只会制造更多噪声。可以先从少量高价值规则开始，观察提醒是否减少遗漏，再逐步扩展，而不是把所有可能的检查都变成强制门禁。

5. 短周期指标与长期质量如何平衡

缩短周期和提高按期率是有价值的，但如果通过减少测试、推迟缺陷修复或把问题留给线上支持来实现，短期效率会损害长期质量。版本复盘应同时看交付速度、返工、线上缺陷、客户影响和团队负担，避免只奖励速度而忽略后续成本。

对不同类型的版本，应采用不同的成功定义。探索性功能更关注反馈速度和假设验证；稳定性改造更关注故障率和恢复能力；合规变更更关注证据完整和风险控制。一个版本是否成功，不能只由发布日期是否达成来决定。

九、结尾：把状态设计成能推动行动的共同语言

版本管理的独特价值，不在于把每个版本放进一条漂亮的流程图，而在于让不同角色少猜测、少重复确认，并在风险尚可处理时及时发现偏差。状态如果不能改变下一步行动，它只是记录；状态如果能明确门槛、责任和决策，它才是管理工具。

下一步可以从一个正在进行的版本开始：确认版本对象和范围，列出当前状态的进入与退出条件，标注每个交接点的责任人，再记录一次延期或阻塞的真实原因。先用数据跑过两三个周期，找出等待最长、返工最多或决策最慢的环节，再决定是否增加状态、审批和自动化。

不要先问“还缺几个状态”，先问“下一次交接，接收方凭什么相信它已经准备好”。当这个问题有清楚、可验证的答案，版本状态才能真正连接管理层的决策与团队的执行。