今日最有感的事

今天最有感的事，是第一次真的把 Kimi 的 WebBridge 用在自己工作流裡。

事情的起點很單純：我問 Claude「你可以像 Threads 一樣幫我貼 IG 嗎？我的帳號是 ecg_bear」。Threads 早就有現成的管線（自己寫的 threads-post skill 走官方 Threads API），所以那邊一句話就解決。Instagram 卻整個是另一個世界——要走 Meta Graph API、IG 帳號得是「專業帳號（商業或創作者）」、要綁一個 FB 粉專、要開 Meta App、要拿到一把帶 instagram_content_publish 權限的 token，光是把這條路念完就覺得頭很痛。

我接著說的那句話才是今天的關鍵：「你能不能處理完大部分的狀況，我只要在某個地方按允許就好了？」

過去 AI 的回答通常會變成一大段「請你去 developers.facebook.com → 選 App → 加權限 → 按 Generate Access Token → 把 token 貼回來給我」。那種回答的本質還是把 Claude 當顧問——所有手部動作仍然得 Bear 自己做。

今天不一樣的地方，是 Claude 直接掛上 kimi-webbridge 這個 skill，回答變成：

我直接操控你電腦上那個已經登入的 Edge 瀏覽器，一頁一頁開到定位、每一步截圖給你看，跟你說「現在按這顆」。輪到要登入或按「允許」時你按一下，其他我自己點。

然後它就真的開始做了。本機跑了一個 daemon 在 http://127.0.0.1:10086，Claude 用 navigate 開 Meta 開發者後台、截圖回給我看、抓頁面元素參照、點下拉選單選 app。我這邊的螢幕上是一個會自己動的 Edge——我已經登入的那個 Edge——它列出我帳號底下既有的 6 個 Meta app（Threads 那個、Agoodbear 那個都還在），Claude 自己決定挑 Agoodbear 來掛 IG 發文，避免污染現有的 Threads bot。

更具體一點：當 Claude 試圖組一條帶齊 IG 發文權限的 OAuth 授權捷徑、直接把我送到 Meta 授權頁時，那條 URL 被擋掉，原因是 Agoodbear 這個 app 沒把 facebook.com 加進允許網域。它沒卡住、也沒丟回給我處理，而是當場回退到 Meta 官方 Graph API Explorer 走它自家內建的授權流（那條 Meta 自己有開白名單），先把目前進度寫進一份檔案防斷線、再重新抓 app 下拉選單的位置繼續做。

這代表什麼？這代表「AI 操作你 session」這件事，從今天開始對我來說從抽象觀念變成具體工具。Kimi 模型本身強不強對我意義不大；真正關鍵的是 WebBridge 補上了過去最尷尬的那個缺口——有登入態的瀏覽器。任何 SaaS 後台、任何需要 OAuth 的開發者控制台、任何只有 webapp 沒 API 的服務，過去都是 AI 完全進不去的灰色地帶；現在只要本機有一隻 daemon 把你登入好的瀏覽器借出去，AI 就能接手。

真正值得我留意的是兩個落差。第一個是操作 vs 顧問的落差：我以前以為「把 Claude 當資深工程師問」就已經夠了，今天才感覺到中間還有一層「資深工程師願不願意直接坐到你電腦前面動手」的差距。第二個是信任邊界：daemon 跑在 127.0.0.1 看起來乖，但它操作的是我已經登入的 Edge——意思是 Claude 在這段 session 裡擁有我所有 cookie 的能動性。Threads bot 那種「我把 token 寫進 .env、Claude 拿 token 打 API」是有作用域的；WebBridge 是「Claude 直接代我」，這兩件事在資安心智模型上完全不同。

更直白地說：今天我多了一個能力——能請 Claude 幫我跑完那種「半小時的 GUI 雜活」，例如 Meta token、Google Cloud 專案設定、健保署 API 申請這類沒 CLI 的後台流程。代價是我得開始認真想：什麼狀態下我願意把已登入的瀏覽器借給 AI，借多久，借的時候有沒有人在旁邊看著。

Instagram 那條線今天還沒拿到 token（卡在重選 app + 逐類展開權限的繁瑣 dropdown），不過這個 session 對我來說最大的收穫已經拿到了——知道「下次再遇到需要 OAuth 的後台，我有 WebBridge 可以用」這件事。

今日收集的資源

Kimi 主站

Moonshot AI（月之暗面）官方

Kimi WebBridge 功能頁（繁中入口）

Kimi WebBridge 功能頁（簡中）

◆ ◆ ◆