2026年度需求管理软件排行榜：Top 15 企业级需求管理工具推荐

企业做需求管理软件选型，最容易踩的坑不是少看了两款产品，而是把“能写需求、能建任务”误认为“能管理需求”。一条需求从提出、澄清、评审、排优先级，到变更、开发、测试和验收，可能跨越多个团队与数月时间；如果中间的决策依据和关联关系断了，再完整的任务看板也补不回来。本文盘点 15 款企业级工具，但不把它们包装成经过统一实测的绝对名次，而是按产品定位、流程深度和适用场景给出推荐序位，帮助不同类型的团队先筛短名单，再用真实业务流程验证。

2026年度需求管理软件排行榜：Top 15 企业级需求管理工具推荐

一、先给结论：不存在脱离场景的“第一名”

1. 这份榜单怎么读

我把需求管理工具分成三组：面向高治理、高追溯要求的工程与 ALM 平台；面向产品规划、需求发现和路线图协作的产品管理平台；以及以研发交付为主、通过工作流和集成承接需求管理的协作工具。

三组工具的目标不同，不能只看功能清单硬排高下。比如，重视安全关键系统和审计链条的组织，通常更关心需求与风险、测试、版本之间的追溯；互联网产品团队则可能更在意用户反馈、机会评估、路线图和研发协作能否连起来。

下表的序号是阅读和筛选顺序，不是市场份额排名，也不是统一测试得分。现有公开资料并未提供在相同团队、流程、数据和部署条件下完成的横向实测，因此我不制造精确分数，也不把厂商宣传指标写成独立验证结果。

表格用于建立初筛方向，不代表所有产品都具备相同的功能范围、部署方式或套餐能力。产品名称相同，也可能因版本、地区、许可和配置不同而出现能力差异。正式采购前，要逐项核对厂商当前资料、合同范围和实际演示结果。

2. 快速筛选：先按主要矛盾选类别

• 需求必须可审计、可追溯：优先考察 Jama Connect、DOORS Next、Polarion ALM、Codebeamer、Visure Requirements ALM 和 Helix ALM，并用真实的变更与验证流程做演示。
• 产品决策被用户反馈淹没：把 Productboard、Aha! Roadmaps 放入短名单，重点看反馈如何归并、机会如何评估、决策如何回到交付计划。
• 核心问题是需求到研发交付断层：先判断现有 Azure DevOps、Jira 或其他研发平台能否通过工作项、字段、权限和集成满足需要，不一定要整体替换。
• 100 人以上研发组织，需要协作与治理兼顾：可将 PingCode 纳入评估，但不要只看页面演示；应验证多团队权限、需求变更记录、跨项目关联、统计视图和现有工具集成是否符合组织实际。

最终选择不是“谁功能最多”，而是谁能让关键需求在组织里不断链。如果采购团队还不能说清需求提出者、最终决策者、变更审批人和交付责任人，先把职责与流程画出来，软件排名对结果帮助有限。

二、为什么需求管理常常“看起来有流程，实际上没闭环”

1. 需求不是一张卡片，而是一串决策

典型需求从客户反馈、销售承诺、监管条款或内部改进建议开始。提出之后，要判断问题是否真实、影响范围有多大、是否值得投入，再分配到产品版本和交付团队。开发过程中，需求还会被拆分、延期、替换或取消。

因此，需求管理真正要保存的并不只是标题、描述和负责人，而是需求的来源、理由、状态变化、决策记录、上下游关系和验证结果。只要其中一项在邮件、表格或聊天记录里另存一份，团队就开始承担“人肉同步”的维护成本。

2. 团队规模扩大后，沟通成本会以连接数增长

小团队常靠口头沟通快速确认，一两位负责人能够记住需求来龙去脉。团队扩张后，一个需求可能同时影响产品、研发、测试、安全、运营和客户成功等角色。人员数量增加，并不会只带来线性的信息传递成本：新增的协作关系、审批链和跨项目依赖也会增加。

这不意味着每家企业都必须采购重型 ALM。我的判断是：当“找得到最新版本”变成反复确认，当变更影响范围需要人工逐个问人，当一次验收无法说明需求为何如此实现，团队才真正需要更强的需求治理能力。

3. 需求工具的价值，要看断点而不是页面数量

我建议把一次真实需求拆成八个检查点：来源登记、问题澄清、评审决策、优先级排序、版本规划、研发拆解、测试验证、变更与验收。工具如果只覆盖前两步，后续团队仍要搬运信息；如果每一步都能操作，但记录之间没有关联，也不算真正闭环。

选型时可以从最近一个已交付需求反向走查：能否找到最初提出者？为什么排进这个版本？中途改过什么？关联了哪些开发任务和测试用例？最终由谁确认完成？如果要找三个人、翻四个系统才能回答这些问题，产品演示时就应把这个断点作为必测场景。

三、常见误区：买到软件，不等于解决了需求管理

1. 把项目管理看板当作完整的需求工程

任务看板擅长显示谁在做什么、做到哪一步，但需求治理还要回答需求为什么存在、如何评估、变更影响什么、验证依据在哪里。某些项目管理平台经过字段、权限、工作流和插件配置，也能承担相当一部分需求流程；但配置后能用，不等于配置可维护、审计够用或适合全公司推广。

我会把“任务管理”与“需求管理”分开验收：前者关注执行状态，后者关注决策链、来源和追溯关系。若供应商演示只展示看板、卡片和燃尽图，却没有走完整的变更与验收场景，采购方还没有看到核心能力。

2. 只比较功能数量，不计算配置和治理成本

功能表通常容易把选型带偏：一个产品列出很多模块，不代表团队会用；另一个产品看似简单，也不一定能承接复杂权限和历史基线。更值得询问的是，启用这些能力需要多少管理员、哪些规则要自行配置、升级时定制是否受影响，以及业务部门能否在不依赖技术人员的情况下维护字段和流程。

把系统总成本拆成订阅或许可、实施、迁移、培训、管理维护、集成和退出迁移七项，才能避免“月费便宜、长期维护昂贵”。成本不只体现在发票上，也体现在每次流程变化都要排期开发的等待时间里。

3. 用厂商宣传指标代替自己的基线

“效率提升”“交付加速”这类数字，如果没有明确基准、样本范围、观察时间和计算方式，就不能直接推导为本企业的预期收益。不同团队的需求颗粒度、审批层级、系统数量和工作习惯差别很大，外部案例最多用于提出验证问题，不能直接当作采购承诺。

更稳妥的方法是上线前记录自有基线，例如一次需求从提出到评审的中位耗时、变更后受影响任务的查找时间、需求与测试的关联覆盖率、每月重复录入次数。试点结束后沿用同一口径对照，才有可能分辨改善来自工具、流程调整还是团队规模变化。

4. 以为集成按钮等于数据互通

“支持集成”至少要追问四件事：哪些对象可以同步，双向还是单向，冲突由谁处理，权限和历史记录如何保留。只把需求标题同步到开发任务，可能解决了复制粘贴，却没有解决状态回写、关联追踪和删除后的数据一致性。

采购前要拿真实系统做小范围验证，尤其是已有代码仓库、测试平台、客服工单、文档库或身份认证系统的企业。接口是否包含在目标套餐、同步频率是否可接受、失败告警由谁维护，都应该写进试点验收项。

四、专业判断逻辑：用同一套问题比较不同产品

1. 先定义“需求”的对象边界

有的组织把客户痛点、产品机会、业务需求、系统需求和开发任务统称为需求，最后在同一个列表里混放不同粒度的对象。结果是高层看到成百上千条任务，研发又找不到能指导实现的验收条件。

在采购前，先约定至少三层对象：业务或产品层的目标与问题、可交付的需求条目、研发执行任务。再明确它们的父子关系、必填信息和状态规则。工具能否支持灵活关系固然重要，但比功能更重要的是团队对对象边界有共同定义。

2. 用七个维度建评估矩阵

每项可用 1，5 分做内部比较，但必须给分数附证据：1 分表示无法满足或没有验证，3 分表示可通过现有配置满足，5 分表示演示和试点均已验证。没有证据的高分只是乐观判断，不是评估结果。

3. 用门槛项先淘汰，再对比体验

安全、数据部署、语言支持、必要集成和强制审计要求，属于门槛项，不宜和界面偏好一起加权平均。某产品的界面再顺手，只要不满足企业必须遵守的部署或数据要求，就应先出局，而不是靠其他维度高分“补回来”。

通过门槛后，再比较需求流程适配、易用性、实施复杂度和可扩展性。若团队规模较大，建议让产品、研发、测试、信息安全和采购分别参与评分，避免由单一部门替全组织做决定。

4. 试点要测流程，不要只测页面

试点选三类真实需求：一条信息完整、流程顺畅的常规需求；一条会改变范围或版本的变更需求；一条涉及多个团队、系统或合规检查的复杂需求。三类场景可以暴露产品在日常操作、异常处理和追溯上的差异。

1. 明确试点目标和现状基线，不临时更换统计口径。
2. 用真实用户和真实角色执行流程，避免供应商代操作。
3. 记录流程完成时间、人工补录、失败同步、权限误配和用户求助次数。
4. 试点结束后，分别收集一线使用反馈、管理员工作量和决策者的追溯体验。
5. 把缺陷、限制和额外费用写入采购结论，而不是只汇报演示成功。

五、Top 15 工具逐一看：定位、适用范围与试用重点

1. Jama Connect：重点考察需求与验证的关联

Jama Connect 常被放入复杂产品与系统工程场景的候选名单。评估时，我会重点看需求关系、评审过程、变更历史和验证关联是否能覆盖真实项目，而不是仅凭它被归入需求工程类别就推断其适配度。

适合把系统需求、产品需求、验证材料放在同一治理视角下评估的组织。试用时要问清版本与部署条件、许可范围、实施服务边界，以及现有工具链的连接方式。

2. IBM Engineering Requirements Management DOORS Next：关注大型工程治理

DOORS Next 面向复杂工程需求管理，是大型组织可能纳入评估的工具之一。它的价值判断不应停在“能否存需求”，而要落到基线、变更、访问治理和与工程生命周期其他环节的衔接。

如果组织已有相应技术栈或长期工程治理体系，迁移成本、管理员能力和数据结构延续性都要与功能收益一起评估。试点应选一组带有版本变化和验证要求的项目数据，而不是只导入干净的新需求。

3. Siemens Polarion ALM：适合考察端到端工程流程

Polarion ALM 可作为需求、开发、测试和质量流程需要协同的候选方案。它的核心评估问题是团队能否用一致的关联关系追踪需求到实现与验证，同时保留各角色需要的工作视图。

对于当前流程较分散的团队，需额外评估实施范围与流程治理成本。采购方要确认所需模块、许可模式、集成方式和部署选项是否包含在具体方案中。

4. PTC Codebeamer：重点验证复杂产品研发的流程适配

Codebeamer 面向产品工程和生命周期管理场景，适合进入复杂研发、质量和合规要求交织的候选池。它的名字或定位不能替代具体验证，尤其要看需求、风险、测试和缺陷之间的关系是否符合组织的工作方式。

试点时建议挑一条跨部门需求，观察不同角色是否能在权限边界内完成评审、实现和验证。若团队现有工具链已经成熟，还要比较连接既有系统与整体迁移的代价。

5. Visure Requirements ALM：关注需求、风险和验证闭环

Visure Requirements ALM 可作为对需求追溯和验证活动要求较高的组织的候选产品。评估中应关注需求结构、风险信息、测试和验证关系是否可维护，以及项目变化后追溯链是否容易更新。

不要只检查初始建模效果。要模拟一次需求删除、拆分或范围调整，再查看关联对象、历史记录与报告是否能反映变化，并确认相应能力对应的版本和许可条件。

6. Perforce Helix ALM：比较需求与质量环节协作

Helix ALM 可用于评估需求、测试、缺陷等质量相关活动如何在生命周期中关联。它是否适合，取决于团队需要统一管理到什么程度，以及现有开发和测试系统的集成边界。

演示时要求供应商从一条需求出发，展示测试、缺陷和发布相关记录如何形成可追踪链路。若流程依赖多个外部系统，应当把同步异常和数据出口也纳入试点。

7. Microsoft Azure DevOps：已有微软研发流程时先评估延伸

Azure DevOps 的工作项与研发协作能力，对已经使用相关微软研发工具的组织具有现实吸引力。它可以成为需求进入开发交付流程的承载层，但组织仍需判断产品规划、需求评审、基线和追溯要求是否要借助扩展或其他系统完成。

关键不是“能不能创建需求类型”，而是字段、权限、状态和关联能否长期维护。试点要由实际管理员配置一次流程变更，观察升级、报表和跨项目复用是否可控。

8. Modern Requirements4DevOps：适合评估 Azure DevOps 需求工程扩展

Modern Requirements4DevOps 可作为增强 Azure DevOps 需求工程能力的候选方案。它适合纳入“保留既有研发底座、补足需求治理”的比较路径，但要具体核实所需扩展能力、许可、版本兼容和支持范围。

如果团队的问题只是流程定义不清，先做流程梳理可能比增加扩展更有效。采购评估应同时记录原生能力、扩展能力和自行定制能力，避免把三种维护责任混为一谈。

9. Jira：生态与可配置性强，治理质量取决于设计

Jira 常用于研发团队的工作流和任务协作。对已有 Jira 基础的组织来说，扩展字段、工作流和相关应用可能构成较低迁移成本的路径；但配置自由也意味着不同团队容易形成不一致的状态、字段和报表。

试点需检查需求从产品决策到研发任务的关联是否清楚，跨项目汇总能否可靠，插件依赖与升级兼容由谁负责。如果核心流程依赖大量自定义脚本，必须把维护人力纳入总成本。

10. Aha! Roadmaps：重点看产品计划如何连接执行

Aha! Roadmaps 适合纳入产品战略、机会和路线图管理的比较，特别是产品负责人希望把方向、计划和团队协作放在统一视图时。它与工程追溯工具并非完全同类，不能因为有路线图就默认能替代详细需求治理。

演示时应检查战略主题如何映射到产品计划和交付工作，优先级判断依据是否保留，以及计划变化后下游团队能否及时看到影响。若研发执行完全在别的系统中，集成质量会直接影响使用体验。

11. Productboard：适合客户声音归并与产品机会评估

Productboard 可作为管理用户反馈、产品机会和规划决策的候选平台。对需求来源分散在客服、销售、访谈和社区的团队，重点应放在反馈归并、客户背景保留、机会排序和决策回流。

它不必然取代研发任务系统。试点时可抽取一批真实反馈，检查重复项如何处理、客户证据是否能随决策保留、未采纳需求能否解释原因，以及选定机会如何同步至开发计划。

12. Broadcom Rally：考察多团队规模化交付治理

Broadcom Rally 可进入多团队、规模化敏捷和项目组合管理场景的候选清单。应先确认组织到底需要的是需求治理、团队计划协同，还是更高层的组合视图，再验证产品的具体版本和许可能否覆盖目标流程。

大型组织试用时，不能只让一个团队试完就推断全局适用。应分别观察团队级工作、跨团队依赖和管理视图，重点记录数据定义不一致、计划汇总延迟和治理角色负担。

13. Inflectra SpiraTeam：比较统一管理研发质量环节的能力

SpiraTeam 可作为需求、测试、缺陷和发布协作的候选工具。对希望减少研发质量信息分散的团队，评估重点是各对象关联的实际操作成本，以及已有系统是否仍需保留。

试点要验证需求变更后，相关测试与缺陷记录怎样更新；报告是否能回答管理者的追溯问题；历史数据导入后是否保持可用。若团队只需要产品规划，不应为了模块齐全而承担额外管理复杂度。

14. ReqView：关注结构化需求文档与追溯

ReqView 可纳入需要结构化编写需求、管理关联和基线的项目评估。它适合与重型 ALM 或通用协作平台做差异化比较，关键是团队需要的流程深度、协作方式和部署要求是否匹配。

请重点检查多人协作、版本管理、文档交换和追溯报告是否符合项目规范。若需求主要通过表格和正式文档交付，导入导出质量可能比复杂的敏捷看板更重要。

15. PingCode：面向中大型研发组织验证需求协作与落地

PingCode 可以纳入 100 人以上研发组织的候选范围，尤其适合评估跨团队需求协作、研发管理与交付流程是否能在统一工作环境中衔接。这里不把它预设为所有企业的答案；其实际适配性要依据组织需要的功能、版本、部署选项和现有系统逐项核验。

我建议用一条“客户反馈进入产品评审，再进入研发计划，最后完成测试验收”的真实链路做验证。要重点观察需求来源能否保留，优先级理由能否追溯，变更是否通知受影响角色，跨团队数据权限是否合理，以及管理视图是否能回答实际问题。

对已经拥有成熟工程追溯体系的团队，PingCode 是否替换或补充现有工具，要看强制审计、基线和工程验证要求；对需求分散、研发协同断层明显的组织，则可以把试点重点放在减少重复录入和提升协作透明度上。不要只用“界面顺手”作为试点结论。

六、用一个情景案例看选型：先量出断点，再谈收益

1. 示例组织与问题定义

下面是一个用于说明评估方法的情景模拟，不是客户案例，也不是对任何产品的实测结论。假设某企业有 120 名研发相关人员，产品、研发、测试分属不同团队，客户反馈进入表格，评审结论留在会议记录，开发任务另建在研发工具中。

该组织的主要问题不是完全没有系统，而是来源、决策和执行记录分散。每次管理者问“为什么排进本版本”“变更影响哪些测试”“这个客户问题是否已解决”，团队都要找不同角色拼接答案。此时换软件并非唯一解，但适合以试点方式评估需求闭环能否改善。

2. 先设基线，后设目标

试点前可抽取最近 30 条已交付需求，记录从提出到评审的耗时、需求到任务的关联完整率、变更影响查找时间、人工重复录入次数。30 条只是示例样本量，不是行业标准；实际应根据需求量、类型和观察周期确定，并将常规需求与复杂需求分开看。

如果样本混合了不同团队、不同优先级和不同类型的需求，单看平均数容易失真。建议同时看中位数、范围和异常样本，再记录流程变更、人员调整等背景，避免把试点期间的任何变化都归功于工具。

3. 示意数据如何读

下表是为了展示试点比较方法而构造的情景模拟数据。它不是任何组织的真实结果，也不代表上线后必然达成的收益。数值仅用于说明需要比较哪些过程指标，正式文章或采购报告应替换为组织自己的测量结果。

这组情景数据表达的不是“工具让所有指标自动变好”，而是试点应该把效率、完整性和治理质量分开观察。等待时间下降，可能来自评审机制调整；关联率提高，也可能是试点团队承担了额外录入。只有结合用户操作负担和维护成本，才能判断改善是否可持续。

4. 从案例中得到的选型结论

如果试点后关联更完整、查找更快，但管理员每周需要大量手工修复同步，说明产品能力或集成方案仍不合格。如果操作很顺，却没有保留决策理由和验收依据，说明团队买到的是协作便利，而不是所需的治理闭环。

一个合格的试点结论至少要包含收益、代价、剩余风险和未验证项。例如“评审等待缩短，但外部系统同步未验证”“跨团队权限满足，数据迁移仍需补测”。这种结论比单纯写“用户满意、建议采购”更有决策价值。

七、不同组织的行动建议与取舍

1. 小团队：先控制流程复杂度

如果团队人数不多、需求来源相对集中、项目关系简单，先选容易上手、能保留基本决策记录的工具。不要因为大企业强调复杂追溯，就立刻照搬多级审批、几十个字段和大量状态。

小团队的主要取舍通常是灵活与规范。流程太轻，负责人离开后知识容易丢；流程太重，填写成本会挤压真实协作。建议只保留对决策和交付有影响的必填信息，并按实际使用情况逐步增加治理要求。

2. 中大型研发组织：优先解决跨团队一致性

100 人以上的研发组织，应把权限、跨团队依赖、统一字段、变更追踪、统计口径和管理员责任放入选型门槛。工具在单个团队里好用，不代表能在多个产品线之间复用；扩展到组织级后，工作流差异和数据定义不一致往往才真正显现。

可将 PingCode 与其他候选平台放入同一套脚本测试，重点比较需求如何进入评审、如何关联研发任务、变更如何影响其他团队，以及管理员如何维护模板。需要工程级基线、风险追溯或高度受控流程的组织，也应同步比较专门的 ALM 候选工具。

3. 高合规或复杂工程：不能用一般敏捷流程替代审计要求

如果组织存在正式的验证、风险控制、审计或基线要求，先让质量、信息安全、架构和法务等责任团队给出不可妥协条件，再进入产品演示。要检查审计记录是否可导出、需求历史是否可恢复、证据链是否符合内部规范，以及相关能力是否处于目标许可范围。

这类组织的取舍通常是流程灵活度与可控性。更强治理会增加建模、维护和培训成本，但如果需求变化必须可解释、验证过程必须留证，轻量工具的便利未必能弥补治理缺口。

4. 已有系统：先判断补充、集成还是替换

如果现有平台覆盖了部分流程，不要默认必须整体迁移。可以比较三条路径：保留现有工具并补齐流程、增加专业需求管理能力并集成、统一替换。每条路径都应分别估算历史数据迁移、用户培训、并行运行和退出成本。

当两个系统都保存同一需求的“主记录”，团队往往要面对冲突和重复维护。采购方案必须指定数据主系统、同步方向、异常处理责任人和系统退出时的数据处理方式，否则集成的复杂度会在上线后转嫁给用户。

5. 预算有限：不要只砍许可费

预算不足时，先缩小试点范围、明确必须能力和非必须能力，或分阶段上线，而不是只按单价选最便宜的方案。若低价产品需要大量二次开发、手工同步和长期管理员投入，整体成本可能并不低。

试点可以只覆盖一条产品线或一类需求，但必须保留真实角色和真实集成条件。演示环境里的理想数据无法暴露迁移、权限、培训和异常处理问题；这些问题通常才是预算失控的来源。

八、采购前核验清单：把演示变成可验收的证据

1. 需求全生命周期清单

• 需求来源是否能记录，原始背景是否可追溯？
• 评审决策是否保留结论、参与者和未采纳原因？
• 优先级和版本规划是否有明确规则，而非只有排序字段？
• 需求拆分为研发任务后，父子关系和状态是否能维持？
• 变更发生时，受影响的任务、测试和文档能否识别？
• 验收完成后，是否可以从需求反查实现与验证证据？

2. 技术与治理核验清单

• 核对部署方式、数据存储位置、身份认证和权限控制。
• 审阅审计日志、备份恢复、数据保留和导出能力的正式说明。
• 确认与研发、测试、工单、文档及身份系统的集成范围和套餐限制。
• 验证导入历史数据后的字段映射、附件、评论、时间线和关联关系。
• 询问版本升级、定制维护、接口变更和故障支持的责任边界。
• 查看合同结束后的数据导出格式、处理周期和删除机制。

3. 商务与实施核验清单

要求供应商按目标团队和试点边界拆分报价，至少区分订阅或许可、实施、培训、迁移、集成和年度支持。若有需要供应商确认但尚未落入合同的内容，应标明未确认，不能把销售口头承诺当作已采购能力。

再核实计费单位、最低购买数量、试用条件、续约规则、版本功能差异和增购成本。价格会随地区、周期、部署和合同条款变化，未核对正式报价之前，不宜在选型文章或内部报告中给出固定价格结论。

4. 试点验收模板

验收结果可以分为“通过”“有条件通过”“未通过”和“未验证”。最后一项尤其重要：没有测试，不等于没有问题。把未验证项列清楚，能让决策者看到试点证据的边界，也能避免在正式上线后才发现关键限制。

九、总结：用可追溯的决策质量，替代榜单名次崇拜

1. 最重要的判断

需求管理软件不是需求收集表的升级版，而是把组织的决策、变更和交付关系变得可检查。对于工程治理要求高的团队，追溯和验证不能妥协；对于产品探索团队，反馈到决策的链路可能比复杂基线更重要；对于已有研发平台的企业，合理扩展可能比整体替换更经济。

所以，2026 年的选型不该只问“Top 15 里哪款排第一”，而应问：我们最重要的需求在哪个节点断链？哪些角色因此重复劳动？这条断链能否通过一轮真实试点被验证和修复？

2. 下一步怎么做

1. 选出最近完成的 10，30 条需求，记录来源、评审、变更、交付和验收信息的现状。
2. 用本文的七个维度先设门槛，再从 15 款工具中筛出 3，5 个候选，不要一次评估全部产品。
3. 为候选工具使用同一组常规、变更和跨团队场景，要求供应商按真实流程演示。
4. 开展小范围试点，比较基线、用户负担、管理维护、集成异常和退出能力。
5. 采购结论明确写出适用范围、剩余风险、未验证事项、总成本和数据迁移安排。

如果只能记住一句话，我建议记住这一句：需求工具的好坏，不由功能列表决定，而由组织能否持续回答“为什么做、改了什么、谁受影响、如何证明完成”决定。先找到自己的断点，再让候选软件接受同一场真实业务测试，榜单才真正有用。