我把戒指變成 Samsung TV 遙控器：Ring Remote 從想法一路改到 V1.1.13

我原本以為，這會是一個很直覺的小工具。

戒指往下滑，電視游標往右；往上滑，游標往左；點一下就是選擇。需要上下移動時，再切換一次模式。Samsung TV 本來就能透過 SmartThings 控制，只要把戒指的手勢和電視遙控器的按鍵接起來，應該就完成了吧？

真正做下去之後，我才發現，「上下左右」只是使用者最後看到的四個字。它的背後還隔著智慧戒指、智慧眼鏡、手機上的 Even App、EvenHub Plugin、自己的後端、SmartThings OAuth、Samsung TV 的能力差異，以及真實網路中每一段都可能發生的延遲和誤判。

Ring Remote 就是在這些看似瑣碎、實際上環環相扣的問題中，一路改到 V1.1.13。

目前狀態（2026 年 8 月 20 日）： 軟體、測試、正式套件與後端路徑已完成；真實 R1、G2 與 Samsung TV 的 30 分鐘連續穩定性驗收仍待完成。這篇文章記錄的是已經發生的開發與實測，不把「程式通過」寫成「產品已正式完成」。

先看目的、成果與證據邊界

這三格是我現在寫 AI 實作文章時最重要的分界：想做什麼、實際證明了什麼，以及還不能說自己完成了什麼。Ring Remote 的故事很長，但所有細節最後都要回到這三個問題。

我真正想做的，不是 Netflix 專用遙控器

這個點子一開始很容易被理解成「用戒指控制 Netflix」，但我很快就把產品方向定清楚：Ring Remote 應該是 Samsung TV 的通用導航遙控器，Netflix 只是其中一個相容性場景。

真正的第一關不是快轉或倒轉，而是在 Samsung Home 能不能穩定完成：

• 左、右、上、下
• 選擇
• 返回上一頁

如果連電視首頁都無法穩定導航，即使 Netflix 偶爾能暫停，也不能算是一支好用的遙控器。這個決定後來很重要，因為它讓開發不會被單一影音 App 的介面行為牽著走，也讓 YouTube、設定選單和其他接受標準方向鍵的畫面能沿用同一套操作。

戒指並不是直接連到電視

Ring Remote 的正式路徑，其實是這樣：

R1 戒指或 G2 眼鏡手勢
→ Even App 裡的 Ring Remote Plugin
→ Ring Remote HTTPS 後端
→ SmartThings Cloud
→ 已選定的 Samsung TV

我沒有採用戒指直接藍牙連電視，也沒有使用非官方的 Samsung 區域網路遙控協定。原因很簡單：第一版要先建立可維護、可授權，也能在不同網路環境中工作的正式路徑。

Even 官方文件說明，G2 的 Plugin 本質上是跑在手機上的網頁應用，眼鏡負責顯示與接收輸入；R1 和 G2 都提供點擊、雙擊、上滑與下滑等手勢。SmartThings 則提供標準裝置命令介面，讓後端可以依電視實際支援的 capability，把抽象的 RIGHT、BACK 等動作轉成正式命令。

這個架構也帶來一條不能妥協的安全界線：SmartThings 的 Client Secret、Access Token 和 Refresh Token 只能留在後端，不能被包進 .ehpk，也不能送到手機 Plugin。

第一個大魔王不是手勢，而是「怎麼連上」

開發前半段，我花了很多時間在一個使用者根本不會想看到的地方：設定與授權。

我先後遇過這些畫面：

• Restart Ring Remote to create a setup session
• NETWORK_UNAVAILABLE
• NETWORK_HEALTH_UNAVAILABLE
• 按下 SmartThings 授權後只剩一片空白
• SmartThings 顯示無法完成 authorization
• 已經授權，卻找不到相容的 Samsung TV
• 更新 .ehpk 後，手機裡還是舊版本

其中一個最容易誤判的情況是：同一個後端網址用 Chrome 可以正常看到 JSON，不代表 Even App 裡的 WebView 就一定能連線。

EvenHub 的網路連線同時受到 Plugin manifest 的網域白名單和後端 CORS 規則限制。網址少列一個、來源不完全相符，或舊版 WebView 對 fetch 的支援不同，都可能讓瀏覽器測試正常、Plugin 卻只顯示 NETWORK ERROR。

後來我把「建立設定工作階段」、「開啟 SmartThings 授權」和「回到 Ring Remote 完成選擇」拆成可以恢復的步驟，也參考了公開的 EvenSmartThings 社群專案，確認這條產品路徑在真實環境中可行。它是實作參考，不是 Ring Remote 的平台規格來源；正式行為仍以 Even 與 SmartThings 官方文件為準。

這個階段教會我的第一件事是：跨平台整合裡，能打開網站只代表第一跳活著，不代表整條流程可用。

終於連上電視，卻還不是一支能用的遙控器

第一次真的連上 Samsung TV 時，我原本以為最難的部分已經過了。實際操作後，問題反而變得更具體：

• 播放影片時，單擊會先暫停，接著又立刻播放。
• 左右滑看起來像在移動 Plugin 畫面，不像控制電視。
• 雙擊雖然顯示切換模式，卻很快又跳回 Browse。
• 上下與音量沒有作用。
• R1 漸漸順了，換成 G2 時雙擊又無法切換模式。
• 用得越久，控制越容易失去反應。

這些問題很難只靠模擬器發現。程式可以收到手勢、後端可以回 HTTP 200、SmartThings 也可以回傳 ACCEPTED，但眼前的電視仍然可能完全沒動。

SmartThings 的官方文件特別說明，ACCEPTED 只表示命令已經排入執行，不表示裝置已經完成動作。這個差異後來成為整個專案最重要的驗收原則：

API 說成功，不等於電視真的動了。

因此每次修正都要分成兩種證據：程式與測試能證明什麼，以及人在真實電視前面實際看到了什麼。兩者不能互相冒充。

最關鍵的一次修正：畫面和輸入不能是同一層

有一版最令人困惑：眼鏡上的文字會隨著手勢晃動，但電視沒有反應。

問題不是 SmartThings 根本沒收到正確按鍵，而是顯示操作說明的畫面本身也在吃滑動事件。使用者以為自己正在對電視送出 LEFT 或 RIGHT，實際上只是把眼鏡中的介面捲動了一點。

最後的解法不是再調整 API，而是重新切開畫面與輸入：

• 可見的操作提示改成不互動的 bitmap HUD。
• 另外建立專門接收手勢的事件層。
• 畫面只負責告訴我目前是 Browse 還是 Vertical。
• 輸入層才負責把手勢送進狀態機。

這次修正之後，左右與上下控制才真正開始像一支遙控器，而不是一個會被自己手勢捲動的網頁。

為什麼模式會自己跳回去？

第二類問題來自點擊判斷。

單擊和雙擊不是兩個完全獨立、同時就能知道答案的事件。當第一次點擊發生時，系統必須短暫等待，確認使用者會不會再點第二下。如果太快把第一次點擊送成 SELECT，後面收到雙擊時，就可能同時發生「選擇」與「切換模式」。如果裝置或韌體又送出重複事件，同一次雙擊甚至可能切過去又切回來。

Ring Remote 最後加入幾個明確的時間邊界：

• 120 毫秒內的相同事件，視為可能的韌體重複包。
• 單擊等待 300 毫秒，再決定是否真的送出。
• 已接受的雙擊在 700 毫秒內不重複切換。

這不是為了追求漂亮的數字，而是為了解決實際看見的行為：單擊不能變雙擊，雙擊不能切兩次，錯誤或延遲也不能偷偷把目前模式改回去。

R1 可以，為什麼 G2 又不行？

R1 逐漸順暢之後，換成 G2 測試又遇到一個很典型的跨裝置問題：兩者看起來有相同手勢，但實際送到 Plugin 的事件包不一定完全相同。

部分 G2 的正式 typed event 沒有帶出可用的 eventSource。如果程式堅持「沒有來源就不要接受」，雙擊看起來就像完全沒發生；但如果所有沒有來源的資料都當成點擊，又可能讓格式不完整的事件誤觸電視。

最後的做法是只接受 SDK 已明確定義的手勢類型；如果是合法的滑動或雙擊、只是沒有來源，就標記成 UNATTRIBUTED，而不是假裝它一定來自 R1 或 G2。同一個實體動作若同時產生有來源與無來源的兩份事件，也會先合併，避免切換兩次。

這讓 R1 和 G2 最後可以共用同一套狀態機，同時保留事件來源不確定時的誠實邊界。

用久了失效，問題可能不在手指

我還發現一個很惱人的現象：剛開始可以操作，用得越久卻越容易失去反應。

這類問題很容易被歸因於「手勢沒滑好」，但實際追蹤後，至少有兩個程式層原因：

第一，手機切到背景或鎖定時，Even App 的生命週期事件可能讓命令佇列暫停。穿戴裝置仍然戴在身上，使用者也沒有退出 Ring Remote，但後端派送卻已經停止。

第二，某個 SmartThings 請求逾時後，如果沒有真正中止並等待它結束，下一個命令可能搶先執行，甚至讓控制佇列進入不穩定狀態。

後來的版本把「手機進入背景」和「使用者真的退出」分開處理。進入背景時只取消尚未判定的單擊，不停止 R1／G2 的 TV 控制；命令則使用有上限、有過期時間、可中止且保持順序的佇列。就算某次網路失敗，下一次新的操作仍然必須有機會恢復。

這也是為什麼 Ring Remote 後來加入不含帳號與裝置識別資料的暫時診斷資訊：不是要監看使用者，而是要分辨問題發生在手勢判斷、排隊、後端，還是 SmartThings 回應時間。

我最後砍掉了第三個模式

Ring Remote 曾經設計過第三個 Playback 模式，用來處理播放／暫停、快轉、倒轉，也測試過音量控制。

實際使用後，我決定把它拿掉。

原因不是這些功能完全沒有 API，而是「有 capability」和「在所有電視、所有 App、所有播放狀態下都直覺可靠」是兩回事。以 YouTube 為例，左右鍵有時是切換畫面選項，不一定是調整影片進度。要自動判斷目前是否正在播放、使用哪一個 App，以及應該送方向鍵還是影音命令，也不是每台 Samsung TV 都能提供足夠一致的狀態。

第三個模式讓操作更難記，雙擊切換也更容易讓人不知道自己現在在哪裡。既然我真正需要的是日常導航，最好的產品決定不是再加一層判斷，而是刪掉它。

最後只留下兩個會持續存在的模式：

模式只會在我明確雙擊時切換，不會因為命令成功、失敗、逾時或畫面更新而自己跳回。Vertical 裡的單擊是送出電視的「返回上一頁」，不是回到 Ring Remote 的上一個模式。

把第三個模式砍掉之後，Ring Remote 才從「功能很多的實驗」變成「比較有機會記得住的遙控器」。

戒指明明能長按，為什麼程式沒有用？

開發過程中還出現一個需要修正的誤會：我知道自己的 R1 戒指可以長按，早期設計卻一度說它不支援。

後來重新查官方資料，R1 硬體確實支援按住一秒，官方用途是開啟系統 Menu。真正的限制不是戒指不能辨識長按，而是當時檢查的 EvenHub Plugin SDK 沒有提供一個獨立的 LONG_PRESS 事件，讓第三方 Plugin 可以安全地把它改成 TV 功能。

因此 V1.1.13 沒有把長按綁成電視按鍵。這是 SDK 與系統保留手勢的邊界，不是硬體能力不存在。這個更正也提醒我：使用者手上的真實產品經驗，不能因為程式介面沒寫出來就被否定。

AI 寫得出程式，但替代不了我站在電視前面

Ring Remote 的大量程式、測試、文件與錯誤隔離，是我和 AI 反覆協作完成的。AI 很適合做這些事情：

• 整理官方 SDK 與 SmartThings 文件。
• 把手勢邏輯拆成可測試的狀態機。
• 為 OAuth、能力探索、命令排序與錯誤恢復建立測試。
• 在缺少實體裝置時先用 adapter、mock 和 simulator 繼續完成其他工作。
• 把每次實機失敗轉成下一版的 regression test，避免同一個問題再次出現。

但真正改變產品方向的資訊，幾乎都來自人在硬體前面的感受：

• 「看起來是在捲動畫面，不是在控制電視。」
• 「雙擊後只切換一下，又馬上跳回去。」
• 「R1 已經順了，但 G2 不能切模式。」
• 「第三頁太難成功，我不想要了。」
• 「戒指明明可以長按。」

如果沒有這些回報，測試很可能一直是綠色的，產品卻仍然不好用。

所以我現在對 AI 開發的理解，不是「把需求交給 AI，它就會變成產品」，而是把工作重新分配：AI 負責大量可重複的查證、實作、測試與紀錄；人負責感覺摩擦、辨認錯誤的產品假設，並決定什麼功能值得留下。

V1.1.13 完成了什麼，還沒完成什麼？

截至這篇文章整理時，V1.1.13 已經完成：

• R1 與 G2 共用的兩模式手勢邏輯。
• Samsung TV 的官方 SmartThings 控制路徑。
• Backend-only 的 OAuth 與 Token 保存方式。
• 分離顯示與輸入的眼鏡 HUD。
• 可恢復、維持順序並限制延遲的命令派送。
• 對重複事件、單擊／雙擊衝突、背景切換與網路逾時的回歸測試。
• 可驗證、不包含密鑰的正式 .ehpk 套件。

但我不會把它寫成「已經完全完成」。目前仍需要安裝同一份 V1.1.13 正式套件，分別用 R1 與 G2 在 Samsung Home 驗證 Browse、Vertical 和模式切換，接著完成 30 分鐘不中斷的混合操作，觀察手機鎖定、背景切換、實際電視反應與延遲。

這個狀態在專案裡被明確寫成：

SOFTWARE_COMPLETE_PHYSICAL_ACCEPTANCE_PENDING

軟體完成，實體驗收待完成。這句話不漂亮，卻比「大功告成」更接近真實開發。

這次開發留給我的三個結論

1. 看起來最簡單的功能，常常跨越最多系統

使用者只想滑一下，但這個動作可能跨過韌體事件、WebView、手機生命週期、後端、OAuth、雲端 API 和真實裝置。介面越簡單，背後越需要把複雜度藏好。

2. 刪掉功能，也是重要的開發成果

第三個模式不是做不出來，而是它沒有讓產品變得更好用。把 Playback 與 volume 留在相容程式裡、卻不讓穿戴手勢碰到它們，是比勉強塞進操作流程更成熟的選擇。

3. 實體產品的最後裁判永遠是實體體驗

測試、HTTP 200、SmartThings ACCEPTED 和套件驗證都很重要，但它們只能證明各自負責的那一段。最後還是要看電視有沒有動、手勢有沒有被正確理解，以及半小時後它是否仍然可靠。

Ring Remote 還沒有走到故事終點，但它已經從一個「應該不難吧」的點子，變成一個能清楚說明架構、限制、失敗與下一步的產品原型。

而對我來說，這次最大的收穫也許不是多了一支遙控器，而是更具體地學會：怎麼和 AI 一起，把真實世界裡那些不按文件走的問題，一個一個找出來。

官方資料與延伸閱讀

• Even Hub：Overview and architecture
• Even Hub：Networking
• Even Support：R1 How to Control
• SmartThings：Control Devices
• SmartThings：Production Capabilities
• EvenSmartThings：公開社群參考實作

商標說明：Samsung、SmartThings、Even Realities、Even G2、Even R1、Netflix 與 YouTube 為其各自權利人的商標或產品名稱。本文僅以描述相容平台與實作過程的方式使用，Ring Remote 並非上述公司的官方產品或合作專案。