Agent 說「改好了」，PR 裡也真的多出一個錯誤提示。畫面只在某位同事的電腦上開過，測試跑在另一個容器，接手的人還得猜哪份 log 才是這次修改的。我遇到這種交接，會先把「完成」兩個字劃掉。

能在編輯器裡叫到 agent，解決的是入口問題。選工具時，我更在意它讀對專案了沒有、修改能不能在指定環境驗證，以及換人接手後能不能重跑。

拿同一道小題目試，不要比聊天視窗

假設團隊有一個送出表單，現在 API 回傳失敗時只會讓按鈕恢復，使用者不知道發生什麼事。拿測試資料與拋棄式分支，請候選的 IDE／agent 組合各自完成同一件事：送出失敗要顯示錯誤訊息，成功時仍照原本流程走。

測之前，先由人寫下這次的驗收條件，而不是讓 agent 自己決定「完成」長什麼樣：

• 指定要修改的表單元件與可用的測試資料；不需給正式環境帳號。
• 指定專案原本就有的 build、test 指令，以及它們應在哪個環境執行。不要把 pnpm test 當成所有專案的通用指令。
• 預覽時親自操作一次成功和失敗狀態：訊息有沒有出現，重試後會不會留下舊錯誤。
• 記下每個步驟的實際結果。若某套整合無法提供預覽，就記「這一步要人手動開」，不要直接記成 pass，也不要推論整個產品做不到。

我會故意挑小題目。連一個錯誤提示都交接不清楚，跨頁面任務只會更難查。

先看它找到了哪個專案，再看它寫得快不快

在下第一個修改指令前，請 agent 指出元件位置、錯誤狀態從哪裡來，以及專案用什麼設定建置。人要對照 repo 確認；回答得漂亮，不等於讀對檔案。若它找的是過期的元件或另一份 workspace，後面的測試就算綠了也不算數。

Android Studio 的 Bring Your Own Agent 公告描述，IDE 可提供專案圖譜、建置脈絡與 Android 工具給接入的 agent。這仍是 Android Studio Canary 的預覽功能；不要因此假設每個 ACP agent 都拿得到相同工具和權限，更別把切換 agent 當成對話狀態自動移轉。

所以先讓它指出所用的專案脈絡，再讓它動手改。接上協定沒有替我們做這項核對。

Build 跑在哪裡，結果就要在哪裡留證據

另一個容易錯位的地方是執行環境。VS Code 的 1.139 相關更新提到遠端 Dev Container 的 agent 工作流程；能不能使用仍取決於專案設定、遠端主機上的 Docker、相關介面設定與逐步開放情況。發表前應再依官方更新確認版本通道及實際啟用條件。這不是 Android Studio 那套功能的跨平台對照表，兩邊也不能假設共用同一個 agent 協定。

在我們的表單題目裡，請明確記錄指令在哪台機器或容器跑、依賴用哪份設定裝，以及失敗時去哪裡看輸出。容器讓環境比較容易重建，卻不會自動證明畫面正確，也不是權限安全的保證。build passed 還得對得上這次修改的版本；昨天的綠燈沒有用。

若這題還要讓 agent 嘗試生成互動元件，我會先從 生成式 UI 資源 看幾種元件與互動範例，挑一種適合表單錯誤提示的做法試做。範例只幫忙選方向；結果仍得回到自己的程式碼，跑 build、測試並打開實際畫面。

接手的人要拿得到任務紀錄，不是接一段聊天

收尾時，把這次實際做過的事留成一份短紀錄：改了哪些檔案、對應哪個 commit 或工作樹狀態、在哪個環境跑了哪些命令、退出結果是什麼、正常與失敗畫面各看到了什麼、還有哪一步沒做。測試失敗就附原始輸出的位置，不要把摘要寫成「大致沒問題」。

交給另一位同事時，請他不看原本的對話，照紀錄重跑驗證。跑不起來就查缺的是環境、測試資料還是操作步驟，補完再交。換 agent 也是一樣，新的 session 未必知道上一位做過什麼。

我會選能把這道小題目走完、又能說清楚哪一步還要人工接手的組合。交接若只剩一行「已完成」，再多支援幾個 agent 也不會讓下一位同事知道該怎麼驗證。

資料來源

• Android Developers Blog：Build your way, use any AI agent in Android Studio
• Visual Studio Code 1.139 更新紀錄