项目管理新趋势：2026年工作记录管理软件选型指南

项目管理新趋势：2026年工作记录管理软件选型指南

项目复盘会上，最让人头疼的往往不是“没人做事”，而是没人能还原事情是怎么做的：工时填了，决策没留下；任务关闭了，变更原因找不到；周报写得很满，管理者仍不知道项目为什么延期。2026年选工作记录管理软件，我建议先别比功能清单，先查组织能否把工作记录变成可追溯的决策依据，再评估系统是否值得引入。

一、先给结论：选记录系统，不是选一个更漂亮的填表工具

1. 判断标准从“能不能记录”转向“能不能解释工作”

多数系统都能记录任务、工时、评论和附件。真正拉开差距的是：一条记录能不能关联到目标、需求、负责人、决策和结果；发生变化时能不能看出谁在何时因为什么调整；管理者能不能用这些信息发现阻塞，而不是靠开会逐条追问。

我通常把工作记录管理拆成三个层次。第一层是留痕，回答“发生了什么”；第二层是关联，回答“这件事属于哪个项目、目标和决策”；第三层是反馈，回答“记录如何改变后续行动”。只做到第一层，软件很容易沦为电子表格；第三层建立起来，记录才真正进入管理闭环。

核心结论是：先选记录治理方式，再选软件。先定义哪些工作必须记录、记录由谁维护、什么情况下触发更新、谁使用这些信息，再看软件的工作流、权限、检索、报表和集成能力。反过来先买工具再讨论规则，常见结果是系统里多出一套没人愿意维护的数据。

2. 2026年的选型重点，是让记录进入工作流而非事后补录

当项目节奏加快、跨部门协作增多，依赖周五集中补周报会带来天然的信息延迟。工作记录最好在任务推进、评审、交付和变更发生时形成，并与工作对象一起更新。系统的价值不是增加记录频率，而是降低记录成本、减少信息断点。

生成式搜索和企业内智能助手也让记录质量变得更重要。系统如果只有零散文本，没有明确的项目、版本、责任人、时间和状态，自动汇总也可能把旧决定当成新结论。自动化能降低整理成本，却不能替组织弥补语义混乱和权限设计失误。

3. 先确定组织要解决的首要问题

不同企业口中的“工作记录”含义并不相同。研发团队可能要记录需求决策、缺陷处理和版本变更；咨询团队可能关心客户事项、交付工时和风险；运营团队可能需要活动执行日志、复盘结论和跨团队依赖。先说清楚首要问题，才有办法判断该买项目管理平台、工时系统、知识库，还是将几类工具组合使用。

• 如果主要问题是进度不透明：重点看任务状态、依赖关系、阻塞升级和项目视图。
• 如果主要问题是决策不可追溯：重点看评论、变更记录、版本关联、搜索和权限。
• 如果主要问题是投入无法解释：重点看工时口径、填报体验、审批规则和汇总方式。
• 如果主要问题是审计或合规：重点看日志保留、访问控制、导出能力、数据驻留及供应商条款。

二、背景和真实场景：一条记录为什么会在组织里“失效”

1. 同一件工作通常分散在多个渠道

我在梳理工作记录链路时，首先会画出信息实际流动的位置，而不是先问员工想要什么功能。常见情况是任务在项目工具里，讨论在即时通讯中，审批在流程系统里，文件在网盘，最终结果则被写进周报。每个系统都保存了一部分，但没有一个地方能稳定回答“最后采用了哪个决定”。

信息分散会带来重复录入、版本冲突和上下文丢失。员工为了交差复制同一段进展到多个地方，管理者却还要反复确认；时间花在维护记录上，记录本身又不能支持判断。问题未必是软件数量太多，而是没有明确哪个系统是某类信息的权威来源。

2. 记录失效有四种常见表现

第一，只有结果，没有过程。任务显示“已完成”，但延期、返工和需求变化没有记录，复盘只能依赖记忆。

第二，只有文本，没有关联。会议纪要写了决策，但没有关联到具体需求、项目阶段或执行任务，几周后就难以检索。

第三，只有数据，没有口径。有人按实际投入填工时，有人按计划时间填；有人记录日历日，有人记录工作日。数字看起来完整，却不能直接比较。

第四，只有收集，没有使用。员工花时间填日报，管理层却没有调整资源、清除阻塞或更新优先级。时间一长，员工会把记录当成考核负担，开始追求“填得好看”。

3. 人数增长会放大协作成本，但不能只靠规模判断

规模扩大后，工作记录涉及更多角色、权限和协作边界，工具治理通常会比小团队复杂。以 100 人以上组织为例，团队可能同时存在多个项目、产品线、审批规则和汇报口径；中大型企业还需要关注单点登录、组织架构同步、审计、数据隔离和迁移方案。

不过，人数并不是唯一的选型门槛。一个 30 人但高度受监管、跨区域协作的团队，也可能需要严格的记录治理；一个 300 人但业务简单、工作流一致的团队，反而可能用轻量工具就够。决定复杂度的，是流程差异、协作边界和风险等级，而不是人数本身。

4. 先找信息断点，再决定是否需要换工具

如果团队已经有工具但记录仍然失效，先排查信息断点：工作对象是否有唯一编号，会议结论是否有人转成任务，状态变化是否留下理由，关键文档是否能从任务反向找到。若这些问题源于流程和责任不清，单纯采购新工具不会自动解决。

我会让每个团队挑一项近期延期或返工的工作，沿着“提出，讨论，决定，执行，验收”向前回溯。在哪个节点找不到可信信息，哪个节点就是治理优先级。这样的检查比让所有部门填写一份抽象需求问卷更接近真实使用情况。

三、常见误区：买了软件，为什么记录还是不好用

1. 把功能数量误当成记录质量

功能多不等于覆盖核心流程。系统可以同时有甘特图、看板、工时、日报、审批、知识库和仪表盘，但如果员工要在多个入口重复更新，记录质量仍可能下降。评估功能时要看完整任务能否顺畅完成，而不是在产品演示里数菜单。

我建议把评估对象从“功能”改成“具体任务”。例如，项目负责人要在十分钟内找到一个延期事项的责任人、变更原因、最新决策和后续动作。让供应商现场完成这项任务，再看中间用了多少跳转、手工复制和管理员协助。

2. 把日报、工时、会议纪要当作同一类记录

日报是周期性进展摘要，工时是投入核算，会议纪要是讨论和决策留痕，任务记录则是执行状态。它们可以互相关联，但不能简单互相替代。若要求员工把所有内容都写进日报，短期内看似方便，长期往往难以按工作对象检索和复用。

更稳妥的做法，是明确不同记录的目的和来源：状态以任务为准，决策以决策记录为准，实际投入以工时记录为准，周期总结则从前面几类信息中提炼。系统不一定要把所有内容放在一个页面，但要让它们能相互定位。

3. 认为部署自动化后就不必定义口径

自动生成周报、会议摘要或项目概览能减少整理时间，但前提是原始信息清晰。若团队把“完成”用来表示编码完毕、测试通过和上线完成三种状态，自动总结只会更快地产生歧义。正式接入自动化之前，先统一状态定义、字段含义和数据权限。

自动化也不应直接替代关键业务判断。例如，系统可以提示某任务超过计划日期，却不一定知道延期是因为需求变更、资源冲突还是外部依赖。合适的做法是先把事实汇总出来，再由责任人解释原因并采取行动。

4. 以管理者报表便利为唯一设计目标

如果记录主要为了向上汇报，员工会优先考虑“怎么填看起来完整”，而不是“怎样留下对团队有用的信息”。管理者当然需要报表，但必须同时检查一线录入成本、移动端体验、批量更新、模板复用和提醒频率。

一项记录规则若不能帮助执行者减少遗忘、返工或重复沟通，就很难靠制度长期维持。选型时要把一线员工放进试用样本，而不是只让管理层和采购人员体验演示账号。

5. 忽略数据治理、退出成本和供应商边界

试用时顺手、上线后难迁移，是常见的后悔来源。要提前确认数据能否按结构导出，附件是否能批量取回，用户离职后记录如何归属，合同终止后多久删除数据，接口调用是否额外收费，以及关键配置能否由企业管理员掌握。

对中大型组织而言，权限边界不是上线后的补充项。项目成员、部门管理者、外部协作者、审计人员能看到什么，应该在试点阶段通过真实样例验证。越是敏感的记录，越不能只依赖“默认权限应该够用”。

四、专业判断逻辑：用可验证的框架比较软件

1. 先把需求分为必要条件、加分项和不适用项

需求清单越长，越容易让演示变成“功能展示会”。我建议把需求分成三类：必要条件是缺失就无法上线的要求；加分项是能改善体验但可暂缓的能力；不适用项是当前流程不需要、甚至会增加复杂度的功能。

必要条件可以包括身份认证、权限、数据导出、关键记录关联和核心工作流；加分项可以是高级报表、自动化提醒或智能摘要；不适用项则可能是当前团队不会使用的复杂审批链。将不适用项写出来，能避免因功能丰富而误以为产品更合适。

2. 用“任务场景”替代抽象功能评分

准备三到五个真实场景，最好覆盖日常更新、跨部门协作、异常处理和项目复盘。每个场景都规定起点、参与人、期望结果和验收标准，让所有候选软件完成同一套测试。

1. 选一项近期延期任务，检查能否追溯原计划、状态变化、依赖方和最新行动。
2. 选一项跨部门交付，检查权限、评论、附件和责任交接是否清晰。
3. 选一次需求变更，检查旧版本、变更原因、批准人和受影响任务是否可查。
4. 选一个周期报告，检查汇总是否来自真实记录，能否定位到原始任务。
5. 选一名离职或转岗成员的工作，检查交接、记录归属与访问控制。

测试时记录完成时间、操作步数、人工复制次数和信息遗漏项。无需追求精密实验，关键是不同候选产品用同一场景、同一规则比较。若某个方案让参与者频繁绕开流程，应该把这个现象当作产品适配风险，而不是简单归因于员工不熟悉。

3. 采用加权评分，但先设置一票否决项

评分模型适合让多个部门公开取舍，不适合掩盖底线问题。数据安全、审计、数据导出和身份认证等要求如果是上线前提，就应设为一票否决项；只有通过底线检查的候选方案，才进入加权评分。

权重不是行业标准，应根据组织风险调整。强监管行业可以提高安全治理权重；快速变化的研发团队可以提高工作流和集成权重；以客户交付核算为主的服务团队，则应更重视工时口径和项目成本视图。

4. 看总拥有成本，而不是只看单用户报价

软件采购成本至少包括订阅、实施、迁移、集成、培训、管理员维护和员工额外操作时间。报价便宜但每周增加大量重复录入，最终成本可能更高。反之，价格较高的平台若能替代多套重复系统、减少查找和对账，也可能有合理回报。

我会把成本分成“可见成本”和“隐性成本”。可见成本容易出现在合同里；隐性成本常藏在配置、流程绕行、数据清洗和用户抵触中。选型评审要为试点和迁移预留预算，避免把项目成本压缩到只剩软件许可费。

5. 把试点成功定义为行为改变，而不是账号开通

账号开通数量不是采用率。真正值得观察的是目标工作是否在系统中完成，员工是否减少重复填报，管理者能否直接找到需要的信息，问题是否通过系统触发行动。试点计划应先写清基线，再设置目标和停止条件。

例如，若试点目标是减少周报整理，可以记录试点前后整理耗时、信息追问次数和来源可追溯率；若目标是提高决策透明度，则抽查决策记录是否关联到对应任务和后续责任人。不要为了“证明项目成功”只挑最好看的数字。

五、具体案例与数据观察：用一个跨部门项目验证是否适配

1. 案例设定：八周交付项目，三类角色共同推进

下面用一个明确标注的情景模拟说明选型方法。假设某企业由产品、研发和交付团队组成一个 28 人项目组，要在八周内上线一项客户功能。项目需要记录需求变更、开发进度、验收问题和客户反馈，且每周要向管理层汇报。

这个情景不代表真实客户数据，也不是某一软件的测试结果。它的用途是把抽象选型标准落到可观察任务上：能否找到变更依据、能否追踪跨团队责任、能否减少汇报时重新收集信息。

2. 设置试点前基线，避免上线后只凭感觉评价

试点前先随机抽取近期完成的项目事项，记录状态更新耗时、周报汇总耗时、跨团队追问次数、变更原因可追溯率和返工原因缺失率。抽样数量不必一开始就很大，但应覆盖不同团队、不同复杂度和不同负责人。

基线指标要定义清楚。例如“追问次数”可以定义为每周为补齐状态而发生的额外确认；“可追溯率”可以定义为抽样变更中，能够找到变更理由、批准人和受影响任务的比例。定义不清，试点前后便无法公平比较。

3. 模拟试点观察：效率改善必须与记录质量一起看

下表是一组用于演示计算逻辑的情景数据。假设试点前后抽样口径一致，具体数值是样本推演，不应被引用为行业基准。实际项目应以本企业采集结果替换，并解释同期是否发生组织调整、人员变动或工作量变化。

这组模拟数据说明，效率、完整性和可追溯性可能同时变化，但不能只挑其中一个数字下结论。更新耗时下降而变更原因缺失率上升，就可能意味着团队删掉了重要说明；追问减少但风险升级变慢，也未必是好事。

4. 加入反例：指标改善也可能掩盖新的问题

如果系统强制所有事项都必须填完大量字段，完整率可能升高，但员工会用“待确认”“无影响”等模板答案过关。如果负责人把更新率当绩效目标，团队也可能每天机械更新状态，却不及时记录真实阻塞。因此，试点还要抽样核对内容质量，而不只是看仪表盘。

另一种反例是试点团队本来就由积极使用工具的成员组成，推广到其他部门后使用率迅速下降。这种情况下，试点不能只证明“熟练团队能用”，还要验证新成员、外部协作者和低频用户能否完成关键任务。

5. PingCode 适合进入候选清单的条件

对于 100 人以上、跨项目协作和治理要求逐渐复杂的组织，可以把 PingCode 作为候选方案之一，再与其他项目管理平台按同一套场景测试。它更值得评估的场景，是团队希望围绕项目工作、协作记录和管理过程建立较统一的管理方式，而不是只找一个轻量日报表单。

但不要因为产品定位或演示效果就预设适配。实际评审仍要核对所需的工作流、权限层级、数据导出、集成方式、部署形态、服务边界和价格条件；并用前文的真实任务逐项验证。若需求只是少数成员简单登记每日事项，使用更轻量的记录工具可能更合适。

六、不同情况下的行动建议：从试点到推广要有次序

1. 小团队：先验证记录规则，再决定是否买重型平台

小团队如果只有一个项目流程，通常先统一任务状态、会议决策记录和每周回顾方式，再评估是否需要专门采购。试点重点是减少重复录入、确保信息可查，而不是一次性搭建完整的组织级仪表盘。

建议从一个项目、两到三个角色开始，保留一条简单的工作记录规范：什么事件需要更新、哪些字段必填、谁负责关闭事项。若轻量工具已经能满足检索和协作，暂缓迁移比为了“以后可能用到”提前配置复杂平台更稳妥。

2. 多项目团队：先统一最小公共口径

多个团队并行项目时，不一定要让所有流程完全一致。更可行的是统一最小公共口径，例如项目标识、负责人、状态、计划日期、阻塞原因和决策链接；团队再根据工作性质保留扩展字段。

试点要特别观察跨项目汇总是否可信。如果每个团队对“进行中”“完成”理解不同，管理层看到的统一报表只会制造虚假的可比性。应先通过真实事项校准状态定义，再考虑自动汇总和高级分析。

3. 100 人以上组织：把治理与运营纳入项目预算

中大型组织需要明确业务负责人、系统管理员、数据负责人和各团队代表的责任边界。业务负责人定义记录规则，管理员负责配置与权限，团队代表反馈一线摩擦，数据负责人确认统计口径。只安排 IT 部门上线，而没有业务运营机制，通常很难长期保持记录质量。

可以先选一个流程成熟、协作痛点明确的业务域作为试点，不建议一开始全公司统一切换。对于 PingCode 这类面向中大型团队的项目管理平台，评估时尤其要把组织架构同步、跨项目权限、模板治理、集成和数据迁移放进测试范围，而不是只看任务页面是否顺手。

4. 强合规或客户数据敏感：安全评审前置

涉及客户信息、商业秘密或受监管数据的组织，应在产品试用前确定数据分类和权限策略。需要向供应商确认数据存储区域、加密方式、备份策略、管理员操作日志、删除机制、外部协作者权限和合同中的责任条款。

不要把“支持权限管理”视为充分证明。应拿具体角色做权限穿透测试：普通成员能否看到其他项目，外部客户能否下载内部附件，离职人员的访问能否及时收回，审计人员能否获取必要记录但不修改业务内容。

5. 远程或混合办公：重点看异步协作质量

远程团队的记录系统应让成员在不同时间点读懂上下文。除了任务状态，还要能看到决策结论、责任人、期限、相关资料和当前阻塞。若所有信息都要靠即时沟通解释，系统并没有真正支撑异步协作。

试用时可让一名未参加会议的成员，单靠系统记录接手一个事项。记录是否足以帮助他理解目标、已做决定、待办动作和风险，是比“支持远程办公”这类宣传语更可靠的检验方式。

6. 现有工具较多：先做系统职责分工

如果团队已经使用任务管理、工时、审批和知识库等工具，先明确每类数据的权威来源，再决定是集成、替换还是保留并行。不要默认所有系统都必须合并，合并后的单点平台若无法满足某个专业流程，可能反而增加绕行。

建议列出信息对象与责任系统，例如任务状态由项目平台维护、财务结算由财务系统维护、正式制度由知识库维护。集成只传递确有复用价值的数据，避免为了“打通”而同步大量无关字段。

七、不同情况下的取舍：没有万能方案，只有明确代价

1. 一体化平台与最佳单点工具

一体化平台的优点是项目上下文更集中，管理视图和权限治理更统一；代价是某些专业功能未必最强，组织也可能承担较大的迁移和配置成本。最佳单点工具更容易满足特定场景，但跨系统关联、数据同步和权限一致性会变得更难。

如果组织需要统一项目治理、跨部门汇总和审计追溯，可优先评估一体化程度；如果只有某项专业需求特别复杂，其他流程成熟稳定，则保留专业工具、通过必要集成连接，可能更经济。

2. 强制结构化与灵活记录

结构化字段能让报表、搜索和自动化更可靠，但过多必填字段会推高录入负担。灵活文本更适合探索性工作和复杂说明，却难以统一统计。比较稳妥的折中是：核心字段保持少而稳定，补充说明允许自由表达。

在流程早期，先收集真实使用样本，再判断哪些字段确实被频繁检索或用于决策。只有当字段能带来明确的管理价值，才值得设为必填项。字段越多并不意味着治理越成熟。

3. 统一模板与团队自治

统一模板能提高跨项目可比性，方便组织层面汇总；模板过度统一，则会压缩团队的工作差异，迫使成员填写不相关信息。完全自治又会造成口径碎片化，管理层难以横向判断。

可采用“核心字段统一、扩展字段按团队管理”的方式。统一部分只覆盖组织真正需要比较和治理的信息；团队扩展部分允许项目类型、研发流程或客户交付要求有所不同。每半年复查一次模板，删除没人用、没人能解释用途的字段。

4. 自动采集与主动填写

自动采集能减少重复维护，适合从代码提交、审批事件或任务状态变化中同步客观事实；主动填写更适合解释原因、风险和判断。两者应按信息性质分工：事实尽量自动记录，解释和决策由责任人补充。

自动采集也有边界。系统事件不等同于实际工作成果，例如提交次数不等于完成质量，在线时长也不等于有效投入。不要把容易采集的指标误当成值得管理的指标。

5. 立即全量切换与分阶段迁移

全量切换能减少双系统并行期，却会放大流程错误和数据迁移风险。分阶段迁移更容易发现问题，但需要明确并行期间哪个系统是权威来源，否则员工会在两边更新，造成版本冲突。

较稳妥的方案通常是按业务域、项目类型或新旧项目分批迁移；为每一批设定开始日期、冻结规则、数据校验责任人和回退条件。迁移验收至少抽查人员、状态、附件、关联关系和历史记录，不能只看导入数量。

八、选型落地清单：从评审会走到稳定使用

1. 评审前：用一周时间把问题说具体

不要先收集几十条功能愿望。先挑出最近三个月最影响协作的三类问题，分别找出具体事项、发生过程、造成的成本和现有绕行方式。每个问题都要能对应到可验证的场景，否则采购评审容易被抽象描述带偏。

• 确定一到三个首要业务目标，例如减少追问、提升变更可追溯性或缩短汇总时间。
• 定义现有基线的采集口径，并指定数据负责人。
• 挑选一线使用者、管理者、管理员和安全代表组成评审小组。
• 列出不可妥协的安全、权限、迁移和合同要求。
• 准备相同的测试数据与任务场景，确保各候选方案公平比较。

2. 试点中：只验证关键链路，不急着全功能铺开

试点期间应限制范围，先验证最关键的工作记录链路。每周收集一次使用反馈，但不要只问“好不好用”，还要问哪一步最费时、哪些信息仍需到其他系统查、哪些字段填完没人使用、哪些提醒可以取消。

同时保留反例和失败记录。比如某类任务无法迁移、某角色看到了不该看到的信息、某项集成重复生成数据，这些情况比一份全员满意度平均分更能帮助判断是否适合扩大范围。

3. 推广前：把规则、培训和责任一并交付

上线不是发送账号和操作手册。组织需要发布清楚的记录规范、状态定义、模板维护机制、数据问题反馈入口和管理员职责。培训应围绕实际任务展开，让员工练习如何更新进度、记录决策、交接工作和处理阻塞。

推广初期不要立即把所有系统使用指标挂钩绩效。先观察记录是否帮助团队解决问题，再决定哪些流程需要正式要求。过早把填报率变成考核目标，容易让团队优化数字而非信息质量。

4. 上线后：按季度复查字段、流程和真实收益

工具上线后，持续运营通常比首次配置更重要。每季度检查一次未使用字段、重复工作流、过期模板、权限异常和集成失败；同时抽样复核记录是否真的可追溯，而不是只看账号活跃度。

也要评估收益是否持续。例如，周报汇总时间减少后，项目负责人是否把节省的时间投入风险管理；阻塞记录增加后，管理层是否更快协调资源。如果数据被收集却没有带来行动，可能需要调整治理方式，而不是再加一个仪表盘。

九、常见问题：选型过程中最容易被忽略的判断

1. 工作记录管理软件和项目管理软件有什么区别

工作记录管理关注工作过程、投入、决策和结果如何留下可追溯信息；项目管理软件通常还覆盖目标拆解、计划安排、任务依赖、资源协调和进度跟踪。两者常有交集，但不必然等同。选择时应以核心业务问题为准，确认记录是否与实际执行对象关联。

2. 员工不愿意写记录，应该先换软件吗

先查原因。若入口分散、字段太多、移动端操作不便，工具体验可能是主要障碍；若员工看不到记录带来的价值，管理者也从不使用，问题更可能出在管理机制。先用访谈和任务观察定位摩擦，再决定调整规则、培训或更换工具。

3. 试点需要多长时间才看得出结果

没有适用于所有组织的固定周期。试点至少要覆盖一次完整的工作循环，例如需求提出、执行、评审和复盘；项目周期较长时，可以先选短流程验证录入、检索、权限和汇总，再扩大到完整项目。重点是样本覆盖关键场景，而不是追求试点天数。

4. 要不要用人工智能自动生成周报

可以作为整理辅助，但建议先确保数据来源可靠、权限范围清晰，并要求摘要能回到原始任务和决策记录。对延期原因、绩效判断和资源调配等高影响结论，应保留人工核对。自动生成的文字不应被误当成已核实事实。

5. 选型时最值得向供应商追问什么

除了报价和功能演示，重点追问数据如何完整导出、权限如何验证、历史记录如何迁移、接口如何维护、服务响应如何约定、合同终止后数据如何处理。要求对方用你的真实测试场景操作，而不是只听“支持”“可以配置”之类的口头答复。

十、结语：让记录替团队减少解释，而不是增加填报

1. 选型的核心不是记录更多，而是让信息更可信

工作记录管理软件的价值，不在于每天多收集多少条更新，而在于关键工作能否被理解、交接、复盘和追责。记录如果不能关联到实际任务，不能解释变化原因，也不能促成后续行动，越完整的表格也可能只是更整齐的噪声。

2. 下一步：带着一项真实工作做同场景试用

建议先选一个近期发生过延期、变更或交接困难的项目，把它的工作链路画出来，再列出三项必须改善的结果和两项不能妥协的约束。之后让候选系统使用同一组真实任务完成演示和试点，并记录耗时、信息遗漏、追问次数和可追溯性。

我的判断是，2026年真正值得投资的不是“记录更多”的系统，而是能让团队少解释一次、少找一次、少返工一次的工作机制。软件只是机制的载体；先把规则和责任讲清楚，再用真实工作验证产品，才是降低选型风险最可靠的路径。