---

我怎麼走到這裡

Physics

我的起點是物理。物理訓練給我的不是特定技術，而是一種處理問題的方式：先把系統寫成模型，再用量測驗證模型，然後從誤差回頭修正理解。這個習慣後來在寫軟體時一直跟著我——先問「這個系統真正的狀態是什麼」，再問「要怎麼實作」。

Electrical Engineering / Control exposure

之後我進入電機工程研究所，接觸 automatic control 與 power conversion。雖然最後沒有完成研究所學位、選擇轉向軟體，但控制理論的觀點留下來了：系統有狀態、有回饋、有穩定與不穩定的條件。我後來在生產流程與部署流程裡都在做同一件事——把隱性的狀態變成顯性的模型。

Software

轉往軟體之後，我很快發現自己在意的不只是功能能不能完成，而是系統是否容易測試、資料是否一致、問題是否能被追蹤，以及半年後還能不能維護。

Manufacturing Systems

在製造業開發生產系統，是我真正理解「軟體有物理後果」的地方。SMT 上料錯誤不會只是資料庫裡一筆錯的紀錄，而是後段的不良品。設備會產出格式各異、編碼不一致的程式檔；現場需要的是掃一下條碼就能推進並驗證的流程，不是漂亮的表單。這些限制不是來自技術選擇，而是來自現場本身——而好的系統設計必須把這些限制當成輸入。

Backend

後端是這些限制最終被建模的地方：API 邊界、領域邏輯分層、資料一致性、驗證規則放在哪一層、什麼狀態是合法的。我習慣把「什麼是合法的」放在後端，把「現在可以做什麼」交給明確的狀態模型，而不是讓規則散落在畫面事件裡。

Data / Infrastructure

系統上線之後才是真正的開始。資料要從設備流到後端、CI/CD 要讓部署可重複、監控與日誌要讓問題可被發現而不是被猜測。我自己也維運一套 home lab，把 Prometheus / Grafana / Loki、MQTT 資料管線與容器化部署放在上面實作與驗證，因為可觀測性這種東西，只讀文件是學不會的。

AI Agents

現在我的重心是 AI 如何進入既有系統。我關注的問題不是模型分數，而是工程問題：Agent 該擁有哪些能力、介面應該切到多細、最壞情況能不能還原、哪些動作需要人的核准。這個網站本身就是這個問題的實驗場——它由 Claude Code 透過受限的 MCP 介面維護，Agent 能建立與發布頁面、管理 navigation，但沒有 shell、SQL 或使用者權限。

---

為什麼是跨領域

跨領域不等於每個領域都只懂一點。我的主軸一直是後端與系統設計，其他領域是因為「要把事情真的做出來」而必須理解的上下游。

實務上最常出問題的地方也很少在單一領域的內部，而是在交界：設備吐出的檔案編碼不對、資料格式在傳遞過程中語意漂移、CI 能跑但沒人知道部署到哪個版本、AI 能生成內容但沒人定義它可以改動什麼。這些問題需要有人同時看懂兩邊，並且願意在中間定義清楚的 interface。

Connecting software, data, machines and AI.

我的工程原則

常用技術