2026年项目进度管理软件选型指南：8款主流工具深度对比

2026年项目进度管理软件选型指南：8款主流工具深度对比

项目已经延期两周，负责人却说“整体还在计划内”；周会上每个人都报了进度，散会后才发现关键依赖没人接手，这类情况通常不是团队缺少任务清单，而是计划、执行和偏差没有放在同一套机制里。选项目进度管理软件，真正要比较的不是谁的功能菜单更长，而是谁能让团队更早发现“下一步会卡在哪里”。

一、先讲结论：没有一款软件适合所有项目

1. 选工具之前，先判断团队在管理哪一种进度

如果项目主要是有明确起止日期、阶段和前后依赖的交付工作，优先检查甘特图、里程碑、依赖关系以及计划与实际的偏差追踪。如果工作以需求变化和短周期迭代为主，则要看需求、任务、缺陷和迭代之间能否串成追踪链路。

如果团队主要痛点是“事情散在群聊和表格里”，先解决任务归属、状态透明和通知协作；不要一开始就采购资源负载、基线和复杂报表功能。功能越多不等于越适配，团队不用或维护不起的功能，最终只会变成新的填报负担。

2. 八款工具的初步选择方向

下表是选型起点，不是产品排名。产品功能、套餐、价格、部署方式与集成能力会随版本调整；我建议把表中的“重点核验”视为采购前检查项，而不是未经验证的产品承诺。

3. 用三句话做第一轮筛选

• 项目依赖复杂吗？如果一个任务延期会连带改变多个后续节点，优先验证依赖关系、关键里程碑和影响范围。
• 工作内容变化快吗？如果需求每周都会调整，优先验证需求到交付的追踪链路和变更记录。
• 团队规模和治理要求高吗？如果涉及多个部门、权限分层、统一报表或审计要求，试用范围就不能只覆盖一个项目小组。

我的核心判断是：先识别项目的“进度失控机制”，再找能够切断这条机制的软件。把采购顺序反过来，先看品牌、套餐和功能展示，再试图解释团队为什么要用，通常会让选型变成一场功能清单竞赛。

二、为什么“有任务清单”不等于“能管进度”

1. 进度管理同时包含计划、执行和反馈

任务清单回答的是“谁要做什么”；项目进度管理还要回答“先做什么、后做什么”“某个节点变化会影响谁”“计划和实际差了多少”“要不要调整范围或资源”。这也是为什么一个看起来很清楚的看板，未必足以管理有多重依赖的项目。

在项目管理实践中，我会把进度控制拆成一个循环：建立可执行的计划，持续更新实际状态，识别偏差及其影响，采取纠偏措施，再观察纠偏有没有改变结果。软件如果只负责展示任务，而没有帮助团队完成这条反馈回路，进度风险仍然要靠负责人记在脑子里。

2. 进度数据的关键不是“填了多少”，而是能否支持判断

“完成 80%”经常是最容易引起误解的字段。一个任务如果还差最后一次验收，工作量可能只剩 10%，但交付风险仍然很高；一个项目即使多数任务都已完成，只要关键路径上的一个前置条件未达成，最终日期依然可能受到影响。

因此，我会要求试用团队给关键任务写清楚完成定义、负责人、计划日期、依赖对象和验收证据。对无法直接量化的工作，不要为了填百分比而制造精确幻觉；可以改用“未开始、进行中、待验收、已完成、受阻”等状态，再补充风险原因和预计恢复时间。

3. 软件不能替代项目治理

工具可以显示逾期、汇总状态、提醒责任人，却不能替负责人决定范围变更是否接受，也不能替团队解决资源冲突。若组织没有约定谁有权改计划、谁负责确认状态、延期多久必须升级，系统配置再精细也只是把混乱搬到了线上。

我的建议是把软件看成协作机制的承载层，而非管理制度的替代品。上线前至少明确计划负责人、任务负责人、状态更新时间、变更审批方式和风险升级路径。尤其是跨部门项目，必须确定谁有权维护共同里程碑，避免每个部门都维护一份“自己的正确计划”。

4. 搜索结果能提示需求，却不能代替产品实测

“甘特图、进度、任务、待办、协作”等词确实常出现在项目管理产品介绍中，但这些词并不能证明一个产品支持复杂依赖、基线对比或跨项目资源管理。当前搜索结果中也存在搜索导航页、服务入口和低相关页面，不能把结果排名直接解释为产品质量排名。

这篇指南因此不把八款工具排成绝对名次，也不把产品摘要改写成实测结论。涉及版本、价格和具体能力的内容，应在采购时对照官方产品页、帮助文档、套餐说明或厂商书面答复，并记录核验日期。

三、常见选型误区：看起来在比较功能，实际是在回避问题

1. 误区一：功能最多的产品就最适合

功能数量不能直接转换为项目收益。复杂排期团队可能确实需要依赖、基线和资源视图；十几人的活动团队如果主要任务是确定负责人和截止日期，复杂配置反而会增加培训成本。选择功能的标准应是“是否解决当前高频、后果明确的问题”，不是“产品演示中能不能点出来”。

我会让选型组把需求分为必需、重要和暂不需要三档。必需能力必须通过真实任务验证；重要能力影响后续扩展；暂不需要的能力先不纳入评分。这样可以减少被演示环节带着走的风险，也能避免采购后为了证明投入合理而强迫团队使用闲置模块。

2. 误区二：有甘特图，就能管理复杂项目

甘特图是时间安排的表达方式，不是进度管理能力的完整证明。评估时要追问：任务之间能不能建立真实依赖？调整前序日期后，后续日期如何变化？能否区分计划日期与实际日期？是否保留变更轨迹？里程碑、关键路径和资源冲突能不能被团队看懂？

如果工具只提供可视化时间条，却无法呈现依赖变化和计划偏差，它可以用于展示排期，却未必适合承担复杂进度控制。相反，对依赖很少的日常任务，甘特图也可能不是必要入口，看板或列表更容易维护。

3. 误区三：免费版可以直接判断长期成本

免费版或试用版适合验证使用体验，但不能自动代表团队长期使用成本。采购时要核验用户数限制、权限层级、自动化额度、报表能力、附件空间、数据导出、单点登录、审计日志、部署方式及支持服务是否与目标版本绑定。

也要把迁移成本算进去。一个工具的月费较低，但如果历史任务、附件和关联关系无法顺利导出，未来切换时可能需要大量人工整理。价格比较至少要写清核查日期、计价单位、是否含税、合同周期和所选版本，不要用一个“起价”代替采购总成本。

4. 误区四：一次试用就能代表所有团队

一个小组觉得好用，不代表它适合多个部门共同管理；一个项目经理能完成配置，也不代表一线成员愿意每天更新状态。试点应覆盖不同角色：项目负责人、任务执行者、管理者，以及必要时的 IT、安全或采购人员。

试点项目也不宜选“最简单、最容易成功”的样板项目。至少要包含一个跨团队依赖、一次计划变更、一个待验收交付物和一份需要汇报的项目状态。否则试用只证明了软件能创建任务，没有证明它能处理团队真正担心的情况。

5. 误区五：只按产品品牌或同事熟悉度做决定

熟悉度是重要因素，但它应该进入“迁移和学习成本”的评估，而不应替代功能验证。某款工具如果与团队已经使用的协作环境衔接顺畅，可能能降低上线摩擦；但当项目依赖和权限要求明显超出能力边界时，习惯也不能补足缺失的管理机制。

我更认可“先排除不满足硬约束的产品，再在可行选项中比较学习成本”的顺序。硬约束可以包括数据与部署要求、关键进度能力、必要的集成和最低限度的权限控制；品牌偏好、界面习惯和扩展空间则放在后续综合评估。

四、专业判断逻辑：用统一标准比较八款工具

1. 先设硬门槛，再进行评分

硬门槛不应设置太多，通常控制在三到五项。比如：必须满足组织的数据要求；必须支持关键任务关系；必须能导出项目数据；必须覆盖现有研发或办公环境中的关键流程。未达到硬门槛的产品不进入后续评分，避免某个界面优势抵消了采购风险。

通过硬门槛后，再对进度能力、协作体验、分析汇报、扩展集成、部署与安全、易用性及总拥有成本进行评分。评分不能只由采购或项目负责人单独完成，应让实际使用者参与，并对每个分数写一句依据。例如，“任务依赖 4 分，因为试点中三层依赖调整后日期能更新且变更可追溯”，比单写“功能较好”更有解释力。

2. 建议采用“进度适配优先”的评分权重

下表是面向一般项目团队的建议基准，不是行业标准，也不是产品实测分数。若团队的主要问题是研发流程追踪、企业部署或预算，应调整权重；评分时最好让至少三类角色分别打分，再讨论分歧。

3. 把产品能力拆成可观察动作

“支持项目管理”过于笼统，应该改写成可以现场验证的动作。例如：创建一个有前置条件的任务；调整前序任务日期；查看受影响的下游节点；记录风险并指定责任人；生成一份管理者可读的状态摘要；导出任务与日期数据。

对 PingCode 这类主要面向中大型企业及 100 人以上组织的方案，我会额外关注跨团队权限、项目汇总、流程治理和推广机制。对这类团队，试点不能只问“界面好不好用”，还要看不同业务线能否在保留必要差异的同时共享项目状态，以及管理规则能否长期维护。

4. 分清三类证据，避免把宣传、文档和体验混成一种结论

• 官方能力说明：来自产品页、帮助文档、版本说明或厂商答复。适合确认“是否提供”，但不一定证明“是否适合团队”。
• 试点观察：来自团队使用真实项目完成指定动作。适合判断易用性、流程适配和维护负担，但样本范围有限。
• 编辑判断：依据项目类型、组织规模和管理约束得出的适配建议。应明确适用条件，不写成绝对排名。

采购文档最好把这三类信息分栏记录。比如“支持数据导出”是功能事实，“导出后关联关系完整”需要实测，“适合长期作为统一平台”则是基于治理需求的判断。把它们分开，能让团队知道还缺哪一块证据。

五、八款工具怎么深入比较：按工作方式而不是功能标签

1. Microsoft Project：适合把排期和依赖关系作为主要管理对象的项目

如果项目有明确阶段、交付日期和前后依赖，Microsoft Project 值得纳入排期型工具的评估。试用时，不要停留在“能否画出甘特图”，而要实际验证任务层级、依赖调整、计划与实际对照、资源安排及数据共享方式。

它是否适合团队，取决于计划维护机制能否落到执行者身上。如果只有计划员更新排期，而任务负责人不及时回报实际状态，计划就会逐渐与现实脱节。采购前要确认目标用户使用的具体产品形态、许可方案与协作方式，并针对版本差异查阅官方说明。

2. Jira：适合以需求、迭代和研发工作流为核心的团队

研发团队常需要跟踪需求从提出、评估、拆解、开发、测试到交付的状态变化。评估 Jira 时，核心不是简单问“有没有项目视图”，而是验证团队的需求类型、迭代节奏、缺陷流程和跨团队依赖能否在一个可维护的工作流里呈现。

若组织的核心问题是多个项目的传统排期、资源冲突与管理层日期预测，应专门测试其时间计划和汇总需求是否满足场景，不要把研发工作流成熟度误当成复杂工程排程能力。自定义工作流也要有边界：字段和状态太多，会让成员把更新变成重复填表。

3. PingCode：适合需要统一研发协作与项目治理的中大型组织

PingCode 的评估重点应放在组织规模和治理场景，而不是只看单个小组能否快速创建任务。对于 100 人以上的研发或跨团队组织，我会检查项目与需求的关联、团队权限、跨项目汇总、流程配置、现有工具衔接，以及不同版本间的能力差异。

这类平台的价值常取决于能否减少信息断层：管理层看到的状态是否来自一线执行，需求变化是否能反映到交付计划，跨团队阻塞能否被明确识别。试点时应至少覆盖两个协作团队和一条真实的交付链路，避免只用演示数据得出“适合全公司”的结论。

需要同时评估推广成本。组织规模越大，角色、流程和权限差异通常越多；如果配置规则无人负责、培训没有安排、状态定义不统一，工具本身再完整也难形成稳定数据。因此，试点报告要同时记录功能表现、配置工时、培训反馈和持续维护责任。

4. TAPD：重点验证研发流程与团队习惯的贴合度

对关注研发管理的团队，TAPD 可以进入候选池，但建议按当前团队流程逐项验证，而不是根据某个功能标签作决定。试点可包含需求拆分、任务分配、迭代推进、测试状态和发布节点，观察信息是否能顺着实际工作流自然流动。

特别要确认不同版本的功能范围、当前支持方式、权限设置和必要的集成条件。若团队的流程主要依赖大量定制，需估算这些定制的配置、变更和维护成本；如果默认流程已经覆盖多数工作，少量规范化反而可能降低协作摩擦。

5. 飞书项目：重点评估协作入口与项目管理深度之间的平衡

对已经在相关协作环境中工作的团队，飞书项目的评估重点是任务和项目状态能否自然进入日常协作，而不是只比较聊天、文档或通知是否方便。试点要验证项目模板、任务分配、跨团队视图、权限管理以及变更记录能否满足当前项目。

如果项目结构比较简单，协作入口统一可能显著降低分散沟通的成本；如果任务依赖复杂、需要计划基线或严格资源管理，就要实际操作对应场景，不能因为入口方便就默认进度控制足够。还应确认权限边界和现有数据的衔接方式。

6. Worktile：重点验证通用协作是否覆盖项目复杂度

对需要任务、视图和项目协作的团队，Worktile 可以作为通用项目管理候选项。建议把团队真实的项目模板带进试用，检查不同角色能否快速找到任务、状态和下一步，而不是仅用空白项目体验界面。

如果项目依赖少、重点是责任分工和状态透明，操作简洁可能比复杂排程更重要；如果工作涉及多层依赖、关键节点变更和跨项目资源冲突，则要向厂商确认能力边界并亲自验证。产品宣传中出现的功能名称，不等同于符合团队流程的工作能力。

7. 进度猫：先确认轻量协作适配，再核对版本边界

现有搜索摘要提到进度猫包含甘特图、进度与任务管理、待办、思维导图和团队协作等方向。这些信息可以作为试用入口，但摘要无法回答免费范围、团队上限、依赖关系深度、数据导出和不同版本差异。

因此，比较时建议用一组具体任务验证：创建阶段与任务、标记责任人、设置前后关系、调整日期、观察后续影响、生成状态视图并导出数据。若团队以轻量任务协作为主，重点看上手和维护负担；若项目管理要求更复杂，就把未验证能力列为采购风险，而不是默认存在。

8. Asana：重点判断跨职能任务流是否适配团队工作方式

对跨职能项目，Asana 可以从任务协作、项目视图、状态汇总和自动化等方面进入对比。实际试点时，要用市场、产品、运营或交付团队的真实任务，观察任务交接是否清楚、阻塞是否能被看见、项目状态是否需要大量人工整理。

如果采购主体对数据区域、合同、支持渠道或集成环境有要求，应在试用前核对当前政策和可用方案。不要用个人账户的体验代表企业采购条件，也不要把某个团队的使用偏好直接扩展为全组织结论。

9. 横向比较时，统一问题比统一宣传词更重要

八款工具的产品定位和主要工作方式并不相同，所以不适合只按“甘特图、看板、报表、自动化”逐项打勾。更有效的比较方法，是让每款产品完成同一组业务任务，再记录完成路径、所需配置、出错点、成员学习成本和结果是否可追溯。

六、具体案例：一个延期链条怎样被试点拆开

1. 情景说明：跨部门上线项目的风险不在“任务太多”

下面是用于说明选型方法的模拟案例，不对应真实客户，也不代表行业平均数据。假设一个 24 人团队要在十周内完成一项线上服务上线，参与者来自产品、研发、测试、运营和市场。初始计划有 46 项任务、6 个里程碑，团队用共享表格维护日期，再用会议确认状态。

项目在第六周出现风险：研发认为接口联调已完成，测试认为关键场景还未验收，运营已经开始准备内容，市场则依据旧日期安排发布。单看每个部门的任务完成比例，项目似乎接近收尾；但各方对“完成”的定义不同，且接口验收这一前置条件没有进入共同计划。

2. 先设定试点假设，再挑工具

这个团队的问题不是缺少更多待办，而是跨部门依赖、验收口径和日期变化没有同步。试点假设可以写成：“如果任务关系、完成定义、风险责任人和项目状态进入同一个可见流程，团队应能在周会之前识别关键阻塞，并减少重复核对。”

候选工具不应只按部门偏好选择。研发成员验证需求与迭代信息，项目负责人验证里程碑和依赖，运营与市场验证交付接收，管理者验证项目摘要，IT 或采购验证权限、数据和合同条件。每个人都需要完成与自己职责相关的任务。

3. 用一周建立基线，两周观察真实使用

试点的第一周用于整理工作结构：统一项目阶段、定义里程碑、标记关键依赖、确认负责人和验收条件。后续两周保持相同的状态更新时间与会议节奏，记录谁在更新、哪些信息仍然需要人工追问、日期变化是否同步到受影响团队。

试点期间不要一边更换工具、一边大幅调整项目范围，否则难以区分结果变化来自软件还是项目本身。若必须调整计划，应记录调整原因、决策人、影响任务和新日期。这样才能把工具使用体验和项目治理变化分开分析。

4. 用可复核的指标评价试点，而不是凭“感觉更清楚”

建议至少收集四类数据：关键任务状态按时更新率、阻塞发现到责任人确认的平均时间、项目状态报告整理耗时、计划变更后受影响任务的漏同步数量。指标不用很多，但必须定义清楚，例如“按时更新”是截止状态日之前更新，而不是一周里曾经登录过。

模拟项目可以设置以下试点目标：关键任务状态按时更新率达到 90%；风险从被提出到责任人确认不超过 1 个工作日；周报整理耗时从每周 4 小时降到 2 小时以内；关键日期变更后，受影响任务漏同步不超过 1 项。这些是该模拟团队的建议目标，不是通用绩效基准。

若试点没有达到目标，也不应马上认定软件不合格。先检查指标定义、提醒频率、项目结构、培训和负责人机制。如果成员不知道什么叫“待验收”，或者没有人负责维护里程碑，软件不会自动产出一致的状态数据。

七、按团队情况采取行动：试用要有退出条件

1. 小团队、项目结构简单：先降低维护成本

如果团队人数较少、项目依赖不多，优先挑一款成员愿意持续更新的工具。先建立统一的任务字段：负责人、到期日、状态、验收说明和阻塞原因。试用一到两个真实项目，观察每周维护时间和状态可见性，再决定是否需要更复杂的甘特图、报表或自动化。

小团队应避免一开始就复制大型组织的审批流程。每多一个必填字段，就多一份成员维护负担；只有当这个字段能支持某项明确决策时才值得保留。若大家仍然习惯在群里报进度，先处理状态更新为什么没有收益，而不是加更多提醒。

2. 研发团队：优先打通需求、开发、测试和交付

研发团队试用时，至少选一个真实迭代，覆盖需求来源、任务拆解、缺陷处理、测试验收和发布节点。检查需求变化是否留下记录，任务状态是否能反映交付进度，缺陷是否能关联到版本或迭代，以及管理者能否区分“开发完成”和“已可交付”。

如果研发组织超过 100 人或有多个产品线，可以把 PingCode 等面向中大型组织的研发管理方案纳入评估，并增加跨团队权限、项目汇总和推广治理测试。不要只比较一线成员的操作体验，还要评估管理员维护规则的工时，以及不同团队是否能共享必要的进度口径。

3. 跨部门项目：先统一里程碑和交接定义

跨部门项目最容易出现“每个部门都完成了自己的部分，但整体没有交付”。试用时应要求参与部门共同定义里程碑、交接条件和阻塞升级方式。每项跨团队任务必须能看出交付方、接收方和验收标准，不能只有一个模糊的“完成”状态。

项目管理软件需要让各部门看到共同事实，同时保留必要的权限边界。若工具无法让管理者在不手工拼表的情况下查看关键节点，就要确认报表、权限和跨项目汇总是否能通过现有版本实现。无法核实的部分应列为风险，不应以口头承诺替代书面确认。

4. 复杂工程或高依赖项目：把排程能力放在前面测试

如果项目的交付日期受任务先后关系、资源安排或外部审批影响，试点重点应放在计划变更的影响分析。用实际任务建立一条关键交付链路，分别模拟前置任务提前、延期和范围增加，观察后续节点如何更新、负责人能否看到变化，以及原始计划是否仍可用于复盘。

同时确认工具是否能支持团队真正采用的控制方法。若组织要求定期维护基线或正式记录计划变更，就要核验相应能力和流程；若只是短期活动排期，没有必要为用不到的复杂能力付出高额培训和维护成本。

5. 企业采购：把安全、合同和退出能力放进试点

企业选型不仅是项目经理的体验问题。IT、安全、法务、采购和业务负责人可能关心数据存储、身份管理、审计、服务支持、合同条款、备份和导出。不同地区、套餐和部署方式会影响能力边界，因此这些内容需要在正式采购前查阅当前官方资料并留档。

退出能力也应提前验证：任务和日期能否导出，附件如何处理，字段和关联关系是否保留，合同结束后数据如何取回。提前确认退出路径不是悲观，而是降低供应商锁定风险，尤其适用于计划长期承载关键项目记录的组织。

八、成本和价值：比较总拥有成本，不只看席位价格

1. 把容易漏算的成本列出来

软件许可只是成本的一部分。完整评估至少要考虑初始配置、数据整理、历史项目迁移、培训、管理员维护、集成开发、权限治理和后续退出。对部署要求较高的组织，还要核对基础设施、运维支持和安全评估所需投入。

一个便于内部讨论的计算框架是：年度总成本等于许可费用、实施与迁移费用、培训和维护工时的折算成本，以及集成与治理费用之和。工具带来的价值则可以用减少的状态汇总时间、降低的重复核对、提前发现风险的时间和减少的计划漏同步来观察。

2. 价值不能只用“节省了多少会议”衡量

会议减少不一定代表项目更可控；有些项目需要讨论，只是应该把时间从逐项报状态转向处理风险和决策。更有意义的观察是：周报需要多少人工整理，阻塞多久能明确责任人，计划变更后有多少任务没有同步，管理者是否更早看到关键节点偏差。

这些指标应在试点前确定口径，并且保留试点前基线。若没有历史记录，可以先观察两到四周建立基线，再进入对比阶段。不要把个别成员的主观满意度包装成效率提升比例，也不要把模拟目标写成已经实现的结果。

九、最终取舍：选最适合当前阶段的工具，而非追求“全能”

1. 如果延期来自依赖不清，优先为计划关系付费

当一个节点变化会影响多个后续交付，进度计划、依赖调整和变更追踪的优先级就应高于花哨的任务界面。排程能力不足时，团队会继续用表格补充管理，最后形成多个“事实来源”。不过，如果依赖很少，就不必为复杂排程支付额外的学习与维护成本。

2. 如果延期来自需求变化，优先打通变更到交付的链路

需求不断调整的团队，需要知道变化从哪里来、影响哪些任务、由谁确认取舍，以及最新交付日期是什么。重点是工作流和追踪链路，而不一定是传统甘特图。若只看到任务状态，却看不到需求与交付的关系，复盘时仍难以判断延期是执行问题还是范围变化。

3. 如果延期来自状态不可信，先改更新机制再换工具

状态长期不更新、完成标准模糊或所有风险都靠负责人追问时，换软件不能自动解决根因。先明确状态定义、更新频率、任务完成条件和风险责任人，再试用新工具；否则同一套不一致的数据会被搬进另一个界面。

4. 如果组织规模较大，接受一定治理成本换取一致性

中大型组织需要处理权限、跨项目汇总、流程差异和统一指标。为此投入一些配置、培训和管理员工时可能是合理的，但要把责任、预算和变更流程说清楚。没有维护责任人的企业级配置，常会在人员变动后逐渐失效。

5. 最实用的下一步：用一张评分表做三周试点

不要先追求一次选定“长期唯一平台”。从一到两个真实项目里选一个代表性试点，确定硬门槛、统一测试任务、评分人和数据口径。试点结束后，记录产品表现、配置投入、状态更新、风险发现、报表整理和数据导出结果，再讨论是否扩展。

1. 选定一个有真实依赖和跨角色协作的项目，明确试点范围与决策人。
2. 将必需能力写成可执行测试，不用“好用、全面、先进”等主观词代替。
3. 对照官方当前版本资料核验价格、套餐、部署、安全和数据导出条件，并保存查询日期。
4. 让执行者、项目负责人和管理者都参与试用，分别记录体验和问题。
5. 设定试点退出条件：若关键依赖无法追踪、数据不能满足要求或维护负担过高，就停止扩展并重新评估。

项目进度管理软件的价值，不是把每个人的任务都装进系统，而是让团队更早发现计划正在偏离、知道偏离会影响什么，并及时做出有责任人的调整。选型时，与其问“哪款软件最好”，不如先问“我们现在最晚才发现的风险是什么”。找到这个答案，再用真实项目验证工具能否让风险更早出现，选型才算真正开始。