Day 1:為什麼要讓 LLM 當視覺工程師?——系列開賽與架構總覽

一個做過視覺檢測的人都懂的痛

如果你調過工業視覺檢測的參數,你一定經歷過這種下午:對著一張打光不均的影像,把二值化閾值從 127 調到 131,再調回 129;把形態學的 kernel 從 3×3 換成 5×5;輪廓面積篩選的下限改了八次。每一次調整都要重跑、看圖、再調。這些工作不難,但極度依賴「手感」——而手感沒辦法寫成文件交接。

去年開始,我有了一個念頭:這些手感,LLM 有沒有可能學得會?

不是叫 LLM「看圖說故事」——多模態模型看圖的能力還不足以做精密量測。而是反過來:讓 LLM 當那個「調參數的工程師」,它負責推理該用什麼演算法、參數怎麼調,實際的影像運算交給 OpenCV 執行,結果再回饋給它繼續判斷。LLM 出腦,OpenCV 出力。

這個系列要做什麼

30 天內,我會從零開始拆解一個我已經實際做出來的專案:DevTerminal——一個 Hyper Terminal 插件,把終端機變成 VS Code 式的開發者主控台,並且在上面長出一個「AI 機器視覺工作台」。核心架構長這樣:

Claude Code ──MCP (stdio)──▶ vision-sidecar.exe ──寫入──▶ state.json
                              (.NET 9 + OpenCV)               │
                                                              ▼
                              DevTerminal VisionPane ◀──chokidar 監看
                              (Hyper 插件,Electron renderer)

三個行程,各司其職:

1. Claude Code:使用者既有的 AI CLI,透過 MCP(Model Context Protocol)呼叫視覺工具。插件本身完全不碰 LLM API——用的是使用者自己的訂閱。
2. vision-sidecar:.NET 9 寫的 MCP server,包了 OpenCvSharp,提供 60 多個工具:濾波、閾值、輪廓、模板比對,一路到 ONNX 分類器推論與 TorchSharp 微調。
3. DevTerminal 插件:監看 sidecar 寫出的 state.json,即時把 AI 的每一步處理結果畫在終端機旁邊。

中間還藏了一個有趣的協定問題:MCP 沒有 server push,那當 AI 需要人類「框一個 ROI 給我」時怎麼辦?我們用**檔案側信道(file side-channel)**實現了「工具呼叫中途暫停、等待使用者互動、再繼續」——這會是系列中段的重頭戲。

你會學到什麼

• Electron / Hyper 插件開發:在別人的 React 樹裡動手術,以及 xterm.js 吃掉滑鼠事件的各種地雷
• MCP server 實作:用 C# 從零寫一個 production 等級的 MCP server,以及「怎麼設計工具讓 LLM 好用」
• OpenCV 檢測流程:從前處理到量測的完整 pipeline,由 AI 實際操作給你看
• 不用 Python 的模型訓練:ONNX Runtime 推論 + TorchSharp 微調,全部在 C# sidecar 內完成
• 一個真實案例:工業環形碼字元辨識,含 GF(16) 同位驗證

寫在前面

這不是一個「跟著做就會動」的教學系列——更像一份踩坑紀錄。很多設計(檔案側信道、capture-phase 事件監聽、prototype 分類器)都是撞牆之後的產物,我會連撞牆的過程一起寫。

明天從最底層開始:Hyper Terminal 的插件機制,以及為什麼我選它而不是自己刻一個 Electron app。

我們 Day 2 見。

30 天目錄

第一部:DevTerminal 插件基礎(Day 1–6)

第二部:MCP Sidecar 與視覺工具(Day 7–14)

第三部:前端整合與互動原語(Day 15–20)

第四部:分類器實戰——環形碼辨識(Day 21–27)

第五部:延伸與總結(Day 28–30)