2026年研发项目管理软件选型指南：7款企业级工具深度对比

2026年研发项目管理软件选型指南：7款企业级工具深度对比

研发团队买了项目管理软件，最常见的失败并不是功能太少，而是上线后需求在一个系统、代码在另一个系统、测试结果留在表格里，管理者仍要每周手工拼进度。选型时真正要比较的，不是产品页面上谁的功能清单更长，而是团队能否把需求、计划、开发、测试、发布和复盘连成一条可追溯的工作链。本文按统一维度讨论 Jira Software、Azure DevOps、PingCode、TAPD、飞书项目、GitLab 和 ClickUp，并说明哪些结论可从产品定位初筛，哪些必须通过试用或采购核实。

一、先给结论：选工具先看流程断点，不先看功能数量

1. 七款工具没有脱离场景的通用排名

我不建议把这七款产品排成“第一名到第七名”。它们的产品边界并不完全相同：有的以研发事项与敏捷协作为主，有的把代码仓库、持续集成和交付能力放在同一体系内，还有的更像企业协作平台中的项目管理模块。若不先说清楚“比较的是什么”，总分很容易把不同类别硬放在一起。

更实用的初筛方式，是先找出组织的不可妥协条件。若团队希望围绕研发过程管理需求、迭代、缺陷与交付，可以重点验证 Jira Software、PingCode、TAPD 等工具的流程适配；若现有工程体系大量使用微软开发工具链，应把 Azure DevOps 纳入优先验证；若代码托管和 CI/CD 是工作重心，应评估 GitLab 是否能覆盖足够多的项目协同需求；若项目工作分布在业务与研发团队之间，可将飞书项目、ClickUp 放入横向试用，但仍需检查研发专属流程是否够用。

这只是候选顺序，不是产品能力结论。具体功能、部署选项、授权方式和集成范围会随版本、合同和地区变化。本文不把厂商宣传页当作独立评测结果，也不提供未经核验的价格或性能排名。

2. 先筛硬约束，再谈体验优劣

企业选型中，部署、身份权限、安全要求、数据迁移、系统集成和服务保障常常是淘汰条件。一个操作体验很顺手的 SaaS 产品，如果不满足组织的部署约束，就不应进入最终体验评分；一个能够私有部署的产品，如果关键流程需要大量定制，也不能仅凭“可部署”就判为合适。

我建议把决策拆成两层：第一层是准入筛选，回答“能不能用”；第二层是情境试用，回答“用起来是否适合”。只有通过准入筛选的产品才参与后续打分，避免把硬性合规要求和界面偏好加权平均，最后得到一个看似精确、实际不可执行的总分。

• 准入条件：部署模式、数据边界、身份认证、权限与审计、合同要求、关键系统集成。
• 体验条件：需求拆解、计划调整、跨团队依赖、缺陷关联、报表可读性、日常维护负担。
• 落地条件：迁移周期、管理员投入、培训安排、历史数据处理、供应商支持和后续扩展成本。

3. 适合大多数团队的决策顺序

若目前尚未形成清晰标准，可以先按下面的次序组织评审。这样做的好处，是把“谁喜欢哪个产品”的讨论，转换为“哪些流程必须跑通、哪些条件不可妥协”的验证过程。

1. 列出当前工作流中的系统：需求、任务、代码、测试、缺陷、发布、知识文档和沟通工具。
2. 挑出最常发生的三类断点，例如需求无法追溯到版本、跨团队依赖没有负责人、发布状态需要人工汇总。
3. 把部署、安全、权限、审计和数据迁移要求写成准入清单。
4. 从候选工具中选出两至三款，使用同一组真实任务进行试用。
5. 记录配置与管理耗时、用户额外操作、数据可追溯性和流程例外处理能力。
6. 让研发、测试、项目管理、IT 与采购共同确认结果，最后比较总拥有成本而非只看许可费。

二、背景与真实场景：研发管理软件解决的不是“任务太多”

1. 从任务看板到研发工作链，问题发生在衔接处

团队常说“项目进度不透明”，但真正的原因往往不是缺少看板。看板能显示任务状态，却不一定说明一个需求对应哪些开发任务、测试用例、缺陷和发布版本；项目经理看到“进行中”，也未必能判断它是否被外部依赖卡住、是否有代码变更、是否已经进入测试。

因此，评估工具时要观察信息如何流动，而不能只看每个模块是否存在。需求、任务、缺陷和版本之间可以相互关联，管理者才有机会从项目状态追到执行事实；如果这些对象只能靠人工复制标题、粘贴链接或重复录入，表面上系统齐全，实际仍然是多个孤岛。

我会在试用中观察一个简单但很有区分度的动作：开发人员完成一项工作后，团队能否从需求记录中找到对应任务、代码变更、测试结果和交付状态。如果只能通过个人口头汇报补齐，工具还没有形成闭环。

2. 三类常见组织，卡点并不相同

（1）规模较小、协作链路较短的研发团队

小团队通常更在意上手速度和沟通成本。流程太重、字段太多、状态配置太复杂，容易让研发人员把系统当成“填表工具”。这类团队可以优先验证任务创建、迭代规划、缺陷跟踪、基本报表和常用研发工具集成，不必一开始就引入复杂的项目组合治理。

（2）多团队并行、依赖关系复杂的企业

当多个产品线共用平台、测试或基础设施资源时，难点会从“每个项目怎么排任务”变成“项目之间怎样看依赖、共享资源和风险”。此时要验证权限边界、跨项目查询、统一数据口径、阶段门禁与组合视图。单个团队觉得好用，不代表组织级推广后仍然可维护。

（3）工程工具链已经较完整的研发组织

如果团队已经使用代码仓库、构建、测试、制品管理和发布平台，新的项目管理工具必须说明它与现有链路如何连接。要问清集成是原生能力、官方连接器、第三方插件，还是需要接口开发；还要确认同步方向、失败重试、数据延迟、权限映射和后续维护责任。

3. 为什么“一个平台全包”不一定更省事

整合平台有机会减少工具切换，但也可能让团队为了迁就平台重做已有工程流程。反过来，专业工具组合看似更灵活，却可能产生重复录入、身份权限不一致和数据口径不统一。真正需要比较的不是系统数量，而是每条关键工作链的总摩擦。

在采购讨论中，我会把工具切换成本拆成四项：研发人员的额外操作、管理员的配置维护、集成接口的故障处理、管理者的汇总与解释。若某方案减少了两种工具，却让每位工程师多维护一份状态，它未必更轻。

三、拆解常见误区：功能表格很容易让采购判断失真

1. 误区一：功能越多，研发管理越成熟

产品列出需求、迭代、测试、报表、自动化等功能，并不能证明团队可以直接使用。功能是否可配置、不同角色是否能理解、多个项目是否能共用规则、后续是否需要管理员持续维护，都会影响落地效果。功能列表是“存在性证据”，不是“适配性证据”。

试用时，应挑一个当前真实存在的工作场景，而不是只浏览演示数据。例如，把一个有跨团队依赖的需求从创建一路推进到发布，观察人员要不要跳出系统补信息、状态是否需要重复录入、异常流程能否保留审计记录。

2. 误区二：有集成入口，就等于集成可用

产品页面上的“支持集成”可能指多种不同方式：内置连接、官方应用、第三方插件、开放接口或定制开发。它们在实施成本、数据同步质量和故障责任上差别很大。采购团队应确认连接范围，而不是只记录一个“支持/不支持”。

• 是否能双向同步，还是只有单向推送？
• 同步的是状态、链接和负责人，还是包含关键字段及历史变更？
• 出现同步失败时是否有日志、重试和告警？
• 离职人员、权限变更和项目归档如何处理？
• 连接器由谁维护，升级后是否可能失效？

3. 误区三：项目经理觉得顺手，就代表团队会采用

项目经理、研发负责人和工程师观察工具的角度不同。管理者关注跨项目状态和风险，研发人员关心操作路径与上下文切换，测试人员关注用例、缺陷和版本关联，IT 关注身份、审计和部署。只让一种角色试用，很容易把局部体验误认为整体适配。

建议至少邀请四类角色参与试用：项目管理者、开发人员、测试人员和系统管理员。采购阶段还要让安全或 IT 负责人核实企业约束。试用记录也应按角色拆分，避免把“界面喜欢”与“流程能跑通”混成一个主观分数。

4. 误区四：只看账号单价，不算持续使用成本

企业项目的实际成本，通常不只由订阅或许可费用构成。实施、迁移、插件、接口开发、管理员时间、培训、数据保留和续约条款都可能影响总拥有成本。不同产品的计费单位、功能分层和部署报价可能不同，不能拿官网展示的单一数字做直接结论。

我建议把成本至少按三年观察，并由供应商逐项确认：基础授权、额外模块、存储或使用量、实施服务、定制与集成、升级维护、培训支持、数据导出和退出迁移。无法确认的项目应标记为“待报价”，而不是默认免费。

5. 误区五：试用账号能打开，就算完成试用

浅层试用通常只验证了登录、创建任务和查看页面。企业选型更需要覆盖真实流程、权限边界、数据导出、异常情况和管理员维护。建议试用前先写出验收任务，明确每个动作由谁完成、成功标准是什么、需要留下什么证据。

例如，不能只问“能不能做迭代计划”，还应验证计划临时变更后，任务、责任人、版本范围和管理视图如何同步。不能只问“有没有权限控制”，还应测试跨项目成员能否看到不该访问的数据、离职账号如何回收、审计记录能否查询。

四、专业判断逻辑：用同一套任务比较七款工具

1. 把“功能评估”变成可复现的任务测试

若想减少主观判断，七款工具应使用同一组测试任务。测试材料可以是一项真实需求、一个迭代计划、几条缺陷、一次跨团队依赖和一个待发布版本。数据不必庞大，但要包含正常路径和例外情况，比如需求变更、负责人调整、缺陷阻塞和延期风险。

1. 创建需求：记录目标、范围、验收条件、优先级和业务负责人。
2. 拆分计划：把需求拆成任务，分配负责人、时间和依赖关系。
3. 推进开发：关联代码变更或工程事项，并记录阻塞与状态变化。
4. 开展验证：把测试结果、缺陷和回归状态关联到需求或版本。
5. 完成交付：核对发布范围、遗留风险、审批记录和变更历史。
6. 复盘汇报：尝试从工具直接读取项目状态，记录仍需手工汇总的内容。

2. 评估指标不要只做加权总分

建议把指标分成“准入项”和“比较项”。准入项不参与平均分：不满足部署、安全或核心集成要求，就直接淘汰。比较项可采用分档评分，但应保留原始观察记录，避免小数点制造虚假的精确感。

3. 记录“额外操作率”，比记录功能数量更有用

试用中可以统计完成一条典型工作链需要跨越多少个系统、重复录入多少个字段、多少次状态需要人工同步。这些数据不是行业基准，却能帮助企业比较自己的候选产品。记录时要固定测试任务、角色、账号权限和试用时间，避免不同产品用不同难度的数据。

以下是一个可直接采用的内部记录口径：一次“额外操作”指为使信息在工具间保持一致而进行的重复输入、复制链接、手工更新状态或人工汇总。单纯点击导航不计入。这样可以避免把界面点击数误当成真实工作成本。

4. 通过“反向验收”发现隐藏成本

供应商演示通常展示顺畅路径，选型团队却需要验证失败时会怎样。反向验收的核心，是故意设置常见异常：需求中途变更、人员离开项目、集成暂时失败、缺陷无法按期修复、版本回滚、权限被收回。观察系统能否留下清楚的责任、时间和状态记录。

还要从退出角度检查数据可携带性。试用前询问能导出哪些对象、字段、附件和历史记录，导出是否包含关联关系，若停止使用如何完成迁移。工具选型不仅是“怎么开始”，也包括“将来如何调整”。

五、七款工具深度对比：先看定位，再核实实际适配

1. Jira Software：适合验证复杂事项管理与敏捷流程需求

Jira Software 常被纳入研发团队的候选清单，主要因为它属于面向软件团队的项目与事项管理工具。评估时，应重点查看工作项类型、流程状态、迭代计划、权限、报表与现有开发工具的连接方式。它是否适合某个组织，不能只由“支持敏捷”这一标签决定。

需要重点验证的是配置治理。流程、字段和工作项类型的灵活性，可能帮助不同团队表达各自工作方式；也可能让组织逐渐积累多套相似流程，导致报表口径分裂。应安排管理员评估长期维护责任，并确认目标版本、部署方式和可用功能，而不是默认不同版本能力完全一致。

• 优先试用：团队需要较细的事项流程、迭代管理或跨项目协作。
• 主要核查：配置复杂度、管理权限、第三方扩展治理和跨项目数据口径。
• 不宜直接假设：任何插件都能长期稳定使用，或所有流程变更都不需要管理员投入。

2. Azure DevOps：适合把项目管理放进微软工程链路一起评估

Azure DevOps 更适合放在现有开发环境中整体观察，而不是只比较其工作项界面。若团队已经使用微软相关开发工具，应核对项目计划、代码、构建、测试和发布能力之间的连接边界，判断是否能减少上下文切换，或只是把现有工具迁入一个新入口。

企业还应核实授权、组织结构、身份与权限策略，以及目前采用的功能组合是否满足目标流程。不同组织的微软技术栈、账号体系和工程实践差异很大，不能因为“同属一个生态”就假定集成无需配置或不产生维护成本。

• 优先试用：现有工程链路与微软工具结合较深的团队。
• 主要核查：工作项、代码、流水线、测试与权限是否按团队实际方式衔接。
• 不宜直接假设：使用单一供应商生态就能自动满足所有治理和数据要求。

3. PingCode：适合中大型组织重点验证研发过程管理与协作适配

PingCode 面向研发管理场景，尤其适合中大型企业及 100 人以上组织将其纳入正式评估。对这类团队，我会优先检查需求管理、计划与迭代、缺陷和测试协作、跨团队状态查看，以及权限和管理口径是否能覆盖实际组织结构。具体模块、部署方案、集成范围与价格仍应以当前官方资料和采购确认结果为准。

试用时不要停留在“能创建项目、能分任务”。应选一条跨角色流程，要求产品演示从需求到交付的关联与状态流转，再让研发、测试和项目管理人员分别完成自己的操作。若企业已有代码仓库、测试平台或身份系统，应逐项验证接口能力、同步范围和责任边界。

对于百人以上组织，推广成本不只在软件设置上，还包含流程标准化和团队采用。建议先选一个业务边界清楚、存在真实协作问题的团队做试点，形成字段、状态、权限和报表模板，再决定是否复制到其他团队。不要在试点前就要求所有团队使用同一套过度细化的流程。

• 优先试用：组织需要评估研发过程协同，并且多个角色或团队之间存在信息断点。
• 主要核查：目标版本的功能范围、部署与安全条件、已有工具集成、管理员维护方式。
• 建议验证：从需求到发布的完整链路、项目间协作、报表口径和数据导出。

4. TAPD：适合验证团队对敏捷研发与协作流程的实际需求

TAPD 可以作为研发团队项目协作与过程管理的候选工具进行评估。关键问题不是它是否提供某项常见敏捷能力，而是现有团队是否能用较少的流程摩擦把需求、迭代、缺陷和团队沟通接起来。实际覆盖范围应按当前版本及采购方案逐项核验。

如果团队正在从分散表格转向系统化管理，应重点观察默认流程是否容易理解、流程配置是否足够灵活、数据能否支撑团队复盘。如果组织已有复杂的多项目治理要求，则应测试跨项目查询、角色权限和统一报表，而不要仅凭单团队演示结果做全企业决定。

5. 飞书项目：适合评估研发与业务协作是否能在同一工作空间衔接

飞书项目值得业务与研发协同频繁的组织纳入候选，因为选型关注点不仅是项目模块本身，还包括它与团队现有协作方式如何配合。试用时应查看任务、项目动态、文档、沟通与通知是否真正减少切换，以及研发管理所需的字段、依赖、迭代和权限是否足够清晰。

如果团队需要较细的工程生命周期治理，应确认产品是否覆盖所需工作对象，或需要与其他工程工具组合使用。组合使用不是缺点，但要明确哪些数据是主数据、哪些系统负责状态更新，避免同一任务在两个系统里各有一份“最终状态”。

6. GitLab：适合评估以代码协作和交付流程为中心的团队需求

GitLab 的评估重点应放在代码协作、开发流程与交付能力如何与项目事项衔接。对代码仓库和流水线已经是工作核心的团队，它可能适合纳入工程链路整体比较；但团队仍需确认其项目管理能力是否覆盖需求规划、跨团队组合视图、项目治理和管理报表等实际要求。

如果企业需要更强的项目组合或业务侧协作，不能只因为代码与流水线在同一平台，就假定全部项目管理问题也能解决。应把工程事项、计划管理和组织级治理分别验收；若需要额外工具补位，要在成本表中纳入接口、维护和重复录入的影响。

7. ClickUp：适合评估跨职能工作管理与研发需求的兼容程度

ClickUp 可以作为跨职能项目协作的候选方案之一。组织应测试其工作结构和视图能否满足研发项目实际需要，并核对团队是否能在不堆叠大量定制的前提下管理需求、任务、负责人、时间和依赖关系。对研发团队来说，通用项目管理体验好，并不自动意味着测试、缺陷、版本与工程集成也足够。

若一个企业同时有产品、市场、运营和研发项目，统一工作空间可能带来协作便利；但角色、字段和状态过度通用，也可能削弱研发流程表达能力。建议让研发和非研发团队分别跑任务，再比较统一模板带来的协同收益与流程妥协。

8. 七款工具对照：用“待验证问题”替代未经核实的绝对结论

这张表用于缩小试用范围，不是能力评分表。表中每项都要求团队在当前版本、目标部署方式和实际流程下验证。若采购方案包含不同模块，需把验证结论绑定到具体方案，避免把一种版本的体验迁移到另一种合同配置上。

六、具体试点怎么做：用两周验证流程，不用两周开会

1. 试点前先定义“成功”的可观察标准

试点开始前，先选出一条具有代表性的研发链路，并设定成功标准。标准应描述可观察行为，例如“从需求记录能找到对应版本与验证结果”“跨团队阻塞有负责人和更新时间”“每周项目状态汇总可从系统生成”。不要写“体验好”“效率提升明显”这类无法复核的目标。

建议选一个规模适中的团队作为试点：既要有真实协作，不要小到只有一名负责人；也不要把全公司最复杂的组织结构一次性放进去。试点要覆盖研发、测试和项目管理角色，安排一名管理员记录配置投入，同时指定一名业务负责人收集意见。

2. 试点安排可以按四个阶段推进

3. 试点中同时观察人和数据

工作流数据能显示任务状态、逾期情况和交付记录，但不能单独解释采用障碍。试点期间要询问用户：哪一步最容易忘记更新？哪些字段没有决策价值？哪些内容仍然在聊天记录或表格里？管理员则要记录流程变更需要多少时间、权限问题如何处理、报表是否需要额外清洗。

如果团队表面上完成了任务迁移，但大家仍在旧表格里维护“真实进度”，说明工具尚未成为主要工作入口。反之，短期内任务完成率变慢，也不一定说明产品不适合，可能是流程设计或培训不足。需要结合操作记录、访谈和管理数据判断原因。

4. 试点结束后要做“停止、调整、扩围”三选一

试点不是为了证明采购正确。若工具满足核心流程但维护成本偏高，可以调整流程后再测；若关键部署或数据要求不满足，应停止推进；若真实任务跑通、用户采用稳定、管理员能够维护，才考虑扩围。把“不继续”视为有效结论，能避免沉没成本推动错误采购。

扩围前要明确模板治理：哪些字段统一、哪些流程允许团队自定义、谁能修改全局配置、报表指标由谁定义。缺少治理机制时，试点成功也可能在推广过程中变成多套流程并存，最后失去跨团队比较能力。

七、不同团队的行动建议与取舍

1. 小团队：优先减少维护负担，不追求一次建成完整治理体系

如果团队人数不多、流程简单，先检查基础协作是否足够顺畅：需求能否拆成任务、迭代是否易于调整、缺陷是否能关联到工作项、管理者能否看到必要状态。对小团队而言，管理员维护时间和日常录入负担，可能比高级报表或复杂组合管理更影响采用。

取舍上，可以接受部分管理能力暂时通过轻量流程补充，但不要接受核心信息需要长期重复录入。若候选产品必须配置大量字段才能跑通简单需求，应重新评估是否过度设计。

2. 百人以上研发组织：先解决口径与权限，再扩展看板

对于中大型企业及 100 人以上组织，优先验证统一项目视图、跨团队依赖、权限边界、数据留痕和管理员治理。PingCode 可以作为研发过程管理的重点候选之一，但仍应按具体部门的工程环境、部署约束与管理方式实测，不能仅凭产品定位直接决定采购。

这类组织的取舍重点，是标准化与团队自治之间的边界。统一核心对象和指标，有助于管理层跨项目观察；给团队保留少量流程差异，可以避免工具压平真实工作方式。建议先统一“项目、需求、缺陷、版本、风险”等关键对象，再决定哪些字段和状态必须一致。

3. 工程链路完整的团队：优先验证连接深度与故障处理

已有代码、构建、测试和发布系统的团队，应把“真实集成”作为首轮试用任务。确认状态如何同步、身份如何映射、历史数据是否保留、接口出错时谁负责。若候选工具无法可靠连接关键工程系统，团队就需要比较两种成本：开发和维护集成，还是接受多个工具并行。

取舍上，不必为了减少产品数量而强行合并所有能力。若现有工程工具成熟稳定，新平台负责计划和协作、工程平台负责代码与交付，只要主数据边界明确、关键记录可追溯，组合架构也可以合理。

4. 有私有化或合规要求的企业：把技术与合同条件前置

部署和数据要求应在产品演示前提供给供应商，避免评审团队先投入大量试用时间，最后才发现目标部署方式不适用。技术负责人需要核对身份、网络、备份、日志和数据保留；采购或法务需要确认授权边界、服务责任、退出与数据迁移条款。

取舍上，部署选择不是单纯的技术偏好。私有部署可能提高环境控制能力，也可能增加升级、运维和安全管理工作；SaaS 可能减少基础设施维护，但必须确认数据处理和服务条款符合组织要求。最终要比较组织实际承担的责任，而不是把某种部署方式简单视为优劣。

5. 跨职能项目较多的团队：看统一入口带来的收益是否大于流程妥协

研发与产品、运营、交付、客户成功之间协作频繁时，统一项目入口可能减少信息分散。试用中应分别让研发和业务角色完成任务，观察是否都能理解工作结构，是否需要在通用字段里塞入大量研发专属含义。

取舍上，如果业务协同收益明显，团队可以接受部分研发深度由专门工程工具承担；但需求、版本和责任人必须有明确的关联规则。否则统一入口只会变成新的汇总层，原系统仍保存真正的数据。

6. 不同情况的最终决策参考

八、采购前核查清单与结论：下一步不是看演示，而是跑一条真实链路

1. 要求供应商按你们的任务演示

演示前发出一份简短任务脚本：创建需求、拆分任务、调整迭代、关联缺陷、查看跨团队风险、验证权限并导出记录。不要接受完全由供应商控制的数据和流程演示。若某项能力无法在当前账号或版本中展示，应记录为“未验证”，后续以书面材料或实际试用确认。

2. 采购前逐项确认的信息

• 当前产品名称、版本、模块边界和适用授权方案。
• 目标部署方式、升级路径、数据备份、审计与身份认证能力。
• 代码、测试、文档、沟通和身份系统的连接方式与维护责任。
• 历史数据、附件、评论、关系字段和变更记录的迁移范围。
• 基础授权、实施、接口、定制、培训、支持和续约成本。
• 客户案例是否提供行业、使用范围、上线时间和可核实出处。
• 停止使用后的数据导出格式、服务期限和迁移协助条款。

3. 用小型评分卡收束决策

建议把每个候选工具的结论写成一页：准入项通过与否、真实流程测试结果、用户额外操作、管理员投入、集成风险、三年成本和未解决问题。若团队无法解释某个分数来自哪次测试或哪份资料，就先不要把它放进最终决策表。

4. 独特结论：选型真正比较的是组织能否维护这条工作链

研发项目管理软件不是一个看板，也不只是研发团队的任务清单。它是一套让需求、责任、工程活动和交付结果能够相互解释的工作机制。功能可以购买，流程却要由组织定义；系统可以上线，采用和治理仍要靠团队持续维护。

因此，七款工具之间最有价值的比较，不是“谁的功能最多”，而是“哪一款在你们现有约束下，能以较少重复操作和可接受的维护投入，支撑最重要的研发链路”。先写出不可妥协条件，再用同一组任务试用两至三款候选产品；把部署、集成、管理成本和数据退出路径一并核实。做完这一步，选择通常会比任何脱离场景的排行榜更可靠。

下一步可以先开一次不超过一小时的选型工作会：研发、测试、项目管理和 IT 各带来一个真实断点，合并成一条试用任务，再按本文清单确定准入项与记录口径。先验证工作流，再决定产品；先证明团队愿意用，再讨论全组织推广。