Timesheet怎么做？企业管理者最佳实践：工时表从0到1

Timesheet 怎么做，难点通常不在“让员工填表”，而在于让填报数据同时满足三件事：员工填得动、经理看得懂、财务或管理层用得上。我的建议是先别急着选表格或系统，也不要先设计几十个字段；先明确工时数据要支持什么决策，再从最小可用的记录规则开始，经过试运行、校准和复盘，逐步把工时表从 0 做到 1。否则，企业很容易得到一份看似完整、实际无法解释项目成本和团队负荷的表。

一、先讲核心结论：工时表不是考勤表，而是管理决策的输入

1. 先回答“为什么记”，再回答“怎么记”

我判断一套工时管理是否值得上线，第一步不是看字段齐不齐，而是问管理者准备拿数据做什么。如果答案只是“想知道大家每天忙不忙”，工时表很可能变成一种低信任度的监控工具；如果答案是“要核算项目投入、识别超负荷、改善排期或支持客户结算”，才有明确的记录对象、使用者和行动方式。

工时表通常服务于四类决策：项目成本与预算、团队容量与排期、客户或合同结算、流程效率与投入结构。它们看起来都需要“记录时间”，但字段、精度和审核方式并不相同。把四种用途混成一个目标，往往会得到一张谁都能填、谁也不敢用的表。

• 项目核算：需要知道时间落在哪个项目、阶段、任务或成本中心。
• 团队排期：需要汇总角色和人员的可用容量，判断未来工作是否超载。
• 客户结算：需要符合合同约定的计费单位、审批规则和可追溯记录。
• 流程改进：需要识别等待、返工、会议和支持工作的投入，不是只看任务完成时间。

2. 我推荐从“管理问题，数据字段，动作”反向设计

一条工时记录只有能触发合理动作，才有管理价值。比如，项目经理发现某阶段实际投入持续超过预算，应有权限调整范围、排期或资源；如果发现数据后没有任何人能改变计划，收集数据只是增加员工负担。

可以用一句话检查字段是否必要：这个字段缺失，会让哪一个明确决策无法做出？如果回答不出来，就先不采集。尤其是“工作状态”“紧急程度”“详细说明”等字段，不要因为系统能配置就全部加上。

3. 先把“记录”与“评价个人”分开

工时是投入记录，不是绩效结论。某员工记录了更多小时，不等于贡献更大；某任务花费时间更短，也不等于效率更高。工作的复杂度、上下游等待、临时支持、质量要求和经验差异都会影响时长。

如果团队担心工时数据被直接用于排名、扣分或证明“谁最忙”，填报质量会迅速下降。员工可能把零碎时间凑整、把不确定工作填到容易通过的任务，甚至避免登记协作与支持工作。工时系统的可信度，取决于管理者如何使用数据，而不只取决于系统如何采集数据。

二、背景和真实场景：企业为什么会突然需要工时表

1. 从“项目做完了”到“为什么超了”

我见过的常见触发点，不是管理者忽然想看员工每天做了什么，而是一个具体问题无法回答：项目延期后，团队说人手不足；财务说预算已经用完；客户认为需求没有变；负责人却说做了大量额外工作。此时争议并不只是“花了多少小时”，而是哪些投入对应原定范围，哪些来自变更、返工、等待或临时支持。

如果企业没有统一的项目、任务和工作类型口径，事后补填经常只能得到一个总数。总数可能有用，但很难解释原因。例如某项目累计投入 1,200 小时，并不能说明是需求增加、技术风险、测试返工、跨团队等待，还是工时分类方式不同造成的。

2. 从“大家都很忙”到“容量到底去哪了”

在 100 人以上的组织，管理者面对的通常不是一个团队，而是多项目、多角色、多层级的资源冲突。研发团队可能同时承接产品迭代、客户交付、线上故障和内部平台建设。每一项工作单独看都合理，合在一起却可能超过团队容量。

工时数据能帮助解释实际投入结构，但不能代替未来排期。历史上某个团队投入 70% 时间在客户项目，不意味着下个月还能按同样比例承诺；休假、值班、培训、岗位空缺和新任务都会改变容量。用历史工时做资源预测时，必须同时看未来承诺和可用时间。

3. 从“一个表格管所有人”到“分场景治理”

同一家公司可能同时存在研发、咨询交付、客户成功、市场活动和职能支持等工作。研发人员按任务记录，咨询顾问按客户与服务阶段记录，职能团队则可能更适合按工作类别或内部项目汇总。强行让所有人按相同粒度填报，通常会让部分团队负担过重，另一部分团队数据失真。

我会先划分工时场景，再确定统一字段和差异字段。统一部分包括日期、人员、时长、归属对象和状态；差异部分可以是客户、合同、工作类型、成本中心或任务层级。这样既能横向汇总，又不必把各类工作硬塞进同一种业务模型。

4. 组织规模越大，越需要先统一口径而不是统一细节

对中大型组织来说，统一口径通常比统一每个团队的操作细节更重要。比如，大家都理解“实际投入小时”是什么意思，哪些时间算会议、哪些算等待、哪些要归入项目；至于某团队每天填、某团队每周填，可以在共同规则下保留差异。

以 PingCode 这类面向中大型企业及 100 人以上组织的项目管理平台为例，工时设计可以围绕项目、工作项、人员和时间记录建立关联，再通过权限、流程和报表支持不同角色查看。关键不在于“功能多不多”，而在于组织是否已经确定对象层级、审批责任和数据使用边界。平台不能替企业决定管理口径。

三、拆解常见误区：填报率高，不代表工时表有效

1. 误区一：把工时表做成详细日报

有些管理者要求员工按 15 分钟为单位登记每项工作，还要写长篇说明。这个设计看起来精确，实际往往把员工注意力从工作转到记账。高频切换的人尤其难以准确回忆每个短时活动，记录越细，事后补录的估计成分越高。

精度应与决策需要匹配。若项目按人天估算，精确到 5 分钟未必能改善预算判断；若客户按实际服务时长结算，确实可能需要更细粒度，但仍要遵守合同约定并控制记录成本。看似更精细的数据，不一定更准确；它可能只是更精细地记录了误差。

2. 误区二：只要求员工填，却不给负责人复核责任

员工填写只是数据产生环节，不等于数据治理完成。一个人可能选错项目、漏记支持工作、把任务时间填在所属迭代而不是实际日期。若没有负责人定期复核，这些误差会进入月报，最终让团队围绕错误数字做决定。

审核也不应变成逐条盘问员工。更有效的做法是检查异常：缺失日期、单日时长异常、项目归属不明、超出预算、重复记录、审批逾期。异常触发复核，正常记录低干扰通过，既保护管理质量，也减少无意义的审批工作。

3. 误区三：把填满标准工时当作目标

若规则要求每个人每天必须填满 8 小时，系统就可能把请假、培训、等待和临时支持挤进项目任务里。表面上工时完整，实际上企业看不到容量损失来自哪里。标准工时是容量规划参考，不应被误用为要求每小时都能归属某个交付任务。

我建议明确非项目时间的处理方式。根据组织需要，可以设置休假、培训、内部会议、值班、招聘、行政支持等类别；不需要细分时，也可以用少量汇总类别。重点不是把所有空档都追踪到分钟，而是避免把非项目投入伪装成项目成本。

4. 误区四：用工时总量直接比较员工效率

总工时既不是产出，也不是价值。同样 40 小时，有人完成了高风险技术迁移，有人处理了大量线上支持，有人承担跨团队协调。若没有产出、质量、工作复杂度和上下游条件，单看时长排名很容易惩罚承担困难工作的员工。

可以分析投入与结果之间的关系，但要先做合理分层：同类型任务、相近复杂度、相似团队条件，再观察工时偏差、交付质量和返工率。若样本量小、任务类型不同，结论应写成待验证假设，而不是个人绩效定论。

5. 误区五：上线系统就等于完成变革

系统能减少重复录入、关联任务和汇总报表，但无法自动解决“项目叫什么”“什么算可计费工时”“谁能改记录”“争议由谁裁决”等问题。口径没定，系统只是把旧的不一致搬到了新界面。

在引入项目管理平台之前，我会先用一页规则说明和小范围试点验证流程。如果员工需要在多个系统重复输入、项目负责人不知道怎样审批、财务拿到数据仍要手工清洗，那么即使功能齐全，也不适合立即全员推广。

四、专业判断逻辑：从 0 到 1 设计一套能用的工时规则

1. 第一步：明确数据使用边界

正式设计表单前，我会让管理层写清楚：谁能看个人明细、谁只能看团队汇总、哪些数据用于项目核算、是否用于客户计费、是否用于绩效评估、员工如何查询和更正记录。权限边界不清，员工就会把每个字段都理解为潜在考核证据。

如果组织决定工时不直接用于个人绩效，应明确写进规则并落实到报表权限；如果某类工时要支持客户结算，也要说明审批、修改留痕和争议处理方式。所谓透明，不是所有人看所有人的明细，而是每个人清楚数据会如何被使用。

2. 第二步：确定工时的计量单位和填报节奏

计量单位要根据用途选择。内部项目管理通常可以按 0.5 小时、1 小时或半天记录；客户计费则以合同约定为准；对无法可靠拆分的管理类工作，按周汇总可能比逐日回忆更诚实。不要默认越细越好，先用试点确认员工能否稳定执行。

填报节奏也应考虑记忆误差和工作负担。每天登记适合工作切换多、账单追溯要求高的团队；每周提交适合任务较稳定、以项目复盘为主的团队；月末集中补录通常是风险最高的方式，因为时间越久，记录越依赖回忆。

3. 第三步：搭建最小字段集

一个起步版本可以只保留：记录日期、人员、所属项目或成本中心、任务或工作类型、投入时长、说明（必要时）、提交状态。不要一开始就加入十几个必填字段。每新增一个必填项，都应说明它是否支持明确的汇总或审批需求。

4. 第四步：定义归属规则和边界情形

常见争议通常来自边界，而不是正常任务。一个人参加跨项目会议，工时应归到各项目还是统一会议类别？处理线上故障时，算产品项目、运维成本中心还是客户支持？等待外部反馈算不算投入？这些问题必须在试点之前列出来，至少给出默认归属规则。

如果工作同时服务多个项目，不要要求员工凭感觉将一小时拆成三份。可以按会议议程分摊、归入共享支持类别，或由团队负责人按明确规则决定。选择哪种方式取决于核算目的，但要确保同类工作在不同团队之间能够一致解释。

5. 第五步：建立轻量审核和纠错机制

我建议将审核重点放在异常，而非逐条审批。负责人每周或每月查看缺失、超预算、日期不合理、归属不明和未提交记录；员工能在一定时间内自行更正；修改后保留变更记录。这样既不把管理者变成数据录入员，也保留必要的可追溯性。

异常阈值不要照搬固定数字。例如单日记录超过 12 小时可能需要确认，但有值班或跨时区工作的团队需要不同规则。阈值应是提醒线，不是自动认定违规的证据。判断还要结合工作安排、休假、时区和特殊事件。

6. 第六步：把指标拆成“质量、投入、结果”三层

我不会只看总工时，而会分三层观察。第一层是数据质量：按时提交率、缺失率、修改率；第二层是投入结构：项目、工作类型、阶段和角色的时间分布；第三层是结果关联：预算偏差、交付周期、返工、服务水平或客户结算差异。

只有第一层，管理者知道表填得怎么样，却不知道经营状况；只有第二层，能看见钱和时间去哪儿，却未必知道效果；把三层连起来，才有机会判断投入是否合理。需要注意的是，数据关联不自动证明因果，发现某类任务工时升高后，还要核实范围、复杂度和资源变化。

五、案例与数据观察：用一个模拟试点看出工时表真正的价值

1. 案例设定：一个跨项目的 120 人产品与交付组织

下面是一个用于说明设计方法的模拟案例，不是对特定企业的真实业绩承诺。假设某组织有 120 名员工，其中研发、测试、产品和交付人员共同参与多个项目。管理层发现两类问题：部分项目常常在中后期超出原预算；团队负责人也无法判断超额投入来自需求变更、线上支持还是返工。

原有做法是月末由员工回忆填写项目小时数，再由行政人员汇总。管理层能看到项目总投入，却看不到投入对应的任务和工作类型。对账时，项目经理和财务经常需要反复询问；团队也不愿意把临时支持单独列出来，因为没有统一类别。

2. 试点不先追求全面，而是选择三个有代表性的团队

我会选择一个研发团队、一个客户交付团队和一个共享支持团队做试点。三类团队分别检验任务级记录、合同相关记录和碎片化工作分类。试点周期可以设为四至六周，重点不是在短期内证明绩效提升，而是验证字段是否可填、归属规则是否可执行、报表是否回答了原来的管理问题。

试点开始前，为每个团队明确一个负责人、一位数据口径联系人和一条纠错通道。员工要能看到自己提交的记录，负责人要知道何时复核，管理层要同意不将试点数据直接用于个人排名。若这三项缺一，试点得到的可能是形式上的填报，而不是可用的数据。

3. 四周观察什么：不要把填报率当唯一成功指标

假设试点记录显示，按时提交率从第一周的 68% 上升到第四周的 91%，看起来有所改善。但更重要的是，同时观察每周补录比例、记录修改率、无法归类的工作时长、审批平均耗时和项目预算偏差的解释率。

举例来说，如果按时提交率上升，但月底补录比例仍高，说明团队可能只是按时提交了估算值；如果无法归类的工时下降，可能意味着分类目录更贴合实际；如果审批耗时增加，则需要检查责任链或审批规则，而不是继续要求员工更快提交。

4. 真正的收益可能不是少填几张表，而是更早发现偏差

在这个模拟案例中，最值得追踪的不是“每个人少花了多少时间填表”，而是项目超预算能否从月末才被发现，提前到阶段复盘时识别。若项目连续两周投入高于计划，负责人可以检查需求变更、技术风险或返工，而不是等到预算耗尽再追问。

因此，企业可以把“偏差发现提前量”作为内部观察指标：从某项投入首次偏离计划，到负责人确认原因并采取动作，间隔了多少天。这个指标更接近管理价值，但必须记录触发规则和复核过程，不能把示意数据当成通用行业基准。

5. 分析偏差时，先解释业务，再判断流程

假设一个项目的投入比计划高 20%，不要立即得出“团队效率低”的结论。先检查需求范围是否变化、关键成员是否被调去支持其他项目、技术方案是否存在未知风险、缺陷返工是否集中在某个阶段，以及工时归属是否发生了口径变化。

如果新增需求占用了大量时间，管理动作可能是调整合同范围或计划；如果线上支持造成项目投入被挤占，可能要单列支持类别并重新估算团队容量；如果同类返工持续出现，可能需要改进需求评审或测试策略。工时表最有价值的地方，是让偏差可解释，而不是让偏差看起来可以被归罪。

六、不同情况下怎么行动：按组织成熟度选择起步路线

1. 小团队、项目少：用轻量规则先跑起来

如果团队规模较小、项目数量有限、主要诉求是回顾投入，电子表格或现有协作工具可能已经足够。先固定项目目录、日期、时长和工作类型，约定每周提交一次，由负责人抽查异常。短期内不必上复杂审批，也不用把所有工作拆到最低层级。

当项目数增加、汇总清洗变成重复劳动、多人需要同时维护口径时，再考虑工具化。判断升级时机不应只看员工人数，还要看数据关联复杂度、审计要求和报表频率。一个 30 人但合同结算复杂的团队，可能比 100 人但工作类型单一的团队更早需要系统支持。

2. 中大型、多项目组织：先治理项目目录和权限

对于 100 人以上、多个部门共享资源的组织，最大风险通常不是少一个报表，而是项目命名不一、人员归属不一致、记录权限混乱和口径各自解释。上线前应先设定项目目录负责人、归档规则、成本中心映射和访问权限，再决定各团队如何提交。

PingCode 可作为这类项目管理平台的例子：当工时记录能关联项目或工作项，并按组织角色展示数据时，管理者可以减少在多个表格之间反复对账。选型时应验证实际流程能否覆盖工时填写、审核、修改留痕、项目归属和报表权限，而不是只看功能列表或演示环境中的理想路径。

平台部署还应考虑数据迁移、账号权限、历史项目清理、系统集成和员工培训。特别要测试离职人员记录、已关闭项目、跨部门任务和临时支持等边界情形。若这些情况仍靠线下表格补充，系统就没有真正形成统一数据链路。

3. 需要客户结算：把合同口径放在内部便利之前

客户计费场景中，工时字段、四舍五入规则、最小计费单位、审批人与可追溯说明必须以合同和企业财务规则为准。内部报表可以另行保留非计费时间，但不能将计费规则和内部效率分析混为一谈。

建议至少把记录分成可计费、不可计费、待确认三类，并建立修改留痕。对于需要客户确认的服务工时，应把签收或审批凭证与记录关联。任何“为了方便”而修改原始工时的做法，都可能造成账单争议和审计风险。

4. 主要目标是容量规划：记录历史，也要管理未来

若重点是资源协调，工时表只能说明过去做了什么，不能单独说明未来还能接多少工作。还需要结合人员可用工时、休假、值班安排、技能匹配、已承诺任务和不确定性缓冲。历史平均投入可用于校准估算，但不应直接当作下期容量。

一个实用的做法是每月对比“计划容量、已承诺容量、实际投入”，并在团队层面讨论差额。若实际投入中包含大量支持、会议或中断，未来排期就要预留相应容量。不同团队的可交付比例不同，不宜用单一利用率目标横向排名。

5. 数据质量较差：先减字段、改规则，不要先加考核

如果大量员工延迟提交、项目归属错误或说明内容重复，第一反应不应是加重处罚。先检查项目目录是否难选、字段是否过多、提交入口是否分散、任务是否及时更新，以及管理者是否给出稳定的归属规则。

可以针对异常类型分开处理：缺失多，改善提醒和提交节奏；归属错误多，治理目录和名称；时长不可信，缩短补录周期并明确计量单位；员工不愿填，公开数据边界并减少无用字段。数据质量问题通常是流程信号，不只是员工态度问题。

七、不同情况下的取舍：精度、负担、透明度与控制力

1. 记录越细，分析越丰富，但员工负担也越大

细粒度记录可以更好地解释项目阶段和客户服务内容，但同时增加切换、分类和补录成本。粗粒度记录更容易坚持，却可能无法区分返工、会议和支持。取舍的标准应是：新增信息能否改变决策？如果细分后的数据不会改变排期、定价或流程改进，就不必要求员工付出额外成本。

对于频繁切换的团队，可以按任务类别做有限归并；对于计费和审计要求严格的团队，可以保留更细的记录，并为填报时间设置合理预算。企业可以先试行，再比较记录耗时、分类稳定性和决策收益，而不是凭管理者直觉一次定终身。

2. 实时填报更接近现场，周度汇总更低干扰

实时填报能减少回忆误差，但会打断工作流，尤其不适合短任务多、临时协作频繁的团队。周度汇总更容易执行，却要求员工有清晰的任务记录和较稳定的记忆辅助。月末一次补录通常不适合作为常态，因为它把大量工作交给回忆和猜测。

折中方法是允许员工在工作过程中用任务状态、日历或工单留下轻量痕迹，周末统一确认工时；特殊客户服务或需要精确计费的工作，则尽量当天记录。这样将“现场追踪”和“最终确认”分开，既兼顾准确性，也减少频繁操作。

3. 统一规则与团队自主之间，需要有明确边界

完全统一可以提升横向可比性，但可能不符合不同团队的业务节奏；完全自主则会让数据无法合并。比较稳妥的做法是统一核心定义、项目标识、日期口径和总时长规则，让团队自行选择适合的填报频率和必要的业务分类。

组织应明确哪些规则不可改，哪些可以按团队调整。例如“实际发生日期”通常应统一；“会议是否细分为客户会与内部会”可以根据分析需求决定。变更口径时要记录生效日期，避免把旧数据和新数据直接横向比较。

4. 透明有助于信任，过度开放可能泄露业务信息

员工应能查看和更正自己的记录，负责人应能看到团队所需信息，项目或财务角色应获得与职责相符的汇总。将所有人的详细工时公开给全公司，既不一定提高透明度，也可能暴露客户信息、项目计划或个人工作安排。

企业应按角色设置访问范围，并保留查看、修改和导出的必要记录。若存在敏感客户或受监管业务，项目名称和说明字段还要避免收集不必要的个人或商业敏感信息。数据治理不只是报表权限，也包括采集最小化和保存期限。

5. 自动化减少重复劳动，但不能替代解释责任

自动关联任务、日历或工单可以降低重复输入，但自动化也会带来新的误差。例如日历事件并不代表实际投入，任务状态变化也不等于工作时长。自动生成的记录应能由员工确认和更正，不能把推测值直接作为结算或绩效依据。

系统要解决的是重复操作、汇总清洗和权限追溯，而管理者仍需判断异常是否有业务原因。自动化越多，越要明确数据来源、生成逻辑和人工修订方式。否则，错误数据只会更快、更大规模地传播。

八、落地检查清单：用 30 天完成从试点到复盘

1. 第 1 周：确认目标、范围和负责人

先选一个具体管理问题作为试点目标，例如解释项目投入偏差、减少月底人工汇总，或提升客户服务记录的可追溯性。明确试点团队、数据查看权限、负责复核的人和员工更正方式，不要同时启动多个互不相关的目标。

• 写出工时数据的用途和明确不用于什么。
• 确认项目、任务、客户或成本中心的命名规则。
• 指定业务负责人、数据口径联系人和流程支持人。
• 选定填报频率、计量单位和边界工作处理规则。

2. 第 2 周：配置最小流程并用边界案例演练

配置最少字段，先用真实但低风险的工作记录测试。演练跨项目会议、线上故障、临时支持、休假、工作中断、项目关闭和记录更正等情况。测试的目的不是证明页面能打开，而是确认不同人面对同一情形会作出一致选择。

若同一条记录被不同负责人归到不同项目，说明口径还没有成熟；若员工需要重复进入多个页面才能完成提交，说明流程可能需要简化；若报表上的项目名称无法与预算表对应，则要先治理目录和映射关系。

3. 第 3 周：收集反馈，检查数据质量和操作成本

试运行期间，每周查看按时提交率、补录比例、字段缺失率、归属错误率和审批耗时。也要询问员工完成一周填报大约需要多少时间，哪些字段最难判断，哪些工作类型经常没有合适选项。问卷之外，抽查实际记录更能发现分类问题。

数据质量指标应帮助定位流程，不宜一开始就变成惩罚标准。比如某团队补录比例偏高，先检查工作节奏和提醒设置；某类记录经常被退回，可能是规则不清或项目目录重复。先纠正系统性原因，再要求个人改善。

4. 第 4 周：复盘决策价值，决定扩大、调整或暂停

月底复盘时，回答三件事：数据是否能解释原先的问题？填报和管理成本是否可接受？负责人是否根据数据采取了行动？如果只能回答前两项，仍需检查工时表是否形成闭环；如果数据无法支撑原来的决策，应调整字段、粒度或试点目标。

扩大推广不一定意味着所有部门马上采用同一流程。可以先推广核心规则，再按团队类型建立模板；也可以保留一段并行期，核对新旧报表的一致性。只有当数据口径、培训材料、权限和异常处理机制稳定后，再逐步停用旧表。

5. 上线前最终核对的九个问题

• 我们要用工时数据解决的具体问题是什么？
• 每个必填字段是否都对应一种明确用途？
• 员工能否查看并更正自己的记录？
• 工时数据是否会被直接用于个人排名或惩罚？
• 跨项目会议、临时支持、返工和等待如何归属？
• 补录、审批、修改和项目关闭之后如何处理？
• 报表中的项目与预算、合同或成本中心是否一致？
• 异常由谁复核，复核后能采取什么管理动作？
• 试点结束后，如何判断扩大、调整或停止？

九、总结：先建立可信的记录，再追求更复杂的分析

1. 工时表从 0 到 1，关键不是把时间填满

我对工时表的核心判断是：企业不是缺少一个填报入口，而是缺少一套能把投入、业务归属和管理行动连起来的规则。若数据没有明确用途，员工就会把它当作额外劳动；若管理者不承担复核和行动责任，组织就会把记录误认为管理。

因此，起步时先选一个真实问题，定义最小字段集，试点验证记录成本和数据质量；之后再逐步增加审批、报表和系统集成。不要用“字段更多、粒度更细、填得更满”衡量成熟度，应该看数据是否更及时、更可解释，是否让团队更早发现偏差。

2. 下一步：今天就写下三句话

如果你正在从零搭建工时表，我建议先不要打开表格或配置系统，而是先与项目负责人、财务和一线员工共同写下三句话：我们记录工时是为了什么；哪些时间归到哪里；发现异常后由谁采取什么动作。三句话能说清楚，再用一个团队试跑四周。

工时管理做得好，不是让管理者更容易盯住每个人，而是让投入的去向更清楚、项目偏差更早暴露、资源调整更有依据。先建立可信度，再追求精度；先闭合决策链，再扩大采集范围。这才是工时表从 0 到 1 的真正起点。