<span id="OSC_h2_1"></span> 关于开源之夏
开源之夏是中国科学院软件研究所发起的 “ 开源软件 供应链点亮计划” 系列暑期活动，旨在鼓励高校学生积极参与开源软件的开发维护，培养和发掘更多优秀的开发者，促进优秀开源社区的蓬勃发展，助力开源软件供应链建设。
202 5年，开 源之夏与 182 家优秀开源社区紧密合作，OurBMC社区也积极参与其中。今天，我们采访 “基于三维引擎的BMC硬件展示” 的开发者李宇航（个人Github：https://github.com/olddove-laoge）。
项目链接： https://summer-ospp.ac.cn/org/prodetail/25ce30009?lang=zh&list=pro
关于贡献者——李宇航
OurBM C社区： 请简单介绍一下自己。
李宇航 ：
我是南昌大学2024级软件工程专业的一名学生，今年是第一次参与开源之夏的活动。
OurBMC社区： 是什么样的契机让你决定参加开源之夏活动？以及参加这种活动和你平时在学校学习体验有哪些不同之处？
李宇航：
关于参加开源之夏的契机，其实就是两点：一是想多练练实战能力——平时在学校都是做老师布置的作业，要么是零散的小程序，要么是小范围的小组项目，很少有机会完整参与一个真正的大型项目，想试试从看懂别人的代码、理解项目逻辑，到自己动手开发新功能的全流程；二是觉得有一段开源经历，在没有实习经历时，简历能比其他人更有优势 。
开源项目和学校学习的区别真的挺大的：学校的作业目标都很明确，老师会把要求说清楚，我们只要按部就班完成，验证知识点就行，不用考虑太多其他的；但开源之夏面对的是成 熟的大型项目，首先得花时间阅读别人写的海量代码，还得遵守项目里的代码规范，提 交修改的时候还要走流程、接受审核。而且不能只想着自己写的功能能用就行，还得考虑会不会和其他模块冲突、会不会影响项目的整体使用。这种 “在现成的大项目里添新东西” 的体验，比学校的作业复杂的多，也让我学会了怎么在团队协作里做事，怎么考虑问题更全面，感觉比在学校单纯学技术要实用很多。
关于李宇航与开源的故事
OurBMC社区： 可以分享一下你的开源经历吗？
李宇航：
虽然是第一次参与开源之夏活动，但其实这并不是我唯一的开源经历。作为南昌大学超算俱乐部的一员，我参与构建了俱乐部的项目——寻路之南：普通人的大学成长指南(https://github.com/NCUSCC/cs4ncu)，此项目已经获取了80多个star。此外，我在参与比赛时和同学一起编写了一个小型项目：避雷真，通过大模型进行商品避雷，该项目及其子项目在github上也有10+个star（https://github.com/olddove-laoge/SpotTruth）。这些经历不仅锻炼了我的代码能力，同时还教会了我怎样更好的进行团队合作。
OurBMC社区： 分享一下你是如何了解到 OurBMC社区的？
李宇航：
我是听专业课老师介绍的OurBMC社区，当时老师聊到开源项目实践，说这个社区里有他之前带的优秀学长，我想着有熟悉的学长在，后续参与的时候遇到问题也能多请教，就主动去了解了一下，之后就加入了该项目。
OurBMC社区： 请介绍一下你眼中的 OurBMC社区。
李宇航：
OurBMC 社区是一个积极致力于开源事业发展的专业平台。 社区不仅在 “开源之夏” 等重要开源项目中设立专项课题，还主动参与开放原子设计大赛等行业核心赛事，通过提供奖金支持等激励机制，广泛动员并鼓励广大学生群体积极投身社区项目建设与技术创新，OurBMC 社区是一个兼具行业影响力与发展潜力的优秀开源社区。
关于 “基于三维引擎的BMC硬件展示” 项目
OurBMC社区： 在项目申请过程中，你是如何选择开源社区和项目的？有考虑哪些因素？
李宇航：
正如前文所述，因有学长作为 OurBMC 社区的核心成员，我此前已通过学长的分享对社区进行了初步且全面的了解，对社区的发展理念与开源氛围抱有较高的认可与好感。后续 “开源之夏” 项目申报通道开启后， 我第一时间将 OurBMC 社区列为优先选择对象。 基于此前的了解，OurBMC 社区在开源领域始终保持着活跃的参与度与积极的建设姿态，其项目质量与社区生态均具备较强的吸引力，这也是我最终倾向于选择该社区的重要原因。
OurBMC社区： 在准备项目申请书的过程中做了哪些准备？有什么技巧可以推荐给之后参与活动的同学们么？
李宇航：
首先是吃透需求，反复琢磨社区对 “BMC 硬件 3D 展示” 的核心诉求 —— 不只是简单的 3D 建模，更要适配现有 WebUI、支持交互和真实数据对接，所以先明确了 “可视化 + 实用性” 的核心方向；然后是技术调研，因为要用到 Vue 和 Three.js，我先补了补 Three.js 的基础 API（比如几何体创建、场景渲染这些），还找了几个类似的 3D 展示案例参考，确认技术方案的可行性；接着拆解开发任务，按照 “环境搭建→基础开发→功能完善→集成优化” 的逻辑，把 200 小时的工作量拆分到六个阶段，每个阶段都明确了具体要完成的目标（比如第一阶段要搞定环境和设计文档，第二阶段完成基础 3D 场景搭建），避免后续混乱；最后还提前写了个简单的 Demo，验证 Vue 和 Three.js 的结合效果，确保技术选型没问题，也让申请书中的方案更有说服力。 技巧推荐：
-
贴合社区核心需求，不盲目炫技；
-
优先选熟悉的技术，降低开发难度；
-
细化任务和时间节点，明确阶段产出；
-
提前做小原型验证可行性；
-
文档简洁明了，说清技术、进度和价值。
OurBMC社区： 请介绍一下你在本届活动中承担的开源项目，在开发过程中有遇到哪些困难与挑战？你是如何克服它们的？
李宇航：
我所承担的项目最终目的是用尽可能轻量的3d技术模拟展示机箱内部的元器件所有信息，精确到具体空间长度，可多角度切换观察。具体数据由后端提供，前端获取数据后使用3d技术展示。
开发过程中遇到了几个实际问题，都是边查资料边尝试解决的：第一个是模型格式的问题，一开始选了 FBX 格式的模型，加载后没法在 3D 场景里精准放到指定位置，硬件布局根本还原不了。我查了 Three.js 的官方文档和相关技术帖，发现 GLB 格式是专门适配网页 3D 渲染的，换成 GLB 格式后，模型就能以指定的大小精准显示在指定位置了。第二个是模型精度的问题，一开始建模时把元器件的细节做得太细，导致模型适配不同尺寸 机箱时，拉伸后容易变形，还看不清元器件类型。后来我简化了非关键的细节，比如去掉元器件表面复杂的纹理，只保留 CPU 方形、风扇圆形这些核心特征，再用 Three.js 里的 Box3 方法获取模型原始尺寸，按比例缩放，既保证了辨识度，又能适配不同机箱的尺寸需求。第三个是没法对接真实后端 API 的问题，没有真实数据就验证不了硬件状态动态展示的功能。我就用 Mock.js 工具按照设计好的 API 数据格式做了模拟数据集，通过 Axios 请求这些模拟数据，成功让 3D 模型能模拟显示风扇转速、CPU 温度这些状态，先完成了功能验证，也为后续对接真实后端做好了准备。
OurBMC社区： 在整个开发过程中，你有哪些开发经验可以分享给读者们？
李宇航：
第一，保持 “需求先行” 的思维。 不管用什么技术、做什么项目，核心都是解决实际问题 —— 不能先想着 “我要用到哪些新技术”，而是先明确 “项目要达成什么目标、用户 / 社区真正需要什么”。就像这次 3D 展示项目，核心需求是 “精准可视化 + 实用交互”，而非 “堆模型细节”，所以我放弃了复杂纹理，优先保证适配性和数据对接，这一点适用于任何开发场景：先锚定需求核心，再倒推技术方案，才能避免做无用功。
第二，养成 “拆解复杂问题” 的做事习惯。 面对大型项目或模糊需求时，别想着 “一口吃成胖子”，而是用 “结构化思维” 把大目标拆成可落地的小模块。比如 200 小时的开发任务，我按 “准备→搭建→完善→优化” 的逻辑拆分阶段，每个阶段只聚焦 1-2 个核心目标，既避免了混乱，也能及时看到阶段性成果，增强信心。这种思路不管是做开源项目、课程设计还是未来工作，都能帮我们理清逻辑、掌控进度。
第三，建立 “低成本验证” 的试错意识。 遇到不确定的技术方案或需求理解时，别盲目投入大量时间深钻，先做最小可行性验证—— 比如不确定技术选型是否适配，就搭个简单原型测试；不确定需求理解是否到位，就先出个简化版本和社区 / 导师确认。这样能提前规避方向错误，用最低成本验证可行性，比等到开发中后期再返工高效得多。
导师寄语
@导师Kooji（喻柏炜）：
宇航同学在本次开源之夏项目中，承担了课题的开发工作，整体表现突出，展现出了优秀的技术学习能力、工程实践意识和良好的协作沟通素养。在项目执行过程中，他快速理解了BMC（基板管理控制器）的业务逻辑与3D可视化结合的应用场景，并主动研究了Three.js等前端3D技术栈，在较短时间内完成了技术选型与原型搭建。他不仅实现了服务器设备关键部件的三维模型渲染与状态交互展示，还注重代码的可维护性与用户体验，对交互细节做了持续优化。
宇航同学在本次项目中圆满完成了项目既定目标，具备了在开源项目中协作成长的潜力。作为指导老师，对其表现表示充分肯定，并期待他在未来的技术道路上持续精进，取得更大进步。
</div>
