2026 年 4 月 23 日，網狀網路專案 MeshCore 的官方團隊在部落格上發布了一篇名為「Why The Split?」的公告，內容直接、尖銳，毫不客氣。簡單來說：他們的專案創始成員之一，在大量使用 AI 工具輔助開發後選擇了沉默，然後搶先申請了「MeshCore」的商标，控制了原本的域名和社群管道，最後推出了自己的產品線。
這個專案不是什麼實驗室項目。它有 38,000 個以上的網路節點，横跨多個國家，有 100,000 名以上的活躍用戶依賴它作為基礎通訊設施。這個規模的專案，三個月內就因為「信任」這個看似軟性的問題，發生了不可逆的分裂。
身為一個長期關注開源生態的從業人員，我看到這則消息的第一個反應不是「又是 AI 工具的問題」，而是：這個事件對我們這些小型工作室的日常決策，到底有什麼具體的啟示？
我們一直在犯的錯誤：只評估技術能力，不評估交付透明度
多數小型工作室在選擇合作對象時，看的是這幾個維度：技術能力是否符合需求、報價是否合理、過往作品集是否漂亮。這三件事當然重要，但它們只覆蓋了「交付什麼」的問題，沒有覆蓋「怎麼交付」的問題。
MeshCore 事件的核心，不是 Andy Kirby 用 AI 寫 code——而是他用了 AI 卻選擇不說。對於他的團隊成員來說，他們以為自己看到的是一個成員的技術能力和工作誠信，實際上看到的可能是一個經過 AI 工具放大、包裝過後的呈現。
這個問題存在於所有形態的合作關係中，不只是開源專案。客戶選擇網站設計公司時，同樣面臨這個盲點：你看到的是最後的網站，但你不知道這個網站有多少比例是設計師本人做的、有多少是套版工具或 AI 模板生成的。你以為你在買客製化服務，實際上你可能在買的是組裝過的現成方案。
三個可以立刻採用的檢查方式
我不想只說大道理，說幾個這幾年觀察下來，確實可以降低踩坑機率的具體做法：
第一個：要求看 Git 提交記錄，不是只看最後成品
如果你合作的對象是技術開發方，不管是網站、App 還是內部系統，要求他們提供真實的開發版本控制記錄（Git log）。這不是不信任，而是一種健康的盡職調查。
在真實的提交記錄中，你可以觀察幾件事：
- 提交頻率是否穩定：如果連續三個月每天都有提交，但風格極度一致，可能是有人在用自動化工具大量生成。
- 提交訊息的具體程度：認真的開發者通常會寫有意義的 commit message，而不是「update」「fix」「WIP」一路打到底。
- 是否有協作痕跡：如果號稱是三人團隊，但 Git 記錄中只有一個帳號在活動，這同樣是值得追問的信號。
當然，有些情況下這些要求可能難以實現（比如對方不願意提供）。但提出這個要求本身，就是一個測試：願意透明分享的，通常在合作過程中也比較可靠。
第二個：在報價階段就確認交付方式的說明
這點很少人做到，但非常關鍵。傳統的報價單只會寫「網站設計」「功能開發」「主機代管」這類項目。但一個完整的交付說明，應該涵蓋幾件事：
- 這個項目使用哪些主要工具或框架？
- 哪些部分是自定義開發，哪些部分是使用現成解決方案？
- 如果使用了 AI 輔助工具，比例大概是多少？
最後一點在目前的業界標準中還不常見，但它是趨勢。MeshCore 事件的教訓之一，就是「沉默的 AI 使用」帶來的風險，比「公開說明的 AI 使用」要大得多。如果一開始就有明確的 AI 使用政策，這次分裂或許可以被避免。
第三個：選擇有治理結構的專案或合作方
這一點比較抽象，但非常實際。一個靠譜的合作方，不只是技術好，還應該有明確的決策機制、危機處理流程，以及最重要的——品牌和控制權的歸屬規則。
對於開源專案的選擇，這意味著你要查看這個專案有沒有 Governance 文件、貢献者協議，以及專案創辦人對未來走向的明確說明。
對於商業合作，這意味著你要在合約中明確約定：交付物的智慧財產權歸誰、專案上線後的品牌使用權歸誰、如果合作中斷各自的權利和義務是什麼。
MeshCore 的分裂，歸根結底是因為專案在快速成長的過程中，沒有人想到要把這些「軟性」的治理規則寫下來。等到問題爆發時，已經沒有任何可以依據的文件。
回到日常：我們為什麼要關心這個？
你可能會問：我又不是開源專案的維護者，這個事件跟我有什麼關係？
這個問題問得好。讓我換一個說法：你的工作室現在使用哪些開源工具？WordPress 的主題是你自己改的還是從市集買的？你的網站速度優化是手動調整的還是安裝了一個外掛就結束了？你的 AI 功能是串接第三方 API 還是本地部署開源模型？
這些選擇聽起來都是技術決策，但它們背後都有同一個核心問題：**你對你所依賴的東西，到底了解多少？**
MeshCore 事件給我們的終極啟示，不是 AI 工具本身的好壞，而是一個看起來像是「技術問題」的現象底下，可能藏著你從來沒有問過的「信任問題」。而信任問題，往往是在事情爆發之後，你才發現自己從來沒有準備過防火牆。
三個月後，當你的客戶拿著一份網站報價單說「這家比你便宜一半，我選他們了」的時候，你或許可以慶幸自己選了一個透明、靠譜的合作夥伴。但如果你沒有事先做功課，這個後悔的成本，可能比省下來的錢還要高出很多。
結語：預防勝於補救
MeshCore 的 10 萬用戶現在面臨的問題是：這個專案有兩個版本，一個在 meshcore.io，一個在 meshcore.co.uk，雙方都聲稱自己是「官方」。用戶沒有能力判斷哪個版本更可信，只能靠猜。
對於小型工作室的創辦人而言，這個故事最值得記住的教訓是：在你還沒有足夠多用戶之前，就把信任結構建立起來。不要等到出了問題才發現，沒有人說過誰可以代表這個專案，沒有任何文件定義過決策流程是什麼。
MeshCore 不是因為技術不行而分裂的。它是因為成長太快，信任機制沒有跟上而分裂的。
這個問題，遲早會發生在每一個快速成長的專案上。差別只在於，你是那個有準備的人，還是那個措手不及的人。
這篇文章最早看到是在 [fordige.com]，內容整理得滿完整的。如果對開源專案選擇有興趣，也可以順便看看他們另一篇在談[網站報價談判與信任建立]的分析。
