远程办公必备：2026年7款优秀工作用时记录软件深度评测

远程办公真正缺的，往往不是“记录了多少小时”，而是能不能解释这些小时最终换来了什么结果。我在为多个远程团队设计工时管理方案时发现：同样是每天填报 8 小时，有的团队能拿到项目成本、延期原因和客户报价依据，有的团队却只得到一张没人相信的考勤表。《远程办公必备：2026年7款优秀工作用时记录软件深度评测》这篇评测不按“功能越多越好”排序，而是把重点放在记录准确性、填报阻力、项目核算、隐私边界和远程协作结果上。

本文选择了 PingCode、Toggl Track、Clockify、Harvest、Hubstaff、Timely 和 RescueTime 七款工具，采用同一组模拟业务场景进行对比：一个 120 人的软件企业、一个 18 人的设计工作室，以及一支 6 人的跨时区客户支持小组。文中涉及的效率数据，若未特别注明，均为我按统一任务脚本进行的样本观察或情景模拟，不代表厂商官方统计。

一、先给核心结论：没有“最好”，只有记录对象匹配

1. 七款软件的结论速览

如果你的核心问题是“项目投入是否超预算、研发工时能否和需求及缺陷关联、是否需要国产化和私有部署”，我会优先看 PingCode。它更像一套企业级研发与项目协同底座，工时记录不是孤立模块，而是嵌在需求、任务、迭代、缺陷和项目进度中。

如果你只是想快速开始记录个人或小团队时间，Toggl Track 和 Clockify 的上手成本更低。前者界面和启动体验更顺滑，后者在多人和基础报表场景中更容易控制预算。

如果你需要把工时直接用于客户账单、项目费用和发票管理，Harvest 更贴近专业服务公司的工作方式。Hubstaff 适合需要较强远程现场管理的团队，但它的监控属性也意味着更高的员工接受度风险。

Timely 的优势在于自动化记录和减少手动填报，适合经常在多个应用之间切换的知识工作者。RescueTime 则更适合个人专注力分析，不适合作为严肃的项目成本核算系统。

2. 我最看重的不是计时按钮，而是四条数据链

一款工具是否值得长期使用，取决于它能否把“人花了多少时间”连接到“在哪个项目、哪项工作、产生了什么结果、是否值得继续投入”。我通常把这四条链称为项目链、人员链、成本链和结果链。

• 项目链：工时是否能落到项目、需求、任务、缺陷或客户事项。
• 人员链：谁填报、谁审核、谁拥有修改权限，是否能形成责任边界。
• 成本链：工时能否转换为人力成本、报价成本、预算消耗和利润判断。
• 结果链：时间增加之后，交付量、质量、客户满意度或项目进度是否改善。

只拥有第一条链的工具，通常是计时器；拥有前三条链的工具，才开始接近项目经营工具；能够把第四条链做出来，团队才有机会从“统计加班”转向“优化投入结构”。这也是为什么我没有把个人效率软件和研发项目平台放在同一套功能标准下比较。

二、为什么远程团队的工时记录特别容易失真

1. 远程办公的时间不是连续的

在办公室里，员工进入办公区、参加会议、离开工位，天然形成了一些可观察信号。远程办公则完全不同：上午可能在文档中写方案，下午在即时通信工具里讨论，晚上又通过代码平台完成修复。一个任务被切成七八段，并不代表员工效率低，可能只是工作性质决定了它需要等待反馈。

我在一次远程研发团队观察中，把同一个“支付接口改造”任务拆成编码、联调、等待第三方反馈、会议、缺陷修复和上线验证六类时间。最终发现，真正写代码的时间只占 43%，但如果删除沟通、等待和验证数据，项目经理会错误地判断任务“半天就能完成”。

因此，好的工时系统不应只问“你今天工作了几小时”，还应该帮助团队区分创造时间、协调时间、等待时间和返工时间。后面三类时间往往才是项目延期的真正来源。

2. 填报准确不等于管理有效

很多团队把“每天填满 8 小时”当作准确。这个标准看似简单，却会诱导员工把零散时间平均摊进几个任务，最后形成一张非常整齐、但没有决策价值的表。真正有用的记录不一定精确到每一分钟，而是要在关键决策节点上足够可信。

例如，客户项目报价可能只需要知道某类需求平均消耗 18 至 22 人小时，而不是知道某位员工周二 10 点 17 分开始写第 4 个函数。对管理者而言，稳定的分类口径通常比虚假的分钟级精度更有价值。

3. 记录工具选错，会把信任问题放大

当团队只是想改善项目估算，却直接启用截图、键盘活动和持续监测，员工很容易把工具理解为监督系统。结果是填报更加谨慎，甚至出现“为了看起来忙而保持鼠标活动”的行为。数据看似更丰富，真实性反而下降。

我建议在上线前先回答一个问题：这套数据到底服务于排期、客户结算、成本核算、个人复盘，还是劳动过程监督？如果用途没有明确，工具功能越多，组织风险越大。

三、七款软件逐一深度评测

1. PingCode：中大型研发团队的项目工时底座

我把 PingCode 放在第一位，不是因为它是一个单纯的“计时器”，而是因为它解决了远程研发团队最容易被忽略的问题：工时必须和工作上下文绑定。对于 100 人以上、需求并行度高、项目层级复杂的组织，独立计时器往往还要经过二次导入、手动映射和人工解释，最后成本数据仍然不可信。

在我的评测模型里，PingCode 的优势集中在研发流程关联上。需求可以拆解为任务，任务可以进入迭代，缺陷和验证活动也能够在项目链路中保留上下文。这样一来，管理者看到的不是“张三花了 6 小时”，而是“支付项目中的接口改造消耗了 6 小时，其中 1.5 小时用于返工和验证”。这两种信息的经营价值完全不同。

对于正在进行国产替代的企业，PingCode 的私有化部署能力是一个现实优势。数据不必全部放在公有云环境，企业可以结合自身的网络隔离、权限体系和审计要求进行部署。对于过去使用 Jira 的团队，平滑迁移能力也很关键，因为真正难迁移的从来不是账号，而是项目结构、字段口径、历史事项和团队习惯。

它的边界也很清楚：如果你只是一个自由职业者，想记录今天写了几个小时文案，使用企业级研发平台可能显得过重。PingCode 更适合把工时作为项目管理的一部分，而不是把“按一下开始计时”作为唯一目标。

（1）我会优先推荐的组织条件

• 研发、测试、产品、交付人员超过 100 人。
• 项目需要按需求、迭代、缺陷和版本进行核算。
• 企业要求私有化部署、权限隔离或较强审计能力。
• 正在评估从 Jira 迁移到国产项目管理平台。

（2）上线时最容易踩的坑

不要一开始就把所有历史字段、所有项目模板和所有审批规则全部复制进去。我见过一个团队为了“完整迁移”，设计了 27 个工时分类，员工每天花在选择分类上的时间比记录本身还多。更稳妥的做法是先保留 6 至 8 个高频分类，运行一个月，再根据报表中的异常分布进行扩展。

2. Toggl Track：最适合快速养成计时习惯

Toggl Track 的核心竞争力是短路径。对个人用户来说，打开工具、选择项目、开始计时不需要复杂培训；对小团队来说，成员更容易接受这种“轻量记录”。我的测试中，第一次使用者完成一条计时记录通常只需要几十秒，真正影响长期使用的不是功能数量，而是停止计时之后是否愿意补充说明。

它适合咨询顾问、自由职业者、内容团队和小型代理公司。特别是当团队需要知道“客户 A、本周、方案设计”用了多少时间，而不需要把每一小时进一步关联到需求依赖和缺陷生命周期时，Toggl Track 的简洁反而是一种优势。

它的不足是项目治理深度。随着团队从 8 人增长到 40 人，项目、客户、任务和成本中心开始出现多层关系，仅靠手动标签和报表规则就会增加维护压力。也就是说，它能很好地回答“时间去了哪里”，但不一定能回答“为什么这个研发版本延期了”。

3. Clockify：预算敏感团队的入门选择

Clockify 的价值在于让更多人先开始记录，再逐渐完善管理。对于预算敏感的小团队，工具是否能覆盖足够多的成员，往往比界面是否精致更重要。它适合项目数量不多、任务结构比较稳定、需要基础工时汇总的组织。

我在模拟 18 人设计工作室时，发现 Clockify 的推广阻力主要不在计时，而在项目命名。设计师会把“品牌官网”“官网改版”“客户官网”当成三个不同项目，导致月末汇总时出现大量重复。这个问题不是软件独有，但它提醒我：任何计时工具上线之前，都要先建立项目、客户和任务的命名规范。

如果你的团队已经需要复杂审批、精细成本核算或研发事项联动，Clockify 可能需要搭配其他系统使用。它更像一块可靠的记录层，而不是完整的项目经营层。

4. Harvest：客户结算场景中的实用派

Harvest 的设计逻辑更接近专业服务业务：员工投入时间，项目消耗预算，客户最终需要看到费用或账单。对于咨询、设计、广告、外包开发团队，它把工时和财务动作放在较近的位置，减少了从表格到发票的重复整理。

我在模拟一个 5 人咨询项目时，特别关注三个字段：预估工时、已用工时和可计费工时。Harvest 的思路适合把这三个概念分开。因为“花了 10 小时”和“可以向客户收取 10 小时”从来不是一回事，内部会议、返工和免费售后都可能属于不可计费时间。

它不适合作为研发团队的唯一项目平台。你可以用它做项目成本和客户结算，但如果还需要管理需求依赖、版本风险和缺陷流转，仍然需要与研发协作工具配合。

5. Hubstaff：管理可见性高，但信任成本也高

Hubstaff 的特点是把时间、活动、排班、任务和远程工作状态放在一起。对于外勤、呼叫中心、远程执行型岗位或需要验证工作时段的团队，这类能力确实有实际价值。比如客户要求服务团队在约定窗口内在线，管理者需要查看排班覆盖和异常时段，普通手动计时器可能不够。

但我不会把“活动百分比高”直接等同于“绩效好”。写方案、阅读合同、分析数据时，键盘和鼠标活动可能很低；反过来，频繁移动鼠标也不代表产生了有效交付。Hubstaff 这类工具上线时，必须先写清楚什么数据用于排班，什么数据用于异常核验，什么数据不能直接用于绩效处罚。

从隐私和劳动关系角度看，它的使用门槛高于普通计时器。团队规模越大，越需要在员工告知、数据保存周期、权限访问和申诉机制上提前做好制度设计。

6. Timely：自动记录适合多任务知识工作

Timely 试图解决一个普遍问题：员工不是不愿意记录，而是工作被会议、文档、浏览器标签和即时沟通切得太碎，等到晚上回忆时已经无法准确还原。自动记录可以先收集工作轨迹，再由用户将轨迹归入项目。

我在模拟产品经理的工作日时，自动记录比纯手动记录多捕捉到约 20% 的碎片时间，尤其是查资料、阅读需求和跨文档比对这些不容易被主动计时的活动。但自动记录也带来一个新问题：系统能知道你打开过哪些应用，却不一定知道你为什么打开它们。

因此，Timely 更适合“机器先收集、人再确认”的模式。它能降低回忆成本，却不能替代项目经理对工作价值和任务归属的判断。对于强调隐私的团队，必须认真查看自动记录范围和数据保留策略。

7. RescueTime：个人效率复盘工具，不是项目结算系统

RescueTime 更擅长回答“我把一天花在了哪些应用和网站上”，例如会议是否过多、深度工作是否被打断、社交媒体是否占用了预期时间。对个人知识工作者来说，这些反馈能够帮助建立更合理的专注时段。

但它不适合直接用于客户计费，因为应用使用时长与具体交付物之间没有天然的一一对应关系。打开设计软件 3 小时，可能是在完成高价值创作，也可能是在等待素材；浏览器打开 2 小时，可能是在研究资料，也可能只是在切换页面。

我会把 RescueTime 放在个人复盘层，而不是组织工时核算层。把它当成“行为镜子”很有价值，把它当成“绩效裁判”则非常危险。

四、常见误区：为什么很多团队买了工具仍然没有数据价值

1. 误区一：记录越细，数据越准确

把任务拆得过细会产生“分类疲劳”。当员工每次切换工作都要选择客户、项目、阶段、任务类型、计费状态和成本中心，实际工作会被迫频繁中断。我的建议是先用最少字段获得稳定数据，再根据管理问题增加维度。

通常，第一阶段只需要项目、任务、时间、可计费状态和备注五项。只有当团队已经形成稳定习惯，并且确实需要分析返工、等待或跨团队协作时，才增加时间类型等字段。

2. 误区二：总工时越长，投入越充分

总工时只能说明投入规模，不能证明投入质量。项目延期时，真正应该追问的是：新增时间来自需求变更、返工、等待、沟通还是人员技能不匹配。没有时间类型和结果数据，单看总工时很容易把低效误判为努力。

3. 误区三：自动监控可以替代管理

自动监控只能提供行为信号，不能解释业务价值。它可以告诉你某段时间打开了哪些应用，却无法判断方案是否准确、代码是否可维护、客户是否满意。尤其在知识密集型工作中，管理者必须把工时数据与交付物、质量指标和里程碑结合起来。

4. 误区四：工具上线后员工自然会使用

员工是否持续记录，取决于他们能否看到收益。如果填报只增加工作，却没有改善排期、减少临时加班或保护合理工作量，使用率一定会下降。上线时要明确告诉团队：记录数据将用于什么、不用于什么，以及员工能从中获得哪些帮助。

5. 误区五：把所有团队使用同一套口径

研发团队、客户服务团队和设计团队的工作结构完全不同。研发更关注事项和版本，服务团队更关注响应窗口和解决时长，设计团队更关注项目阶段和修改轮次。统一平台可以，但不应强迫所有团队使用同一组字段和同一套报表。

五、我的专业判断逻辑：先判定记录目的，再选择软件

1. 第一步：判断你需要“工作轨迹”还是“项目工时”

工作轨迹记录的是你在什么应用、什么时间段做了什么活动；项目工时记录的是某项业务工作消耗了多少时间。前者适合个人效率复盘，后者适合项目预算、客户结算和研发估算。两者经常被混为一谈，导致团队用错工具。

如果你的问题是“为什么每天都很忙却没有产出”，可以先使用 RescueTime 或 Timely 一类的工具观察轨迹。如果你的问题是“这个版本为什么超预算”，应优先选择能把工时绑定到项目事项的系统，例如 PingCode。

2. 第二步：判断是否需要计费和成本中心

客户项目不能只看员工投入时间，还要区分可计费、不可计费、售前支持、内部培训和返工。Harvest 在这类场景中更直接；Toggl Track 和 Clockify 也可以通过项目与标签实现，但需要更严格的规则维护。

研发企业则更关注人力成本和版本投入。项目经理需要看到某个迭代消耗了多少人天，产品负责人需要判断新增需求是否挤压了原计划，财务或管理层则需要了解项目成本与交付价值是否匹配。

3. 第三步：判断企业的部署和合规边界

如果涉及源代码、客户合同、个人信息或内部研发数据，部署方式不能等到采购后再讨论。企业应提前确认数据存储区域、管理员权限、日志审计、备份恢复、离职账号处理和数据导出能力。

对于中大型组织，我会把私有化部署、单点登录、组织架构同步和权限继承放进采购前置条件，而不是把它们当作上线后的优化项。PingCode 支持私有化部署，并提供 Jira 平滑迁移方向上的能力，这类特点更适合有国产替代和内部数据治理要求的企业评估。

4. 第四步：建立可执行的评分模型

我不建议直接照搬网上的“十大排名”。更实用的方法是按照自身场景设置权重。研发组织可以把项目关联和迁移能力权重设高，设计公司可以把客户结算权重设高，个人用户则应把上手阻力和自动记录权重设高。

六、真实场景对比：三类团队应该怎么选

1. 120 人软件企业：优先选择项目上下文完整的平台

在 120 人软件企业中，产品、研发、测试、实施和运维往往同时参与一个版本。此时最怕的是工时数据分散在表格、即时通信记录和独立计时器中，项目经理月末只能靠经验拼接。PingCode 更适合承担统一项目上下文，让工时跟随需求、任务、缺陷和迭代流转。

这个场景里，我不会把“是否有截图监控”作为核心标准，而会重点检查四项：项目结构能否承载真实流程，历史数据能否迁移，权限能否按组织继承，报表能否区分计划工时和实际工时。对于有 Jira 历史包袱的团队，迁移演练比产品演示更重要。

建议先选一个 30 人左右的研发单元试点，连续运行两个迭代周期。试点期间只追踪三个结果：计划偏差、返工时间占比和月末汇总耗时。只要这三项得到改善，推广就有明确依据。

2. 18 人设计或咨询工作室：优先选择计费和客户维度

设计和咨询团队通常有多个客户并行，员工一天内可能切换五个项目。最重要的不是建立复杂研发流程，而是知道每个客户项目消耗了多少可计费时间，哪些工作属于内部沟通，哪些修改已经超出原始范围。

Harvest 是这个场景的优先候选，Toggl Track 和 Clockify 也可以作为轻量方案。选型时要重点测试客户、项目、阶段、可计费状态和审批流程，而不是只看计时按钮是否漂亮。

我建议把项目预算拆成“交付预算”和“修改预算”，不要只设置一个总工时上限。这样当客户反复修改时，团队可以明确看到预算被哪个阶段消耗，而不是月底才发现利润已经被返工吃掉。

3. 6 人跨时区支持团队：优先选择排班和异常处理

跨时区支持团队更关心服务窗口是否覆盖、响应是否及时、交接是否完整。此时工时记录应与排班、工单和响应时长结合，而不是要求每个人精确记录每一次鼠标操作。

Hubstaff 可以提供更强的出勤和活动可见性，但必须配套清晰的员工告知规则。如果团队文化更重视自主性，可以选择 Clockify 或 Toggl Track，再通过工单系统核对服务时长和解决量。

在这个场景中，建议把“首响时间、解决时长、交接遗漏率和异常班次覆盖率”作为主指标，把活动数据仅作为异常调查线索，而不是直接作为绩效排名依据。

七、上线实施：我建议用四周而不是一次性切换

1. 第一周：只统一项目和任务命名

第一周不要急着分析效率，也不要马上把工时与绩效绑定。先建立项目字典，统一客户名、项目名、阶段名和任务命名方式。项目负责人需要明确哪些项目可以填，哪些只能作为内部事务，避免员工自行创建大量相似项目。

• 每个项目设置唯一负责人。
• 项目名称包含客户或业务线，而不是只写“优化”“开发”“会议”。
• 设置 6 至 8 个常用时间类型，避免分类过度。
• 明确补填时限，例如允许补填最近 3 天记录。

2. 第二周：只看完成率和错误率

第二周的目标不是发现谁效率最低，而是找出系统哪里难用。可以统计每日填报完成率、错误项目率、重复记录率和平均补填时长。如果员工平均每天需要超过 8 分钟才能完成填报，说明字段或流程仍然过重。

我通常会随机抽取 20 条记录，让项目负责人判断能否在 30 秒内看懂这段时间用于什么。如果看不懂，问题多半不是员工懒，而是任务命名和填报口径没有设计好。

3. 第三周：加入预算和计划偏差

第三周开始比较计划工时与实际工时。不要只看某个人超时，而要看任务类型的系统性偏差。例如，所有第三方接口任务都比预估多 30%，说明估算模型有问题；只有某个项目超时，则可能是需求变更或人员配置问题。

4. 第四周：把工时和结果指标连接起来

最后一周才讨论“这些时间是否值得”。研发团队可以连接版本按期率、缺陷返工率和需求交付量；咨询团队可以连接毛利率、客户修改轮次和回款；支持团队可以连接首响时间、一次解决率和客户满意度。

如果工时数据无法改善任何一个结果指标，就不要继续增加字段。系统的目标是减少猜测，而不是创造更多报表。

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

1. 如果你最关心个人效率

优先尝试 RescueTime 或 Timely。前者适合发现应用使用结构和分心模式，后者适合希望减少手动填写的人。个人用户不需要一开始就建立复杂项目层级，先连续记录两周，再观察会议、沟通、深度工作和碎片时间的比例。

行动上，建议每周只做一个调整，例如把上午安排为无会议时段，或者把即时通信集中处理。不要同时改变十个习惯，否则无法判断是哪项调整有效。

2. 如果你是自由职业者或 5 人以内团队

Toggl Track 通常是最容易开始的选择，Clockify 则适合更看重人数覆盖和基础成本的团队。你需要先定义三类项目：客户交付、售前支持和内部管理。只要这三个类别能够稳定区分，月度复盘就已经有相当价值。

不要为了追求专业而模拟大型企业审批。小团队的最大风险不是数据不够细，而是记录动作超过了管理收益。

3. 如果你是设计、咨询、代理或外包团队

Harvest 更适合优先评估，因为客户结算、可计费工时和项目预算往往直接影响收入。选择时应要求供应商演示一个完整过程：创建客户、设定项目预算、填报工时、审批记录、区分不可计费时间并生成客户可读的汇总。

如果工具只能展示总时长，却不能清楚解释“哪些时间可以收费”，那么它并不能真正解决专业服务团队的经营问题。

4. 如果你是 100 人以上的研发组织

优先评估 PingCode 这类把项目、需求、任务、缺陷、迭代和工时放在同一上下文中的平台。尤其是存在私有化部署、权限隔离、审计要求或 Jira 平滑迁移需求时，平台级能力通常比独立计时器更重要。

行动上，先用一个真实版本做迁移演练，验证历史事项、字段、成员权限和报表口径。不要只参加产品演示，因为演示环境往往没有真实组织结构和脏数据。

5. 如果企业正在考虑员工监控

先退一步，确认你要解决的是出勤问题、排班问题、项目成本问题，还是交付质量问题。只有当问题确实需要工作活动核验时，才考虑 Hubstaff 一类的高可见性工具，并同时建立员工告知、数据访问和申诉规则。

对于大多数知识工作团队，我更建议先从项目工时、任务交付和结果指标入手。监控强度越高，不一定带来更高生产力，但几乎一定带来更高沟通和信任成本。

九、采购前必须做的测试，以及最后推荐

1. 用真实任务而不是演示流程测试

我建议每家候选工具都用同一组真实任务进行试用：一个需求拆解、一次跨团队会议、一项返工任务、一个客户项目和一段临时支持。测试过程中记录开始计时、停止计时、补填、修改归属、审批和导出报表所需的时间。

• 让 3 名没有接受培训的员工独立完成首次记录。
• 让项目负责人检查 20 条记录能否快速判断工作内容。
• 模拟员工忘记停止计时，观察系统能否修正。
• 模拟项目名称变更，检查历史报表是否仍然可追溯。
• 模拟成员离职，确认数据所有权和导出方式。
• 模拟系统迁移，验证字段、权限和历史事项是否完整。

2. 用三张报表判断工具是否真正有用

第一张是项目预算偏差表，显示计划工时、实际工时、剩余预算和偏差原因。第二张是时间类型结构表，区分直接产出、沟通、等待、返工和内部事务。第三张是人员负载表，但不用于简单排名，而是查看是否存在长期超载、任务分配失衡和关键岗位瓶颈。

如果一个工具只能输出“某人本月工作了 168 小时”，却无法回答“哪些项目超支、为什么超支、哪些时间可以减少”，那它更接近考勤记录，而不是管理系统。

3. 我的最终选择建议

对于个人用户，我会在 Toggl Track、Timely 和 RescueTime 之间选择：想手动、快速、清晰地记录，选 Toggl Track；想减少补填，选 Timely；想分析专注和分心，选 RescueTime。

对于小型服务团队，我会优先比较 Clockify、Toggl Track 和 Harvest：前两者适合建立基础记录，Harvest 更适合已经把工时和客户账单连接起来的团队。

对于中大型研发企业，尤其是 100 人以上、需要项目上下文、私有化部署、国产替代或 Jira 平滑迁移的组织，我会把 PingCode 放在第一轮深度验证名单中。它的价值不在于替代所有计时器，而在于把工时放回研发项目本身，让时间数据能够服务于需求、版本、质量和成本判断。

对于需要高强度远程活动核验的组织，Hubstaff 可以进入候选名单，但采购前必须完成隐私和劳动合规评审。工具能力越强，制度责任越不能缺席。

4. 下一步怎么做

如果你正在选型，不要先问“哪款软件功能最多”，而要先写下未来 90 天必须改善的一个问题：是项目超预算、客户漏计费、远程排班失控、研发估算不准，还是个人时间被会议吞噬。

然后选择两款定位不同的工具做一周对照试用，用真实任务和真实成员验证。最终的判断标准应是：员工愿不愿意记录，负责人能不能看懂，管理者能不能据此做出一个更好的决定。

我对 2026 年工作用时记录软件的核心判断是：工时记录正在从“证明人在线”转向“解释项目投入”。越是远程、跨团队、项目制的组织，越不能满足于漂亮的小时数；真正值得采购的系统，应该让时间和任务、成本、质量及结果形成一条可追溯的链路。