提升效率必备：2026年最值得投资的5大进度计划横道图软件推荐

选择进度计划横道图软件，最容易踩的坑不是买贵了，而是把“能画横道图”误当成“能管住进度”。我在做工具评估时，会先看计划能否随着任务依赖、责任人、资源冲突和实际进度持续更新，再看图表是否好看。下面这 5 款分别适合复杂排程、跨部门协作、快速上手、轻量团队和中大型组织；文中的成本与评分是选型模型或情景模拟，不是软件厂商报价，也不是行业抽样调查。

一、先讲结论：买的是一套进度管理方式，不是一张图

1. 五款软件，各自解决不同的麻烦

项目依赖复杂、需要严谨排程：优先评估 Microsoft Project。它适合任务关系多、基线和关键路径重要、项目经理需要精细控制计划的场景。需要接受的代价是学习门槛，以及组织既有办公环境和具体版本对协作方式的影响。

跨职能团队要共同维护计划：评估 Smartsheet。它将表格操作习惯和项目视图结合，适合希望让业务、运营和项目成员都参与更新的团队。选型时要重点核验自动化规则、权限颗粒度、报表能力与所购版本是否匹配。

想快速建立专业横道图、降低排程配置负担：评估 GanttPRO。它的产品定位围绕甘特图计划、任务依赖和团队协作，适合项目负责人希望尽快把计划结构化的情形。采购前要以真实项目验证导入、导出、资源管理和团队协作是否够用。

小团队希望快速看清任务和负责人：评估 TeamGantt。它适合重视视觉排程、希望迅速共享项目时间线的团队。若需要复杂的企业级审批、财务管理或多项目资源组合，建议先验证当前版本能力，不要只凭演示中的单项目界面判断。

中大型组织需要把计划放进研发或产品协作体系：评估 PingCode。它更适合把项目计划与需求、迭代、任务及团队协作衔接起来的组织，而不是只需要一个独立制图工具的个人用户。尤其是 100 人以上团队，应重点验证权限、项目模板、跨团队依赖和数据汇总能否承接实际治理规则。

我的排序方法不是给五款软件做一个脱离场景的“总冠军榜”。我会先判断项目是否有复杂依赖、多少人要更新计划、数据是否需要进入组织级流程，再决定候选工具。单纯按功能数量排名，往往会让小团队买到负担，也会让大组织低估协作成本。

2. 先用三个问题缩小候选名单

如果一项任务晚两天会自动影响后续节点，且项目经理必须知道哪些任务位于关键路径，那么计划逻辑比界面美观更重要。优先看依赖关系、基线、延期影响和实际进度更新，不要先被模板数量吸引。

如果计划需要由多个部门共同维护，核心问题是更新成本和责任可见性。应确认每个角色能否只看到或修改所需内容，任务变化能否通知相关成员，管理者能否快速发现逾期而不必逐行追问。

如果有多个项目争用同一批人力资源，单项目甘特图远远不够。要确认工具能否汇总资源负载、查看跨项目冲突，以及在一个项目调期后识别其他项目受影响的程度。

3. 购买前要验证的不是功能清单，而是失效场景

我建议用一个“会出错”的项目来试软件：放入十几个任务、三条跨部门依赖、一个资源冲突、两项已延期工作，再让不同角色分别更新。正常演示只能证明软件能显示计划，异常演练才能看出它能不能帮助团队处理计划变化。

如果供应商只演示新建任务、拖动条形和导出图片，而没有演示延期如何传导、谁能修改基线、任务状态如何汇总，就还不能证明它适合成为进度管理系统。选型应围绕变更处理能力，而不是截图效果。

二、为什么横道图经常“看上去很准，实际没人信”

1. 计划一旦脱离执行，就会变成装饰

横道图把任务和时间放在一张视图里，天然适合回答“什么时候开始、什么时候结束、哪些事情重叠”。但图表不会自动判断任务是否拆得合理，也不会替团队确认前置条件、负责人投入和验收标准。输入不真实，排得再整齐也只是漂亮的错觉。

实际工作中，我会把“计划可信度”拆成三个环节：任务定义是否可执行、依赖关系是否真实、进度反馈是否及时。任何一环缺失，图上的日期都可能只是管理者希望发生的日期，而不是团队能够交付的日期。

比如，一个“完成新功能”的任务跨越六周，没有设计评审、开发、联调和验收等可检查节点，负责人很难在中间阶段报告真实进展。图上看起来只有一根平滑长条，实际上进度风险被隐藏了五周。

2. 计划误差往往来自输入机制，而不是软件画法

我做工具筛选时，会留意计划数据怎么进入系统：由项目经理逐项录入，还是任务负责人直接更新；是否能从需求或工作项继承信息；延期原因是否要单独记录；会议纪要中的变更是否需要重复录入。录入链条越长，计划越容易在现实里落后。

假设 30 人团队每周花 10 分钟更新 20 个任务，仅任务维护就需要约 100 分钟；若还要由项目经理再花两小时核对、整理和制作汇报，成本会迅速转移到管理者身上。这个例子是时间预算推算，不是任何软件实测数据，目的是提醒采购方把“维护成本”纳入总成本。

3. 项目规模越大，计划视图越需要分层

十几个任务可以放在一个画面里，几百个任务同时展开则很难有效阅读。大型计划需要把项目阶段、交付物、团队任务和个人工作分层，让不同角色看到适合自己的信息。若软件只能把所有任务堆在一条时间线上，横道图会随着项目增长而变成滚动浏览的长清单。

中大型组织还需要区分“项目基线”和“当前预测”。前者用于回答最初承诺是什么，后者用于回答按当前信息预计何时完成。若团队把每次调整都直接覆盖原计划，最后就无法判断偏差来自估算失准、范围变化还是执行延迟。

4. 计划治理要解决的，是信息在团队间如何流动

项目经理关心关键路径和里程碑；任务负责人关心自己需要完成什么；部门负责人关心资源是否冲突；管理层关心项目是否可能影响季度目标。这些人不需要完全相同的视图，也不应通过同一张密密麻麻的总图来沟通。

因此，我会把工具评估从“有没有甘特图”转向“谁在什么时候用什么信息做决定”。如果工具只能展示进度，却不能明确谁更新、谁审批、谁收到风险提醒，团队仍然要靠会后追问补足流程。

三、五款软件逐一拆解：适合谁，购买前问什么

1. Microsoft Project：排程逻辑优先的项目经理工具

这类工具适合项目计划本身复杂、任务依赖密集、时间和资源冲突需要精细分析的团队。典型场景包括工程交付、设备部署、复杂产品发布和多阶段实施项目。项目经理需要的不只是把任务画成条，而是能理解前置任务变化后，哪些节点会被推迟。

它的优势在于传统计划管理方法成熟，适合管理大量任务关系和阶段节点。对于熟悉项目排程的人，任务层级、时间安排和依赖关系的表达更直接；但若团队成员没有计划管理经验，功能丰富也可能转化成设置负担。

购买前我会重点测试四件事：关键路径是否清晰；基线和实际日期能否并列比较；资源冲突如何发现；团队成员能否低成本反馈进度。还需要核对当前授权、桌面端和协作环境的具体组合，不同产品版本和组织配置可能带来不同体验。

一个常见误区是把“日期填得很细”理解为“预测准确”。如果任务估算没有依据，精确到小时的安排只会制造虚假的确定感。对不确定性较高的项目，先用阶段和交付物管理，再逐步细化近期工作，通常比一次性排满全周期更实用。

2. Smartsheet：表格习惯与协作视图之间的折中

Smartsheet适合已经大量使用表格管理项目，但希望增加视图、自动化和协作能力的团队。它的价值不是让所有人都学习一套复杂的排程术语，而是让习惯行列式工作的人更容易参与计划更新。

这种迁移方式尤其适用于运营计划、营销活动、内容排期、供应商跟进和跨部门交付。项目经理可以用结构化字段整理负责人、状态和日期，再通过不同视图服务于执行和汇报。不过，表格思维也有边界：字段多、规则多之后，用户可能需要经过培训才能理解哪些信息必须更新。

我会让测试团队用原有工作表做一次迁移，记录导入后的字段整理时间、关联关系丢失情况和权限配置步骤。再测试两个触发规则，例如任务逾期提醒和状态变化通知，观察是否能减少人工催办，而不是增加一堆没人维护的自动化。

采购时要区分“页面上能配置”与“组织中能持续运行”。跨部门权限、审批链路、自动化额度和报表能力可能受到版本限制。对于只用一张简单时间表的小团队，不一定需要为完整协作套件付费；对于多人维护多个计划的团队，则应核算统一模板和自动提醒能否减少重复劳动。

3. GanttPRO：更聚焦于快速建立甘特计划

GanttPRO的适用价值，在于团队明确需要甘特图作为主要工作界面，且希望较快建立任务、时间和依赖关系。它适合项目经理、实施团队或小型交付团队从零建立时间计划，再把计划共享给执行成员。

在试用时，我会避免只看默认模板，而是导入一个已有项目计划，观察任务层级、日期、责任人和依赖是否能保留。之后故意推迟一项前置任务，检查后续任务是否需要手动逐项调整，系统能否让影响范围一眼可见。

它的潜在短板不应通过产品介绍猜测，而要结合组织的治理要求实测。如果需要跨项目资源汇总、复杂审批、财务成本管理或与研发工作流深度连通，应该将这些需求列入验收清单。甘特图专注度高并不自动代表适合所有企业级流程。

对项目经理个人或小型交付团队，最重要的收益可能是减少制作计划和反复更新图表的时间。对有严格审计、审批和权限边界的组织，单一功能界面的顺手程度不能代替治理能力评估。

4. TeamGantt：轻量团队共享时间线的候选项

TeamGantt适合想让团队快速看懂项目时间线，并通过可视化方式协调任务的场景。小团队通常没有专职计划管理员，工具必须让新成员容易理解，否则计划会很快退化成项目负责人的个人文件。

它可以进入活动筹备、内容制作、客户交付和小型产品发布的候选清单。测试时应观察成员是否能清楚区分“任务还没开始”“正在进行”和“已经完成”，也要验证拖动日期后，团队如何收到变化信息。

如果团队已经发展到多个项目共享同一批专家资源，单独检查每个项目的甘特图可能无法发现资源过载。此时要问清楚工具能否在团队维度呈现分配情况，或是否需要通过外部系统补足。工具简单是优点，但简单界面也可能隐藏能力边界。

我不会因为项目规模小就默认不需要管理规则。相反，小团队常常只有一两位关键成员，一旦任务冲突，风险会直接影响整个交付。轻量软件同样需要明确任务负责人、验收条件和更新频率，只是这些规则可以保持简洁。

5. PingCode：让计划和研发协作发生关联

PingCode更适合研发、产品和技术交付团队把项目计划与需求、迭代、任务和团队协作联系起来。若团队的主要问题不是缺少画图能力，而是需求变更、开发工作和项目节点分散在不同地方，那么一体化工作流可能比单独增加一款制图工具更有价值。

对于 100 人以上组织，我会重点确认项目层级和团队边界是否能映射组织结构，需求变化是否能追溯到计划调整，管理者是否能看到跨项目风险，同时避免让每个成员重复维护两套状态。工具是否支持某项具体横道图、依赖或报表能力，应以当前版本演示和合同范围为准。

这种选择的代价是，组织需要投入时间梳理统一的工作方式。假如公司尚未定义需求、任务、迭代和里程碑之间的关系，直接上线平台可能把混乱搬进系统。应先选一个真实业务团队试点，明确必填字段、状态含义、变更责任和汇报口径，再逐步扩展。

如果团队只是要输出一张施工进度图或个人学习计划，完整的研发协作平台可能过重。反过来，如果多个团队需要共享需求与执行状态，单独购买横道图工具也可能留下数据孤岛。这类选择的关键不是功能最多，而是计划是否能连接真实的工作对象。

四、常见误区：为什么功能表打满勾，项目还是延误

1. 误区一：有依赖线就等于有关键路径管理

一条任务依赖线只说明两个任务存在某种先后关系，不代表组织已经识别出真正影响交付日期的关键任务。关键路径分析需要任务工期、依赖逻辑和日历假设足够完整；如果任务持续时间只是随手估的，计算出的关键路径也没有决策价值。

验证时要人为调整一项前置任务的完成日期，再观察后续节点和项目结束日期如何变化。若系统没有传达影响，或者团队成员不知道谁有权确认新日期，那么“支持依赖”这项功能并没有变成管理能力。

2. 误区二：工具支持多人协作，就会有人主动更新

协作功能只能提供更新入口，不能替代责任制度。团队需要明确谁负责修改任务状态、实际完成日期由谁确认、延期原因是否要记录、项目经理多久检查一次。没有责任归属时，软件越方便，也可能只是让过期信息更快地被复制。

一个实用做法是把更新动作放进既有节奏，而不是额外增加一次填表会议。比如在每周项目例会上，由任务负责人更新近期工作，项目经理只检查超期和依赖风险；对于变化不大的任务，不要求反复补写冗长说明。

3. 误区三：自动排期能让所有日期都更准确

自动排期依赖明确的关系和可靠的工作日历。若团队没有考虑假期、审批等待、外部供应商响应或共享人员可用时间，系统算出的日期就可能比人工计划更整齐，却并不更可信。

对外部依赖较多的项目，我通常建议把等待时间显式写进计划，标出责任方和确认节点，而不是把不确定性藏在一项过长的任务里。软件可以计算已知条件，但无法自动消除现实中的未知条件。

4. 误区四：管理层只要看一张总览图就够了

管理层总览图适合观察里程碑、整体状态和关键风险，不适合替代团队日常执行视图。若把所有任务都塞入领导汇报页，重要信息会被层级、颜色和长列表淹没；若只留几个总体百分比，又会看不出延误来自哪里。

建议至少维护两类视图：一类是团队执行视图，能看到任务、负责人、依赖和近期日期；另一类是管理视图，突出里程碑、预测完成时间、范围变化和需要决策的事项。两者应来自同一套数据，而不是每周人工重做两份计划。

5. 误区五：价格最低就是总成本最低

订阅费用只是直接支出的一部分。数据迁移、权限配置、培训、流程梳理、系统集成和持续维护都会占用团队时间。免费或低价工具如果需要项目经理每周反复整理汇报，实际使用成本可能高于收费产品。

相反，昂贵的企业工具也未必划算。如果组织只有一个项目负责人和少量任务，复杂配置会造成长期闲置。采购时应比较“每月为保持计划可信所需的总工时”，而不是只比较每个账号的标价。

五、专业判断逻辑：用同一把尺子做横向评估

1. 先将需求分为计划能力、协作能力和治理能力

计划能力包括任务层级、日期、依赖、关键路径、基线、里程碑和资源安排。协作能力包括责任人更新、评论、提醒、附件和团队视图。治理能力包括权限、审批、审计记录、模板、跨项目汇总和数据导出。

不同工具在这三类能力上的强弱并不相同。小团队可能最看重任务快速录入和共享；成熟项目办公室可能更看重基线和组合视图；研发团队还需要计划与需求和迭代衔接。先确定主次，再进入产品演示，才能避免被供应商预设的功能路径牵着走。

2. 用“能不能改变决策”判断功能价值

我会把每项功能改写成一个管理问题。比如，不问“是否支持提醒”，而问“任务延期后，负责人和项目经理能否在需要决策前发现”；不问“是否支持报表”，而问“管理者能否在五分钟内识别本周必须处理的三个风险”。

如果功能不能改变下一步行动，它在采购中的优先级就应该较低。相反，哪怕只是一个简单的变更记录，只要能帮助团队解释计划为什么调整、影响了哪些交付物，就可能比华丽的总览仪表盘更重要。

3. 设计一套可重复的测试项目

不要让五家供应商各自挑一套最顺手的演示项目。准备统一的数据样本，要求每款工具完成相同动作：建立任务层级、设置前置依赖、调整日期、分配负责人、标记逾期、查看管理视图和导出数据。每项动作记录时间、步骤数和出现的问题。

测试用例不必庞大。二十到三十个任务、三种角色、两次变更就足以暴露很多差异。重要的是记录同样的观察口径，例如完成一轮更新需要多少分钟、是否需要管理员协助、变更后有多少人能及时看到。

4. 把“最小可行治理”一起纳入试点

试点开始前，先定义任务字段、状态含义、计划基线和实际完成口径。否则每个人按自己的理解操作，最终得到的不是工具效果，而是不同工作习惯混在一起的结果。

最小规则通常包括：每个任务有明确负责人；重要任务有可验收的完成条件；每个里程碑有日期和责任人；延期要记录原因与影响；计划变更要有确认人。规则不用一开始就复杂，但需要全员理解一致。

5. 用权重而不是“功能打勾数量”计算适配度

可以将“计划逻辑”“成员更新”“跨项目治理”“实施成本”和“系统衔接”分别设为权重，再让实际使用者按同一测试任务评分。分值本身不需要假装客观，关键是让选择依据公开，避免决策最后变成谁的演示更好看。

评分后还要写下每个高分背后的证据。例如“成员更新便利”应来自任务负责人实际完成更新的时间，而不是采购人员主观判断；“系统衔接良好”应来自真实数据流或接口验证，而不是功能列表中的一句描述。

六、具体案例与数据观察：一个跨部门发布项目如何验证工具

1. 案例设定：把“延期”拆成可以追踪的工作节点

下面是一个示意项目，不是对特定客户的实测案例。某团队需要在十二周内完成一项产品功能发布，参与角色包括产品、设计、研发、测试和市场。原计划只有八条大任务，到了第六周，管理者发现设计确认、接口联调和测试准备之间没有明确依赖。

团队重新拆分后，将计划整理为需求冻结、方案评审、设计交付、开发、接口联调、测试准备、验收和发布准备等节点，并为每项工作指定负责人和交付条件。这里的关键不是把任务拆得越细越好，而是把交接点拆到足以判断“下一步是否可以开始”。

2. 先测维护时间，再讨论效率提升

团队在选型试点中设定一组观察指标：每周更新计划花费的人工时间、逾期任务发现时点、跨部门依赖识别次数、计划变更后通知到相关角色的时间。所有数值先由团队记录，不把它们当成行业基准。

为了说明如何做预算，可设定一组情景模拟：试点前，每周汇总和核对计划耗时 4.5 小时；统一任务负责人和提醒规则后，目标是将重复汇总压到 2.5 小时以内。这个差值只是试点目标，不是任何产品保证的效果。若实际没有下降，应继续检查更新流程，而不是把问题简单归咎于工具。

更有价值的观察往往发生在变化之后。例如，设计交付延迟一天，研发负责人能否及时看到依赖变化；项目经理能否指出受影响的验收节点；市场团队能否知道发布时间预测已经改变。工具是否减少了信息传递的等待时间，比图表是否能导出高分辨率图片更重要。

3. 用数据区分“任务完成率”与“交付可信度”

任务完成率很容易被过度解读。一个团队可能完成了 90% 的任务，却仍然缺少关键验收、合规审批或外部接口确认。建议至少并列观察三个维度：已完成任务比例、关键路径任务逾期数量、里程碑预测变化次数。

另一个容易忽视的指标是计划更新延迟，即事情已经发生，但系统状态过了多久才被更新。若延期在会议上已被讨论，却两周后才进入计划，管理层看到的风险提示就失去了价值。减少更新延迟，常常比追求更复杂的汇总图更能提升决策质量。

4. 小样本试点的结果必须谨慎解释

单个项目只能帮助发现工具与流程中的具体问题，不能证明某工具普遍提升效率。项目成员对软件熟悉程度、项目复杂度、领导参与方式和外部依赖都会影响观察结果。团队应记录这些背景条件，避免把一次顺利交付归因于软件本身。

我更愿意把试点看作一次可控的流程实验：先记录旧流程基线，再用同一团队、同一类项目进行新流程测试，最后比较维护工时、延期发现时点和交接遗漏。若两次项目差异很大，就只报告观察到的变化，不作夸大的因果结论。

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

1. 个人、自由职业者或两三人小组

先挑一款轻量工具，用一个真实任务列表测试共享、日期调整和进度标记。TeamGantt或GanttPRO可以进入试用候选；如果原本主要依赖表格，也可以评估 Smartsheet。重点不是部署流程，而是验证你是否会持续打开并更新。

不要为未来可能出现的复杂需求提前购买一整套企业能力。先把负责人、开始日期、完成日期、依赖和验收条件用清楚，团队自然会暴露真正的管理短板。小组阶段最值得投资的通常是稳定的更新习惯，而非高级报表。

2. 多部门共同交付的中型团队

先绘制一次跨部门交接：需求从哪里来、谁确认、谁接手、变化如何通知、什么情况需要升级。接着选两个有代表性的项目试点，一个流程成熟、一个变化较多，分别观察工具在正常和异常情况下的表现。

Smartsheet适合考察表格迁移和跨部门协作；若项目排程更复杂，可以把 Microsoft Project 或 GanttPRO 纳入对照。评估重点应放在权限、更新责任、依赖变化和汇报复用，而不是全员是否都能看见一张图。

3. 100 人以上的研发或产品组织

先厘清组织要解决的是计划可视化、研发过程追踪，还是多个团队间的组合管理。如果需求和迭代本身已经是工作核心，应评估计划工具能否连接到实际工作对象；PingCode可作为这类场景的候选平台之一，但必须通过版本演示和试点确认具体能力边界。

大型组织不宜全员一次性切换。先选一个有代表性的产品团队，明确项目模板、权限边界、状态规则和风险升级路径，再通过阶段复盘判断是否扩展。数据迁移和旧系统并行期的责任安排，应在上线前写清楚。

4. 工程、实施或外部依赖密集项目

若项目主要难点是严格前置关系、多个阶段门、现场资源冲突和交付基线，应优先验证 Microsoft Project 等排程能力较强的候选方案。测试中要加入外部审批等待、节假日和资源不可用时间，避免只在理想条件下得出结论。

如果计划软件不能覆盖团队的合同、现场管理或供应商流程，不要强迫它承担超出设计范围的工作。可以保留专业计划软件作为计划源，再通过清晰接口或定期同步提供管理视图；前提是明确哪个系统才是权威数据源，避免出现两套互相矛盾的日期。

5. 不同情况下怎么取舍

想要严谨排程，接受较高学习成本：优先验证 Microsoft Project。它的价值在于计划逻辑和控制能力，而不是人人都能无培训上手。

想让习惯表格的团队快速参与：优先验证 Smartsheet。需要确保表格灵活性不会演变成字段过多、规则无人维护的复杂表单。

希望专注建立甘特计划：比较 GanttPRO 与 TeamGantt。前者适合验证计划建立和项目管理需要，后者适合验证轻量团队能否快速共享时间线；最终差异应以同一项目任务演示为准。

计划必须连接研发工作流：将 PingCode 纳入候选，但同时评估实施治理成本。平台覆盖面越广，越需要先统一工作对象和流程口径。

只需要短期活动排期：优先选成员最愿意更新、导出和共享最方便的工具。为短期项目承担复杂系统配置，通常不划算。

6. 采购和上线的分阶段做法

1. 第一步：写清硬性条件。列出必须支持的依赖关系、权限、数据导出、部署要求和协作对象。把“最好有”与“没有就不能用”分开。

2. 第二步：准备统一样本。用真实项目改写成脱敏任务数据，保留关键依赖、角色和变更情景，让所有候选工具接受同样的测试。

3. 第三步：开展限时试点。试点周期应覆盖至少一次计划更新和一次真实变更。没有变化的演示项目无法检验进度管理能力。

4. 第四步：记录成本和风险。同时记录订阅、配置、培训、迁移和每周维护时间，并核对数据导出与退出方案。

5. 第五步：复盘后再扩展。确认计划可信度和协作效率确实改善后，再复制模板和治理规则，不要把试点团队的特殊做法直接当作全组织标准。

八、最后的判断：值得投资的软件，应该让计划更可信

1. 把“更好看”换成三个更有用的问题

第一，计划变化能否及时传到受影响的人；第二，管理者能否区分基线、预测和实际；第三，项目成员能否在不重复劳动的情况下更新真实进度。如果一个工具能持续回答这三个问题，它才开始具备实际投资价值。

横道图的价值不是让项目显得井井有条，而是把隐性的依赖和风险提前暴露出来。看得见的延期并不一定能避免延期，但发现得越早，团队越有机会调整资源、范围或交付顺序。

2. 用试点数据代替“听说很好用”

建议下一步先挑一个项目，记录当前每周维护计划所用时间、逾期信息进入系统的延迟、跨团队依赖漏报次数，再用统一任务样本测试两到三款候选软件。试点结束后，把新增培训和配置时间也算进去，判断收益是否真实。

如果你只需要快速共享一张项目时间线，轻量工具可能就是最佳答案；如果团队需要严格排程，优先考虑计划深度；如果计划必须和研发任务、需求及组织权限共同运转，就要评估平台级方案。最值得投资的不是功能最多的软件，而是能让团队更早发现偏差、减少重复维护，并且愿意长期更新的那一款。