关闭实操方法：实施团队提升Bug / 缺陷效率的实操方法方法与模板

关闭实操方法：实施团队提升Bug / 缺陷效率的实操方法方法与模板

缺陷单从“已修复”变成“已关闭”，看起来只差一次验证，实际可能还隔着环境确认、版本核对、客户复测和证据留存。实施团队最容易踩的坑，不是修得慢，而是把“关闭数量”当成效率：单子关得很快，客户却反复报同一个问题。要提升关闭效率，先把关闭定义说清楚，再把缺陷从发现、定位、修复到验证的每个等待点管起来。

一、先讲结论：关闭效率不等于关单速度

1. 先区分“已修复”和“已关闭”

我判断一条缺陷是否真正闭环，会先看它是否满足三个条件：问题现象有明确结论，修复内容已进入约定版本，验证证据能够说明原问题不再出现。只把状态从“处理中”改成“已关闭”，而没有版本、环境和验证结果，只是状态变化，不是问题解决。

实施项目还有一个容易被忽略的条件：客户现场是否已经具备验证窗口。有些修复已经在测试环境通过，但生产环境无法立刻升级；这类缺陷可以标为“待客户验证”或“待发布验证”，不应伪装成已关闭，也不宜无限期留在开发处理队列里。

2. 把效率拆成速度、质量和可预测性

只看平均关闭时长，团队可能通过优先关闭简单缺陷来美化数字；只看关闭数量，又会鼓励拆分单据或过早关单。我建议至少同时观察处理周期、一次验证通过率、重开率、超期在制数量和客户等待时间，分别回答“快不快”“对不对”“能不能预期”。

3. 先减少无效流转，再追求更短时长

我更愿意把“少一次退回、少一次追问、少一次无证据重开”看作效率改善的先导信号。关单时间缩短可能只是流程压缩，也可能是质量下降；而缺陷字段完整率、首次分派准确率、复现信息充分率改善，通常能说明团队真正减少了返工。

如果团队目前只有一种改进空间，我会优先处理在制缺陷的等待原因，而不是立即要求开发加快编码。实施团队的缺陷常卡在“客户补充材料”“现场版本不明”“问题难复现”“修复已完成但没有验证窗口”，这些时间不通过更快写代码就能消除。

二、实施团队的真实场景：缺陷不是只在研发环节产生

1. 一个问题可能跨越多种现场条件

实施团队接到的缺陷，往往来自部署、数据迁移、权限配置、接口联调、业务规则确认和用户操作等多个环节。用户说“提交失败”，不一定意味着程序代码有缺陷：可能是账号角色变化，也可能是数据不满足校验规则，或者现场运行的版本与提单人描述不一致。

因此，实施缺陷的第一步不是马上把单子转给开发，而是建立可复现的事实描述。至少需要知道谁在什么环境、使用什么版本、执行了什么操作、预期结果是什么、实际结果是什么，以及问题是否持续发生。缺少其中任何一项，后续判断都可能建立在猜测上。

2. 客户现场的“等待”会被误算成团队慢

现场缺陷的日历周期通常比研发处理时间更长。客户业务时间有限，升级窗口可能只能安排在夜间；网络隔离环境不能随时上传日志；关键用户出差，验证要等下一次业务操作。若只从提单时间计算到关闭时间，团队会看见一个很长的周期，却不知道真正卡在哪一段。

我会把状态设计成能够说明下一步动作的语言。例如，“待补充信息”意味着由谁补什么材料；“待客户验证”意味着修复已在哪个版本、哪个环境可测；“待发布”意味着代码已合并但还不能验证。状态不是装饰，而是交接合同。

3. 实施问题要先分流，不能全都算作软件缺陷

缺陷、咨询、配置问题、数据问题和需求变更，处理路径并不相同。把所有反馈都建成缺陷，会让开发队列膨胀，真正的程序故障被淹没；把复杂缺陷误判为操作问题，则会让客户重复受挫，信任也会被消耗。

4. 工具能显露等待，但不能替团队作判断

对于中大型企业或百人以上组织，缺陷通常横跨项目、研发、测试、交付和客户现场，靠群聊追踪容易出现信息散落、责任模糊和统计口径不一致。以 PingCode 这类项目管理平台为例，可以通过统一工作项、状态流转、字段和仪表盘，让团队查看负责人、版本、优先级与阻塞原因。

但工具无法自动判断“这是不是缺陷”“客户是否接受验证结果”或“同一现象是否由同一根因造成”。我会把平台视作证据和协作的载体，而不是流程设计的替代品。先约定分流规则与关闭标准，再配置工作流；否则只是把原来的混乱更完整地记录下来。

三、常见误区：看起来关得快，问题可能并没有解决

1. 用“关闭数量”给个人或团队排名

缺陷复杂度差异很大：修正文案和定位跨服务的数据一致性问题，不应按相同权重计数。单纯按关闭数量排名，会鼓励成员优先拿简单单、拆小单、绕开难单，甚至把尚未确认的问题提前关闭。表面产出增加，关键客户风险却可能留在队列深处。

如果确实要观察产出，应按缺陷类型、严重级别、估算复杂度和阻塞状态分层看趋势，不用于孤立地评价个人。更重要的是观察团队整体的在制量、老化分布和一次通过率，确认工作是不是在系统中流动，而不是在少数人手里堆积。

2. 把“修复完成”当成“客户问题关闭”

开发提交代码，只说明工程动作完成了一部分。补丁可能尚未合入目标分支，测试版本可能与现场版本不同，修复也可能只覆盖了单一数据路径。若直接关闭，客户再次遇到问题时，团队往往要从头确认版本、复现条件和改动范围。

更稳妥的状态转换是“修复完成，待验证，验证通过，关闭”。对于客户无法立即验证的情形，应保留待验证状态并设置复查日期。这样既不把研发工作无限期挂在“处理中”，也不把未验证结果包装为已解决。

3. 用统一时限覆盖所有严重级别

严重影响核心业务的阻断问题，与低影响的界面显示问题，不应套用同一响应承诺。统一要求“所有缺陷两天关闭”，要么让团队对高风险问题响应不足，要么逼迫团队对低风险问题做无意义加急。时限必须结合业务影响、可用绕行方案和客户承诺来定。

另外要分开“首次响应时限”和“彻底关闭时限”。团队可以要求高优先级问题在较短时间内给出负责人、影响范围和下一步计划，却不应承诺复杂问题必定在短时间内修完。可信的进度说明，比无法兑现的关闭承诺更能稳定客户预期。

4. 每个问题都追求立即复现

复现很重要，但并非所有问题都能在短时间内复现。偶发并发异常、历史数据错乱、第三方接口波动或现场设备问题，可能需要日志、时间窗口和多方协作。把“暂时不能复现”直接判为无效，会丢失有价值的风险线索。

对难复现问题，我会明确记录已尝试的步骤、观测窗口、日志位置、发生频次和下一次捕获方式，再决定是否进入观察队列。关键不是强求当场复现，而是让下一次发生时团队能拿到更多证据。

5. 把重开都视为客户误报

重开有时是修复遗漏，也可能是现场仍运行旧版本、验证条件不一致、另一条数据路径存在同类问题，或者原缺陷描述把多个现象混在一起。未经判断就把重开归咎于客户操作，会让真实的修复质量问题无法进入复盘。

每次重开都要记录“为何重开”。如果是原场景仍失败，归入修复或验证不足；如果是新环境、新条件或新需求，应关联原单并说明差异。这样的分类让重开成为质量反馈，而不是互相推责的依据。

四、专业判断逻辑：先决定处理路径，再讨论关闭目标

1. 用业务影响确定优先级，而非用提单者声音大小

优先级应同时考虑影响范围、业务关键度、发生频率、是否存在安全或合规风险、是否有可接受的临时绕行方案。客户催得急值得关注，但催促频率不是技术严重程度的可靠替代指标。相反，一个暂时没人催、却影响财务结算准确性的缺陷，可能具有更高风险。

可以使用四级优先级作为起点，但不要照搬固定时间承诺。团队要用历史处理能力、发布频率、客户合同和业务窗口校准服务目标。对于存在数据安全或合规风险的问题，应有独立升级通道，不能被普通队列的平均时长掩盖。

2. 用“信息充分度”决定能否进入修复

一条缺陷是否可以派给研发，不取决于字段填得多不多，而取决于是否能支持下一步行动。至少要有问题现象、预期与实际结果、环境版本、复现步骤或已尝试的排查、影响范围和联系人。日志或截图应附上时间、脱敏说明和关联请求标识，避免证据无法对应到具体事件。

如果某项信息暂时无法取得，应写明缺失原因、已尝试获取的方式和计划回访时间。这样，缺陷可以进入受控的“待补充”状态，而不是以模糊描述占用研发分析队列。信息不完整并不一定代表提单人做得不好，有时是客户权限、环境限制或偶发性造成的。

3. 用责任人与下一动作消除“有人看但没人推进”

每条在制缺陷都应同时有一个责任人和一个下一动作。责任人负责推动单据前进，不代表需要独自完成所有工作；下一动作则应该具体到“采集某时间段日志”“确认补丁进入哪个版本”或“预约客户复测”，而不是笼统地写“继续跟进”。

跨团队问题可以设置协作人，但不要把主责任人留空。主责任人应在交接时确认接收方、交接材料和预期反馈时间。否则，状态虽然变了，实际责任却容易在实施、测试、研发和客户之间漂移。

4. 用证据决定关闭，证据不足就选择合适的暂停状态

关闭前我会核对三个证据：修复内容与原问题之间的关联、验证环境和版本是否符合约定、验证结果是否覆盖关键条件。若无法在客户生产环境直接验证，可以通过经批准的预发布环境、复现数据或自动化测试提供证据，同时明确剩余风险和客户验证计划。

若问题只在特定条件下出现，验证至少要覆盖该条件，而不能只证明“系统启动正常”。证据可以是测试记录、日志对比、版本构建号、操作录屏或客户确认；敏感数据需按安全要求处理。证据的目的不是增加文书，而是让不同人员在交接后仍能判断结论是否成立。

五、案例与数据观察：把“卡了几天”拆成能行动的事实

1. 示例案例：提交失败背后其实有三个待确认条件

下面是一个用于演示分析方法的情景案例，不代表特定企业的真实客户数据。某实施团队连续收到“批量提交失败”的反馈，原始记录只写了报错截图。开发无法稳定复现，客户则认为问题已经影响上线，双方在群里多轮追问，但缺陷状态连续数日没有实质变化。

团队重新整理证据后发现：问题集中在一类历史导入数据；反馈截图没有包含发生时间和请求编号；不同测试人员使用的账号权限也不一致。团队将问题拆成“权限条件确认”和“特定历史数据触发异常”两条排查线，并在缺陷单中记录版本、操作步骤、脱敏数据样例和日志时间范围。

随后研发在受控测试数据中复现异常，修复后由测试覆盖正常数据、边界数据和原始失败数据三种场景。实施人员在与客户约定的窗口内进行现场复测。该示例的关键不在于某个工具或某个成员的速度，而是把笼统的“提交失败”变成了能够分工和验证的条件。

2. 示例数据要用来发现流程问题，不要伪装成行业基准

为演示如何复盘，假设同一团队改进前后各观察 40 条已关闭缺陷。以下数字均为情景模拟：改进前中位处理周期为 6.2 个工作日，一次验证通过率为 68%，重开率为 17%；改进后分别为 4.4 个工作日、83% 和 9%。这些变化只有在口径不变、样本构成相近时才有解释价值。

如果改进后关闭周期变短，但重开率同时升高，就不能直接宣布流程成功。也可能是团队提前关闭待客户验证的问题，或者改进后处理的多为低复杂度单据。因此，解读时要核对优先级、问题类型、客户等待时长和版本发布周期，避免把样本差异误当成改进成果。

3. 中位数比单看平均值更能说明典型体验

缺陷处理周期通常有长尾：多数问题几天内解决，少数依赖现场窗口或第三方厂商的问题可能持续数周。平均值容易被极端个案拉高或拉低。我建议同时报告中位数、较高分位数和超期在制数，例如中位周期代表典型体验，较高分位数代表长尾风险，超期数量用于安排当下清理。

也要避免把长尾缺陷直接从统计中剔除。长期未关闭的问题可能正是项目风险所在。可以按原因标注“等待客户”“等待第三方”“研发处理中”“待发布”，再分别看数量和持续时间。这样既不把不可控等待误算作纯研发效率，也不会让问题因为“不好统计”而消失。

4. 用等待原因做周度复盘，而不只看最终结果

每周复盘时，我会挑选超过目标时限的缺陷，逐条回答：当前卡在哪个状态、谁负责下一步、需要谁提供什么、是否存在可行绕行、下一次更新时间是什么。复盘目标是移除障碍，不是要求每个人解释为什么自己没能关单。

若多个缺陷都在等待同一类信息，改进应该落在入口模板、客户沟通或自动采集机制；若反复等待版本发布，应讨论发布节奏和热修复策略；若责任模块频繁变化，应补充模块责任矩阵。问题集中在哪个节点，改进就落在哪个节点，而非一律增加会议。

六、可直接使用的模板：把操作要求写进缺陷单

1. 缺陷提交模板

提单模板要让提交者更容易说清事实，而不是让人为了填表完成一串无用字段。必填字段控制在能够启动分诊的范围内；不适用的字段允许说明原因。截图和日志应能补充证据，不要把截图当作全部描述。

2. 缺陷分诊记录模板

分诊记录的重点，是留下判断依据和下一步，而不是只留一个优先级标签。若结论暂时不确定，应标注待确认事项及责任人，避免“待分析”成为长期停滞状态。

• 初步类型：软件缺陷、配置问题、数据问题、咨询、需求变更或待确认。
• 业务影响：受影响流程、人员或客户范围；是否阻断业务；是否有安全、合规或数据风险。
• 复现结论：稳定复现、偶发复现、暂未复现；写明尝试条件和观察时间。
• 优先级依据：影响范围、发生频率、可绕行方案和客户承诺，而非只记录等级名称。
• 责任人及协作人：一个主责任人，必要时补充研发、测试、实施或客户联系人。
• 下一动作：明确动作、执行人和计划更新时间。
• 阻塞原因：等待日志、客户窗口、环境权限、第三方响应或版本发布。

3. 修复与验证模板

修复信息要能让测试和实施知道该测什么、在哪里测、如何判断通过。对复杂缺陷，不能只写“已修复，请测”；至少说明影响模块、修复版本、潜在回归范围，以及是否需要数据迁移或配置变更。

4. 客户进度沟通模板

客户沟通不要只写“研发正在看”或“预计尽快”。在尚未找到根因时，也可以提供有价值的更新：已确认的事实、仍未知的事项、正在执行的排查动作、需要客户配合的材料和下一次更新时间。

• 已确认：我们已在指定环境观察到什么现象，当前影响到哪些业务环节。
• 尚待确认：哪些条件尚未验证，例如账号权限、数据范围或发生时间对应的日志。
• 正在处理：当前责任团队正在采取的具体动作，以及何时提供下一次状态更新。
• 需要协助：请客户提供什么信息、安排什么窗口；若无法提供，说明可替代的配合方式。
• 当前安排：说明临时绕行方案、使用风险和版本验证计划，不把未验证的推测写成结论。

七、不同情况下怎么做：把流程压到适合团队的复杂度

1. 小团队或项目初期：先统一最低限度的信息

团队规模较小、缺陷量不高时，不必马上搭建复杂工作流。先统一缺陷类型、严重级别、负责人、版本环境、下一动作和关闭证据，规定每周一次短时复盘。只要所有成员能从同一处看到当前阻塞，这套轻量做法就已经比群聊里散落的追踪可靠。

小团队的优势是沟通链短，风险是规则依赖个人记忆。最值得先做的不是增加审批，而是把常见问题的复现信息、验证步骤和客户沟通方式写成模板。随着缺陷量增加，再基于真实瓶颈增加字段和自动化，不要一开始照搬大型组织的全部流程。

2. 百人以上组织或多项目并行：统一口径，保留项目差异

组织规模扩大后，多个实施项目可能对“已关闭”“高优先级”“待客户验证”有不同理解。建议统一状态定义、指标口径、必填信息和风险升级原则，再允许项目按合同约定配置响应目标。统一的是可比较的管理语言，不是强迫所有业务采用一模一样的时限。

可借助 PingCode 这类管理平台建立跨项目视图，查看缺陷负责人、项目、模块、版本和阻塞原因，并让项目负责人能从总览下钻到具体工作项。使用时要先验证字段权限、工作流、历史数据迁移和报表定义，避免不同项目把同一个字段填成不同含义，导致仪表盘看似完整、实际不可比较。

3. 客户无法及时验证：保留待验证状态和复查机制

当客户暂时没有验证窗口，不要为了降低在制数量强行关闭。可以把缺陷移到“待客户验证”，记录修复版本、建议验证步骤、客户联系人和约定复查日期。到期未反馈时，按沟通规则提醒并升级联系，不应默认沉默代表通过，除非合同或双方流程明确约定了这一规则。

对于客户长期无法验证但业务风险可控的情况，可由项目负责人评估是否采用替代证据，例如预发布环境复测、自动化回归或受控数据验证。关闭前应把未覆盖条件和剩余风险写清楚，并取得有权限人员确认；这是一项风险决策，不是单纯的状态调整。

4. 高风险缺陷：速度优先，但验证不能省略

涉及业务中断、数据正确性、安全或合规的缺陷，应走快速升级通道：尽快确认影响范围、指定事件负责人、提供临时缓解方案，并同步更新相关决策人。快速响应并不等于跳过测试，而是缩短等待决策和协调资源的时间，让必要的分析与验证并行推进。

若采用热修复，应明确补丁适用版本、回滚方法、监控信号和后续正式版本计划。临时恢复业务后，仍要完成根因分析与回归验证。否则，团队可能只是把故障压下去，却没有确认相同条件是否会再次触发。

5. 难复现或第三方依赖：设置观察策略而不是无限挂起

对偶发问题，先确定要收集的关键信号、采集位置、保留期限和责任人。例如记录请求标识、发生时间、调用链、关键配置变更和复现频次。若无法在现有环境稳定重现，可以将其移入观察状态，并约定何种新证据会触发重新分析。

第三方依赖问题应同时保留内部跟进责任人，记录供应商工单号、响应时间、临时方案和升级渠道。外部依赖不意味着内部团队可以停止沟通；项目方仍应持续告知客户当前事实、风险和下一次更新时间。

八、不同情况下的取舍：追求速度时，哪些不能牺牲

1. 表单完整度与提单速度之间的取舍

必填字段过多会让客户和一线实施人员绕过系统，转而在聊天群里报问题；字段太少则导致研发反复追问。我的建议是把“可进入分诊”的信息设为最低门槛，其余字段按缺陷类型动态要求。比如安全问题强调影响范围与访问条件，数据问题强调样例、批次和修复风险。

如果字段填写质量长期偏低，先检查提单者是否知道如何获取这些信息。提供示例、分类型提示和自动带出版本环境，通常比增加处罚更有效。字段的价值要看它是否减少后续往返，而不是看它是否填满。

2. 立即修复与安全绕行之间的取舍

并非所有问题都适合立刻上线修复。复杂改动可能带来回归风险；在关键业务窗口，经过验证的临时绕行有时更安全。决定时要对比故障持续损失、绕行操作成本、错误修复的潜在影响，以及何时能安排正式补丁验证。

绕行方案必须写清适用条件、操作步骤、风险边界和撤销方式，并指定复核人。口头告知的临时方案很容易在人员交接中变成长期默认操作。最终修复完成后，应确认绕行已撤销，避免两套处理方式并存。

3. 更细的状态与更低的维护成本之间的取舍

状态太少，管理者看不出卡点；状态太多，一线人员会把时间花在维护状态上。每增加一个状态，都应回答两个问题：它是否改变下一步责任人，是否能帮助团队采取不同动作。如果答案都是否定的，通常应把它合并为备注或标签。

对多数实施团队，重点不在状态数量，而在“处理”“待补充”“待验证”“待发布”“关闭”等关键阶段是否定义清楚。其他细分差异可以通过阻塞原因、缺陷类型和责任团队表达，避免状态机变成难以培训的流程迷宫。

4. 个性化项目流程与跨项目统计之间的取舍

客户合同、监管要求和发布安排不同，项目流程不可能完全一致。但如果每个项目都自创一套字段和优先级，总部就无法判断哪些缺陷真正超期，也无法识别重复根因。可采用“统一核心字段、项目自定义扩展”的办法，让必要差异存在，但不破坏跨项目统计口径。

平台报表要明确统计时间、状态范围、去重规则和等待时间算法。对管理层展示趋势时，应说明数据边界，不能把不同项目、不同缺陷类型混在一起简单排位。报表的目的应是发现系统性阻塞，而不是创造新的数字竞争。

九、30天落地计划：先建立基线，再改一个最明显的瓶颈

1. 第一周：统一定义和基线数据

先把缺陷、咨询、配置、数据问题和需求变更的边界写清楚，并统一“受理”“待验证”“关闭”“重开”的定义。抽取近一段时间的缺陷记录，检查字段缺失、状态停留时间、重开原因和客户等待原因。基线不需要完美，关键是说明样本范围和统计口径。

这一周不要急着设定过高的关闭目标。若历史数据记录不完整，应先修复记录方式，并把“数据质量不足”本身列为发现。用不可靠的基线做考核，容易让团队花精力争论数字，而不是解决流程问题。

2. 第二周：改进入口质量和分诊

选取最常见的三类缺陷，分别制作简短提单模板，加入环境版本、复现步骤、预期与实际结果、影响范围和证据要求。安排实施、测试和研发代表共同分诊，重点检查误分类和信息不足，不以批量退单作为提单质量改进的主要手段。

观察新模板是否减少追问次数、重新分派次数和从受理到首次有效分析的时间。如果字段变多但这些指标没有改善，就删掉无效字段或调整填写提示。模板是为了降低沟通成本，应允许根据真实使用反馈持续修订。

3. 第三周：建立超期在制和阻塞处理

为不同优先级设定内部响应目标和复查节奏，并明确何时升级。每天或每两天查看超期在制缺陷时，不要求每条立刻关闭，而是确认责任人、下一动作、阻塞人和下次更新时间。对“没有下一步”的缺陷优先处理，因为它们往往已经从正常工作流中脱落。

当同一阻塞原因反复出现，指定一个流程改进负责人。例如客户日志经常拿不到，就优化采集指引和脱敏流程；验证窗口常冲突，就提前约定发布日历。个案催办只能清理眼前积压，重复阻塞要通过机制解决。

4. 第四周：复核质量，决定是否扩大

比较改进前后的周期、一次验证通过率、重开率和超期数量，同时按缺陷类型、优先级和等待原因分层。至少抽查一批已关闭缺陷，确认状态与证据一致。若速度改善但质量指标恶化，先调整关闭规则，不要继续扩大自动关单或压缩验证步骤。

若结果稳定，再把有效做法推广到其他项目；若效果不明显，回到数据寻找瓶颈，不急于增加新工具或新会议。管理平台可以帮助汇总流程信号，但最终改进仍要落在清晰的责任、证据、决策和协作安排上。

1. 定口径：明确缺陷类型、状态含义、优先级依据和关闭条件。
2. 建基线：统计周期、重开、验证通过、超期在制和等待原因，并标注数据范围。
3. 选瓶颈：只优先改善一个高频阻塞点，避免同时改流程、指标和工具造成归因困难。
4. 用模板试点：选一个项目或一类缺陷测试提单、分诊和关闭模板。
5. 复核质量：抽查关闭证据和重开原因，确认速度变化没有以问题漏检为代价。
6. 再决定扩围：有稳定效果后逐步推广；没有效果时先修正判断，不把流程复杂化当成进步。

十、总结：真正的效率，是更少返工和更少不确定

1. 从关单指标转向问题闭环能力

实施团队提升缺陷关闭效率，核心不是要求所有人更快点击“关闭”，而是让问题更早被正确分类，让研发尽早拿到可用证据，让每次交接都有明确负责人和下一动作，并让关闭结论经得起复查。速度、质量和客户预期必须放在同一套观察框架里。

我的独特判断是：缺陷关闭周期往往不是由修复动作单独决定，而是由等待与返工共同塑造。若团队只加快编码，却不改善信息质量、版本协同、客户验证窗口和状态交接，缩短的可能只是局部时间，整体体验未必变好。

2. 下一步先做一件可验证的小改进

下一步可以从最近 20 至 30 条已关闭缺陷开始，逐条标注类型、等待原因、验证结果和重开情况，找出最常见的一个阻塞点。然后用一份简短模板或一次分诊规则调整做小范围试点，明确观察周期和评价口径，再判断是否推广。

如果团队能够回答“当前最慢的等待发生在哪里”“谁负责推动下一步”“什么证据才算真正关闭”，就已经具备持续改善的起点。工具负责让事实可见，流程负责让责任清楚，专业判断负责在速度与风险之间做取舍；三者配合，关闭效率才会转化为客户能感受到的解决能力。