為什麼 Remote Engineering 應該變成工程師的常態？今年開始，我愈來愈常用語音的方式寫規格。
不是自己一個字、一個字慢慢輸入 prompt，而是直接把想法講出來，再透過 LLM 幫我整理成規格。
尤其是規格這種東西，你腦中可能已經有完整的畫面，但要把每一個條件、流程、例外狀況全部打成文字，真的非常花時間。現在只要透過 Typeless，或其他帶有 LLM 整理能力的語音輸入工具，就可以先把整段想法講完，再讓它幫你整理成有標題、有層次、有格式的內容。
對我來說，這不只是輸入速度變快而已。它改變了整個開發方式。
語音輸入完成之後，就可以透過各種 Remote Control Agent，例如 Claude Code Remote Control，或是我自己使用的 OpenClaw 龍蝦這類遠端控制工具，把規格送回本地端的開發機器執行。
這代表你不一定要一直坐在電腦前面。你可以在外面走路、搭車、整理家裡，甚至只是在沙發上躺著，把需求講清楚之後，遠端的機器就可以開始工作。
真正困難的地方：你要怎麼在遠端看到結果，以及完成 Debug 和驗證？
網頁
如果開發的是網頁，這件事情已經非常簡單。
你可以透過 Tailscale 連回開發機器，直接查看本地端正在執行的網站；也可以用 Tailscale Serve，把本地的開發服務分享給自己 Tailnet 裡的其他裝置。只要開發機器還在線上，你在外面一樣可以直接打開網站、操作功能、確認結果。
Mobile App
Mobile App 也有幾種做法。
- 讓實體手機一直插在開發機器上。 只要把開發機器和手機設成 Always On，Agent 就可以透過 Command Line 建置、安裝 App，並搭配相關工具截圖、取得 Log，甚至執行部分操作
- 直接使用 Simulator。 iOS Simulator 本身就可以透過
simctl指令截圖與錄影。Agent 執行完一段功能後，可以直接產生截圖或影片，再把結果傳回來給你驗證 - 把測試版本送到 TestFlight / Firebase Distribution。 這比較不像即時 Debug，而是每完成一個可以驗收的版本，就自動 Build、上傳，再讓你直接從手上的手機安裝測試。你人在外面，也可以拿真實裝置查看完整結果
所以 Mobile App 的遠端開發流程，可以變成：
語音講規格 → Agent 在遠端開發 → Simulator 截圖或錄影 → 實體機器執行驗證 → TestFlight / Firebase 發佈測試版本 → 手機查看結果
實體硬體
那實體硬體呢？其實概念也是一樣的。
先把硬體全部接好，讓開發機器、測試設備和必要的線路維持連線。接著，替這套設備設計一些可以被 Agent 呼叫的 Protocol 或 Skill，例如：讓它讀取設備狀態、執行指定操作、取得 Log、控制測試流程，或者透過攝影機截圖和錄影。
社群上已經有各路大神在開發相關的遠端控制硬體開發的 Skill。只要 Agent 能操作，結果又能用某種方式回傳，就可以在遠端 Debug。
核心其實都一樣
換句話說，不論是網頁、Mobile App，還是實體硬體，核心其實都一樣：
把原本需要人坐在機器前面做的操作，轉換成 Agent 可以呼叫的工具；再把原本需要人親眼確認的結果，轉換成截圖、錄影、Log 或測試報告。
當這兩件事情完成之後，整個開發迭代就可以遠端進行。
我覺得這是 2026 年非常重要的一種開發方式。只要把需求講出來，遠端的機器就可以開始開發。在等待執行的過程中，你可以去做其他事情；等它完成之後，再透過手機驗證結果，指出問題，讓它繼續修改。
這和以前所謂的 Remote Work 不太一樣
以前的 Remote Work，只是把你從公司的電腦桌，搬到家裡的電腦桌。
但 Remote Engineering 是讓你逐漸離開電腦桌。
你不需要一直盯著 Terminal，也不需要一直守在 Build 前面。你的工作會愈來愈集中在幾件事情上：把需求講清楚、決定下一步、檢查結果，以及處理那些目前仍然無法被遠端化的實體摩擦。
所以到最後，Remote Engineering 真正剩下的限制，可能只剩下那些必須親手處理的事情：插線、重開機、移動設備、更換零件，或者處理某些只能在現場重現的狀況。
也許等未來某一天，機器人也發展得夠成熟，連這些事情都可以被遠端控制。到了那個時候，Remote Engineering 的最後一點實體摩擦，可能也會被彌平。
工程師真正需要 On-site 的時間，或許就只剩下處理人與人之間的關係。
剩下的時間，都可以拿回來，塞進更多自己真正想做的事情。