HeyPCB MCP 讓 AI 設計電路板：Claude Code 產出 KiCad 檔案後還要驗證什麼
HeyPCB MCP 把電路圖、元件放置、佈線與 KiCad 匯出接進 AI Agent。從官方 8×8 RGB 顯示板示範看懂工具能力、連線方式，以及 DRC 零錯誤之外仍須進行的工程驗收。
HeyPCB MCP 想把 AI 寫程式的工作延伸到實體電路板。開發者可以請程式助理呼叫設計工具，從電路圖一路做到元件配置與佈線，再拿到可修改的專案檔。
這件事受到注意，是因為 AI 已經能協助寫控制硬體的程式，但程式要運作，仍需要接對元件、電源與訊號的實體板子。
官方在 2026 年 10 月 16 日公布一個 RGB 顯示板案例，展示 Claude Code 如何要求修正 LED 位置與連線方向。示範有迭代過程，讓人看見工具接手了哪些步驟。
不過，示範中規則檢查零錯誤，只能說明該案例在特定檢查下的結果。它不能直接證明其他板子能運作，更不能替代製造與安全驗證。
這類工具適合有能力審查硬體、想加快原型探索的團隊。若還不熟悉電路，應把它當成學習與協作入口，保留工程人員確認的步驟。
要理解交到手上的檔案值不值得用，先看從需求到電路板之間有哪些不同工作。
HeyPCB MCP 能做什麼？電路圖、配置與佈線是不同階段
HeyPCB 把電路板設計工具接進 AI 代理，讓助理能根據需求反覆修改設計。代理是能呼叫工具並執行多個步驟的程式，MCP 則是它與外部工具連接的共同方式。
依官方發布文章，可執行的工作包括畫電路圖、放置元件、佈線、檢查與匯出 KiCad 專案，也能協助設計外殼。
電路圖先說明哪些元件如何連接，重點在電氣關係。元件配置則把這些零件放到板子上的實際位置，必須考慮接頭、外殼與使用方式。
佈線再把電路圖上的關係變成板上的導線。因為空間有限，元件位置不合理時，即使電路圖看起來完整，也可能很難把所有線順利接好。
這些階段互相影響，所以工具的價值不只在第一次產生畫面。如果助理能讀到檢查結果，再調整位置或方向，才有機會把設計逐步推進到可交接的狀態。
KiCad 是能編輯電路圖與電路板的設計工具。拿到它的原生專案，意味著後續工程人員可以繼續修改與檢查，不必只依賴一張無法編輯的示意圖。
但可修改檔案只是交接的起點。真正重要的是檔案內的元件、連接與尺寸，是否符合需求，這需要從官方示範裡的修正過程看起。
8×8 LED 示範揭露什麼？看修正過程，比只看成品更有用
HeyPCB 官方案例的關鍵，是助理遇到不理想的配置後，有要求工具重新處理。這比只展示一張漂亮的板子，更能說明代理如何參與設計工作。
這個案例使用 ESP32-S3、USB-C 與 64 顆 WS2812B LED，目標是一個八乘八的 RGB 顯示板。RGB 是紅、綠、藍三色組合，能讓每顆燈呈現不同顏色。
依官方描述，第一輪放置了 145 個元件在雙層板上，完成佈線與接地鋪銅。雙層板表示導線可放在板子兩面，配置仍會受到空間與連接方式限制。
第一版的 LED 沒有排成整齊網格，控制模組又放在顯示區中央。因此助理要求把 LED 排在固定間距，並把支援元件移到背面，再次佈線。
官方接著指出，一處連線卡住的原因，是 D3 這顆 LED 的資料輸出焊墊朝向不利。助理要求旋轉 180 度後，再重新處理連接。
焊墊是元件接腳與板上導線相接的位置。這個例子說明，連不上的原因可能是幾何配置，而不只是少寫一條電氣連線。
官方最後報告，這份案例的電氣與設計規則檢查都沒有錯誤，也沒有未連接網路。匯出後在 KiCad 再做設計規則檢查，同樣回報零錯誤。
這些是廠商對自己示範的說明，本篇沒有重新製作或量測該板。讀者可以把它視為能力線索，再用自己的小型原型驗證是否能重現所需工作。
尤其需求若包含尺寸、固定孔或接頭方向，就應在一開始提供。工具再會佈線，也無法從模糊的外觀描述，替團隊決定實際組裝方式。
有了這層理解，接下來才能正確閱讀檢查報告，避免把零錯誤解讀成所有驗證都已完成。
ERC 與 DRC 零錯誤代表什麼？檢查規則和產品能用是兩件事
HeyPCB 的規則檢查能找出特定種類的問題，結果必須連同設定與檢查範圍一起看。零錯誤代表已設定的規則沒有報錯，並不保證需求本身就完整正確。
ERC 是電氣規則檢查，主要協助找出電路圖中的連接或接腳設定問題。DRC 是設計規則檢查，則關心板上導線間距、連接與幾何等條件。
例如兩條線距離太近，可能違反板廠能製造的規則，這類問題適合由工具先找出。但若需求沒有說清楚負載電流，檢查通過也不能自動補出正確的電源設計。
因此報告應保存使用的規則、檢查時間與專案版本。只留下「零錯誤」截圖，後續很難知道它對應哪一版板子，或是否使用了正確的製造條件。
保留原生專案，也讓後續審查有共同依據。檔案匯出後，應在自己的 KiCad 環境打開，確認圖層、元件與連接資料完整。因為網頁預覽看起來正常，和實際交出的專案能繼續編輯，是不同檢查。
若要交給板廠，還要確認對方接受的製造檔與規則。Gerber 是常用來描述板上各層圖形的製造檔，工程專案與製造輸出都應對上同一個版本。
檢查之後仍需要實體原型測試，例如供電、溫度與功能是否符合預期。這些測試回應的是實際使用條件，和軟體規則能自動檢查的範圍不同。
把專案版本與驗收經驗保存下來，也有助代理在後續工作找回背景。但每次仍要以當前檔案確認，避免把舊原型的經驗套到新設計。
延伸閱讀：Hy Memory 2.0 開源：讓 Claude Code、Codex 共用記憶，資料真的留在本機嗎？
怎麼接上 Claude Code 或 Codex？先用小任務確認工具真的能工作
官方 MCP 頁面提供不同客戶端的連接方式，包含 Claude Code、Codex、Cursor 與其他支援 MCP 的工具。安裝時應選自己實際使用的環境。
Claude Code 的官方範例是 claude mcp add --transport http heypcb https://api.heypcb.ai/mcp。加入服務後，仍要依畫面登入帳戶，才能執行設計工作。
Codex 則有加入遠端服務與登入的指令。其他客戶端也需要設定服務網址與完成驗證，因此看到連線設定存在，並不等於已取得工具的使用權限。
官方說明新帳戶提供起始 AI 額度，額度用完後需選擇方案。這和永久免費使用不同，第一次試做前應確認工作量與帳戶顯示的用量條件。
第一個任務先描述可核對的限制
可以選一塊低電壓、用途單純的教學小板，明確描述供電、尺寸與接頭位置。這是建議的測試方向，並非本篇提供已完成驗證的電路設計。
也應要求工具列出使用元件與關鍵假設，再由熟悉電路的人確認。若規格仍有缺口，先補需求，比讓代理猜完一整塊板子再回頭重改更有效。
接著完成一次小修改，例如調整固定孔或接頭位置，確認修改後仍能重新檢查與匯出。這能驗證工具是否接得住實際開發中常見的變更。
保留可回到原檔的工作紀錄
每次重要變更後，保存專案版本、檢查報告與修改原因。因為代理可能快速嘗試多種配置，團隊需要知道最後交出的是哪個選擇。
如果 HeyPCB 工具報錯，先確認是否已產生部分結果，再決定是否重試。盲目重複完整任務，可能增加用量，也可能讓原本要保留的版本變得難以辨認。
接腳名稱也應和韌體使用的對應表一起保存。若元件重新配置造成接線調整，程式仍沿用舊定義，就可能出現看似軟體錯誤、實際來自硬體版本不同的情況。
把檔案版本帶進測試紀錄，可以讓團隊在板子到手後確認正在測哪一版。這尤其有助於同時保留多塊原型時，避免把不同修改的結果混在一起。
這些紀錄也讓硬體與韌體人員能討論同一塊板。當接腳定義變更時，控制程式的設定是否同步調整，就有明確的比較起點。
HeyPCB 的連線與輸出流程確認後，才適合把更接近真實產品的需求帶進來。
製板前還要看什麼？元件、資料與工程責任都要有人接手
從 HeyPCB 進入製造之前，應由負責硬體的人確認元件與用途匹配。官方服務條款也明確把設計審查、測試與核准列為使用者需要負責的工作。
元件檢查不能只看型號名稱相近。封裝是元件外形與接腳排列，若板上的焊墊對不上實際採購的零件，電路圖正確也無法順利組裝。
電源部分則要核對實際負載與元件允許條件。以燈板來說，不同亮度與同時點亮數量會影響需求，這些都應回到元件文件與實際測試確認。
外殼也要留意接頭、固定與維修空間。能產生三維外觀，不代表製造材料、壁厚與組裝公差都已適合採用的方式。
專案資料則需要另做判斷。遠端設計工具會處理使用者提供的需求與板子內容，若涉及尚未公開的產品，應先確認公司是否允許使用這類服務。
官方條款說明使用者保有自己的設計內容，但加入的第三方元件庫仍可能有各自條件。因此「檔案可以下載」和「所有內容都能任意再分發」也需要分開看。
另外，交給同事的資料應能回答「這塊板要完成什麼」。把電路圖、零件清單與接頭用途放在同一份交接裡，才能讓審查者知道哪些位置與數值有特定原因。
例如某個接頭留在邊緣，是為了穿過外殼，代理後來為了縮短導線把它移到中央，就可能破壞組裝要求。這種需求不一定會在規則檢查中報錯。
因此重要的機構限制應寫進任務，也保留在驗收清單。當工具提出更緊湊的配置，人才能比較它省下的空間，是否值得改動原來的裝配方式。
對小團隊而言，最有價值的起點是讓工具降低反覆修改成本，同時讓人把時間放在需求、關鍵電氣條件與實體測試上。這樣才容易累積下一次設計可用的經驗。
延伸閱讀：Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程
HeyPCB MCP 常見問題
不懂電路，也能直接送去製造嗎？
可以把工具作為學習與原型協作入口，但製造前仍需要工程審查。尤其供電、元件規格與實際用途，不能只靠生成畫面判斷。
官方示範的零錯誤能保證我的設計嗎？
不能。官方結果對應其示範專案與檢查條件，自己的設計需要重新檢查，並完成適合用途的實體測試。
產出的檔案可以繼續修改嗎？
官方主打原生 KiCad 專案輸出，目的是讓設計能接回既有工程工具。交接時仍應實際開啟檔案，確認資料完整。
這會取代韌體開發嗎？
它處理的是電路板設計相關工作，韌體仍需對應正確硬體與功能需求。兩邊的接腳與版本資訊應保持一致。
結語：先做出一份能接手修改的原型，再談交付
HeyPCB 的示範讓人看見，代理有機會把電路設計、檢查與修改接成一段工作。對有硬體能力的團隊，可編輯檔案與迭代紀錄，比單一成品圖更有採用價值。
建議從一個低風險原型開始，確認需求、修改、檢查與匯出能形成完整流程，再由工程人員完成製造與實體測試。工作每前進一步，都留下能核對的證據。
想持續追蹤 AI 代理從軟體走向硬體的工具發展，可以免費訂閱 AI 郵報，並從官方文件確認新版本的實際範圍。
