延期申请流程与规范：研发团队延期管理最佳实践关键指标

研发延期最危险的信号，往往不是某个需求晚了三天，而是团队直到原定发布日期前才第一次正式讨论“能不能延期”。延期申请如果只是补一张表、等一次审批，既不能让项目按时，也不能帮助管理者判断是否值得继续投入。真正有效的延期管理，要把申请变成一次可追溯的预测校准：说明偏差从哪里来、剩余工作有多少、延期会改变什么，以及谁负责把新的承诺兑现。

一、先讲核心结论：延期不是审批动作，而是重新做一次交付决策

1. 延期申请的价值在于提前暴露偏差

我判断延期机制是否有效，首先不看审批表有几栏，而看团队能否在交付日期失守之前发现计划正在失真。一个项目在截止日前提出延期，不一定说明管理做得差；如果风险在早期已经量化、升级并调整范围，这次延期可能是负责任的选择。反过来，若延期申请只是最后一刻为既成事实补手续，流程再完整，也只是记录失败，而没有管理风险。

因此，延期申请的起点不应是“日期已经过了”，而应是“预测交付日期已经越过可接受阈值”。例如，团队每周更新剩余工作量和依赖状态，若连续两次预测显示关键路径将晚于承诺日期，项目负责人就应发起评估，而不必等到测试失败或上线窗口错过。

2. 好的延期决策同时回答四个问题

我建议将每次申请压缩到四个核心判断：当前计划为什么不再可信；延期申请覆盖哪些交付项；延长时间能换回什么可验证结果；如果不延期，组织愿意接受什么损失或风险。四个问题缺一不可。只写原因，容易变成解释；只写新日期，容易变成重新许愿；只写风险，又无法比较延期与缩减范围的代价。

• 事实：原承诺日期、已完成范围、未完成工作、关键依赖和当前预测日期。
• 原因：导致偏差的主要事件，区分已知工作量、需求变化、外部阻塞和质量返工。
• 方案：延期、缩范围、分批交付、增加资源或停止投入等可比较选项。
• 承诺：新的验收条件、负责人、检查节点以及再次偏差时的升级动作。

3. 管理目标不是减少延期次数，而是减少意外和重复延期

如果管理者只考核延期次数，团队可能把风险藏到最后，或把一个延期拆成多个看起来更小的日期调整。更合理的目标是减少“临近交付才暴露”的延期、减少同一事项连续申请延期，并提升预测日期的可信度。延期本身可能是为了保护质量、合规或客户利益；真正需要追问的是，团队是否在该预警时预警、是否基于证据重新承诺。

以下图表为建议基准的情景模拟，用于展示指标之间的管理关系，不代表行业统计。团队可用自身过去两个季度的数据替换。

二、背景和真实场景：为什么研发延期会变成组织问题

1. 计划偏差通常不是单一原因造成的

在研发项目中，延期常常由多个小偏差叠加而成：需求澄清晚了几天，接口环境未按时提供，测试数据准备不足，修复又引入回归问题。单看每个环节，似乎都只是局部延迟；但它们如果都落在关键路径上，就会让最终日期持续后移。此时，团队最容易犯的错，是把多个问题合并成一句“工作量超出预期”，管理者也就失去了判断空间。

我会要求项目负责人把原因分成“范围变化、估算偏差、依赖阻塞、质量返工、资源变化、外部事件”几类，并标明证据和影响区间。原因分类不是为了给团队贴标签，而是为了决定下一步该改计划、改范围、协调依赖，还是投入质量治理。若问题来自需求持续变化，单纯加人很可能只会增加沟通成本。

2. 同一个日期，可能对应完全不同的交付承诺

“延期两周”听起来明确，却可能有两种截然不同的含义：一种是原定范围全部完成，且通过验收；另一种是核心功能可用，但部分非关键能力进入后续版本。如果申请表只记录新日期，不说明范围变化，业务方会以为交付内容不变，研发团队却以为可以先交一部分。到最后，双方争论的不是延期，而是承诺究竟是什么。

因此，延期申请必须把范围变化写成可核验的清单。建议至少区分“本次必须交付”“可延后交付”“本次明确不做”三类，并对每一项写验收责任人。特别是涉及客户承诺、监管要求、数据迁移或跨部门依赖时，不能用“基本完成”“功能可用”等模糊说法替代验收条件。

3. 延期是组合决策，不是单团队的日期决定

研发项目的日期往往影响测试、运维、销售、客户成功、采购和安全审查。延期可能导致发布窗口变化、合同节点变更、培训重排，甚至错过业务季节性窗口。所以审批人不能只看研发团队还有多少任务，还应看到延期的下游成本，以及提前交付部分功能是否能降低损失。

对中大型组织而言，跨团队依赖常常比单个团队的开发速度更影响交付。若团队规模超过百人，依赖关系和权限边界往往使“口头同步”难以支撑可靠决策。采用统一的项目管理平台时，应重点验证它能否记录计划基线、工作项状态、依赖关系、风险变更和审批结论；工具本身不能替代判断，但能减少信息散落在会议纪要、聊天记录和个人表格中的情况。

三、常见误区：表格齐全，不代表延期管理成熟

1. 误区一：延期原因写得越长，申请越可信

一页背景说明并不能证明延期判断准确。有效的原因描述应当可验证，例如“第三方接口联调环境比约定日期晚四个工作日，导致两个集成测试任务无法开始”，而不是“外部配合不够”。前者能核对约定、阻塞时间和受影响任务；后者只表达情绪，既不能估算影响，也无法形成行动。

申请材料可以精简，但证据链要完整。建议将关键事件、受影响工作项、当前剩余量、预计恢复时间和责任人分别列出。若数据尚不确定，也应明确标注区间和假设，而不是用一个看似精确的日期掩盖不确定性。

2. 误区二：给关键路径加人，就能把时间追回来

增加人手只有在任务可拆分、交接成本可控、环境和需求已经稳定时，才可能缩短周期。对正在联调、排查复杂缺陷或修改共享架构的工作，新增人员需要熟悉上下文，也会增加评审和沟通负担。若瓶颈是外部审批、测试环境或未决需求，加人通常不会触及瓶颈。

我会先问“阻塞点是什么”，再讨论“要不要加人”。如果瓶颈在测试资源，调整测试窗口可能比增加开发人员有效；如果瓶颈在需求决策，指定有授权的决策人可能比增加会议更有效；如果瓶颈在架构返工，则应重新评估技术方案和验收范围。

3. 误区三：为了避免延期，先降低测试标准

压缩测试时间看似能保住日期，实际可能把成本转移到上线后。尤其是涉及权限、数据一致性、支付、隐私或大规模迁移的功能，未完成的验证可能造成更高的恢复成本。是否能降低测试范围，必须基于风险分级、可回滚能力和影响面判断，不能把“测试没做完”改写成“风险可接受”。

可考虑的做法包括：将低风险功能与高风险功能分批发布；对非关键路径采用后续补测；建立灰度、监控和回滚条件。但这些替代方案都需要明确负责人和触发阈值。若没有可观测性或回滚方案，按期发布可能只是把风险推迟到用户侧。

4. 误区四：每次延期都让更高层审批，流程就更严谨

审批层级增加，不一定提升决策质量。若高层看到的只有一句延期原因和一个新日期，审批只是把责任向上转移。相反，设置与影响范围匹配的授权边界，让最了解依赖和业务代价的人参与评估，通常更有效。关键是审批者要能比较方案，并对跨团队资源和业务取舍拥有相应权限。

流程应区分项目内部调整、跨团队承诺变更、客户或合同节点变化、合规及安全风险等情形。小范围且不影响外部承诺的调整，可由项目负责人和产品负责人确认；影响版本目标或外部承诺的，才需要进入更高层级的组合决策。

四、专业判断逻辑：如何判断该延期、缩范围还是继续推进

1. 先确认基线是否仍然有效

在讨论延期前，先核对原计划是否有明确的范围、验收标准和责任人。如果基线从未稳定，或者需求不断变化，直接比较“原日期”和“新日期”会产生假精确。此时应先冻结一版可执行范围，并记录已发生的变更，再估算剩余工作。否则，延期申请会把需求治理问题误当成研发效率问题。

计划基线至少要覆盖主要交付物、关键里程碑、依赖项和验收口径。基线不是不可更改的承诺，而是用来识别变化的参照点。每次变更都应保留变更时间、发起人、影响范围和批准结论，这样团队才能区分“原计划估算错了”与“后来工作变多了”。

2. 用剩余工作和不确定性估算日期，而不是按已耗时间外推

“已经做了三个月，应该再给两周”不是可靠估算。已经投入的时间无法直接说明剩余工作量，尤其是在探索性研发、复杂集成和缺陷修复阶段。更实用的做法，是把剩余工作拆成可验证的交付项，给出乐观、最可能和保守三种估计，并说明主要不确定性来自哪里。

团队可用历史迭代数据校准估算，但不能把历史平均值机械套到不同性质的任务上。若某类任务过去常受外部审批影响，就要把审批等待作为独立区间；若过去的缺陷修复波动较大，就应避免给出没有缓冲的单点承诺。估算不是承诺的替代品，而是让承诺建立在可解释的假设上。

3. 比较方案的总成本，不只比较日期

延期两周的成本，不只是两周的人力。还可能包括发布窗口、客户沟通、合同节点、其他团队等待、环境占用和机会成本。另一方面，按原日期上线也可能带来缺陷处理、回滚和声誉损失。决策者应比较不同方案的预期损失，而不是把“按时”当作唯一正确答案。

4. 将风险、置信度和影响面放在同一张决策桌上

一个可操作的评估方法，是分别评估交付置信度、延期影响和风险严重度。交付置信度可结合剩余工作、历史偏差和依赖稳定性判断；影响面要识别是否触及客户、合同、合规、运营窗口；风险严重度则看失败后能否发现、能否回滚、损失是否可控。三者不能被一个总分完全替代，但能帮助审批人避免只盯着日期。

例如，内部效率改进工具延期一周，若没有外部承诺且可继续使用旧流程，影响可能较低；支付链路改造延期一周，则可能影响交易稳定性和财务对账，质量验证优先级应更高。相同的延期天数，不代表相同的管理风险。

五、具体流程：把延期申请做成一条可审计的决策链

1. 触发：设置预警条件，而不是等到截止日

团队可以把触发条件分为定量和事件两类。定量条件包括关键里程碑偏差超过约定阈值、剩余工作量连续两次上升、关键路径缓冲消耗过快；事件条件包括关键依赖方无法按期交付、验收标准发生重大变化、上线风险达到团队无法接受的级别。阈值不必所有项目相同，但必须提前约定。

例如，普通内部项目可在预计偏差超过五个工作日时启动评估；涉及合同节点或合规审查的项目，可以采用更早的触发点。这里的数字只是可讨论的组织基准，不是普遍适用的行业标准。团队应根据项目周期、发布节奏和风险等级调整，并在复盘中校准。

2. 准备：用最小必要信息形成可比较方案

申请材料不宜成为长篇汇报。建议采用一页决策摘要，加上可追溯的工作项和风险明细。摘要说明发生了什么、影响什么、建议选哪个方案；附件保留证据、估算和依赖记录。这样既能让决策者快速理解，也不会牺牲后续复盘所需的信息。

1. 核对基线：列出原承诺日期、范围、里程碑和验收条件。
2. 更新现状：标明已完成、进行中、未开始和阻塞的工作项，避免只报一个完成百分比。
3. 说明偏差：按原因类别记录事件、发生时间、影响工作和证据来源。
4. 估算剩余：给出剩余工作量、依赖等待和不确定区间，说明估算假设。
5. 提出选项：至少比较延期、缩范围或分阶段交付中的可行方案。
6. 写明新承诺：包括范围、日期、验收人、检查点和再次偏差的处理方式。

3. 评审：让有决策权的人参与，而不是只收集签名

评审会议应围绕取舍展开，而不是逐字朗读申请表。研发负责人解释剩余工作和技术风险，产品负责人确认价值与范围，测试或质量负责人说明验证边界，依赖团队确认输入日期，业务负责人评估外部影响。项目经理负责把分歧转化为待决事项，并确保结论有责任人和截止时间。

审批结论至少有四种：批准整体延期、批准缩范围或分阶段交付、暂不调整并设置短周期复核、拒绝延期并明确可接受风险。单纯写“同意”没有管理价值。结论还应记录选择该方案的理由、未采纳选项的原因以及风险接受者。

4. 执行：新日期必须绑定检查点和退出条件

批准延期后，不应把原计划整体向后平移，然后期待团队自然追上。新计划需要重新确认关键路径、依赖负责人和验收窗口，并设置至少一个中间检查点。若延期时间较长，可将交付拆成阶段，以便更早发现估算仍然偏差。

退出条件尤其重要。比如，某阶段必须在新日期前三个工作日完成集成测试；若未完成，则自动启动缩范围方案或升级风险，而不是再次临时讨论。退出条件让团队知道何时停止继续投入、何时切换方案，减少“再给几天就好”的连续延期。

5. 复盘：核对预测误差，而不是追究谁报晚了

项目完成后，应比较申请时的预测和实际交付日期，分析误差来自估算、依赖、范围变化还是质量返工。复盘应关注可改进的系统因素：需求冻结机制是否有效、依赖承诺是否有负责人、测试环境是否稳定、预警是否被忽略。把复盘做成追责会让团队下次更晚暴露问题。

对于连续延期的项目，复盘重点应转向预测模型是否失效，以及项目是否存在结构性问题。例如，若每次申请都把修复和回归测试估得过低，组织应调整估算模板和质量活动安排，而不是只要求负责人“下次估准一点”。

六、关键指标：衡量延期管理，而不是制造新的考核陷阱

1. 延期率要按项目类型和风险分层

延期率可以定义为实际交付晚于基线日期的项目数占比，但单一比例很容易误导。短周期迭代、探索性研发、客户定制和合规项目的计划稳定性不同，直接放在一起比较，会让团队倾向于降低目标难度或隐藏延期。建议按项目类型、周期长度、外部依赖程度和风险等级分层观察。

延期率上升不一定代表团队变差，也可能意味着风险透明度提高、更多问题被提前登记。反之，延期率很低也不必然说明管理优秀，可能只是日期被频繁重设，或统计口径只计算最终版本而忽略中间承诺。

2. 关注预测误差和提前量

预测误差可用“实际完成日期与申请时预测日期的偏差”观察。偏差持续较大，说明团队对剩余工作、依赖等待或质量返工缺少有效校准。预警提前量则衡量首次正式升级风险到原承诺日期之间的时间。提前量增加，决策者才有机会调整资源、范围和发布安排。

这两个指标应一起看：如果提前预警很多，但预测误差仍大，说明问题发现得早，却没有更好地估算；如果误差较小但预警非常晚，可能只是碰巧赶上了日期，流程韧性仍不足。

3. 连续延期率比延期次数更能揭示承诺质量

同一个交付项连续两次以上更改日期，通常值得单独复核。连续延期可能来自需求未冻结、关键依赖不可控、估算方法失真或管理者持续给出乐观承诺。统计时要区分范围变化导致的新基线与同一范围下的反复推迟，避免把合理的变更与不可靠的承诺混为一谈。

此外，建议观察延期申请的方案质量，例如是否提供了范围选项、是否注明验收条件、是否有明确的风险接受者。流程成熟度并不只体现在时间结果，也体现在决策信息是否完整。

4. 用指标组合防止“数字好看，决策变差”

任何单一指标都可能被优化到失去意义。只考核延期率，团队会推迟登记；只考核预警提前量，团队可能过早发出大量低质量预警；只考核延期后验收通过率，团队可能把低风险工作留在统计范围之外。建议至少组合观察延期率、预测误差、预警提前量和延期后验收通过率，并结合定性复盘。

以下数据为样本推演，不是外部行业基准。其目的在于说明单个“延期率”无法完整反映管理效果。

七、案例推演：一个跨团队研发项目如何选择延期方案

1. 场景：原日期不变，剩余范围却已发生变化

以下为匿名化的情景案例，用于说明判断方法，不对应某家企业的真实项目数据。一支约一百二十人的研发组织正在准备一个跨平台业务版本，涉及客户端、服务端、数据迁移、测试和运维。原计划八周交付，承诺范围包括核心流程、管理报表和历史数据迁移。

进入第六周后，核心流程开发大体完成，但外部数据接口晚到一周，迁移脚本的边界场景又发现问题。团队最初仍按原日期报“整体完成约八成”，但拆解工作项后发现，剩余任务集中在集成验证、数据校验、缺陷修复和上线演练；这些工作之间存在先后依赖，不能简单并行。

2. 证据：完成百分比掩盖了关键路径上的高风险任务

项目负责人复核计划基线后，发现“八成完成”是按工作项数量计算，而不是按关键路径和验收条件计算。剩余两成工作中，数据迁移和回滚演练虽然数量少，却决定了版本能否安全上线。若只用完成百分比做判断，管理者会低估最后阶段的工作量和风险。

团队随后列出三种方案：整体延期两周；按期上线核心流程，将报表和部分历史数据迁移拆到后续批次；或维持日期但压缩迁移验证。第三种方案被否决，因为关键数据校验尚未完成，且现有监控和回滚机制不足以把风险降到可接受水平。

3. 决策：选择部分按期交付，并明确延期范围

产品、研发、测试、运维和业务负责人共同确认：核心流程在原日期进入受控发布，限定首批用户范围；管理报表和完整历史数据迁移延期两周。首批发布设定数据一致性阈值、错误率阈值和回滚负责人。两周后的验收不以“脚本运行完成”为条件，而以抽样校验、全量核对和业务签字为准。

这个决定没有让所有团队都“满意”：业务方不能一次拿到全部功能，研发团队要维护两个交付批次，运维还需增加灰度观察。但它把不可接受的迁移风险从核心流程中隔离出来，同时尽量保留了按期验证核心价值的机会。

4. 结果评估：延期管理要看延期换回了什么

复盘时，团队不只记录“延期两周”，还核对了三件事：首批用户是否完成核心流程验证；数据迁移是否满足事先约定的校验标准；灰度期间是否触发回滚阈值。若核心流程上线后没有获得有效反馈，或者数据验收条件在过程中被放宽，那么这次分阶段决策就不能仅凭“没有事故”判定成功。

案例中的关键动作不是选了“延期”还是“按期”，而是把两者拆开：可验证、风险可控的范围先交付；高风险、依赖未稳定的部分继续完成验证。对于研发管理者，这比让整个项目在“按期”和“延期”之间二选一，更接近真实业务决策。

八、不同情况下的行动建议与取舍

1. 依赖方延迟：先验证依赖承诺是否真实可用

如果延期主要由跨团队依赖造成，首先确认依赖交付物、负责人、验收方式和可用日期。不要只记录“等待某团队”，要核对对方交付后本团队还需多少联调和验证时间。一个接口按时交付，不代表集成任务就能当天完成；权限、数据质量、环境配置和异常处理仍可能成为新的阻塞点。

取舍上，可并行推进不依赖外部输入的工作，准备模拟数据或替代环境，但应明确模拟结果不能替代最终联调。若依赖方日期不可确认，项目计划应表达为区间或条件式承诺，而不是把未经确认的日期当作确定输入。

2. 需求持续变化：先处理范围治理，再讨论资源

如果延期源于需求增补，需把变更记录与原始范围分开，评估新增需求带来的工作量和影响。如果业务价值高，可考虑替换低优先级范围，而非将所有需求叠加到原计划中。若决策人无法确认优先级，延期申请应明确指出这是尚未解决的业务决策，而不应让研发团队独自承担不确定性。

取舍上，严格冻结需求有利于稳定交付，但也可能错过重要市场反馈；持续吸收变化有利于适应业务，却会降低日期可信度。组织需要决定哪些变更允许进入当前版本、哪些进入后续版本，并指定有权作出取舍的人。

3. 质量问题集中暴露：不可用日期压力掩盖系统性缺陷

若延期原因是缺陷密度、回归失败或架构问题，应先判断问题是否具有扩散性。局部缺陷可能通过修复和定向回归解决；若同类问题出现在多个模块，说明可能存在设计、测试策略或集成节奏的系统性缺口。此时只给少量缓冲，往往不足以修复根因。

取舍上，可把低影响功能分批交付，但涉及数据安全、权限隔离、交易一致性或不可逆操作的缺陷，应设置明确的发布门槛。延期换来的时间必须用于降低风险，而不能只用于追赶新增需求。

4. 商业窗口不可错过：评估最小可行交付和后续维护成本

若错过发布日期的机会成本很高，可以考虑最小可行交付，但要确认它确实能支撑业务目标，而不只是为了保住一个日期。最小范围应有独立价值、完整验收路径和明确的后续演进计划。若为了按期拆分导致长期维护两套逻辑、增加数据迁移风险或造成用户体验断裂，短期收益可能被后续成本抵消。

取舍上，适合分批交付的功能应具备相对清晰的边界、可独立验证的价值和可控的回滚方式。高度耦合、无法独立验收或涉及不可逆数据变更的功能，不宜为了日期强行拆开。

5. 小团队和大型组织：流程复杂度应匹配协调成本

小团队可以由项目负责人、产品负责人和技术负责人快速会商，但仍需要留存基线、选择理由和新验收条件。大型组织则要更重视跨团队依赖、权限、版本关联和审批记录，避免同一风险在多个会议中被重复讨论，却没有明确责任归属。

如果使用项目管理工具或项目管理平台，重点不在功能清单有多长，而在是否能把需求、任务、版本、缺陷、依赖和审批记录关联起来。以 PingCode 作为评估对象时，可以将其作为中大型研发组织候选平台之一，重点核验实际部署方式、权限模型、数据留存和迁移范围。若考虑私有化部署或从 Jira 平滑迁移，应以供应商当前版本的正式能力说明、试迁移结果和合同服务边界为准，不宜仅凭宣传描述做决策。

选择工具时，我会要求团队用一条真实延期链路做验证：从基线和工作项开始，模拟发起延期、调整范围、记录审批、更新里程碑，再检查报告是否能还原决策过程。迁移测试还应覆盖附件、评论、历史变更、用户权限、字段映射和关联关系。工具能否减少重复录入、提升信息可追溯性，比功能演示是否流畅更重要。

九、落地模板：让申请、审批和复盘使用同一套事实

1. 延期申请字段建议

• 项目与版本：项目名称、版本编号、项目负责人、产品负责人、申请日期。
• 原计划基线：原承诺日期、交付范围、关键里程碑、验收标准及基线确认人。
• 当前状态：已完成工作、剩余工作、阻塞项、关键路径状态和依赖负责人。
• 偏差说明：原因类别、发生时间、影响任务、证据链接及可控性判断。
• 预测区间：乐观、最可能和保守完成时间，估算假设及主要不确定性。
• 备选方案：整体延期、范围调整、分阶段发布或维持原计划的成本和风险。
• 建议决策：推荐选项、推荐理由、未选方案的主要代价。
• 新承诺：新日期、交付范围、验收责任人、检查点、退出条件和升级规则。
• 审批记录：决策人、决策时间、接受的风险、附加条件和未决事项。

2. 审批者的五个核对问题

审批者无需重做项目管理，但应确认申请是否具备决策所需的信息。以下问题比“团队是否努力”更有用，也能减少审批流于形式。

1. 原始范围和当前范围是否能清楚区分？
2. 延期原因是否有时间、任务和依赖证据支撑？
3. 新日期是否由剩余工作和不确定性推导，而不是按惯例顺延？
4. 是否比较过缩范围、分阶段交付或维持原计划的代价？
5. 如果新计划再次偏差，谁在什么节点采取什么动作？

3. 复盘时保留三类记录

第一类是计划记录：保留最初基线和每次经批准的调整，不能只覆盖成最新日期。第二类是决策记录：保留当时可获得的信息、备选方案和风险接受人，避免事后用结果倒推当时判断。第三类是结果记录：比较实际交付范围、验收情况、延期后质量表现和下游影响。

如果团队用统一平台管理这些信息，应把字段和状态设计得足够简单。字段过多会让申请人复制粘贴，字段过少则无法复盘。开始阶段只保留支持决策和统计所必需的内容，运行一两个周期后，再根据实际缺口增减，而不是一开始就试图建立完美流程。

十、结尾：成熟的延期管理，是让坏消息更早变成可选方案

延期管理的独特价值，不是把所有项目都推回原定日期，而是把不确定性变成组织能够处理的选择。提前暴露风险，团队就有机会缩小范围、调整依赖、保护质量或改变发布节奏；临近截止才提出延期，往往只剩下接受损失或承担更大风险。

下一步可以从过去一个季度的项目中抽取延期案例，统一基线和统计口径，先计算预警提前量、预测日期误差、连续延期申请率和延期后验收通过率。然后选一个跨团队项目试运行申请模板和决策检查点。先让延期申请能够解释偏差、比较方案、兑现新承诺，再考虑增加审批层级或采购工具。工具的作用是让事实可见、过程可追溯；真正决定延期管理质量的，仍是团队愿不愿意提前说出风险，以及管理者是否愿意基于证据做取舍。