成功实施PLM系统，并非简单的软件采购，而是一场涉及战略、流程、数据与人的系统性变革。本指南将为您提供一套从战略规划到持续优化的七步法实施路线图，确保您的PLM项目精准落地，规避常见陷阱，最终实现研发效率与产品创新能力的双重起飞。
为什么说，没有章法的PLM项目注定是一场灾难？
在我接触过的制造企业中，PLM项目失败的案例远比我们想象的要多。很多企业投入巨资，耗费数年，最终得到的却是一个没人愿用、数据混乱的“僵尸系统”。究其根源，问题往往不出在软件本身，而是出在实施过程的失控。
一个没有章法的PLM项目，就像一艘没有航海图的船，出发时满怀希望，最终却极有可能在茫茫大海中迷失方向，甚至触礁沉没。它会耗尽你的预算、消磨团队的士气，更可怕的是，它会让你对数字化转型本身产生怀疑。
制造业的研发困境：从“部门墙”到“数据孤岛”
让我们回到业务一线，看看研发流程中那些令人头疼的日常：
- 图纸版本满天飞： 设计部门还在用V1.2版本，工艺部门拿到的却是V1.1，生产现场用的甚至是V1.0的旧图。一个微小的设计变更，因为信息传递不畅，可能导致整批次的物料报废。
- BOM管理靠Excel： 设计BOM、工艺BOM、生产BOM之间靠手动传递和核对，不仅效率低下，错误率更是居高不下。一个元器件的替换，可能需要通知七八个部门，开上三四个会才能搞定。
- 跨部门协作靠“吼”： 项目进度到哪了？某个零件的测试结果如何？这些信息散落在不同的邮件、微信群和个人电脑里，项目经理想要了解全貌，只能一个个去问，效率可想而知。
这些看似琐碎的问题，背后是两个长期存在的管理顽疾：“部门墙”和“数据孤岛”。每个部门都像一个独立的王国，只关心自己的一亩三分地，数据无法顺畅地在研发、工艺、采购、生产等环节流转，最终形成了一个个信息黑洞。
PLM的真正价值：它不是一个工具，而是一套管理思想的落地
很多决策者将PLM（产品生命周期管理）简单理解为一个管理图纸和文档的软件。这是一个极大的误解。
PLM的本质，是一套先进的管理思想。它强调以产品为核心，将从概念设计、研发、工艺、生产、采购、销售、到售后服务的全生命周期数据和流程进行统一管理。它的目标是打破部门墙，夷平数据孤岛，建立一个统一、协同、高效的产品研发平台。
所以，上PLM项目，绝不是IT部门一家的事。它是一场自上而下的管理变革，是对现有研发流程的重塑和优化。想清楚这一点，是我们踏上正确实施之路的第一步。
第一步：战略规划与目标定义——找准方向，谋定而后动
任何成功的项目都始于清晰的规划。我见过太多企业，因为急于求成，跳过了这个最关键的步骤，直接进入选型阶段，为后续的失败埋下了伏笔。“谋定而后动”，这句话在PLM项目中尤为重要。
诊断业务痛点：您的研发流程究竟“堵”在哪里？
在启动项目前，请不要急着去看软件功能演示。先坐下来，组织一场深入的内部诊断会。把设计、工艺、质量、采购、生产等所有相关部门的负责人和一线骨干都请来，围绕以下问题进行一次彻底的“会诊”：
- 新品研发周期为什么总是比预期的长？瓶颈在哪里？
- 哪个环节最容易出错？是图纸变更，还是BOM传递？
- 跨部门沟通中，哪些信息的获取成本最高？
- 我们沉淀了多少可以复用的知识和数据？还是每次都在“重新发明轮子”？
通过这种方式，你会得到一张企业专属的“研发流程痛点地图”。这张图将成为你后续定义目标、评估需求的根本依据。
设定可量化的项目目标（SMART原则），拒绝“感觉良好”
“提升研发效率”、“加强协同”——这类模糊的目标在项目管理中是毫无意义的。我们需要的是基于SMART原则的、可量化的目标。
- S (Specific - 具体的): 目标必须清晰明确。例如，“建立统一的零部件库”就比“规范物料管理”要具体。
- M (Measurable - 可衡量的): 目标必须可以量化。例如，“将图纸变更流程的平均审批时间从3天缩短到8小时”。
- A (Achievable - 可实现的): 目标在现有资源和条件下是可能达成的。
- R (Relevant - 相关的): 目标必须与企业的整体战略相关联。
- T (Time-bound - 有时限的): 必须明确完成目标的截止日期。
一个好的项目目标应该是这样的：“项目上线一年内，通过实施PLM系统，将新产品研发周期平均缩短15%，因BOM错误导致的物料报废率降低50%。” 这样的目标，才能让你在项目结束后，清晰地衡量其价值，而不是停留在“感觉良好”的层面。
组建跨部门核心项目团队：谁必须在船上？
PLM项目是“一把手”工程，但具体执行需要一个强有力的跨部门团队。这个团队中，以下角色缺一不可：
- 项目发起人（Sponsor）： 通常是公司高管，如研发副总或CIO。他负责争取资源、协调高层、为项目“撑腰”。
- 项目经理（Project Manager）： 项目的“大管家”，负责制定计划、控制进度、管理风险、沟通协调。这个人必须懂业务、懂管理，最好还有一定的IT背景。
- 业务流程负责人（Business Process Owners）： 来自研发、工艺、质量等核心业务部门的专家。他们是未来系统的主要使用者，负责提出需求、参与蓝图设计和系统测试。
- IT技术负责人（IT Lead）： 负责技术方案评估、系统环境搭建、数据迁移和集成开发等工作。
这个团队不是临时拼凑的，而是要在项目期间被充分授权，并投入足够的时间和精力。
获取管理层“金牌令箭”：确保资源与支持
在项目启动会上，项目发起人必须向全体成员，尤其是管理层，清晰地阐述项目的战略意义、核心目标和预期收益。最重要的是，要获得管理层明确的授权和资源承诺，也就是我们常说的“金牌令箭”。
这不仅意味着预算的批准，更意味着当项目推行遇到部门阻力时，管理层愿意站出来协调和推动。没有这块金牌令箭，项目在后续的流程变革中将寸步难行。
第二步：需求分析与系统选型——选对的，而不是选贵的
当方向和目标明确后，我们才能开始寻找合适的工具。PLM市场品牌众多，功能各异，从几十万到上千万的系统都有。如何选择？核心原则是：匹配你的业务需求。
深入一线：绘制您企业专属的研发流程图
在给供应商提需求之前，你必须先彻底搞清楚自己“现在是怎么做的”（As-Is）以及“未来想怎么做”（To-Be）。
组织项目核心团队，深入到设计室、工艺部、车间一线，用流程图的方式，将当前核心的研发业务流程完整地绘制出来。例如：
- 新产品立项流程
- 设计图纸创建与审批流程
- 工程变更（ECN）管理流程
- 物料申请与承认流程
这个过程虽然耗时，但价值巨大。它不仅能帮助你梳理内部逻辑，更能让你在与供应商沟通时，从被动的倾听者，变成掌握主动权的对话者。
制定需求规格说明书（RFP）：向供应商清晰传递你的诉求
基于痛点地图和流程图，你可以开始编写一份高质量的需求规格说明书（Request for Proposal, RFP）。这份文件是你向潜在供应商发出的“考卷”，其质量直接决定了你能否收到靠谱的“答案”。
一份专业的RFP至少应包含：
- 公司与项目背景介绍： 让供应商了解你是谁，要做什么。
- 项目目标与范围： 清晰界定本次实施的核心模块和边界。
- 详细的功能性需求： 逐条列出你对图文档管理、流程管理、BOM管理、项目管理等模块的具体要求。
- 非功能性需求： 对系统的性能、安全性、可扩展性、易用性等方面的要求。
- 技术与服务要求： 对技术架构、实施服务、售后支持、培训等方面的要求。
RFP写得越详细、越清晰，供应商给出的方案就越有针对性，你后续的评估工作也就越轻松。
评估供应商：从技术实力、行业案例到服务能力的“三维考察”
收到各家供应商的方案后，评估工作需要从三个维度展开：
- 产品与技术： 系统的技术架构是否先进？功能是否满足核心需求？扩展性和集成性如何？安排一次详细的产品功能演示，让业务部门的同事参与进来，模拟真实场景进行操作。
- 行业经验与案例： 供应商是否服务过你所在行业的客户？是否有成熟的行业解决方案？要求供应商提供2-3个与你公司规模、业务相似的成功案例，如果可能，进行实地考察或电话访谈。
- 实施与服务能力： 供应商是否在本地有专业的实施团队和服务团队？他们的项目实施方法论是怎样的？售后服务响应机制如何？
记住，你采购的不仅是一套软件，更是一个长期的合作伙伴。实施团队的专业能力，某种程度上比软件功能本身更重要。
警惕“水土不服”：如何选择真正懂制造业的PLM伙伴？
一些国际大牌PLM软件功能强大，但在国内市场常常会遇到“水土不服”的问题。它们的流程设计可能过于僵化，服务响应链条过长，本地化定制成本高昂。
相比之下，一些深耕国内制造业的本土PLM厂商，可能更理解中国企业的管理习惯和业务特点。他们通常更灵活，服务更贴近，性价比也更高。在选型时，不妨将目光放得更广一些，综合评估，找到那个最懂你的“伙伴”。
第三步：项目规划与蓝图设计——绘制清晰的作战地图
选定了合作伙伴，并不意味着可以立刻开始安装软件。我们需要和实施方一起，制定一份详细的项目规划，绘制出未来系统的业务蓝图。这相当于为整个项目绘制一份精密的“作战地图”。
制定分阶段的实施路线图与时间表
一口吃不成胖子。对于复杂的PLM项目，分阶段实施是降低风险、确保成功的最佳策略。
通常，我们会建议采用“总体规划，分步实施”的原则。
- 一期： 聚焦核心痛点，上线最关键的模块，如文档管理、流程管理和BOM管理，先让基础数据跑起来。
- 二期： 在一期基础上，扩展到项目管理、工艺管理等模块。
- 三期： 深入应用，并与ERP、MES等外围系统进行深度集成。
为每个阶段设定清晰的目标、范围、里程碑和时间表，并获得双方项目团队的一致认可。
设计未来的业务流程蓝图：流程再造，而非简单线上化
实施PLM绝不是把线下的审批流程原封不动地搬到线上。这是一个流程再造（BPR）的绝佳机会。
你需要和实施顾问一起，结合PLM系统的最佳实践，重新审视和优化现有的研发流程。哪些环节可以简化？哪些审批可以合并？哪些人工操作可以被系统自动化？
例如，过去一个工程变更可能需要纸质单据在线下传来传去，耗时数天。在新的流程蓝图里，它可以变成一个线上流程，相关人员会收到自动提醒，系统会记录所有变更痕迹，整个过程可能在几小时内完成。这个蓝图设计的过程，是项目价值实现的核心环节。
规划数据迁移策略：历史数据的“清洗”与“继承”
历史数据是企业的宝贵财富，但也可能是新系统的“包袱”。在系统上线前，必须制定周密的数据迁移策略。
你需要明确：
- 哪些数据需要迁移？ （如图纸、BOM、零部件库等）
- 数据源在哪里？ （在文件服务器？在旧系统？还是在个人电脑里？）
- 数据质量如何？ 是否存在大量重复、错误、过时的数据？
- 谁负责数据的清洗和整理？
“垃圾进，垃圾出”是IT系统实施的铁律。在数据迁移前，必须投入足够的人力进行数据的“清洗”和标准化，确保导入新系统的是高质量的“血液”。
规划系统集成方案：打通PLM与ERP、MES的数据动脉
PLM系统不是一个孤岛。它位于企业信息化的核心，需要与ERP、MES等系统紧密集成，才能发挥最大价值。
- PLM与ERP集成： 当设计BOM在PLM中发布后，应能自动传递给ERP系统，生成生产BOM和采购需求，避免了手工录入的错误和延迟。
- PLM与MES集成： PLM中的工艺路线、作业指导书等数据，可以直接下发到MES系统，指导车间的生产执行。
在规划阶段，就需要与实施顾问一起，明确集成的范围、技术方案和数据接口，为打通企业的数据动脉做好准备。
实战案例：某精密设备制造商如何通过PLM将研发周期缩短30%？
为了让你更直观地理解PLM的价值，我们来看一个真实的案例。
痛点回顾：图纸版本混乱，变更流程失控，跨部门协作靠吼
这是一家典型的中型精密设备制造商。在实施PLM之前，他们面临着前文提到的所有典型困境。研发部门内部使用一套文件服务器管理图纸，版本控制仅靠文件名后缀（如V1.0, V1.1_final, V1.1_final_final），极度混乱。一个工程变更需要发起人拿着纸质的《工程变更单》跑遍设计、工艺、采购、质量等多个部门签字，一个流程走下来，两周过去了是常态。项目经理每周都需要组织好几次协调会，才能勉强跟上项目进度。
解决方案：实施以BOM为核心的PLM，打通研产供协同流程
在经过详细的规划和选型后，他们决定分两期实施PLM系统。
一期目标： 建立统一的电子化图文档和物料管理平台，固化工程变更流程。
- 核心动作1： 将所有历史图纸和技术文档导入PLM，建立唯一的、受版本控制的数据源。所有人都只能从系统里检出和检入最新版本。
- 核心动作2： 建立统一的零部件库，对物料进行分类和编码，从源头杜绝“一物多码”。
- 核心动作3： 将工程变更流程在PLM系统中固化，所有审批、会签全部线上完成，过程透明可追溯。
二期目标： 实现与ERP系统的集成，打通设计与生产的数据流。
- 核心动作： 开发PLM与ERP的接口，当设计BOM在PLM中签审发布后，自动将BOM数据和物料主数据传输到ERP系统。
量化成果：新品上市时间（TTM）缩短，物料错误率降低超过50%
项目上线一年后，效果非常显著：
- 研发周期缩短30%： 电子化的流程大大加快了审批速度，查找资料的时间几乎可以忽略不计，设计师能将更多精力投入到创新工作中。
- 物料错误率降低超过50%： 由于BOM数据从设计端直接传递到生产端，彻底消除了人工转录带来的错误。
- 工程变更周期从平均10天缩短至2天： 线上流程让变更过程透明高效，瓶颈环节一目了然。
这个案例的关键成功因素在于：明确的阶段性目标、管理层的坚定支持，以及选择了真正理解他们业务的实施伙伴。
第四步：系统部署与定制开发——将蓝图变为现实
蓝图绘制完成后，就进入了将图纸变为现实的阶段。这个阶段技术性较强，但业务部门的深度参与同样不可或缺。
环境搭建：测试、预生产与生产环境的科学布局
一个专业的PLM项目实施，至少会搭建三套环境：
- 开发/测试环境： 用于实施顾问进行系统配置、定制开发和单元测试。
- 预生产环境（UAT环境）： 功能与生产环境完全一致，用于业务部门进行用户验收测试和数据迁移演练。
- 生产环境： 最终用户正式使用的系统。
这种科学的布局，可以确保所有功能和数据在正式上线前都经过了充分的验证，最大限度地降低上线风险。
核心功能配置：让软件匹配你的业务，而非业务迁就软件
PLM系统通常都具有很强的可配置性。实施顾问会根据前面设计的业务蓝图，通过系统后台的配置功能，来匹配你的业务流程。
例如，配置不同的对象类型（如图纸、文档、物料）、定义对象的属性、设计审批流程的节点和路径、设置不同角色的操作权限等。这个过程需要业务部门的人员深度参与，不断确认配置结果是否符合预期。好的PLM系统，应该是通过配置就能满足企业80%以上的需求。
必要的二次开发：满足企业个性化需求的“最后一公里”
对于一些企业特有的、标准功能无法满足的个性化需求，就需要进行二次开发。例如，开发特定的报表、与某个专用软件的集成接口等。
二次开发应遵循“非必要，不开发”的原则。因为过多的定制会增加项目复杂度和未来的维护成本。在决定开发前，一定要与实施顾问充分论证其必要性和投入产出比。
关键节点：单元测试与集成测试，确保系统稳定可靠
在配置和开发过程中，测试是贯穿始终的。
- 单元测试： 对每一个配置的功能点或开发的模块进行单独测试。
- 集成测试： 将多个模块组合在一起，测试它们之间的数据流和业务流是否顺畅，特别是与ERP等外部系统的接口。
只有通过了严格测试的功能，才能交付给用户，进入下一阶段。
第五步：数据迁移与验证——为新系统注入“血液”
系统框架搭建好了，接下来就要为它注入“血液”——也就是迁移历史数据。这个过程容不得半点马虎。
数据清洗与准备：源头杜绝“垃圾进，垃圾出”
这个工作在规划阶段就应启动，在迁移前必须完成。业务部门需要按照预先定义的数据标准，对要迁移的图纸、BOM、物料清单等进行整理、去重和标准化。IT部门则配合开发数据提取和转换的脚本。这项工作虽然枯燥，但其重要性怎么强调都不过分。
执行分阶段的数据迁移计划，确保业务平稳过渡
数据迁移通常不会一次性完成。我们会制定一个详细的计划，分批次、分类型地进行。
例如，先迁移基础的零部件库数据，再迁移产品BOM数据，最后迁移图文档数据。每一次迁移，都会先在预生产环境进行演练，成功后再在生产环境正式执行。对于正在进行中的项目数据，还需要制定特殊的增量迁移方案。
进行严格的数据验证与一致性检查
数据导入新系统后，并不是万事大吉了。必须组织业务人员进行严格的数据验证。通过抽样检查、新旧系统数据比对等方式，确认数据的完整性、准确性和一致性。只有验证通过的数据，才能被确认迁移成功。
第六步：用户培训与系统上线——成功的关键在于“人”
系统和数据都准备就绪，项目成功与否的最后一关，落在了“人”的身上。用户的接受和使用，是衡量项目成败的最终标准。
制定多层次的用户培训计划：从“为何用”到“如何用”
一次成功的培训，不仅仅是教会用户如何操作软件。它应该包括三个层次：
- 思想培训（Why）： 面向所有用户，尤其是中层管理者，讲解PLM项目的背景、目标和价值，让他们明白为什么要进行这场变革。
- 功能培训（What & How）： 面向不同角色的用户，提供针对性的操作培训。例如，给设计师培训图纸管理，给工艺员培训工艺路线编制。
- 深化培训（Better）： 在系统上线一段时间后，针对用户的疑问和高级需求，提供进阶培训，帮助他们用好系统，挖掘更深层次的价值。
开展用户接受度测试（UAT）：让使用者成为系统的第一批“质检员”
在正式上线前，必须在预生产环境组织一次正式的用户接受度测试（User Acceptance Test, UAT）。
让核心业务用户按照事先编写的测试用例，完整地模拟一遍未来将在新系统中执行的业务场景。例如，从创建一颗新物料，到在BOM中使用它，再到发起一个围绕它的工程变更。
UAT不仅是对系统功能的最后一次检验，更是让用户提前熟悉系统、建立信心的过程。他们在测试中发现的问题，必须在上线前得到解决。
制定详细的上线切换计划与应急预案
上线切换是一个高风险的时刻。必须制定一份精确到小时的切换计划（Cutover Plan），明确每项任务的内容、负责人和完成时间。例如，何时停止旧系统录入、何时开始正式数据迁移、何时进行最后验证、何时宣布系统正式上线。
同时，必须准备好应急预案。如果上线过程中出现意外，是立即回滚到旧系统，还是启动紧急修复？这些都必须提前想好。
正式上线与初期的“保姆式”支持
系统正式上线后，项目团队并不能马上解散。在初上线的一到两个月内，需要提供“保姆式”的现场支持（On-site Support）。
实施顾问和内部核心团队成员要随时待命，快速解答用户的疑问，解决他们遇到的问题。这个阶段的目标是帮助用户平稳度过适应期，建立起使用新系统的习惯和信心。
第七步：持续优化与价值评估——上线只是新的开始
PLM系统的成功上线，标志着项目实施阶段的结束，但更是企业研发数字化之旅的全新开始。一个有生命力的系统，需要在使用中不断优化和迭代。
建立运维支持体系与问题快速响应机制
项目团队撤出后，需要将运维工作顺利地交接给企业的IT部门或指定的系统管理员。建立一套清晰的运维支持流程，包括问题提报渠道、响应时间和处理机制，确保用户在使用中遇到的问题能够得到及时解决。
监控关键绩效指标（KPI），量化项目成果
还记得我们在第一步设定的那些可量化的项目目标吗？现在是检验成果的时候了。
你需要持续跟踪和监控这些关键绩效指标（KPI），例如：
- 新产品平均研发周期
- 工程变更平均处理时间
- 零部件复用率
- BOM一次性准确率
通过数据的对比，你可以清晰地看到PLM系统带来的价值。
定期复盘，挖掘系统深化应用潜力
组织业务部门和IT部门定期召开系统应用复盘会。一方面，收集用户的使用反馈和新的需求；另一方面，共同探讨如何进一步挖掘系统的潜力，将PLM的应用从广度向深度推进。也许可以上线新的模块，或者与更多的系统进行集成。
衡量项目ROI，向管理层提交一份亮眼的成绩单
在系统稳定运行半年到一年后，你可以进行一次全面的项目投资回报率（ROI）评估。
- 收益（Return）： 包括前面提到的KPI改善所带来的直接经济效益（如减少报废、缩短周期），也包括难以量化的间接收益（如知识沉淀、协同效率提升）。
- 投资（Investment）： 包括软件采购、实施服务、硬件投入和内部人力成本等。
一份数据详实、成果亮眼的ROI报告，不仅是对项目团队工作的肯定，更是为你争取未来进一步数字化投入的有力武器。
[资源下载] 点击此处，获取《制造业PLM项目规划与执行清单》可编辑模板
制造业PLM项目实施常见问题 (FAQ)
实施一个PLM项目通常需要多长时间？
这取决于项目的范围和复杂程度。对于一家中型制造企业，如果分阶段实施，完成核心功能（如图文档、BOM、流程管理）的第一期项目，通常需要6到12个月。这包括了从项目启动、需求分析、蓝图设计、系统部署到上线支持的全过程。企业自身的配合程度、数据准备情况是影响周期的关键变量。
PLM实施失败最常见的原因是什么？
根据我的经验，失败的原因主要集中在管理层面，而非技术层面：
- 缺乏高层支持： 管理层只是口头支持，在遇到部门阻力时无法提供有效推动。
- 目标不明确： 项目启动时没有设定清晰、可量化的业务目标，导致项目方向迷失。
- 忽视流程变革： 仅仅把PLM当成一个IT工具，试图用新系统去适应旧的、不合理的流程。
- 用户参与度不足： 在需求、设计、测试等关键环节，真正的使用者没有充分参与进来。
- 培训和上线支持不到位： 认为系统上线就万事大吉，忽视了对用户持续的赋能。
中小制造企业是否也需要上PLM系统？
非常有必要。研发管理的混乱和数据孤岛问题，并不会因为企业规模小而消失。中小企业可能没有大型企业那么复杂的流程，但对提升研发效率、保证产品质量、快速响应市场的需求同样迫切。市场上有许多针对中小企业的、更轻量化、更具性价比的PLM解决方案，它们通常采用云部署（SaaS）模式，投入更低，上线更快。关键在于选择与自身规模和业务复杂度相匹配的系统。
如何衡量PLM项目的投资回报率（ROI）？
衡量ROI需要从“硬性”和“软性”两个方面来看。
- 硬性（可量化）收益：
- 研发成本降低： 通过提升零部件复用率、减少物理样机、降低物料报废等。
- 产品上市时间（TTM）缩短： 通过优化流程、加强协同，让产品更快推向市场，抢占先机。
- 质量成本降低： 通过减少设计错误、改善变更控制，降低因质量问题导致的返工和索赔成本。
- 软性（难量化）收益：
- 协同效率提升： 跨部门沟通更顺畅，信息查找时间大幅缩短。
- 知识资产沉淀： 将经验和数据系统化，形成可复用的企业知识库。
- 合规与追溯能力增强： 轻松应对行业法规要求，建立完整的产品数据追溯链。
PLM与ERP、MES系统之间是什么关系，如何协同？
这是一个非常好的问题。我们可以用一个简单的比喻来理解：
- PLM（产品生命周期管理）： 负责定义“产品是什么以及如何制造”，是所有产品数据的源头。它管理着产品的设计、工艺、配方等“基因”信息。
- ERP（企业资源计划）： 负责管理企业的“财和物”，基于PLM提供的BOM和工艺路线，进行生产计划、物料采购、成本核算。
- MES（制造执行系统）： 负责“如何把产品在车间里做出来”，它接收来自ERP的生产订单和来自PLM的工艺指令，调度和监控车间的生产过程。
三者关系是：PLM是龙头，是数据之源；ERP是中枢，负责计划与资源；MES是手脚，负责落地执行。 只有将三者有效集成，打通从设计到生产再到运营的数据流，才能真正实现智能制造的闭环。
