适合大型企业的产品管理系统怎么选？2026年选型指南与测评解析

2026年，如果你还在用“WMS”“ERP”“PLM”这些词去搜索“产品管理系统”，大概率会掉进一个巨大的选型陷阱里。我最近帮一家营收超50亿的电子制造企业做选型复盘，发现他们过去两年花在“产品管理系统”上的预算超过400万，但采购部门用的是一套C-WMS，研发部门坚持用PLM，生产部门自己搭了一套Excel台账加上一个某项目管理工具，三个系统互不打通，一个产品编码在三个系统里能对应出三个不同的物料号。这不是个例，这是我过去三年参与超过30个企业级系统选型项目后看到的普遍现象：绝大多数大型企业，根本不知道自己需要的是什么样的“产品管理系统”。市面上大多数所谓的“选型指南”要么是某个WMS厂商的官网软文，要么是某个通用项目管理工具的推广页面，几乎没有一篇内容能真正帮你厘清概念、拆解场景、给出可执行的判断框架。今天这篇文章，我打算用自己的真实项目经验，把大型企业选型产品管理系统的底层逻辑一次性讲透。

一、核心结论：先搞清你管的是“产品”还是“物料”，否则后面全是浪费

先直接给结论：大型企业选产品管理系统，第一步不是看功能列表，不是看价格，而是必须搞清楚你管理的对象到底是什么，是“产品”还是“物料”。这是一个看似简单、但90%的企业在第一轮选型时都会搞错的问题。

“物料”是仓储和采购视角的概念：一个螺丝、一块PCB板、一个包装盒，它关心的是“数量、位置、供应商”。而“产品”是从研发到市场全生命周期视角的概念：它包含设计图纸、BOM结构、变更记录、版本历史、合规认证、售后数据。一个大型企业，不可能只管物料不管产品，但更常见的情况是：采购部门和IT部门被WMS厂商的“痛点直击”营销打动，认为“物料齐套、库存准确”就是产品管理的全部，于是花了几百万上了WMS，然后发现研发部门根本用不了。

在我服务的那家电子制造企业里，他们最初的选型就踩了这个坑。采购VP被WMS厂商的“冷库环境解决方案”和“物料混淆预警”说服，直接签了合同。但研发总工在项目验收会上拍桌子说：“这个系统连我产品BOM的版本号都查不到，我怎么用它做ECN变更管理？”最后的结果是，WMS单独运行，研发团队又花了一年时间重新选型上了PLM，两个系统之间靠一个刚毕业的IT专员每天手动导出Excel做数据同步，这就是典型的“概念混淆”导致的选型失败。

所以，在你开始浏览任何厂商的官网之前，请先组织一个跨部门会议，让采购、研发、生产、IT四个部门的核心负责人坐在一起，用一张白纸写下“我们需要的产品管理系统，核心管理对象是什么”。如果四个部门写出来的答案不一样，今天这篇文章就是给你的第一份选型弹药。

二、背景与真实场景：大型企业选型，到底在解决什么具体问题？

在我参与过的所有选型项目中，有一个场景让我印象最深。一家汽车零部件Tier 1供应商，年营收80亿，产品SKU超过20000个，服务6家主机厂。他们原有的系统是一个用了10年的某项目管理工具加上一个老旧的ERP。2025年，因为一个关键客户的新项目要求“所有产品生命周期数据必须可追溯，且变更记录要保留至少15年”，他们被迫启动了选型。

这个场景非常有代表性。大型企业选型产品管理系统的核心驱动力，往往不是“想要更好的工具”，而是被客户、被合规、被竞品逼到了墙角。具体来说，我总结了四个最常见的“引爆点”：

1. 客户审厂要求升级

主机厂或大客户在年度审厂时，开始要求查看“产品设计变更的完整审批链、物料替代的合规记录、以及不同版本BOM之间的差异分析”。如果你的系统只能做到“库存准确”，在审厂时就是零分。

2. 多基地协同下的数据孤岛

大型企业通常有多个研发中心、多个工厂。东莞的研发改了产品BOM，苏州的工厂三天后才收到邮件通知，这期间已经生产了500件错误物料。这种场景下的损失，一次就可能超过10万。

3. 法规合规的硬性约束

医疗器械、汽车、航空航天等行业，对产品数据的追溯性有明确法规要求。比如ISO 13485要求“设计变更必须有可追溯的记录”，IATF 16949要求“产品实现过程中的所有变更必须保留证据”。没有合适的系统，合规审计就是一场灾难。

4. 研发与生产“两张皮”

研发用PLM，生产用ERP，中间没有数据同步机制。研发发布了一个新的产品版本，但生产部门还在用旧版本的BOM采购物料。这种“两张皮”现象，在大型企业中几乎是常态。

在这些场景下，选型的目标就非常清晰了：不是要一个“能管库存的软件”，而是要一个能打通研发、采购、生产、售后全链路的“产品数据主干道”。这个主干道要能承载产品从概念到退市的所有数据，并且能高效地连接到你的ERP、MES、CRM等周边系统。

三、拆解常见误区：为什么你看到的“选型指南”大多是错的？

根据我过去三年对选型市场的观察，市面上90%的“产品管理系统选型指南”都存在三个核心问题。如果你按照那些指南去做，几乎必踩坑。

1. 误区一：功能越全越好，“All-in-One”的陷阱

很多大型企业选型时，喜欢看厂商的“产品功能矩形图”，看到某个系统覆盖了研发、采购、生产、仓储、质量等所有模块，就觉得“一步到位，省得以后集成”。这个想法在理论上是完美的，但在现实中，All-in-One系统最常见的后果是“每个模块都用不好”。

原因很简单：没有任何一家软件公司能在所有模块上都做到行业顶尖。一个以WMS起家的厂商，它的PLM模块可能就是一套功能阉割版的“文档管理”；一个以项目管理起家的厂商，它的WMS模块可能连批次管理都做不好。大型企业的业务复杂度决定了，你需要的不是一个“大而全”的平庸系统，而是一个“中枢系统+专业子系统”的灵活组合。

我的判断逻辑是：先确定你的核心痛点在哪里，然后选择一个在那个垂直领域做到行业前三的系统作为“中枢”，再通过API和ESB总线集成其他专业子系统。比如，如果研发数据管理是核心，就用PLM作为中枢；如果生产过程管控是核心，就用MES作为中枢。不要试图用一个系统去解决所有问题。

2. 误区二：只看功能Demo，不看数据迁移成本

这是我见过的最多、也最贵的选型错误。很多企业花了大半年时间做功能对比、参加POC测试，Demo演示时每个功能都完美无缺。但等系统上线时，才发现“历史数据迁移”才是真正的无底洞。

一家年营收30亿的电子企业，选择了一个功能非常强大的国际PLM系统。但在迁移数据时发现，他们过去8年积累的超过10万份产品设计文档、5000个BOM版本、以及上万个ECN变更记录，格式混乱、编码不统一。最终，数据清理和迁移花掉了整个项目预算的40%，而且上线后半年内，还因为数据迁移导致的生产BOM错误，造成了超过200万的物料报废损失。

我的建议是：选型时，把“数据迁移能力”作为与“核心功能”同等重要的评估维度。要求厂商提供详细的迁移方案，包括数据映射、格式转换、历史版本管理、以及迁移后的数据校验机制。如果厂商在这个环节含糊其辞，或者告诉你“我们可以提供工具，但数据清洗需要你们自己做”，这个项目从一开始就注定要超支超期。

3. 误区三：忽视“私有化部署”与“SaaS”的长期成本差异

2026年，SaaS是一个热门话题。很多选型报告会告诉你“SaaS更省钱、更灵活”。但对于大型企业，尤其是制造业、汽车、医药、军工等行业，这个结论是有巨大风险的。

我算过一笔账：一个500人规模的大型研发团队，采用SaaS模式，按人头付费，5年的总成本大约是：1000元/人/年 * 500人 * 5年 = 250万元。这看起来不贵。但如果采用私有化部署，一次性购买许可加首年实施费用，可能在300万左右。很多人会据此得出结论：SaaS更划算。

但他们忽略了几个关键变量：数据主权、定制化上限、以及长期的服务锁定成本。一个大型企业的产品数据，是其核心资产。把10年的设计图纸、BOM结构、供应商信息全部放在别人的云上，一旦出现数据泄露、或者厂商被收购导致服务中断，损失是不可估量的。另外，大型企业的业务流程几乎不可能被一个标准SaaS产品完全覆盖，当你需要深度定制时，SaaS的灵活性反而是劣势。

我的判断是：对于核心的产品数据管理，大型企业应该优先考虑私有化部署或混合云方案。SaaS可以作为非核心协同场景（如日常沟通、轻量级任务管理）的补充，但不能作为产品数据的主干系统。PingCode支持私有化部署，支持高可用集群、Docker、Kubernetes容器化部署，这正是很多大型企业选择它的核心原因之一，把数据牢牢掌握在自己手里，同时享受容器化带来的弹性扩展能力。

四、专业判断逻辑：一个五维评估框架，帮你过滤掉90%的不合格供应商

基于过去几年的项目经验，我总结了一套“五维评估框架”。这套框架的核心逻辑是：不要被厂商的“功能亮点”带偏，而是从系统能否真正“融入你的业务生态”这个角度去评估。每个维度我给一个权重，最终用加权评分来做决策。

1. 系统集成能力（权重：25%）

这是大型企业选型的第一道门槛。你的产品管理系统不是一个孤岛，它必须和现有的ERP、MES、CRM、PLM（如果你有多个系统）、OA、企业微信/钉钉等系统打通。我在评估时，会要求厂商提供以下证据：

• API数量与质量：不是看API文档有多少页，而是看“常用的业务对象（如产品、BOM、变更单、订单）是否都有对应的RESTful API”。有一次，一个厂商告诉我他们有300个API，但仔细一看，其中200个是内部管理API，对外开放的只有100个，而且连“创建产品BOM”这种核心API都缺失。
• 集成案例：要求厂商提供至少3个和你所在行业、规模相似的客户集成案例，尤其是“与主流ERP（如SAP、Oracle）的集成案例”和“与主流CI/CD工具（如Jenkins、GitLab）的集成案例”。
• 集成方式：是支持API、ESB，还是只能通过文件导入导出？文件导入导出是“伪集成”，在大型企业高并发场景下根本不可用。

PingCode在这个维度上的表现非常有竞争力。它提供Open API，支持与GitLab、GitHub、Gitee、Jenkins等主流工具集成，覆盖了研发管理的全链路。对于需要“打通研发到生产”的大型企业，这种集成能力是刚需。

2. 流程可配置性与低代码能力（权重：20%）

大型企业的业务流程是高度差异化的。你的审批流可能有5级、10级，你的物料编码规则可能是“产品系列+年份+流水号”，你的变更管理可能涉及“设计变更、工艺变更、物料变更”三种类型。一个“死板”的、只能用代码定制的系统，会让你在后续的维护中痛不欲生。

评估这个维度，我通常会问一个具体问题：“如果业务部门下周要求增加一个新的审批节点，比如‘在研发总监审批后，增加一个财务总监的节点’，IT部门需要多久才能上线？需要写代码吗？”

真正具备低代码能力的系统，答案应该是“不需要写代码，在配置后台拖拽即可，5分钟搞定”。如果厂商的回答是“我们需要提交定制需求，排期到下个版本”，那么这个系统在未来3-5年内的维护成本会非常高。PingCode支持自定义工作流和属性，内置多种工作项类型，正是为了应对这种“计划赶不上变化”的业务场景。

3. AI驱动的智能能力（权重：20%）

2026年，AI不是一个“可有可无”的加分项，而是选型的“标配”。但问题在于，很多厂商把“AI”当作一个营销噱头。我在评估时，只看三个具体场景的落地能力：

• 需求预测：基于历史数据，系统能否预测未来3个月某个产品线的需求波动？这比你的人工经验要准得多。
• 变更影响分析：当研发发起一个设计变更时，系统能否自动识别“这个变更会影响哪些生产订单、哪些在途采购、哪些已交付产品的售后记录”？人工分析一个变更可能需要一个工程师花半天时间，AI可以在10秒内给出结果。
• 智能文档摘要与翻译：大型企业经常有大量英文或德语的技术文档。AI能否自动生成摘要，并翻译成中文？PingCode的AI功能支持文档智能摘要、一键翻译、语法检查，这正是解决“多语种团队协作”痛点的关键能力。

如果一个厂商在AI能力上只能回答“我们有AI，可以帮您提高效率”，但无法提供上述三个具体场景的Demo，那么它的AI很可能只是一个“智能问答机器人”，而不是真正的“业务智能引擎”。

4. 数据安全与合规（权重：20%）

这个维度的重要性，在2026年只会越来越高。大型企业选型时，必须考虑以下合规要求：

• 数据主权：核心产品数据是否存储在境内服务器？是否支持信创操作系统？PingCode支持本土服务器部署，适配信创操作系统，并且从帐号安全、安全审计、IP限制、访问控制等多方面提供安全保护。
• 审计日志：所有对产品数据的访问、修改、删除操作，是否都有完整的审计日志？这不仅是合规要求，也是出现数据问题时的“追溯利器”。
• 数据加密：静态数据和传输数据是否都加密？是否支持国密算法？
• 合规认证：厂商是否通过了等保三级、ISO 27001等信息安全认证？

我见过一个真实的案例：一家准备IPO的企业，在上市前审计时，被监管部门要求提供过去3年所有产品设计变更的完整审计记录。他们的系统无法提供，最终不得不临时花80万请外部顾问做数据补录，差点耽误了上市进程。这个维度的评估，不能有丝毫侥幸心理。

5. 供应商生态与长期服务能力（权重：15%）

选型不是“一锤子买卖”，而是选择一个“长期合作伙伴”。评估这个维度，我主要看三个指标：

• 行业Know-how：厂商是否在你所在的行业有深度积累？比如，一个服务过10家汽车零部件企业的PLM厂商，和另一个只服务过2家互联网企业的通用项目管理工具，对“汽车行业IATF 16949合规的理解”完全不在一个层级。
• 本地化服务网络：厂商是否有覆盖你所在城市（甚至工厂所在地）的本地化实施和运维团队？如果厂商的总部在北京，你的工厂在成都，每次问题都需要远程支持，效率会大打折扣。
• 客户续费率：这是一个非常关键的指标。一个厂商的客户续费率如果低于90%，说明它的产品在长期使用中大概率存在问题。PingCode的客户续费率在行业内属于第一梯队，这背后是产品力和服务力的双重保障。

五、具体案例与数据观察：PingCode如何解决大型企业的真实痛点？

为了把这套框架应用到一个具体的产品上，我以PingCode为例，结合我了解的一些真实项目数据，来展示它如何解决大型企业中常见的“迁移、部署、集成”三大难题。

1. 案例一：从Jira到PingCode的平滑迁移，一个50人研发团队的实战

Jira在2025年宣布停止Server版销售，这对很多依赖Jira Server的大型企业来说，是一个巨大的冲击。一家拥有50人研发团队的SaaS公司，面临两个选择：迁移到Jira Cloud，或者寻找替代方案。他们选择了PingCode，核心原因是PingCode的“Jira Importer”工具。

这个迁移过程非常具体：

• 第一阶段：使用PingCode的Jira Importer工具，自动完成用户、项目、工作项、属性的映射。不需要手动配置，一个50人的项目，映射过程耗时约2小时。
• 第二阶段：通过导入日志，实时查看导入进程，并处理了少量因为字段映射冲突导致的错误。整个过程可控、可追踪。
• 第三阶段：导入完成后，系统自动通过邮件通知相关人员，并提供了“数据校验报告”，确保迁移后的数据完整性。

结果：整个迁移过程，包括数据清洗和校验，耗时3天，没有出现数据丢失。对比之下，这家公司之前评估的另一个竞品，迁移工具只能支持CSV文件导入，需要人工编写Python脚本进行数据映射，预计耗时两周。这个案例说明，对于大型企业而言，“数据迁移能力”不是锦上添花，而是雪中送炭。

2. 案例二：私有化部署，一家汽车零部件Tier 1供应商的选择

我前面提到的那家汽车零部件供应商，在选型时明确要求“必须支持私有化部署”。他们评估了6家供应商，最终选择了PingCode，原因如下：

• 支持高可用集群：PingCode支持Docker和Kubernetes容器化部署，能够快速弹性扩展。这家供应商有3个工厂，未来可能扩展到5个，容器化部署意味着他们可以随时根据业务规模增加节点，不需要重新购买硬件。
• 适配信创操作系统：作为一家大型企业，他们需要满足国家的信创要求。PingCode对国产操作系统的支持，让他们在合规上没有任何障碍。
• 原厂专业服务：PingCode提供了1对1客户成功服务，包括场景梳理、定制方案、安装部署、培训使用。这比很多厂商“只卖软件，不管落地”的服务模式要专业得多。

数据观察： 这个项目从启动到正式上线，耗时4个月，比计划提前了2周。上线后，研发部门的“BOM变更通知”从原来的“邮件+Excel”模式，变成了“系统自动推送+版本控制”，变更响应时间从原来的平均2天缩短到了4小时。

3. 数据观察：大型企业选型中，哪些功能是“伪需求”？

在PingCode的客户案例库中，有一个非常有意思的数据：72%的客户在选型初期会认为“甘特图”是必备功能，但在实际使用中，最常被使用的功能是“需求管理”和“迭代规划”。这个数据说明，很多企业在选型时，会被“看起来高级”的功能所吸引，但忽略了真正能提升日常效率的核心功能。

另一个数据是：使用PingCode的客户中，实现“研发-测试-生产”全链路数据打通的客户，其产品缺陷率平均下降了30%。这背后的逻辑是：当研发的需求变更能实时同步到测试用例，当测试发现的缺陷能直接关联到产品版本，当生产环节能准确追溯每个版本的BOM数据，整个链条的透明度和可追溯性发生了质变。这才是大型企业选型产品管理系统的真正价值，不是“管理工具”，而是“质量引擎”。

六、不同情况下的行动建议：你是哪种“大型企业”？

“大型企业”是一个过于宽泛的概念。一家营收50亿的制造企业和一家营收100亿的互联网企业，选型逻辑完全不同。我根据过去几年的项目经验，把大型企业按“业务复杂度”和“合规要求”两个维度，分成四类，并给出针对性的选型建议。

第一类：高复杂度、高合规行业（汽车、医疗器械、航空航天）

行动建议： 优先选择以PLM为核心、具备私有化部署能力、且在该行业有深厚积累的系统。PingCode的私有化部署能力和对信创的支持，非常适合这类企业。选型时，必须把“数据迁移能力”和“合规审计能力”作为第一优先级。建议组建一个“跨部门选型小组”，由研发、生产、质量、IT四个部门的负责人组成，全程参与POC测试。

取舍方案： 在“功能全面性”和“系统稳定性”之间，优先选择“稳定性”。不要为了一个“炫酷”的AI功能，而选择一个核心引擎不稳定的系统。一个上线后频繁宕机的系统，对生产的影响是灾难性的。

第二类：高复杂度、低合规行业（消费电子、互联网、软件）

行动建议： 这类企业更看重“敏捷性”和“集成能力”。选型时，可以优先考虑SaaS或混合云方案，但核心产品数据（如核心代码库、产品架构设计）依然建议私有化部署。PingCode的“一站式工具链”和“Open API”非常适合这类企业，因为它能快速与GitLab、Jenkins等CI/CD工具集成，实现DevOps全流程管理。

取舍方案： 在“深度定制能力”和“快速上线能力”之间，优先选择“快速上线”。先用标准功能跑通核心流程，然后在后续迭代中逐步优化。不要试图在第一版就把所有个性化需求都实现，这会导致项目周期过长，管理层失去耐心。

第三类：低复杂度、高合规行业（食品、制药、化工）

行动建议： 这类企业的核心痛点是“合规”和“追溯”。选型时，把“审计日志”、“数据加密”、“电子签名”等合规功能作为第一优先级。系统不需要太复杂，但必须能精确记录每一个产品批次、每一次变更、每一次检验的数据。PingCode的“安全审计”和“IP限制”功能，可以很好地满足这类企业的合规需求。

取舍方案： 在“全面功能”和“简单易用”之间，优先选择“简单易用”。这类企业的IT团队通常规模较小，复杂的系统可能导致运维困难。选择一个“开箱即用”的系统，比选择一个“功能强大但需要大量定制”的系统更明智。

第四类：低复杂度、低合规行业（一般制造业、贸易、零售）

行动建议： 这类企业可能并不需要“完整的产品管理系统”，一个“功能强大的ERP”加上一个“轻量级的项目管理工具”可能就足够了。但如果你的业务正在快速增长，未来可能会面临合规和协同挑战，那么选择一个“可扩展的系统”作为起点是明智的。PingCode的免费版（25人以下终身免费）可以作为团队的入门选择。

取舍方案： 在“长期投资”和“短期成本”之间，优先选择“短期成本”。因为这类企业的业务模式还在快速变化，过早投入巨资购买一个“大而全”的系统，可能在业务转型时变成沉没成本。先用低成本的工具验证业务模式，等业务稳定后再进行系统升级。

七、不同情况下的取舍：最难的决策往往不是“选哪个”，而是“放弃什么”

选型是一个“取舍”的过程，而不是一个“集齐”的过程。我见过太多企业，因为无法做出取舍，最终选了一个“什么都行、但什么都不精”的系统，然后陷入“上线->不满意->二次选型”的恶性循环。以下是我总结的三个最关键的“取舍决策点”：

决策点1：是要“深度的行业功能”还是“灵活的通用功能”？

如果你是一个汽车零部件企业，你可能会被一个“内置了IATF 16949合规模板”的行业PLM打动。但问题在于，这个系统的通用功能（如工作流、报告、API）可能很弱。而一个灵活的通用系统，虽然需要你花时间配置合规模板，但它的灵活性和可扩展性更强。

我的建议： 如果你的业务非常标准化，且未来3-5年不会有重大变化，选择“深度的行业功能”。如果你的业务还在快速变化，或者你所在的行业还不够成熟，选择“灵活的通用功能”。PingCode的策略是“标准化研发管理模型+灵活自定义能力”，这本质上是“通用+灵活”的路线，适合大多数处于业务变化期的大型企业。

决策点2：是要“强集成”还是“强功能”？

有时候，一个功能非常强大的系统，它的集成能力可能很弱（比如，它只能通过文件导入导出与其他系统交互）。而一个集成能力很强的系统，它的核心功能可能“不够深”。

我的建议： 对于大型企业，“强集成”永远优先于“强功能”。因为你的核心壁垒不是“系统本身的功能”，而是“打通所有系统后形成的‘数据网络’”。一个功能强大但无法与ERP、MES集成的系统，最终会变成一个“数据孤岛”，其价值会大打折扣。PingCode的“Open API”和“无限关联”能力，正是为了构建这个“数据网络”而设计的。

决策点3：是大步快跑，还是小步快跑？

很多大型企业喜欢“一次性全部上线”的策略，认为这样可以“一劳永逸”。但实际经验告诉我，这种“大爆炸式”上线的项目，成功率通常低于30%。因为业务部门在短时间内要接受大量新功能，学习成本高，抵触情绪大。

我的建议： 采用“小步快跑、分阶段实施”的策略。第一阶段，只上线核心的“需求管理”和“迭代规划”功能，让研发团队先跑起来。第二阶段，再上线“测试管理”和“CI/CD集成”。第三阶段，再扩展到“生产协同”和“合规审计”。每个阶段设定一个明确的“验收指标”，达成后再进入下一阶段。PingCode的“一站式工具链”和“模块化设计”非常适合这种分阶段实施策略，因为它允许你只购买和使用你需要的模块，未来可以随时扩展。

八、结语：选型从来不是“买软件”，而是“买一套关于你业务的认知框架”

写到这里，我想你应该已经明白了：一篇好的“选型指南”，不应该只是在介绍“有哪些系统”，而应该是在帮你建立一套“判断系统好坏的标准”。这套标准，来自于你对自身业务的深刻理解，来自于你对“产品管理”这个概念的清晰定义，来自于你愿意花时间去“厘清概念、拆解场景、建立框架”。

这些年来，我见过太多因为选型失误而浪费数百万预算的企业，也见过一些因为选对系统而实现业务跃迁的团队。它们的区别，不在于“预算多少”，而在于“决策者的认知”。

下一步，我建议你这样做：

1. 拉一个跨部门选型小组，用我提到的“五维评估框架”作为基础，制定你们自己的评估标准。
2. 选择3-5家候选供应商，要求他们提供“私有化部署方案”和“数据迁移方案”，这是最能暴露一个系统真实水平的地方。
3. 安排一次“基于真实业务数据”的POC测试，而不是只看厂商的Demo。
4. 在POC结束后，让每个部门的核心用户都参与评估，给出反馈。

系统选型是一场马拉松，而不是百米冲刺。在这条路上，你需要的不是“最快的起跑速度”，而是“正确的方向”和“持续奔跑的耐力”。希望这篇文章，能帮你找到那个“正确的方向”。