选对工具事半功倍：2026年计划进度图软件选购指南

计划进度图软件最容易买错的地方，不是少了几种图表，而是团队把“画出一张计划图”误当成“项目已经可控”。我做项目工具评估时，通常先问三个问题：任务之间有没有真实依赖，进度变化能不能追溯，负责人能不能在不额外做一份周报的情况下更新计划。只要其中两项答不上来，软件再漂亮，也可能只是把原来的表格换了个界面。

选对工具事半功倍：2026年计划进度图软件选购指南

一、先讲核心结论：买的是计划控制能力，不是图表数量

1. 计划进度图软件的价值，取决于计划能否持续更新

我判断一款计划进度图软件是否值得选，不会先数它有多少种甘特图样式，而会沿着一条工作链检查：任务如何拆分、依赖如何建立、工期由谁估算、进度如何更新、变更如何审批、风险如何暴露、实际结果如何复盘。只要这条链断在某处，图表就很难反映真实工作。

因此，采购目标不应是“让计划看起来专业”，而应是“让负责人更早发现计划正在偏离，并且知道该由谁采取什么动作”。对小团队来说，简单的任务表加时间轴可能已经够用；对多部门、多项目、依赖关系复杂的组织，真正重要的是计划与执行数据能否贯通。

2. 先按计划复杂度选工具，再按品牌和界面筛选

我会把候选方案分成三类：轻量时间轴工具、专业排程工具、带项目协作与治理能力的平台。第一类适合短周期、低依赖、单一团队的安排；第二类适合关键路径、资源约束和基线管理要求较高的项目；第三类则更适合多个团队共同交付，需要统一状态、责任、风险与汇报口径的组织。

没有哪一类天然“最好”。如果团队只是要把活动排到日历上，复杂的排程平台会增加输入负担；如果项目跨部门并且上游交付会影响下游窗口，单纯的可视化时间轴又可能让风险被隐藏在漂亮的色块里。

3. 选型先设门槛，再比较分数

我建议先设不可妥协的门槛，再做加权评分。比如，任务必须可以建立前后依赖；负责人要能看到自己的待办；计划变更必须保留历史；项目数据要能导出；权限需要覆盖外部协作方。候选工具若过不了硬门槛，就不应靠界面美观或折扣补分。

通过门槛后，再比较排程能力、执行协同、汇报成本、集成与治理、总拥有成本。评分表是帮助团队说明取舍的工具，不是把复杂决策伪装成一个精确数字。权重、门槛和试用结果都要能追溯。

二、背景和真实场景：为什么一张进度图经常越画越不可信

1. 计划失真往往从输入方式开始

很多团队的计划从一张电子表格起步，早期看起来十分有效：负责人手动填日期，项目经理每周收集状态，再把变化改到时间轴上。问题出现在项目开始并行、任务依赖增多之后。更新日期的人不一定是执行人，日期变化没有解释，已完成任务和被阻塞任务又使用同一套“百分比完成”表达，图就逐渐变成管理者希望看到的样子，而不是团队实际发生的样子。

这不是表格天然有错，而是维护机制不再适合规模。只要任务由多人共同更新、依赖需要计算、进度变化要留下依据，靠一个人汇总的方式就会形成瓶颈。换工具前，先判断工作流是否需要改变；否则只是把原来的手工维护搬到新软件里。

2. 看起来只有一个日期，背后可能有四种不同含义

计划中的“完成日期”经常混合了承诺日期、当前预测日期、基线日期和实际完成日期。四者若被放进同一个字段，项目复盘时就分不清：团队是按时完成，还是事后把计划日期改成了实际日期？工具必须支持团队清楚区分这些口径，至少要能保留原始承诺与变更历史。

我会建议团队把“计划基线”和“当前预测”分开看。基线是经过确认后用于衡量偏差的参照；当前预测是根据最新进展推算出来的未来状态。若计划一直被覆盖更新，表面上日期总是绿色，实际却失去了衡量项目偏差的尺子。

3. 计划图不是排期会议的替代品

工具可以展示依赖、冲突与日期变化，但无法自动替团队决定谁有权调整范围、哪些质量检查不能压缩、哪个外部承诺必须优先。若这些决策规则没有明确，项目成员就会在系统里不断改日期，最终得到一份每个人都能编辑、却没人真正负责的计划。

所以，我会把选型和计划治理一起讨论：谁建立基线，谁确认任务工期，谁批准关键节点变化，谁负责更新实际进展，什么时候必须升级风险。软件在这里提供的是证据和流程载体，不是责任本身。

4. 多团队环境中的计划，通常是依赖网络而非一条时间线

一个产品上线可能同时依赖需求确认、设计评审、开发完成、环境准备、数据迁移、客户验收和运营培训。每条工作线都可能有自己的负责人和节奏。项目经理真正要管理的不是一排横条，而是前置条件、决策节点、资源窗口和外部承诺之间的关系。

在这类场景里，计划图如果只展示“谁在什么时候做什么”，不显示“为什么这项工作现在不能开始”，就很难帮助团队协作。选型时要把真实项目里最麻烦的依赖拿来试，而不是只用三五条虚拟任务检查界面。

三、常见误区：界面漂亮，不等于排程可靠

1. 把甘特图当成计划管理的全部

甘特图擅长展示任务跨度和时间重叠，但它不能单独解释范围是否完整、工期依据是什么、资源是否可用，也不一定能表达所有复杂约束。图上的条形整齐，不代表项目已经有可执行的交付路径。

试用时不要只看能否拖动日期。要检查是否能建立依赖类型、是否能识别关键路径或关键节点、改动是否留下记录、是否可以查看基线与预测差异。若工具不提供某项能力，也要判断团队是否真的需要，以及有没有明确的替代控制方式。

2. 把“完成百分比”当成客观进度

“完成了80%”听起来精确，但如果没有统一的计量方式，不同负责人对80%的理解可能完全不同。有人按投入时间估算，有人按任务数量统计，有人只看主观感受。项目越复杂，单一百分比越容易掩盖未完成的关键工作。

对可交付成果清楚的任务，我更倾向于用可验证状态：未开始、进行中、待验收、已完成，并补充阻塞原因和预计完成日期。确有必要使用百分比时，应规定口径，例如按已验收工作量或可核验的工作包计算，而不是让每位负责人自行定义。

3. 把自动排程误解为自动决策

自动排程可以依据任务关系、日历和工期重新计算日期，但输入若不准确，计算结果只会更快地产生错误。比如任务估时未考虑评审等待、节假日设置错误、资源能力没有维护，系统给出的日期再整齐也不可靠。

我会把自动排程视为“影响计算器”，而不是“项目经理替代品”。试用时主动制造一个真实变化：把关键前置任务延后一周，观察系统能否指出受影响任务、关键节点和资源冲突；再检查负责人能否理解为什么日期变化。只显示新日期，却解释不了传导原因，仍然不够。

4. 只比较订阅价格，不核算总拥有成本

采购报价只是成本的一部分。实际成本还包括管理员配置、模板维护、数据迁移、权限设计、用户培训、集成开发、历史数据清理和持续运营。工具若需要项目经理每周额外维护数小时，省下的订阅费可能很快被隐性工时抵消。

我通常要求试点期间记录“每个项目每周维护时间”和“生成管理报告所需时间”。这些数据比单纯比较用户单价更接近真实成本，因为软件最重要的长期成本，常常是使用者持续投入的时间。

5. 先买全员账号，再想怎么推动采用

有些组织把上线等同于开通账号，随后才发现执行人不愿重复录入，管理者继续用旧表格汇报，项目经理则要在新旧系统之间做双份维护。用户数量增长并不等于采用成熟，真正要看的是关键进度信息是否在工作发生的地方被及时更新。

更稳妥的做法是先确定试点项目和最小流程，明确哪些信息只录一次、哪些角色必须更新、哪些管理动作依赖系统数据。只有当试点能够减少重复汇总并形成稳定习惯后，才考虑扩大范围。

6. 只让项目经理参加产品演示

项目经理关注全局视图和汇报效率，执行人关心任务更新是否方便，职能经理关心资源冲突，管理者关心组合层面的进度与风险。只让单一角色试用，容易买到“演示时很顺、日常中没人愿意用”的工具。

我建议至少让项目负责人、任务执行人、资源或职能管理者、系统管理员参与试用。每个角色都要完成真实动作，而不是只坐在会议里观看销售演示。

四、专业判断逻辑：用一套可复现的标准做选型

1. 先盘点工作形态，不先问“要什么功能”

列功能清单很容易越列越长，最后每个候选工具都有一项看似必需的特色功能。更有效的起点，是描述实际项目：有多少项目并行，任务平均有多少层，哪些依赖最常改变，谁维护计划，外部协作方是否参与，管理层需要什么频率的预测。

建议从过去三个月挑出三个项目：一个按期完成，一个延期明显，一个跨部门依赖最多。不要只选最顺利的项目，否则试用无法暴露边界。整理出真实任务、关键日期、负责人、依赖和两次重要变更，作为所有候选工具的同一套测试数据。

2. 用硬门槛筛掉不适配方案

评分之前，我会先设置“必须满足”的条件。以下门槛可以作为讨论起点，但应按组织实际调整：

• 关键任务能指定负责人、工期、起止日期和依赖关系。
• 计划日期调整能够保留变更记录，至少能区分基线与当前预测。
• 管理者与执行人可以使用合适的权限查看或更新信息。
• 项目数据能够以可用格式导出，避免被单一工具锁定。
• 试点范围内的用户能在实际工作流程中完成更新，而不依赖额外的人工代录。
• 部署方式、数据存放、账号管理和安全要求符合组织的合规标准。

有些需求不适合做硬门槛。例如，特定颜色主题或某一种汇报样式，可能只是偏好。把偏好写成“必须”，容易误导采购并延长评估时间。

3. 通过同一套任务情景做横向测试

我不建议让不同供应商各自挑一套最适合展示的样例。准备一份相同的测试脚本，要求每个候选方案完成同样的操作：建立任务层级、添加依赖、设置里程碑、录入基线、更新实际进展、推迟一个关键任务、检查下游影响、输出管理视图。

测试要记录完成时间、出错次数、需要管理员帮助的步骤，以及任务执行人是否能独立完成。尤其要关注失败路径：权限不足时会发生什么，任务日期冲突如何提示，导入字段不匹配时是否可恢复，离职人员的任务如何交接。

4. 把评分权重与项目目标绑定

下面是一份可调整的评分框架。总分可以用来缩小候选范围，但必须同时保留每项评分的证据与备注。比如“依赖管理得4分”需要说明具体测试了什么，而不是只写评审者觉得好用。

权重不是标准答案。例如，强监管项目可能把治理与审计提高到20%以上；以创意制作排期为主的团队，可能更重视日历视图和交付审批。权重应来自项目失败的代价，而不是功能听起来有多先进。

5. 试点必须验证“更新成本”和“风险发现速度”

在一到两个真实项目中试用，至少观察两个完整更新周期。统计每周实际维护时间，记录从风险出现到管理者看见风险的时间，并比较旧流程的手工汇总耗时。若工具让信息展示更集中，却没有缩短反馈链或减少重复录入，试点价值就需要重新评估。

试点不应只看项目经理是否满意。执行人可能觉得任务更新麻烦，管理员可能发现权限配置复杂，职能负责人可能看不到资源冲突。把这些反馈分角色记录，能避免由单一决策者替所有用户做判断。

五、案例与数据观察：用一次模拟试点看清“好用”的含义

1. 案例背景：跨部门上线计划为什么不能只看延期天数

下面是用于说明选型方法的情景模拟，不对应任何企业的真实披露数据。设想一家有120名员工的企业，产品、研发、测试、交付和客户成功团队需要共同完成一个季度版本上线。计划包含约90项任务、12个主要里程碑，另有3个客户验收窗口。

项目早期使用共享表格。项目经理每周收集状态，平均需要约6小时整理一次汇报；延误通常在周会前后才被集中发现。管理层看到的是“整体完成度”，但关键依赖的等待时间、待验收工作和客户侧窗口变化没有统一口径。

这里的“6小时”和后续对比数字均为情景模拟的演示参数，并非某个组织的实测结果。实际试点应由团队记录时间戳、更新次数、任务历史和报告生成时间，不能把示例数值直接当成采购收益承诺。

2. 试点任务：重点测试变更影响，而不是演示建图速度

测试先用同一份任务清单建立计划，再选取一个真实会影响验收窗口的开发任务，将其预测完成日期推迟五个工作日。观察系统是否显示受影响的测试、部署和客户验收任务；是否区分原始基线与当前预测；是否能指出新的关键节点；负责人能否说明调整原因。

随后让执行人直接更新阻塞状态，让项目经理从同一份数据生成管理视图。这样可以同时检验“任务更新是否方便”和“汇报是否仍需手工二次加工”。如果只验证项目经理可以画图，测试就没有覆盖系统是否能成为日常工作入口。

3. 用可量化指标评价试点，不用“感觉顺手”做结论

建议从四组指标观察：维护成本、数据及时性、风险可见性和决策支持。维护成本包括每周手工汇总时长与重复录入次数；数据及时性可以看任务实际变化到系统更新的间隔；风险可见性可以看关键阻塞出现到相关负责人收到提醒或在例会上被识别的时间；决策支持则看预测日期与实际结果的偏差。

不要把指标变成追责工具。若执行人因为担心延期被处罚而延迟更新，数据会更差。试点阶段应鼓励诚实报告风险，并关注问题是否更早暴露、是否更快找到解决负责人。

上表是建议试点目标的情景模拟，不是软件效果保证。不同项目的更新频率、工作节奏和基线成熟度差异很大。重点是试点前先约定计算口径，试点后按同一口径复算，不要为了证明工具有效而临时更换指标。

4. 如何解释结果：节省时间不等于项目自动按期

假设试点后每周汇总时间下降，但关键风险仍然在节点临近时才出现，说明工具可能减少了汇报工作，却没有改善风险前置识别。若风险暴露提前了，但执行人维护计划的时间明显增加，就要进一步检查字段设计、通知频率和输入入口。

同样，按期率提高也不能简单归功于软件。范围变更减少、管理层及时决策、团队增员或项目难度较低，都可能影响结果。更稳妥的做法是记录同期变化，并用多个项目、多个更新周期交叉观察，不把单个项目的偶然结果包装成确定收益。

5. PingCode适合放在什么位置评估

当选型问题从“如何画一张计划图”扩大到“多个团队如何围绕工作项、状态、责任和交付信息协同”时，可以把PingCode作为项目管理平台方向的候选对象之一进行试点评估。对于100人以上、中大型企业组织，试用时尤其要观察跨团队协作、信息口径、权限治理和管理视图能否匹配现有流程。

我不会因为平台覆盖的协作范围更广，就默认它一定适合所有排程场景。若团队的核心需求是复杂资源受限排程、严格的关键路径分析或特定工程进度控制，仍应拿这些真实场景直接验证，必要时与专业排程工具进行对照。选型结论应来自测试结果和组织约束，而不是平台类别或功能宣传。

六、不同情况下的行动建议：先做小试点，再决定部署规模

1. 小团队、单项目、低依赖：先控制维护成本

如果一个团队只有少量并行任务，任务之间大多互不依赖，项目周期短且变更容易口头协调，优先选择上手快、共享方便、提醒清楚的轻量方案。先验证团队能否在一个迭代或一个交付周期内持续更新，再决定是否需要更复杂的排程能力。

不要因为未来可能扩张，就立即购买所有高级功能。可以把数据导出、字段定义和迁移能力作为预留空间，避免轻量工具成为无法退出的封闭系统；但现在不用的复杂功能，不必成为当前选择的主要理由。

2. 跨部门、任务相互依赖：优先验证变更传导

这类项目要把真实依赖关系放进试用数据。除了看日期能否自动调整，更要看上游任务延迟后，哪些下游工作受影响、哪些工作可以并行、哪个里程碑会被推迟、负责人是否收到明确提示。

如果关键节点变化需要人工逐项检查，就要估算这种检查的频率和风险。工具未必必须具备所有高级排程功能，但团队必须知道哪些传导可以自动识别、哪些仍然需要项目经理判断，并为人工判断保留明确责任人。

3. 多项目共享人员：先找资源冲突，再谈组合报表

多项目组织容易出现“每个项目都安排合理，合在一起却不可能同时完成”的情况。选型时应把同一名关键人员放入两个项目，安排重叠任务，检查系统是否能发现冲突、是否能让职能负责人看到负荷、是否能区分硬性承诺与可调整计划。

若组织还没有统一的人员可用性数据，不要期待工具单独解决资源冲突。先明确工时日历、兼职比例、休假来源和优先级规则，再测试工具能否呈现这些输入。错误的资源数据会产生貌似精确、实际误导的负荷图。

4. 面向客户或供应商协作：优先做权限与责任测试

外部协作的首要问题不是对方能不能看到漂亮的时间轴，而是能看到什么、可以修改什么、谁批准变更、合作结束后如何撤销访问。试点应使用非敏感数据，模拟新增、调整和移除外部账号，检查历史记录与权限边界。

如果外部协作方只需要接收里程碑状态，可能不需要开放内部任务细节。按最小必要原则设计视图，能减少敏感信息外泄，也能避免外部用户误改内部排程。

5. 受监管或数据敏感组织：把合规列为硬门槛

此类组织应在产品演示前准备安全与采购问题清单，包括部署方式、数据存放与备份、账号身份管理、权限审计、数据导出、删除与留存策略、供应商服务支持和合同条款。相关要求应由安全、法务、采购和业务负责人共同确认。

不要仅凭演示环境或销售口头说明作判断。涉及数据处理与合规的结论，必须以组织适用的正式材料和评审结果为准；如果某个要求无法满足，应尽早淘汰候选方案，而不是在业务试点后才发现。

七、不同情况下的取舍：越复杂的系统，越要证明它值得复杂

1. 易用性与控制深度之间的取舍

功能丰富通常意味着更多字段、规则和权限。对成熟项目管理团队来说，这些控制可以提升一致性；对刚开始建立计划习惯的团队来说，可能变成额外负担。判断标准不是“功能多不多”，而是团队目前是否有能力维护这些功能依赖的基础数据。

如果执行人需要经过多层页面才能更新一个阻塞原因，工具的控制能力可能反而拖慢反馈。反过来，如果字段过少、变更没有记录，管理者也会失去必要的追溯能力。试点应同时测量任务更新用时与信息完整度，寻找够用而不臃肿的配置。

2. 自动化与人工判断之间的取舍

自动提醒、日期推算和汇总可以减少重复操作，但过多自动通知会导致提醒疲劳，未经核实的自动排程也可能制造错误确定性。应该自动化的是重复、规则清晰、输入可靠的工作；涉及优先级、范围取舍和承诺变更的决定，仍要由有权限的人做出。

对每一项自动化，最好问三个问题：触发条件是否稳定、错误结果是否容易发现、是否能撤销或修正。若自动化结果不能解释，且修正需要管理员介入，就要谨慎扩大使用范围。

3. 单一平台与专业工具组合之间的取舍

单一平台的优势是信息集中、权限和协作口径较统一；代价可能是某个专业环节不够深入。专业工具组合能满足特定排程、成本或工程要求，但会带来数据同步、身份管理、报表口径和接口维护成本。

不要为了“一个系统包打天下”牺牲关键能力，也不要为了每个团队都拥有最熟悉的工具而接受无限集成。先确定哪一份数据是权威来源，哪些数据可以复制，谁负责接口异常，以及系统中断时如何继续工作。

4. 统一标准与团队自主之间的取舍

统一模板有利于跨项目比较，但不同类型的工作未必能使用完全相同的阶段与状态。若标准过于僵硬，团队可能在线下另做一份“真正可用”的计划；若完全不设标准，管理层又无法比较项目风险。

较稳妥的方式是统一少量核心字段，例如负责人、状态、预测日期、基线日期、风险和交付物，再允许各业务团队增加本地字段。跨项目汇总的字段应有清晰定义，避免同一个“完成”状态在不同团队中代表不同事情。

5. 价格低与长期可维护之间的取舍

低价方案不一定便宜，高价平台也不一定带来回报。真正需要比较的是总拥有成本和风险成本：订阅费用、实施费用、迁移工时、日常维护、培训投入、集成成本、切换成本以及因信息延迟造成的决策代价。

评估时可将所有成本折算到一个明确周期，例如一年或一个项目周期，并记录数据来源。若无法量化延期损失，就不要虚构一个巨额收益来支持采购；可以先量化确实发生的人工工时、重复录入和报告等待时间。

八、上线与复盘：把工具采购变成可验证的管理改进

1. 上线前先定数据口径和责任人

至少要定义任务状态、基线日期、当前预测日期、实际完成日期、风险等级和变更原因。每个字段都要回答：谁录入，何时更新，谁审核，缺失时如何处理。字段越多不代表管理越成熟，定义不清的字段只会增加噪声。

还要明确哪些项目必须使用系统，哪些工作可以暂时保留在原有流程中，以及谁有权建立或修改项目模板。统一范围比一次性追求全员覆盖更重要。

2. 先做有边界的试点，避免双系统长期共存

选择一个重要但可控的项目作为试点，确定开始与结束时间、参与角色、观察指标、成功门槛和退出条件。旧流程可以作为短期对照，但必须明确何时停止重复维护，否则团队会把试点变成长期双录。

试点开始前记录基线：每周汇总工时、关键任务更新延迟、管理报告生成时长和现有数据缺失比例。试点结束后使用相同口径复测，才能判断改善是否来自流程与工具变化。

3. 以异常样例验收，不只以正常流程验收

验收时测试延期、负责人变更、任务拆分、外部依赖取消、人员冲突、权限撤销和数据导出等异常情景。正常流程容易演示，真正决定长期可用性的，往往是遇到变化时系统能否留下清晰记录，并帮助团队恢复计划。

还要安排一次“故意犯错”的测试，例如把任务日期设到非工作日、导入重复任务、移除关键用户或制造依赖循环。系统若只能在理想输入下运行，组织就需要评估额外的校验与管理成本。

4. 复盘时区分工具问题、流程问题和数据问题

当任务更新不及时，不应立刻归咎于执行人。可能是提醒方式不合理，也可能是状态字段设计复杂、负责人没有更新权限，或者流程规定每周才更新一次。复盘时把问题归到工具、流程、数据、角色和激励五类，再决定修复方式。

若主要问题是负责人不清楚、工期缺少依据或变更没有审批权，单靠增加提醒不能解决。相反，若责任明确但信息要在多个入口重复录入，集成或简化字段才可能真正降低负担。

5. 扩展部署要以可复用模板和持续运营为条件

试点成功不等于全组织部署已准备好。扩展前应整理标准模板、字段字典、角色权限、培训材料、数据迁移规则、支持机制和版本更新责任。组织规模越大，越需要明确谁维护这些标准，以及业务团队如何申请调整。

建立定期复盘机制，检查项目预测偏差、任务更新延迟、基线变更频率、报告人工整理时间和用户反馈。若指标长期没有改善，应重新评估配置和使用场景，而不是简单增加培训或要求团队“更认真使用”。

九、选购清单：把最后的决策落到可执行动作

1. 供应商演示前准备这份问题清单

• 能否区分项目基线、当前预测和实际完成日期？历史变更如何查看？
• 任务依赖是否能呈现影响关系？变更后能否检查里程碑和下游任务？
• 任务负责人能否用最少步骤更新状态、阻塞原因和预测日期？
• 多项目视图是否能发现共享人员冲突？需要哪些准确的资源数据？
• 报告是否直接使用任务数据，还是仍然需要手工导出、拼接和修订？
• 外部用户、临时成员和离职人员的权限如何管理？
• 数据如何导入、导出、备份和删除？发生切换时如何迁移？
• 初始实施、内部管理员、培训、集成和持续支持分别需要投入多少？

让供应商用团队提供的真实、脱敏样例回答问题，并要求现场完成关键操作。只看功能清单，无法判断操作步骤、权限边界和实际维护成本。

2. 试点结束后按结果做去留判断

如果关键依赖和变更历史能够被可靠管理，执行人愿意更新，管理报告减少人工拼接，且实施成本在团队可承受范围内，可以进入有限扩展。若图表更漂亮但信息仍靠人工汇总，或任务更新负担显著增加，应先调整配置或流程，而不是直接扩大采购。

如果组织的核心排程约束超出候选工具能力，合理结论也可能是保留现有方案、引入专业排程工具，或把计划治理和协作平台分层处理。不买某个工具，同样是一种有效的选型结论。

3. 下一步怎么做

我建议本周先完成三件事：选出一个延期项目和一个依赖复杂项目；整理任务、里程碑、责任人、基线和最近一次变更；约定试点指标与硬门槛。随后用同一份数据评估两到三类候选方案，而不是先看演示再临时编测试题。

计划进度图软件真正的价值，不是让项目看起来更有秩序，而是把变化更早变成团队能处理的信息。选工具时，优先寻找能缩短“变化发生，责任人知情，采取行动”这条链路的方案；做不到这一点，图表再完整也只是记录，不能替代管理。