事件背景：38,000 節點、10 萬用戶的網狀網路專案正式分裂

2026 年 4 月 23 日，MeshCore 官方部落格發布了一篇名為「Why The Split?」的公告，揭露這個擁有超過 38,000 個節點、10 萬名活躍用戶的網狀網路（mesh network）專案，因為核心成員的爭議行為而正式分裂。

這起事件的規模並非單純的團隊內部衝突。MeshCore 自 2025 年 1 月成立以來，在一年多時間內支援超過 75 種硬體變體，並建立跨國節點網路。對於一個開源基礎設施專案而言，這樣的成長速度與用戶規模並不常見。

而真正引發關注的，是分裂的原因：一位創始成員大量使用 AI 工具輔助開發，卻未對團隊說明，甚至搶先申請商標並掌控官方資源。

三個核心爭議：AI、代碼、品牌

從技術與治理角度來看，這次事件主要圍繞三條主線展開。

1. AI 使用的隱瞞

根據公告，涉事成員大量使用 AI 工具（如 Claude Code）進行開發，但未向團隊披露。問題的核心並非「使用 AI」本身，而是資訊不對稱。

當部分成員認為程式碼來自人工開發，而實際上卻有大量 AI 生成內容時，團隊對於程式碼品質、可維護性與風險的評估會出現根本性偏差。

2. 商標與控制權爭奪

該成員在 2026 年 3 月 29 日單方面申請了「MeshCore」商標，並掌握原有的官方域名與社群渠道。分裂後，另一方團隊被迫重新建立網站與對外溝通管道。

在基礎設施型專案中，品牌與官方渠道的控制權幾乎等同於用戶信任的控制權。誰掌握這些資源，誰就更容易被視為「正統」。

3. AI 輔助的設計複製

更具諷刺意味的是，公告指出其中一方在分裂後使用 AI 工具複製另一方網站的設計與風格。這使得整起事件呈現出一種矛盾：一方面質疑 AI 生成內容，另一方面又依賴 AI 進行快速複製。

開源治理的結構性問題

這起事件之所以引發討論，不只是因為個別行為，而是它放大了開源治理中的長期問題。

貢獻來源難以追溯

傳統上，Git 提交紀錄可以追蹤程式碼作者。但在 AI 介入後，程式碼來源變得模糊：相同的輸出可能來自人工或 AI，且難以從結果判斷。

治理機制缺失

許多中小型開源專案缺乏正式的治理文件與爭議處理流程。當衝突發生時，沒有仲裁機制，也缺乏對商標、域名等資產的明確規範。

相比之下，成熟專案通常具備清晰的治理架構，但快速成長的專案往往忽略這一點。

AI 時代下的 CLA 挑戰

傳統的貢獻者授權協議（CLA）並未考慮 AI 生成內容，帶來幾個新問題：

• 智慧財產權歸屬：AI 生成的程式碼屬於誰？
• 來源證明困難：無法區分人工與 AI 產出
• 是否需要披露：目前多數專案沒有要求說明 AI 使用情況

這些問題在過去並不明顯，但隨著 AI 能力提升，已成為不可忽視的議題。

對開發者的實務啟示

對於正在評估或使用開源專案的開發者，可以從這次事件中得到幾點提醒：

1. 觀察貢獻模式

AI 生成的程式碼往往在提交頻率、風格與結構上呈現高度一致性。異常穩定的輸出，可能值得進一步關注。

2. 確認治理文件

至少應包含：

• 決策機制
• 商標與品牌歸屬
• 緊急情況下的控制權轉移規則

3. 理解所有權風險

開源並不代表沒有控制權風險。授權條款解決的是程式碼使用問題，而非品牌與專案主導權。

總結

這起事件的核心並不只是 AI，而是透明度與信任的失衡。

使用 AI 工具本身並非問題，但當資訊未被充分揭露，並與資源控制行為（如商標申請）結合時，就可能導致整個專案生態的分裂。

在 AI 工具快速普及的背景下，開源專案不僅需要技術能力，也需要更成熟的治理結構與信任機制。

這篇文章最早看到是在 fordige.com，內容整理得滿完整的。如果對開源專案選擇有興趣，也可以順便看看他們另一篇在談網站報價談判與信任建立的分析。