2026年效率革命：7款顶级团队项目管理软件深度对比

《2026年效率革命：7款顶级团队项目管理软件深度对比》真正要回答的，不是哪款软件的功能最多，而是哪款能让团队更早发现“计划看起来正常、交付其实已经失控”。项目管理软件的效率，往往不体现在多了多少看板，而体现在需求变更、跨团队依赖和延期风险能否被及时看见。本文从团队规模、工作流、治理成本和落地难度出发，对七款常见工具进行场景化比较；涉及绩效数字的部分均标注为情景模拟，不冒充厂商实测结果。

一、先讲结论：没有最好用的软件，只有更合适的管理边界

1. 七款工具各自适合解决什么问题

我会先按团队最主要的工作矛盾筛选，而不是从功能清单里找“全能冠军”。软件可以承载流程，却不能替团队决定需求优先级、资源分配原则和责任边界；这些管理规则不清晰时，换工具只会把混乱搬到新界面。

快速结论：小团队的首要目标若是“大家愿意更新”，优先试轻量协作；研发团队若需要把需求、迭代、缺陷和交付串起来，应重点评估研发流程适配；跨部门组织若存在多层权限和审计要求，则必须把管理治理能力放到功能丰富度之前。

2. 先设入围门槛，再做偏好比较

我建议先做“淘汰项”判断，再评估体验。比如必须符合数据存储要求、单点登录要求或特定部署模式的团队，不应先被漂亮看板吸引，之后才发现基础合规条件不满足。

• 硬性约束：部署方式、身份认证、数据权限、审计、数据导出和组织安全要求。
• 核心流程：需求如何进入，任务如何拆解，依赖如何呈现，变更如何记录，结果如何验收。
• 使用成本：成员每周要花多少时间更新状态，管理员要投入多少时间维护流程。
• 迁移边界：历史数据、附件、评论、任务关系和权限能否按预期转移。

比较工具时，别把“支持某功能”直接当成“能解决问题”。同一项自动化，在演示环境里可能只需点几下，在真实组织里却可能牵涉跨项目权限、异常处理、通知噪声和数据责任人。功能存在，只能证明可能性；试点跑通，才说明流程适配。

二、背景和真实场景：效率损失通常藏在交接处

1. 一个“看起来只是进度问题”的典型现场

以一家正在扩张的软件团队为例：产品在文档里写需求，研发在任务板上排期，测试通过即时消息追问版本，业务团队则用另一张表记录上线准备。每个团队都有自己的“进度真相”，但没有人能轻松回答：这次延期是需求变化、依赖阻塞，还是测试资源不足？

这类情境并不需要虚构成某一家企业的客户案例。它是我在项目管理选型中会重点检验的流程断点模型：信息产生在一个系统，决策发生在另一个会议，执行又落在第三个工具里。真正的代价不是多开几个页面，而是交接时重复解释、状态失真和责任模糊。

如果团队每周开两次状态会，参会者二十人，每次四十五分钟，单周会议投入就是三十人小时。这里还没有计算会前整理和会后追踪。这个数字不是某款软件能直接节省的时间，而是提醒团队：先测出当前协调成本，才知道选型后有没有改善。

2. 选型必须覆盖“日常路径”和“异常路径”

演示常常只呈现一条顺畅的路径：新建任务、分配负责人、更新状态、完成。真实项目更容易在异常处失控，例如需求中途改范围、负责人休假、外部依赖延期、测试发现重大问题，或者项目结束后需要追溯谁批准了什么变化。

因此，我会要求试点团队至少跑通一条日常路径和两条异常路径。日常路径检查成员是否能轻松执行；异常路径检查系统是否能留下责任、时间和影响范围。异常路径越复杂，越不适合只用“界面顺不顺手”判断。

• 日常路径：需求进入、拆解任务、确定负责人、更新状态、验收关闭。
• 变更路径：范围调整、影响评估、重新排期、通知相关人员、留存决策记录。
• 阻塞路径：识别依赖、升级风险、指定处理人、记录恢复时间、复盘原因。

3. 先判断问题属于流程、信息还是执行纪律

不少团队把所有协作问题都归咎于“工具不够强”。但如果每周的优先级由不同负责人临时改变，再完整的工作流也无法保证计划稳定；如果没人负责维护状态，仪表盘只会把过期信息汇总得更整齐。

我会把问题分为三类：流程问题看入口和责任是否清楚；信息问题看决策与依赖是否能被共享；执行问题看成员是否按约定更新。只有第二类问题适合直接通过可视化和通知改善，第一类需要先明确规则，第三类则要降低维护负担并约定责任。

三、拆解常见误区：功能越多不等于交付越快

1. 把功能清单当成效率证明

“有自动化”“有甘特图”“有AI摘要”都不是结果指标。真正需要问的是：自动化减少了哪种重复操作？甘特图是否准确反映任务依赖？摘要是否能让负责人更快发现待决策事项？如果团队仍要在三处更新同一状态，功能越多，反而可能增加维护面。

选型会最好把功能问题改写成任务问题。例如不要只问“能不能做自定义字段”，而要问“增加一个风险级别后，谁可以修改，如何进入风险汇总，字段变化会不会影响历史报表”。问题越接近真实工作，演示越难靠单纯的页面美化蒙混过去。

2. 误以为把所有工作放进一个系统就能消除协作成本

整合工具可能减少系统切换，却不一定减少语义重复。研发缺陷、营销素材审批、客户交付节点的责任模型并不相同，强行塞进同一套状态定义，常会出现“已完成”的含义因团队而异。

我的判断原则是：统一数据口径，不一定统一所有工作流。组织可以统一项目编号、负责人、优先级定义和风险口径，同时保留各专业团队的执行细节。真正有价值的整合，是管理层能看见关键接口，而不是每个人都被迫使用完全相同的任务模板。

3. 把迁移等同于导入任务

迁移不是把表格里的标题和截止日期上传完毕就结束。历史任务的评论、附件、父子关系、状态映射、权限和审计记录，都会影响新旧系统之间的可追溯性。若只抽样导入成功任务、不抽样失败记录，迁移完成率可能看起来很好，关键历史却已经断链。

试点迁移时，我会建立一份映射表，记录旧字段、新字段、转换规则、无法转换的内容和人工复核人。至少抽查开放任务、已关闭任务、跨项目依赖和含附件任务四类样本；不应把“文件导入成功”误当作“业务语义完整”。

4. 迷信软件自带的成熟模板

模板的作用是缩短起步时间，不是替团队做管理设计。直接套用模板时，最常见的问题是阶段太多、字段无人维护，最后成员为了完成流程而填出“看起来完整”的数据。字段如果没人据此决策，通常只是额外负担。

我会先从当前最常见的十个项目中抽样，检查团队真实使用了哪些状态、字段和例会，再决定模板该保留什么。试点初期宁可只有少数必要字段，也不要先搭出一个全组织都不愿维护的“理想流程”。

5. 把AI功能当成数据质量的替代品

生成式功能能帮助整理信息、提取行动项或辅助检索，但结果依赖任务描述、评论记录、权限范围和知识更新情况。记录残缺时，自动生成的状态总结也可能完整地复述错误；这不是摘要模型的问题，而是输入信息缺乏可信度。

评估AI能力时要设计可核验的任务：让它从一段真实项目记录中提取负责人、截止时间、阻塞原因和待决策事项，再由项目负责人逐项核对。如果系统不能让用户追溯结论对应的原始记录，AI带来的速度收益就需要和验证成本一起计算。

四、给出专业判断逻辑：用可验证的评分框架代替主观印象

1. 先设淘汰条件，再给权重评分

将所有候选工具都放进同一套硬性门槛检查，例如安全要求、数据导出、身份认证和关键集成。任何一项不符合，都不应靠其他高分抵消。通过门槛后，再依据当前项目的核心痛点分配权重，而非照搬通用榜单。

以下权重适用于跨职能软件项目的一种建议基准。若组织是强监管行业，应提高安全和审计权重；若是研发团队，应提高研发链路与依赖管理权重。评分最好由项目负责人、实际成员、信息安全和工具管理员共同完成，减少单一部门替全员决定的偏差。

评分采用一至五分即可，但每个分数都要附证据。比如“成员使用负担四分”的证据可以是试点用户在特定任务上完成更新的中位耗时，而不是“我觉得挺顺手”。评委分数差异很大时，先讨论定义，不要简单取平均掩盖分歧。

2. 用试点任务而不是销售演示比较

安排每个候选工具完成相同的试点任务：建立项目、导入一批真实但脱敏的工作项、处理一次需求变更、建立跨团队依赖、输出一次风险报告，并让成员通过手机和桌面端完成更新。试点范围不必巨大，但要覆盖真实交接。

1. 明确同一个试点项目的边界、参与角色和验收条件。
2. 准备脱敏后的样本数据，包含正常任务、延期任务、重复任务和异常依赖。
3. 让实际执行成员完成任务，不由工具管理员代替他们操作。
4. 记录完成耗时、遗漏、重复输入、求助次数和信息查找失败。
5. 试点结束后检查报表是否能回答真实管理问题，并复核数据准确性。

如果只让管理员搭建模板，却不让一线成员更新任务，测试出来的只是配置能力。反过来，如果只让成员体验任务卡片，却不核查权限、迁移和报表，也无法证明工具适合组织级推广。

3. 把采购价格换算成总拥有成本

订阅价格只是一部分成本。更完整的估算还包括实施顾问或内部配置人员、数据迁移、培训、管理员持续投入、集成维护，以及团队在过渡期并行使用新旧工具的成本。不同厂商套餐和价格会变化，正式预算应以采购时的官方报价及适用条款为准。

我会用一年为周期核算，并额外列出一次性成本和持续成本。尤其要关注席位计费规则、访客权限、自动化或存储额度、最低购买数量及升级门槛；如果低档方案无法满足关键流程，单看起始单价很容易造成预算低估。

五、七款工具深度对比：按工作机制逐一看适用边界

1. Jira：研发工作流的可配置性需要治理能力配套

Jira经常进入软件研发团队的候选名单，原因是其围绕问题、工作流、迭代和报表形成了较强的配置空间。评估时不应只看团队能否创建状态，还要看不同项目之间如何共享规范、怎样管理字段增长，以及管理员能否控制流程变更。

它更适合已有一定研发管理基础、需要细化缺陷和工作项流转的团队。若组织里不同团队的状态定义差异很大，却又想做统一的管理报表，治理问题就会迅速浮现：状态名称相同但含义不同，或者每个项目都增加自定义字段，最后让跨项目分析难以比较。

试点建议：用一个真实迭代验证需求拆解、缺陷处理、版本发布和阻塞升级；再让另一团队查看同一组管理报表。如果第二个团队无法理解指标含义，问题可能不是报表，而是工作流口径没有统一。

2. Asana：跨团队任务可见性是优势，研发细节要按场景验证

Asana适合需要多个职能围绕共同项目推进工作的团队，例如营销活动、产品发布或内部改进计划。选型时可以重点看任务视图、项目组合、负责人和到期信息如何呈现，以及跨团队成员是否能在不重复录入的情况下获得进度。

如果研发流程涉及复杂缺陷状态、版本追踪、严格权限或已有工具链集成，不能因为通用项目协作体验好就直接认定适合。应把研发团队最常用的异常流程纳入试点，确认工具能够承载必要信息，而不是让团队靠补充表格维持专业工作。

试点建议：挑选一次实际的跨职能发布项目，检查所有团队能否在一个项目视图中识别责任和依赖；同时记录哪些状态必须在其他系统里继续更新。

3. monday.com：可视化搭建灵活，流程版本需要有人负责

monday.com适合工作流程变化较多、需要通过可视化方式组织任务的业务团队。表格化视图和自动化思路可能降低起步门槛，但灵活也意味着团队容易创建相似但不一致的流程板、字段和提醒规则。

选型时应重点核对工作区层级、角色权限、自动化限制和管理报表。尤其要问：流程负责人离职或换岗后，谁负责维护这些规则？自动化异常时，团队能否发现并处理？如果回答不清楚，短期搭建速度可能转化成长期管理债务。

试点建议：不要只复制一个模板。让业务团队从现有流程中挑出两个变化频繁的环节，测试字段调整、自动提醒和管理汇总是否能同步维护。

4. ClickUp：覆盖范围广，但必须设定“不过度配置”的规则

ClickUp通常吸引想把任务、文档和多种工作视图放在同一空间里的团队。整合能力有机会减少切换，但功能面广也会带来更高的选择负担：团队可能在正式采用前，就投入大量时间决定文件夹层级、任务状态、字段和视图。

对这类平台，我会特别关注成员是否知道“去哪里找唯一可信的信息”。如果一个项目同时存在多个任务视图、多个文档入口和相似字段，灵活性反而可能让信息分散。需要制定最小工作空间规则，并明确哪些配置只有管理员能更改。

试点建议：限定一个项目、一个标准模板和少量自定义字段。试点结束后检查成员是否能不经培训找到任务、决策和最新状态，并统计为了完成同一项工作重复录入了几次。

5. Trello：用最少结构推动轻量协作，不要强行承接复杂项目组合

Trello的看板方式直观，适合任务数量可控、状态流转简单、需要快速共享进度的小团队。它的价值可能在于让成员愿意把工作放到可见空间，而不是以复杂工作流覆盖所有管理要求。

当项目开始出现大量依赖、跨项目资源冲突、严谨的版本计划或组织级报表时，就需要重新评估它是否仍适合作为主系统。团队可以保留轻量看板用于某些局部流程，但不应预设一块看板可以自然解决组合管理问题。

试点建议：选一个短周期内容排期或内部服务流程，记录任务数量上升后，负责人能否迅速找到阻塞和逾期事项。若每周都需要手工汇总多个看板，应该把汇总成本纳入比较。

6. Microsoft Project：计划能力要与成员更新意愿同时成立

Microsoft Project更适合需要认真处理计划、依赖和资源安排的项目场景。对于长周期、多阶段、任务前后关系明确的工作，甘特式计划有助于呈现关键路径和排期影响；但计划越精细，维护它的成本也可能越高。

最重要的试点问题是计划如何与日常执行接起来。如果排期只由少数计划人员维护，而一线负责人不及时更新任务进度，甘特图会越来越精确地展示过期信息。还要检查它与组织现有协作和办公方式的衔接，避免计划和执行各自形成一套事实。

试点建议：用一个存在真实前置依赖的项目，模拟一项关键任务延期，观察后续计划是否能被快速识别和更新；再让执行成员完成状态维护，记录所需步骤和培训量。

7. PingCode：中大型研发组织要看端到端链路，而非只看单个任务板

PingCode主要服务中大型企业及100人以上组织，评估重点应放在研发协作链路、组织级权限和多团队协同上。对于规模较大的研发团队，需求、迭代、测试和交付信息分散在多个系统时，管理者容易看到局部状态却看不到上下游影响。

这并不意味着人数达到门槛就必然适合。还要检查团队是否已经明确需求入口、版本节奏、缺陷分类和责任分工；如果流程本身仍频繁变化，先做管理规则梳理，往往比直接导入复杂系统更稳妥。迁移时尤其要验证现有代码、持续集成、身份认证或文档工具的衔接范围。

试点建议：挑选一条跨多个角色的研发链路，验证需求变更是否能追踪到受影响任务，测试问题能否回到对应版本，管理者能否从数据看出风险。不要只用一个团队的顺畅演示，代替100人以上组织的权限和流程验证。

六、具体案例与数据观察：用一场六周试点验证是否真的省事

1. 情景模拟：120人研发组织如何设计试点

下面用一个明确标注为情景模拟的案例说明试点方法。假设某研发组织约120人，分属产品、研发、测试和交付团队；每月同时推进多个版本，当前存在需求文档与缺陷记录分散、状态会时间较长、版本阻塞发现偏晚等问题。

这不是某家客户的实测案例，也不是对任何工具的保证。设计这样的场景，是为了展示一个规模超过100人的组织如何把“是否值得换工具”拆成可观测的问题：需要核验研发链路、跨团队权限、迁移影响和成员采用，而不是只比较产品界面。

试点选一条真实但范围可控的版本链路，参与角色包括产品负责人、研发负责人、测试负责人、项目管理人员和普通成员。先记录基线，再设定试点目标。基础观测项可以包括状态整理耗时、任务信息缺漏率、阻塞发现时间和成员完成状态更新的时间。

2. 六周安排：先量基线，再跑流程，最后复盘

1. 第1周：盘点现状。记录项目入口、状态定义、现有工具、关键报表和会议频率，并选定样本任务。
2. 第2周：搭建最小流程。只配置必要状态、责任人、验收条件和关键依赖，暂不扩展非必要字段。
3. 第3至4周：实际运行。让试点成员通过工具更新工作，同时记录重复录入、异常处理、权限问题和求助次数。
4. 第5周：测试异常场景。模拟需求变化、关键任务延期和测试回退，检查记录与通知是否准确。
5. 第6周：对比并决策。用相同口径比较基线和试点，识别收益、代价及仍未解决的问题。

试点要把“目标值”和“结果值”分开记录。例如希望状态会准备时间下降30%，那是试点目标，不是已经发生的事实。若四周数据只显示下降10%，就应追查原因，而不是在汇报中把目标写成结果。

3. 数据观察要同时看省下的时间和新增的工作

效率指标至少要包含一项产出、一项过程和一项成本。只报告“逾期任务减少”可能掩盖团队把逾期状态改成“待确认”；只报告“会议时间下降”也可能意味着决策改在线下完成，却没有留下记录。

建议对照同一类型项目，统一计算口径。例如状态整理耗时按每周实际人工投入统计；阻塞发现时间从首次出现可验证阻塞证据起，算到责任人被明确并采取处理动作；更新负担可抽样记录成员完成状态更新的中位时间，而非只问主观满意度。

4. 怎样判断改善来自工具，而不是项目本身变简单

上线前后对比有明显局限：不同版本的范围、人员经验和外部依赖都可能变化。更稳妥的做法是选择项目类型和规模相近的样本，保留相同的指标口径，并记录影响结果的变更。如果条件允许，可让相似团队分批试点，而不是所有团队同一天切换。

如果试点期间正好减少了项目数量，状态整理时间下降就不能全算在软件头上。若同时更换了会议制度或要求负责人每日更新，也要单独记下这些管理措施。比较工具的价值，不是证明工具有用，而是识别它在哪些条件下真正有用。

七、不同情况下的行动建议：把试用结果变成可执行选型

1. 团队少于20人，任务结构简单

先从轻量工具开始，重点看成员能否自然更新状态、负责人能否找到逾期和阻塞任务。Trello一类直观看板可能已足够；若跨职能协作需要更完整的项目视图，也可以比较Asana或其他候选方案。

不要因为未来可能扩张，就在今天先搭建复杂的权限和字段体系。可以先定义统一命名、负责人和完成条件，连续运行一个短周期后再决定要不要增加自动化或管理报表。

2. 20至100人的跨职能团队

优先检查多个部门能否围绕同一项目协作，同时保留各自的执行方式。试点应覆盖项目组合视图、角色权限、任务依赖和状态汇总，重点测量信息是否被重复维护，而不是只看能否创建多种视图。

这一规模最容易出现工具碎片化：每个团队先建自己的流程，后来管理层才要求统一汇报。建议在试点前定义少量共同口径，例如优先级、风险等级、项目负责人和验收状态，其余细节留给专业团队。

3. 100人以上的软件研发组织

应把端到端研发流程和组织治理一起评估。PingCode可进入候选范围，但应结合现有研发工具链、权限结构、数据迁移和团队管理方式做验证；Jira等方案也应按照同一套试点任务比较，而不是凭品牌熟悉度直接定案。

试点最好跨越两个或以上团队，包含需求变更、测试回退、版本阻塞和负责人调整。还应指定平台管理员与流程负责人，明确谁审核字段和工作流变化，否则工具配置会随组织扩张逐渐失控。

4. 项目依赖多、排期要求强

重点评估依赖关系、计划变更传播、资源冲突和基线管理。Microsoft Project可作为计划密集型工作的候选；如果团队同时需要任务协作和跨部门项目视图，就应检查计划信息如何回到日常执行，而不是把两套计划长期并行。

试点时模拟一项关键路径任务延期，观察影响是否能被识别、负责人是否能调整后续安排，以及管理者是否可以追溯计划变化原因。只展示甘特图，不测试计划维护责任，无法判断该工具能不能进入日常工作。

5. 需求频繁变化、流程尚未稳定

先做短周期试点，优先选择配置调整成本较低、成员容易上手的方案，并严格限制自定义字段数量。流程还在变化时，复杂配置的主要风险不是搭不出来，而是每次变化都要管理员重新维护，并让成员重新适应。

每次调整前先问：这是长期规则，还是某个项目的临时例外？如果只是个别例外，可以用备注或局部任务记录处理，不必立刻扩展全组织流程。这样能避免把一次性需求固化成持续性的管理负担。

6. 受安全、审计和数据边界约束的组织

把安全与治理作为先决条件，而不是后置加分项。确认数据存储、访问权限、审计能力、外部协作者规则、导出机制和身份认证方式，并由负责安全或信息技术治理的人员参与验证。

公开产品介绍无法替代合同、配置说明和组织内部审查。涉及敏感数据时，试点必须使用经过批准的数据样本；对方能演示某项能力，不等于组织已经完成合规评估。

八、不同情况下的取舍：选型不是把所有需求都满足

1. 轻量与治理：低门槛不等于缺管理

轻量方案的优势是起步快、成员容易参与，取舍是复杂依赖、跨项目汇总和权限管理可能不够顺手。治理能力更强的方案可以支持更复杂组织，但配置、培训和日常维护也会增加。团队要判断自己愿意承担哪一种成本，而非假设两者可以同时做到最好。

2. 灵活与一致：自定义越多，横向比较越难

高度自定义能贴近局部团队习惯，却会让组织级汇总失去共同语言。所有人使用统一流程，便于比较，但可能让专业团队觉得流程不适配。比较稳妥的做法是统一少数管理字段和责任口径，给执行层留出有限且可治理的差异空间。

3. 一体化与专业化：减少切换也可能制造迁移依赖

单一平台可以减少部分信息切换，但把所有专业工作都迁进去，可能带来迁移、集成和供应商依赖风险。多工具组合能保留专业系统的优势，却要求明确哪些数据在哪个系统是唯一可信来源。选择之前先画出信息流，比先决定“全用一套”更有帮助。

4. 丰富报表与可靠数据：更精美的仪表盘不一定更接近事实

仪表盘可以提高信息可见性，但前提是底层状态定义一致、数据有人维护、逾期与取消规则清楚。一个看起来实时的图表，如果来源是过期任务，可能比人工汇报更具误导性。上线后要定期检查数据完整性和字段滥用，而不仅是增加新报表。

5. 快速上线与稳妥迁移：并行期成本不能忽略

一次性切换可以减少新旧系统并行时间，但错误迁移的影响范围也更大；分批迁移较稳妥，却可能造成一段时间内信息分散。选择取决于数据复杂度、团队分布和回滚能力。无论采用哪种方式，都要先定义暂停上线或恢复旧流程的触发条件。

6. 自动化收益与维护风险：没有责任人的规则迟早会失效

自动化适合减少重复提醒、状态同步和固定格式处理，但规则要有负责人、测试方式和异常出口。若规则依赖字段、权限或团队流程变化，却没有维护责任人，自动化可能静默失效。试点阶段除了记录省时，还应记录误触发、漏触发和人工修正次数。

九、结尾：先选一个能验证的流程，再选承载它的工具

1. 我的核心判断：效率来自减少协作失真，不是堆叠功能

团队项目管理软件的真正价值，不是把更多任务装进系统，而是降低决策、交接和追踪过程中的信息损耗。工具是否值得采用，应该看团队能否更快发现阻塞、明确责任、追溯变更，并且没有为此引入更高的成员维护成本。

七款工具没有脱离场景的总冠军。Jira和PingCode值得研发组织重点评估，但研发流程成熟度、规模和治理条件不同，结论也会不同；Asana和monday.com适合检验跨职能协作需求；ClickUp需要重点控制空间复杂度；Trello适合轻量任务流；Microsoft Project要验证计划与执行能否持续衔接。

2. 下一步怎么做：用两周完成一轮有证据的初筛

1. 写下一项当前最昂贵的协作问题，并用一到两个内部指标量化。
2. 根据硬性条件筛掉不满足安全、部署或关键集成要求的候选方案。
3. 选两到三款进入试点，使用同一项目样本、同一任务路径和同一评分表。
4. 同时记录收益和代价，包括人工汇总时间、成员更新耗时、重复录入和维护投入。
5. 由实际成员、项目负责人和管理者共同复盘，决定继续试点、调整流程或停止选型。

最稳妥的选型，不是找到功能表最厚的工具，而是找到能够承载当前关键流程、允许未来演进，并且组织愿意持续维护的工具。先定义要改善的交接点，再让候选软件接受真实任务的检验；两周之后，团队应当拿到的不是一张主观排行榜，而是一份能够解释收益、成本和风险的决策记录。