關於開源之夏

開源之夏是中國科學院軟件研究所發起的 “開源軟件供應鏈點亮計劃” 系列暑期活動，旨在鼓勵高校學生積極參與開源軟件的開發維護，培養和發掘更多優秀的開發者，促進優秀開源社區的蓬勃發展，助力開源軟件供應鏈建設。

2025年，開源之夏與 182 家優秀開源社區緊密合作，OurBMC社區也積極參與其中。今天，我們採訪 “基於三維引擎的BMC硬件展示” 的開發者李宇航（個人Github：https://github.com/olddove-laoge）。

項目鏈接：https://summer-ospp.ac.cn/org/prodetail/25ce30009?lang=zh&lis...

關於貢獻者——李宇航

OurBMC社區：請簡單介紹一下自己。

李宇航：

我是南昌大學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技術棧，在較短時間內完成了技術選型與原型搭建。他不僅實現了服務器設備關鍵部件的三維模型渲染與狀態交互展示，還注重代碼的可維護性與用户體驗，對交互細節做了持續優化。

宇航同學在本次項目中圓滿完成了項目既定目標，具備了在開源項目中協作成長的潛力。作為指導老師，對其表現表示充分肯定，並期待他在未來的技術道路上持續精進，取得更大進步。