系统科学（systems science）是一门总结复杂系统的演化规律，研究如何建设、管理和控制复杂系统的科学。系统科学汇集系统各个方面的研究，以识别、探索和理解跨越学科多个领域和应用的诸多范围的复杂性特征模式为目的。系统科学所包括的理论主要有一般系统论、信息论、控制论和耗散结构论、协同学、突变论等。
还有很多教材和著作，将系统工程称为“系统工程学”也存在类似的问题。钱学森曾在《论系统工程》中明确地说：系统工程“不宜像有些人说的那样泛称为科学”，以及“提‘系统工程学’这样一个词就太泛了”“强调系统工程是要改造客观世界的，是要实践的。”系统思维或者系统思考（systems thinking）是把认识对象作为系统，从系统和要素、要素和要素、系统和环境的相互联系、相互作用中综合地考察认识对象的一种思维方法。它将面对的问题视为整个系统的组成部分，并考虑到问题的潜在影响，而不仅是对特定部分结果或事件作出反应。系统思维是整体性的思维，帮助管理者以整体的视野去认识和处理管理复杂性问题，避免“只见树木”和只顾眼前利益带来的片面性。
系统思维在工程领域的实践应用是系统工程，但是不等于系统工程。既然是工程，就不能同时又是思想。所以经常有人说：“要用‘系统工程’思想作指导，把我们的单位搞得更好。”或者“要用‘系统工程’理论，把这个项目做好”的说法也有问题。系统工程不是思想、理论，系统工程就是工程方法。这些语言里面的本意，其实是系统思维或者系统论的观点和方法，能够指导单位建设、组织管理的是考虑整体、注重关系、避免局部和片面的系统思维。
****目标系统范围确定系统工程作用范围******
系统工程产生于第二次世界大战后期，20世纪五六十年代霍尔（Arthur D. Hall）等的研究，特别是随着美国“曼哈顿工程”和“阿波罗工程”等重大项目的成功实践，系统工程得以快速发展，形成了一套成熟的方法体系，成为研制卫星、飞机、舰船等目标系统（systems of interest, SOI）的重要方法，得到了越来越多研究与应用。本文不妨称这些项目为工程项目，而所研制的卫星、飞机、舰船等都是人造系统（man-made systems）。人造系统一直是系统工程讨论的目标和范围。国际系统工程协会（INCOSE）在其系统工程手册中指出：“ISO/IEC/IEEE15288和本手册中所考虑的系统是人造的，被创造并使用于明确的环境中提供的产品和服务，使用户和其他利益攸关方受益。”
1978年，钱学森在《文汇报》上发表《组织管理的技术——系统工程》，指出“系统工程是组织管理系统的规划、研究、设计、制造、试验和使用的科学方法，是一种对所有系统都具有普遍意义的方法。”这其中的“所有系统”是关键词，它将系统工程所瞄准的人造系统产品扩展到了社会系统，涉及到了“人”这个最活跃也最复杂的因素。以此为标志，中国的系统工程被推广到了管理领域，这篇文章也成为系统工程在中国发展的一个里程碑，掀起了全国研究和应用系统工程的热潮。随后出现了军事系统工程、农业系统工程、法制系统工程，以及环境系统工程、交通系统工程、教育系统工程、人口系统工程等，不下十几种。此后，对很多学者来说，系统工程的主攻方向转到了研究社会经济系统的组织管理问题。
这些领域都提高了以系统思维指导的自觉性，更加注重工作的整体性以及处理好各个元素的关系。以“交通系统工程”为例，仍然是原有交通管理专业的内容，但加强了交通规划的整体性以及统筹协调，这些都充分体现了系统思维的强大作用。扩展到社会系统的系统工程，其本质都是系统思维而不是系统工程在这些领域组织管理中的应用，它们与系统工程是“兄弟”关系而不是“父子”关系。
********工程项目中的系统工程定义与特点********
在国际上，美国电子工业协会标准 EIA/IS632定义系统工程是一个综合全部技术工作的跨学科方法。INCOSE 定义系统工程是成功研制系统的一种跨学科的方法（approach）和手段（means）。美国国家航空航天局（NASA）的系统工程手册认为系统工程是设计实现一个系统并对其进行技术管理、运行和退役处置的严格方法（approach）。欧洲空间局（ESA）的航天标准化组织（ECSS）将系统工程定义为一个跨学科的方法（approach），综合协调将需求转化为实际系统的全部技术工作。
中国航天系统工程方法是从需求出发，综合多种专业技术，通过全寿命周期分析—综合—试验的反复迭代过程，开发出一个满足使用要求、整体性能优化的系统。中国商飞系统工程的定义是：以满足客户需求为目的，围绕产品全生命周期，通过产品集成与过程集成，实现全局最优的一种跨专业、跨部门、跨企业的技术和管理方法。
总结上述系统工程定义可以看出：系统工程是途径、步骤、方法（不是思想、科学、理论）；相对于具体专业，系统工程是跨学科、跨专业的总体方法：系统工程通过全局优化致力于满足用户要求；系统工程面向目标系统的全生命周期。
********工程的扩展含义论与项目管理的关系**********
将系统工程与项目管理混淆起来的现象也非常普遍。现在有很多专著、书籍和教材，以“系统工程项目管理”命名，内容将两个联系紧密但又有区别的知识体系混淆起来，其主要原因可能是汉语的“工程”包含了“项目”的含义造成的，因此必须加以区分。
项目是为创造独特的产品、服务或成果而进行的临时性工作。项目管理的主要职能是对项目的计划、组织、指导、协调和控制。系统工程更多地关注所研制的系统（SOI）本身，更多地关注技术本身的问题，而项目管理致力于项目的全面成功，除了产品本身，也要考虑经费、进度以及团队多方面的成功。
工程项目的实施需要开展两类工作，一类是技术工作，表现为工程活动，例如需求分析、软硬件设计、软件编码、部件加工制造、集成和组装、试验与测试等，其主要责任人是工程师；另一类是管理工作，是为保障支撑技术研制活动而开展的计划、组织、协调和控制工作，例如，制定各类工作计划，监控项目成本和进度，实施采购和进行团队建设等，主要由管理人员完成。
在一个工程项目的实施中，系统工程方法首先体现为总体技术。现代几乎所有人造系统都是多个专业技术共同实现的系统，以复杂技术系统为研制目标的工程项目在这一点上更为突出。但系统工程不研究具体的专业技术问题，侧重于对系统总体问题（即系统构成要素、结构、信息交换和反馈机制等）的研究。系统工程方法一方面从需求及大系统约束条件出发，经过权衡和综合得到系统体系架构和各层级功能、性能要求；另一方面从部件、分系统到系统逐级集成并验证，最终得到满足用户需求的系统产品。
同时，系统工程管理又是系统工程方法的重要组成部分。总体技术涉及多个门类的专业技术，综合集成成千上万甚至更多的部件和元器件，历经由多个阶段组成的生命期，需要不同团队人员的参与和协作，因此总体技术活动的有序开展，离不开充分的管理工作保证。例如，研制工作计划制定、技术需求管理、技术风险控制、技术状态控制等。技术管理过程是项目管理和技术团队之间的纽带。
系统工程管理是项目管理的一部分，是项目管理中的技术管理。项目管理中的进度管理、经费管理以及质量管理和利益攸关方的管理等，是系统工程方法中定义用户技术需求、确定系统架构、开展技术评估评审和决策、开展验证和确认等技术过程和管理过程的输入和约束条件；系统工程又从技术管理层面提出了对项目人力资源管理、采购管理、沟通管理等的要求。
工程研制项目包括两类工作，一类是技术工作，一类是管理工作；系统工程方法包括技术和管理两个方面；系统工程技术是各类专业技术中的总体技术，系统工程管理是项目管理中的技术管理。
由于概念的外延不清晰，系统工程呈现出“打包拼盘”的情况，更有甚者将系统工程无限拔高，系统工程变成了一种无所不包、无所不能的“学问”，这样“包治百病”的拔高无异于对系统工程的“捧杀”，这很可能造成原本清晰的系统工程方法被淹没和异化，特别是系统工程的源头——航天等国防科技工业部门反倒说不清什么是系统工程了，从而在型号任务中不能顺利地实践系统工程。因此，必须还原各个概念，界定其内涵和外延，系统工程才能与系统科学、系统思维以及项目管理等各个层次各个专业的学科一起健康发展。
**作者简介：**曹松，中国航天系统科学与工程研究院，中国科学院国家空间科学中心，副研究员，研究方向为项目管理与系统工程。
已剪辑自: chinese.freecodecamp.org/news/what-i…
原文：What is Systems Engineering? A Beginner’s Guide，作者：Tiago Monteiro
我最近在读 J. Martin 的书《Systems Engineering Guidebook – A Process for Developing Systems and Products》（《系统工程指南–开发系统和产品的过程》）[1]。 从中我了解到，系统工程可以降低 40% 的制造成本——你知道吗？
我以前也不知道。即使在上了一堂以系统工程为主题的课后，我也只有在了解其在现实生活中的应用时才明白其相关性。
但是，系统工程是否用于软件开发？
是的！
一些大名鼎鼎的公司使用系统工程来改进他们的产品。
事实上，谷歌有自己的学科，叫作工程生产力.
Facebook 也有自己的，叫作生产工程.
另外，亚马逊雇佣了一个团队 的工程师来帮助建立其云计算基础设施。
为了了解什么是系统工程以及它的重要性，我们来回答四个问题。
- 什么是系统？
- 什么是项目的生命周期？
- 什么是系统工程？
- 为什么系统工程很重要？
什么是系统？
一个系统是许多“东西”的组合，它们像一个整体一样一起工作。
比如说：
- 太阳系统
- 树木
- 公司
这些例子中的每一个都有许多组件（行星、树叶、部门），它们共同构成一个整体。
这些组件也可以是子系统。例如，我们的太阳系有我们的星球。我们的地球有自己的系统，如地圈、生物圈，等等。
地质圈是地球上的一个 子系统。[2]
有关系统的例子
在编程中，你可以把程序看作是系统。
例如，某个程序中的一个函数可以被看作是系统中的一个元素。
通过为你的程序的不同组成部分布置一个系统，你不仅会做出一个更有效的程序，而且它也会变得更容易维护和在未来添加功能。
因此，你可以把程序的系统看作是其中的一种架构。
这里有一个编程中的系统的例子：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cJ4OZa9W-1655045998582)(raw.githubusercontent.com/xkyvvv/blog…)]
文件树来自 htm5up 网站模板
图片显示了一个网站模板项目的目录（或文件夹）的结构。
许多这些目录包含多个 .html、.css 和 .js 文件。
这些文件都有组件和特性，与项目内的其他文件相互作用。从本质上讲，你在这里有一个系统。
整个项目是一个系统。这个项目中的子系统是指方向。一个目录内的每个文件都有许多组件，它们构成了一个项目的整体。
通过学习如何创建一个系统，你将学会如何更好地创建和管理项目。
什么是项目的生命周期？
项目的生命周期指的是某个项目的各个阶段——从想法到项目的创建，到最终的使用和最后的制造。
通常情况下，项目的生命周期包括：
- 构思
- 创造一个想法
- 为实际的项目概念创造概念
- 使用和支持该项目
- 停用
下面是一个例子，解释了如何应用系统工程为一个公司开发网站。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Lw0EdKko-1655045998582)(raw.githubusercontent.com/xkyvvv/blog…)]
Photo by Eduardo Dutra from Pexels
项目生命周期实例
假设你正在经营一家软件公司，一个客户要求你为他们公司开发一个网站。
提出想法
在这里，你需要与客户进行对话，以确定项目将如何发展，并了解客户对项目的实际需求。
与客户讨论未来可能出现的问题也是一个好主意，无论是技术还是财务问题。
这是迄今为止项目整个生命周期中最重要的阶段。
不了解客户的需求，你就无法完成他们想要的项目。无论你的技术知识如何，这一点都是真实的。
创造和发展想法
下一步是在了解客户的需求后，计划所有需要的步骤，把计划变成一个真正的项目。
举例来说，你要计划出你将在哪里启动网站，在哪里部署网站，等等。
为实际的项目概念提出构想
在这个阶段，你建立客户想要的项目。这也是一个极其重要的步骤。
它允许你根据客户的要求来设计网站。
使用和支持该项目
我们现在正处于生产阶段。在这个阶段，项目将被测试，任何技术问题将被修复。
如果有技术问题，应该是小问题，而且不应该对网站的大部分内容产生不利影响。
然而，一旦项目交给客户，维护工作就应该由客户来处理。
停用
在这最后一步，网站将被停用。
它要么被另一个网站取代，要么客户结束他们的公司并关闭该网站，等等。
什么是系统工程，它为什么重要？
我们已经看到，一个系统是许多 东西 的组合，它们作为一个整体一起工作。
我们还看到，系统有生命周期。
那么，在项目开始前和执行过程中对这些生命周期进行规划的行为被称为系统工程。
系统工程的技术实例
让我们想象一下，你已经知道客户想要什么。
想象一下，他们让你设计一个电子商务网站，该网站将承载来自卖家的成千上万张照片。
该网站需要一个中央服务器来托管和传递大量来自用户的图片。例如，你的网站可能以其销售的产品图片为特色。
你需要创建一个高效且易于维护的系统，在短时间内为网站请求图片。
你如何能实现这一点？
难以回答吧？毫无疑问，这是一个具有挑战性的问题。
一个需要对系统进行规划以最大限度地提高效率，并尽可能地易于维护的问题。
如果你想了解更多关于这个问题，你可以查看这篇文章。
虽然这是一个大的技术问题，但还有其他更严重的问题。
例如，管理一个大型开源图书馆的增长的最佳方法是什么？
它的架构究竟如何，才能做到高效和易于使用？
这里 是对 Python 中一个流行的库架构的概述，matplotlib。
当你计划一个系统时，你可以创建和管理程序的架构。
这样，开发者就不必担心功能目标的缺失、严重的缺陷，或在生产和维护上花费大大超过预期。
正是由于这个原因，谷歌、Facebook、亚马逊和其他许多公司都有专门的系统工程师团队。
通过系统工程，我们可以制定一种“计划”，以接近完美的方式实现我们的目标或公司的目标。
总结
好了，现在你明白了：
- 什么是系统
- 什么是项目生命周期
- 什么是系统工程以及它在各种项目中的价值
谢谢你阅读本文！
附录
- J. Martin, Systems Engineering Guidebook A Process for Developing Systems and Products. London: CRC Press, pp. 5–6.
- National Geographic Society, “Earth’s Systems,” National Geographic Society, Oct. 29, 2019. www.nationalgeographic.org/article/ear…
- “The Architecture of Open Source Applications (Volume 2): Scalable Web Architecture and Distributed Systems,” www.aosabook.org. www.aosabook.org/en/distsys.…
- B. Douglass, in Real-time design patterns: Robust Scalable Architecture for real-time systems, Boston: Addison-Wesley, 2003, pp. 96–97.
系统工程在工业界是始于航天工业。对于一个复杂系统，单独某个方面的工程师是无法掌控整体系统的设计的。举个例子，如果一个功能用硬件或软件都可以实现，但是他们实现的代价不同，这时候就需要系统工程师在整体框架下对不同的解决方案进行权衡，试图定义一个在成本，性能，安全性，用户体验诸方面最均衡的设计。
更为重要的是，系统工程对于产品设计的质量是至关重要的。 在整个设计控制过程中，系统工程师负责定义设计参数与要求，管控设计风险，处理不同模块之间的设计冲突。在很多公司里，系统工程师还需要支持设计转化，产品更改甚至产品注册。
个人经验是系统工程师并不适合新手工程师去做，这个职位需要的是对本行业与产品有一定的了解，并对公司各个职能都有联系–因为系统工程师在进行总体设计时是需要来自方方面面的信息，同时也要与不同职能的同事合作以实现设计目标。
1.你关于系统工程的第一印象是什么？
第一印象就是：这玩意是聪明绝顶的人用来制造复杂机器，实施复杂项目或者复杂工程的秘密武器。
2.系统工程的工程师们都应该做什么？
他们基本上就是要一览众山小地全局观，统筹各个子系统互相协调，然后和外界相互协调，然后整个大系统正常运行。
3.系统工程师们应该对什么事负责任？
对整个项目负责，上到战略，计划执行，下到一个螺丝钉买没买对~
系统工程之大局观：写点关于系统工程大局观的东西，在一个大型研发项目中，系统工程处于什么地位，在各个阶段主要做什么，与其它部分的关系是什么。不同领域有不同的研发过程标准，这里仅举美国DoD的例子，DoD的系统范围比较广，从复杂的航母到简单的枪支都有，不像NASA那样比较单一，便于不同行业的人理解；DoD也比较强势，能够整合三军的标准，整个研发过程各个标准协调一致性很好；DoD有两张教学挂图（就是下面两张），非常完整地展示了整个武器系统采购中各个系统之间的关系。在这两张图上，横轴代表研发阶段，分为：装备方案分析阶段（目标是选择满足能力需求的方案，主要活动是执行多方案分析），技术成熟和风险规避（目标是技术成熟减少风险，主要活动是竞争样机）、工程研制（目标是生产的设计，证明产品是可生产的，活动是详细设计和系统演示） 、生产部署（目的是证明生产线并生产和部署系统，活动是生产、初始作战使用评估和部署）和使用保障阶段，生产部署和使用保障有所重叠。纵轴是各个系统，包括三大块，第一是JCID(联合能力整合与开发系统），这个系统是分析需求的，最初美国国防是基于威胁来采购产品，后来经过改革是基于国家战略来采购能力，能力可以是非装备的，例如通过改装现役装备或者培训部队来达到某种能力；第二块是PPBE(计划和预算执行系统)，这个系统是管钱的；第三块是DAS(国防采购系统)，这里面有项目管理、签合同、系统工程、软件、试验和评估、生产、后勤保障等，国防采购系统的主要产品包括AoA（多方案分析）、装备方案、Prototypes（样机）以及产品；在方案分析阶段，系统工程的主要任务是分析需求、规定性能指标、评估可选方案，在技术成熟和风险规避阶段，系统工程的主要任务是对成本性能进行权衡、计划技术方法、管理技术风险、建立系统架构，在工程研制阶段，系统工程的主要任务是最终定稿设计和制造规范、策划小批量生产，之后的阶段主要任务是评估生产准备状态、评估系统功能、改进系统等。以上三个系统的驱动方式不同，JCID是需求驱动，PPBE是时间驱动，DAS是事件（评审、产品的交付等事件）驱动。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3Nr0xV3C-1655045998582)(raw.githubusercontent.com/xkyvvv/blog…)]
有很多人问有哪些系统工程专业大学可以选，转个地址吧：www.incose.org/academic-af…。里面有个下载文件，可以查。
更新201808
写一个影响了世界的系统工程项目：Semi-Automatic Ground Environment (SAGE)，翻译过来叫半自动地面环境。这个项目为计算机时代和互联网时代奠定了基础。在第二次世界大战的时候，英国在伟大的不列颠空战中利用一项全新的技术：雷达取得了胜利，当时各个雷达站收集的信息被汇总到指挥中心，由操作员观察敌军的动向，并指挥迎击，但当时的信息有5min延迟，对于第二次世界大战的飞机还够用，但到了冷战时期，美国面临苏联的战略轰炸机的危险，这个延迟就太大了，为此美国国防部授权空军去改进防空系统，而美国空军又找到了麻省理工去做这个事情。当时的假设情景是苏联的战略轰炸机会从高空过来，然后在最后一段航程潜入低空，由于水平线的限制，地面雷达很难发现目标（当时还没有空中雷达），而且当时雷达站之间用无线电通讯，会被核打击的脉冲电磁波干扰。为此，MIT列出了两个核心问题： 第一，要能将各个雷达站的数据传输到中央计算机；第二，要有可以实时分析数据的计算机。今天看起来这两个问题很好解决，但当时是1950年，既没有互联网，也没有计算机。当时的美国空军一个实验室开发了一个将雷达模拟信号转换成数字编码的早期形式的调制解调器，而MIT的伺服机构实验室也为飞行仿真开发过一个计算机，但这个计算机仅仅有5个字的RAM和27个字ROM，还不如我们现在最简单的手持计算器，为此MIT成立一个数字计算机实验室开发了磁芯存储器。这个项目的成本超过了原子弹的曼哈顿项目。有趣的是，这个项目由于苏联搞了战略导弹，其在军事上作用有限，但这个项目的成果包括存储器、调制解调器、软件工程却对世界产生了革命影响，通过这个项目成长起来的IBM在1954去搞一个微缩版的SAGE系统，叫作半自动业务相关环境SABRE，用于航空订票系统（应该是我们的12306的祖先吧），最后从一个制表器公司成为世界计算机行业巨头；MIT林肯实验室成为美国雷达科技最先进的研发中心 ；兰德公司的一个系统工程部门“系统开发公司”为SAGE开发软件，后来推动了软件工程和信息技术的发展 。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E6QGdOzY-1655045998583)(raw.githubusercontent.com/xkyvvv/blog…)]
更新，写一个涉及验证、软件工程和控制工程、可靠性、故障追踪方面的例子。那是在很多年以前，刚参加工作不久，当时碰到一个产品，交付后可靠性很低。先介绍一下这个产品的背景，这是个控制系统，采用一种类似脉冲调宽PWM控制方法，也就是说控制器送给执行器的不是个比例信号，而是个脉冲，经典PWM仅仅调制脉冲宽度，而我们更复杂，还要调制脉冲的中心，其原理就是计算机根据所需控制量大小生成脉冲上升沿和下降沿，最早用模拟电路做，后来用软件实现，当时还是汇编。学过控制的大概都清楚，大学里面通常学得都是周期性线性控制，至于脉冲调制控制，很少学到，在这个系统中脉冲边沿的生成与控制解算周期是异步执行的，控制专业对这个异步执行的行为缺少 认知，而软件编码的人对异步执行中的数据更新也缺少理解，这就埋下了小强滋生的土壤。有一次一个很明显的故障引起了我的注意，表现为脉冲的边沿不准确，但这个现象很随机，很难抓住。一般来说，验证一个控制器是否准确，有两种方法，一种是给产品加一个输入，测量这个产品的输出，用记录下的输入在仿真程序里面跑一下，得到一个标准输出，再将标准输出和实际输出对比，就可以直观的看出是否超差；第二 种是提供一个标准输入，预先计算出标准输出，再选择几个典型时刻比对标准输出和实际输出。两种方法我们都用到了。但如前所述，这是脉冲调制控制，不像比例关系那么直接，另外由于控制专业对脉冲的生成所采用的异步机制缺少认知，也没有仿真脉冲生成的过程，仅仿真到脉冲生成的前端，因此，第一种方法不知道脉冲生成有没有问题；第二种方法虽然发现了有时候脉冲生成的不准确，但由于其很随机，通常大家都将其作为随机输入噪声引起的，为此验收时还有意放宽了标准。我发现了几个脉冲不准确后，对此有所怀疑，于是想到了一个验证方法： 统计。虽然噪声可能引起个别误差，但当统计样本量足够多时候，误差的平均值应该趋于0，这一统计不得了，发现了脉冲生成有一个系统性延迟，而且这个延迟有一个很大散布。然后，对历史数据做了个回顾，一直回顾到很多年前研制阶段的某个时间点，在这个时间点前没有系统延迟，在这个时间点上，控制对象的运动出现了系统偏差，当时请了很多专家分析，最后原因不清楚，没有人想到是控制器本身输出不正确，后来控制专业在算法做了补偿算是将 这个问题解决了，但是他们没想到的是算法虽然能够补偿系统延迟，但无法补偿随机散布。这个随机散布引起了后面一系列可靠性问题并持续数年之久。当我得出是控制器本身出问题的结论后，编软件的人开始查软件，最后发现其内部中断设置有错误。最终进行了软件升级，消除了系统延迟，取消了控制补偿，算是解决了问题。这个故事说明了几个重要的事： 1. 细心。2. 验证方法设计。3. 出现故障时仅仅有解决措施不行，还要机理清楚。
更新，搬运一个洛克西德马丁公司的系统工程职位说明，国内是不会这么详细的说明的，注意它们的系统工程职位下有很多种，这只是其中一个：
要求ID:245519BR
工业职位标题：系统工程
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
