「我們直到最近才發現，Andy 在 3 月 29 日申請了 MeshCore 商標，而且完全沒告訴我們任何人。」

這不是某間新創公司的宮鬥戲碼，而是開源專案 MeshCore 本週爆出的真實風波。一個從 2025 年 1 月才開始、以 mesh 網路技術為核心的開源專案，僅用一年多時間就累積了超過 38,000 個節點和 10 萬活躍用戶，如今卻因「AI 生成程式碼」與「商標權」兩個爭議點，正式宣告分裂。

對台灣開發者來說，這個故事值得細讀——不是因為它有多狗血，而是因為它觸及了一個開源社群正在集體面對的靈魂拷問：用 Claude Code 寫程式碼然後不告訴團隊，到底算不算背叛？

什麼是 MeshCore？一個低成本的 mesh 網路方案

在深入分裂事件之前，有必要先了解 MeshCore 到底是什麼。

MeshCore 是一個開源的 mesh 網路通訊技術，讓裝置之間可以不透過中央伺服器直接通訊。想像一下，你的手機可以直接連結到另一個人的手機，然後一路串聯下去，形成一張不依賴電信公司的通訊網路。在偏鄉地區、災難應變、大型活動現場等場景中，這種技術的價值不言而喻。

這項技術最吸引人的地方在於它的低成本。MeshCore 支援超過 75 款硬體型號，包括常見的 ESP32 微控制器、LoRa 模組等低成本開發板。開發者可以用不到幾百元的硬體成本，就搭建出自己的 mesh 網路節點。這也解釋了為什麼這個僅成立一年多的專案能夠快速成長——它把原本高門檻的 mesh 網路技術變得人人可及。

MeshCore 生態系統包含了多個元件：
– MeshCore Companion 韌體： 核心的 mesh 網路通訊韌體，已在全球部署超過 38,000 個節點
– MeshCore Repeater 韌體： 中繼器韌體，用於延伸網路覆蓋範圍
– MeshCore Room Server 韌體： 室內伺服器韌體，適合固定部署場景
– MeshCore App： 跨平台 App（Android + iOS），已有超過 10 萬活躍用戶
– MeshCore Map： 全球節點地圖，顯示所有公開的 MeshCore 節點位置

從 2025 年 1 月專案啟動開始，核心團隊已經發布了超過 85 個版本的韌體更新。就像他們自己說的一樣：「這一切程式碼都是人類手工打造的（hand crafted, by humans）。」而這句話，後來成為了整個事件的關鍵轉折點。

一場由 Claude Code 引發的內部地震

MeshCore 團隊對 AI 生成程式碼的態度，從一開始就非常明確。

「我們對 AI 生成的程式碼一直保持謹慎，但我們也認為每個人都有自由去實驗自己想要的東西。」核心團隊在部落格中寫道。

然而，團隊成員之一 Andy Kirby 顯然對「實驗」的定義有所不同。

根據核心團隊的公開聲明，Andy Kirby 開始大量使用 Anthropic 的 Claude Code 來生成程式碼，而且「秘密地」接管了 MeshCore 生態系的多項元件開發：獨立裝置韌體、手機 App、網頁燒錄工具（Web Flasher）、網頁設定工具（Web Config）。核心團隊描述這是一個「激進的接管企圖」。

最關鍵的問題不在於他用 AI 寫程式碼——團隊自己也說了「每個人都有自由去實驗」——而在於 他隱瞞了這件事。

「他隱瞞了一個小細節：這些東西大部分都是 vibe coded 出來的，」團隊寫道。

「Vibe coding」這個詞最早由 OpenAI 的 Andrej Karpathy 在 2025 年初提出，指的是讓 AI 主導程式碼生成，開發者只管「跟著感覺走」來調整方向。在 Karpathy 的原始描述中，這是一種完全信任 AI 的開發方式——開發者幾乎不再親自寫程式碼，而是像指揮家一樣引導 AI 完成所有實作。

但 MeshCore 團隊對這種開發方式顯然不買單。他們在 Discord 社群中做過一次關於 AI 與信任度的投票，結果顯示社群對 AI 生成程式碼的態度存在明顯分歧。然而，對核心團隊來說，這個問題的核心從來不是「能不能用 AI」——而是「用了 AI 卻不告訴團隊」。

從技術路線之爭到商標大戰

如果只是 AI 程式碼的爭論，這可能還停留在技術社群的常規辯論範圍內。畢竟，Reddit 上每天都有關於「AI 程式碼品質」的激烈討論。

真正讓事情爆炸的，是商標。

核心團隊表示，Andy Kirby 在 2026 年 3 月 29 日向英國智慧財產局提交了 MeshCore 商標申請，而且「完全沒有告知任何一位團隊成員」。當核心團隊試圖與他溝通時——他們想了解他的意圖是什麼、為什麼不公開討論——對話破裂了。

「這幾個月壓力很大，」核心團隊在部落格中寫道，語氣中充滿了疲憊與失望。「一個內部成員夥同機器人與律師聯手，對我們這些努力付出的團隊來說，是一記當頭棒喝（slap in the face）。」

更令團隊不滿的是，Andy Kirby 開始大量使用「Official」這個詞來推廣他的 MeshOS 產品線，暗示他的版本才是「官方 MeshCore」。核心團隊對此提出強烈反駁：

「真正的『官方 MeshCore』是 GitHub 上的原始碼倉庫。那是 MeshCore 的根本來源——而 Andy 從未對那個倉庫做出過任何貢獻。」

這是一個令人玩味的場面：一個從未貢獻過原始碼核心的人，現在卻聲稱擁有這個專案的品牌所有權。

分裂之後，核心團隊被迫推出了 meshcore.io 網站，因為 Andy Kirby 控制了原本的 meshcore.co.uk 網域和原始的 Discord 伺服器。團隊表示他們「幾乎別無選擇」。更令人沮喪的是，在上線 meshcore.io 之後，Andy Kirby 又用 Claude 複製了新網站的視覺風格來製作自己的網站——即使團隊已經明確要求他不要這樣做。

開源商標戰：這不是第一起，也不會是最後一起

MeshCore 的商標爭議在開源世界中其實並不罕見。回顧歷史，類似的事件層出不窮：

這些案例的共同教訓是：開源專案一旦成長到一定規模，品牌和商標就會成為比程式碼本身更具爭議性的資產。 程式碼可以被 Fork，但品牌和社群認同很難被複製。

MeshCore 的案例特別之處在於，它是一個成立僅一年多的年輕專案，商標爭議在成長初期就爆發了。這對其他剛起步的開源專案來說，是一個很及時的警訊。

AI 生成程式碼的信任危機

MeshCore 事件觸及的不只是 MeshCore 一個專案的問題，而是整個開源生態系統正在面對的結構性挑戰。

過去一年半，AI 輔助程式開發工具已經徹底改變了軟體開發的方式。從 GitHub Copilot 到 Claude Code 再到 Cursor，越來越多的開發者將 AI 整合到日常工作流程中。根據 GitHub 的統計，財星 500 強企業中有超過 85% 的團隊每週使用 Copilot 或其他 AI 編碼工具，涵蓋的部門從軟體工程到財務、行銷。

但在開源社群中，「AI 寫的程式碼該不該被信任」從來沒有取得共識。這個問題可以從幾個層面來看：

可審查性問題

傳統的程式碼審查（Code Review）建立在一個基本假設上：每一行程式碼都有人類作者，審查者可以透過提交紀錄（git blame）來理解程式碼的來龍去脈，找到原始作者進行討論。

但 AI 生成的程式碼打破了這個假設。當一個 PR 中的大部分程式碼都是由 AI 生成時，審查者很難判斷特定的實作選擇是出於深思熟慮的設計，還是模型隨機生成的結果。如果某段程式碼有 bug，你能找誰問？寫 prompt 的人可能根本不知道 AI 為什麼那樣寫。

授權合規風險

這是最容易被忽視但實際上最棘手的問題。

AI 模型的訓練資料中，包含了大量的開源程式碼——從 GPL、MIT 到 Apache 2.0 等各種授權條款的專案。當 AI 生成一段程式碼時，它可能無意中「複製」了訓練資料中受特定授權保護的程式碼模式。

2025 年初，已經有幾起關於 AI 生成程式碼涉及授權爭議的案例。雖然目前還沒有明確的法律判例來界定 AI 生成程式碼的授權責任歸屬，但對於重視授權合規的開源專案來說，這是一個無法迴避的風險。

責任歸屬

如果 AI 生成的程式碼包含安全漏洞，誰該負責？

在傳統開發模式中，這個問題相對清楚：寫那行程式碼的開發者（以及沒審查出來的 reviewer）需要負責。但在 AI 模式下，寫 prompt 的人可能完全不知道 AI 生成的程式碼有什麼潛在的安全問題。

這不是理論問題——研究已經證明，AI 模型在生成安全相關的程式碼時表現不穩定。2024 年史丹佛大學的一項研究發現，主流 AI 編碼工具生成的程式碼中，約有 40% 存在安全漏洞。雖然這個數字隨著模型進步在下降，但風險仍然存在。

專案治理與團隊信任

MeshCore 事件最核心的教訓，其實是關於團隊信任。

當團隊成員開始用 AI 大規模生成程式碼，而其他成員仍然堅持手工編寫，兩者之間的認知差距就會逐漸擴大。手工編寫的成員可能覺得 AI 寫的程式碼品質不可控，而用 AI 的成員可能覺得手工編寫效率太低。如果沒有公開透明的溝通機制，這種裂痕最終會演變成 MeshCore 今天的局面。

從 MeshCore 事件學到的教訓

對台灣的開發者和開源參與者來說，MeshCore 事件提供了幾個值得思考的方向。

如果在團隊中使用 AI 編碼工具

如果你正在帶領一個開發團隊使用 AI 編碼工具，以下幾個問題值得先討論清楚：

  1. 透明度第一： 團隊中是否應該有明確的規範，要求成員在使用 AI 生成大量程式碼時註明來源？
  2. 程式碼審查加嚴： AI 生成的程式碼是否需要更嚴格的審查標準？特別是安全性方面。
  3. 授權合規檢查： 專案是否應該加入自動化工具來檢測 AI 生成程式碼的授權風險？
  4. AI 使用邊界： 哪些部分可以用 AI 生成（如測試程式碼、工具腳本），哪些部分應該保持人工編寫（如核心邏輯、安全關鍵程式碼）？

這些問題沒有標準答案，但 MeshCore 的教訓告訴我們：與其等到問題爆發，不如及早建立團隊共識。

如果維護開源專案

對開源專案的維護者來說，MeshCore 事件也提供了幾個具體的建議：

開源社群的世代交替

MeshCore 事件背後，其實反映了開源社群正在經歷的一場深刻的世代交替。

傳統的開源開發模式強調「人類親手編寫每一行程式碼」，這是從自由軟體運動時代以來的核心信念。Richard Stallman 曾說過，程式碼的「自由」不僅體現在使用權利上，更體現在開發者之間的透明協作關係中。

但在 AI 時代，這個信念正在被挑戰。

新一代的開發者——那些在大學時期就開始使用 Copilot 的工程師——對「AI 寫程式碼」的接受度遠高於老一輩。對他們來說，AI 只是另一種工具，就像從組合語言進步到高階語言一樣自然。你沒有必要向團隊報告你用了 Python 而不是 C 來寫某個功能，同樣地，為什麼要報告你用了 AI？

這個視角的差異，正是 MeshCore 事件的核心矛盾。

好消息是，開源社群已經開始正視這個問題。Linux 基金會正在討論 AI 生成程式碼的貢獻指南，GitHub 更新了其開源政策來涵蓋 AI 輔助開發，一些大型開源專案（如 Kubernetes）也開始制定自己的 AI 貢獻規範。

MeshCore 的分裂雖然令人遺憾，但從另一個角度來看，它提供了一個真實的案例研究——讓更多的開源專案可以及早建立自己的 AI 治理機制，而不是等到問題爆發才來後悔。

畢竟，開源的本質從來不是「不用什麼工具」，而是「透明地協作」。如果團隊成員之間無法坦誠溝通，無論用不用 AI，遲早都會出問題。MeshCore 的故事提醒我們：工具可以換，技術可以變，但信任——一旦失去，就很難重建了。

有趣的是，MeshCore 的競爭優勢——mesh 網路技術的低成本、去中心化特性——也諷刺地映射了它現在的分裂狀態：一個去中心化的技術，最後因為中心化的商標歸屬問題而分裂。技術可以去中心化，但人與人之間的信任，永遠是最中心的命題。