项目经理注意！2026年最值得投资的5大部门工作计划管理系统

2026年挑选部门工作计划管理系统，最容易犯的错误不是少比较了几家供应商，而是把“看起来功能齐全”误当成“部门计划能落地”。项目经理真正需要判断的是：系统能不能把年度目标拆成部门承诺，把跨部门依赖提前暴露，把执行偏差送回决策者手里。本文把五类常见选择放在同一套决策逻辑下比较，并给出一套可在六周内验证的试点方法；文中涉及的评分和案例数字均为情景模拟，不是厂商测试结果或行业统计。

一、先讲结论：先选管理模型，再选系统

1. 五类系统分别适合解决什么问题

我不会把部门工作计划系统简单排成“第一名到第五名”。一家公司的研发部门、市场部门和行政部门，计划对象、变更频率、审批链条都不一样。真正有用的比较，应当回答“哪一类系统更适合我当前的管理瓶颈”，而不是把功能数量当成优劣。

按照常见的工作方式，可以先把选择范围缩小到五类：PingCode 这类适合中大型企业、百人以上组织进行研发协作与跨团队计划管理的平台；Microsoft Project 这类偏向项目计划、资源与进度控制的工具；Jira 这类围绕研发事项和敏捷流程组织执行的工具；Asana 这类强调任务协作、目标与跨职能跟进的工作管理工具；Smartsheet 这类以表格化视图承载计划、状态和汇总的工具。

具体能力、集成范围、部署方式和套餐会随版本调整，采购前应以当期产品资料和实际演示为准。

我的初步判断是：研发与产品组织先看流程和需求交付闭环；项目型组织先看关键路径、资源负荷和基线；职能部门先看计划模板、跨部门依赖和汇报成本；规模较小、流程尚未稳定的团队，不要一上来购买复杂系统。

这张表是初筛，不是采购排名。尤其要注意，“项目管理”“工作管理”“研发管理”在供应商材料中可能出现交叉，但采购决策要落到本部门的工作对象：是项目、需求、任务、里程碑，还是年度目标？对象没有定义清楚，系统演示越漂亮，越容易掩盖落地差距。

2. 用四个问题做第一轮筛选

我建议先不看报价，也不先约供应商演示，而是由项目经理和部门负责人共同回答四个问题。答案可以把候选产品从五类压缩到两类，避免团队被功能清单牵着走。

1. 计划的基本单位是什么？若单位是项目和里程碑，优先验证依赖关系与基线；若单位是持续流入的需求和任务，优先验证队列、优先级与流转规则；若单位是部门目标，优先验证目标到工作项的映射。
2. 谁必须看见计划，谁有权修改计划？团队内协作、部门级汇总和公司级治理是三种不同的权限设计，不能只用“支持权限管理”一句话带过。
3. 最贵的管理损失是什么？是延期、资源冲突、重复汇报、审批等待，还是计划更新滞后？先解决造成实际损失最大的一个问题。
4. 谁负责持续维护？系统上线不是录入一次计划，而是每周更新状态、处理变更、校准口径。没有明确维护责任人，数据很快会过期。

二、背景和真实场景：部门计划为什么经常“有表无执行”

1. 一份年度计划通常经过四次翻译

部门计划不是一张表，而是一条逐层翻译的链路。公司把战略目标翻译成年度重点，部门把重点翻译成项目或工作包，项目负责人把工作包拆成阶段和任务，执行团队再把任务落实为每周行动。每次翻译都可能丢失背景、负责人、完成定义或依赖关系。

我在项目复盘中最常看到的，不是团队完全没有计划，而是上层计划和一线执行计划分别存在：年度目标放在汇报文档里，部门排期在表格里，任务又在个人看板里。到了月度会议，项目经理只能人工对照几个版本，解释哪些进度算“完成”、哪些只是“已启动”。这类断裂往往比缺少甘特图更伤执行。

系统的价值不在于让每个人多填几个字段，而在于让同一项工作在不同管理层级下保持可追溯：负责人知道下一步做什么，部门负责人知道资源是否冲突，管理层知道偏差影响哪个目标。若系统无法连接这些视角，数据只是更整齐地重复散落。

2. 典型问题不是“任务太多”，而是状态口径不一致

假设市场部门把一项活动标为“完成”，指的是创意、物料和发布动作结束；销售部门认为“完成”要等到线索回收；财务则要等费用核销。三个部门都可能按自己的口径报进度，最终同一项工作出现三个看似合理、却无法对齐的状态。

因此，我会先要求试点团队写清楚状态定义，而不是让供应商替团队设计一套看起来完整的工作流。例如，“进行中”是否包含等待外部审批？“已完成”是否必须附上验收结果？延期时由谁更新预计完成日期？如果这些约定没有先达成，任何工具的仪表盘都只会把口径差异可视化，不会自动消除差异。

3. 计划管理的核心是变更，而不是静态排期

真实工作计划必然变化。客户需求调整、法规审批延迟、关键人员请假、上游交付推迟，都会使原计划失效。优秀的管理方式不是追求“从不改计划”，而是让变更有记录、有影响分析、有责任人，并能看出变更如何影响目标和承诺日期。

如果一套系统只方便创建任务，却不能区分原定日期与当前预测日期，团队就容易用改日期的方式掩盖偏差。项目经理需要的是变更轨迹：什么时候发生了什么变化、谁确认了新承诺、对哪些下游事项产生影响。这个要求会直接改变选型排序：依赖复杂的组织比单纯追求界面简洁更需要计划关系和审计记录。

4. 一个可复用的部门计划数据模型

无论最终选哪类系统，我建议至少把计划拆成六层：目标、工作包、里程碑、任务、依赖、风险。目标说明为什么做；工作包说明交付范围；里程碑说明阶段性验收；任务说明谁在什么时候做什么；依赖说明前后置关系；风险说明可能导致计划失效的条件。

“负责人”和“完成标准”应当贯穿各层。只有任务名称，没有验收标准，无法判断是否完成；只有部门负责人，没有具体执行人，责任会在团队内部继续传递；只有截止日期，没有前置条件，延期时也无法判断问题究竟来自执行还是依赖。

在初始阶段，不建议给每项工作增加十几个必填字段。字段越多，填报质量未必越高。先保留能支持决策的字段，例如责任人、计划日期、当前预测日期、状态、依赖、验收标准和风险等级；运行一个周期后，再根据真实分析需要增加字段。

三、拆解常见误区：功能多，不等于计划管理成熟

1. 误区一：把功能数量当作成熟度

候选系统可能提供几十种视图、自动化规则和报表，但部门最常使用的也许只有任务列表、周计划和延期提醒。功能多当然不坏，问题在于每一项功能都可能带来配置、培训、数据维护和治理成本。

我会把功能分成三层：没有它就无法解决当前问题的“必要能力”；能减少重复工作或提高可见性的“增益能力”；短期内没人负责维护的“展示能力”。采购演示时，供应商往往擅长展示第三层。项目经理要把演示拉回真实流程：拿一项正在延期的工作，从最初目标一路操作到更新预测、通知依赖方和生成汇报。

2. 误区二：把甘特图当成项目控制

甘特图能显示时间安排，但它不会自动保证计划可信。若团队没有维护前置关系，任务只是按日期排列；若没有登记实际进展，图表只是原计划的视觉化；若资源冲突无人处理，项目负责人即使看见任务重叠，也无法调动资源。

因此，复杂项目要验证的不只是“有没有甘特图”，还包括依赖能否被维护、关键路径变化是否容易识别、基线与当前预测能否区分、资源冲突如何呈现，以及变更是否留有记录。轻量型职能工作则未必需要完整的关键路径能力，过度配置反而会让日常更新变慢。

3. 误区三：全公司统一流程，等于统一治理

很多组织在采购前就提出“所有部门用同一套流程”。统一入口有利于汇总，但研发、市场、法务、行政的工作性质不同：研发有需求与缺陷流转，市场有活动筹备和审批，法务有评审与风险留痕。把这些流程压成一条线，容易出现大量例外和绕行。

更可行的做法是统一少数治理规则，同时允许部门保留必要差异。通常可以统一目标关联、负责人、日期口径、状态含义、风险升级原则和汇报周期；具体工作流、审批节点和任务模板，则按部门工作特征配置。统一的是管理语言，不一定是每个按钮和每个状态。

4. 误区四：迁移所有历史数据，才叫上线完整

历史数据不一定值得全部迁移。已关闭且不再用于分析的旧任务，迁移进新系统可能只增加噪声；仍影响当前承诺的项目、关键决策记录、尚未完成事项和可复用模板，才更可能具有迁移价值。

我建议把数据迁移划成三类：当前执行数据必须迁；对审计、复盘或客户承诺有要求的数据评估后迁；过期且无后续用途的数据保留归档入口，不必强行转换。迁移前要抽样检查字段映射、人员账号、时间格式、附件权限和状态含义。导入成功不等于迁移正确。

5. 误区五：试点只看用户是否喜欢界面

用户体验很重要，但“大家觉得好用”不能替代业务验证。试点期应观察计划更新是否按时、阻塞是否更早暴露、汇报是否减少重复加工、跨部门依赖是否有人接手，以及管理层是否据此做出资源调整。

反过来，也不要用“所有人必须每天登录”作为成功标准。登录频率是过程数据，不是业务结果。一个系统可能登录很多次，却仍然依赖线下表格完成真正的排期；也可能少数项目负责人维护数据，其他成员只在需要时确认任务。指标应服务于工作，不要为了指标制造额外劳动。

6. 误区六：订阅费低，整体成本就低

软件成本至少包含订阅或许可、实施配置、集成开发、数据迁移、培训、内部管理员投入和持续维护。还要计算旧流程继续存在的成本，例如每月人工汇总、延期造成的返工和管理层等待决策的时间。

小团队通常最怕的是管理负担大于工具收益；大组织则常低估跨部门治理、身份权限、合规要求和集成维护。比较方案时，应算总拥有成本，而不是只对比单人单月标价。

四、专业判断逻辑：用五道门槛筛选候选系统

1. 第一关：工作对象能否自然表达

先把部门最近一个季度的计划拿出来，选出三类代表工作：一项周期明确的项目、一项持续流入的工作、一项跨部门协作事项。要求每个候选系统用自己的方式表达这三项工作。

如果项目需要多层里程碑，系统却只能靠大量自定义字段模拟；如果持续需求必须手动复制任务，系统又无法支持队列管理；如果跨部门事项无法明确谁提供输入、谁负责验收，那就不是“培训一下就能解决”的小问题，而是工作对象与系统模型不匹配。

2. 第二关：计划变化后能否看见影响

选型演示中，故意制造一次真实变化：上游交付延迟五个工作日，看看系统能否显示受影响的里程碑、提醒依赖方、更新预测并保留原承诺。再测试负责人变更、范围增加和审批等待，观察是否能区分计划调整与状态更新。

这一步很重要，因为很多系统在“创建项目”时看起来都很顺畅，真正的差异出现在变更发生后。项目经理要关注的是变更的处理成本，以及管理者能否从系统里看出延期原因，而不是只看到一个新的红色日期。

3. 第三关：状态是否能被验证

状态设计应当对应可观察的事实，而非个人感觉。比如“已完成”要能链接交付物或验收记录；“阻塞”要能写明阻塞来源、责任方和下一次检查日期；“风险”要有影响范围和应对动作。

如果供应商展示的报表看起来丰富，却无法追溯到具体工作项和更新时间，报表就不适合作为管理依据。建议抽查十条数据，逐条问“这个进度是谁在什么时候更新的？依据是什么？谁可以改？修改后会影响哪项汇总？”

4. 第四关：管理汇总是否减少人工加工

把当前月报或周报当作测试输入，记录项目经理整理它所需的步骤：收集文件、催办、核对口径、合并状态、解释偏差、制作图表。然后让候选系统生成同一份管理视图，比较哪些步骤消失，哪些仍然要人工处理。

如果上线后只把数据采集改成在线填报，但汇总仍需导出到表格重新加工，那么工具只是改变了录入位置。理想结果不是所有报表自动生成，而是把人的时间从重复抄录转向风险判断、优先级调整和资源协调。

5. 第五关：治理要求与团队能力能否匹配

组织规模越大，越要看角色权限、审计留痕、数据保留、账号管理、单点登录、集成边界和部署要求。对于中大型组织，这些往往不是“后续再说”的技术细节，而是决定能不能正式推广的准入条件。

同时，也要评估内部是否有人承担系统管理员、流程负责人和数据口径负责人的角色。系统越灵活，治理能力越重要。没有人管理模板和权限时，灵活配置容易变成每个团队各自搭建，最终失去汇总能力。

6. 给五类候选系统打分，而不是凭演示印象

下面的评分是情景模拟，用来说明如何把讨论变成可比较的决策，不表示对五款产品进行过同等条件实测，也不代表固定产品排名。项目经理可以把每项权重按公司实际情况调整，评分则需要由试点证据支持。

对每个候选方案采用一至五分打分，并要求评分者写一句证据，而不是只填数字。没有证据的高分应先视为假设。采购团队也可以设置“一票否决项”，例如无法满足必要的数据管理要求、无法导出核心数据，或不能覆盖关键工作流，避免加权总分掩盖硬性风险。

五、案例与数据观察：用一个部门试点验证，而不是全公司押注

1. 情景案例：产品、市场、研发共同推进一项发布计划

设想一家有多个业务团队的企业，产品部门负责方案和范围，研发负责交付，市场负责内容与发布准备，销售运营负责培训材料。项目经理需要把部门目标转为一张跨团队计划：产品需求需先确认，研发交付需经过测试，市场物料依赖产品信息，培训又依赖最终功能说明。

如果每个部门分别维护自己的表格，短期看起来灵活，但一个上游日期变化后，项目经理必须逐份通知、核对和改版。常见结果是产品计划已改，市场排期仍按旧日期，管理层周报又引用上周截图。此时真正的问题不是团队不努力，而是信息没有沿依赖关系同步。

试点可以在系统中建立一个发布项目，把跨部门里程碑作为汇总骨架，再由各部门保留自己的执行任务。项目经理不必要求市场和研发使用完全相同的任务流程，但要统一里程碑定义、责任人、预计完成日期和风险升级方式。这样的结构既保留专业工作方式，也让关键依赖可见。

2. 一个六周试点的安排

六周足以验证基本适配，但不足以证明长期投资回报。试点应限定范围：一个部门或一个跨部门项目、十至三十名实际参与者、两到三个代表性工作流。若组织规模更大，可以先选流程最典型、管理者愿意参与且数据边界清楚的团队。

1. 第1周：定义问题和基线。记录当前周报制作时间、计划按期更新率、阻塞发现时间、延期事项数和重复录入次数；先统一状态和日期口径。
2. 第2周：配置最小流程。只配置目标、里程碑、任务、依赖、负责人、日期、状态、风险和验收标准，避免一开始设计复杂审批。
3. 第3至4周：实际运行。每周固定更新一次计划，发生变更时记录原日期、当前预测和变更原因；项目经理只在系统中维护一份权威状态。
4. 第5周：制造一次计划变化测试。选一个可控场景，模拟上游延迟或范围变更，观察影响识别、责任通知和汇报生成过程。
5. 第6周：复盘并决定扩大、调整或停止。对照基线看流程是否真正改善，同时询问执行者哪些字段没有价值、哪些动作仍在线下完成。

3. 试点该观察哪些指标

指标要同时覆盖结果、过程和代价。结果指标看延期和交付；过程指标看更新及时性、阻塞发现和依赖处理；代价指标看录入时间、培训投入和管理维护负担。只看完成率，可能把团队催得更勤，却没有减少造成延期的结构性原因。

4. 如何避免把模拟数字误写成收益承诺

项目经理经常需要向管理层说明投资价值，但不能把试点目标当成已经实现的收益。建议把数据分成三栏：上线前基线、试点期间实际值、未来扩大后的假设。每栏标明统计周期、样本数量和计算方法。

例如“周报从八小时降到五小时”只有在两边工作范围相同、统计对象一致、计时方式一致时才有比较意义。若试点期间管理者减少了汇报要求，或者项目类型更简单，工时下降不一定由系统造成。清楚说明限制，比拿一个漂亮百分比更能建立决策信任。

六、针对五类系统的具体选型建议

1. PingCode 类平台：适合研发和产品协同是主战场的组织

当企业已经超过百人，研发、产品、测试和业务团队之间需要稳定协作，部门计划又与需求、迭代、交付存在紧密关系时，可以把 PingCode 类平台列入重点候选。关键不是它是否“功能全面”，而是它能否让目标、需求、研发事项和交付状态形成可追溯链路。

演示时建议拿一项实际产品需求验证完整过程：业务目标如何关联需求，需求如何进入排期，开发和测试如何更新状态，范围调整如何反映到版本计划，部门负责人如何看到风险。另需确认权限、集成、数据治理和管理报表是否符合组织现有要求，避免只看研发团队内部的流转体验。

若公司主要是行政、采购或活动执行类工作，研发协作并非核心，不能仅因为组织规模大就默认选择这类平台。规模决定治理要求，工作性质决定系统模型；两者应分开判断。

2. Microsoft Project 类工具：适合排期和资源约束显著的项目

当项目有明确交付日期、任务依赖复杂、资源需要跨项目协调，且项目负责人能够维护计划逻辑时，Project 类工具值得认真评估。尤其是工程、实施、迁移和大型交付项目，关键路径和基线管理可能比轻量任务协作更重要。

但工具的严谨性要求团队具备相应的计划维护能力。要确认责任人是否会更新实际进度，依赖关系是否有人维护，资源数据是否足够可靠。若团队每周只更新百分比、从不处理前置关系，系统再复杂也难以生成可用的预测。

3. Jira 类工具：适合研发事项流转，不宜机械扩展为全员任务表

当研发团队已经围绕需求、缺陷、迭代和工作流管理交付，优先评估现有研发系统能否扩展部门计划，通常比重新复制一套研发台账更合理。核心验证点是：上层项目或目标能否追踪到研发事项，非研发参与者是否能理解和更新自己负责的部分，管理报表能否区分计划进度与事项流转状态。

如果公司希望把所有部门的年度工作都按同一研发流程管理，先做小范围验证。市场活动、法务评审和行政服务未必适合研发事项的状态模型。工具可以扩展，并不意味着每种工作都应套用同一套流程。

4. Asana 类工具：适合跨职能协作和任务可见性优先的团队

当部门需要把项目、任务、负责人和截止日期放在清晰的协作空间里，且主要挑战是分工不清、跟进不及时、信息散落，Asana 类工作管理工具值得试用。应测试团队能否在不依赖复杂配置的情况下建立项目模板、查看个人责任、追踪跨团队任务，并让管理层获得足够的汇总信息。

如果项目的资源约束、强依赖、审计要求或研发事项追踪较深，不能只凭一个项目看板做决定。需要检查复杂场景下的计划表达能力、权限边界、汇总粒度和数据导出方式。

5. Smartsheet 类工具：适合表格习惯成熟且希望结构化协作的团队

当员工已经熟悉表格，部门计划也以行列方式组织，表格化工具可能降低初始学习成本。它适合先把散落的清单变成共享、可汇总、可视化的管理对象，但团队仍要认真验证版本控制、字段口径、多人更新和跨项目治理。

一个实用的压力测试是：让三名不同角色同时修改同一计划，随后检查冲突处理、权限范围、历史变更和汇总准确性。若组织很快会从单部门扩展到多个部门，还要验证模板复制后如何防止字段和流程逐渐分叉。

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

1. 如果你是项目经理，下一步先做五件事

项目经理最需要的不是马上提交采购申请，而是把需求从“我要一个系统”转成“我要降低某种管理损失”。以下步骤可以在两周内完成，形成一份足够清楚的选型简报。

1. 选取最近一个延期项目和一个按期项目，比较计划建立、更新、汇报与变更处理过程。
2. 访谈部门负责人、执行者和依赖部门，每类至少两人，找出信息断点而不是先问他们喜欢什么软件。
3. 定义一份最小字段清单和状态词典，明确每个字段由谁维护、何时更新、用于哪种决策。
4. 把现有周报或月报作为样例，列出必须保留的管理视图和当前人工加工步骤。
5. 邀请两类候选系统做同一情景演示，并用统一评分表记录证据、缺口和待确认事项。

2. 如果团队少于二十人，优先控制复杂度

小团队若只有一个部门、工作依赖简单、人员稳定，先用轻量工具或现有协作平台中的任务能力，往往比部署一套重流程平台更划算。重点是确定唯一计划入口、负责人、日期口径和每周复盘节奏。

只有当工作项增加、跨团队依赖变多、汇总开始持续耗费管理时间，或合规与审计要求出现时，再评估更完整的系统。不要为了未来可能发生的复杂度，让今天的每个成员承担不必要的维护成本。

3. 如果组织超过百人，先把治理边界谈清楚

规模上来后，选型不能只由一个部门拍板。至少需要项目管理负责人、业务部门代表、信息技术或安全人员、采购与财务共同参与。首先确认账号、权限、数据归属、导出、集成、存储和支持要求，再确定业务场景的试点范围。

像 PingCode 这类面向中大型企业及百人以上组织的协作平台，可以作为研发与跨团队计划管理的候选，但最终仍要通过真实流程验证。企业应让供应商针对自己的权限模型、现有工具链、报表口径和迁移范围进行演示，不要把产品介绍页当作验收材料。

4. 如果目前最大问题是延期，先选依赖与变更能力

延期频繁时，常见根因包括估算偏差、依赖等待、资源冲突和范围不断增加。系统必须能让团队看清前置任务、计划变化、风险责任人和新的预测日期。若延期主要来自审批等待，还要把审批责任和等待时间纳入流程，而不是只增加项目看板。

此时可以接受一定的初始配置成本，但前提是项目经理有时间维护计划关系。若没有维护者，先简化流程、建立周度计划评审，等数据纪律形成后再引入更复杂能力。

5. 如果问题是重复汇报，先选单一事实来源

重复汇报通常不是缺少报表，而是不同层级的管理者各自要求一份格式不同的进度表。项目经理应先谈妥哪些字段是权威数据、哪些报告可以从同一来源生成，以及哪些补充说明仍需要人工撰写。

如果管理者坚持每个部门继续维护自己的独立表格，系统的收益会受到限制。要么让这些表格成为系统数据的视图或导出结果，要么明确各表格的更新责任和废止时间；否则新系统只会成为额外入口。

6. 如果现有系统很多，不要忽视集成和数据归属

企业可能已经有财务、客户、研发、文档和身份管理系统。新的计划管理系统不必替代它们，但必须说明哪些数据由谁维护、哪些信息需要同步、同步失败由谁处理。没有明确边界，接口会把数据不一致变成自动化的不一致。

优先集成真正影响计划判断的信息，例如项目编码、负责人、客户交付日期或研发里程碑。不要为了“打通一切”而一次连接所有系统。每个接口都要计算维护成本、权限风险和业务价值。

八、最终取舍：值得投资的不是最全的系统，而是可持续的管理机制

1. 三种常见取舍，先说清楚再签约

轻量和控制之间：轻量方案启动快、学习负担低，但复杂依赖和治理能力可能有限；控制能力强的方案更适合关键路径和跨团队治理，却需要更多配置、维护和培训。应按风险大小选，不要把复杂等同于专业。

统一和自治之间：统一口径可以提高汇总质量，但过度统一会压平部门差异；完全自治让团队灵活，却会让管理层无法比较。建议统一指标、责任与汇报规则，把工作流差异留给部门。

短期成本和长期维护之间：低价但需要大量定制、重复录入或人工汇总的方案，未必总成本最低；高配置平台若没有内部管理者，也可能成为昂贵的闲置系统。应把内部人力投入写进预算。

2. 采购前的最终核对清单

• 是否用真实工作项验证过目标、里程碑、任务、依赖和验收，而不是只看演示数据？
• 是否明确计划状态、更新时间、当前预测和原始承诺的定义？
• 延期或范围变更时，是否能追溯原因、责任人、受影响对象和决策记录？
• 执行人员是否知道自己需要维护什么，预计每周增加或减少多少操作？
• 周报、月报和管理视图是否减少了重复加工，而不是多出一份系统报表？
• 权限、数据导出、集成、迁移、部署和支持要求是否有书面确认？
• 是否设定试点的成功、调整和停止条件，并明确谁有权作出决定？

3. 下一步怎么做

如果你正在为2026年的预算做准备，我建议先用两周完成问题诊断，再用六周跑一个小规模试点，最后根据证据决定是否扩大。先选最能暴露管理瓶颈的工作，而不是最容易做出演示效果的工作；先验证系统是否减少信息断点，再讨论全公司推广。

本文的独特判断是：部门工作计划管理系统的投资回报，首先取决于管理口径能否统一、变更能否被看见、责任能否落到具体工作，其次才取决于功能数量。五类系统没有脱离场景的绝对冠军。项目经理的下一步，不是问“哪款最强”，而是拿一项真实计划做同场景验证，记录维护成本、风险提前量和汇报节省，再让证据决定采购。