工时表任务工时全流程：产品经理入门指南与一文讲清

工时表里最容易被误读的，不是“某人填了多少小时”，而是“这些小时究竟对应什么任务、处于什么状态、能不能解释项目的实际进展”。我见过团队把工时填报率做到接近百分之百，月底却仍然回答不了为什么版本延期：原因往往不是员工没填，而是任务拆得太粗、工时口径不一、填报和任务状态脱节。工时表任务工时全流程的核心，不是多填几格，而是把计划、执行、记录、核验和复盘连成一条可追溯的管理链。

一、先讲核心结论：工时表记录的不是忙碌，而是可解释的投入

1. 工时管理首先要回答三个问题

我判断一套工时流程是否有效，通常先看三个问题：员工做了什么、实际投入了多少、投入和结果之间是什么关系。若系统只能回答“这个月填了多少小时”，却无法关联具体任务、交付物和状态变化，那么它更像考勤补录表，而不是项目管理数据。

因此，产品经理入门时不应从“选一个工时表模板”开始，而要先确定记录目的。项目估算、资源协调、成本核算、客户结算、组织产能分析，都是可能的目的；但它们的统计粒度、审批要求和误差容忍度并不相同。

2. 把工时闭环理解为六个连续环节

我建议把任务工时流程拆成六步：定义口径、建立任务、估算工时、记录实际投入、核验异常、回到计划和复盘。每一步都应有明确责任人和可检查的结果，而不能把全部责任推给最后填写工时的员工。

1. 定义口径：说明哪些活动计入工时，采用小时还是人天，休息、会议、支持和返工如何处理。
2. 建立任务：让工作有明确的任务对象、负责人、时间范围和验收条件。
3. 估算计划：记录预计投入，并说明估算基于什么范围和假设。
4. 记录实际：按约定频率填写实际投入，尽量在工作发生后记录，而非月底回忆。
5. 核验异常：检查漏填、重叠、超计划、跨项目以及任务状态与工时不一致等情况。
6. 用于决策：将差异反馈到排期、估算、资源配置和流程改进，而不是只用于追责。

3. 计划工时和实际工时不能混为一谈

计划工时是承诺与预测，实际工时是发生过的投入记录。两者相减得到的差异，不应自动解释为个人效率高低。任务范围变化、依赖等待、验收返工、环境问题和估算偏差，都可能造成差异。没有上下文的差异数字，容易引导团队做出错误判断。

例如，某项接口开发预计 16 小时，最终登记 24 小时。如果任务中途增加了两个字段校验和一次兼容处理，那么 8 小时差异里有一部分是范围变化，不是开发执行效率下降。若系统没有变更记录，管理者只看到“超时 50%”，结论就可能完全偏离事实。

二、背景和真实场景：为什么产品经理需要懂任务工时

1. 工时数据常常是在问题出现后才被想起

产品经理通常不会因为“想统计小时数”而推动工时流程。更常见的起因是项目延期、需求频繁变更、跨团队资源冲突，或者管理层想知道一项功能为什么投入超出预期。到了这个时候，团队才发现任务没有拆分、临时支持没有记录、会议时间混在开发时间里，历史数据无法还原决策过程。

这类困境的根源是把工时当成项目结束后的汇总字段，而不是执行过程中的管理信号。工时数据只有和任务范围、优先级、状态、变更原因以及交付结果放在一起，才有机会帮助团队解释项目发生了什么。

2. 不同岗位的任务结构不同，统一模板不等于统一口径

一个产品经理的工作可能包括需求调研、方案撰写、原型评审、数据分析和跨部门协调；开发人员可能承担编码、联调、缺陷修复和技术治理；测试人员的工时又可能分布在用例设计、执行、回归和自动化维护上。所有人都使用同一张表并不一定有问题，但若任务分类强行一致，数据就可能掩盖岗位差异。

我更倾向于统一“记录规则”，而不是统一“工作名称”。例如统一要求每条记录关联任务、日期和实际时长，同时允许不同专业团队设置符合工作的任务类型。这样既有跨团队的共同口径，也保留了必要的业务细节。

3. 中大型组织的难点通常是协作边界，不只是填报界面

在 100 人以上的组织里，一个项目的工作可能横跨产品、研发、测试、设计、运维和业务部门。人员不一定都向同一位经理汇报，项目负责人也未必拥有资源调配权。此时，工时流程需要处理项目归属、团队归属、审批职责、跨项目投入和权限边界，单靠一张表格很难长期维持一致。

以 PingCode 这类面向中大型企业和 100 人以上组织的项目管理平台为例，适合关注的不只是工时字段是否存在，还包括任务和项目如何关联、角色权限如何区分、视图能否按项目或团队汇总，以及异常能否被负责人及时发现。具体功能应以实际部署版本和组织配置为准；平台提供能力，并不意味着口径和治理会自动建立。

4. 先区分管理目的，才能决定需要收集多少数据

若目的是掌握项目资源占用，项目和任务层级可能足够；若要做客户结算，需要明确可计费、不可计费和审批证据；若目的是改善估算，则要保留计划基线、实际投入、变更原因和交付结果。目标不同，数据字段就应不同。

我的判断原则是：每增加一个字段，都要能说清楚它将支持什么决策。如果没人会根据某字段采取行动，它多半只会增加填报成本。尤其要避免为了“以后可能有用”而一次性要求员工填写大量分类、说明和审批信息。

三、拆解常见误区：填得更多，不代表管理得更好

1. 误区一：填报率高，就说明工时数据可信

填报率只表示记录动作发生了，不代表记录准确。月底集中补填、把一整周平均分配到若干任务、复制上周记录，都可能让填报完整度变高，却降低数据可信度。管理者若只盯着“是否提交”，会不自觉地奖励形式合规，而忽略记录是否能反映实际工作。

更好的做法是同时看及时性、关联完整度和异常修正情况。例如，记录是否在工作发生后约定时间内完成，是否关联有效任务，是否出现大量相同整数时长，是否经常在截止日集中补录。单一指标很容易被优化，组合信号更接近真实状况。

2. 误区二：工时偏差等于个人表现差

估算少了、实际多了，不必然是执行者能力不足。需求范围、依赖系统、环境可用性、评审等待和缺陷返工都可能造成差异。反过来，实际工时低于计划也不必然代表效率优秀：可能是需求被删减、验收不充分，或者只记录了开发投入，遗漏了联调和支持。

我会先问“差异由什么事件造成”，再讨论“谁可以改变这个因素”。如果团队没有记录变更和等待原因，却把差异直接用于个人排名，那么员工的理性反应很可能是少报复杂工作、避免承接不确定任务，最终损害协作和数据质量。

3. 误区三：任务越细，数据越精确

任务拆得太粗，工作内容无法追溯；拆得过细，每天就会产生大量微任务和维护成本。精度不是任务数量的同义词。一个可操作的任务，应当有相对清楚的成果、负责人和可判断的完成状态，并且其工时规模足以被团队稳定估算。

实践中可先以半天至数天作为讨论起点，而不是硬性标准。团队若工作节奏短、依赖多，可以拆得更细；若任务高度探索、范围难以预知，应该记录阶段目标和实际投入，而非假装能精确预估每个小时。粒度要服从管理问题，而不是服从表格设计。

4. 误区四：会议和沟通属于“非工作”，可以不记

会议不是天然的浪费，也不是天然应该记入所有项目。若会议是项目评审、技术方案讨论或客户需求澄清，并且消耗了明确资源，团队可以依据目的把它归入项目任务或独立活动类型。若会议属于全组织例会，则未必应该摊到某个具体项目。

关键是规则一致。某个团队把讨论会计入项目，另一个团队完全不记；同样的跨团队支持，有人记在原项目，有人记在支持项目，最后的项目投入就不能直接比较。无法统一的活动可以单独分类，不必为了报表整齐而伪装成同类数据。

5. 误区五：工时表可以直接衡量个人产出

工时描述投入，不直接描述价值。一个高复杂度故障可能几小时解决，却避免了数天业务损失；一个重复性任务可能耗时很久，却没有形成可复用产出。把投入小时数当作绩效分数，会导致员工追求可记录的忙碌，而非有效交付。

如果组织确实需要评估交付效率，至少还要结合任务难度、质量、结果、返工、协作贡献和目标达成情况。即便形成综合判断，也应明确其局限，不应把一个表格里的数字包装成客观、完整的个人评价。

四、专业判断逻辑：先定口径，再定粒度，最后定审批

1. 明确计入范围：什么活动算工时

上线前应把计入规则写成简短、可执行的说明。至少回答：任务执行、需求讨论、项目会议、等待、返工、培训、休假和内部支持分别怎么记录；实际投入是按开始结束时间计算，还是按投入时长登记；跨午夜或跨多个项目时如何处理。

不必追求理论上无遗漏的分类树。分类越复杂，员工越难稳定使用，负责人也越难解释。优先区分会影响业务决策的活动，例如项目直接投入、客户支持、内部治理和非项目工作。暂时无法可靠分类的部分，可用少量“其他”类别承接，并定期检查其占比是否过高。

2. 选择统计单位：小时、人天和工作日不能混算

如果团队要看短周期任务，按小时记录通常更容易观察投入变化；如果目标是资源规划，人天可能更容易沟通。无论选择什么单位，都要写清换算规则。例如，一个工作日按多少有效小时计算，休息时间是否排除，兼职投入怎样表达。

我不建议把“工时”和“工作时长”混为一谈。员工当天工作 8 小时，不表示某一个项目获得了 8 小时投入；同一天可能同时处理多个项目、内部事务和支持请求。项目工时合计若长期明显超过组织可用工时，应先检查重复记录和跨项目口径，而不是解释成团队“产能超常”。

3. 任务粒度：用完成条件控制，而不是用固定条数控制

创建任务时，至少确保它有可识别的对象、负责人、预期结果和完成条件。比如“优化搜索”难以核验；“为商品列表增加按状态筛选，并通过指定验收用例”更便于估算和记录。任务名称本身不需要写成完整需求文档，但不能只有模糊动词。

当一项任务跨越多个阶段且各阶段可独立验收时，可以拆分；当拆分后每个子任务都没有独立结果，只会产生重复维护时，不必拆。对探索性工作，可以按调研阶段、验证阶段和决策产出记录，避免用虚假的精确估算掩盖不确定性。

4. 实际工时记录：保留发生时间和任务关联

基本记录建议包含人员、日期、任务、实际时长和简短说明。只有在管理目的需要时，再增加活动类型、可计费状态、审批人或原因代码。对于非日常任务，说明不必写成长篇日报，但可以记录关键事件，例如需求新增、依赖等待、环境故障或返工来源。

记录频率应和工作节奏匹配。每天登记适合任务切换频繁、成本核算要求较高的团队；每周汇总适合任务相对稳定、统计精度要求适中的团队；月底补记通常最省操作次数，却也最容易损失上下文。产品经理应把及时性要求设计成团队能坚持的规则，而非理想化口号。

5. 审核异常：审查可疑模式，不审判正常波动

工时审核的目标是发现数据问题和管理阻塞，不是要求每条记录都写出“令人满意”的解释。建议优先检查：未关联任务、任务已关闭仍持续记工时、同一时间段重复记录、单日总投入异常、计划大幅超出、工时与任务状态明显矛盾，以及某类工作长期被归入“其他”。

异常阈值应先试运行，再调整。若刚开始就把计划偏差 10% 设为强制审批条件，可能造成大量低价值流程；若完全没有阈值，真正的范围失控又可能没人关注。更可行的方式是先提示、再复核、最后对高风险情况升级处理，并记录处理结果。

五、具体案例和数据观察：用一个模拟项目走完流程

1. 案例背景：一个 12 周的企业功能迭代

下面使用一个情景模拟案例，用于展示计算和判断方式，不代表某个企业的真实运营统计。假设一个 8 人跨职能团队，用 12 周完成企业后台的权限与审计功能，角色包括产品、设计、开发、测试和项目协调。项目按每周计划投入 200 小时估算，总计划工时为 2,400 小时。

项目初期，团队把“权限改造”作为单一任务，计划工时 320 小时。执行中，产品补充了审计字段，旧系统又需要兼容；开发把部分投入记在“日常支持”，测试则把回归工时登记为单独任务。虽然每周都能收齐表格，项目负责人仍无法确定超出投入究竟来自需求变化、兼容成本还是记录口径不同。

2. 先建立基线：拆任务并记录估算依据

团队重新把范围分成权限模型梳理、后台配置页面、接口改造、审计字段、兼容处理、测试回归和发布验证七个可核验部分。计划工时并非一次性“拍一个总数”，而是由相关岗位分别估算，再由项目负责人记录依赖和假设。

例如，接口改造计划 240 小时，假设旧系统文档完整、联调环境可用；兼容处理计划 120 小时，假设历史数据不需要批量修复。保留这些假设很重要，因为最终偏差可能来自假设失效，而不是估算人员计算错误。

3. 按周观察差异，不等到月底才追原因

假设前四周计划投入分别为 200、200、200、200 小时，实际投入为 188、216、235、224 小时。单看第一周，团队似乎低于计划；到第四周累计计划 800 小时，实际已达 863 小时，累计超出 63 小时，约为 7.9%。

这时不宜马上要求个人解释“为什么效率下降”。应先查看任务级差异：增加的审计字段是否经过范围确认，兼容问题是否形成缺陷记录，测试回归是否重复执行，是否存在未归类支持。按事件核对后，团队才可能判断这 63 小时应归为范围增加、技术债处理、估算偏差还是数据错误。

4. 计算时要统一公式和口径

最基础的计划偏差率可以这样计算：计划偏差率＝（实际工时－计划工时）÷计划工时×100%。当计划工时为 800 小时、实际工时为 863 小时，偏差率就是约 7.9%。这个数字只说明相对差值，不说明差异原因，也不能单独用于判断项目是否失败。

如果任务范围中途改变，应保留原计划基线，并记录经批准的调整版本。把原计划直接覆盖成最新计划，会让历史偏差消失，团队也就无法复盘原先的估算是否合理。若采用范围调整后的新基线，报表应同时区分原始基线、批准变更和当前预测。

5. 通过案例看管理动作，而不是只看最终总数

假设团队复核后发现，63 小时差异中，24 小时来自新增审计字段，18 小时来自兼容问题，11 小时来自测试重复回归，另有 10 小时是支持工作未及时归类。前三类分别需要范围调整、技术风险处理和测试流程改进；最后一类主要是记录规则问题。

若只看到项目多用了 63 小时，管理者可能会要求团队“下次估准一点”。但拆开之后，解决方法至少有四种：产品明确变更审批、研发提前验证兼容风险、测试维护稳定的回归集合、项目管理明确支持工时归属。总数相同，原因不同，行动就应该不同。

6. 数据观察的边界：模拟数字不能冒充行业基准

上面的项目数据只是为了说明流程，不能推导“团队正常偏差应为 7.9%”，也不能据此宣称某种工具能让工时减少固定比例。不同任务的复杂度、团队经验、需求稳定性和统计定义都不同，跨企业对比容易产生假精确。

在真实团队里，我会先建立连续数个迭代周期的内部基线，按任务类型和项目阶段观察中位数、分布和变化原因。比起追求一条看起来漂亮的行业均值，更值得关注的是同类任务的估算误差是否逐步收敛、等待时间是否减少、反复返工是否下降。

六、不同情况下的行动建议：先解决最影响决策的那一个问题

1. 小团队、项目少、没有专职项目管理人员

小团队可以从最小记录集开始：日期、人员、任务、实际时长和简短备注。每周安排一次 15 至 30 分钟的任务复盘，集中处理漏填、任务范围变化和明显偏差。不要一开始就引入多级审批和大量分类，否则团队可能把精力花在维护流程，而不是交付。

若暂时使用表格，建议每条记录一行，采用统一任务编号或链接，限制日期和时长格式，并避免每个人维护自己的字段版本。表格不是天然低效，真正的问题是多人复制多个版本、公式被覆盖、历史记录被删除，以及任务关联无法持续维护。

2. 多项目并行、资源频繁冲突的中大型组织

当团队同时参与多个项目，优先建立项目归属规则和跨项目投入视图。需要明确员工在什么情况下可以登记到其他团队任务，谁负责处理项目间争议，以及支持性工作由原团队还是受益项目承担。没有这些规则，单个团队的数据再准确，也可能在组织汇总时相互矛盾。

采用 PingCode 等项目管理平台时，可以优先验证任务、项目、角色权限、工时记录和报表之间的关系是否满足组织流程，再决定是否扩大应用范围。建议用一个代表性项目做试点，覆盖跨团队协作、审批和异常处理，不要只演示最简单的“填写小时数”。需要特别核对现有平台配置与企业实际流程是否匹配。

3. 需要客户结算或项目成本核算的组织

若工时会影响合同结算，记录规则应比内部资源管理更严格。除任务和投入时长外，还需要明确可计费状态、计费单位、审批责任、客户项目归属、修订留痕和证据保存期限。必须把“投入发生过”和“投入可以收费”分开；并非所有项目工作都能向客户计费。

还应提前定义更正流程。员工补录或修改历史记录时，系统或流程需要保留修改时间、修改人和原因。否则报表数字虽然更新了，组织却无法说明何时、为什么改变。财务、项目负责人和交付团队应共同确认口径，而不是由某一部门单方面规定。

4. 任务高度不确定、探索性较强的产品工作

对新方向验证、用户研究和技术预研，过早要求精确到小时级的计划，往往只是在把不确定性转移到表格里。更适合的方法是按探索阶段设时间盒，先估算投入上限，再记录实际投入和阶段结论。例如先投入一周验证核心假设，到期根据证据决定继续、调整或停止。

这类工作仍然可以记录工时，但决策重点应是每一阶段获得了什么证据、消除了哪些风险，而不是要求实际投入完全贴合最初计划。若试验过程改变了问题定义，必须保留这一变化，否则最终数据会误导管理者以为计划失准只是因为个人执行不力。

5. 已经收集数据，但没人使用报表

这种情况不应先增加填报要求。先检查报表是否对应明确会议和决策：谁在什么时候查看，看到异常后能做什么，结果如何反馈给团队。如果没有固定的资源评审、项目复盘或成本核算场景，数据很容易成为无人维护的仓库。

我通常建议挑出一到两个高价值视图，例如项目计划与实际投入差异、团队跨项目负载、超期任务投入变化。每个视图都要写清负责人和使用频率。报表数量不宜成为成功指标；能够稳定推动一个资源决策或流程改进，往往比生成十张没人看的图更有价值。

七、不同情况下的取舍：记录精度、流程成本和信任之间要平衡

1. 日填还是周填：精度与维护成本的取舍

日填的优点是离事件近，任务切换和异常原因容易回忆；缺点是操作频率高，若界面繁琐，会让员工把记录当作额外工作。周填减轻操作次数，适合工作稳定的团队，但需要提供每周回顾机制，避免把大量时间花在月末补记。

我的建议不是只选一个全公司标准，而是先给出统一的最迟记录时限，再根据岗位和业务要求配置频率。客户结算、事故响应或任务切换频繁的团队可更及时；长期研究和阶段性交付团队可以按周归集。任何例外都应说明原因，不能让各团队在没有共同边界的情况下自行解释。

2. 细分类还是少分类：解释能力与填报摩擦的取舍

细分类可以帮助区分开发、评审、支持、返工和会议，但类别一多，员工更难选，管理者也可能把有限样本拆成许多不可比较的小组。少分类更容易执行，却可能掩盖真正的成本结构。

较稳妥的做法是从最小必要分类开始，观察“其他”是否长期占比过高、是否有稳定的重复活动被埋在其中。只有当新分类能支持具体决策时再增加，并明确旧数据如何兼容。不要因为报表想要更多颜色，就要求员工承担没有管理价值的分类工作。

3. 强制审批还是事后抽查：控制风险与响应速度的取舍

强制审批适合外部收费、预算约束严格或合规要求明确的场景，能提高记录的责任意识，但可能增加等待，尤其是审批人多、阈值过敏感时。事后抽查更轻量，适合以资源观察和估算改进为主的内部项目，但需要稳定的数据质量检查和处理责任。

可以把两种机制组合起来：常规工时快速提交，对高风险或超过阈值的记录触发复核；抽查发现的系统性问题，再通过规则或培训解决。不要用审批掩盖模糊的口径。审批人不知道如何判断某项记录时，流程只会把“填得像真的”变成通行证。

4. 个人可见还是团队可见：透明度与误读风险的取舍

团队共享项目投入，有助于发现资源冲突和任务拥堵；但若直接展示个人小时排名，容易诱发防御性填报。员工可能避免记录帮助同事的时间，或倾向选择容易量化的工作，形成“数字可见、贡献不可见”的偏差。

因此，访问权限应与用途一致。项目成员需要看任务级协作信息，项目负责人需要看资源和偏差，部门管理者可能看汇总趋势；并非所有人都需要查看所有人的逐条记录。涉及绩效使用时，应公开指标解释、数据范围和申诉机制，避免把工时数据作为脱离上下文的自动评分依据。

5. 表格、项目管理平台还是专门的工时系统：灵活性与治理能力的取舍

表格启动快、调整灵活，适合小范围试运行；当项目、人员和审批关系增加后，容易出现版本分裂、任务关联失效和公式维护风险。项目管理平台适合把任务、状态和投入放在相近的工作流里，但需要检查权限、导出、历史追溯和报表能力是否满足要求。

专门的工时或工时成本系统可能更适合复杂结算、合规审计和跨业务核算，但部署和集成成本更高。选型不能只看功能清单，应实际演练一个完整流程：创建任务、计划工时、日常记录、超额处理、修改留痕、跨项目汇总和导出核对。任何一步需要长期人工拼接，都应纳入总拥有成本。

八、落地检查清单：让流程先跑通，再逐步提高精度

1. 上线前：确认目标、范围和责任人

• 写明工时数据将支持哪些决策，例如资源协调、估算复盘或客户结算。
• 确认哪些活动需要记录，哪些活动不纳入项目工时，跨项目工作如何归属。
• 统一小时或人天的定义，明确有效工作日换算和时区、休假等特殊情况。
• 定义任务最低信息要求，确保任务有负责人、预期结果和完成条件。
• 明确员工、任务负责人、项目负责人和财务等角色分别负责什么。
• 选定试点范围，优先覆盖真实协作和异常场景，不只测试理想流程。

2. 运行中：把问题放在工作发生时处理

• 按约定频率记录工时，尽可能减少长期积压和月底集中补填。
• 通过任务变更记录保留计划调整，不直接覆盖原始估算基线。
• 定期检查无任务关联、重复记录、异常总时长和已关闭任务仍有投入等情况。
• 对超计划投入先识别原因，再决定是否调整范围、资源、日期或估算。
• 把表单中的模糊类别和重复填写项记录下来，按实际使用情况迭代。
• 对修改过的记录保留修改人、时间和原因，尤其是涉及结算的场景。

3. 复盘时：看趋势和原因，不只看总量

项目复盘至少应回答：计划基线和实际投入相差多少，差异主要来自哪些任务和事件，哪些假设被事实推翻，哪些工作没有被合理归类，哪些环节可以提前识别风险。结论应落到可执行改进，例如调整同类任务估算、补充技术验证步骤或减少重复回归，而不是停留在“下次注意”。

团队成熟度还可以从记录到行动的链路观察：数据是否及时、任务是否可追溯、偏差是否能归因、复盘是否产生改进、改进是否影响下一轮计划。若只有前两项，系统可能只是记录工具；若后面几项也持续发生，工时数据才逐渐成为管理能力的一部分。

4. 常用指标：少而稳定，避免把指标变成目标

这些指标的目标不是设定漂亮的统一红线，而是建立本组织的可解释基线。初期先观察趋势，再结合团队工作方式判断是否需要阈值。若指标开始影响员工行为，应检查它是否诱发少报、拆单、改类或追求表面合规等副作用。

九、结论：工时表不是计时器，而是项目认知系统的一部分

1. 用投入解释项目，不要用投入替代项目

工时数据的真正价值，不是给每个人贴上“快”或“慢”的标签，而是让团队知道资源花在哪里、计划为什么变化、哪些风险可以提前发现。它必须与任务结果、范围变更、质量和依赖关系一起理解，不能脱离项目上下文独立判定。

我更愿意把工时表看作一种“项目认知系统”：它把原本散落在聊天、会议和个人记忆里的投入，转化成能讨论、能校正、能复盘的证据。但证据并不等于真相，记录越精细，也不自动意味着管理判断越正确。

2. 下一步从一个小闭环开始

如果团队还没有稳定流程，下一步可以选一个正在进行的项目，先统一五件事：记录目的、计入范围、任务粒度、填报频率和异常处理方式。运行一个迭代后，复盘哪些字段真正帮助了决策，哪些字段只增加了负担，再决定是否扩大范围。

如果已经有平台和报表，下一步则不是继续加指标，而是抽查一组任务，从计划、实际记录、范围变更、审批到复盘完整走一遍。一条可以解释、可以追溯、可以促成改进的工时记录，比一百条没人知道该如何使用的数据更有价值。