今天一整天最反覆用到、也最值得記下來的，是 Kimi WebBridge 這個工具。它一天之內在兩件完全不相干的事上都上場了：登入綠界金流後台、還有幫忙抓付費的醫學論文。有趣的是——它成功的地方跟失敗的地方，剛好把「讓 AI 直接開我的瀏覽器」這件事的邊界劃得清清楚楚。

今日最有感的事

先補個背景給非工程師讀者：Kimi WebBridge 是 Moonshot（Kimi 背後那家公司）做的功能，它會在你自己電腦上跑一個小服務（掛在 127.0.0.1:10086 這個本機位址），然後用「你本人那顆已經登入好的真實瀏覽器」去代你操作。這代表它跟一般 AI 開一個乾淨無痕視窗很不一樣——它動的是帶著你全部登入 cookie 的那個 Chrome。好處很明顯：凡是需要「我的身分才能看到的頁面」，它理論上都能進得去。

今天第一個用途是綠界後台。ECPay 的信用卡與非信用卡收款審核今天早上剛通過，接著就是要進廠商專區把三組正式金鑰（MerchantID、HashKey、HashIV）抄出來設進部署環境。這種「先登入、再進 iframe 框架、再翻選單找系統介接設定」的流程，正是 WebBridge 的強項——它幫忙填了帳號跟圖形驗證碼，只把密碼、身分證末四碼這種敏感個資留給 Bear 自己出手。這一段它做得很順。

真正撞牆的是第二個用途：抓三篇付費的 OMI ECG 論文。Bear 有機構（陽明交大）的期刊存取權，所以原本的算盤是——既然 WebBridge 用的是我登入好的瀏覽器，那它應該能直接把付費 PDF 下載下來，省掉一堆驗證關卡。結果一連三個操作全部回同一個錯誤：Cannot access a chrome-extension:// URL。換頁、重選分頁都沒用，連拿一個空白的 example.com 測試都附不上。

問題的根因很值得記下來：當你在 Chrome 裡點開一個 PDF，Chrome 是用它內建的 PDF 檢視器顯示，而那個檢視器本身就是一個 chrome-extension:// 頁面。WebBridge 的除錯器（它用來「附著」到分頁去操作的機制）依設計就無法掛到這種擴充頁面上。更直白地說：WebBridge 天生抓不了「已經在 Chrome 檢視器裡打開的那份 PDF」。這不是哪一篇文章擋它，是一條全域的硬邊界。

真正值得看的是最後怎麼收尾——不是靠更聰明的自動化，而是 Bear 人已經站在那份 PDF 上，直接按 Cmd+S 存到 Downloads，兩篇馬上就進來了。這件事把工具的性格講得很透：一個「借用你登入態」的瀏覽器自動化，在正常網頁（登入頁、後台主控台、iframe 選單）上非常有力；但它會剛好斷在瀏覽器自己的內部介面上，而 PDF 檢視器就是那個介面。它搞得定看起來很難的綠界 iframe 後台，卻搞不定看起來最簡單的「抓我眼前這份 PDF」——這個反差，才是今天最有感的一課。給自己的提醒是：下次要用它抓文件前，先想清楚目標頁到底是「網頁」還是「擴充頁面」，這一格分類就決定它能不能動。

今日收集的資源

Kimi WebBridge 功能頁

Kimi 官網

Moonshot AI 官網

Google 文件

◆ ◆ ◆