本文是 Lauren Tan 訪談的中文整理摘要。原始影片為 〈Lauren Tan – SpaceXAI engineer〉。文中的 AI Agent 開發方法與工程案例，來自 Lauren 在訪談中的分享，由范育銘依逐字稿整理；這場訪談並非由 WeAgile 製作或主持。文末「主管反覆提醒的事，有沒有辦法讓團隊自己判斷？」則是范育銘延伸的管理心得。

AI 寫程式越來越快，工程師卻不一定更輕鬆。

程式碼寫完，還得有人確認：問題解決了嗎？其他功能有沒有壞掉？這樣寫符合原本的系統架構嗎？如果每一項都得由人檢查，省下的寫程式時間，很可能又花在審查與修正上。

Lauren Tan 在這場訪談中，分享了她如何從緊盯少數 AI Agent，逐步走到讓 Agent 自動合併程式碼變更。她能放手，是因為花了時間建立驗證流程，也把工程要求寫進工具與架構，讓 Agent 的工作有依據，做錯時也能及早發現。

不相信 Agent，就只能一直盯著

Lauren 提到一種讓人失去耐心的經驗：Agent 很有信心地說自己找到問題了，但仔細一查，卻發現它連相關程式碼都沒讀完整。

碰過幾次之後，工程師自然會開始懷疑它的判斷。於是，每次工具呼叫、每一段修改都要看，必要時還得自己重新查一遍。

她把這種處境比喻成管理團隊：主管不信任團隊，就容易事事過問。使用 Agent 也一樣，如果連一個 Agent 的工作都得全程盯著，多開幾十個，只會增加需要檢查的東西。

在擴大使用規模之前，工程師得先有辦法判斷：Agent 說完成了，究竟拿得出什麼證據？

讓 Agent 自己檢查，問題到底解決了沒有

Lauren 認為，與 Agent 協作時，應該優先建立驗證能力。

Agent 要能自己啟動應用程式、操作介面、重現錯誤，再用測試、效能追蹤或錯誤紀錄，確認修改後的行為。

缺少這些能力，工作就會變成：Agent 寫完程式，人打開產品檢查，發現有問題後截圖、複製錯誤訊息，再交回去修正。

只要每一輪都需要人接手檢查，就很難同時推進多項工作。

但 Lauren 也區分了兩件事：功能正常，不代表程式設計得好。能執行、能通過測試，還不足以證明架構合理，或往後容易維護。

Agent 能操作產品，還得知道功能在哪裡

即使 Agent 已經能操作產品，也不代表它知道該去哪裡找問題。

Lauren 曾經建立工具，讓 Agent 可以啟動產品、擷取效能資料，卻發現它還是在介面裡迷路。使用者說「左側欄很慢」或「PR 分頁有問題」，Agent 不一定知道如何進入那個功能。

她因此建立了 Feature Map，記錄功能在哪裡、如何操作、有哪些快捷鍵，以及自動化工具可以用哪些資訊找到介面元素。

有了這份地圖，Agent 比較能把模糊的問題描述，對應到產品裡實際可以操作與檢查的地方。

她也把反覆出現的錯誤整理成 Skills。例如，調查問題前應該先讀哪些程式碼、蒐集哪些證據，以及什麼時候還不能下結論。

這些指引是在實際協作中慢慢累積的。每發現一種常見錯誤，就調整工作方法，再看 Agent 下次做得如何。

寫了指引，還要確認 Agent 有沒有照著做

寫好一份 Skill，不代表 Agent 每次都會照做。

Lauren 使用 Eval，也就是評估測試，檢查 Skills 是否讓 Agent 做出預期的行為。她把它比喻成 Agent 的單元測試：先設計任務與評分標準，交給不同 Agent 或模型執行，再檢查結果。

她也會用其他模型交叉評估，並在修改 Skill 後重新測試。

驗證方法本身，同樣需要檢查。不過，評分能告訴我們多少事情，取決於測試案例與標準設計得好不好；在既有案例裡拿到高分，仍不能保證遇到其他情況都能處理。

重要的規則，要讓工具幫忙檢查

訪談後半段，Lauren 談到軟體架構，以及如何讓工程要求確實被遵守。

文件、Skills 和程式碼審查可以說明要求，但 Agent 仍可能漏看、誤解，或這次遵守、下次忘記。因此，有些限制需要交給編譯器、靜態分析與持續整合（CI）檢查，不能只靠提醒。

例如，她分享的專案會檢查不同執行環境之間的程式碼依賴，避免把耗費資源的工作帶進負責畫面渲染的部分，造成介面卡頓。團隊也把容易出錯的寫法加入自動檢查，違反規則就無法通過。

她採取的原則是：讓 Agent 最容易想到、最方便採用的寫法，也符合團隊的架構要求。

Agent 喜歡沿用現成的模式，也傾向找最快能解決問題的方法。功能邊界清楚、目錄結構固定、寫法一致，就能減少它自行猜測的機會。

這些規則有各自的適用條件。訪談中提到禁止特定 API 或限制程式碼註解，未必適合所有團隊；可以借鏡的是她的處理方式：發現某種錯誤一再發生，就設法讓工具檢查，減少人工反覆提醒。

放手要循序漸進，也要算成本

Lauren 建議先在本機使用少量 Agent，親自觀察它們如何操作產品、調查問題。等驗證方法與工作流程比較可靠，再擴展到雲端，讓更多任務同時進行。

她提到，自己的 Agent 已經能自動合併 PR，程式碼變更的提交量也很高。但這是她在特定工作環境下的經驗，單看 PR 數量，還無法判斷產品品質與商業價值。

她也承認，自己擁有充裕的 Token 資源。建立工具、設計評估方法、重構架構，都需要前期投入，其他團隊得自己算一算是否值得。

除了交付速度，團隊還需要看缺陷、返工、人工審查時間與維護成本，以及做出來的功能是否解決了使用者的問題。

主管反覆提醒的事，有沒有辦法讓團隊自己判斷？

讀完這場訪談，我想到的是主管如何為授權做準備。

如果品質標準一直留在主管腦中，等成果交出來才逐項指出問題，團隊就很難知道該怎麼判斷。主管經驗越多，也可能越容易變成所有事情都得經過的關卡。

Lauren 的做法提供了一個起點：當相同的審查意見一再出現，就問問自己，能不能把它寫成清楚的工作原則、交給工具檢查，或調整架構，讓這類問題不容易再發生。

管理人與管理 AI 當然有差別。人的動機、關係、學習與責任承擔，都需要另外看待，不能直接套用限制軟體的做法。但兩者都需要清楚的目標、決策邊界，以及能及早發現問題的回饋。

正在導入 AI 的團隊，可以先找出一件最常需要資深人員提醒的事。把判斷標準說清楚，讓執行者能自行檢查，往往比急著增加 Agent 數量更有幫助。

完整直播影片

本文依據 Lauren Tan 訪談逐字稿整理。文中的工程案例與產出描述，來自她在訪談中分享的個人經驗。

觀看完整英文直播：Lauren Tan – SpaceXAI engineer

作者簡介

范育銘是 Scrum Inc. 認證培訓師及台灣敏捷協會常務理事，曾陪伴不同規模的企業推動數位與組織轉型。我協助主管對齊目標、釐清決策邊界，建立回饋與協作機制，讓主管能放心授權，團隊也能承擔決策與成果責任。
我也持續在 WeAgile 分享組織變革與敏捷實務文章，並提供公開課、企業內訓及教練顧問服務，幫助企業把自組織與自管理，從理念轉化為真正能運作的管理能力。