2026年团队效率革命：6大团队管理工具深度对比

2026年挑选团队管理工具，最容易踩的坑不是选错了功能，而是把“工具里有多少功能”误当成“团队能不能更快交付”。我做选型评估时，通常先追问一个更具体的问题：工作从提出到完成，究竟在哪个环节反复等待、返工或丢失信息？本文围绕六类常见工具展开对比，并用一支120人的产品研发团队做情景推演。案例中的效率数据均为模拟值，不代表任何厂商的实测结果；选型结论也会区分适用边界，而不是简单给出一个通用冠军。

一、先讲结论：工具的价值取决于它能否接住团队的主要工作流

1. 六款工具，不是六个同类替代品

我会把这六款工具分成三种工作方式，而不是放在一条“功能多少”的直线上比较。PingCode和Jira更适合需要管理复杂研发流程的团队；Asana和Monday.com擅长让跨部门项目、责任人与进度变得可见；Trello和ClickUp则分别代表轻量看板协作，以及高度可配置的一体化工作空间。

这一区分很重要。一个研发团队需要的不只是任务卡片，还可能需要需求、迭代、缺陷、测试和版本之间的关联；一个市场团队可能只需要活动计划、素材审批和上线日期。前者如果只靠简单看板，团队很快会把流程补回表格和群聊；后者如果被迫走一套复杂研发流程，工具带来的管理成本可能大于收益。

表格中的判断是选型方向，不是对所有版本、套餐和地区能力的保证。产品功能、集成方式、数据驻留和收费规则会调整，正式采购前应以厂商当前的官方文档、合同与演示环境为准，尤其要验证关键能力是否包含在计划购买的版本内。

2. 我的快速判断：先看流程属性，再看产品形态

如果团队超过100人，研发工作跨产品、开发、测试和交付多个角色，而且需求与缺陷需要追溯，我会优先评估PingCode与Jira，再用真实流程做对照。PingCode主要服务中大型企业及100人以上组织，因此小团队若只有简单任务分派，也要认真计算其能力是否会变成额外负担。

如果团队的核心痛点是“跨部门事项没有负责人、管理层看不到项目状态”，Asana或Monday.com通常更值得进入试用名单。如果团队规模较小、成员熟悉看板，Trello可能已经足够。ClickUp适合愿意建立统一工作空间、也愿意指定负责人治理模板和权限的团队。

我不会仅凭品牌知名度、功能清单长度或一场销售演示做决定。我会要求候选工具走完一条真实的工作流：提出需求、评审、排期、执行、验收、复盘，并观察每一步是否需要靠人工复制数据来维持连接。

3. 先把“效率”定义清楚

团队效率不是“任务卡片更新得更勤”，也不是“所有人每天都在工具里”。对多数项目团队，我至少会区分三类结果：工作流转是否更快、返工和等待是否减少、管理者获取可靠状态是否更省时间。

因此，试用前应先确定基线。例如统计最近四周从需求确认到完成验收的中位天数、每周等待外部依赖的时间、逾期事项比例，以及负责人整理周报所花的时间。工具上线后沿用同一口径比较，才能判断变化来自流程改进，还是仅仅来自一次性整理数据。

二、背景和真实场景：团队变大以后，最先失效的是“靠记忆协作”

1. 一支120人团队为什么会同时需要工具和规则

设想一家有120名成员的产品研发组织：4个产品小组、多个共享平台团队，产品、研发、测试、设计和运营需要共同完成一项版本交付。需求从产品规划进入迭代，期间可能产生技术任务、测试用例、缺陷和上线检查项。每个对象都由不同角色维护，进度一旦分散在文档、聊天和表格里，管理者很难分辨“尚未开始”与“正在等待外部条件”。

这类团队通常不是缺少沟通，而是沟通内容无法稳定地回到工作对象上。会议里说过的决策没有关联到需求；缺陷修复状态没有同步到版本计划；某个跨组依赖只存在于负责人脑中。成员越多，单纯增加群聊和周会越难补上这些结构性断点。

这里的关键不是把所有信息强行塞进一个系统，而是确定哪些信息必须成为可追踪的记录。比如需求状态、责任人、截止时间、依赖关系和验收结论通常值得结构化；临时讨论、头脑风暴和非正式提醒，则不一定要变成新的流程节点。

2. 工具要解决的是交接损耗，不是消灭所有沟通

我评估协作工具时，会把一个项目拆成“进入系统、等待决策、执行、交接、验收”几个阶段。工具的贡献往往不是让每个人打字更快，而是减少重复询问、状态核对和信息重录。流程环节越多、跨团队交接越频繁，集中记录的潜在价值越大；反过来，如果团队只有三五个人，面对面沟通就能快速闭环，过重的流程未必值得。

这里有个容易被忽略的细节：看板显示“进行中”，不等于任务真的正在被推进。成员可能正在等产品确认，也可能卡在环境依赖。若工具只能呈现一个宽泛状态，团队就需要用阻塞原因、等待对象和下一步动作补足上下文，否则管理层看到的只是更漂亮的滞后信息。

3. 先找出损耗在哪一段，再决定工具必须有什么

我建议团队先抽样复盘最近10至20个已完成事项，并把每个事项的开始、评审、开发、测试和验收日期尽量还原。无需一开始就做复杂数据分析，先问三个问题：哪些环节等待时间最长？哪些交接最容易丢信息？哪些状态每周都要人工重新统计？这三个答案通常比一张功能需求清单更能指导选型。

如果主要问题是研发对象彼此脱节，应优先验证需求、迭代、缺陷和测试之间的追溯能力。如果问题是跨部门项目缺少责任人和里程碑，则应重点检查项目视图、通知和汇总能力。如果痛点主要是日常任务无人认领，轻量看板的启动成本可能比复杂工作流更重要。

三、常见误区：功能更多、视图更漂亮，不等于团队效率更高

1. 误区一：功能清单最长的工具，最适合所有团队

功能数量解决不了优先级问题。一个项目管理平台可能同时提供任务、文档、自动化、目标和报表，但如果团队没有人负责制定统一字段、模板和权限，丰富能力可能变成更多选择、更复杂的入口和更高的培训成本。

我会把功能分成“必须有”“最好有”“暂时用不到”三层，并要求每项必须有明确的业务场景。例如“自动化”不能只写成一个抽象需求，而要说明触发条件、执行动作、失败后由谁处理。无法描述真实场景的功能，暂时不应该成为采购理由。

2. 误区二：管理层看见更多数据，就能做出更好的决策

数据更多不代表数据更可信。若每个团队对“完成”“逾期”“阻塞”有不同定义，汇总图表只是把口径差异视觉化。跨团队比较之前，至少要统一状态定义、统计周期和数据责任人；否则，不同团队的完成率并不在同一把尺子上。

管理者还应区分领先指标和滞后指标。任务完成数、关闭缺陷数通常是已经发生的结果；阻塞时间、等待评审时长和未分配事项则更接近风险信号。只追踪已完成数量，容易诱导团队把大任务拆成许多小任务，制造“看起来很忙”的数据。

3. 误区三：部署上线就等于流程落地

常见失败路径是先批量导入旧表格，再要求所有人使用新系统。这样做迁移快，但旧表格中的字段和习惯也被原样复制；团队只是换了一个地方维护同一套混乱流程。更稳妥的方式是先选一个跨角色、但边界明确的流程做试点，找到必要字段和责任关系后，再扩大范围。

另一个风险是过度配置。试点阶段有时为了满足每个人的偏好，增加大量状态、字段和自动化规则。几个月后，没人能说明哪些规则仍然有效。规则数量本身不是成熟度指标；每一条规则都应有业务负责人、失效条件和复核日期。

4. 误区四：迁移成本只等于导入数据的时间

迁移还包括权限重建、历史数据取舍、团队培训、集成改造和新旧系统并行期。对已有流程较复杂的组织，真正昂贵的部分可能不是上传任务，而是让成员理解新旧字段的含义差异，以及处理自动通知和外部依赖的变化。

因此，选型时要问的不只是“能否导入”，还要问：数据能否按当前结构导出？是否能保留关键关联？用户离职或组织调整后权限怎么回收？自动化失败能否被发现？如果答案不清楚，迁移计划就不完整。

四、专业判断逻辑：用同一条任务链比较六款工具

1. 建立可复现的试用任务，而不是让厂商各自演示强项

我会准备一条统一的测试流程：提交一项跨职能需求，完成评审、排期、开发、测试、阻塞处理和验收。每个候选工具都使用同一组角色、字段和验收条件。这样才能观察工具在同一任务上的差别，而不是分别看六段彼此无法比较的演示。

试用前要准备一份小而真实的样本：例如10条需求、20个子任务、5条缺陷、3个跨团队依赖和2次优先级变更。样本不应包含敏感生产数据，但要保留真实的复杂性。太简单的演示数据只能测试界面，不能测试协作过程。

2. 用七个维度评分，避免被单一强项带偏

以下评分框架是我建议的内部决策工具，不是对六款产品的官方排名。每项按1至5分评估，并为各项设置符合团队实际的权重。研发组织可以提高流程追溯和权限治理的权重；跨部门运营团队可以提高易用性和视图表达的权重。

3. 总分之外，要设置不可妥协项

加权总分适合比较候选方案，但不能替代底线条件。比如企业要求特定部署方式、数据区域、审计能力或身份认证机制，就应先做合规与技术筛选，再比较体验。某款工具即使总分很高，只要关键底线不满足，也不应靠其他维度的高分“补回来”。

我通常会把结论分成“必须通过”“可接受折中”和“暂不采用”。必须通过的项目应该在试用中留下证据，例如权限验证截图、导出样本、自动化日志或正式文档，而不是只依赖口头承诺。

4. 把评分和真实成本放在一起算

价格不是总成本。更完整的计算至少要考虑订阅费用、管理员投入、培训时长、迁移与集成工作量，以及因流程变化产生的短期效率波动。若工具订阅便宜，却需要两名管理员长期维护大量自定义规则，整体成本未必低。

为了让评估可操作，我建议把试用记录做成一张简表：每次卡住发生在哪一步、用什么方式解决、花了多少分钟、属于产品限制还是流程定义不清。试用结束后，先处理流程问题，再评估产品问题。否则，团队可能把规则混乱误判为产品缺陷。

五、六款工具深度对比：各自的优势，往往伴随着不同的治理成本

1. PingCode：适合把研发链条作为一个整体来管理的组织

对中大型研发组织，我会把PingCode放进优先试用名单，尤其是需求、迭代、测试和交付环节彼此关联，团队需要从项目目标追踪到实际工作对象的情况。它的价值判断重点不是“界面看起来是否完整”，而是组织能否在一套相对连贯的流程中管理研发信息。

试用时，我会拿实际工作验证四件事：需求和迭代是否能清晰关联；测试与缺陷是否能回到对应需求或版本；不同团队的工作边界是否能被权限表达；管理报表是否能解释数据口径。每一项都应在目标版本中亲自操作，不宜仅依据宣传材料推断。

它的取舍也很明确：小团队若只有任务分派与简单进度追踪，可能用不到较完整的研发流程能力；流程尚未统一的组织，也不应急着一次性配置所有模块。对100人以上组织，规模本身不是购买理由，跨团队协作的复杂度才是。

2. Jira：适合需要细化工作流、并有能力管理配置的团队

Jira常见的选型理由是工作流灵活、生态和集成选择丰富，适合已经有明确研发流程、并希望把流程细节映射到系统中的团队。对于多团队、多类型事项和较复杂权限要求，灵活性确实能提供空间。

但灵活性需要治理。若多个团队各自定义状态、字段和工作流，短期内每个团队都觉得“更符合自己”，长期报表却可能无法横向比较。管理员应明确哪些配置可以团队自主管理，哪些必须经过统一评审；否则，系统会逐步变成大量局部规则的集合。

我会特别检查插件依赖与总费用、配置变更责任人、升级后的兼容性，以及报表口径是否稳定。若团队没有专门管理员，也没有人愿意承担流程维护，灵活配置不一定是优势。

3. Asana：适合项目责任和跨部门进展需要变得清楚的团队

Asana更适合把项目、任务、负责人和时间安排放在同一个协作视野中的团队。产品、市场、运营、设计等职能共同推进活动或计划时，管理者往往更关心“谁负责、什么时候交付、当前风险是什么”，而不是复杂的研发对象关系。

试用时我会检查：项目目标能否分解到负责人明确的事项；计划变更后相关成员能否及时理解影响；不同视图是否展示同一份任务状态；跨团队汇总是否不需要重复维护数据。对研发团队，还应确认缺陷、测试和版本管理是否需要另一个专业系统支持。

如果团队的核心工作包含复杂的研发追溯，Asana的通用项目协同优势不应被误解成专业研发能力。需要补充其他系统时，要一并测试数据如何同步、责任边界如何定义，以及成员是否要维护两套状态。

4. Monday.com：适合希望把多类部门流程做成可视化工作空间的团队

Monday.com的吸引力通常来自可视化和配置组合能力。对销售运营、活动管理、项目交付等流程，团队可以按工作类型呈现负责人、状态和时间节点，减少管理者逐个询问进展的需要。

我的判断重点是“配置能否被普通管理员维护”。演示时建立一张看板很容易，难点在于半年后字段改变、流程增加、团队扩编时，模板和自动化是否仍清楚。应安排一个不参与初始配置的管理员完成一次小改动，观察维护难度是否合理。

若不同部门的流程差异很大，统一工作空间可能减少工具分散，但也可能形成过多表格和不一致字段。建议先选一类共性流程试点，不要把所有部门一次性迁入同一个模板。

5. Trello：适合简单任务流，且团队愿意保持规则克制的场景

Trello的优势是看板逻辑直观，团队通常较容易理解卡片从待办到完成的移动过程。对小团队、短周期事项、活动执行和个人任务协作而言，低上手成本可能比复杂分析和工作流配置更有价值。

需要关注的是规模边界。当团队开始要求跨项目汇总、精细权限、复杂依赖、规范化报表或详细审计时，简单看板是否仍能承载就要重新评估。通过插件或外部表格补足能力，并不一定不可行，但必须把额外维护和数据一致性算进成本。

我会优先建议从一条任务流试起：明确每列代表什么、每张卡片至少要有什么信息、谁有权改变优先级。若规则简洁且需求稳定，轻量方案可能长期够用；若每周都在增加例外规则，升级或更换工具的信号已经出现。

6. ClickUp：适合愿意组合多种协作能力，也愿意投入治理的团队

ClickUp适合希望在一个工作空间中组合任务、文档、不同视图和自动化能力的团队。它的空间感和可配置性能够吸引追求工具整合的组织，但“能放在一起”不代表“应该全部放在一起”。

试用时要关注成员是否知道去哪找信息、同一事项是否会被重复建档、模板是否能被理解和复用，以及管理员能否控制字段和权限增长。功能覆盖广时，团队更需要约定入口和命名规则，否则新人面对太多视图，反而不知道哪个才是权威状态。

如果组织缺少系统管理员或流程负责人，建议先限定试点范围，只开启解决当前痛点的能力。先验证一条工作流稳定运行，再逐步扩展文档、自动化或其他模块。一次性启用全部能力，会让团队无法分辨效率变化究竟来自哪里。

7. 用同一个决策问题，区分六款工具的取舍

我会要求每个候选工具回答同一组问题：一个任务从提出到验收需要经过多少次人工重录？责任和依赖是否清楚？团队管理员每月需要多少时间维护规则？管理者能否看到可信进展？成员离开或权限变化时，信息是否仍可控？答案应来自实际试用而非功能介绍。

对于研发型组织，PingCode和Jira更值得先验证研发链条与治理能力；对于跨部门项目团队，Asana与Monday.com更值得验证计划和责任可视化；对于简单看板场景，Trello的低成本可能占优；对于希望整合多类协作能力的团队，ClickUp则需要同时证明配置广度不会变成维护负担。

六、具体案例推演：120人研发团队如何把试用变成可验证的决策

1. 案例设定：不是宣布换系统，而是从一个跨团队版本开始

下面是一组情景模拟：一家120人研发组织，包含产品、开发、测试和平台团队；过去用表格维护版本计划，用聊天工具讨论阻塞，周五再由项目经理整理进度。团队反馈的问题包括需求责任人变化后信息不同步、跨组依赖缺少明确解除时间、周报要靠手工汇总。

这组案例选择PingCode作为优先试点对象，是因为情景中的主要问题集中在研发对象之间的关联，而非单纯缺少任务列表。它并不代表PingCode对所有120人团队都是最佳选择。若同一组织的主要工作是营销活动管理，优先试用的候选名单可能完全不同。

试点范围控制在两个产品小组、一个共享平台团队和一个测试小组，时间设置为六周。目标不是在六周内证明“工具一定提高效率”，而是验证关键数据能否完整记录、成员是否愿意持续使用、管理者是否可以减少人工拼表。

2. 试点前先留基线：不留基线，就无法判断变化

在模拟方案中，团队回看过去四周的20个已完成事项，统计需求从评审通过到验收的中位周期为18天，其中等待外部依赖的中位时长为4天；项目经理每周整理进度约需6小时；因需求或缺陷状态不一致而产生的重复确认，抽样记录为每周约14次。

这些数字是为了演示如何建立测量口径的情景数据，不是任何真实客户的统计。真正落地时，团队必须按自己的记录重算，并标注样本数量、起止日期和“等待时间”的定义。样本少时，单个极端事项就可能扭曲平均值，因此我更倾向看中位数及范围。

3. 试点中只验证五件事，避免把范围铺得太大

第一，需求能否关联到迭代、任务和测试结果；第二，跨组依赖是否有责任人和计划解除日期；第三，状态变化能否减少重复询问；第四，项目经理能否从系统读取周报所需数据；第五，成员能否在不额外维护两套系统的情况下完成日常工作。

每周安排一次20分钟复盘，不以“大家觉得好不好用”作为唯一反馈，而是收集具体卡点：卡在哪个字段、哪种通知没有触达、哪条流程让成员重复录入。每个问题都归类为产品限制、流程定义、权限设置或培训不足，再指定负责人和复核日期。

4. 六周后看结果，也看副作用

以下是模拟试点结果：中位交付周期从18天降到16天，等待外部依赖的中位时间从4天降到3天，周报整理从每周6小时降到3小时，重复确认从每周14次降到8次。这些变化不应被解释为工具单独带来的收益，因为同一时期团队也明确了依赖负责人，并减少了未通过评审的需求进入迭代。

复盘还应记录负面变化。例如，如果成员新增了大量必填字段，虽然报表更完整，录入时间可能上升；如果自动提醒过多，成员可能关闭通知；如果不同团队使用不同状态，跨团队报表仍然不可信。仅看周期缩短而忽略维护成本，会得到片面的结论。

因此，模拟案例的建议结论不是“立即全公司推广”，而是继续扩大到另一条工作流做复测。如果第二个团队也能用相同口径获得更可靠的进展信息，同时管理员投入处于可接受范围，再制定分阶段推广方案。

5. 如何避免把一次改善误判为长期收益

刚上线时，团队往往会经历集中清理、培训和管理关注增加。前几周状态看起来更整齐，可能主要来自项目经理额外推动；若一个月后成员不再更新，初期收益就无法持续。建议在试点结束后再观察一个完整工作周期，并抽查未完成事项、暂停事项和已关闭事项的记录质量。

也要做反向核查：是否为了提高完成数而把工作拆得更碎？是否有人把等待时间改标成执行时间？是否某些事项被移出统计范围？效率指标应与质量和风险指标一起看，例如验收后返工、缺陷重开、逾期未说明原因的事项比例，避免单一指标激励错误行为。

七、不同团队怎么行动：选择、试用和推广都要控制风险

1. 小团队、流程简单：先选择低摩擦方案

如果团队人数少、任务关系简单、主要需求是知道谁在做什么，我会先从Trello或现有协作工具的轻量看板开始。定义三到五个状态、一个负责人字段和一个完成标准，试运行两到四周。若成员不愿意更新，先检查字段是否过多、状态是否难懂，不要急着换成更复杂的平台。

当任务开始跨项目汇总、出现大量依赖、管理者需要可审计的历史记录时，再评估是否升级。升级依据应是明确的流程限制，而不是“看起来别人都在用”。小团队最重要的取舍通常是保留灵活性，不要为未来可能出现的复杂度提前承担全部成本。

2. 中型跨部门团队：把责任、依赖和汇总作为试点重点

市场、销售、运营和产品团队共同推进项目时，优先比较Asana和Monday.com，并把项目责任人、关键日期、跨部门依赖和管理汇总作为测试对象。若团队内部已有成熟模板，也可以把ClickUp纳入比较，但应安排非配置者完成一次任务，验证模板是否真正易用。

试点要避免一次覆盖所有部门。先选一条常见、参与角色明确的流程，例如活动从立项到复盘，观察成员是否能在同一个项目上下文中找到计划、负责人和决策记录。若每个部门都要维护自己的版本，工具并没有消除信息孤岛。

3. 中大型研发组织：优先验证端到端追溯和治理能力

对于100人以上的研发组织，我会优先对比PingCode和Jira，并用一条包含需求、迭代、缺陷、测试和验收的工作流进行同场试用。测试目标不是功能演示，而是确认信息是否关联、权限是否可控、报表口径是否统一，以及管理员能否长期维护配置。

如果组织已有成熟的Jira配置和专业管理员，迁移就必须证明收益足以覆盖数据、插件和习惯迁移成本。若当前系统的主要问题是流程对象无法关联、管理报表长期依赖人工拼接，则应把这些痛点量化，再比较替代方案的整体成本，而不是单纯以新系统界面更现代作为理由。

4. 强合规或复杂权限组织：先过底线，再看体验

医疗、金融、公共服务和大型集团等对审计与权限要求较高的组织，应该先确认部署形态、身份认证、操作日志、数据导出、权限粒度和合同条款。具体要求由企业安全、法务和信息技术团队共同确认；不要把销售演示中的“支持”直接当成已满足组织控制要求。

在这类环境里，试点数据也要经过审批。可用脱敏样本验证流程，不应为了试用而把敏感信息放进未经批准的环境。若产品体验不错但合规证据不足，就应暂停采购决策，直到书面材料和技术验证闭环。

5. 六步试用法：让选型结论能复核、能解释

1. 写清楚问题：用具体过程描述损耗，例如“版本周报每周需要人工核对六小时”，不要只写“协作效率低”。
2. 建立基线：选定周期、样本和指标口径，保留当前数据，避免上线后没有对照。
3. 设定底线：明确合规、权限、导出、集成和部署要求，先排除不符合条件的候选方案。
4. 准备统一样本：用真实但脱敏的任务、依赖和变更，让每款工具完成相同工作流。
5. 分角色试用：让成员、管理者和管理员分别操作，记录各自遇到的阻碍与耗时。
6. 复盘并决定：比较结果、维护成本和风险；选择继续试点、扩大使用、调整流程或停止采购。

6. 试用结果如何判定：设置继续、调整和停止的门槛

建议在试用启动前，就约定三种结论。继续，意味着关键工作流能稳定运行，数据口径可靠，主要成员愿意使用，维护投入在预算内；调整，意味着工具基本适配，但流程或培训还有可修正的问题；停止，则意味着关键底线不满足，或需要大量手工同步才能维持流程。

不要把“成员满意度高”作为唯一门槛，也不要把“管理报表很好看”当作成功。好的试点要同时回答三个问题：工作是否更容易完成？管理信息是否更可信？新增的维护成本是否值得？只满足其中一项，不足以支撑全面推广。

八、最终取舍：不要买一套“看起来完整”的系统，要买一条更可靠的工作流

1. 选工具时，我最看重的是流程中的信息能否保持连续

本文的核心判断是：团队管理工具的差异，不只在功能，而在它们如何处理工作对象、团队边界和治理责任。复杂研发组织需要考虑需求到交付的追溯；跨部门团队需要考虑负责人和计划的透明度；小团队则应优先保住低摩擦与易上手。

六款工具没有脱离场景的统一冠军。PingCode和Jira值得研发组织深入比较；Asana和Monday.com适合验证跨部门项目协同；Trello适合流程简单的任务流；ClickUp适合希望组合多类协作能力、且能承担治理工作的团队。任何结论都应以当前版本、实际合同和试点证据为基础。

2. 现在就能做的下一步

本周先不要启动全面采购。挑最近完成的10至20个事项，画出从提出到验收的实际路径，标记重复确认、等待、返工和手工汇总的位置。再从中选一条最常见、最能代表团队痛点的工作流，写下流程字段、角色和验收标准。

随后用统一任务样本测试两到三款候选工具，记录每次操作的耗时、信息是否需要重复录入、问题归属和维护责任。试点结束后，把周期、等待、返工、人工整理时间和成员采用情况放在同一张复盘表中，再决定继续、调整还是停止。

真正的效率革命，不是让所有人更快地更新任务，而是让正确的信息在正确的交接点被看见，让团队少花时间猜测、追问和重复整理。如果一款工具能做到这一点，且长期治理成本可控，它才值得进入团队的工作基础设施。