微軟 Skill Recorder：
錄得到的，比用得到的多

摘要

一、聽起來很有用

Skill Recorder 的第一句自我介紹寫得非常好：

這句話戳中的痛點很真實：寫技能檔案的困難從來不是格式，而是把腦子裡的默會流程翻譯成文字。你知道怎麼做，但要一步一步寫下來很累，而且常常漏掉自己習以為常的判斷。用「做一遍」取代「寫一遍」，直覺上確實省事。

四個階段

1. 錄製：按下錄影鍵（⌘⇧R 或 Ctrl+Shift+R），照常做你的任務，程式在背景於本機擷取畫面與活動。
2. 控制：錄製期間有一條常駐最上層的小工具列，顯示擷取與麥克風狀態，可即時靜音、換麥克風、結束或捨棄這一次。
3. 分析：按下 Analyze，GitHub Copilot 重建出一個整體意圖與一串有序步驟，你可以審閱與修改到讀起來正確為止。
4. 建立：從審過的分析結果，產生可重複使用的 Skill 或排程用的 Automation。

真正聰明的那一句設計原則

它不是傳統的 RPA 錄製器。README 明講兩種產出都會：

這是整個專案最有見地的一句。它承認了一件業界花了二十年學會的事：模擬滑鼠點擊很脆——版面一改就壞、慢、貴、出錯難查。所以錄影在這裡不是要照著演一遍的腳本，只是拿來反推意圖的素材。你在瀏覽器上點了半天 GitHub，它產出的步驟可能直接是「執行 gh pr list」。

記住這句話。它同時也是後面那把剪刀的其中一片刀刃。

二、實際上要怎麼用？前半段很清楚

先講清楚的部分。安裝方式相當特別：它沒有提供編譯好的安裝檔。

官方稱之為「原始碼發行」（source release）：你到 Releases 頁複製對應平台的指令，該指令會下載一個固定版本的 Node.js 執行環境，在你自己的機器上編譯該版本的原始碼，然後建立一個「Skill Recorder (Source)」應用程式。macOS 會裝進 ~/Applications，Windows 會建立桌面與開始功能表捷徑，Ubuntu 會加一個應用程式項目。整個過程不做任何全域安裝。

每個 release 會把安裝腳本與要編譯的原始碼都釘在同一個 40 字元的 commit 上，這點做得嚴謹。不過實務上你仍是在把一段 curl 下來的腳本直接餵給 bash；官方也知道這件事，所以文件裡特別留了「想先檢視腳本再執行」的說明頁。

接著錄製也很清楚：首次啟動時 macOS 會要求螢幕錄製權限，授權後即可錄。第一次按 Analyze 時，若尚未登入會出現「Sign in to Copilot」。你需要一個具備 Copilot 存取權的 GitHub 帳號，Copilot CLI 本身隨應用程式附上。若要使用旁白功能，首次會下載約 252 MB 的 Whisper 模型，之後轉文字都在本機完成，支援 99 種語言。

然後文件就斷了

從「產生了一份 Skill」到「這份 Skill 在哪裡執行」之間，README 沒有任何說明。

這不是印象，是可以驗證的：這個專案的倉庫描述（repo description）寫著產出可供 Microsoft Scout、Microsoft Copilot Cowork 或 Copilot Studio 使用，但 README 全文零次提到這三個名字中的任何一個。倉庫裡的說明文件也只有安裝、發行流程、評測框架與 Windows 擷取細節，沒有一份講輸出去向。

三、翻開原始碼：三個目標，沒有一個能碰原生 App

答案藏在 electron/architectures/catalogues/ 這個目錄。裡面有三個檔案，每一個都是一份「目標能力清單」——一段直接內嵌進 Copilot 系統提示的文字，用來告訴它：你產出的技能可以依賴哪些能力。

換句話說，這三份檔案就是這個工具對世界的假設。全部只有三個目標：

通用目標：明文禁止瀏覽器自動化

通用的 agent-skill 目標刻意不列出任何專屬工具，好讓產出的技能能載入到使用者選擇的任何代理。代價是它只准依賴「每個代理都合理具備」的能力：

Cowork：一句寫進系統提示的自白

Cowork 目標的能力清單極長，Teams、Outlook、日曆、SharePoint／OneDrive、組織目錄、Power BI 一應俱全，也明確要求「GitHub 一律走 gh CLI，絕不要用瀏覽器操作 github.com」。但在工具清單最後，有這麼一段：

最後那半句值得停下來看一次。微軟在自家產品的系統提示裡，預先寫好了失敗時的措辭。這是一份非常誠實的文件，同時也是一份非常清楚的能力聲明。

Scout：唯一能點 UI 的，但只限網頁

Scout 是三者中唯一有瀏覽器自動化的：它列出 browser_navigate、browser_snapshot、browser_click、browser_type、browser_fill_form 等 Playwright 工具，但定位講得很小心——「UI 後備方案，只給那些沒有 API 也沒有 CLI、非得從 UI 操作不可的網頁應用程式（GitHub 不算，請用 gh）」。

注意兩件事。第一，仍然是網頁，Playwright 碰不到 Windows 視窗程式。第二，Playwright 開的是乾淨的瀏覽器設定檔，沒有你的登入狀態——這對需要登入的內部系統是個現實問題。

於是核心矛盾成立了：它錄整個桌面，包含 Excel、終端機、各種原生應用程式；但它三個輸出目標沒有一個能重播原生 App 的操作。錄得到的，遠多於用得到的。

四、那什麼情況下真的有用？

判準其實只有一條，而且可以在錄影之前就先問自己：

五、把兩件事並排看，價值就被夾掉了

前面的觀察各自都只是缺點。但把兩片並排，會發現它們是一把剪刀：

這個判斷跟「產品還不成熟」無關。就算微軟明天把文件補齊、把 Copilot Studio 接上，這把剪刀還是合的——除非他們讓 computer use 成為輸出目標，而那等於承認「優先用原生工具而非重播點擊」這個核心主張失敗。

它最漂亮的那句設計原則，正是殺死它自己的那句。

還有第三刀：繞了一圈回到原點

它唯一還算通用的產出，是一份 SKILL.md——帶 name、description、allowed-tools 欄位，格式與 Claude Code 的 Agent Skills 相同，不進微軟生態也能用。聽起來至少還算個「技能草稿產生器」。

但請注意是誰生出這份檔案的：GitHub Copilot。你本來就能直接叫它寫。

於是整個工具的淨貢獻，是在「跟 AI 說一句話」和「AI 寫出一份技能」之間，插入了螢幕錄製、雲端上傳，和一次影片理解。

六、那，更好的形狀會長什麼樣？

把前面的問題倒過來看，答案其實自己浮出來：

• 錄影之所以必要，是因為 AI 不在現場。那讓它在現場就好了。
• 重建之所以必要，是因為 AI 沒做過那件事。那讓它自己做一遍就好了——做過的人不需要猜自己的意圖。
• 上傳之所以必要，是因為理解影片得靠雲端。沒有影片，就沒有要上傳的東西。

一個 AI 能直接操作、而你同時也看得見的介面：你示範一次，它自己試一次，點錯了你當場說「那個欄位不用填」。這不就是帶新人嗎。兩三輪之後它會了，把流程寫下來，之後交給程式跑——AI 就可以退場了。

AI 只該出現在第一次。

這條路我們正在走，走完再另外寫一篇。

常見問題（查證日期：2026-08-07）

結論

Skill Recorder 沒有解決任何人的問題，但它把問題的形狀畫得很清楚：真正需要自動化的系統，都是那些沒有 API 的系統；而「沒有 API」正好也代表沒有東西能替你執行。

微軟這一版選擇了「翻譯成原生工具」而不是「重播點擊」——這個選擇在工程上是對的，在市場上卻剛好避開了所有痛點。它承接得了那些你本來就有指令可下的任務，卻承接不了那些你只有滑鼠可用的任務。

所以這不是一個失敗的產品，是一份寫得很誠實的問題說明書。誠實到它在自家的系統提示裡預先寫好了「如果真的必須操作 UI，就在技能裡直說，不要假裝點得到」。

值得追蹤的是下一步：如果哪天 Copilot Studio 的 computer use 出現在那個 catalogues/ 目錄裡，代表微軟決定讓 AI 留在迴路裡點滑鼠。如果沒有，代表他們仍然相信 AI 只該負責翻譯，執行交給程式。那個目錄裡有沒有多一個檔案，就是答案。