2026年效率之选：6款顶级做进度图的软件工具大盘点

2026年效率之选：6款顶级做进度图的软件工具大盘点

进度图做得漂亮，不等于项目真的可控：我见过排期表上每个任务都有起止日期，到了周会上才发现关键依赖没人确认、实际完成量也没有统一口径。选做进度图的软件，真正要比较的不是谁的甘特图颜色更多，而是它能不能把任务、依赖、责任人、实际进展和变更影响连成一条可执行的管理链。本文从这条链出发，对 Microsoft Project、Excel、Smartsheet、Asana、monday.com 和 PingCode 六类选择逐一拆解，并给出适用边界、试用方法和一组明确标注为情景模拟的数据。

一、先讲结论：选工具之前，先确定进度图要回答什么问题

1. 六款工具没有脱离场景的统一冠军

如果项目需要严谨的依赖关系、基线和关键路径分析，我会优先评估 Microsoft Project；如果目标是用低门槛表格快速搭出简单计划，Excel 往往够用；如果团队需要表格、自动化和协作视图结合，可以考察 Smartsheet；如果重点是跨团队任务协作与时间线管理，可以看 Asana 或 monday.com；如果进度必须和需求、迭代、缺陷、交付流程一起跟踪，PingCode 更值得进入候选名单。

这不是产品排名，而是按项目管理问题分类。把工具只按“甘特图好不好看”来选，往往会忽略更昂贵的成本：计划变化后要不要手工改几十行、负责人是否能及时更新、管理者能否看出延期原因，以及项目结束后数据能不能复盘。

上表是选型入口，不是功能承诺清单。各产品的具体能力、套餐限制、集成方式与界面会更新；我建议以官方产品说明和试用环境为准，尤其要现场确认依赖自动调整、权限粒度、导出格式、历史记录及集成范围。不要仅凭产品宣传页的一张示意图决定采购。

2. 先分清三类“进度图”

排期图回答“计划什么时候开始、什么时候结束”。它可以是一张时间轴，也可以是日历或甘特图，但只呈现计划，不代表项目实际情况。

执行进度图回答“已完成多少、哪些工作偏离计划”。它需要实际开始时间、实际完成时间、状态、剩余工作量等数据。没有这些字段，图表显示的通常只是计划，不是进度。

管理汇总图回答“哪些项目需要管理者介入”。它不一定展示每个任务，而是按阶段、负责人、风险、延期天数或交付批次聚合。工具即使有漂亮的甘特图，如果不能快速定位偏差，也未必适合管理层使用。

选型时，我会先问使用者每周打开图表后要做什么决定：重排资源、催办责任人、调整范围，还是向客户汇报。只有把决策动作讲清楚，才能判断产品的时间线、看板、报表和自动化能力是否有用。

3. 我会用“变更成本”而不是“功能数量”做最终判断

进度图的价值，通常在第一次变更后才显现。需求延期两天后，工具能否指出后续任务受影响、谁需要确认、关键交付日期是否改变？如果所有信息都要项目经理手工查找和改写，再多视图也只是展示层。

因此我更看重三个连续动作：更新是否够轻、偏差是否够清楚、调整是否能传递给相关人。这三项分别对应数据维护成本、风险识别速度和协作闭环。试用时把这三项做成任务，而不是让团队只浏览模板和演示数据。

二、背景和真实场景：一张甘特图为什么常常管不住项目

1. 计划看起来完整，实际数据却可能不同步

典型项目计划会包含阶段、任务、开始日期、结束日期、负责人和状态。但如果任务状态由成员在聊天工具里报，实际完成时间记在表格里，风险说明又留在会议纪要中，甘特图就会逐渐和现实脱节。项目经理需要在多个来源之间人工拼接，这通常是进度管理失真的起点。

另一种常见情形是，团队只记录“完成百分比”，却没有规定百分比如何计算。一个负责人按工时估算，另一个按子任务数量估算，还有人把“正在做”填成百分之五十。图表看上去有精确数字，实际却没有可比较的含义。

2. 不同团队要的不是同一种图

工程建设和大型交付项目往往需要前置关系、关键路径、资源负载和基线比较；软件研发团队更关心需求进入迭代后，任务、缺陷和版本交付之间的关联；市场活动团队可能更关心内容制作、审批、上线和渠道协同；小团队则可能只需要知道本周谁负责什么、是否按时完成。

我会先画出工作实际流转路径，再判断需要甘特图、看板、日历、路线图还是汇总报表。比如一个内容发布流程，如果主要风险来自审核卡点，按审批状态分组的看板可能比一张横跨三个月的甘特图更能暴露问题。

3. 数据越细，不一定越可控

任务拆得过粗，图表无法定位阻塞；拆得过细，成员维护状态的时间可能超过实际执行时间。我的经验判断是，任务颗粒度应该服务于管理动作：如果某件工作需要单独指定负责人、单独验收，或可能独立延期，就值得考虑拆成独立任务；否则可以留在任务描述或检查清单中。

一个可用的任务记录至少要有明确的交付物、唯一责任人、计划时间和可验证的完成条件。依赖关系只有在前置任务不完成就不能开工时才应建立。把所有任务串成一条链，容易制造虚假的关键路径，也会让微小调整引发不必要的排期波动。

4. 选工具之前，先约定数据口径

试用前我会写一页简短的数据规则：状态有哪些、完成百分比按什么算、延期从哪一天开始计、谁有权限改基线、每周何时更新。规则不需要复杂，但需要团队用同一种方式理解数据，否则图表的准确程度无法靠软件补救。

例如，“已完成”可以定义为交付物通过验收，而非负责人做完自认为的工作；“风险”可以定义为存在明确阻塞、依赖未确认或预计日期可能变化。用可观察的事件定义状态，比让每个人自由选择颜色更容易复盘。

三、拆解六款工具：各自能解决什么，又不适合什么

1. Microsoft Project：复杂排程优先，协作习惯要单独设计

对于包含大量任务依赖、多个阶段和资源约束的项目，Microsoft Project 的优势在计划结构与排程思维。它适合项目计划负责人集中维护较正式的计划，也适合需要比较基线和当前排期的团队。

需要留意的是，排程软件的能力强，并不意味着团队协作自然顺畅。如果任务负责人不使用计划工具，项目经理仍要把消息、会议纪要和现场反馈手动回填。采购前要确认团队是由少数计划管理员集中维护，还是要求大量成员日常更新；两种模式对培训、权限和许可的要求不同。

我的试用动作是先建立一个包含 20 至 30 个任务的小型样例：设置若干前置关系、两项并行工作、一项资源冲突，再把其中一个前置任务延期。观察后续日期是否按预期变化、排期逻辑是否易于解释，以及负责人能否理解自己需要更新的字段。

2. Excel：最快的起步方案，也是最容易悄悄变成系统的表格

Excel 适合任务量有限、项目周期较短、参与者熟悉表格的情况。用日期列和条件格式就能做出基础时间轴，不需要先搭建复杂流程，也容易导出、打印和自定义字段。对一次性活动计划或小团队内部协同，轻量是它的优势。

问题在于公式、颜色和数据验证规则通常由少数人维护。一旦复制出多个版本，成员可能编辑了旧文件；如果计划依赖关系靠人工调整，延期后还得逐项检查后续日期。Excel 可以绘制进度，但不能自动弥补缺失的流程治理。

我建议把 Excel 用在“先验证管理方法”的阶段，而不是默认将它发展为长期的多项目平台。如果需要持续维护版本、处理大量协作者、自动提醒、权限隔离或跨项目汇总，应该计算长期维护成本，再决定是否迁移到专用工具。

3. Smartsheet：适合表格思维强、协作流程也需要被管理的团队

Smartsheet 的吸引力在于，团队可以从熟悉的行列结构出发，再组合不同视图和工作流。对于跨部门推进、需要自动提醒或汇总多个工作表的项目，它可能比纯表格更容易形成统一的数据入口。

风险也来自灵活性：列名、状态选项和自动化规则如果缺乏治理，团队会创建相似但含义不同的字段。试用时不要只验证能不能做出漂亮视图，还要测一个实际流程：任务逾期后谁收到通知、负责人变更后通知是否失效、表格中的权限能否满足部门隔离，以及导出的数据是否便于审计。

自动化的可用范围和数量可能受订阅方案影响，不能仅凭演示环境推断正式使用成本。采购前要用预计的活跃用户数、工作表数量和通知频率核算，而不是只比较单个用户的标价。

4. Asana：协作体验是重点，计划治理仍需团队建立规则

Asana 适合任务责任明确、成员需要频繁沟通和更新工作的团队。时间线或相关视图可以帮助团队看任务分布与计划关系，任务讨论和责任归属也有助于减少信息散落在会话中的情况。

但工具并不会自动消除“任务完成”的歧义。团队仍需明确什么时候算完成、任务是否允许多人共同负责、延期时需要填写什么原因，以及状态变更是否要同步计划负责人。选择时还要检查当前方案提供的时间线、依赖、汇总和管理能力，避免把某个套餐才有的功能当作基础能力。

如果组织有复杂资源排程或正式的基线管理需求，建议拿真实样例验证，而不是把协作工具的时间线视图直接等同于专业排程系统。两者解决的问题有交集，但管理深度和计算方式未必相同。

5. monday.com：可配置性高，成功条件是先管住字段和视图

monday.com 适合希望用不同视图呈现工作、又不想从固定模板开始的团队。看板、时间线和表格之间的转换，有利于让执行者和管理者查看同一批工作数据的不同切面。

配置灵活的另一面是容易过度定制。团队可能为每个部门设置不同状态，最后无法做跨项目汇总；也可能建立很多自动化，却没有人知道规则在什么情况下触发。我通常会建议先确定少量公共字段，再把部门特有字段限制在必要范围内。

试用中要实际检验一条完整链路：创建任务、指定负责人、添加依赖、调整日期、变更状态、查看汇总。观察界面是否让成员知道下一步该做什么，也要看管理者能否从汇总视图追溯到具体任务。

6. PingCode：研发交付场景要验证“计划是否连接执行”

PingCode 更适合从产品研发和交付协作角度评估。对中大型企业及 100 人以上组织，选型重点往往不只是画出一条项目时间线，而是需求、迭代、任务、缺陷、版本和交付信息能否在同一管理链路中衔接。

我会把验证重点放在端到端追踪：一项需求进入计划后，能否找到对应迭代和执行任务；任务延期后，项目负责人能否看到交付影响；迭代数据能否支持复盘；不同角色能否看到各自需要的信息。只有当进度图能追溯到真实工作项，它才不只是汇报层的展示。

具体的甘特视图、依赖关系、跨项目汇总、权限和集成能力，应以当前版本的产品说明及实际试用为准。组织也需要评估既有研发流程与工具配置之间的匹配度，避免为了迁就软件而把流程改得复杂，或因流程不清晰而误以为工具缺少功能。

四、常见误区：做图容易，误判项目状态也很容易

1. 把甘特图当成全部进度管理

甘特图很适合展示时间安排和任务关系，却不天然告诉你需求是否合理、成果是否达标、风险是否正在变大。管理者如果只看条形长度和颜色，可能错过范围变更、质量返工或关键人员不可用等问题。

因此我会把甘特图当作项目状态的一个视图，而不是项目管理本身。进度图旁边至少应有偏差原因、下一步动作和负责人；如果项目风险主要来自审批或质量，图表还要配合审批状态、缺陷趋势或验收结果。

2. 把“完成百分比”当作精确数据

任务完成百分比只有在计算规则一致时才有比较价值。若任务没有可拆分的验收节点，百分之七十可能只是主观判断。对于研究、设计和创意类工作，适合用阶段性成果或检查点表示进度；对于可计数的工作，则可以按已完成数量除以总数量计算。

我通常不要求每种任务都强行填写百分比。可以将状态限定为未开始、进行中、待验收、已完成、受阻，并为“受阻”和“待验收”配置说明字段。必要时再用检查点计算完成度，避免用一个数字掩盖工作性质差异。

3. 把颜色当作风险控制

红黄绿只能提示状态，不能解释问题。红色任务可能是延期一天，也可能已经威胁最终交付；绿色任务可能只是负责人没有更新。颜色必须对应明确阈值，例如距离计划完成日期的天数、未关闭依赖数量或剩余缓冲时间。

更重要的是，每个颜色都要对应处理动作。红色意味着谁需要介入、何时升级、需要做什么决策；否则颜色只是把焦虑视觉化，并没有形成管理闭环。

4. 把功能多当成效率高

功能越多，潜在配置、培训和治理工作也越多。若团队只有十几项并行任务，复杂的权限体系和自动化规则可能反而增加维护成本；若组织有数百人共同交付，过于轻量的表格又可能缺乏必要的追踪与控制。

我会把“少做一步重复劳动”作为功能价值的判断标准：自动提醒是否替代了人工催办？依赖计算是否减少了改期检查？报表是否让决策更快，而不是多出一份需要维护的汇报材料？无法对应到具体节省或风险降低的功能，不应该成为采购理由。

5. 忽略迁移与退出成本

试用顺利不代表迁移顺利。真实项目可能包含历史任务、负责人映射、自定义字段、附件、评论和权限关系。迁移时如果只导入任务名称和日期，团队会失去关键上下文，最后仍要回到旧系统查资料。

选型前应准备一小份真实数据，测试字段映射、导出、附件处理和历史记录保留。也要确认团队是否能在合同结束或工具变更时取回可读数据。数据可移出，不只是技术问题，也是降低未来锁定风险的管理要求。

五、专业判断逻辑：用一套可复现的试用方法代替主观演示

1. 先把需求变成验收问题

试用前，将“我们需要更好地管进度”改写成可现场回答的问题。比如：新增一项前置依赖后，后续日期是否更新？成员能否在一分钟内找到自己的待办？任务延期后，项目负责人是否能看到受影响的交付日期？数据能否导出并保留关键字段？

每个问题都要规定通过条件。没有通过条件，试用很容易变成团队喜欢哪个界面、销售演示哪个功能，最终缺少可比较的证据。能被重现的测试，比主观印象更适合进入采购评审。

2. 用同一组样例测试所有候选

样例不宜太简单，也不应大到无法比较。我会准备约 25 项任务，包含三个阶段、两项并行工作、三条关键依赖、一项延期、一项返工、一名跨项目共享的关键成员，以及一个需要管理者审批的变更。

这组数据足以观察计划、协作、变更和汇总能力，又不会让试用成本过高。不同工具使用相同的任务定义和日期口径，记录完成时间、手工操作次数、错误点和成员理解成本。

3. 不只测项目经理，也测普通成员

项目经理可能熟悉功能，但日常更新通常由任务负责人完成。让一名第一次使用工具的成员执行领取任务、更新状态、填写阻塞原因和提交验收等动作，观察他是否能独立完成。

如果每次更新都要培训或由管理员代填，团队的真实维护成本就会高于演示中呈现的成本。工具越依赖少数管理员，越要把人员变动和管理员离职的风险纳入评估。

4. 记录变更后的人工工作量

我会专门记录一次延期发生后，项目经理需要做几件事：找到受影响任务、修改日期、通知负责人、重算汇总、更新汇报材料。工具如果能减少其中若干动作，就有明确价值；如果只把任务画得更整齐，却没有减少任何工作，效率收益就需要重新审视。

还要区分“自动更新”与“自动决策”。日期根据依赖重算，可以减少机械劳动；但是否接受延期、是否缩小范围、是否增加资源，仍需要项目负责人判断。软件可以给出信息和影响范围，不应被误认为替代业务决策。

5. 把总拥有成本纳入评分

工具成本不仅是订阅费用，还包括实施、培训、数据迁移、管理员维护、权限治理、集成开发和退出迁移。一个价格较低但每周要花数小时整理数据的方案，长期成本未必低。

试算时建议把成本分成首年投入和稳定运营投入。首年包括建模、迁移和培训；运营期则重点估算每周维护时间、管理员工时和系统集成维护。财务数字未必一开始就精确，但成本项应完整列出，避免只比较授权单价。

六、具体案例与数据观察：把选型放进一个可复算的项目里

1. 案例背景：八周产品发布，团队有三类不同工作

下面是用于演示选型逻辑的情景模拟，不是我的客户实绩，也不代表行业平均值。假设一个 12 人团队要在八周内发布一项线上服务，工作分为需求确认、产品设计、开发、测试验收和上线准备，另有市场内容与客户支持准备两条并行工作。

项目管理的困难并不在于任务总数，而在于工作之间的连接：需求确认未完成会影响设计；核心接口延误会压缩测试时间；内容发布依赖最终功能说明；客户支持材料又需要通过产品验收信息校准。

2. 第一轮建模：先定义关键任务与依赖

我会先建立约 30 项可验收任务，而不是把团队所有日常活动都塞进计划。每项任务指定唯一责任人、计划起止时间、交付物和验收标准；有明确先后关系的工作再设置依赖。并行且互不阻塞的工作则保持独立，避免人为制造串行流程。

管理者视图只保留阶段交付、关键依赖、风险状态和预测完成日期；执行者视图则保留个人待办、描述、验收要求和讨论记录。两类视图使用同一批任务数据，但关注点不同。

3. 第二轮模拟变更：接口延期两天

假设核心接口比计划晚两个工作日。若计划中已经记录开发与测试的依赖，项目负责人可以判断测试窗口是否被压缩；若内容团队依赖最终功能说明，也要评估市场准备是否受影响。此时的关键不是图上把条形改成红色，而是识别哪些日期可调整、哪些交付必须重新协商。

如果工具只能展示任务延期，负责人仍需要逐条查找其他团队的关联工作；如果依赖关系清晰且更新路径可追踪，项目经理就能更快组织一次有针对性的调整会。后者未必保证项目不延期，但能缩短发现影响与做出决定之间的时间。

4. 用模拟数据看维护时间，不把估算冒充实测

以下数据假设同一项目每周召开一次状态会，项目经理需要整理进度、找出延期任务并更新汇报。时间数字是用于预算讨论的情景估算，实际结果会受任务数量、更新纪律和配置质量影响。

这组估算不能用来宣称某款产品一定节省多少时间。它的用途是提醒选型者：把试用期的人工整理时间也记录下来，并按团队规模折算。如果一个方案每周节省两小时，但上线时要花大量时间治理流程，组织需要计算多久才能收回投入。

5. 结果观察：判断效率改善，必须同时看三类数据

我会同时观察人工维护时间、计划偏差被发现的时间和变更后的通知覆盖情况。只看整理时间可能会把“少做了汇总”误认为“项目更有效”；只看准时率则可能忽略范围被削减或质量风险上升。

建议每周记录计划完成任务数、实际完成任务数、逾期任务数、关键阻塞时长和返工数量。连续观察四到六周，比拿单次演示结果做结论更有参考意义。项目周期很短时，也至少覆盖一轮真实变更和一次阶段验收。

七、不同情况下的行动建议与取舍

1. 只有少量任务、项目周期短：先用熟悉的工具验证管理方法

如果团队规模小、任务依赖少、计划变化不频繁，Excel 或现有表格工具可能足够。先统一字段和状态定义，再观察每周维护是否可接受。不要因为市场上有更复杂的系统，就在问题尚未明确时引入额外配置和培训工作。

但要设一个升级信号：例如多个版本经常冲突、项目经理每周花大量时间手动汇总、延期影响无法追踪、多人需要不同权限。出现这些情况后，再试用协作型或专业排程工具。

2. 依赖多、日期约束严格：优先验证排程推演

对于大型交付、工程计划或多阶段发布，先测试前置关系、资源冲突、基线和变更传播。Microsoft Project 可以作为候选之一，但不要只看它能否生成甘特图，还要确认计划维护责任、协作方式和成员使用门槛。

如果排程模型由专职计划人员维护，团队通过其他协作渠道执行，需明确主数据在哪一处、变更由谁批准、状态多久回填一次。工具之间存在信息断点时，不能把“有集成”简单理解为“数据一定一致”。

3. 表格使用习惯明显：比较轻量表格与协作化表格

团队习惯用表格工作时，可以在 Excel 与 Smartsheet 之间做小样本对照。前者适合灵活、低门槛和一次性工作；后者可进一步验证自动提醒、视图和协作机制是否减少了维护成本。

评价时不要把“可以配置”当作无成本。列越多、公式越复杂、自动化越多，越需要指定维护人。先让一名普通成员独立完成更新，再由管理者查看汇总，看看信息是否自然流动。

4. 研发流程复杂：优先看需求到交付的可追踪性

如果计划状态必须关联需求、迭代、缺陷和版本，PingCode 值得进入验证名单。对于中大型研发组织，关键是看管理层能否从交付节点追到执行项，团队能否从个人任务理解它为什么重要。

如果组织已经有成熟工具链，迁移前应逐项核对数据模型、集成和历史信息保留。替换工具的收益必须超过迁移、培训、流程重建和并行运行的成本，不能因为单一视图不够美观就整体推倒重来。

5. 需要快速推进多个部门：优先试验协作与治理的平衡

Asana 和 monday.com 可以作为任务协作与多视图管理的候选。前者可重点看任务协作和责任追踪，后者可重点看视图配置与字段治理。最终要以团队工作方式和当前方案能力为准，不建议仅凭品牌知名度或模板数量选型。

多部门项目最需要明确公共字段：任务状态、责任人、计划日期、风险、验收条件。部门特有字段可以保留，但应避免每个团队都自创一套状态词，否则跨部门汇总会失去可比性。

6. 把试点做成两周实验，而不是一次演示会

一个可执行的两周试点可以这样安排：

1. 第一天，选定一个真实但风险可控的项目，记录当前整理进度所需时间。
2. 第二至三天，用统一模板导入任务，补齐责任人、日期、验收条件和依赖。
3. 第一周，让执行成员自行更新状态，记录遗漏、误解和管理员代操作次数。
4. 第二周，模拟或遇到一次真实变更，检查工具能否呈现受影响任务和决策信息。
5. 试点结束，比较维护时长、偏差发现速度、字段完整度和成员可用性，再决定是否扩大范围。

若试点期间恰好没有发生任何变更，就不能证明工具擅长变更管理。可在测试环境中人为调整一项前置任务日期，观察影响传播和通知过程；但应把模拟结果与真实运行结果分开记录。

7. 按团队规模做取舍，不要只按使用人数做预算

小团队应优先降低启动和维护门槛；中型团队要关注跨部门汇总、权限、模板和自动化的治理成本；大型组织则要把审计、集成、数据迁移、管理员能力和长期服务纳入评估。人数只是规模变量之一，项目并行度、依赖数量和流程差异同样重要。

一个团队如果只有二十人，却同时推进十个相互依赖的项目，管理复杂度可能高于五十人只做单一项目。预算评审最好使用实际项目数量、活跃任务数和管理员工时，而不是只用员工总数推算。

八、最终怎么选：让进度图变成行动入口，而不是汇报终点

1. 先把结论写成一张需求卡

在联系供应商或启动试用前，写清项目类型、参与角色、任务规模、主要依赖、更新频率、必须保留的数据和预算边界。再列出三项不能妥协的能力，例如依赖变化可追踪、负责人能自主更新、管理者可以按风险汇总。

这张需求卡能过滤掉大量与实际问题无关的功能讨论。若团队无法说清自己最想解决的三个问题，建议先做一轮流程梳理，而不是先买软件再期待软件替团队设计管理方式。

2. 先选管理机制，再选呈现形式

甘特图、时间线、看板、日历和路线图并非彼此替代的“漂亮程度”选项。甘特图适合回答依赖和时间安排；看板适合呈现状态流转；日历适合观察某段时间的工作密度；路线图适合沟通阶段目标。一个项目可能需要多个视图，但它们最好共享同一套基础数据。

如果不同视图需要分别维护，工具就可能制造新的数据孤岛。试用时确认同一任务在不同视图中的日期、负责人和状态能否保持一致，也要检查图表背后的数据能否导出、复用和审计。

3. 用“长期维护成本”决定是否升级

从表格升级到专用工具，不是越早越好，也不是越晚越省钱。值得升级的信号是：人工核对持续增加、跨团队信息反复丢失、变更影响难以判断、管理者无法及时识别风险，且专用工具可以在试点中证明能改善这些问题。

反过来，如果团队仍缺少责任人、交付定义和状态口径，再强的系统也可能只会更快地产生不一致的数据。先把最低限度的工作规则讲清楚，软件才有稳定的流程可承载。

4. 我的最终判断：好图表应让人更早做决定

我判断一款进度图工具是否有效，不看它能生成多少种图，而看团队是否更早发现偏差、更快确认责任人、更少重复整理数据，以及是否能把延期原因转成下一步动作。图表的颜色、模板和动画都可以加分，但它们不是管理能力本身。

下一步可以从一个真实项目开始：选定 20 至 30 项任务，明确负责人、验收条件和依赖，用同一组样例试用两到三款候选工具；记录变更后的人工操作和数据完整度，再决定是否扩大采购范围。对大多数团队而言，先验证数据能否持续更新，再比较界面与功能；先验证变更能否被管理，再讨论图表是否漂亮，是更稳妥的效率之选。