你的代理可以交給你一個 STEP 檔：text-to-cad 和"程式碼即幾何"這一招

那段一直都不是文字的部份

寫程式的代理之所以能寫軟體，是因為軟體就是文字。光是這一點，幾乎就解釋了它們擅長的一切。它也解釋了為什麼它們在機械領域一直派不上用場：一個支架不是文字，一個壁厚不是文字，而一個 STEP 檔當然也不是文字，雖然技術上來說它確實是。

text-to-cad 是 earthtojake 做的 MIT 授權外掛，這個月一直掛在 GitHub 趨勢榜上，大約 18,600 stars。它用一個老招解決了這個矛盾：如果這東西不是文字，就幫這東西做一個文字表示。在這裡，就是一支參數化的 Python 腳本。

代理的工作不是去想像一個 3D 模型，而是寫出幾何核心能執行的程式碼。這個差別就是整個產品。

這個循環實際上怎麼跑

底下那層引擎是 cadgen，一個 PyPI 上的 Python 套件，建立在 build123d 之上，build123d 又驅動 Open CASCADE——正經的 CAD 工具用的就是這一系的幾何核心。模型就是一支普通的 Python 腳本：一個用 step 定義裝飾、回傳一個 shape 的函式。

比如說你想要一個 3mm 壁厚、兩個 M3 孔的相機支架。你用文字描述它。代理寫出帶參數的腳本，參數有壁厚、孔徑、孔距。cadgen 跑一遍，寫出 STEP；你要的話還能輸出 STL、3MF 或 GLB。想改孔位，改一個數字，再跑一次。模型原始碼就留在儲存庫裡，跟你的其他程式碼放在一起，也就是說它可以被 diff、被 review、被還原，跟別的東西一樣。

這就是精確幾何和"看起來像"的網格之間的差別。網格產生器產出的是一個看起來像支架的表面。實體建模器產出的是一個壁厚已知的支架，而加工廠會收 STEP 檔，同時會客氣地拒絕你那個由 4,000 個三角面拼成的曲面 STL。

外掛也管那些決定設計能不能真的做出來的無聊部份。它會跑面向製造的設計檢查和面向積層製造的設計檢查——壁厚、懸垂、拔模角、倒扣——而且每一條結論都會給出背後的規則，不是丟一句冷冰冰的警告。它能產生帶尺寸的工程圖 PDF，有視圖、隱藏線、孔標註和圖框。它能寫雷射切割用的 DXF 輪廓，透過 OrcaSlicer 切片出 G-code，把列印工作送到 Bambu Lab 機器，替 SendCutSend 跑上傳前檢查，也能寫 URDF、SRDF 和 SDF 檔，用於機器人描述和模擬環境。

還有一個本機檢視器。在支援的 app 裡，模型會以卡片形式出現在對話裡；其他地方就給你一個 localhost 連結。

為什麼這套東西可以推廣

CAD 這個用例很具體，但這個模式不具體。任何具備兩個屬性的領域，都可以交給寫程式的代理：一個是產物的程式碼表示，一個是能判斷產物有沒有效的檢查器。

機械零件兩樣都有。腳本是表示，可製造性檢查是驗證器。網頁兩樣都有：HTML 和瀏覽器。基礎設施兩樣都有：設定和 plan。影片直到不久前兩樣都沒有——至少沒有代理能執行的形式，而這正是 HyperFrames 這類專案在補的洞。

一個領域要是缺檢查器，代理就會信心滿滿地產出垃圾。這就是 "AI for 3D" 一直卡在預覽階段的原因：在"看起來像一張椅子"和"做得出來"之間，沒有驗證器。

這個模式的另一半是本機執行。cadgen 跑在你自己的機器上，對著一個真的幾何核心。幾何這一步，沒有任何東西是被神經網路近似出來的。代理貢獻參數化意圖，核心貢獻真相。

採用成本，這些是真的

有兩件事會咬人，而且兩件都寫在儲存庫裡，不是讓人踩坑踩出來的——這點得給作者記一功。

Windows 11 有個專門的坑。 CAD 核心的 Python 綁定帶了一個未簽章的原生模組，而 Windows 11 的 Smart App Control 在全新安裝時預設開啟，會把它攔下來。然後每一條命令都以 DLL 載入錯誤失敗。沒有針對單一應用程式的例外。你的選擇是關掉 Smart App Control（有些系統上只能靠重裝 Windows 才能恢復），或者把 CAD 技能放到 WSL 下跑。有個 doctor 命令能辨識這種情況，所以你至少能很快知道。

遙測預設開啟。 README 把它寫得異常詳細，這個直覺是對的。送出去的是：版本、安裝來源、作業系統、你用哪個代理 app，還有一些計數，比如每個工具被呼叫了幾次、建了多少模型，以及從固定清單裡選的失敗原因，而不是錯誤文字。當機報告包含錯誤類型和工作在程式碼裡失敗的位置。所有東西都打上一個隨機安裝 ID，存在 PostHog；伺服器從 IP 推斷你的國家，但不保留位址。永遠不送的是：檔案名稱、路徑、檔案內容、prompt。一條命令就能關掉，關掉時也會把已經送出去的刪掉，而且 CI 裡和開發版安裝都不送。

這兩件事對一個年輕專案來說都正常，也都影響採用。商業 CAD 廠商兩樣都不會做。

它不適合拿來做什麼

有機形狀。角色、公仔、雕塑形態——任何形狀本身是目的、不是功能的東西，那是網格生成的地盤，以網格為基礎的 image-to-3D 模型是更好的工具。想用參數描述一條龍，會是一個很糟的下午。

它也不能取代工程簽核。DFM 技能是一次引導式審查，不是認證。如果一個零件要承受人的體重，還是得有人類工程師在圖面上簽字。這個循環的終點是有人去付一張發票，而人類大概就該待在這個位置上。

儲存庫本身很年輕，跑得很快：2026 年 4 月建立，超過 1,400 commits，一個 PyPI 套件發了幾十個版本，十月初兩天內連發三個版本。這個速度，你要是喜歡新技能就是優點，你要是需要穩定就是風險。

README 裡那句話，才是重點

描述裡埋了一個很容易被跳過的說法：這個外掛給你的代理一套真正的 CAD 工作流程。不是 demo，不是 prompt 包裝，而是一套有表示、有執行器、有驗證器、還能把手上的活交給加工方的工作流程。

這就是那種能讓代理在軟體之外也有用的東西的形態。不是一個懂支架的模型，而是一個循環：模型寫出可執行的東西，另一個東西去檢查它，輸出是另一個系統能接受的檔案。代理不需要擅長 CAD，它需要擅長程式碼，而這個領域需要有編譯器。

機械工程先走到這一步，是因為它的編譯器已經五十歲了，而它的驗證器是一套製造規則。其他任何領域只要湊齊這兩塊，一年之內看起來都會是這個樣子。