Excel项目管理神器：2026年最受欢迎的5款进度计划工具对比

Excel项目管理神器：2026年最受欢迎的5款进度计划工具对比

Excel项目进度表最常见的失灵方式，不是公式错了，而是五个人维护同一份表：有人改了完成日期，有人覆盖了负责人，还有人仍在看上周发出的附件。选工具时，真正要比较的也不只是“有没有甘特图”，而是计划能否被及时更新、任务变化能否被看见，以及团队能不能继续使用熟悉的 Excel 工作流。本文把 Excel、Microsoft Project、Smartsheet、Asana 和 monday.com 放在同一张选型桌上，按进度计划、协作、Excel衔接、学习成本和适用边界逐项比较。

需要先说明：“最受欢迎”没有统一、可核验的公开排名口径，以下是五种常见方案的实用对比，不是销量或用户数量排行榜。

一、先说结论：选进度工具，先看计划是怎么变化的

1. 五款方案各自解决的不是同一个问题

如果项目只有几十项任务、一个维护人、每周更新一次，Excel往往已经够用。它的优势不是功能最多，而是几乎不需要迁移、培训和采购决策。任务数量增加，并不必然意味着要换软件；真正的信号是多人同时维护、任务依赖变复杂、延期影响需要快速传递。

如果工作核心是工期计算、任务依赖、关键路径和资源排期，Microsoft Project更值得评估。它更接近专业排程工具，而不是在普通表格上加一层任务看板。对只想分派任务、看状态的轻量团队来说，它的专业能力可能超出实际需要。

如果团队熟悉表格，希望在线协作、状态汇总和自动提醒，同时又不想完全放弃行列式管理，Smartsheet可以进入候选范围。它的价值在于把表格化工作方式和协作管理结合起来；具体的 Excel 文件兼容、自动化额度及套餐限制，发布或采购前应查看官方当前说明。

如果大家需要快速看清“谁在做什么、做到哪一步、卡在哪里”，Asana这类任务协作工具更合适。它适合围绕任务分配和状态协作组织工作，但不应默认它能替代复杂的工程排程。是否支持所需的时间线、依赖关系及导出方式，需要按当前版本逐项确认。

如果项目团队习惯用看板、状态列和可配置视图推进工作，monday.com可作为协作型方案评估。它较适合把任务、负责人、日期和状态放在共享工作区中管理。选择前仍要确认团队是否需要更严谨的关键路径计算，以及所购买的套餐是否包含所需的视图、自动化和权限能力。

这张表比较的是产品类型与常见使用方式，不是五款产品的实测分数。界面、价格、功能开放范围和地区服务可能变化；真正采购时应以产品官方当前页面、方案说明和试用结果为准。

2. 我的选型顺序：先找协作瓶颈，再看功能清单

我会先问团队：计划表目前最让人头痛的是什么？如果答案是“每周都要手工汇总”，关注点应放在数据汇总和视图上；如果答案是“前置任务延期后，后续日期没人调整”，就要看依赖关系和排程；如果答案是“大家不知道谁负责更新”，优先解决责任和更新机制，买软件并不会自动生成执行纪律。

一句话判断：维护问题选协作能力，排期问题选计划能力，决策问题选汇报能力。一个工具可能三者都覆盖，但在成本、易用性和控制力度上通常要做取舍。

3. 不建议把“最受欢迎”误读为“最适合我”

“最受欢迎”看上去像结论，实际可能指搜索热度、下载量、付费组织数、团队使用率，也可能只是内容平台上的提及频次。不同口径无法直接互换。若没有注明数据来源、统计范围和时间窗口，排名只能制造确定感，不能替你做决策。

本文因此不声称某款产品“排名第一”，也不根据搜索结果页面推断产品优劣。它采用的是需求对照法：先把五种方案的产品类别分清，再判断各自适用边界。对选型者来说，这比一张缺少测量口径的总分榜更有用。

二、为什么熟悉的 Excel 会突然不够用

1. 表格通常不是在任务太多时失效，而是在变化太频繁时失效

一个包含一百行任务的项目，若由一位计划员维护，字段统一、每周集中更新，Excel仍然可能运行得很好。反过来，一个只有二十行任务的项目，如果十个人每天改日期、状态和负责人，表格就可能很快出现多个版本、覆盖修改和口径不一致。

因此，项目复杂度不能只用任务行数衡量。更实际的变量包括：参与更新的人数、更新频率、任务依赖数量、跨部门交接次数、变更后需要通知的人，以及管理层需要查看的汇总维度。它们共同决定维护工作量。

一个粗略的风险观察法是把“参与编辑人数 × 每周更新次数 × 需要联动的字段数”当作检查提示，而不是精准公式。这个数值越高，越应该关注版本控制、权限、变更追踪和汇总自动化；它不能直接用于预测工期，也不等于一定要采购软件。

2. 文件共享解决的是“拿到表”，不一定解决“大家在同一份计划上工作”

把工作簿放到共享盘，只能改善文件分发。团队还要明确谁能改基准日期、谁负责更新实际进度、谁审核延期，以及周报引用的是哪一个时间点的数据。否则，同一个共享文件里仍可能有随意改列、填值口径不同和历史状态难以追溯等问题。

我会把进度表里的字段分成三类：计划字段、执行字段、管理字段。计划字段包括计划开始、计划完成和前置任务；执行字段包括实际完成比例、当前状态和阻塞原因；管理字段包括责任人、风险级别、审批人和更新时间。字段混在一起却没有定义，通常比缺少图表更容易引发误判。

例如，“完成度”可能被不同人理解成工时已投入比例、已完成子任务比例，或负责人主观判断。三个口径都能写成百分比，却不是同一指标。工具能提供下拉选项，却不能替团队决定“完成”的定义。

3. 报表越漂亮，不代表计划越可信

甘特图、仪表盘和颜色状态能提高可读性，但它们只会把输入数据呈现出来。如果计划日期长期不更新，仪表盘只是更精致地展示过期信息。如果任务都标为绿色，却没有明确的验收条件，颜色本身也无法证明项目按计划交付。

先保证数据有来源、更新有责任、状态有定义，再谈可视化。这是我判断一款进度工具是否真正有用的顺序。对于每个核心字段，都应能回答“谁填、何时填、依据是什么、谁会据此采取行动”。

三、五款进度计划方案逐项对比

1. Excel：适合把简单计划做清楚，不适合把多人协作问题藏起来

Excel的优势非常具体：团队多数人已经会用；字段、公式和格式可以按业务快速调整；模板容易复制；小规模任务计划不用额外学习一套系统。对于固定周期、少量责任人、变化不频繁的工作，它仍可能是成本最低、启动最快的选择。

它的风险同样具体：同一列可能出现不同写法；附件被复制后产生多个版本；公式被覆盖后不易察觉；状态更新依赖负责人主动提醒；任务延期后，后续日期不会自动成为可靠的行动提示。部分问题可以通过表格保护、数据验证和云端协作改善，但改善程度取决于团队的使用方式和当前办公环境。

Excel适合的不是“项目不重要”，而是项目管理机制足够简单。若计划里只有任务、负责人、开始日期、完成日期、状态和备注，且由固定人员维护，完全可以先把表格标准化。若大家已经需要大量手工复制状态、催促更新和合并不同版本，继续加宏、加公式未必划算。

最容易忽略的成本是隐性维护时间。工具免费不等于管理免费。负责人每周花三小时整理表格、追问状态、合并变更，这些工时应该计入总成本，而不能只比较许可证价格。

2. Microsoft Project：适合排程严谨，前提是团队真的需要排程

这类专业排程方案的价值在于把任务关系、持续时间和计划变动放在更系统的模型中考虑。对于阶段多、前后依赖明确、延期影响需要评估的项目，单纯的日期列很难回答“一个任务晚了，哪些节点会受到影响”。此时，依赖关系与排程逻辑比漂亮的看板更重要。

选择前应确认团队有没有人愿意承担计划维护工作。专业排程的前提是任务拆分合理、工期估算可信、依赖关系有人维护。若输入的是随意估的日期，软件算出的关键路径也只会显得精确，并不会自动变得正确。

还要区分“需要工期计算”与“需要任务协作”。前者偏项目计划模型，后者偏日常执行和团队沟通。有些团队两者都要，有些团队其实只需要负责人更新状态。不要因为专业工具功能更密集，就认为它更适合所有项目。

购买或迁移前，建议用一个真实项目验证：导入任务后日期、依赖和负责人是否映射正确；计划变化后是否能解释原因；成员是否能按权限更新；每周管理报告是否能在可接受时间内产出。试验中无法解决的工作流问题，正式上线后通常不会自然消失。

3. Smartsheet：适合表格思维仍占主导的协作团队

有些团队不想从行列式工作方式切换到完全不同的任务界面，却希望多人在线更新、集中查看状态并减少反复收附件。此时，表格化的在线项目管理方案可能更容易被接受。它的价值不在于“长得像 Excel”，而在于能否让数据共享、状态同步和汇总更有秩序。

评估时要把“可以打开 Excel 文件”和“工作簿完全兼容”分开。导入后，公式、合并单元格、条件格式、附件、下拉值和跨表引用是否保留，可能各不相同。日常导出能否继续用于财务、客户或管理汇报，也应拿真实文件做验证。

如果团队原有表格结构杂乱，把它整体搬进在线平台通常只是把混乱搬到云端。迁移前先删掉长期没人使用的列，统一状态词，确认日期格式和任务编号，再测试样例数据。这样能减少字段映射问题，也便于发现真正需要重建的流程。

价格与功能边界尤其需要核对当前方案。在线用户数、自动化次数、视图、权限、附件或报表能力可能与套餐有关。本文不列固定价格，是因为价格会变动；请以采购时官方页面和正式报价为准。

4. Asana：适合把任务责任和推进状态摆到台面上

协作型任务平台的主要优势，是让任务责任人、到期时间、状态和讨论围绕工作本身组织，而不只存在于表格附件、邮件或聊天记录里。团队若经常追问“这件事是谁接、下一步是什么、卡在谁手上”，任务协作的可见性可能比更多排程参数更有价值。

不过，任务看板不等于严格的进度计划。评估时要确认是否能表达任务之间的先后关系、如何呈现里程碑、是否支持团队需要的时间线和汇总视图，以及相关能力适用于哪个方案。对于依赖链长、工期变化影响大、需要关键路径的项目，不能只看演示页面。

导入历史任务时，不要把 Excel 的每一列机械复制成自定义字段。先确定哪些列是真正要持续维护的，哪些只是一次性备注。字段越多不一定越专业；每一个字段都会增加填写、解释和检查成本。

这类方案更适合以执行推进为中心的团队：任务数量不少，但项目不一定需要复杂资源排程；负责人需要在一个地方更新进度；主管希望尽早看到阻塞项。若关键需求是严格计算日期，必须另做专项验证。

5. monday.com：适合需要可视化工作流、愿意配置规则的团队

可配置工作区能让团队围绕自己的流程组织任务状态、视图和提醒。它的好处是可以贴近具体工作方式，不必让所有项目都套同一个僵硬模板。与此同时，可配置也意味着管理者要做选择：字段设多少、状态分几类、哪些变更触发提醒、谁能改流程。

如果每个小组都建立一套不同状态，管理层就很难横向汇总；如果提醒规则太多，成员可能忽略通知；如果把所有工作塞进一个大看板，项目之间的权限和重点也会混在一起。配置弹性是能力，不是自动产生标准化的保证。

在试用中，我会特别看三件事：从 Excel 导入时字段对应是否清晰；视图能否服务不同角色而不制造重复数据；自动化条件是否容易被团队理解。能配置不代表值得配置，优先保留能减少重复录入或加快决策的规则。

若项目需要多团队协作，应先定义共用字段和状态，再开放局部自定义。这样既保留业务灵活性，也能避免每个团队都把“进行中”解释成不同含义。

6. 这五种方案的横向判断

表中“适合”指建议优先验证的方向，不代表某项能力在所有版本、地区或套餐中都存在。工具功能可能调整，最终应以实际试用及官方说明为准。

四、别踩这五个误区：软件功能不等于项目管理能力

1. 误区一：支持 Excel 就等于无缝兼容

“支持 Excel”可能只意味着能导入或导出某种表格文件，不一定代表公式、格式、筛选、批注、附件和多工作表结构都能完整保留。不同产品对日期、百分比、人员字段和状态值的处理也可能不同。

我建议拿一份真实但脱敏的项目表做迁移验证，至少包含日期、负责人、下拉选项、公式、里程碑、前置关系和备注。迁移后随机抽查关键字段，再让一名实际用户完成新增任务、改期和导出。只用一张干净的演示表测试，通常发现不了真实数据的问题。

迁移验收不要只问“文件能不能打开”，还要核对：任务数量是否一致、日期是否变成正确时区或格式、负责人是否匹配、状态值是否丢失、导出后是否仍能满足外部汇报用途。

2. 误区二：甘特图越完整，计划就越准确

甘特图擅长呈现时间安排，不会替团队验证工期估算是否靠谱。若工期是随手填写的，依赖关系又没有经过执行人员确认，图表看起来越精细，反而越容易让人误以为计划可靠。

我会检查每个关键任务是否有可验收的产出、是否有负责人确认工期、前置条件是否真实存在，以及计划是否包含评审、返工和等待时间。甘特图应服务讨论，而不是用来压住合理的延期反馈。

3. 误区三：自动提醒能够解决不更新的问题

提醒只能通知到人，无法保证收到的人知道要更新什么，也无法判断更新是否真实。通知越多，越可能被静音或忽略。更可靠的做法是约定固定节奏，例如每周三中午前由负责人更新，项目经理周三下午核查阻塞项，周四再发布汇总。

提醒应围绕明确动作设置：到期前提醒责任人确认状态；依赖任务延期时通知受影响负责人；状态长期未更新时提醒计划维护人核查。单纯每天推送“还有任务未完成”，通常只增加噪声。

4. 误区四：所有项目都应该用同一套模板

团队可以有共用的基础字段，但不同项目的核心控制点并不一样。产品发布可能重视评审、验收和上线窗口；工程实施可能重视前置条件、现场资源和安全检查；市场活动可能更重视物料、审批节点和供应商交付。

最实用的模板通常分两层：一层是跨项目汇总必须统一的字段，如编号、负责人、状态、计划完成日、风险等级；另一层是项目类型所需的专属字段。既不把模板做成空壳，也不要求所有团队填写用不上的列。

5. 误区五：免费与付费只差在价格

团队应比较的是总拥有成本，而不只是订阅费。总成本还包括迁移、培训、管理员维护、流程配置、数据整理、外部协作者使用，以及导出后续处理。一个低价方案如果每周多耗费数小时做手工汇总，未必是真正便宜。

反过来，付费功能也不一定值得买。如果团队不需要自动化、跨项目报表或复杂权限，购买更高方案可能只增加闲置功能。建议先列出必须满足的需求，再把“有更好”与“没有就不能工作”分开。

五、用一个模拟项目看清：换工具之前，先算维护账

1. 场景设定：一个十二周的跨部门交付项目

以下是用于演示决策方法的情景模拟，不是真实客户案例，也不是任何产品的实测结果。设定一个十二周项目，涉及产品、设计、运营和供应商协作，共36项任务，其中8项存在明确前置关系，5名内部成员需要更新进度，另有外部协作者只需查看少量任务。

原有表格每周由项目协调人整理一次。每次整理需要约三小时：收集各人状态、核对日期、更新汇报页、追问缺失信息。若按十二周计算，单这一项整理工作就是36小时。这个数字是情景假设，用来展示测算方式；实际项目应记录真实耗时，不可照搬。

观察重点不是“36项任务够不够大”，而是更新者人数、依赖关系和汇报频率。若大家每周只更新一次且协调人能轻松维护，Excel可能仍是合理选择；若项目延期后经常要重排日期、追踪多个版本，继续使用附件表格的隐性成本就会上升。

2. 把问题拆成流程成本，而不是抽象地说“效率低”

我会把维护工作分成四段记录：收集状态、核对变更、生成汇报、跟进阻塞。连续记录两到四周后，团队能看出时间究竟花在哪。如果大部分时间都用于催更新，先定责任和节奏；如果大部分时间都用于整理数据，评估统一数据源和报表能力；如果主要耗在重排日期，就重点测试依赖管理。

同样，返工也要记录原因。是负责人迟报、计划基线不清、审批等待，还是 Excel 公式出错？不同原因对应不同解决方案。换系统最容易解决的是数据集中和部分重复操作，不会自动缩短审批等待，也不会替代管理决策。

3. 试点时比较“前后流程”，不要只比较界面

可以选一段真实工作做两周试点，不必一上来迁移全部项目。试点开始前先定义指标，例如每周汇总耗时、未更新任务比例、重复录入次数、延期原因可追溯率。试点结束后，用同一口径复测，才知道变化来自工具还是来自管理规则调整。

对这个模拟项目，如果新方案把每周汇总从三小时降到一小时，十二周理论上可节省24小时；但若迁移、培训和双轨核对投入34小时，单个项目周期内并没有收回投入。若之后多个类似项目复用同一套流程，累计收益才可能超过一次性成本。

这个简单算例提醒我，工具价值要放到使用周期里看。短期试点不一定证明采购错误，也不应被包装成“效率翻倍”；需要估算复用次数、团队维护成本及流程稳定性，再判断是否扩展。

4. 设定停止条件，避免试点变成“既然开始就必须上线”

试点应提前约定停止条件。例如，关键字段无法可靠迁移；目标成员在两周后仍需要重复维护两套数据；权限不满足外部协作边界；或每周管理维护成本明显超过旧流程。出现这些情况，不一定说明产品不好，也可能说明团队需求识别错误或模板设计不当。

继续扩展的条件也应明确：核心数据完整率达到团队设定标准，参与者知道如何更新，管理者能在约定时间内看到可信进度，且新流程的维护成本可接受。没有这些验收条件，试点容易只剩下一次演示和几张截图。

六、按团队情况做选择：从需求到行动的决策逻辑

1. 单人或小团队：先把 Excel 模板治理好

如果维护者不超过两三人、任务依赖少、每周更新一次即可，我会先保留 Excel，并做好四件事：统一字段、锁定公式区域、设置状态下拉选项、指定唯一发布版本。再把负责人、计划完成日、实际状态和阻塞原因设为必填或重点检查字段。

试运行两周后再看维护耗时和错误类型。如果主要问题是填写不规范，培训和模板治理可能已足够；如果主要问题是多人并发编辑、信息延迟或无法追溯变更，再开始评估在线协作工具。

2. 有明确依赖和关键日期：先验证排程能力

当一个任务的延期会影响多个后续任务，或团队必须解释关键里程碑为何变化时，应把依赖关系作为首要筛选条件。拿真实任务链测试：人为把一个前置任务延后两天，观察系统是否能准确呈现受影响任务、是否能保留原计划、是否方便解释变更。

若这个测试无法完成，或者团队仍要另开工作簿手工计算，那么所谓排程能力并没有进入实际工作流。此时应比较更贴合复杂排程的方案，而不是仅凭产品宣传中出现“甘特图”就作决定。

3. 多人频繁更新：先评估在线协作和责任机制

当任务由多个职能团队持续更新，且负责人经常要合并信息，可以优先评估Smartsheet、Asana或monday.com这类协作方案。三者并非完全相同：前者更贴近表格化协作，后两者可以围绕任务和工作流组织日常推进。实际适配程度要通过试点确认。

试点时不要只让项目经理操作。至少邀请一名任务负责人、一名审批者和一名只需查看汇总的管理者，各自完成真实动作。若只有管理员觉得方便，而普通成员不愿更新，采用率就会成为上线风险。

4. 对外汇报频繁：把导出和报表纳入验收

有些团队内部协作并不复杂，但每周都需要向客户、管理层或其他部门提供不同口径的进度报告。此时，工具能否按角色生成清晰视图、是否保留可追溯的基准日期、能否导出满足现有汇报格式的数据，可能比任务界面更重要。

建议准备一份真实的周报样例，分别测试筛选、汇总、导出和人工修订时间。若每次仍需从系统复制到 Excel 再重新核对，工具未必消除了成本，只是把成本移到了报告环节。

5. 预算紧张：先用总成本公式，而不是只看月费

可以用一个简单公式评估一年成本：软件费用＋迁移与配置工时＋培训工时＋管理员维护工时＋重复录入工时。若方案减少的手工时间无法覆盖新增维护和采购成本，就要重新审视是否需要迁移，或缩小购买范围。

这个公式不要求精确到每一分钟。关键是把原本被忽略的人工投入显性化。对五人团队来说，每周多花两小时和每周节省两小时，年累积差异会很明显；但只有被真实记录的节省才能作为采购依据。

七、迁移与上线：不要一次搬完所有项目

1. 先清理数据，再导入工具

导入前先检查重复任务、过期计划、离职人员、无效字段和不再使用的状态。任务名称应能说明交付物或动作，避免“跟进一下”“持续优化”这类无法验收的表述。计划日期要区分基准日期与当前预测日期，避免把原计划覆盖后无法解释变化。

我通常建议先导入一个项目或一个阶段，核对任务数量、负责人、日期、依赖关系和状态。确认无误后再扩大范围。若旧表里有重要公式、宏或外链文件，必须单独测试，不能默认目标工具能按原样运行。

2. 明确每个字段的责任和更新节奏

每个项目至少要确定一名计划维护人，负责结构和口径；任务负责人负责更新自己承担的工作；项目负责人负责处理阻塞、批准计划变更并确认对外口径。角色不清，工具上线后仍会出现“我以为别人会更新”的空档。

更新频率应由项目节奏决定。变化快的项目可以每天检查关键任务，但没有必要让所有任务每天重复填报；稳定项目每周集中更新可能更合适。不要以“更新越勤快越透明”为目标，应该让数据更新频率匹配决策需要。

3. 保留短期核对窗口，设定单一可信来源

迁移初期可以保留旧表用于核对，但应明确截止日期和职责。长期双轨会让成员重复录入，也会制造两个都像正式版本的数据源。试点通过后，应宣布哪个平台是主记录，并将旧文件标记为历史资料或只读版本。

如果仍需要向外部提交 Excel 报表，应定义导出流程和责任人。导出的文件是报告副本，不是第二套长期维护的计划。每次报告都应标注生成日期和数据范围，避免旧附件再次被当成实时状态。

4. 用三类指标验收，而不是只问大家喜不喜欢

上线验收可以覆盖数据质量、流程效率和采用情况。数据质量看关键字段完整率、状态有效率和近期更新率；流程效率看汇总耗时、重复录入工时和变更核对时间；采用情况看任务负责人按约定更新的比例、活跃用户以及绕开系统的情况。

满意度可以作为补充，但不能替代运行指标。界面看起来顺手，不一定代表信息可信；短期内多录了一些数据，也不一定代表长期维护成本过高。最好在试点前设定基线，试点后以相同口径比较。

八、最后的取舍：别追求“功能最多”，追求计划能被持续相信

1. 什么时候继续用 Excel 更理性

项目结构简单、编辑者少、维护节奏稳定、手工汇总成本可接受时，继续用 Excel 并不落后。先把字段、版本、更新责任和计划基准管理好，往往比仓促迁移更有效。少一个系统，不意味着少一份管理。

但如果表格已经变成多个附件、多人同时修改、计划变更没有记录、负责人每周花大量时间追数据，就要正视它的管理成本。不要因为团队“已经用了很多年”而把沉没成本误当成未来收益。

2. 什么时候值得试用专业工具

当任务依赖需要传播、多个团队需要共享同一状态、权限边界变复杂、管理汇总反复手工加工，或项目变化频繁到表格无法及时反映时，试用专业方案是合理的。重点是找出当前瓶颈，再挑一款能针对性改善的方案。

若最重要的是严谨排程，就重点测试依赖、关键日期和基线；若最重要的是多人更新，就测试责任分配、提醒和变更留痕；若最重要的是报告，就测试汇总、筛选和导出。不要用同一套泛化问题评估所有产品。

3. 下一步按这个顺序做

1. 选一个近期真实项目，记录任务数量、参与编辑人数、每周更新频率和汇总工时。

2. 找出最昂贵的一个问题：排程不准、更新不及时、版本冲突、汇报重复，还是责任不清。

3. 列出三项必须满足的能力和三项可以妥协的能力，避免需求清单无限膨胀。

4. 用脱敏真实数据试用候选方案，核对导入、更新、依赖、权限和导出等关键流程。

5. 设定两至四周试点周期，用同一口径对比数据质量、维护工时和用户采用情况。

6. 根据试点结果决定保留 Excel、局部迁移或全面切换，并明确唯一可信的数据来源。

真正值得称为“神器”的，不是功能最多的进度工具，而是能让团队更早发现偏差、说清责任、并以更低维护成本持续更新计划的工作方式。如果你现在正准备选型，先别急着问哪款最受欢迎；记录一周真实的维护过程，找出时间究竟花在收集、核对、排程还是汇报上，再用那一个具体问题去筛选五种方案。这样选出的工具，才更可能在项目开始后仍然有人愿意用。