填报工时实操方法：研发团队提升工时管理效率的流程优化方法与模板

填报工时实操方法：研发团队提升工时管理效率的流程优化方法与模板

研发团队填报工时，最常见的失败不是“员工忘记填”，而是填完以后没人能解释数据为什么这样、该据此做什么。我见过的典型场景是：周五集中补录，一位工程师把整周 40 小时平均分到几个任务；报表看起来完整，却无法回答需求为何延期、返工耗了多少、下个迭代需要多少人力。工时管理要提升效率，重点不是多加一道审批，而是把记录时点、任务粒度、分类规则和复盘动作设计成一套闭环。

一、先讲核心结论：工时填报不是打卡，而是决策数据的采集

1. 先明确工时数据要回答什么问题

在设计填报流程前，我会先问管理者一个问题：拿到工时数据后，团队准备做什么决定？如果答案只是“看看谁忙”，就不应急着要求所有人精确到分钟。工时采集的成本必须由决策价值来支撑，否则它很快会变成形式主义。

一套可用的研发工时数据，通常服务于四类判断：项目投入和预算、计划与实际偏差、研发活动结构、跨团队资源冲突。它也能帮助团队识别等待、返工、故障处理等隐性成本，但不能直接替代绩效判断，更不能简单把填报时长等同于产出价值。

我的判断标准是：每个字段都要对应一个明确问题，每张报表都要对应一个可执行动作。无法说明用途的字段，优先删除；没人会根据它采取行动的报表，不值得要求团队额外填数据。

2. 用“够用的准确”替代“看起来精确”

研发工作有大量上下文切换、讨论和等待。要求成员把每次活动精确记录到分钟，表面上提升了粒度，实际却可能增加记忆负担和事后编造。对于多数团队，按任务记录到 0.5 小时或 1 小时，往往比按分钟更适合日常管理；具体粒度要结合结算、合规或项目核算要求决定。

我通常建议先把准确性定义为“能支持团队决策的可信程度”，而不是小数点后有几位。比如，团队要分析某版本延期，知道某需求实际投入 30 小时、其中测试修复 8 小时，通常比知道每次讨论精确持续 17 分钟更有用。

3. 用一条闭环衡量流程是否成功

工时流程的完整性不应只看“填报率”。我会把结果拆成四段：成员能否低成本地记录，负责人能否及时发现异常，项目经理能否解释偏差，团队能否根据复盘改变计划或流程。只要最后一段不存在，前面的数据越多，团队越容易把填报视为额外负担。

二、背景和真实场景：为什么研发团队越催填，数据有时越不可信

1. 工作节奏与填报节奏不匹配

研发工作往往以任务、代码评审、测试、故障处理和跨团队协作为单位推进，而工时系统常以日期或周为单位要求记录。成员每天切换多项任务，如果系统没有快速选择当前任务的路径，填报就会被推到周末。时间间隔越长，记忆越依赖估算，记录自然更像“把 40 小时分完”，而不是还原工作过程。

这不是简单的态度问题。若一个人周内处理了 15 项工作，却要在周五回忆每项工作的起止时段，认知负担本身就很高。管理者越用提醒和追责压缩提交时间，越可能得到更快但更粗糙的记录。

2. 任务结构与工时分类不匹配

有些团队只有“需求开发”一个大任务，设计、编码、自测、联调和缺陷修复都被记在同一处；另一些团队把任务拆得过细，成员每天需要在几十个小项之间寻找归属。前者无法分析活动结构，后者把记录成本推得过高。工时任务粒度应处于两者之间：够支撑管理分析，又不要求员工重复维护一套复杂目录。

分类不清也会造成口径漂移。有人把代码评审记作开发，有人记作协作；有人把等待外部接口的时间记在需求上，有人记入“阻塞”。报表数字可以精确到小数，定义不一致仍然无法横向比较。

3. 项目管理者需要的是解释，而不是一张总数表

项目负责人真正关心的通常不是“这个项目用了 960 小时”，而是：哪些工作消耗超出计划？超出来自需求变化、技术不确定性、返工还是资源等待？下个阶段是否要调整范围、缓冲或人员配置？如果系统只产出汇总数字，管理者就会把解释工作重新交还给成员，要求他们额外写周报。

我会把“记录一次、复用多处”作为流程设计原则。工时记录应尽量挂接到团队已经维护的需求、缺陷、迭代或项目任务中，而不是再建一套与工作流并行的台账。对 100 人以上的组织，尤其要先统一项目、任务和人员的基础数据口径，否则跨团队报表会把不同定义混在一起。

4. 合适的工具不能替代流程口径

对于中大型研发组织，可以用 PingCode 这类项目管理平台作为流程承载方式的例子，评估需求、任务、项目和工时信息能否关联，以及角色权限、报表和提醒是否适合组织的管理方式。这里的重点不是预设某个平台一定满足全部需求，而是把评估问题具体化：成员能否从当前任务快速记时，负责人能否看见异常，管理员能否维护统一口径。

如果现有平台无法支持某项关键场景，不一定马上换系统。先检查是配置、字段定义、权限、培训还是流程本身的问题。工具选型要基于真实工作流验证，而不是只看功能清单或演示界面。

三、常见误区：填报率上升，不等于管理质量提升

1. 误区一：把准时提交当作数据准确

按时填报只是数据质量的一个前提，不是准确性的证明。成员可能每天按时填，但把会议、代码评审和故障排查全部归到一个任务；也可能为了满足合计工时要求，把没有明确归属的时间填入“其他”。因此，提交及时性和内容可信度必须分开看。

更有价值的检查方式是抽样：随机选几条记录，确认它是否关联到真实任务、时间跨度是否合理、工作类别是否符合定义。不要要求所有人每天提交详尽说明，否则校验本身会成为另一种填报负担。

2. 误区二：把 100% 工时填满当作管理目标

若团队规定每天必须填满 8 小时，成员会倾向于把所有时间都塞进可选任务。实际研发过程中，等待审批、短时沟通、环境故障和临时支持并非总能准确归类。强制填满会制造“完整”但不一定真实的数据。

我的建议是明确哪些时间需要记录，哪些只需要按团队规则处理。例如，项目核算要求记录全部工作时间，就要给会议、支持、培训和组织事务提供稳定归类；如果目标是估算项目投入，则可以聚焦项目相关工时，并清楚标记不计入范围的活动。不能一边要求全量记录，一边不给合理类别。

3. 误区三：把工时排行榜用于个人绩效排序

工时长短不等于贡献大小。高工时可能来自范围变更、技术债、环境问题或流程等待，也可能只是估算偏差；低工时可能意味着经验丰富、复用成熟，也可能意味着记录遗漏。把个人工时直接用于排名，会诱发防御性记录，降低成员暴露阻塞和返工的意愿。

工时数据适合用来讨论项目投入、工作结构和计划偏差，不适合脱离任务难度、交付质量、职责范围和协作贡献做个人优劣判断。若管理目标是改进团队效率，就应先看系统性因素，而不是先找“工时异常的人”。

4. 误区四：把任务拆得越细，分析就越精确

拆分任务确实可以增加归属信息，但也会增加成员查找和维护的成本。任务粒度过细时，实际工作经常跨越多个子任务，成员要在做完工作后重新分摊时长；任务粒度过粗时，又无法解释偏差。拆分的标准不是“越细越好”，而是“是否能支撑一次明确的计划或复盘判断”。

一个可操作的测试是：团队能否根据任务拆分结果判断下一步工作、责任接口或风险？如果不能，拆分可能只是制造维护负担。反之，如果多个不同阶段的活动必须采取不同的估算、验收或复盘方法，就值得拆开。

5. 误区五：把缺少说明理解为员工不配合

记录缺失可能源自提醒不合时机、任务状态未同步、权限配置错误、类别定义冲突或移动端体验不佳。先把问题归因为态度，通常会错过真正的流程故障。管理者应先排查系统入口和任务结构，再判断是否需要行为提醒。

四、专业判断逻辑：先定口径，再设计任务和提醒

1. 用管理问题反推字段，而不是照搬模板

我设计字段时，会从“要解释什么”倒推“必须记录什么”。例如，想分析延期原因，至少要能关联计划任务、实际工时和变更或阻塞信息；想核算客户项目成本，需要明确项目归属、可计费与不可计费口径；想了解故障负担，则需要区分日常开发、缺陷修复和线上支持。

字段越多不代表越专业。每增加一个必填字段，都会增加记录和维护成本。可以先设最小字段集：日期、任务、工时、工作类别；再根据真正存在的决策需求补充项目阶段、阻塞原因或是否返工。只有经过使用验证的字段，才值得长期保留。

2. 任务粒度要同时满足记录和复盘

任务拆分可以从“一个记录对象是否对应一项可估算、可验收、可复盘的工作”来判断。若需求开发和缺陷修复由不同人员承担，且管理上要分别分析，就应拆成不同任务或使用可靠的工作类别。如果一项任务跨越多个迭代、包含多个独立交付物，通常也需要拆分。

但不必为每次短会、每封邮件创建独立任务。协作活动可以归入明确的类别，前提是团队能稳定区分，并且该类别对报表有意义。建议每个团队先用一个迭代验证任务粒度：若成员频繁询问“应该记在哪”，先修订目录和示例，不要靠临时口头解释维持。

3. 记录时点由工作类型决定

对于连续数小时的开发或测试，日末记录通常足够；对于频繁切换、支持响应和短时故障处理，最好在任务完成后或当日及时记录。并非所有工作都需要实时计时，关键是避免跨周回忆。团队可以把每天最后 5 分钟留给记录，而不是把整周补录安排成固定仪式。

对外部结算或审计要求较高的项目，记录粒度和审批要求可能更严格；对内部产品研发，则应优先控制填报摩擦。相同的表单规则不适合所有业务场景。

4. 质量校验需要有阈值，也要有例外

校验规则可以覆盖重复记录、任务状态不匹配、单日工时异常、无归属工时占比过高等情况。阈值要根据团队工作制度设定，不能机械照搬。例如，单日记录超出某个小时数可以触发提醒，但发布值守、跨时区支持或加班项目要有合理的例外处理。

更重要的是，异常提示应帮助修复数据，而非给成员贴标签。系统发现超时记录时，可以提示“请确认日期、任务或是否重复”，而不是直接给出“效率低”之类结论。校验规则的目标是提高解释能力，不是把管理判断伪装成自动评分。

5. 报表指标要兼顾过程和结果

我会把指标分为过程指标与结果指标。过程指标包括按时提交率、补录比例、无任务工时占比、记录修正率；结果指标包括计划偏差、返工投入占比、支持工作占比、估算误差。过程指标帮助定位流程质量，结果指标帮助讨论工作结构和交付计划。

单一指标很容易被误读。比如，返工投入占比上升，可能意味着质量下降，也可能是团队开始更准确地记录过去被隐藏的返工。分析时要看趋势、任务背景和记录口径是否变化，不能把一次波动直接归因于个人表现。

五、具体案例与数据观察：一个 60 人研发组如何把填报从补录变成复盘

1. 场景设定：数字是样本推演，不冒充行业统计

下面用一个 60 人研发组做流程推演，目的是展示怎样判断和测量改进，不代表公开行业基准。团队包含产品、开发、测试和运维协作人员，每两周迭代一次。改进前，团队周五集中填报，项目经理每月花约 10 小时清洗表格、核对任务归属，成员经常把联调、评审和返工混在“开发”类别中。

我会先保留原有计划和项目，不急着改考核制度，连续两周抽样观察三件事：填报发生在工作当天还是周末；任务类别是否稳定；异常工时能否在复盘时说明原因。这样先建立基线，才能区分是表单优化起效，还是业务变化导致数字变化。

2. 改动一：减少入口，不增加解释文字

团队将填报入口放在成员已使用的任务工作流中，并固定三个常用分类：计划内研发、缺陷与返工、支持与协作。对于培训、休假、组织事务等非项目活动，另设团队认可的归类规则。关键不是类别数量固定，而是减少高频工作在模糊选项中来回猜测。

任务标题也做了轻量规范：需求、缺陷、支持事项使用不同前缀或类型标签，负责人能从记录中看懂工作对象。团队没有要求把每个会议都创建成任务，而是把必要的协作时间归到稳定类别，避免任务目录膨胀。

3. 改动二：将日常提醒放在记录仍可回忆的时点

团队把提醒放在每日工作结束前，而不是周五下午。成员当天只需确认正在处理的任务、输入大致工时并选择类别；如果当日存在跨项目切换，再补充对应任务。对确实无法当天记录的成员，允许次日修正，避免为了按时提交而编造精确数字。

负责人不再逐人催促，而是每周查看未记录和高比例补录的总体情况。只有连续出现的系统性问题才进入团队复盘，例如任务目录找不到、权限不一致或某类支持工作长期无归属。

4. 改动三：每两周只复盘三个可行动问题

迭代复盘不展示个人工时排行榜，而是检查三件事：计划内工作与实际投入差异最大的任务是什么；缺陷与返工占比为何变化；支持和等待是否挤占计划任务。每次复盘最多形成两到三个行动项，例如补充技术验证、拆分过大的需求、明确外部依赖响应责任。

如果数据不能说明原因，团队会把它标记为“待核实”，而不是强行得出结论。一次偏差未必能证明流程有问题，连续多个迭代出现相同偏差才值得调整计划规则或工作方式。

5. 用数据对照改进前后，而不是只看总工时

在这个样本推演中，假设调整流程前的按时记录率为 62%，集中补录比例为 38%，无明确任务归属的工时占比为 17%，月度清洗时间为 10 小时。试运行四周后，假设按时记录率达到 86%，补录比例降至 14%，无明确归属占比降到 8%，清洗时间降至 5 小时。

这组假设数据并不意味着人力投入减少了，也不能证明交付质量自动提高。它只说明记录更及时、数据更容易使用、统计工作量下降。若计划偏差或返工比例没有变化，下一步应检查需求质量、技术风险和依赖管理，而不是继续给填报流程加字段。

6. 不要把相关变化当成因果证明

如果按时记录率提高，同时项目延期减少，不能马上断言是工时流程带来了交付改善。同期可能发生了需求范围缩小、人员变动、技术方案稳定或发布节奏调整。更稳妥的做法是记录变更背景，比较相似类型的迭代，并观察改进是否持续。

数据本身也会经历口径变化。假如团队开始把返工单独记录，返工工时占比短期上升，可能是记录变得更透明，而不一定是质量变差。任何趋势图都应标明定义调整时间，避免把口径变化误读成业务波动。

六、可直接采用的工时填报流程与模板

1. 先建立最小可用流程

我建议从一套简单、稳定、可修正的流程开始，而不是一次性制定一份几十页的制度。成员知道记录什么、何时记录、遇到例外怎么办；负责人知道检查什么、何时提醒、怎样处理异常；管理者知道数据用在哪里，这已经能覆盖大多数试点场景。

1. 任务准备：项目负责人在迭代开始前确认任务归属、负责人和必要类别，合并重复项，补充可识别的任务标题。
2. 日常记录：成员在工作当天或任务完成后记录日期、任务和实际工时；跨任务工作分别记录，不要求事后追溯到分钟。
3. 例外标记：遇到临时支持、等待、返工或任务未建等情况，使用约定类别或备注标记，不把无法归类的时间随意塞进普通开发任务。
4. 周度校验：负责人查看漏记、重复、异常长时段和无归属记录，先解决流程和口径问题，再联系相关成员补充必要信息。
5. 迭代复盘：对照计划与实际投入，讨论偏差原因、返工结构和支持负担，形成少量行动项，并在下一轮检查是否有效。
6. 月度调整：管理员抽样检查字段使用情况，删除没人用的字段，修订容易混淆的类别和示例，保留口径变更记录。

2. 一页式填报规则模板

3. 成员日常记录模板

4. 负责人周度检查模板

周度检查不需要逐条审问成员。负责人可以用一张简单检查表，将异常分为“记录问题、任务结构问题、计划变化、真实工作偏差”四类。每个异常只需要一个处理结论：修正记录、补充任务、更新计划或进入复盘。

• 漏记：是否存在尚未记录的工作？原因是忘记、任务找不到，还是权限或入口问题？
• 重复：同一日期和同一任务是否出现重复记录？是否由跨系统同步造成？
• 归属不清：“其他”或临时类别是否连续出现？是否需要补充任务或类别定义？
• 计划偏差：实际投入与估算差异是否由范围变更、返工、技术不确定性或等待造成？
• 改进行动：是否有人负责、何时检查？如果没有明确动作，就不要把异常包装成结论。

5. 复盘记录模板

七、不同团队和业务条件下的行动建议

1. 十人以内的小团队：少字段、短周期、靠例会闭环

小团队通常不需要复杂审批。先固定任务归属、类别定义和记录时点，使用现有协作工具即可。负责人每周抽查少量记录，在迭代复盘中讨论计划偏差。若填报本身耗时明显超过数据整理节省的时间，应该先简化，而不是扩展字段。

小团队的最大优势是沟通链短，负责人可以直接确认任务背景；最大风险是口径依赖个人记忆，人员增加后难以复制。建议将经过验证的分类和例外规则写成一页说明，别只靠“大家都知道”。

2. 百人以上的组织：先统一口径，再分层治理

中大型研发组织不能只依赖各团队自行解释。项目、任务类型、工作类别、组织结构和权限都需要相对稳定的定义。可以由平台或流程负责人维护企业级底层规则，同时允许不同业务线在有限范围内扩展本地类别，并明确哪些字段可横向比较、哪些只在团队内部使用。

对于 100 人以上的组织，试点范围应覆盖不同工作模式：产品迭代、平台研发、运维支持和客户项目。只在一个团队验证顺畅，不代表流程能适配所有团队。若使用 PingCode 等项目管理平台承载流程，可在试点中检查任务关联、权限配置、提醒方式、汇总报表和数据导出是否符合真实需要，并邀请一线成员参与可用性验证。

3. 客户项目或成本核算场景：精度要服从结算规则

涉及合同结算、项目成本分摊或审计时，工时记录可能有严格口径和审批要求。这类场景需要明确可计费与不可计费活动、跨项目支持的分摊规则、补录审批和数据留痕。此时更高的记录精度有明确业务价值，但仍应减少重复录入，并清楚说明规则如何与合同、财务口径对应。

建议先拿一个真实项目走完整流程：成员记录、项目负责人审核、财务核对、异常修正、最终汇总。只要任何一环需要反复复制数据，就应先解决流程衔接，避免把成本核算负担全部压到研发人员身上。

4. 高支持负荷团队：单独识别非计划工作

运维、平台和客户支持团队往往会被突发问题打断。若只按计划任务记录，临时响应会被隐藏，团队看起来像是“计划总做不完”。建议单独识别故障响应、客户支持、环境维护和常规研发，但不必为每次短时咨询都建立复杂任务。

管理者可以按周或迭代观察非计划工作占比及其波动。如果突发工作长期占据计划容量，就需要调整排班、预留缓冲或设立轮值机制；仅要求成员加快填报，无法解决容量被打断的问题。

5. 远程或跨时区团队：不把即时响应当作记录标准

跨时区协作中，成员的工作日边界不同，统一要求某个时刻填报容易造成不公平。应按当地工作日或约定的任务完成节点记录，并通过清晰的日期口径处理跨夜支持。管理者更应关注记录是否及时到足以支持计划，而非所有人是否在同一时间提交。

异步团队可以在任务评论或工作日志中记录关键阻塞和决策，再与工时数据关联。这样既保留必要上下文，也避免要求成员把工时备注写成重复周报。

6. 组织正在快速变化：先稳住定义，不急着做长期对标

在团队重组、项目切换或产品方向调整期间，项目边界和任务类别经常变化。此时可以用工时帮助观察资源流向，但不宜马上建立跨季度排名。先记录口径变更、生效日期和组织调整背景，待结构稳定后再做趋势比较。

如果业务本身正在变化，工时数据的核心价值是帮助看清资源去了哪里、什么工作不断挤占计划，而不是证明组织结构已经有效或无效。

八、不同方案的取舍：更精细不一定更好，自动化也不等于可信

1. 手工填报与自动采集的取舍

我的倾向通常是先做半自动：系统带入任务、项目和日期，成员确认类别与实际投入。自动采集代码提交数、在线时长或键盘活动，并不能直接得到真实工时。工具能记录事件，不代表事件天然具有管理解释力。

2. 日填、周填和任务完成后填的取舍

日填的回忆负担较低，适合任务切换频繁、工时需要及时核算的团队；周填操作集中，但更容易产生估算和遗漏；任务完成后填适合持续时间清晰的工作，却不适合跨周期任务。可以按工作类型混合使用，但必须统一数据日期和补录规则，避免同一张报表混合不同口径。

3. 审批与抽样校验的取舍

全量审批适合少数需要逐笔确认的结算或审计场景，但会增加负责人工作量，审批越慢，成员越可能延迟提交。抽样校验更轻，适合内部研发和持续改进，但要求异常规则清楚，抽样结果能反馈到流程修订。

可采取分层策略：普通记录自动通过，明显异常进入复核；客户结算、跨项目分摊或补录超过期限的记录按规定审批。这样将管理注意力集中在高风险数据，而不是让每条正常记录都排队等待。

4. 精细分类与低摩擦填报的取舍

分类越细，越能分析工作结构，但成员越容易选错，也越难保持跨团队一致。分类越粗，操作越轻，却可能无法区分计划开发、返工和支持。较稳妥的做法是先保留少数高价值类别，并观察是否有明确管理动作；如果某一类别从来没有引发任何分析或改进，就考虑合并。

分类是否值得保留，可以用一个简单问题判断：“看到这类工时后，我们是否会采取不同的计划、质量或资源动作？”如果答案是否定的，该分类大概率只是增加维护成本。

5. 统一标准与团队自治的取舍

统一口径有利于组织级分析，但如果规则僵硬到无法适配不同工作模式，团队就会用临时字段和线下表格绕开流程。完全自治则会造成同名不同义，无法汇总。建议统一核心定义、字段边界和数据权限，把少量扩展空间留给业务团队，并定期检查这些扩展是否值得长期维护。

九、上线检查与持续改进：先试点，再扩展

1. 两周试点要验证的事项

试点不以“系统上线”作为完成标准，而要观察成员能否顺利完成真实任务的记录。选一到两个业务特征不同的团队，覆盖需求开发、缺陷处理、支持协作等常见工作，并在开始前记录原有的补录比例、分类疑问和统计耗时。

• 成员是否能在不额外查表的情况下找到正确任务。
• 高频工作是否都有清晰类别，边界情况是否有处理办法。
• 日常记录是否比周末集中补录更容易坚持。
• 负责人是否能从报表识别需要核实的偏差，而非只看到汇总时长。
• 管理者是否能根据数据形成具体行动，或者证明当前指标暂时无决策价值。

2. 试点通过的判断条件

建议在试点前设定通过条件，避免上线后只看“大家有没有填”。例如，按时记录率达到团队设定目标、无明确归属的记录下降、统计整理时间减少，同时抽样核对没有明显的集中估算现象。具体阈值要根据基线定，不必照抄其他组织的数字。

若成员提交率提高但记录内容仍无法解释，试点不应直接扩展。先检查任务目录、类别定义和提醒设计；若报表更清晰但负责人没有采取任何行动，则应重新判断采集数据是否值得长期保留。

3. 每月维护口径，避免规则慢慢失效

工时规则不是一次发布就能永久有效。组织结构、项目模式和工作类型变化后，旧类别可能失去意义，新需求可能出现。管理员应保留口径版本和生效日期，减少跨期比较时的误读，并定期清理重复任务类型、无人使用字段和临时类别。

我更愿意把工时管理看作一种轻量的数据治理：少量稳定规则、明确的数据责任人、可追踪的口径变更，以及针对实际问题的复盘。若它变成一套没人理解的审批制度，系统上线越完整，维护成本反而越高。

十、结论：让工时数据回答问题，而不是证明忙碌

1. 真正的效率来自减少无效解释

研发团队填报工时，最值得优化的不是把每一分钟记录得更精细，而是让一条记录能被快速归属、让异常能被合理解释、让复盘能改变下一轮计划。填报入口顺手、分类定义稳定、任务粒度适中、提醒不打断工作，这些基础设计往往比增加审批和字段更有效。

当工时数据可以揭示返工、等待、支持负荷和计划偏差，它才成为改进交付的证据；当它只用于填满时数或比较个人长短，就会促使成员保护自己，而不是暴露真正的流程问题。

2. 下一步从一个小试点开始

如果团队现在还在周末集中补录，不要先重做所有制度。选一个迭代，记录三项基线：按时记录率、无明确归属工时占比、每月人工清洗时间。随后统一少数高频类别，把入口放回任务工作流，并在两周后复盘数据是否更容易解释。

我的独特判断是：好的工时流程不会让管理者更容易盯人，而会让团队更容易看见工作是怎样被消耗的。下一步就从删除一个没人使用的字段、澄清一个最容易混淆的类别，或把一次周末补录改成当日五分钟记录开始。先证明数据能带来更好的决策，再决定是否扩大范围。