GPT-5.5 發布當天：有人用 Codex 生出整套七軸機器手臂

發生什麼事

2026-04-23，OpenAI 正式發布 GPT-5.5，這是它目前最強的 agentic coding 旗艦模型。幾個小時之後，一位帳號是 Jake（@soft_servo）的工程師丟出了一段示範影片，配上一句很有代表性的自述：

Vibe coding a robot with GPT 5.5!

他在 Codex 裡面生出了一支 7-DOF 的機器手臂——包含可運作的 URDF 描述檔、正向與逆向運動學、一套自訂 GUI、以及 STEP 格式的零件與組裝模型。除了夾爪（gripper）以外，其餘 100% 由 Codex 生成。他自己的評語是：同樣的結果，以前要橫跨五六個工具、縫合幾個禮拜才拼得出來。

這支 demo 在發布當天被大量轉傳，不只是因為「AI 生出機器人」聽起來很聳動，而是因為它觸到一個之前 LLM 幾乎碰不太動的領域：結構化的機器人描述 + CAD 幾何 + kinematics 同時端到端產出。

URDF、7-DOF、STEP 各是什麼？為何這組合很硬

要理解這件事為什麼不平凡，需要拆開看這三個名詞。

URDF（Unified Robot Description Format）是 ROS 生態系統用來描述一台機器人的 XML 格式。它定義了每個 link 的幾何外型、質量與 inertia matrix、每個 joint 的類型（revolute / prismatic / fixed）、上下限、parent-child 關係、collision mesh 等。URDF 不是隨便寫寫就能跑的檔，錯一個欄位，模擬器會把整支手臂甩飛。

7-DOF（seven degrees of freedom）指的是有七個獨立控制軸的機器手臂，像 Franka Panda、Fetch 那一類的研究型手臂。比起 6-DOF，多出來的那一軸提供了「冗餘自由度」，可以在末端位置固定時重新配置手肘——這讓 inverse kinematics（逆向運動學）不再有唯一解，需要額外最佳化。也就是說，寫 IK solver 本身就是一個有點麻煩的工程問題。

STEP（ISO 10303-242）是跨軟體的 CAD 交換格式（.step / .stp），可以讓 SolidWorks、Fusion 360、FreeCAD 之間互通幾何。要產 STEP 通常意味著得處理 B-rep 幾何，不是單純輸出一坨 mesh。

把這三件事放在一起——URDF 描述 + 正逆向運動學實作 + GUI + STEP 幾何——等於一次要處理「機械結構語意」「控制數學」「UI」「CAD 幾何格式」四種截然不同的知識。以前要做這件事，你通常會在 ROS、MoveIt、FreeCAD、PyQt、NumPy 之間切換，手動縫合好幾個禮拜。Jake 這句「weeks stitching half a dozen tools」並不誇張。

為什麼發布日期很關鍵：400K context 是 vibe coding 的底氣

這個 demo 不是偶然出現在 GPT-5.5 發布當天。它幾乎是為新模型的特性量身定做的展示。

OpenAI 這次揭露的重點之一是 GPT-5.5 在 Codex 裡提供 400K context window，Plus / Pro / Business / Enterprise 都能用；同時還加上 Fast mode，以 2.5 倍成本換取 1.5 倍速度。官方自己的說法是，GPT-5.5 在 agentic coding 任務上超越 GPT-5.4、Anthropic Opus 4.7、Google Gemini 3.1 Pro，而且 per-token latency 與 GPT-5.4 相同，但完成相同 Codex 任務用更少的 token。至於 GPT-5.5 Pro，目前還只開在 ChatGPT 的 Pro / Business / Enterprise，API「soon」。

400K context 是 vibe coding 一台機器人的前提。URDF 本身就長，運動學程式碼、GUI 程式碼、STEP 生成腳本加起來，再配上使用者的自然語言描述、先前的錯誤訊息、reference sketch——這些東西不放在同一個 context 裡，模型就接不上自己前面的設計決策，會產出不一致的 joint 命名、對不上的尺寸、跟 STEP 不符的 inertia。換句話說，這類「跨子系統一致性」的任務，對 context 容量特別敏感。

同一天發布模型、同一天跑出 demo，這件事本身也反映了另一個訊號：OpenAI 現在的新模型節奏和社群 demo 已經緊緊咬合，新模型出來的幾個小時就決定它未來幾週的敘事。

降溫：vibe coding 一台機器人 ≠ 做出一台能動的機器人

在被 demo 影片帶走之前，需要誠實地拆一件事：URDF 跑得起來 ≠ 機器人站得起來。

URDF 的正確性有幾個很容易出錯、但肉眼又難發現的地方：

Inertia matrix：如果 tensor 填錯，或者質量和幾何配不上，模擬器裡手臂看起來還會動，但動力學完全是假的。真的上實機，馬達力矩就錯了。
Joint limit：上下限寫太寬，solver 會找到在真實機構會撞到自己的解；寫太窄，workspace 會莫名縮小。
Collision mesh：URDF 常見做法是用簡化的 collision primitive。如果產出的 mesh 與 visual mesh 不一致，自碰撞檢查會放出錯誤的假陰性。
IK 正確性：7-DOF 冗餘解是一個 null-space 的最佳化問題，LLM 很容易生出「看起來在算 Jacobian pseudo-inverse」但其實數值條件很差的實作。

這些問題和「LLM 生 Terraform」的情境很像：terraform apply 跑得起來不等於 production-ready，IAM 邊界、狀態鎖、成本爆衝都會在模擬階段完全看不出。Codex 生出的 URDF + STEP 同理——模擬器裡看得到手臂擺動，不等於實體關節受得了真實重力與加速度。

到目前為止，也沒有公開 benchmark 在系統性地衡量 LLM 產 URDF 的正確率。ICLR 2025、ArXiv 2025 有研究探討從 URDF 反向生出「robot resume」、或從符號規劃產出機械手臂軌跡，但「單一 prompt 端到端生出 URDF + kinematics + GUI + STEP」這條路線沒有正式指標。這不是說 Jake 的 demo 有問題——它仍然是一個了不起的工程示範——而是提醒：Twitter 上的驚嘆影片，和論文/工廠裡該有的驗收標準，是兩種不同的證據。

至於 gripper 為什麼被排除、Codex 生出的 STEP 檔案在真實 CAD 軟體裡能不能通過製造檢查、inertia matrix 是不是抄的而不是從幾何算的——tweet 沒講，我們也不該替它補。

結語

這支 demo 在 GPT-5.5 發布日出現，不是巧合。它同時展示了兩件事：400K context + agentic Codex 確實把原本要「跨工具縫合」的長鏈路任務壓成單一 prompt；但也提醒我們，機器人跟 DevOps 一樣，正確性是沿著整條 stack 傳遞的，任何一層的錯誤都會在下游放大。

Vibe coding 值得興奮，尤其是在「結構化描述 + 數學 + 幾何 + UI」這種過去最難 end-to-end 的領域看到端倪。但真正決定勝負的，不是 demo 有多華麗，而是 URDF 能不能被 MoveIt 接走、STEP 能不能進 CAM、IK 能不能在實機跑滿 8 小時不出事。下一個值得追的問題不是「AI 能不能產機器人」，而是「AI 產出的機器人描述檔，能不能通過工程驗收流程」。

那一天來了，才是 vibe coding robotics 真正落地的一天。