2026年项目管理利器：6款顶级项目计划制定软件全面对比

项目计划最容易失真的时刻，不是任务还没填完，而是计划看起来已经很完整：甘特图上有日期、负责人和里程碑，真正执行时却发现关键依赖没人确认、资源被重复分配、变更没有回写。比较 2026 年的项目计划制定软件，我更看重的不是谁的功能列表最长，而是工具能不能让计划持续接近真实执行。本文从六款产品的计划模型、协作方式、约束条件和适用团队出发，给出可落地的选型方法；涉及体验数据的部分会明确标注为情景模拟，不冒充真实产品测试结果。

一、核心结论：先选计划模型，再选软件

1. 六款软件分别适合什么团队

如果你只想先看结论，我的判断是：企业项目控制优先看 Microsoft Project；需要把产品研发的需求、迭代和路线图连起来，可以评估 PingCode；跨部门业务协作优先看 Asana 或 monday.com；项目计划要和表格、预算、审批深度结合，可以看 Smartsheet；已经以 Jira 管理研发任务、需要组合项目视图的团队，再考虑 Jira 相关规划能力。

这不是功能排名，而是计划机制与团队工作方式的匹配。一个工具可以有甘特图，却不一定能处理资源冲突；有看板，也不代表能维护基线、关键路径和跨项目依赖。选择的第一问题不是“有没有计划视图”，而是“计划改变后，谁需要知道、哪些记录需要同步、谁有权确认”。

表中比较的是产品的典型使用方向，不代表每个版本都含有相同功能。软件套餐、地区可用性和功能命名会调整，尤其是高级规划、资源管理、组合视图和自动化能力，采购前应以供应商当期产品文档和合同清单为准。

2. 我建议按“约束优先级”筛，而不是按知名度排

我会先找出项目计划里最难被替代的约束：是关键路径与资源负荷，是研发需求的端到端追踪，是业务团队快速协作，还是审批、表单和数据收集。最硬的约束先匹配，易满足的功能放到第二轮。这样做能避免演示时被漂亮看板吸引，采购后才发现团队最关键的管理动作仍要靠表格补齐。

若团队目前没有统一项目方法，先不要购买“最复杂”的工具。先用一个有代表性的项目跑通计划建立、责任确认、变更记录、风险升级和复盘，再评估是否需要更深的资源或组合管理能力。功能越多，不等于计划越可信；只有数据责任人、更新节奏和变更规则明确，功能才会转化为管理能力。

二、背景和真实场景：计划软件解决的是“变化如何传导”

1. 项目计划不是一次性排期表

计划通常从目标、交付物和里程碑开始，继而拆成任务、责任人、持续时间和依赖关系。随后团队会遇到现实变化：需求多了一项、供应商延期、关键成员请假、评审没有通过。软件的价值不在于把原计划保存下来，而在于让变化能够找到受影响的任务、责任人和决策者。

对单人或小团队而言，一张表格可能已经足够。可是当一个项目跨越产品、研发、测试、法务、采购和市场，计划信息会出现多个版本：有人看邮件，有人改表格，有人按会议纪要更新。此时所谓“进度不准”，经常不是团队懒得更新，而是系统没有让更新变得有意义，也没有说明谁来确认更新。

2. 一个典型的跨部门计划失真场景

以一个 12 周的软件产品发布项目为例：产品团队计划第 3 周冻结需求，研发第 4 周启动，测试第 9 周介入，市场第 10 周制作上线材料。表面上每项工作都有日期；但如果需求冻结没有定义验收条件，研发启动的入口其实并不存在。研发开始后才发现接口口径未定，测试计划就会整体后移，市场物料也可能基于旧功能制作。

在这个场景里，计划软件至少要帮助团队回答四个具体问题：需求是否已达到启动条件；接口评审是谁负责、何时确认；某个延期会影响哪些后续节点；变更是否获得有权人的批准。只显示“完成百分比”，回答不了这些问题。

我会把计划可信度拆成三部分：输入是否完整、依赖是否显式、变化是否留痕。输入完整度不足，日期只是一种愿望；依赖没有表达，任务排序容易失真；变化不留痕，复盘时无法判断是估算偏差、执行问题还是决策延迟。

3. 100 人以上组织的计划难点更像治理问题

对中大型组织来说，团队规模扩大后，困难通常不只是“任务变多”。不同部门会使用不同粒度：产品按需求，研发按工作项，交付按客户里程碑，管理层按季度目标。若工具不允许这些层级建立清晰关系，管理者看到的汇总状态就可能与一线实际工作脱节。

因此，PingCode 这类面向研发项目协作的平台，评估重点不应只放在界面上，而要看需求、迭代、项目和团队之间能否形成一致的跟踪链路。对于 100 人以上的组织，我还会重点核查权限层级、工作流治理、跨项目报表、数据导入导出和管理员工作量。能不能把任务放进去，与能不能长期维护组织级口径，是两件不同的事。

三、常见误区：漂亮的计划图不等于可执行的计划

1. 误区一：把甘特图当成项目管理本身

甘特图适合观察时间关系，但它不是计划质量的证明。任务名称含糊、估算没有依据、依赖关系靠口头补充时，图表依然可以画得很整齐。更重要的是，甘特图上的日期是否能被实际团队承诺，取决于工作范围、可用资源、交付标准和审批节奏。

我会要求项目负责人拿出一项关键任务，现场解释它的完成定义、前置条件、责任人、估算依据和验收人。如果这些问题无法回答，再精致的时间线也只是展示材料。尤其在范围不稳定的探索型项目中，过早锁定过多日期会制造虚假确定性。

2. 误区二：任务越细，计划越准确

把每项工作拆到半小时并不自动提高准确性。过细的任务会增加维护成本，且频繁调整让团队把更新视为行政负担。反过来，任务只有“做研发”“完成测试”，又无法识别阻塞点。拆解粒度应服务于控制决策：能否发现偏差，能否明确责任，能否采取纠正行动。

一个实用的拆解判断是：如果任务完成与否会触发不同的管理动作，就值得单独跟踪；如果多个子任务由同一个人连续完成、期间不需要检查点，也不影响其他团队，则可以合并。不同项目的粒度不必完全一致，但同一层级的任务最好使用相近的估算单位和验收语言。

3. 误区三：买了工具，团队就会主动更新

工具上线后，更新率低的原因常是流程设计不合理。例如，一线成员要在多个系统重复录入，管理层又只在周会上问状态，大家自然会把“维护系统”看成额外工作。解决办法不是再加提醒，而是减少重复输入，并规定状态变化要触发什么后续动作。

我会追问：任务关闭后是否自动更新里程碑？阻塞状态由谁处理？计划变更由谁批准？管理者看到的汇总数据是否能追溯到任务级证据？如果答案不明确，问题在治理，不在提醒次数。

4. 误区四：把所有部门塞进同一套工作流

统一工具不等于所有团队必须使用同一套字段、状态和审批。研发团队关注待办、迭代和缺陷，市场团队关注素材、审批和投放窗口，交付团队关注客户里程碑和验收。若强行统一，会出现字段堆积、状态含义模糊，最后每个团队又私下维护自己的表格。

更稳妥的做法是统一少数管理层共用的定义，例如项目名称、负责人、目标日期、风险等级和状态更新时间；团队执行层则保留必要差异。软件需要支持的是“共同可读”，而不是“形式完全相同”。

5. 误区五：只比较订阅价格，不算维护成本

软件成本至少包括订阅、实施配置、数据迁移、培训、集成、管理员维护和流程变更。低月费若导致大量人工汇总，整体成本未必低；功能丰富的系统若只有一名管理员会配置，管理员离职后也可能迅速退化。

我建议把成本统一换算到年度，并单独估计每月维护工时。比较时不必假装能精确预测所有费用，但要明确哪些是合同费用，哪些是内部人力。对有多个团队的组织，管理员与项目运营的持续投入往往比首次导入更容易被低估。

四、专业判断逻辑：用六道关口筛掉不合适的工具

1. 先界定计划对象和项目类型

选型前，先写清楚你在管理什么：一次性项目、持续运营工作、产品研发、工程交付，还是多项目组合。一次性项目看里程碑和责任清晰度；研发看需求与执行项之间的关系；项目组合还要看优先级、资源冲突和跨项目依赖。对象不同，软件的“好用”含义也不同。

我会选择一个真实且具代表性的项目，而不是拿最简单的内部小任务做演示。样本应包含至少一个跨团队依赖、一个审批节点、一个可能变更的需求和一个管理层汇总要求。这样才能暴露工具对复杂流程的实际承载能力。

2. 把必须满足的约束写成测试场景

不要只列“要有甘特图、看板、报表”。应把功能需求改写成可验证场景，例如：“接口延期两天后，项目负责人能否看到受影响里程碑，并通知相关责任人？”“需求变更是否保留旧版本、批准记录和影响范围？”这会把讨论从功能名称拉回工作结果。

我建议把需求分成三层：必须满足、可以接受替代、暂时不需要。前者是采购门槛；第二层用于权衡；第三层防止演示阶段被功能堆叠带偏。每个需求还应指定验证人，避免采购、IT 和业务各自凭印象打分。

3. 检查依赖、基线和变更机制

项目计划的关键能力不只是设置日期，更是表达依赖和处理变化。试用时可创建一条从输入到验收的任务链，改变其中一个前置日期，观察后续任务是否可见地受影响、是否需要手动调整，以及系统是否保留变更记录。

如果组织需要正式计划基线，应确认产品当前版本是否支持相应能力，是否能比较计划与实际，以及权限如何控制。不要把“历史活动记录”误认为完整基线管理，也不要默认所有产品套餐都开放相同的高级功能。

4. 核对资源管理是否达到实际需要

很多团队把“负责人字段”误当成资源管理。真正的资源规划至少要考虑一个人同时承担多个任务时的容量、假期、技能或角色约束，以及冲突出现后由谁调整优先级。轻量团队可能只需负责人和每周容量；交付型组织则可能需要更系统的负荷视图。

不要为了追求高级资源图而把所有团队都引入复杂估算。先问管理决策需要什么：是否要识别过载？是否要做跨项目人员调配？是否要预测可交付日期？只有答案明确，相关能力才值得纳入采购门槛。

5. 验证权限、集成和数据可迁移性

项目计划可能包含客户信息、研发事项、预算和供应商资料。试用中要检查外部协作者权限、项目间数据隔离、角色管理和审计记录。对于中大型组织，还要确认单点登录、目录同步、数据导出、备份和合规要求是否符合企业政策。

集成也不能只看“有接口”。更具体的问题是：数据由哪个系统作为主数据源？同步是单向还是双向？失败后是否有告警？字段冲突怎么处理？如果计划工具和代码、工单、文件或财务系统之间没有清晰的数据边界，集成越多，重复数据越难治理。

6. 用小规模试点测算总拥有成本

试点不是让团队体验一下界面，而是测算能否稳定运行。建议选两到三个团队、一个真实项目周期，记录计划创建时间、每周维护时间、状态汇总耗时、重复录入次数和变更追踪完整度。试点结束后，再判断节省的时间是否足以覆盖培训、配置和管理成本。

我会特别关注“例外处理成本”：延期、范围变化、负责人替换和权限调整时，是否需要管理员介入。顺利路径容易演示，异常路径才暴露系统是否适合组织。没有经历过至少一次真实变更的试用结果，通常不足以支持规模化采购。

五、六款软件逐一拆解：优势之外更要看边界

1. Microsoft Project：适合正式排期，不应只为甘特图采购

Microsoft Project 的典型优势是传统项目排期逻辑清晰，适合把任务、持续时间、依赖、里程碑和资源放到较正式的项目控制框架中。对于工程项目、系统实施、客户交付和 PMO 场景，团队如果已经采用阶段评审和基线管理，通常更容易理解它的价值。

它的边界在于：企业要先弄清楚购买的是哪种当期产品形态，计划协作需要怎样的许可，桌面使用、云端协同和组织级管理分别由什么能力承担。微软相关产品和套餐会演进，不应仅凭旧教程或旧版截图判断当前功能。

我会把它放在“正式排期和控制”需求较强的候选中，而不是默认推荐给所有小团队。演示时要用实际项目验证多人协作、基线对比、资源冲突和报表输出；若团队只是跟进几十个轻量任务，较重的计划方法可能带来不必要的维护负担。

2. PingCode：研发组织重点看链路与治理，而非只看任务板

PingCode 面向产品研发协作场景，适合把需求、项目、迭代和执行工作放在一条工作链上观察。对于中大型企业和 100 人以上组织，价值要从跨团队协作、组织级权限、状态口径和管理视图评估，而不是只看某个团队能否快速创建任务。

我建议研发组织在试点中选一条真实需求，从提出、评审、拆解、迭代执行到验收，检查每一步的数据是否能追溯。还要观察产品负责人、研发负责人和管理层是否能从同一组信息得到各自需要的视图，而不必再维护一份汇总表。

需要谨慎的地方是：组织级平台的效果依赖工作流治理。若不同团队对“完成”“延期”“阻塞”的定义都不同，单靠平台不会自动统一管理口径。正式推广前应指定流程负责人，限制无治理的自定义字段增长，并明确模板和权限由谁维护。

3. Asana：跨部门任务透明，复杂治理要核对具体套餐

Asana 的常见优势是让团队围绕任务、负责人、截止日期和项目状态协同，适合市场活动、业务运营、跨职能计划和内部项目。对不希望先建立复杂项目管理体系的团队，任务可视化和协作入口往往更容易被接受。

选型时，我会用一个含有多个团队、多个里程碑和审批依赖的项目做演示，确认团队能否快速看懂责任归属，以及变更是否能传递到相关工作。自动化规则、组合视图、目标管理或高级权限等能力，应逐项核对当期方案，而不能只凭产品介绍页上的功能总览判断。

如果公司要求高度定制的研发工作流、细粒度资源容量规划或复杂项目基线管理，Asana 未必是最自然的起点。它更适合把协作任务组织清楚；若计划控制要求进一步提高，应验证是否需要外部系统配合。

4. monday.com：配置灵活，但灵活性需要负责人

monday.com 的工作板和配置思路适合流程差异较大的业务团队。不同团队可以按各自场景设置字段、视图和状态，这种灵活性在流程仍在探索、需要快速调整时有吸引力。

但灵活配置也会产生治理成本。若每个团队都创建自己的字段和状态，管理层很快会遇到相同含义有多个名字、报表无法横向比较的问题。因此我会在试点前先定义哪些字段必须共用，哪些允许团队自定，再观察配置维护是否需要专职管理员。

它适合重视工作流可配置性的组织，不代表可以不做流程设计。测试时还要核实自动化规则的额度、集成限制、权限边界和模板维护方式。团队若没有明确的流程所有者，先追求高度自由，往往会把统一管理变成清理配置的长期工作。

5. Smartsheet：表格熟悉度高，重点防止“表格孤岛”

Smartsheet 对习惯用表格组织项目的人较友好，也适合把数据收集、表单、审批和项目视图结合起来。许多业务团队可以较快理解行、列、状态和责任人，尤其是项目台账、资源请求或多方填报这类流程。

风险是团队可能把表格界面当成继续复制旧表的理由：一个部门一张表，一个项目一份副本，最后仍然没有唯一可信的数据源。试点时要追踪同一项工作是否被多次录入、跨表引用是否稳定，以及权限能否限制敏感信息。

如果项目依赖复杂、涉及大量跨项目资源平衡，应实际验证其计划模型能否满足要求，而不是从“表格看起来熟悉”推断高级控制能力也够用。表格形式降低了入门门槛，却不会自动解决数据标准和依赖管理。

6. Jira：研发执行很强，组合规划要看当前能力边界

Jira 常被研发团队用于工作项和迭代执行。如果团队已经用它管理需求、缺陷和开发任务，继续在同一环境中衔接项目计划，可以减少上下文切换。但“已经用了 Jira”并不等于“已经具备完整的项目组合规划”。

应核实所需的路线图、跨项目计划、层级关系和依赖能力对应哪个产品版本或套餐，且现有工作流是否能与计划视图保持一致。若计划数据只能靠人工维护另一套汇总，工具仍然没有形成闭环。

它更适合有成熟研发工作流、愿意维护项目配置的团队。对非技术部门而言，工作项字段和状态可能过于工程化；如果只是为了统一品牌或减少软件数量而强推使用，团队可能转向私下表格，反而降低数据可信度。

7. 横向对比时，先看限制条件再看功能清单

我会把六款产品放进同一组测试场景，而不是分别看供应商演示。对照时重点检查：计划建立是否快、依赖是否清楚、变更是否能追踪、跨团队是否能协作、汇总是否能追溯、管理成本是否可控。分数只作为讨论工具，不能替代硬门槛。

这个权重是建议基准，不是适用于所有企业的行业标准。研发组织可以提高工作链路和集成的权重；工程交付团队可提高依赖、资源和基线权重；小团队则应提高易用性和维护成本的比重。权重背后的业务原因，比最终分数更值得记录。

六、具体案例与数据观察：用试点记录，而不是宣传语下结论

1. 用一个 12 周发布项目建立可复用的试点

前面提到的发布项目可以作为工具试点模板。先建立 30 到 50 个代表性工作项，覆盖需求、设计、开发、测试、审批和发布；指定真实责任人，设置必要依赖；再安排一轮范围变更和一次前置任务延期，观察系统如何反映影响。

观察时不要只问参与者“喜不喜欢”。我会记录五类行为数据：首次建立计划所需时间、每周状态更新所需时间、信息重复录入次数、变更影响识别耗时、管理层汇总准备时间。每项都要注明统计口径，例如计时范围是否包含会议、人工校验和异常处理。

下面的数字是为了说明如何读试点结果而构造的情景模拟，不是某款软件的真实测试成绩。实际项目中应保留原始记录，并区分工具影响、团队熟练度和流程调整带来的变化。

这组情景数据想说明的不是“某工具能节省多少工时”，而是试点应该把结果落到可观察行为上。即使汇总时间缩短，如果变更记录完整率没有提升，管理层仍可能依据不完整信息做决策；反过来，维护时间稍有增加，但风险暴露更早，也可能是值得接受的代价。

2. 识别“看起来改善”的假象

试点前后比较容易受到学习效应影响。第一次使用新工具，成员需要熟悉界面；试点后期，他们已经掌握流程，时间下降不一定全由软件带来。若同时调整了会议制度、负责人或项目范围，也要记录这些变化，不能把所有改善归到系统。

我会给每个指标写明分母和观察周期。例如“变更留痕完整率”要定义抽查了多少次变更、何种材料算完整；“状态更新率”要说明延期任务是否也计入。没有口径的百分比看起来精确，实际无法比较。

还要关注反向指标：新增字段数量、每周管理员处理请求量、因权限问题等待的时长、系统与旧表之间的差异次数。如果效率指标变好，但管理员负担不断增加，这个方案可能只把维护工作从项目经理转移给平台管理员。

3. 把“试点成功”定义成可决策的门槛

试点开始前，项目发起人和团队应约定成功条件。比如必需的依赖变更场景通过，关键角色能在无需额外培训的情况下完成日常更新，数据可以导出，维护工时不超过组织可接受范围。门槛应写成可验证事实，而不是“大家觉得不错”。

如果某项功能演示失败，不一定马上淘汰产品。先判断它是产品缺口、套餐限制、配置错误，还是团队流程尚未定义。不同原因对应不同成本：套餐限制可能增加订阅费用；配置错误可能需要实施支持；流程缺失则需要管理决策。把原因分开，才能做合理取舍。

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

1. 小团队、项目少、需求变化不频繁

如果团队人数较少、协作边界清晰、同时维护的项目不多，我建议先从轻量方案开始。把目标、里程碑、任务负责人、关键依赖和风险放在一个可信空间里，保持更新规则简单。此时不要为了资源矩阵、组合管理和复杂审批提前支付学习成本。

取舍是：团队可能需要接受部分高级管理能力不足，但换来更低的维护门槛。只要项目数量增加、跨团队依赖变多，或管理层开始要求统一汇总，就应重新评估，而不是不断给轻量工具叠加人工表格。

2. 研发团队已经有稳定的需求和迭代流程

若团队的主要工作是产品研发，先看现有工作流是否需要与项目计划连通。已有研发系统且数据成熟时，优先验证计划视图能否复用工作项；若当前需求、迭代和项目状态分散，可以评估 PingCode 等研发协作平台，把重点放在需求追踪、跨团队治理和组织级报表。

取舍是：研发平台的流程一致性可能改善，但迁移历史数据、调整字段和训练团队都需要投入。不要一次性把所有团队、所有历史项目搬入新系统。先以新项目试点，确认链路稳定后，再决定哪些历史数据有持续使用价值。

3. 工程、交付或 PMO 强依赖排期和资源

如果项目涉及严格里程碑、外部交付承诺、人员容量冲突和正式进度报告，应优先验证 Microsoft Project 这类传统计划工具的实际版本和治理能力。测试应包含关键路径、基线、资源冲突、状态更新和偏差报告，不要只展示任务条和日期。

取舍是：管理深度可能意味着更多计划纪律和培训。若团队没有人维护估算、依赖和进度基线，系统能力会闲置；应明确项目经理或 PMO 的责任，并把更新融入既有节奏，而不是依赖偶尔的集中填报。

4. 跨部门业务协作多，执行流程变化快

市场、运营、人力、法务等部门如果需要共同完成活动或流程项目，可重点评估 Asana 与 monday.com 的协作和配置方式。前者适合围绕任务与项目组织协作；后者适合流程形式需要由团队调整的场景。Smartsheet 则适合团队依赖表格收集和管理项目数据的情况。

取舍是：协作灵活度越高，标准化越需要有意识地建立。建议统一项目命名、负责人、状态定义和关键日期，其他执行字段允许团队按需使用。先统一最少的共同语言，不要一开始就要求所有部门彻底同构。

5. 组织已有大量工具，不希望再增加孤岛

如果公司已经有代码管理、工单、文档、聊天和财务系统，不要先问哪个计划软件功能最全，而要画出数据流：任务事实在哪里产生，项目状态在哪里汇总，审批在哪里留痕，管理层从哪里读取。新工具应减少重复录入，或者明确成为某类数据的唯一来源。

取舍是：集成项目可能比购买订阅本身更耗时。优先连接高频、关键的数据链路，不必追求所有系统实时双向同步。双向同步看似完整，却会扩大字段冲突、权限和故障排查成本。

6. 有严格安全、权限或本地部署要求

若项目资料涉及敏感数据、客户信息或行业合规要求，安全和部署方式应成为前置门槛，而不是最后一轮附加题。请由 IT、安全和法务共同核对身份管理、审计、数据保存、备份、区域限制、导出和合同条款，并让供应商对关键要求给出可留存的书面答复。

取舍是：满足治理要求可能缩小候选范围，也可能带来更高的实施和运维成本。不要用“暂时没人要求”替代风险评估；也不要假设本地部署天然更安全，最终仍要看补丁、备份、权限和运维责任是否有人承担。

7. 最后用一张决策清单安排下一步

1. 选一个真实项目，明确目标、团队范围、依赖关系和必须交付的结果。

2. 把最关键的五个使用场景写成现场测试步骤，指定业务、IT 和安全验证人。

3. 从六款候选中筛出两到三款，不先追求全员试用，避免比较标准不断变化。

4. 试点期间记录建立计划、更新状态、识别变更、准备汇总和处理异常所需的时间。

5. 把订阅、培训、迁移、集成、管理员维护和退出成本合并评估，再决定采购范围。

6. 指定流程负责人、数据负责人和权限管理员，约定试点后复审日期，避免工具上线后无人治理。

八、结论：好计划软件不是把未来画得更漂亮，而是让变化更早暴露

1. 把选择标准从功能数量改成计划可信度

六款产品各有适用场景：Microsoft Project 偏正式排期和控制；PingCode 适合研发工作链路与中大型组织协作；Asana 适合跨团队任务协同；monday.com 强调可配置工作方式；Smartsheet 适合表格驱动的项目台账与流程；Jira 更适合已有研发工作项体系的团队扩展计划能力。

这些判断不是绝对排名。套餐、集成、安全要求和组织成熟度都会改变结论。最可靠的做法，是先定义业务约束，再用同一组真实场景测试产品，并清楚记录哪些能力已经验证、哪些仍需供应商书面确认。

2. 下一步：用一次真实变更做决策

如果你准备开始选型，下一步不必先预约六场产品演示。先找一个近期会发生变化的项目，选出一条关键依赖链，写下日期变动后需要通知的人、需要重新审批的事项和管理层要看到的结果。再让候选工具处理这次变化，比较发现影响、确认责任和留下记录分别需要多少步骤。

我认为最值得购买的不是功能最多的系统，而是能让团队更早看见风险、用更少重复劳动维护同一份计划，并且在出现例外时仍说得清“发生了什么、影响了谁、下一步由谁决定”的系统。只要把这个标准贯穿试点和采购，工具比较就不再是品牌印象或演示效果的竞赛，而会变成对组织真实工作方式的验证。