填报工时怎么做？实施团队协同管理：工时管理从0到1

填报工时怎么做，真正的难点通常不是员工不会填，而是团队直到月底才发现：项目计划、实际投入和交付结果彼此对不上。实施团队尤其如此，客户现场、远程支持、内部协调、等待权限、返工和差旅都可能消耗时间，却未必能直接对应一个清晰的任务。我的判断是，工时管理从0到1，先要把“为什么记录、记录到什么粒度、谁来核对、数据如何被使用”说清楚，再配置表单或管理工具；否则，填报越勤，团队越容易得到一份看似精确、实际无法决策的数字。

一、先讲核心结论：工时不是考勤，而是项目经营的输入

1. 工时管理从三个问题开始

我建议实施团队先回答三个问题：我们要用工时判断什么？员工应把时间记到什么对象？数据由谁在什么时间核验？如果这三个问题没有明确答案，就不要急着规定每天填几次，也不要先讨论管理软件的字段。

对实施团队来说，工时通常至少支持三类决策：估算项目真实投入、识别计划与实际的偏差、判断哪些交付活动正在挤压团队容量。它不能单独说明员工是否高效，更不能替代交付质量、客户结果和任务复杂度的判断。

一个可执行的起步原则是：以任务或交付活动为记录对象，以项目为归集维度，以周为核验节奏，以偏差复盘为主要用途。如果团队已经有成熟项目计划，再考虑按任务填报；如果项目对象和任务边界都不稳定，先建立轻量活动分类，避免要求员工把时间填到一堆不存在或频繁变化的任务上。

2. “从0到1”不是一次性把制度做全

我更倾向于把工时管理拆成四个阶段：定义口径、小范围试运行、核验数据质量、再决定是否扩展。第一阶段不追求指标丰富，而是确认团队能否用相同规则记录同一类工作。

第二阶段也不应立刻覆盖全公司。可以先选一个项目周期明确、负责人愿意参与、现场与远程工作都有的实施小组，跑完至少两到四周。这个周期不代表任何行业标准，只是便于观察工作周之间的波动，并检验周末补填、跨项目支持和等待时间等情况。

第三阶段要看数据是否可解释，而不只是看填报率。员工全部提交了工时，但大量记录落在“其他”或同一个笼统任务上，数据完整不等于数据有用。第四阶段才是把验证过的口径扩展到其他团队，并保留因业务差异而不同的分类。

这些边界很重要。若把工时数据直接当作个人绩效结论，团队会倾向于记录容易解释的时间，而不是记录真实过程。管理者看到的可能是更整齐的数字，却不是更接近事实的项目画像。

二、实施团队的真实场景：时间花在哪里，常常和计划表不同

1. 客户现场并不等于项目任务在持续推进

实施人员的一天，可能从进场沟通开始，随后等待客户开通账号，接着处理配置问题，再参加跨部门评审，最后远程协助测试。若只按“客户现场”或“项目实施”填一整天，管理者就看不到哪些时间用于交付，哪些时间消耗在等待、协调或返工。

反过来，如果要求员工每隔十几分钟切换一次任务，也会把记录负担转嫁给一线。实施现场往往有临时沟通、网络不稳定和任务切换，细到分钟的记录既难坚持，也容易变成事后回忆。

因此，工时粒度应由管理问题决定，而不是由软件能提供多少字段决定。若管理者只需要识别配置、培训、测试、支持等活动占比，按活动块记录即可；若项目成本必须追踪到具体交付物，才有理由进一步拆分到任务。

2. 项目计划之外的工作，往往解释了投入超支

我在设计工时分类时，会专门检查计划外工作是否有落点。比如客户资料未准备、环境不可用、审批等待、需求澄清、数据修复和上线后支持。这些工作未必都是浪费：有些是合同交付的一部分，有些来自客户侧条件，有些则是范围变化或内部返工。若统统记成“其他”，后续就无法区分责任和处理方式。

一个有用的分类不必先追求完美，但要让团队能够回答：这段时间服务于哪个项目？属于哪种工作？是否有明确任务或问题单？如果答案不全，至少要有一个可复核的备注或关联记录。

3. 多项目并行会让“每天八小时”产生错觉

实施顾问可能上午在项目甲处理配置，下午参加项目乙的远程评审，间隙还要回答项目丙的紧急问题。此时，单看每个项目的计划就容易低估切换成本。每次切换未必都能单独准确计量，但长期看，跨项目支持、临时响应和会议会侵蚀连续交付时间。

我会把“跨项目支援”与“内部事务”分开，而不是让它们散落在各项目的模糊任务里。这样做不是为了把所有时间都归到某个成本中心，而是为了识别团队容量究竟被什么切碎。

三、常见误区：数字看上去整齐，不代表工时管理有效

1. 把填满八小时当成目标

不少团队会先设定“每天必须填满八小时”，但这只是一个核对条件，不能直接当成质量标准。出差、请假、培训、待命、跨时区支持和非工作日值守都会改变当天可填报时间。若系统只接受固定时长，员工就会把无法归类的时间塞进熟悉任务，造成看似完整、实则失真的记录。

更稳妥的做法，是先区分应工作时长、已记录项目时长、非项目工作时长和未解释差额。差额超过团队约定阈值时再核验，而不是让每个人机械地补到同一个数字。阈值应结合组织制度和业务场景设定，不宜把某个通用数值当作所有团队的标准。

2. 把工时越细等同于越准确

记录粒度越细，员工回忆成本和操作成本越高。若每天的任务频繁变化，要求精确到几分钟，很可能得到的是事后估算，而不是实时记录。对成本核算需要精细数据的团队，可以要求在任务切换或工作块结束时记录；对刚开始建立机制的团队，先以半小时或一小时为记录单位进行试运行，观察是否足以回答管理问题。

粒度过粗的问题也真实存在。一个任务跨越数周、包含实施、协调和返工，却只留下一个总时长，管理者无法解释偏差。解决方法不是无限拆小，而是按照可管理的工作边界拆分：一个任务应有明确成果、责任人和完成条件。

3. 把填报率当作唯一成功指标

填报率适合检查流程是否有人执行，不适合单独证明数据可用。员工按时提交了记录，但项目归属错误、任务已失效、备注缺失，或者所有活动都被归到同一类别，管理者仍然无法做可靠分析。

我通常建议同时看“提交及时性、分类可解释率、项目关联完整率、抽样复核差异、偏差闭环率”。这些是管理用的观测指标，不是统一行业标准。开始试运行时，团队可以先建立自己的基线，再根据复核结果设定合理目标。

4. 把工时直接用于个人排名

工时多不必然意味着贡献高，工时少也不必然意味着效率高。不同项目的复杂度、角色职责、客户成熟度、任务风险和工作方式都不同。把总工时排成榜单，很容易鼓励填报更多时间，或让员工回避耗时但必要的协作。

如果管理者确实要做个人层面的复盘，应结合工作结果、任务难度、交付质量、响应责任和团队协作，并明确数据的用途与访问范围。工时记录更适合成为“问问题的线索”，而不是自动生成结论的裁判。

5. 把“其他”当成永久分类

初期保留“其他”有助于避免员工无处可填，但如果它长期占比很高，就说明分类设计没有跟上实际工作。我的处理方式是每两周抽查“其他”记录：若一批记录反复出现同一种活动，就新增分类或调整任务结构；若内容确实零散，则保留但要求简短备注。

要避免相反的极端：每个团队都不断创建新类别，最后分类数量超过员工能记住的范围。分类的价值不在于名字多，而在于能支持具体决策。一个分类如果既不影响项目复盘，也不改变资源安排，就应考虑合并。

四、专业判断逻辑：先确定口径，再决定粒度和工具

1. 先问管理问题，再设计分类

分类的第一原则是能支持管理问题。假设团队最想知道实施超时的来源，可以把计划交付、变更、等待、返工、支持分别记录；如果团队要做成本归集，可能还要区分合同项目、售前支持、内部投入和客户成功活动；如果当前只是想改善容量规划，就不一定需要分到合同成本科目。

在设计字段前，我会把每个分类写成一句定义，并补一个正例和反例。例如，“等待”是已经具备推进意愿，但因外部条件暂时无法执行工作；“沟通协调”是主动进行范围澄清、决策对齐或交付安排。若两类活动经常被混淆，先改定义或合并分类，不要指望培训能解决结构性歧义。

2. 用“最小可用粒度”决定拆分深度

最小可用粒度，是能支撑一项重要分析、但不会显著增加记录负担的最小工作单位。对于实施团队，常见的层级是“项目，阶段，任务，工时记录”。若阶段级数据已经足以识别实施偏差，就不必强制所有时间都落到细颗粒任务；若要分析某类部署活动的估算误差，则需要相对稳定的任务模板。

我会用以下判断顺序：第一，偏差发生后，当前记录能否找出具体原因？第二，员工能否在工作完成时快速选择正确对象？第三，任务拆分是否稳定到足以支持跨项目比较？只要其中一个答案是否定的，就先补口径或流程，再提高粒度。

3. 把计划工时和实际工时放在同一口径下

很多所谓“超时”并不完全是真超时，而是计划只算了配置和测试，实际却把培训、评审、等待和返工也纳入了项目。对比前必须明确计划的范围：估算包含哪些活动？是否考虑项目管理、客户沟通、差旅和上线支持？若计划和实际的边界不同，偏差数字会制造错误结论。

我建议在项目模板或估算说明中注明包含项与不包含项，并为变更建立独立记录。这样在复盘时可以拆成“原范围估算偏差”和“范围变化增量”，而不是把全部实际投入压到同一个预算数字上。

4. 设计异常规则，不设计自动定罪规则

规则可以帮助发现待核实的数据，例如同一时段重复填报、工时落在已关闭任务、长时间没有关联任务、周末出现异常记录等。规则的输出应是“请核实”，而不是“无效工时”或“效率低”。异常可能来自补录、跨时区、系统同步延迟，也可能确实是填报错误。

管理者要为异常处理设定责任人、期限和记录方式。若员工改动了时长或关联对象，应保留修改痕迹和原因；如果系统无法保留审计记录，就至少要有可查的变更说明。数据治理不是为了复杂，而是为了在产生争议时能还原过程。

5. 选择工具时看闭环，而非只看计时器

用表格、项目管理平台或工时系统都可以起步，差别在于团队规模、项目对象的稳定性、权限要求、报表需求和现有流程。工具评估不应只看能不能填数字，而要检查任务能否关联、审批或核验是否顺畅、数据是否可导出、权限是否合理、修改是否留痕，以及不同项目能否使用一致口径。

对中大型企业或百人以上组织，若任务管理、项目协作和工时汇总分散在多个系统，长期维护口径的成本会越来越明显。可以把 PingCode 作为项目协作与管理平台的示例，重点评估其是否能支撑团队已有的项目、任务和流程，以及工时记录与任务状态、权限和报表的衔接。是否适合仍应由试点验证，不能仅凭功能清单下结论。

五、案例推演：用四周试点验证，而不是先宣布全员上线

1. 先选一个能暴露问题的试点团队

下面是一组情景模拟，用于说明试点如何设计，不代表某个企业的真实统计。假设一家实施团队有18人，同时负责多个客户项目，其中既有驻场交付，也有远程配置和上线支持。管理者发现项目复盘经常出现“投入超出估算，但说不清超在哪里”的情况。

如果直接要求全员按任务填报，很可能先得到抵触情绪。试点可以选一个负责人愿意参与、项目仍处于交付中段、工作类型相对丰富的小组。开始前先记录现有计划、任务、项目范围和已知风险，确保试点前后比较的是相近内容，而不是拿不同阶段硬做结论。

2. 第一周重点验证分类，不急着评价效率

第一周可以设置少量分类：计划内交付、需求变更、客户等待、返工、临时支持、内部事务。员工按工作块记录，项目经理每周抽查部分记录，重点问“这条记录为什么落在这个分类”，而不是检查员工是否把每分钟都记齐。

若“等待”被理解成项目空闲、“支持”被理解成只有正式工单才能填，说明定义需要改。试点初期最有价值的信息，往往是员工不知道该选什么，而不是员工漏填了多少分钟。把高频困惑改成选择说明，通常比开一场更长的培训有效。

3. 第二至四周验证偏差能否转成行动

第二周开始，团队可以把记录与计划、任务状态和变更信息进行对照。若某项目额外投入集中在需求澄清，就检查范围管理；若等待时间多，就确认客户侧前置条件；若返工偏高，则检查配置模板、测试覆盖或交接质量。

四周结束时，不应只汇报“提交率达到多少”。更值得讨论的是：有多少偏差能追溯到明确原因？哪些分类需要合并或拆分？哪类工作长期挤压计划交付？管理者根据记录采取了什么动作？如果没有任何项目计划或工作方式发生变化，说明团队可能只是新增了录入工作。

4. 用一组情景数据演示如何读数

假设试点前，项目组只能看到每个客户项目的累计投入，无法区分计划交付、等待和返工。试点期间，四周共记录360人时，其中计划内交付250人时、需求变化42人时、等待31人时、返工22人时、支持与内部活动15人时。所有数值均为情景模拟，目的不是设定行业基准，而是演示如何从总量转向原因分析。

如果只看总时长，项目似乎超了预算；分开后，团队会先询问：42人时的需求变化是否有正式变更？31人时等待是否来自相同的前置条件？22人时返工是否集中在同一类配置问题？答案会决定下一步是重估范围、改善客户准备清单，还是更新实施模板。

更重要的是，分类本身不能替代证据。需求变化应尽量关联变更记录，返工应尽量关联缺陷或问题，等待应注明阻塞条件。没有这些上下文，分类只是更细的标签，仍不足以支持准确复盘。

六、落地步骤：把制度、流程和日常操作串起来

1. 写一页工时口径说明

试点之前，用一页纸写清记录目的、统计对象、分类定义、时间单位、补录期限、审核方式和数据用途。说明要回答员工最关心的问题：为什么记录？管理者会怎么看？是否用于绩效？谁可以查看？出错后如何修改？如果这些问题模糊，员工会自行推断，执行阻力往往来自不信任，而不是不会操作。

口径说明不应追求法律文本式的严密，而应减少日常选择时的犹豫。每类活动给一个正例和反例，通常比一段抽象定义更有效。规则调整时，注明生效日期和变更点，避免同一周的数据被不同口径解释。

2. 统一项目、阶段和任务的命名规则

如果项目名称有多个版本，任务长期不更新，或者员工不知道内部支持该记到哪里，填报页面再简单也无法保证数据质量。项目负责人应维护有效对象清单，及时关闭过期任务，并为跨项目支持、培训、售前和团队内部事务提供稳定入口。

对于重复出现的实施工作，可以建立任务模板，但模板应当是估算与复盘的参照，不是所有项目必须完全相同的作业清单。客户环境、数据质量和集成复杂度不同，照搬模板容易让计划看起来统一、实际却忽略项目差异。

3. 让记录尽可能靠近工作发生时

工时可以采用每日简记、工作块结束后记录，或每周集中补录。没有一种方式适用于所有团队。客户现场节奏变化快时，适合用短备注先记录阻塞和活动，稍后补齐项目任务；工作内容稳定的团队，则可以在任务完成时记录。

若采用周末补录，要注意回忆误差。管理者可以关注记录日期与实际工作日期的间隔，并在试点中观察员工补录是否集中在周末或月底。出现集中补录时，不要立即处罚，先确认系统访问条件、移动端体验和团队工作节奏是否构成障碍。

4. 设定轻量核验，而不是逐条审批

并非每一条记录都需要主管审批。对工时数据做逐条审批，可能把项目经理变成录入纠错员，拖慢双方工作。可先采用异常规则加抽样复核：检查缺少项目、重复时段、关闭任务上的新记录、异常长时段和大量“其他”等情况，再由负责人核实。

核验应关注规则是否被一致执行。例如同一种客户等待，在项目甲被归为等待，在项目乙被归为配置，说明分类定义或管理习惯不统一。此时的修正对象可能是制度和培训，而不只是某个员工的记录。

5. 每周做一次短复盘，每月做一次规则回看

每周复盘可以控制在短会内，围绕三件事展开：与计划相比哪里出现明显差异？差异的原因是什么？下周要采取什么行动？会上不需要逐条朗读工时记录，重点是挑出有决策价值的偏差，并确认负责人和截止时间。

每月回看分类和字段是否仍然合适。若某类别长期为零，可能不需要；若“其他”持续偏高，可能需要拆分；若员工总是在同一处选错，可能是界面或定义问题。规则不是发布后永久不变的制度，而是要随着工作方式和项目结构迭代。

6. 给每项数据设定使用边界

工时数据涉及工作过程、项目投入和人员信息，应明确访问权限、保存期限、导出流程和用途限制。若用于项目经营分析，应说明汇总方式；若要用于人员管理，应说明适用范围和复核机制。不要让员工在没有说明的情况下，发现原本用于估算的字段被突然拿去个人排名。

在工具中配置最小必要权限，减少无关人员查看明细的机会。对外报告优先使用项目或团队级汇总，除非业务确有必要，不要把员工逐日记录直接暴露给客户或无关部门。

七、不同情况下的行动建议：不要让所有团队照抄同一套规则

1. 团队少于十人、项目对象还不稳定

小团队不一定需要复杂系统。先用共享表格或现有任务工具建立最少字段：日期、项目或活动、任务说明、时长、简短备注。把规则控制在员工能快速理解的范围，试跑两周后再看哪些信息真正被用于决策。

此时最值得优先解决的是“工作记到哪里”和“计划外工作如何记录”，而不是自动审批、复杂成本中心或多层级报表。表格出现多人覆盖、版本冲突或月度汇总耗时明显增加时，再评估更合适的系统化方式。

2. 百人以上、多项目并行的实施组织

团队人数增长后，口径不一致会快速放大。不同部门可能各自建项目、改分类、导出报表，再由管理者手工拼接。此时要先确定项目主数据、角色权限和跨团队分类规则，再评估能否在同一管理平台中衔接项目、任务和工时。

可以安排跨角色试点，包括项目经理、实施顾问、交付负责人和财务或运营代表。对 PingCode 这类项目协作管理平台的评估，重点放在已有任务结构如何承载工时、跨项目报表是否可用、权限与审计如何设置、员工记录路径是否足够简洁。试点验证不能只由管理员完成，必须让真实填报者参与。

3. 工时需要用于客户计费或合同核算

计费场景对记录证据的要求更高。需要明确哪些活动可计费、哪些活动属于内部成本，客户确认或合同规则如何关联，以及补录和修改是否留痕。任何计费口径都应与合同条款、交付协议和财务流程一致，不能仅凭系统字段来认定某段时间可向客户收费。

这类团队应设置更清晰的审核节点，并对争议记录保留说明。代价是流程更重，员工需要多填一些上下文，因此只对确有计费价值的字段增加要求，不要把所有内部管理字段一并变成客户结算材料。

4. 工时主要用于改善估算与排期

如果核心问题是“项目总是估不准”，就要把历史工时与项目类型、复杂度、范围、环境条件和交付结果一起保存。只存一个项目总时长，难以形成可复用估算。应关注相似项目或相似任务的分布，而不是只拿一个成功项目的数字当模板。

当历史项目之间差异很大时，先按客户成熟度、部署方式、集成数量或数据质量等条件分组。样本不足时，明确标注估算置信度，不要把少数项目的平均值包装成精确标准。

5. 工时用于容量规划和资源协调

容量规划关注的是可用于计划工作的时间有多少，以及哪些常规责任会占用团队资源。应区分项目交付、客户支持、售前协助、内部培训、休假和例行会议，避免将名义工作日全部当成项目可用时长。

当团队被临时支持频繁打断时，单纯加人未必是首选。先观察支持请求的来源、频次和处理时段，判断是否能通过轮值、知识库、服务分级或集中答疑降低切换成本。工时数据可以指出容量被占用，却不能单独决定应该增员还是改流程。

八、不同方案的取舍：精细度、负担和可解释性不能同时拉满

1. 日填还是周填

日填更接近工作发生时，通常有利于减少记忆偏差；代价是增加日常操作频次，对现场工作和临时响应较多的岗位尤其明显。周填操作更集中，但越接近周末越依赖回忆，细节更容易丢失。

如果选择周填，可以要求员工先记录关键阻塞、变更和返工，再补齐时长；如果选择日填，则要把记录路径做短，并允许稍后修正。判断标准不是哪种方式更先进，而是团队能否稳定执行，且记录质量足以回答目标问题。

2. 任务级还是活动级

任务级记录更适合复盘交付物、估算任务成本和追踪责任边界，但前提是任务本身足够清晰。活动级记录上手快，适合团队刚开始建立分类或任务管理成熟度不足的情况，但它不一定能指出某项具体交付物为何超时。

可以先用“项目加活动”起步，待任务结构稳定后，再把少数高价值工作拆到任务级。不要把所有活动都强行绑定到细任务，也不要因为任务管理不成熟就放弃工时记录；关键是先明确现阶段最需要看见什么。

3. 自报为主还是主管核验为主

自报机制操作轻，能让员工掌握自己工作的上下文，但会受到记忆、分类理解和填报习惯影响。主管逐条核验看似更严谨，却容易消耗管理时间，并诱发员工只填容易通过的内容。

折中做法是自报加规则检查、抽样复核和差异说明。主管介入异常和高风险项目，而不是逐条代替员工判断。若团队需要客户计费或审计级证据，再提高复核强度，并同步投入足够的审核资源。

4. 统一分类还是项目自定义分类

统一分类有利于组织层面的比较与汇总，但如果分类无法表达某条业务线的真实工作，员工会把记录塞进不匹配的选项。完全由项目自定义又会导致同名不同义，最后无法跨项目分析。

较稳妥的方式是“组织级核心分类加少量项目扩展字段”。核心分类保持稳定，项目扩展用于描述特殊工作，并且由明确责任人审批。每季度或每个项目阶段检查一次扩展项，及时合并重复分类。

5. 看人力成本还是看交付过程

如果企业需要成本核算，工时应与角色成本、合同和财务规则衔接；如果目标是改善交付，记录应更关注任务、阻塞、返工和范围变化。两种目的可以共用部分数据，但不能默认同一组字段同时满足所有分析需求。

以成本核算为主，优先保证项目归属、角色和计费规则准确；以交付改进为主，优先保证任务上下文、偏差原因和管理动作完整。目标不同，分类、权限和报表也应有所差异。

九、衡量有没有做对：从填报完成转向管理闭环

1. 先建立基线，再设目标

团队刚启动工时管理时，不宜直接照搬外部的填报率、偏差率或效率目标。不同团队的业务节奏、统计口径和系统条件差异很大，先采集一段基线数据更可靠。基线不是拿来证明团队差，而是说明当前记录能力和管理问题在哪。

可以跟踪提交及时率、项目关联完整率、分类可解释率、异常记录处理时长、估算偏差原因闭环率等指标。每个指标都要有明确分母和统计周期。例如“及时提交”是指截止日期前提交的记录占应提交记录的比例，不能只公布一个百分比而不说明应提交范围。

2. 把指标分成数据质量与经营结果两层

数据质量指标回答记录是否可信，经营结果指标回答记录是否帮助改进。前者包括关联完整、重复记录、分类清晰和异常处理；后者包括估算偏差变化、等待原因改善、返工问题减少、容量计划更准确等。

不能因为某一项经营结果短期没有变化，就认定工时机制失败。比如客户环境等待并非实施团队可以直接控制，工时数据可能首先帮助团队提前识别风险、调整排期和准备升级沟通。管理动作先于结果改善，应该区分观察周期。

3. 每个指标都要配一个行动责任人

若数据指出等待增加，但没有人负责推进客户前置条件，指标只会成为月报里的红色数字。若返工增加，却没有技术负责人检查配置模板，团队就会在同一个问题上持续投入。每个高优先级偏差都应对应行动、负责人、期限和复查方式。

我建议每次复盘至少留下一个可检验的改进假设。例如：“下个项目提前确认测试账号，预计减少环境等待；由项目经理在启动阶段检查，下一项目复盘时核对等待时长。”这比“加强沟通、提升效率”更容易验证。

十、结尾：工时管理的价值，在于让偏差变得可讨论

填报工时怎么做，最实用的答案不是“每天填满多少小时”，而是先让团队用同一套规则描述投入，再把投入放回项目范围、任务状态、变更和交付结果中解释。实施团队尤其要看见计划外工作：等待、返工、支持和范围变化，往往比一个总工时更能说明项目为何偏离计划。

我更愿意把工时管理看成一种组织记忆：它记录的不是员工有多忙，而是项目为什么花了这些时间、哪些条件可以提前准备、哪些工作可以复用、哪些阻塞需要被管理。数据只有在引发计划调整、流程改善或资源协调时，才真正超越了填报本身。

下一步可以这样做：选一个项目组，写出一页口径说明，设置少量可解释的分类，试运行两到四周；每周抽查记录并收集困惑，试点结束后挑出一项最明显的偏差，形成具体行动并复查结果。先让一条数据链真实、可解释、能闭环，再考虑扩大范围和提高精度。