【2026 最新】AI 畫 PCB 怎麼驗收？GPT‑6 Astra × KiCad 7 道閘門教學

2026 年 9 月 3 日，OpenAI 在 GPT‑6 Astra 發表頁放出一段 KiCad 影片：公開畫面是 15 秒剪輯，標示的完整任務時間為 2 分 54 秒，模型替原理圖放置元件、拉銅線，官方甚至把結果描述成「可製造的 PCB」。但影片證明的是 Astra 能操作專業軟體、抵達一個看似完整的畫面；截至 9 月 6 日查閱的發表頁並未附上料號核對、ERC／DRC、製造或實板 bring-up 報告。這兩件事不能畫上等號。你可以先看官方 KiCad 示範，再回來把「看起來會動」改造成「查得到證據」。

這篇專為第一次把 AI 帶進硬體流程的人寫，並以一塊只吃 5V 的 LED 指示小板作為文件化範例，建立從需求、檔案、netlist、ERC、SPICE、BOM、footprint 到 DRC 的 7 道閘門。本文撰寫環境沒有安裝 kicad-cli、ato 與 ngspice，所以下文提供的是依官方文件校對的可執行流程、預期判定與證據格式，不會把預期輸出冒充 AlphaLab 本機實跑結果。停手點很刻意：只交付可讓另一位工程師審查的原理圖與 evidence packet（證據包），不把它包裝成可直接送廠的製造答案。

先說結論：AI 是生成器，閘門才是驗收者

可審查原理圖＝需求契約＋可重跑原始檔＋機器檢查收據＋人類簽核。這就是全文的定錨句。Astra 可以幫你更快提出候選電路，也可以透過電腦操作碰 KiCad；但同一個模型不能只因為「自己說完成了」，就同時當設計者、測試者與放行者。這個分工正是 AI Agent Harness 的核心：模型負責機率性的探索，確定性的工具負責裁判。

• 原理圖只有連線：還不能說電路能工作。
• ERC 是綠燈：只能說已設定的電氣規則沒有報錯。
• SPICE 通過：只能說選定模型與測試向量內的行為符合規格。
• DRC 通過：只能說板檔符合目前設定的幾何與連線規則；沒有板檔時，結果應寫 N/A，不是假裝通過。
• 要送廠：還要另外處理製造輸出、可製造性審查、實板量測與適用規範。

先把小板寫成可判定的需求

不要先叫 AI「幫我畫一塊 LED PCB」。模糊需求只會得到漂亮但無法判分的答案。先建立 requirements.md，把教學用假設寫死：輸入為 5V ±5%；節點順序是 VIN_5V → R1 → D1 → GND；目標 LED 電流為 3–6mA；教學模型把 LED 順向壓降範圍設為 1.8–2.2V；R1 初始值 620Ω；電阻與 LED 的目標封裝都是 0805／2012 metric。用歐姆定律計算，兩個邊界約為 (4.75−2.2)/620＝4.1mA 與 (5.25−1.8)/620＝5.6mA。

這裡的 LED 壓降是測試輸入，不是所有紅色 LED 的保證值。真正選料時，要以指定料號 datasheet 的曲線、溫度條件與 SPICE 模型替換它。需求也明寫排除市電、電池充電、馬達與安全關鍵用途；輸出不得包含 Gerber、下單或「可量產」判定。邊界越明確，後面的紅綠燈才越有意義。

Astra、atopile、KiCad：三種操作路徑怎麼分工？

截至 2026 年 9 月 6 日，OpenAI 的模型文件列出的 API ID 是 gpt-6-astra，Computer Use 也在支援工具中；發表頁則寫明採分批開放。以下閘門不綁死某個模型：換成別的 Agent，驗收條件完全不變。

• atopile 程式碼路徑：讓模型修改 declarative（宣告式）.ato，依序跑 ato validate main.ato、ato build 與 ato build --frozen。最後一項只證明重建不需要改動 PCB，不代表電氣正確。atopile 官方專案把它定位為電子設計的語言、編譯器與工具鏈；其公開流程會更新 KiCad board，但本文不假設它另有對應的 .kicad_sch。
• KiCad-native 路徑：讓 Astra 透過 Computer Use 編輯真正的 .kicad_sch；每一小段動作後都截圖、保存檔案差異，禁止採購與輸出製造檔。OpenAI 的官方安全指引也要求隔離環境、允許清單、重大動作確認，以及核對真實結果。
• 人工操作：人類直接在 KiCad 編輯。它一樣要交出 netlist、ERC、模擬與 review 收據；「是人畫的」不是免檢理由。

AI 畫 PCB 的 7 道閘門

第 1 關：需求契約——先定義什麼叫完成

痛點：「做一塊會亮的板」沒有可判定的終點。解法是驗收契約：把輸入範圍、節點、元件值、封裝、允許工具、禁止動作與交付物寫進 requirements.md。給 Astra 的 prompt 依序放入 Goal、Inputs、Constraints、Allowed actions、Forbidden actions、Outputs、Stop conditions；最後一句要求它遇到缺少料號或模型時停在 BLOCKED，不得猜一個綠燈。

可觀察結果不是「AI 回答完成」，而是每個需求都有唯一 ID，例如 ELEC-01 對應 3–6mA、PKG-01 對應 0805。後面的每份報告都要引用這些 ID。想把這種做法擴成完整系統，可接著看 如何打造 AI Agent Harness。

第 2 關：執行邊界——固定版本、權限與操作紀錄

痛點：同一段 prompt 在不同工具版本與專案狀態可能產生不同檔案。解法是可重現工作區：執行 kicad-cli version --format about、ato --version 與 git rev-parse HEAD，把輸出存進 evidence/environment.txt。截至本文查證日，KiCad 最新穩定版為 2026 年 8 月 29 日發布的 10.0.6；版本紀錄不是相容性證明，兩條路徑都要先在拋棄式專案完成 build。

把 Agent 限制在專案目錄，只允許編輯 .ato、.kicad_sch 與 evidence 檔；下單、上傳、匯出 Gerber 都需要人類另行授權。若走 GUI，保存每一輪畫面與前後檔案 diff；若走 API，保存 model ID、prompt、tool call、stdout、stderr 與 exit code。這是硬體版的 Agent 可觀測性。

第 3 關：電路圖譜——先驗 net，再看圖

痛點：線條在畫面上碰在一起，不代表它們真的屬於同一個 net。解法是機器可讀圖譜：KiCad-native 路徑用 kicad-cli sch export netlist --format kicadsexpr --output evidence/design.net led-review.kicad_sch 匯出 netlist；atopile 路徑則保存 .ato 連線與 validate／build 報告。兩者都逐條斷言 VIN_5V→R1.1、R1.2→D1.A、D1.K→GND。不要把 ato build 稱作 KiCad ERC。

這一步把 API、檔案與人工操作拆開：模型提出變更，檔案保存真實狀態，netlist 才是連線證據。截圖只能輔助定位，不能當 graph assertion（圖譜斷言）。

第 4 關：ERC——讓接腳與供電錯誤直接擋線

痛點：人眼容易漏掉未接腳、衝突的 power output 或沒有來源的 power input。解法是 ERC：執行 kicad-cli sch erc --format json --severity-all --exit-code-violations --output evidence/erc.json led-review.kicad_sch。依 KiCad 10 CLI 文件，啟用這個參數後，沒有 violation 回傳 0，有 violation 回傳 5；CI 應把非 0 直接標紅。

但 KiCad 的官方入門文件也寫得很清楚：ERC 無法保證原理圖會工作，它只檢查常見連線問題。不要把「語法能編譯」誤寫成「程式符合需求」。

第 5 關：SPICE——把功能要求變成量測

痛點：620Ω 與 62Ω 都可能通過 ERC，只有其中一個落在這份 3–6mA 契約。解法是規格測試：替來源、電阻與 LED 綁定 SPICE 模型，跑 4.75V／5.25V 與 1.8V／2.2V 邊界，保存模型來源、測試向量和量測值。KiCad 的 schematic editor 整合 ngspice；也可先用 kicad-cli sch export netlist --format spice --output evidence/led.cir led-review.kicad_sch 匯出 deck，再用你的固定版 ngspice 批次執行。

EEBench 的公開案例正好示範為什麼「build 成功」仍會失敗：一個 22µF 名目值設計在 4.7V bias 下只剩 11.4µF 有效電容，遠低於任務所需的 545µF，保護電壓 0.85ms 就跌破 3V。這是 benchmark 團隊保存的特定 submission 結果，不是所有電容的通則。EEBench 由 atopile 團隊建立與出資；它的 V1 用確定性 build、電路圖譜、BOM 與 SPICE 檢查模擬內的類比／數位設計，並明確把 layout、製造與 bring-up 排除在 V1 範圍外。

第 6 關：BOM 與 footprint——讓符號回到真實料件

痛點：原理圖符號對了，實體 pad 仍可能選錯尺寸或 pin mapping。解法是雙向核對：用 kicad-cli sch export bom --output evidence/bom.csv led-review.kicad_sch 匯出 BOM，逐列要求 Manufacturer、MPN、Value、Footprint 與 Datasheet URL；再拿第一方 datasheet 核對封裝尺寸、pin 1、極性、額定值和焊盤編號。KiCad 官方文件也要求每個 schematic symbol 在進入 PCB 前都要有 footprint。

這份 LED 教學若尚未指定真實 MPN，就只能把 PKG-01 留在 BLOCKED，不能用「0805 看起來差不多」代替 datasheet。BOM 有列出料號，也不代表供貨永遠存在；採購日期與替代料批准要另外留下紀錄。

第 7 關：DRC 與人類停手——沒有板檔就誠實寫 N/A

痛點：把 schematic-only 的交付誤標成「DRC 已過」，等於捏造證據。解法是條件式閘門：有 .kicad_pcb 且有真正對應的 .kicad_sch，才執行 kicad-cli pcb drc --format json --severity-all --exit-code-violations --schematic-parity --refill-zones --output evidence/drc.json led-review.kicad_pcb；atopile-only board 要移除 --schematic-parity，並記錄原因。報告只足以證明已設定規則的結果，EMI、signal integrity 與製程仍要各自建立證據。

本文的終點是可審查原理圖，所以 DRC 狀態預設寫 N/A — no board artifact in scope。最後由人類在 review-signoff.md 列出通過、失敗、未測項目與下一階段授權。只要存在 BLOCKED、未解 ERC、缺 MPN 或未核對 pin map，就不輸出製造檔。

設計 3 個錯誤注入：先寫預期 detector

實際操作時，先保存一份乾淨 baseline，然後一次只改一件事。這種 negative test（負向測試）只有在真正執行並保存報告後，才能證明檢查會在預期位置失敗。做法與 AI Evals 相同：先寫預期答案，再看系統是否抓得到；下列三項是待執行的測試設計，不是本文已跑出的結果。

1. 拔掉 D1 cathode 的 GND：netlist 不變量或 ERC 必須指出未連接腳位，命令不得回傳 0。
2. 把 R1 從 620Ω 改成 62Ω：ERC 可能仍是綠燈，但 SPICE 或數值 assertion 必須讓 ELEC-01 失敗。
3. 把 0805 footprint 改成 0603：BOM／footprint review 必須讓 PKG-01 失敗；不要期待 ERC 替你抓封裝需求。

只有當你實際注入錯誤、保存報告，而且每個 detector 都在預期位置失敗後，才能說這三個 failure mode 已有驗收證據；即使如此，也不代表所有故障都被覆蓋。下一輪可以再加入反向 LED、錯誤 pin map、缺 power flag、板邊距與 clearance violation。這正是 確定性核心、機率性邊緣 的實作：讓 AI 自由提出方案，讓檢查器只回答可以被證明的問題。

一條預期 trace：從 prompt 到停手

把流程串起來時，Astra 收到的不是一句願望，而是一個任務封包：讀取 requirements.md；只准編輯指定專案；二選一產生 design.ato 或 led-review.kicad_sch；每次 build 後回報改過哪些檔；不得匯出 Gerber；缺 datasheet 或 MPN 時停下。沒有人工決定，不混合兩條路徑。模型完成後，人類不先看「它說什麼」，而是依序讀 evidence。以下不是本文環境跑出的 log，而是應由真實 artifact 填寫的預期 trace；未執行的項目一律標成 NOT RUN，不得拿預期值代替結果。

1. environment.txt 應記錄 KiCad、atopile、模型與 commit，作為重跑入口。
2. design.net 或 .ato 實際匯出後，應只出現預期的三段連接。
3. KiCad-native 的 ERC 真正執行後，只有 erc.json 沒有未核准 violation 且 exit code 為 0，才可記為 PASS。
4. 算術預期範圍是 4.1–5.6mA，不是 SPICE 量測；實跑後要保存測試向量、輸出並引用 ELEC-01，換成真實 LED 模型後必須重跑。
5. bom.csv 若缺 MPN，PKG-01 應保持 BLOCKED。
6. 如果交付範圍沒有 board artifact，drc_status 應明確寫成 N/A。
7. review-signoff.md 最多只能在證據齊全時寫「可供原理圖審查」，不能跳成「可製造」。

這種 trace 最有價值的地方，不是預填每一關都綠；恰恰是它允許第 6 關保持紅色，仍能誠實交付目前已知的成果。可靠流程的標誌不是永遠成功，而是失敗時知道卡在哪裡、要補哪份證據。

每個檢查器都看不到什麼？

ERC 擅長連線規則，看不到功能規格；SPICE 擅長已建模的電氣行為，看不到模型沒包含的連接器接觸、散熱、EMI、ESD 與實際製程偏差；BOM review 擅長把符號連回真實料件，看不到未來庫存；DRC 擅長已設定的幾何與 net 規則，看不到你從沒寫進 rule set 的限制；人眼擅長理解產品脈絡，卻會疲勞與漏看。所以不是選一個最強裁判，而是讓多個不完美裁判互相補洞。

同樣要小心 benchmark 的邊界。EEBench 即時榜已在 2026 年 9 月 4 日更新 Astra 結果，但它測的是 13 個 simulation-backed tasks，不是 OpenAI 影片裡那塊板，也不是完整 layout／製造測驗；而公開的方法頁與榜上 Astra 的 scaffold 標示目前不一致。最穩妥的讀法是：這些資料支持「模型能參與一部分電路設計迭代」，不能支持「模型已能獨立交付任何 PCB」。

常見問題 FAQ

1. GPT‑6 Astra 可以直接操作 KiCad 嗎？

可以，官方已公開操作示範。更精確地說，公開資料顯示 Astra 透過電腦操作在 KiCad 做 PCB layout；本文不把這段影片延伸解讀成每個帳號都有一個獨立、保證可用的 KiCad 整合。

2. 一定要用 atopile 嗎？

不一定。.ato 比 GUI 座標容易做 diff 與 assertion，但不要假設它會產生對應 .kicad_sch。選 KiCad-native 或 atopile 都可以；要依實際 artifact 套用正確閘門。

3. ERC 通過是否代表電路會工作？

不代表。KiCad 官方文件明確說 ERC 不能確保設計能工作；它主要找常見接線、供電與標註問題。功能需求要靠計算、SPICE、量測與 review。

4. 只有原理圖也能說 DRC 通過嗎？

不能。KiCad CLI 的 PCB DRC 輸入是 board file；若交付範圍沒有 .kicad_pcb，正確狀態是 N/A，並附上原因。

5. SPICE 全過是否就能送廠？

還不能。SPICE 結果只對選定模型、參數與測試向量成立；footprint、layout、製程、實板與環境條件仍是不同證據層。

6. 只規劃三個錯誤注入就夠了嗎？

不夠，而且規劃不等於完成測試。實際注入、保存報告並確認 detector 在預期位置失敗後，它們才構成 smoke test；仍不是完整 coverage。每新增一種高風險 failure mode，就補一個能重跑的負向案例。

7. 可以讓 Agent 自動匯出 Gerber 或下單嗎？

這套流程不授權。製造輸出與採購是難以逆轉的下一階段動作，應在完整板級審查後由人類另行批准；原理圖驗收的成功不能偷偷擴張權限。

8. 最少要保存哪些檔案？

至少保存需求、原始檔、版本、prompt／工具紀錄、netlist、ERC、SPICE、BOM／footprint review、DRC 或 N/A 理由，以及人工簽核。少了其中一層，就在 evidence packet 明寫缺口。

給新手的 5 個重點

1. 先寫可判定需求，再開模型。
2. 優先驗 netlist 與檔案 diff，不要先被 GUI 動畫說服。
3. ERC、SPICE、BOM、footprint、DRC 回答的是不同問題。
4. 故意犯錯，確認每道閘門真的會失敗。
5. 允許 BLOCKED 與 N/A；誠實停手比假綠燈更接近工程。