那些沒有寫在
功能列表裡的決定

沒有完美的人機，但有完整的協作關係

OCR 隱私辨識會自動偵測畫面中的敏感文字，並自動標記需要遮蔽的區域。但開發過程中我們發現 OCR 仍有它的先天極限，偶有辨識不到或辨識錯的地方，但我們並不繼續 push 工具必須完美。

我想讓辨識錯誤不止於工具的失敗告終，而是成為協作的交接點。

我們讓隱私遮蔽的馬賽克變成浮動圖層，並可以調整範圍大小：OCR 沒蓋到的，使用者手動調整。辨識失誤從「錯誤」變成「待確認」，工具的不完美仍無損使用者的控制權。

OCR 可能只能完成自動化 90% 的任務，但使用者輕輕一拉手動馬賽克就可以完成本來 100% 都得自己手動的任務。

而且遮錯了也沒關係——馬賽克是獨立的浮動物件，undo 一鍵刪除。沒有任何結果是不可逆的。

QR Code 掃到了，但它有多確定？

掃 QR Code 這件事，表面上只有「掃到」和「沒掃到」兩種結果。但 VAS 不這樣看——它看的是使用者意圖，然後根據意圖決定下一步要做什麼。

這也是一種人機協作：使用者用截圖的姿態說話，工具讀懂了。不需要語言，不需要按鈕，不需要選單——你怎麼框，就是你想要什麼。工具在讀的不是指令，是行為語言。

我們判斷當使用者想精準偵測 QR Code 時，自然會盡可能在選取框中完整而且僅有框 QR Code——這個動作本身就是意圖的宣告。QR Code 被框得佔選取區域越大，辨識越準，信心度越高，工具越能直接行動。使用者與工具之間，形成了一種不需要言語的默契。

也因為意圖在框選範圍的瞬間就已經明確，QR Code 偵測直接在工具列的矩形截圖工具觸發，不需要進入編輯器才能操作。工具在最早的時間點行動，不讓你多走一步。

工具不應該在自己不確定的時候假裝確定。確定你要 QR Code，就直接行動開啟連結；信心度模糊，就先問你是否要開啟連結；信心度太低，靜默開啟編輯器交給你判斷。每一個閾值背後，都是一個「我知道自己知道多少」的誠實設計。

QR Code 佔框選面積對應行為邏輯：

實際操作示意

呼吸燈讀懂你的意圖，再開口問你

VAS 的呼吸燈不只是等待的象徵——它在偵測環境。當使用者複製了一個網址靠近，呼吸燈會輕輕詢問：「要幫你截這個網頁嗎？」使用者同意，截圖完成，編輯器打開。

這個設計源自一個觀察：原本的網頁截圖流程需要複製網址 → 呼叫工具列 → 按截圖 → 貼上網址——四個步驟，全部是「為了工具而做的事」。但使用者複製網址，是為了他自己的事，不是為了 VAS。

而當使用者帶著一個檔案靠近呼吸燈時，呼吸燈就會像張開雙手擁抱檔案一樣，張開工具列收納檔案並立刻展開編輯器，等待使用者下一步的操作。

最好的工具不讓你切換到「工具模式」。它待在你的環境裡，讀懂你在做什麼，然後再用行動回應。

設計手稿

最終實作

擺好 pose 在那邊等，工具不應該叫你回來選

當我們開發出了「延遲截圖」後，全螢幕截圖功能在雙螢幕模式時提供的 Apple 原生選單反而變成了摩擦力。

延遲截圖是為了捕捉滑鼠事件——報錯狀態、hover 效果、debug 瞬間而誕生的功能。使用者設定倒數等待時，滑鼠必須留在螢幕的某個角落。但原生的雙螢幕選單在讀秒結束後，卻會從工具列跳出來要求使用者在截圖前先回去工具列選擇要截哪個螢幕——就像你自拍已經設定好相機秒數，結果相機結束讀秒時卻在預覽螢幕問你「你要拍哪邊？」一樣荒謬。

VAS 捨棄 Apple 原生選單，改用自製圖層遮罩覆蓋全螢幕：沒有延遲時點哪個螢幕就截哪個，按 Enter 直接合併成雙螢幕截圖。

更進一步：當使用者設了延遲規則，VAS 會默認截取滑鼠當下所在的螢幕——連選都不用選，工具自己判斷。使用者根本不會意識到這個決策在背景發生過。

功能可以一直加，但底層要先說同一種語言

當工具種類越來越多——點、線、面、文字、符號——每個物件都有顏色、線條、大小、方向這些屬性。如果每個工具各自管自己的屬性，加功能就是更多的技術；但如果這些屬性是共享的、模組化的，改一個地方，全體同步，而Electron VAS也能無痛renew。

Tauri VAS 的重構計畫已於 04/14 正式完工，歷時四天（04/11–04/14）、11 個 Sprint，走過六個架構面向：座標系統統一、漸層系統整合、資料模型規範化、TOOL_SCHEMA 屬性面板框架（覆蓋全 10 種工具）、幾何邏輯與渲染管線重寫、Undo/Redo 記憶體管理。

比起開發前期卯起來加功能，VAS 這次停下腳步整理自己的代價是：四天、11 個 Sprint。地基穩了，之後疊加新的功能才不會與現有功能打架或浪費時間在 Debug。

這次重構也連帶讓 Electron 版受惠——底層統一，兩個平台都跑在同一套邏輯上，穩定性自然提升。Electron 雖然不再新增功能，但也需保持功能完整、免費、穩定，讓使用者有機會先信任 VAS，再決定要不要升級 Tauri。一次重構，把整個雙平台長期營運策略都撐起來了。

完工後才知道的事：地基工程的時間很難精準估算。重構啟動前預估 Sprint 10–13 完成，結果一路跑到 Sprint 20——理想與現實的差距，本身就是工程的一部分。追到底才知道：座標系統的位移問題根源在初始化時序，不在換算邏輯；TOOL_SCHEMA 的設計方向從一開始就對了，10 種工具套進去，沒有任何例外情況。當工具都說同一種語言，連 Debug 本身也變清晰了。