基础软件研发是培养高水平计算机人才的重要载体。操作系统、实时系统、虚拟化等系统软件涉及计算机体系结构、内核机制、外设驱动、多核并行、网络通信和软硬件协同，知识跨度大，工程链条长，对研发人员的专业基础、工程能力和解决复杂问题的能力都有很高要求。

ZVM嵌入式虚拟化实时操作系统面向具体芯片、操作系统和应用场景开展研发。学生参与其中，需要面对系统启动、内存管理、中断虚拟化、多核协同、外设复用、Linux与RTOS混合运行、实时性能优化等实际问题。这样的研发过程，为拔尖创新人才培养提供了一个持续、完整、具有挑战性的实践平台。

基于ZVM的人才培养通常经历系统部署与测试、“小而全”模块攻关、工程项目研发三个阶段，在逐步深入的实践中完善知识结构，提升研发能力，形成系统思维和创新能力。

图1：基于ZVM的拔尖创新人才培养路线

第一阶段：系统部署与测试——形成系统知识画像

不安排研发任务，只完成ZVM、Guest OS、开发板和工具链的部署与测试。通过启动、配置、测试和简单故障排查，熟悉各模块功能、系统层次和基本技术。

对于前期接触系统软件较少的学生，这一阶段会集中接触大量新的专业概念，知识量增长很快。重点是尽快形成自己的系统知识画像：知道系统有哪些部分、各自做什么、相互怎样关联，遇到问题大致应该从哪里入手。形成基本认知后，尽快进入第二阶段。

第二阶段：“小而全”模块攻关——独立完成一次完整开发

根据第一阶段形成的系统知识画像，安排一个边界清楚的“小而全”模块任务，例如支持一款Guest OS、适配一款处理器芯片，或者完成一个相对独立的外设模块。这类任务通常已有相近的参考实现，便于把完整研发过程走一遍。

学生需要从需求、方案、编码、调试一直做到测试和完善。这个阶段最重要的收获，是切实体会到“功能跑起来”和“软件做完整”之间的差距，并形成规范的开发习惯。

第三阶段：工程项目研发——承担实际研发任务

完成“小而全”模块后，进入ZVM工程项目，承担实际研发任务。该阶段任务会更复杂，涉及的模块更多，也会遇到没有现成答案的问题，需要查代码、读手册、做实验，也需要和团队成员讨论协作。

做到这一阶段，学生开始形成自己的研发方向，逐步承担核心模块、性能优化甚至系统设计工作。随着研发不断深入，技术专长逐渐形成，也会从工程问题中发现值得研究的问题，并形成论文、专利、开源成果或新的技术方案。

一、专业知识结构要完整

系统软件研发首先要求建立覆盖软硬件的完整知识框架，并围绕具体研究方向持续深入，在实践中不断补齐知识短板。只理解操作系统而不了解处理器体系结构，很难解释很多底层异常；只熟悉Linux而不了解RTOS，很难真正理解硬实时；只会写应用程序而不了解驱动、中断、MMU、Cache和DMA，也很难完成复杂系统的开发和调试。

ZVM的研发天然跨越多个层次。完成一个新平台适配，需要理解处理器启动流程、异常等级、内存布局、页表、中断控制器、定时器和多核启动；继续向上，还会涉及RTOS内核、Linux内核、VirtIO、外设驱动、共享内存和核间通信；更复杂的场景还会进入GPU、NPU、IOMMU、SR-IOV和TSN等技术。

这些知识在课程体系中通常分属于不同课程，在实际系统中却紧密联系。学生需要能够从寄存器看到驱动，从驱动看到内核，从内核看到Hypervisor，再看到Linux、RTOS和应用。只有形成完整的知识结构，才能真正理解复杂系统，也才能在已有技术的基础上发现新的问题。

专业学习阶段应尽可能把计算机系统、体系结构、操作系统、数据结构、网络、编译、嵌入式系统和实时系统等基础打牢。前期课程掌握得不够扎实，也可以通过开发一个“小而全”的ZVM模块，把体系结构、内核、驱动、调试、测试等环节完整走一遍，在“边学边做”中补齐知识短板。很多知识需要经过实际使用、反复调试和验证，才能从“学过”逐步变成“掌握”。

二、研发能力要成熟

会写程序只是系统研发的起点。软件研发还包括架构设计、接口定义、异常处理、并发控制、性能优化、测试验证、文档维护以及长期演进。一个功能能够运行一次，只能说明基本逻辑已经实现，距离成熟软件还有很长距离。

编程和考试不同。考试60分可以及格，软件研发中，60分往往只能完成一个简单Demo；真正达到产品的基本门槛，至少要做到99分。剩下的1分，可能是一次低概率死机、一次越界访问、一次资源泄漏，或者一次长时间运行后才出现的实时抖动。这个1分，往往也是产品化过程中最难、也最需要解决的部分。

ZVM是一套长期持续演进的系统，代码完成以后还会继续被使用、移植和维护。一个模块能不能在不同平台工作，异常场景是否处理完整，长时间运行是否稳定，接口是否清楚，后续人员能不能继续维护，这些都属于研发工作的一部分。

成熟的研发能力最终体现为做事可靠。接到一个任务，能够理解需求、分析方案、拆分问题、实现功能、验证结果并完成收尾；遇到困难能够及时定位，方案存在问题能够主动调整，完成以后能够让后续工作继续开展。这样的能力需要在实际项目中长期训练。

三、面对困难要有攻坚的勇气

底层系统研发经常会遇到没有现成答案的问题。串口没有输出、MMU开启后系统异常、中断无法进入、多核启动失败、Linux或RTOS Guest运行异常、外设直通失败，这些问题在系统研发中都很常见，也往往无法通过简单搜索得到答案。

面对这类问题，需要严谨，也要敢于动手验证。第一次接触开发板，不能因为担心线接错、板子出问题，就不敢动手尝试；进入内核和底层代码，也不能因为担心系统跑不起来，就只停留在熟悉的区域。该查手册就查手册，该接线就接线，该改代码就改代码，核对硬件连接、运行条件和修改范围，通过小步验证逐项排查，并保留日志、配置和代码版本，让每次尝试都能有所收获。

系统崩溃，就分析异常现场；信息不足，就增加观测手段；页表有问题，就逐项核对映射关系；中断不进入，就从中断控制器、路由配置、异常等级和CPU状态逐层排查。底层研发，很多时候就是这样一点一点把问题找出来。

很多有价值的问题没有现成答案，需要持续分析和验证。解决一次复杂启动问题、一次难以复现的异常或者一次微秒级实时抖动，学生对系统的理解通常会明显加深。长期经历这样的过程，面对陌生芯片和陌生系统时，才会逐步建立起解决问题的底气。

四、复杂问题要讲得简单清楚

系统研发还特别需要清楚的表达能力。技术问题本身已经复杂，如果汇报时背景过多、细节过多、术语堆积，团队很难快速判断问题，也会直接影响研发效率。

一个技术问题通常需要先讲清楚几件事情：当前出现了什么现象，正常情况下应该是什么结果，两者之间有什么差异，目前判断问题可能在哪一层，已有证据是什么，下一步准备如何验证。核心问题讲清楚以后，再展开必要的技术细节。

技术表达也要避免简单粗暴地“秀肌肉”。术语多、图复杂、代码长，并不能说明问题研究得深。把问题、原因和方法讲清楚，让别人能够快速理解和判断，更重要。

表达简单清楚的前提，是对问题本身理解清楚。问题没有想透，表述往往会越来越长；真正定位到关键点以后，通常可以用很少的话说明问题。学生在ZVM研发中需要逐步做到：问题说得准、原因说得清、方案说得明白，不绕、不虚、不堆砌概念。

五、在完整研发中形成系统性思维

ZVM涉及硬件、Hypervisor、Guest OS内核等多个系统层次，一个问题很少只停留在一个模块。一个VirtIO问题可能同时涉及Linux驱动、虚拟外设和RTOS虚拟后端；一个多核通信问题可能涉及共享内存、核间中断和Cache一致性；一个实时性问题又可能与调度、中断、外设访问和核间干扰同时相关。

学生在这种环境中，需要沿着一条完整的数据路径和控制路径持续分析。上层没有发现问题，就继续进入内核；内核没有问题，就进一步检查Hypervisor、驱动和硬件。遇到陌生模块，需要阅读代码、查阅芯片手册和技术规范，再通过实验确认判断。

这种训练能够逐渐形成系统性思维。面对问题时，先判断问题处在哪一层，再沿完整的数据路径和控制路径分析；修改一个模块时，要考虑对接口、资源、实时性和其他模块的影响；设计功能时，要考虑模块边界、系统耦合和长期演进；优化性能时，要依靠测量和数据进行判断。

系统研发做到一定阶段以后，学生还需要开始形成自己的技术判断。已有系统为什么这样设计，某个模块是否必要，一次切换能不能减少，系统边界是否可以重新划分，这些问题会进一步推动学生从系统实现走向系统设计。

六、在工程项目中训练协作与研发能力

ZVM面向具体硬件和实际需求持续演进，学生参与的代码需要真正运行在芯片上，也需要面对Linux、RTOS、外设和应用。实际项目不会按照教材顺序给出问题，也不会提前告诉答案。一次系统移植可能同时遇到启动、中断、时钟和驱动问题；一个外设虚拟化功能可能需要连续修改多个模块；一个性能问题可能经过多轮测试以后才能确定真正原因。

ZVM涉及多个系统层次和模块，很多问题靠一个人长时间闷头做，容易陷入局部判断甚至钻牛角尖。遇到问题要及时交流，把现象、判断和证据拿出来讨论。个人要有独立思考和解决问题的能力，也要愿意听取不同意见，避免闭门造车。讨论要基于现象、数据和证据，避免停留在观点争论。

实际项目研发也为科研提供问题来源。通过梳理已有工作，把工程问题抽象为值得研究的问题，明确约束，提出可验证的假设，再通过实验评价方法的效果和局限。工程中发现问题，研究中形成方法，再回到实际系统中验证，形成研究与研发的闭环。

七、从完成任务走向独立创新

拔尖创新人才培养不能只停留在完成导师安排的任务。学生在前期需要学习已有系统、掌握基本方法，随着能力提升，应逐步承担更完整的模块，最终能够自己发现问题、提出方案并完成验证。

ZVM的发展本身提供了这样的空间。随着平台、外设和应用不断扩展，新的技术问题会不断出现。如何进一步降低虚拟化开销，如何提升硬实时能力，如何减少软件层次和系统耦合，如何更好地支持GPU、NPU和TSN，都需要持续研究。

学生做到这一阶段，评价标准也应发生变化。关注点逐步从代码量、功能量转向问题判断、方案设计和系统验证。一个好的想法，最终还要落实到实际系统中，通过运行结果验证其有效性。对于系统软件研发，这也是技术创新必须经历的重要环节。

创新能力来自长期积累。专业知识要完整，研发能力要成熟，面对困难敢于深入，对复杂问题能够准确分析和清楚表达。在这些基础上，才能逐步形成独立判断，提出自己的方法，通过实际系统完成验证，形成有价值的技术创新。

结语

基于ZVM的人才培养，最终希望学生形成可迁移的系统能力。学生未来无论继续研究虚拟化，还是进入操作系统、芯片、智能汽车、机器人和工业控制等领域，这些能力都可以继续发挥作用。

几年以后，面对一颗陌生芯片、一个陌生操作系统或者一个没有现成答案的问题，能够快速形成对系统的整体认识，知道从哪里入手，并能够拆解问题、验证判断、把事情做完整；进一步能够从实际问题中提炼值得研究的问题，提出自己的方法并完成验证。这是ZVM拔尖创新人才培养希望达到的目标。