為什麼下一代 AI IDE 的核心不是 Editor，而是 Runtime

在上一篇文章中，我提出了一個觀點：AI 可以寫程式，但 AI 並不能取代真正的工程（Engineering）。

今天，我想繼續回答另一個問題：如果未來不是 Vibe Coding，那下一代 AI IDE 應該長什麼樣？

我為什麼開始開發 Operator X02？

很多朋友問我：市面上已經有那麼多 AI Coding 工具，為什麼還要自己開發一套新的 IDE？答案其實並不是因為我想做另一個 AI Editor。

真正的原因，是我發現大部分 AI IDE 的設計思維，仍然建立在「編輯器（Editor）」之上。它們努力讓 AI 更會寫程式。但我真正想解決的問題不是「如何讓 AI 寫更多程式？」，而是：

如何讓 AI 成為真正的工程夥伴（Engineering Partner）？

這兩者，其實完全不同。

我的設計思想，來自汽車軟體，而不是傳統 IDE

在汽車產業，我們每天思考的問題不是「如何快速寫出程式？」，而是：

• 如何讓系統可以穩定運行十年以上？
• 如何避免一個模組故障導致整個系統失效？
• 如何管理大量軟體元件？
• 如何保證硬體資源不被錯誤使用？
• 如何讓每一次決策都可以追蹤與驗證？

久而久之，我發現自己的架構思維，與一般 IDE 的設計方式越來越不同。

我們一直在改進 Editor，卻很少重新思考 Runtime

過去二十年，IDE 一直不斷進化。從語法高亮、自動補全，到 Git、除錯器，再到今天的 AI Assistant —— 幾乎所有創新，都圍繞著同一個核心：Editor。

我們不斷讓 Editor 更聰明、不斷加入更多功能、不斷增加更多 Extension。但是，我們很少重新思考另一件事情：Editor 真的是未來 AI 工程平台最重要的核心嗎？

傳統 IDE

AI

▲

Extension

▲

Plugin

▲

Editor

Operator X02

Engineering
Runtime

Engineering MemoryAI AgentSearch Engine Build EngineHardware RuntimeReport Engine Process ManagerKnowledge Management

AUTOSAR 教會我的第一件事：Runtime 比 Editor 更重要

傳統 IDE 通常以 Editor 為核心：Editor → Plugin → Extension → AI。功能越多，就增加更多 Plugin。

但是 AUTOSAR 完全不同。AUTOSAR 的核心不是 Editor，而是 Runtime。Application 不直接操作 Hardware，所有能力都透過 Runtime Environment（RTE）協調。Runtime 負責：

• Lifecycle
• Scheduling
• Communication
• Resource Management
• Error Handling
• Service Coordination

這種思想深深影響了我。因此，在設計 Operator X02 時，我並沒有把 AI 放進 Editor。我反而開始思考：如果把 AUTOSAR Runtime 的概念搬到 AI IDE，會發生什麼事情？

Operator X02 的核心，不是 AI，而是 Runtime

Operator X02 的核心並不是 AI Chat，也不是 AI Code Completion。真正的核心，是一個可以長期運行的 Engineering Runtime。它負責管理 Engineering Memory、AI Agent、Search Engine、Build Engine、Hardware Runtime、Report Engine、Process Manager 與 Knowledge Management。

React 或 Editor，只是 Runtime 的一個使用者介面。真正工作的，是 Runtime。這也是我選擇 Rust 作為 Runtime，而不是把所有能力都放在 Editor Extension 裡面的原因。

真正重要的，不是程式碼，而是知識

回想這些年的工程經驗，我發現真正有價值的，從來都不是程式碼本身。真正困難的是：

• 為什麼當初這樣設計？
• 為什麼這個 Bug 當時這樣修？
• 為什麼這個介面不能修改？
• 為什麼這個流程必須這樣執行？

Repository

做了什麼

• 程式碼
• Commit
• Diff

Not in the repo

為什麼

• 會議
• 郵件
• 文件
• 白板討論
• 工程師的大腦

而這些，恰恰也是今天 AI 最缺乏的東西。於是，我開始產生一個想法：如果 AI 能夠理解的不只是程式碼，而是整個工程知識，會發生什麼？

Functional Safety 改變了我對 AI 的看法

ISO 26262 對我的影響，不只是安全流程。更重要的是，它改變了我思考 AI 的方式。如果 AI 可以 Build、Flash Firmware、操作 ECU、修改硬體設定，那麼 —— AI 不應該擁有無限制的權限。任何高風險操作，都應該經過：

AI 不應該直接控制工程。AI 應該受到工程流程約束。

我相信，未來真正的 AI Engineering Platform，一定需要具備這種能力。

我為什麼選擇開源？

很多人也問我：為什麼不把 Operator X02 做成完全封閉的商業產品？答案很簡單。因為我相信，未來 AI 將不只是幫助我們寫程式，它會開始參與汽車電子、自動駕駛、機器人、工業控制、醫療設備、航太系統。

這些都屬於安全關鍵領域。在這些領域，我們真正需要的，不只是更聰明的 AI，我們更需要：

我相信，開放的架構更有利於建立這些能力。開源並不是放棄商業，而是希望讓更多工程師一起討論：下一代 AI Engineering Platform 應該如何設計。我希望 Operator X02 可以成為一個共同演進的平台，而不是一個只有少數人能理解的黑盒。

我相信，未來的 AI IDE 將會改變

今天，大部分 AI IDE 的重點仍然是：如何更快產生程式碼。但我認為，真正的挑戰已經開始改變。未來真正重要的，不再只是 Code Generation，而是：

• Context
• Architecture
• Engineering Knowledge
• Long-term Memory
• Hardware Integration
• Workflow Automation
• Human Decision

AI 可以協助完成大量工作。但真正決定產品品質的，仍然是工程架構與系統設計。這也是我上一篇文章想表達的核心觀點：

真正的工程，不只是寫程式。真正的工程，是建立一個可以長期演進、值得信任的系統。

Operator X02 的願景

我並不希望打造另一個 AI IDE。我希望打造的是 —— 一個真正屬於工程師的 AI Engineering Runtime：一個能夠連接 AI、Engineering Memory、Engineering Knowledge、Engineering Workflow、Hardware、Functional Safety 與 Digital Twin 的平台。未來，它可以服務的不只是軟體工程，也包括：

• Embedded Systems
• Robotics
• Automotive
• Industrial Automation
• Edge AI
• Intelligent Devices

Operator X02，對我來說意味著什麼？

有人把它看成一個 Side Project，有人把它看成一個 AI IDE，有人把它看成一個開源專案。但對我來說，它更像是一場實驗 —— 一個關於未來工程方式的實驗。

如果未來的軟體開發，不再只是人與程式碼之間的關係，而是人與 AI、知識、硬體、團隊之間的協作，那麼，我們今天使用的工具，是否也應該重新設計？Operator X02，就是我對這個問題的回答。

它也許還不完美，還有很多地方需要改進。但我相信，每一次迭代，都讓它更接近我心中的目標。我並不知道 Operator X02 最終會走到哪裡，也不知道未來 AI 會發展成什麼樣。但我知道一件事情：

真正改變世界的工具，往往不是因為它擁有最多功能，而是因為它改變了人們工作的方式。

如果有一天，Operator X02 能夠幫助工程師 ——

• 把更多時間放在思考，而不是重複勞動；
• 把更多精力放在創造，而不是尋找資料；
• 讓 AI 成為真正值得信賴的工程夥伴，而不僅僅是一個程式碼生成器。

那麼，這一切的投入，就已經值得了。