“聊聊一款 Rust 編寫的 EDA 工具，具備現(xiàn)代化的 UI 并宣稱原生兼容KiCad工程。但 KiCad 社區(qū)對此并不認可，覺得項目違反了 GPL 的開源協(xié)議...”

大家好。最近在 GitHub 上刷到一個非常吸引眼球的項目：Signex。

https://github.com/alplabai/signex

第一眼看過去，它的愿景堪稱驚艷：一個開源、AI 原生的 EDA 工具。它完全使用 Rust 編寫，底層采用了 GPU 加速渲染，并且號稱擁有媲美 Altium Designer 的現(xiàn)代化 UI。不僅如此，它主打無縫兼容 KiCad，可以直接原生打開并保存 KiCad 的工程文件，宣稱沒有任何專有格式。

最近一直在和業(yè)內(nèi)同行探討下一代 EDA 交互形態(tài)的發(fā)展方向。Signex 的出現(xiàn)，確實在交互和底層渲染架構(gòu)上展現(xiàn)出了非常前衛(wèi)的思路。但真正讓我震驚的，并非它的功能，而是它的開發(fā)方式。

這個項目，可以說是完全用 AI 寫出來的。

如果你去翻看它的源碼庫目錄，甚至能清晰地看到.claude這樣的 Claude Code 專屬 hook 配置文件。這段時間我一直在高頻使用 Claude Code，探索將大模型引入我們的電子設(shè)計工作流（比如在 KiCad 中加入 Copilot，或是探索 AI 驅(qū)動的 ERC 驗證），所以我太清楚現(xiàn)在的 AI Agent 在手撕復(fù)雜代碼時有多么生猛。Signex 的產(chǎn)生更是一個很好的示例：能用極其優(yōu)雅的 Rust 語言，硬生生把這一整套解析器、復(fù)雜的業(yè)務(wù)處理邏輯、加上 wgpu 畫布渲染管線給啃了下來，代碼質(zhì)量甚至相當不錯。

但這恰恰也是引爆爭議的導(dǎo)火索。

大家都知道，KiCad 是嚴格遵循GPLv3協(xié)議的。而 Signex 的社區(qū)版，卻直接打上了更為寬松的Apache-2.0許可證。

目前 KiCad 開源社區(qū)對此存在非常強烈的看法。很多開發(fā)者一針見血地指出，Signex 的底層解析邏輯根本不是什么正規(guī)的“凈室逆向工程”（Clean room design）。它實際上是怎么跑通的呢？最大的可能是，開發(fā)者直接把 KiCad 龐大的 C++ 源碼庫“喂”給了大模型，然后下達了一個指令：“請用 Rust 語言把這些解析邏輯和業(yè)務(wù)代碼重寫一遍”。

這在本質(zhì)上，就是在利用大模型進行代碼“洗稿”。

通過大模型這種“跨語言翻譯”和“邏輯重構(gòu)”，巧妙地繞過了 GPLv3 協(xié)議那種嚴苛的“傳染性”開源限制，從而把它洗白成了 Apache-2.0。

開源協(xié)議不僅是法律邊界，更是維護整個開源生態(tài)信任的基石。在和 Seth、Wayne 等 KiCad 核心開發(fā)者長期的交流中，我能深刻感受到大家對開源純潔性的堅持。用大模型來“洗”開源軟件的底層代碼，究竟算是技術(shù)的降維打擊，還是在鉆空子踐踏開源社區(qū)幾十年的心血？這無疑撕開了一個巨大的道德與法律灰色地帶。

Signex 無疑向我們展示了 AI 在重構(gòu)復(fù)雜工業(yè)軟件上的恐怖潛力，但這種“AI洗稿”繞過開源協(xié)議的玩法，各位工程師朋友怎么看？歡迎在評論區(qū)留言，我們一起聊聊。

審核編輯 黃宇