序：這四個月的開發歷程，以及為什麼現在才開源
這是整個系列的序——我在決定停止打磨、把東西開源出來的那一刻，回頭替整個系列寫下的開場。四個月前，我開始嘗試「只用開源工具，把一條 AI 原生的 IC 設計流程跑到端到端」。這篇要說的是：它是怎麼開始的、沿路壞在哪裡、為什麼偏偏挑現在開源，以及——最重要的那一段——我還必須誠實承認、尚未被驗證的兩件事。
為什麼要寫一篇序，又為什麼是現在
這個系列裡的其他每一篇，都是為了解釋流程裡的某一塊而寫的。這一篇不是。這一篇是「序」——放在整個系列最前面的開場白——而我是在決定停手、把手上的東西開源的同一個小時裡，把它寫下來的。
最近這兩個月，我心裡幾乎每天給自己的誠實評語，都是同樣三個字：還不夠好。永遠還有一個粗糙的邊角可以再磨、還有一個角落我還沒做硬、還有一件我告訴自己「應該在給別人看之前先修掉」的事。這個直覺本身沒有錯——但推到極致，它就會變成一種「永遠不上線」的方法。所以這篇序，是我刻意放下那份完美主義。不是因為東西做完了，而是因為我認定：「藏著不給人看、直到完美為止」，是比「現在就打開、讓它在公開之下變得更好」更嚴重的錯。
2026 年 3 月：第一次嘗試，以及它有多令人驚訝
故事要從 2026 年 3 月說起。我想弄清楚的事情，講起來很簡單、做起來很難：AI 能不能只靠開源 EDA 工具，就把一整條端到端的 IC 設計流程開下去？不是商用工具鏈——而是開源、學術的那一套，本質上就是一個套件：一個開源 EDA 的 Docker image，那種活在大學實驗室和 OSS repo 裡的工具箱。
第一次把整套開源 EDA 工具箱放到 AI 面前時，我用一個公平的方式把難度拉滿。我拿了一顆已經流片過的晶片——一個真實、完成的設計——而且是從一位朋友完整的原始設計文件開始的。然後我讓 AI 自己把它一路開過開源 EDA，看它能走到哪裡。
結果順得令人驚訝。順到遠超過我原本敢期待的程度。順到我開始懷疑：AI 是不是現在就已經能做全自動、端到端的 IC 設計了——那些零件是不是早就悄悄各就各位了。我甚至半認真地想過：像 Claude 這樣的模型，是不是早就吸收了足夠多這方面的知識，背後的團隊搞不好正打算自己推出一個 IC 設計外掛，直接一步跨過這整個問題。
然後裂縫出現了：「全部通過」——但其實什麼都沒產出
那個第一印象，一碰到細節就撐不住了。當我往更深處走——把流程一步一步拆開、搞清楚每一階段究竟吃進什麼、又必須交出什麼、把每一階段接到真正的開源工具上，而不是那種一路順風的 demo——問題就不斷冒出來，而且冒出來的一直是同一種問題。
AI 會一路跑到底，然後很開心地回報：全部通過——但實際上根本沒有任何產出，或者 AI 只是把工具印出來的東西照單全收、就相信了。一個階段會空著手「成功」。一道關卡會變綠，只因為根本沒有人真的去檢查它背後那個東西。這一個失效模式，幾乎形塑了我之後做的每一件事；也正因如此，這個系列裡有一整篇就是在講這件事：第 9 篇（誠實才是護城河）。一條「什麼都沒產出、卻會告訴你通過了」的自動化流程，比完全沒有自動化還糟——因為它奪走了你當初要自動化去換取的那唯一一樣東西：信任。
那套開發哲學，是從失敗長出來的，不是規劃出來的
那些沒完沒了的小問題，教會我最需要學的一件事：我先前實在太、太樂觀了。於是，就用那些零碎的空檔時間，我用最笨的方法把路一段一段鋪出來。先讓流程能跑起來。再把它做硬——讓它拒絕對自己的產出說謊。再把前端做到位，也就是「人用自然語言描述他想要什麼」的那一段。再來是中段和後端，設計真正被收斂成矽晶片的地方。
有一件事我想講精確，因為把它說成「先見之明」是不誠實的：這套開發哲學，並不是我一開始就有的。我不是三月坐下來時，就懷著一套「先把流程做出來、再把它做硬」的聰明規劃。這個順序是撞到問題之後才浮現的——它是失敗留下的疤痕組織，不是我事先聰明到想得出來的策略。那些做硬的功夫大多集中在後端收斂，而那本身也是獨立的一篇：第 7 篇（後端收斂）。
為什麼是現在開源——以及那個 Kimi 的巧合
最近這一兩個月，我常常覺得它已經可以發佈了。而每一次，我又找到一個新問題，於是又往後推。我一直在「什麼時候開源」這件事上反覆掙扎，一直把它往後拖。老實說，再拖下去，我可能會無限期地拖著。
兩天前，Kimi 發佈了一件事，正好對上了我三月時設定要做的目標：他們展示了「開源工具加上一份開源 PDK，可以走到端到端」。我想講清楚：我認為這是一件好事。當一個領域受到關注，裡面的每個人都受益——更多眼睛、更多工具、更多在乎它到底行不行的人。他們的發佈，正是那個最後推了我一把、讓我不再騎牆觀望的東西。既然我做的東西看起來鑽得更深一些，我意識到我該抓住這個時機把它開源、讓更多人加進來，而不是永遠卡在「還不夠好」裡。
時機這件事，我想正面回應，因為換作是我也會起疑。有人看一眼日曆就會想：在 Kimi 發佈的兩天後開源——這也太巧了吧。誠實的答案是：我其實已經在「快要發佈」的狀態徘徊一兩個月了；Kimi 只是給了我那個「我自己給不了自己」的推力。我大約三週前才開始用 Kimi Code，然後它就發表了一個和我自己方向吻合的東西。這真的是個巧合——而它剛好就是那個「讓現在成為對的時機」的巧合。
另外，我還是要好好謝謝 Kimi。三、四個月前、我剛開始把整條 IC 設計流程長出來的時候，用的其實一直是免費版的 Kimi Chat：我拿 Claude 產出的流程，讓 Kimi Chat 幫我 review、給我意見。所以這條流程，某種意義上是我和 Claude、Kimi Chat、甚至還有 ChatGPT 一起來回討論、慢慢磨出來的，最後才收斂成一套我敢說堪稱業界標準的 IC design flow。那段討論裡我一毛錢都沒付、就用免費版，它就實實在在幫我把流程收斂到今天這個樣子——這份幫忙，我真心感謝。至於 Kimi Code，我是三個禮拜前才開始用，甚至用上了他們的 API key；不過光是跑 benchmark 就燒掉不少 token，整體體驗對我來說，還是沒有 Claude 好。更完整的對照，寫在第 11 篇（實測筆記：LLM 的選擇）。
兩件誠實的坦白——這篇序的核心
接下來是我最需要講清楚的部分，不迴避、不淡化。如果你從整篇序只帶走一件事，請帶走這一段。關於我給你看的一切，有兩件事還沒有被驗證。
一、沒有任何專家看過
沒有任何一個真正有 IC 設計背景的人審過這個東西。一次都沒有。我明明有一堆完全有資格把它拆得體無完膚的朋友——而我一直沒去找他們，理由還是那個最站不住腳的：太不好意思拿給他們看。所以這條流程產出的一切——包括一份我一直願意稱之為「production-ready」的 GDSII——從來沒有被任何一位專業人士看過。到目前為止，「production-ready」這個詞，從來沒有經過任何一位專家的審視。
二、沒有用商用 EDA 交叉比對過
這四個月裡，我從來沒有用過一次商用 EDA。一部分是因為我是外行人，手上沒有任何一套的授權。另一部分是因為，我當初要證明的，正是「光靠開源 EDA 就能把整條流程跑起來」——把商用工具拉進來，等於悄悄地把這個實驗的意義給抵銷掉。Claude 一直提醒我，而且提醒得對：好幾個階段的產出，其實應該拿去和商用 EDA 對標。它是對的。我就是沒有那樣的工具，所以做不到。
所以我必須用一句話講出來，不能閃躲：這裡的東西，沒有一樣拿商用 EDA 交叉比對過，也沒有任何 IC 設計專家審過。這整個系列裡每一個「production-ready」的宣稱，都是一個盡力而為的宣稱——是我用手上有的資源能做到的最好，而不是一個已被驗證的事實。而這，恰恰就是我要開源的原因。好讓專家進來，看見我看不見的東西。好讓有商用 EDA 的人，去比對我沒辦法比對的產出。好讓這個東西在公開之下，被大家一起做得真正更好。關於「開源與商用工具該如何共存、如何互相對標」的立場，寫在第 7 篇（後端收斂）裡。
我很清楚它的極限：先進製程
除了「還沒被驗證」，還有一塊我很清楚的極限，我得講明白。針對商用 EDA，我其實做過一輪相當完整的分析：我讓 Claude 盡量把現在這些開源 EDA 工具在功能面、以及平行化程度上能做到的都補上了——能解的問題，大概都解掉了。剩下的，是比較深、比較硬的工作：像是大幅度的 restructure、或是一些我現在還不知道的 new feature，特別是衝著先進製程來的那些需求。這一塊，有一個很明確的 gap。我解掉的問題、以及所有補上去的新功能，都已經公佈在 EDA 分支（fork）裡，可以直接參考。
還有一點我必須講清楚：這個 plugin 很明確知道自己現在的 limitation。就算它能產出我口中「production-ready」的結果，離真正支援先進製程，絕對還有非常大的距離。一顆複雜的 SoC，複雜度高得驚人——那絕對不是我一個人花四個月做出來的東西撐得住的。但話說回來，AI 當然還在飛速演化；我相信 AI 加上 vibe-ic 的進化會是指數級的，在可見的未來，它應該能做到支援先進製程、並在功能面上追到和商用 EDA 相當的水準。
你可以自己重現
我盡力讓這件事，成為「你不必靠信任來接受」的相反面。這條流程端到端跑過的一切，都開源了；只要能開，我就把每一階段的產出都開著——尤其是那些開放 benchmark 的 IC。（有少數幾個答案，純粹是檔案太大放不進去，那也是唯一的缺口。）
實際的意思是：任何人在自己的 Linux 機器上、配上 Claude，安裝 vibe-ic 這個外掛，都可以重跑一顆 benchmark IC，並且應該能得到和我同一個等級的結果——不會 100% 一模一樣，因為有些步驟是由 AI 完成的，本來就有自然的變異，但會是同一個等級。如果我能達到我宣稱的那個「production-ready」，你應該也能在你自己的檯子上、在本機達到，然後回頭驗證我說的到底成不成立。這才是這種宣稱誠實的樣子：不是「相信我」，而是「你自己跑一遍、自己看」。
一份給業界的邀請，以及一個必須先講的風險
但有一件事我必須先講清楚，而且要講三次——因為它最重要，我把它放在邀請本身的前面：
千萬、千萬、千萬不要在現在這個時間點，直接把 vibe-ic 產生出來的 GDSII 拿去 tape out。
那是非常大的風險——所以我得把這個警告放到最前面。我歡迎的，是你先用這套工具去重現你們過去的 IC，用它來驗證這個工具到底能不能產出跟你們最後真正 tape-out 同等級的東西。我相信中間一定會有一個 gap；而那個 gap，正是我要努力去縮小的方向。
把話說在前頭之後，這就是那份邀請：如果你是 IC 設計業界的人，願意拿 Claude 加上 vibe-ic plugin 跑一遍完整的 end-to-end，我非常歡迎。最好的試法是這樣：如果你手上有已經 tape-out 過的 IC、而且有很完整的設計文件，就把那份設計文件當成唯一的 input，讓這個流程從頭跑到尾。跑的過程裡，拿你們的商用 EDA 去和 vibe-ic 每一個階段的 output 做 cross-check，也請公司裡的 IC 設計專家 review 每一個階段的產出。我相信只有這樣，大家才真正有底氣、有信心，去確認做出來的東西到底能不能拿去 tape out。
還有一整個 AI for EDA 的圈子——我很歡迎
做這件事的路上，我也把「AI for EDA」這個領域好好 survey 了一遍。這個圈子其實已經有一些玩家，我一直有在追蹤他們公開出來的資訊——像 ChipAgent，就給了我很多養分，包括一些 benchmark 資源。另外還有一批 AI for EDA 的新創，大多是這兩年才成立的。
我想說的是：這些公司在做的事，和 Vibe-IC 想做的「開放平台」並不衝突。相反地，我非常歡迎任何這樣的新創，在某個特定領域、某個特定模組上，成為這個生態的參與者——甚至直接拿這套開源去做 enhance。當然，如果能有一些互動、交流的機會，讓這套開源變得更完善，那是最好的，也正是我期待的。
回饋，以及一個 24/7 不打烊的專案
如果你用了、而且願意的話，請給我 feedback——直接聯絡我（Telegram，或 LinkedIn），或者到官網首頁留下你的資料，我都非常歡迎。
這個開源專案會一直做下去，而且是 24/7 都有 AI agent 在盯著大家的 feedback，主動去把問題解決掉——不管是開源 EDA 工具本身的問題，還是 vibe-ic plugin 的問題，都由 agent 主導去修。所以我相信它的進展會複利式地累積：一邊是 AI 自己在變強，一邊是靠各位的貢獻往前推。一個會加速、而且不打烊的專案。
那些教學影片，其實是我學 IC 設計的副產品
還有一件事想順帶講。我陸續放出來的那些教學影片，其實不是我「懂了以後」才回頭錄的教材——它們比較像一個中間產物。真正發生的是：Claude 一步一步教我什麼叫 IC 設計，我一邊問、它一邊解釋每個步驟在做什麼、那一大堆縮寫又是什麼意思，我才慢慢看懂這條流程。影片，就是這段「被 AI 教會」的過程順手記錄下來的樣子。所以如果你在影片裡看到我偶爾的遲疑、或臨時補問一句，那不是演的——那就是一個軟體人，透過跟 AI 對話，第一次把 IC 設計搞懂的真實過程。
一個簡短的收尾——那份邀請
這就是整個故事：一個三月時懷著「配不上的樂觀」開始的實驗，被上百個小失敗磨得謙卑下來，最後長成一條我終於願意打開的流程——即使心裡那個更小聲的聲音，還在說它沒準備好。這篇序，是我選擇「開放」而非「完美」。
如果你願意一起把它變成真的，就從這裡開始。