解锁项目管理新境界：2026年进度计划横道图软件选型指南

解锁项目管理新境界：2026年进度计划横道图软件选型指南

项目计划画成横道图后，延期依旧层层传导，通常不是图表不够漂亮，而是计划没有连接任务依赖、责任人、实际进度和变更记录。选进度计划横道图软件，我的核心判断是：别先比谁的功能最多，先看它能否让团队持续维护一份可信的计划。对于2026年的选型，最稳妥的路径不是拿一张“软件排行榜”直接采购，而是先定项目场景，再用真实项目试跑，最后核算协作成本、迁移成本和长期使用成本。

一、先给结论：选软件，先选一套能被团队持续执行的计划机制

1. 横道图不是项目进度管理本身

横道图通常以任务为纵向条目、以时间为横向尺度，帮助读者理解任务何时开始、何时结束，以及当前大致推进到哪一步。它对排期沟通很有用，但不会自动回答三个更棘手的问题：任务为什么延期、延期会影响哪些后续工作、谁应在什么时间更新实际进度。

如果团队把软件当作“自动生成进度图的工具”，很容易得到一张精致但过时的图。如果软件能把计划任务、负责人、依赖关系、实际状态和调整记录连在一起，横道图才有机会成为日常管理的入口。决定软件价值的不是横条能不能拖动，而是计划变动之后，相关人能不能及时知道下一步要做什么。

2. 先判断自己需要的是“排期工具”还是“项目控制工具”

如果团队只需要快速分解任务、安排开始和结束日期、给同事查看，轻量工具或表格可能已经够用。采购复杂平台未必能带来相应收益，反而可能增加培训、权限配置和数据维护负担。

如果项目存在多团队依赖、关键节点约束、计划基线、频繁变更，或者管理者需要同时看多个项目，就要验证工具是否能处理更复杂的计划逻辑。这里要注意：产品有横道图视图，不代表它一定具备依赖分析、资源统筹、基线对比或项目组合管理能力。每一项都应在当前版本和对应套餐中单独核实。

3. 选型结论应当来自真实项目试跑

产品演示通常展示最顺畅的操作路径，但采购决定应该基于团队自己的任务结构和协作习惯。至少找一个包含真实负责人、前后置任务、延期可能性和变更记录的项目样本，邀请项目负责人、执行成员和管理者分别试用。

如果参与者只能在演示会议里理解界面，却无法在一周后独立更新任务，这通常说明工具或流程与团队的实际工作方式不匹配。试用要记录操作耗时、重复录入、状态更新及时性和信息遗漏，而不只是收集“界面好不好看”的印象。

这个表格不是功能排名，而是需求映射的起点。真正的选型对象应是“软件能力与团队工作流程的组合”，而不是孤立比较产品宣传页上的功能数量。

二、横道图软件为什么容易选错：从一张图到一套工作流程

1. 计划表格能展示日期，却未必能解释日期

在早期项目中，团队常用电子表格维护任务名称、计划开始日和结束日。这种做法便宜、熟悉，也便于临时调整。但一旦任务之间存在依赖，改一个日期就可能需要人工检查多行计划。修改者如果只更新自己负责的部分，后续负责人看到的可能仍是旧时间。

这不是表格天然不能用，而是计划的关系复杂度超过了人工维护能力。若团队只有十来项相对独立的任务，表格通常足够；若一个里程碑牵连多个团队、变更频繁且需要追溯，就应重点评估依赖联动、更新责任和变更记录。

2. 横道图可能只是“汇报视图”，而不是执行入口

有些团队每周由项目经理手工整理一次进度，再把横道图放进汇报材料。图能让管理者快速看到日期，却不一定能让执行成员顺手更新状态。项目经理因此成了唯一维护者，团队越大，信息汇总越依赖一个人。

我会把“谁更新、在哪里更新、何时更新”作为选型时的必问项。若执行成员需要在工具之外重复填表，或者每次变化都由项目经理转录，那么系统虽然有计划视图，信息流却仍然断开。

3. 项目变复杂，真正增加的是协调成本

多团队项目的难点并不只是任务数量变多，更重要的是依赖关系、负责人变化和信息传递路径变多。一个任务延期，如果没有清晰的后续影响提示，团队可能要靠会议逐个确认受影响节点。此时，横道图的价值应体现在降低“查找影响和重新对齐”的成本，而不是在屏幕上塞入更多任务条。

因此，评估时应模拟一次真实变更：让一个前置任务延后几天，观察系统能否显示关联任务、提醒相关人员、保留变更记录。若系统只改变一条横条的显示位置，却无法帮助团队处理由此产生的协调工作，它的计划能力仍然有限。

4. 工具上线后，数据质量会决定图表可信度

横道图显示的内容来自输入数据。任务没有明确负责人、完成定义不一致、实际开始日期长期不更新，都会让管理者误以为计划准确，实则只是信息不完整。选型时应同时检查数据维护机制：哪些字段必填、状态如何定义、延期由谁确认、历史计划是否保留。

把数据规范留到上线之后再讨论，往往会把工具问题和管理问题混在一起。较稳妥的做法是先定义最小数据集：任务名称、负责人、计划日期、状态、依赖关系、实际进度和变更原因。不同项目可以增加字段，但核心口径应尽量统一。

三、五个常见误区：功能看起来齐全，不等于适合你的项目

1. 误区一：功能列表越长，软件越适合复杂项目

功能数量很容易比较，日常维护成本却常被忽略。一个团队可能需要依赖管理，却不需要财务预算；另一个团队可能需要基线比较，却不需要精细到小时的工时统计。选型表中如果所有功能都等权打分，最终容易被“功能多”而不是“关键任务做得好”带偏。

建议把能力分成三层：必须具备、最好具备、当前不需要。必须具备的项目，一旦缺失就会阻断日常流程；最好具备的项目，可以通过试点衡量收益；暂时不需要的能力，不应成为当前采购溢价的主要理由。

2. 误区二：支持横道图，就代表支持完整的项目计划管理

“有横道图视图”只是一个界面特征。它没有自动说明任务依赖是否可配置、日期改变后是否重新计算、实际进度能否与基线对照，也没有说明资源冲突是否可见。把“能画图”当作“能管理项目”，会造成能力期待与实际使用之间的落差。

演示时不要只看拖动任务条是否流畅，应要求演示人员用你的样本完成一整条操作路径：创建任务、指定负责人、设置依赖、修改计划、更新实际进度、查看受影响任务、导出或汇报。每一步都要确认对应能力在哪个版本提供。

3. 误区三：采购后自然会有人维护计划

工具不会自动形成更新习惯。没有明确更新频率，成员可能只在项目周会上补录状态；没有清晰的完成定义，“进行中”就可能被不同人理解为完全不同的进度；没有变更规则，项目经理会不断收到临时口头调整。

软件选型应与维护机制一起设计。至少明确任务负责人、更新时间点、状态含义、延期升级路径和计划基线规则。若组织暂时无法确认这些规则，先通过小规模试点建立共识，比一开始全员铺开更稳妥。

4. 误区四：只比较软件订阅价格，不核算总成本

订阅费通常只是显性成本。实施配置、系统集成、权限梳理、数据迁移、培训、管理员维护和人员适应，都可能占用团队时间。价格低但需要大量手工维护的方案，长期总成本未必更低；价格较高的方案，也不一定能通过减少重复录入或降低协调时间收回成本。

我建议至少分别估算首年一次性投入和后续年度投入，并把不同角色的工时纳入。不要把所有成本都压成一个金额，否则很难看出费用来自哪里，也无法在试点后判断收益是否成立。

5. 误区五：看一次演示，就能判断实际体验

演示环境里的数据通常结构清楚、任务命名规范、权限简单。真实项目却会遇到任务重复、成员兼职、计划频繁调整、不同团队使用不同术语等情况。演示能验证产品是否具备某项功能，不能充分验证团队能否持续使用。

把试用环境交给不同角色操作，尤其要观察执行成员完成日常更新需要几步、会不会重复录入、手机或其他常用工作入口是否方便。项目经理觉得好用，不代表成员愿意更新；管理者看得见数据，也不代表一线信息足够及时。

四、专业选型逻辑：从需求边界走到可复核的决策

1. 先给项目分型，不要用一张表评估所有团队

我通常先按计划复杂度，而不是按行业名称，给项目分型。行业标签容易带来刻板印象，同一行业里的项目也可能完全不同。一个研发团队可能只做短期独立任务，也可能负责多个版本、跨部门发布和高频依赖；工程项目则可能有严格里程碑与审批约束。

项目分型可以先看四个变量：任务之间的依赖数量、参与团队数量、计划变更频率、是否需要管理多个项目。变量越高，对关系管理、变更追溯和跨项目汇总的要求通常越高。不要用规模一个维度替代复杂度判断。

2. 把需求写成可测试的场景

“需要甘特图”“要好用”“支持协作”都不是足够清晰的选型需求。它们不能直接判断功能是否满足，也很难在试用后复盘。把它们转换成动作和结果，例如：“前置任务日期改变后，负责人能够看到相关后续任务，并且项目经理可以追溯变更原因”。

每个需求都应能对应一个试用动作和一个判断标准。若需求无法转化为可观察结果，可能还需要继续澄清。这样做也能减少供应商演示时出现“功能名称一致，实际口径不同”的误会。

3. 给关键需求加权，但让权重能解释

评分不是为了制造精确幻觉，而是帮助团队把偏好说清楚。可以把依赖管理、更新体验、权限、安全、集成、部署和成本列入评分，并依据当前项目的风险设权重。权重应由项目负责人、执行代表、IT或采购相关人员共同确认，不宜由一个人凭印象决定。

评分完成后，单独检查“关键短板”。某候选工具即使总分高，如果缺少组织不可妥协的部署要求，仍应淘汰。加权总分适合比较可选方案，不能覆盖硬性约束。

4. 区分产品能力、组织流程和人的习惯

试点失败时，不能马上断定“软件不行”。也可能是项目没有明确负责人、状态口径不一致，或管理者要求成员重复更新多个系统。相反，流程设计得很好也不代表产品适配：如果工具无法表达必需的依赖关系，团队只能用备注绕开限制，迟早会增加维护成本。

复盘时把问题分为三类：产品能力缺口、配置或流程问题、使用习惯问题。只有第一类通常需要更换候选工具；第二类可能通过配置或职责调整解决；第三类需要培训、管理约定和持续反馈。分类后再决定是否淘汰，能减少冲动采购。

5. 明确否决条件和可接受妥协

选型会议容易把所有诉求都列成“必需”，但这会让团队找不到真实方案。建议提前区分硬性否决项与可接受差异。例如，特定部署要求可能是硬门槛，某种视图样式可能只是偏好；关键数据无法迁移可能不可接受，个别报表需要手动导出则可能能接受。

妥协应有边界，也应有负责人。若方案靠增加人工工作绕开产品限制，就要把额外工时算进成本；若功能暂时不具备但可以通过管理规则补足，应设定复核日期，避免临时办法永久化。

五、具体场景推演：以一支跨部门团队的计划迁移为例

1. 先声明案例口径，避免把模拟写成实测

下面是一个用于演示选型方法的情景模拟，不代表某家企业的真实项目数据，也不是任何产品的性能测试。设定一支约120人的中大型组织中，一个跨部门项目组由产品、研发、测试、运营和采购等角色组成；项目包含约80项任务，计划周期12周，每周至少一次状态调整。

假设原有计划分散在表格、会议纪要和即时沟通中。这里的关键问题不是“表格能不能画横道图”，而是项目负责人需要花多少时间收集状态、任务延期后能否识别影响，以及不同成员是否能在各自工作入口维护信息。

2. 用问题而不是品牌标签筛选方案

在这个场景里，我会先把必须验证的事项设为五项：是否能表达任务依赖；是否能分辨计划日期和实际进展；延期后是否能定位后续影响；能否按角色控制访问范围；能否减少成员重复填报。只满足横道图展示，不足以通过这轮筛选。

如果团队正在评估适合中大型企业使用的项目管理平台，可以把PingCode纳入候选考察范围。它是否适合某个团队，仍需要按当前版本、套餐、部署条件和组织流程逐项验证；不能仅凭产品类别或宣传描述得出适配结论。尤其应在试用中检查项目计划与日常任务管理之间的衔接，以及所需能力是否包含在拟采购方案内。

这个建议不意味着某个平台适合所有大组织。大型组织的差异往往体现在权限模型、系统集成、安全要求、采购流程和已有管理规范上。一个团队可用的配置，不代表另一个事业部也能直接复制。

3. 试点观察应记录过程指标

情景模拟中可以设定试点前后都记录同一组观察项，例如项目经理每周汇总进度所需时间、成员重复录入次数、延期任务被相关负责人确认所需时间。这里不预设软件一定能改善指标；试点的意义就是测量实际变化，并确认变化来自工具、流程调整还是团队成员熟悉度提升。

为避免试点前后口径不同，至少保持项目类型、观察周期和统计方式一致。如果试点期间恰好赶上项目低峰，或者临时减少了参与人员，数据不能直接说明工具效果。对外发布效率提升比例时，更应说明样本、统计口径和影响条件。

4. 如何判断试点“值得继续”

不要只问参与者喜不喜欢，也要问计划可信度是否提高、关键风险是否更早暴露、成员是否更少重复劳动。试点成功并不一定意味着每个指标都改善，而是至少要看到对组织最重要的两三项指标有可解释变化，并且没有引入难以接受的安全、迁移或维护问题。

若成员觉得更新步骤变多、计划仍要靠项目经理二次整理，就应查清问题发生在哪个环节。可能需要简化字段、调整通知方式，也可能说明工具不适合现有工作入口。若成本增加但关键依赖关系变得可见，也要和管理层讨论这种收益是否值得投入，而不是仅凭单项成本做决定。

5. 试点数据不是宣传数字

试点记录首先服务内部决策，不应用小样本直接外推到整个组织。一个项目的进度汇总时间下降，可能受项目经理个人习惯影响；少数成员更新及时，也不代表全组织都能做到。要推广到多个部门，建议增加项目类型和角色样本，并记录实施前后的流程变化。

对外使用数据时，应该写清“哪个团队、观察多久、用什么口径、比较什么状态”。若数据是模拟或目标，不要包装成客户案例或实际提升结果。选型内容的可信度，来自边界交代清楚，而不是数字看起来足够漂亮。

六、两周试用计划：把产品演示变成可复核的测试

1. 第1至第2天：准备真实样本和问题清单

选择一个规模适中、但能代表真实复杂度的项目。样本最好包含前置任务、跨团队交接、一个重要里程碑，以及至少一项可能发生调整的工作。避免使用过于简单的演示项目，否则无法检验工具真正的适用边界。

准备一份基线记录表，写明任务数量、负责人数量、当前维护方式、更新频率、项目经理汇总耗时和重复录入环节。若组织有部署、安全、权限或数据保存要求，也要在试用前列出来，以免测试结束才发现基础条件不符。

2. 第3至第5天：验证建计划和更新流程

让项目负责人建立计划，让执行成员更新任务，让管理者查看项目状态。重点观察任务字段是否足够、常用操作是否顺手、不同角色能否找到需要的信息。若某项操作需要培训，可以记录学习前后的差异，但不要把“看过一次演示”视为完成学习。

还应测试日期调整后的影响。挑选一个前置任务，故意修改其计划结束日期，查看系统是否提示依赖任务变化、能否保留调整记录，以及相关人员是否能够收到信息。这个测试通常比浏览功能菜单更能暴露流程上的真实差异。

3. 第6至第8天：模拟延期、资源冲突和跨团队交接

挑选一项任务模拟延期，让团队按照实际升级机制处理。记录从发现、评估影响、确认新日期到通知相关成员的时间。若工具支持依赖可视化，检查它显示的是直接依赖还是完整影响链条；若没有相关能力，记录团队是否能接受人工补足。

再模拟一次人员冲突：同一负责人在相邻时间段承担多项关键任务。不要只看有没有“资源管理”标签，而要确认容量的计算单位、假期或兼职安排是否可表达、冲突提示是否足以支持决策。如果产品没有资源负荷能力，也要判断这是否是你的硬性需求。

4. 第9至第10天：核对数据导入、权限和退出方式

用现有计划文件做一次导入，再将关键数据导出，检查任务名称、日期、负责人、状态和依赖关系是否能够正确保留。不要等合同签署后才发现导出格式不满足归档或迁移要求。对于已有系统集成，也要验证接口范围和费用，而不是根据“可集成”三个字作判断。

权限测试应覆盖项目成员、管理者和临时协作者。确认他们分别能看到什么、修改什么、导出什么。组织还需要了解数据保存地点、备份和删除方式、管理员权限以及安全承诺的适用范围，具体以供应商当前正式材料和合同为准。

5. 第11至第14天：复盘数据，形成继续或停止的决定

将试点观察数据与基线对照，说明口径、样本和偏差。除耗时外，还要记录信息遗漏、任务状态滞后、重复录入、培训问题和维护责任。若试用期间有流程变更，要把变化单列，不要把所有改进都归因于软件。

最后做三种判断：继续试点、进入采购评估、停止当前候选。继续试点适用于有价值但仍需验证的能力；进入采购评估适用于关键流程已通过且组织条件清楚的方案；停止则适用于硬性要求不满足、核心流程绕行过多或总体维护负担不可接受的方案。

七、成本与风险取舍：别只看报价单上的席位价格

1. 总拥有成本至少要拆成五项

做成本比较时，我会把支出拆为订阅或许可费用、实施配置费用、集成和数据迁移费用、培训费用、内部管理维护工时。部分费用一次性发生，部分会按年度持续；如果把它们混成一个总额，管理层很难判断成本上升的原因。

还要明确报价口径：按用户、功能模块、存储、部署方式还是服务范围计费？免费试用是否有功能限制？更改用户数或增加部门会不会触发新套餐？这些信息更新较快，正式决策前应以供应商当期官方报价、合同和书面说明为准，并记录核实日期。

2. 把人工维护折算为可比较的成本

如果目前由项目经理每周花数小时收集进度，可以将时间折算为人力成本，但要避免把所有节省下来的时间都视为现金收益。更准确的说法是：团队减少了某类重复操作，为风险识别、沟通或项目交付释放了时间。

相反，如果工具上线后要新增管理员、定期清洗数据、维护集成或人工补录字段，这些都是持续成本。即使报价单看起来更便宜，只要长期依赖大量人工绕行，整体经济性也可能不理想。

3. 数据迁移与退出能力也是采购成本的一部分

选型往往只讨论如何上线，很少讨论如何离开。项目结束后需要归档，组织调整可能要求迁移到其他系统，合同到期也可能需要完整导出。应提前确认导出格式、字段范围、附件处理、历史记录、删除政策和服务终止后的数据处理方式。

迁移测试最好覆盖一次完整的小样本，而不是只导出一张简单任务列表。若任务依赖、状态历史、负责人和附件无法保留，数据表面上迁出，业务上下文却可能已经丢失。退出成本越高，越应该在采购前把相关条款和技术路径写清楚。

4. 识别工具带来的新风险

统一平台可以减少信息分散，但也可能让更多敏感信息集中存储。部署方式、账号生命周期、外部协作者权限、审计记录和备份恢复，都应由组织的相关负责人核验。不要只依赖产品页面上的通用安全表述，应确认具体版本、具体服务范围和合同承诺。

另一类风险是“看板依赖”：团队把所有状态都压缩成一个颜色或百分比，管理者据此做判断，却不清楚数据是否及时、分母如何计算、任务完成定义是什么。可视化提升了可见性，但也放大了错误数据的影响。工具上线后，仍要建立数据口径和复核机制。

八、不同团队的行动建议：按复杂度做选择，不按流行度做选择

1. 小团队、短周期、依赖较少：先控制工具复杂度

如果项目成员少、任务关系简单、计划变更不频繁，优先选择容易建立和共享计划的方式。先确认现有表格或轻量工具是否已能满足版本管理、责任分配和进度更新。只有当人工维护开始造成明显重复劳动或信息滞后时，再考虑增加系统复杂度。

此类团队应把验证重点放在上手时间、共享方式、导出能力和基础状态更新。不要因为大组织使用复杂平台，就推断小团队也需要同样的管理层级。少即是多，前提是必要信息没有遗漏。

2. 跨部门项目：优先检查依赖和变更是否可追踪

多个团队共同交付时，软件价值通常来自协作关系，而不仅是任务展示。建议重点测试依赖变更、责任人确认、通知触达、不同团队权限和会议后任务更新。若延期只能靠项目经理逐个私聊确认，工具可能没有真正接入执行流程。

这类团队应挑选有代表性的跨部门项目试点，邀请不同部门成员参加。若各部门工作习惯差异大，可以先统一核心字段和更新规则，再逐步配置差异化视图，不必一开始把所有流程强行标准化。

3. 中大型组织：把组织治理和项目体验同时纳入评估

中大型组织的选型需要同时考虑一线使用和组织级管理。权限、账号生命周期、数据治理、系统集成、部署、安全审查、审计能力和供应商服务，都可能成为采购门槛。管理层需要看到跨项目信息，但不能因此忽略成员日常操作是否繁琐。

如果组织正在评估PingCode等服务于中大型企业和百人以上组织的项目管理平台，可以把它放进候选清单，结合部门真实样本做验证。需要确认当前产品能力、套餐边界、部署选项和合同承诺是否符合组织要求。适合中大型组织的定位不是适配证明，只有需求逐项匹配并通过试点，才能形成采购依据。

4. 强监管或数据敏感场景：先过门槛，再谈便利性

若项目涉及敏感数据、严格审计或特定部署要求，应先把安全、数据保存、权限控制和服务承诺列为硬性筛选条件。不要先按界面体验打分，最后才让安全团队审查；这会造成前期投入白费，也可能让采购时间线失控。

在满足硬性要求的候选方案中，再比较成员体验、依赖管理、汇总视图和成本。与其追求功能齐全，不如优先选择组织能够稳定治理、能够持续更新且退出路径明确的方案。

5. 已有多个管理系统：优先验证数据衔接，不要重复造入口

如果团队已经有任务系统、工时工具、文档平台或企业身份管理系统，应先画出数据流：任务在哪创建、进度在哪更新、汇报数据从哪里来、人员权限由谁管理。再确认横道图工具是作为主系统、计划层还是汇总层使用。

集成不应只看“是否有接口”，而要核实同步方向、字段映射、更新冲突、失败重试、权限继承和维护责任。若两套系统都允许修改同一字段，却没有明确主数据源，最终可能出现计划日期互相覆盖。必要时先只读接入或小范围同步，降低风险。

九、最终取舍：决定买什么之前，先决定不为哪些能力付费

1. 为高风险场景付费，不为抽象的“全面”买单

选型不是找一款能满足所有想象需求的软件，而是用合理成本降低当前最重要的项目风险。对依赖关系复杂的团队，可靠的变更追踪可能比花哨视图更重要；对多项目组织，权限与汇总能力可能比单项目中的个性化样式更重要；对小团队，快速上手可能比高级资源分析更有价值。

采购前可以写下三项最重要的业务结果，以及三项不能接受的风险。所有功能都应回到这些结果和风险上解释。若某项能力没有清晰的使用场景、责任人和验证方式，它就不应自动进入“必须购买”的清单。

2. 接受合理妥协，但不要接受不可见的人工绕行

任何工具都有边界。团队可以接受某些报表需要额外整理，也可以接受特定角色需要培训，但要清楚知道这些妥协会增加多少工作、由谁承担、何时复查。不可接受的情况是：关键能力缺失，却长期靠私人表格、口头通知和项目经理手工拼接维持计划。

如果人工绕行不可避免，应在试点期间记录频次与工时，再决定是接受、调整流程，还是更换方案。成本透明的妥协，往往比看似功能完整但实际不可维护的选择更稳健。

3. 用“可退出、可复盘、可扩展”作为长期判断标准

一个好方案不只要能上线，还要能被组织复盘和调整。数据能否导出、权限是否可治理、部门扩展时成本是否可预测、管理员离职后能否交接，都会影响长期可持续性。采购文件中应尽量记录当前核实的版本、套餐、功能范围和限制，避免几年后只剩口头印象。

项目管理方式会变，组织结构也会变。与其把软件选型当作一次性的“定终身”，不如设置复核节点：试点结束后复盘一次，规模扩展后再复盘一次，续约前再检查使用率、维护成本和数据质量。这样才能避免工具从帮助项目，变成新的管理负担。

4. 下一步可以这样做

如果你正在准备选型，我建议今天就建立一张需求与验证表，先填入项目类型、任务依赖、参与角色、更新频率、部署要求和预算边界。随后挑一项真实项目，确定三到五个必须通过的测试动作，并指定项目负责人、执行成员和管理者参与。

试用结束后，不要只写“推荐”或“不推荐”，而应留下能被复核的结论：哪些流程通过、哪些能力有条件通过、哪些风险不可接受、哪些成本仍待确认。横道图软件选型的终点不是买到一张更漂亮的计划图，而是让计划、执行、变化和决策处在同一条可追踪的信息链上。