Iris讓AI編碼代理看見執行中的Web應用

如果你用過 AI 編碼助手寫前端程式碼，大概遇到過這樣的尷尬：AI 生成的元件看上去沒問題，但實際渲染後佈局全亂；或是一個 API 呼叫沒生效，AI 卻毫不知情。傳統思路是讓 AI 截圖分析，但截圖既耗 token 又缺乏結構化資訊——它看不懂控制檯報錯，也抓不住具體的 DOM 節點。

Iris 就是為解決這個問題來的。它是一個開源工具，基於 MCP（Model Context Protocol），可以看作給 AI 編碼代理裝了一雙「眼睛」，讓它直接「看」到你的 Web 應用里正在發生什麼——API 呼叫了沒有、DOM 變更了什麼、控制檯有沒有報錯、路由跳轉是否正確。而且它不是用截圖，是用確定性的斷言（assertions）來驗證，有效且高效。

為什麼截圖不夠好？

AI 編碼代理（比如 Cursor、GitHub Copilot 的 agent 模式）要理解執行中的應用狀態，以往的解決方案是截一張全頁面快照，然後把圖片餵給模型。但一張截圖可能包含大量無關資訊，而且視覺模型識別 UI 元素後還需要推理，token 消耗巨大，反饋也慢。Iris 的做法更聰明：它直接暴露應用內部的結構化狀態，以文字形式傳給模型。根據官方資料，同等場景下 Iris 消耗的 token 只有全頁面快照的 1/73 左右。這點對按 token 付費的開發者尤其友好。

Iris 的核心能力

我粗略試用了一下，Iris 主要圍繞這幾個場景提供能力：

• 驗證 API 呼叫：AI 代理可以斷言某個 API 是否被呼叫、返回了預期狀態碼或資料體。不需要再等網路面板截圖。
• 監控 DOM 變化：元件渲染後，AI 可以檢查特定元素是否存在、樣式是否正確、文字內容是否匹配。
• 捕獲控制檯日誌和錯誤：讓 AI 直接看到執行時異常和日誌輸出，定位 bug 更快。
• 路由檢測：在 SPA 應用中驗證頁面跳轉是否符合預期路徑。

這些能力通過 MCP 伺服器暴露給 AI 代理，只要你的代理支援 MCP 協議（目前主流的幾個編輯器擴充套件都逐漸在支援），就能接入 Iris。設定過程不算複雜，克隆倉庫後配置一個 JSON 檔案，指定要監控的應用 URL，然後啟動代理即可。

典型的使用場景

假設你在用 AI 編碼代理重構一個 React 頁面的狀態管理。你讓 AI 把 Redux 替換成 Zustand，並期望某些 API 呼叫不再發生。傳統做法是改完後手動重新整理頁面、開啟 DevTools 檢查，或者截一張網路請求圖給 AI 分析。有了 Iris，你可以直接寫一條斷言：「在點選按鈕後，確保 /api/old-endpoint 沒有被呼叫」。AI 代理會在執行時實時驗證，如果斷言失敗，它會立即知道並嘗試修正程式碼。這種閉環除錯對前端開發者來說相當實用，尤其當你的應用涉及多個非同步流程時。

「Iris 不是替代 DevTools，而是把 DevTools 裡的結構化資訊直接餵給 AI，讓它自己消化並決策。」

開源的誠意

Iris 的原始碼託管在 GitHub 上，採用 MIT 許可證，這意味著你可以自由使用、修改或整合到自己的工具鏈中。目前專案還很早期，文件比較精簡，但核心功能已經跑通。對獨立開發者或小團隊來說，用 Iris 搭建一個 AI 輔助的自動化測試流程，成本極低——除了自己的伺服器或本地環境，沒有額外付費。

當然，它也有侷限性。比如目前只支援基於 Chrome DevTools Protocol 的應用（也就是 Chromium 系瀏覽器），對 Safari 或 Firefox 的支援還在規劃中。另外，斷言語法需要學習一下，不過官方提供了一個簡單的 DSL。

實用建議

想嘗試 Iris 的開發者，可以這樣入手：

• 先在一個簡單的單頁應用上測試，熟悉如何編寫斷言。官方示例用的是 React，但理論上任何前端框架都可以。
• 結合你常用的 AI 編碼代理（比如 Cursor 或 Continue），看它是否支援 MCP 協議。如果不支援，可以給專案提 issue。
• 不要期望一次就跑通，除錯過程中 Iris 自己的日誌也會輸出到終端，幫你排查連線問題。

總的來說，Iris 讓 AI 編碼代理從「盲寫」變成了「有反饋地寫」，這對提升 AI 生成程式碼的可靠性很有價值。如果你已經在用 AI 輔助前端開發，值得花半小時體驗一下。