前言
過去十多年，我一直從事汽車電子軟體開發，主要專注於 AUTOSAR、ADAS、Vehicle Functional Safety（ISO 26262）等安全關鍵系統。在設計 Operator X02 時，我發現自己思考問題的方式，與很多 AI IDE 的設計方式並不相同。
後來我才意識到，這種思維方式，其實來自我多年來的汽車軟體架構經驗。Operator X02，並不是把 AI 放進 IDE，而是嘗試把 AUTOSAR Runtime 的設計理念，帶入 AI Engineering Platform。
一AUTOSAR 教會我的第一件事：Runtime 比 Editor 更重要
傳統 IDE 的架構，大多可以簡化為：
Editor First
Editor→ Extension Host→ Plugin→ AI所有能力都不斷往 Plugin 或 Extension 中堆疊：AI Chat、AI Completion、Search、Git、Debug、Build、Memory。隨著功能越來越多，整個 Extension Host 也越來越複雜。
但是，在 AUTOSAR 世界，並不是這樣。AUTOSAR 從一開始，就把 Runtime 放在整個系統的中心。Application 不直接控制 Hardware，所有能力都必須經過 Runtime。因為 Runtime 才負責：
- 生命週期管理 Lifecycle
- 服務調度 Scheduling
- 資源管理 Resource Management
- 通訊 Communication
- 錯誤處理 Error Handling
這也是我設計 Operator X02 時最大的影響。
二Operator X02 不是 Editor First，而是 Runtime First
因此，X02 的架構並不是 Editor → Plugin → AI → Hardware，而是：
Client
- Editor
- CLI
- Web
- Chat
- Dashboard
- Report
Services
- Engineering Memory
- AI Agent
- Search Engine
- Build Engine
- Hardware Runtime
- Report Engine
- Process Manager
未來甚至可以增加 CLI、Web UI、Mobile App —— 它們都可以共用同一個 Runtime。
Editor 只是 Runtime 的一個 Client。
三AUTOSAR 教會我的第二件事：Service 比直接呼叫更重要
AUTOSAR 一直強調：Application 不應該直接操作硬體。例如，Application 不需要知道 CAN Driver 是哪一家廠商的實作，因為 Runtime 已經完成抽象。
Operator X02 同樣如此。AI Agent 不應該直接控制 Serial、CAN 或 Flash。正確的方式應該是：
Service Path
AI Agent→ Runtime Service API→ Driver→ HardwareAI 只知道：「我要讀取 Serial。」而不知道底層 Driver 如何實現。這樣不僅更安全，也更容易維護。
四AUTOSAR 教會我的第三件事：生命週期比執行一次任務更重要
汽車軟體不會只執行一次。它可能連續運行數小時、數天、數個月。因此，AUTOSAR 非常強調 Lifecycle：
Lifecycle
Init→ Start→ Run→ Error / Recovery→ ShutdownOperator X02 同樣如此。打開一個 Workspace 後，Runtime 會持續運行 File Watcher、Search Engine、Engineering Memory、AI Agent、Git Monitor、Hardware Monitor。這些都不是一次性的任務，而是持續運行的 Service。
因此，我更關心的是：如何安全啟動？如何恢復？如何關閉？而不是：如何執行一次 Prompt？
五Functional Safety 對我的影響
很多人認為，ISO 26262 只是安全標準。但對我而言，它更是一種設計思想。它讓我習慣思考：
- 如果 AI 做錯了怎麼辦？
- 如果 Hardware Disconnect 怎麼辦？
- 如果 Build 中斷怎麼辦？
- 如果 Flash 一半失敗怎麼辦？
因此，我希望未來的 X02 不是「AI → 直接執行硬體操作」，而是：
High-risk Operation
AI→ Policy Engine→ Permission Control→ User Confirmation→ Audit Trail→ 執行危險操作 —— 例如 Flash ECU —— 必須經過確認，而不是由 AI 直接執行。這種思想，其實就是 Functional Safety 帶給我的影響。
六為什麼最後選擇 Rust Runtime？
很多人問我：為什麼不是 Electron？為什麼不是 Node.js？為什麼是 Rust？我的答案其實很簡單：不是因為 Rust 更快，而是因為 Rust 更適合 Runtime。
Runtime 需要長期運行、管理資源、管理執行緒、管理硬體、管理生命週期、管理背景 Service。這些都是 Rust 擅長的事情。
這些概念，具體解決了什麼問題？
Ownership
所有權Rust 在編譯期就決定了每一個資源由誰持有、何時釋放。對 Runtime 來說，這代表一個 Serial Port、一個 File Handle、一條硬體連線，永遠只有一個明確的擁有者。長時間運行時，不會出現資源洩漏，也不需要 GC 在背後暫停整個系統。
Tokio
非同步 RuntimeX02 同時要等待很多事情：Serial 資料、檔案變動、AI API 回應、Build 輸出。Tokio 讓這些等待可以並行發生，而不需要為每一個任務開一條執行緒。一個 Build 跑十分鐘，不會讓 Serial Monitor 停止刷新。
Channel
訊息通道模組之間不共用記憶體，而是互相傳送訊息。這其實就是 AUTOSAR 的思想：不直接呼叫，而是透過定義好的介面溝通。它還帶來一個額外的好處 —— 每一次跨模組的互動，都是可以攔截、記錄、審計的。
Actor
獨立服務單元Serial、Build、Memory、AI Agent，各自是一個擁有自己狀態的獨立單元，只透過訊息與外界溝通。這與 AUTOSAR 的 SWC 概念非常接近。其中一個出錯，不會污染其他模組的狀態。
Supervisor
監督者Supervisor 負責監看這些 Actor，並在失敗時決定：重啟、降級，還是停止。這正是前面提到的 Lifecycle 與 Error Handling 的具體落實。Serial 連線斷掉，只會重啟 Serial Service，而不是讓整個 Runtime 崩潰。
換句話說，這五個概念加起來，其實就是一句話：
Rust 讓我可以用寫車用軟體的方式，去寫一個 IDE 的 Runtime。
七Operator X02 的真正目標
AI 只是其中一個能力。Runtime，才是真正的平台。
結語
Operator X02 的設計，並不是來自傳統 IDE。它更多來自我多年汽車軟體開發的經驗。
- AUTOSAR教會我：如何建立 Runtime。
- Functional Safety教會我：如何管理風險。
- Rust則讓我能夠把這些理念真正落地。
所以，我希望 Operator X02 不只是一個 AI IDE，而是一個真正能夠長期運行、連接 AI 與真實工程世界的 AI Engineering Runtime Platform。