從多代理測試實驗，延伸到 AI 時代下工程團隊應如何演進的更廣泛討論。

一開始，我只是想分享我正在開發的一套 AI 驅動自動化測試系統。

這套系統已經能理解需求、產生測試案例、與網頁瀏覽器和行動 App 互動、找出缺陷，並將修復缺陷與回歸測試串聯起來。我原本以為這場分享會聚焦在 AI 如何提升測試效率。

但在 2026 年 11 月 5 日的內部分享中，討論逐漸超出了測試本身。

我們開始談產品、開發和 QA 團隊如何協作，討論為什麼需求總是容易失準，以及 AI 可能會如何改變工程團隊的組織方式。

到了討論結束時，這場分享甚至成了推動我們公司組織轉型的重要最後一把力。

回頭看，我覺得這件事很有意思。我們原本是想幫助測試人員更有效率地使用 AI，最後卻討論到 AI 是否會迫使整個工程組織重新思考自己的運作方式。

1. 🤖 我原本希望 AI 接手整個測試流程

我一直在開發一套多代理自動化測試系統。

與其只是讓 AI 根據測試案例產生自動化腳本，我更希望把整個流程串起來：理解需求、設計測試、執行測試、回報缺陷、驗證修復，以及執行回歸測試。

大致流程如下：

1. AI 讀取產品需求文件與原型，理解業務流程與驗收標準。
2. 產生測試案例，並交由多個代理進行審核。
3. 根據這些測試案例，AI 控制網頁瀏覽器與行動 App，模擬真實使用者互動來執行測試。
4. 發現問題時，AI 產生缺陷報告並提交到我們的缺陷追蹤系統。
5. 每一筆缺陷都會先經過第二次審核與人工確認，再分派給對應的開發人員。
6. 開發人員修復問題後，AI 會自動執行回歸測試來驗證修復結果，並在保留人工監督的前提下推進缺陷關閉流程。

從需求到回歸測試的端到端流程，現在已經建立並運作中。

最讓我印象深刻的是，AI 開始接手傳統自動化測試中一些最令人頭痛的部分。

在 UI 自動化中，最困難的往往不是一開始寫腳本，而是後續維護。

開發人員只要修改一個 UI 元件，測試人員可能就得重新處理元素定位、頁面物件和互動腳本。介面變動越頻繁，維護成本就越高。有時候，測試人員花在維護自動化腳本上的時間，甚至比真正執行測試還多。

現在，AI 可以觀察目前的頁面、理解其中的元素與互動狀態，並根據測試目標執行操作。它仍然必須面對 UI 變動與執行失敗，但它已經能接手相當多過去需要反覆人工維護的工作。

這讓我開始重新思考自動化測試的邊界。

2. 🔍 自動化測試不該只是不斷重複已知案例

很長一段時間，我對自動化測試的看法相當明確：

自動化適合做回歸測試，但不太擅長發現新缺陷。

原因很單純。傳統自動化測試高度依賴事先設計好的測試案例、固定的執行步驟，以及預先定義的斷言。它可以反覆執行已知路徑，但很難發現測試人員沒想到要檢查的問題。

它比較像是照著指令執行的執行者，而不像能主動探索軟體行為的測試者。

但隨著 AI 代理開始能理解需求、觀察畫面、分析頁面狀態並調整行動，我開始改變想法。

在訓練與調校這些代理的測試行為時，我特別強調一個原則：

不要只照著需求文件做，也不要把測試案例當成探索的上限。

需求描述的是產品預期要做什麼，但無法涵蓋所有可能的使用者行為或系統狀態。

因此，在完成需求中定義的測試後，AI 也應該進一步探索更多情境，包括：

• 無效與非預期輸入： 空值、過長文字、非法字元、異常格式，以及不常見的資料組合。
• 邊界條件： 最大值與最小值、臨界條件、重複提交，以及異常的操作順序。
• 異常流程： 操作中斷、重複點擊、頁面重新整理、網路失敗、登入逾時，以及連續步驟之間的不一致狀態。
• 安全相關情境： 未授權存取、權限邊界、敏感資訊外洩，以及嘗試執行不應被允許的操作。
• 非預期互動： 跳過正常步驟、快速連續操作、反覆切換狀態，或透過不同入口進入相同的業務功能。

當然，這不代表可以讓 AI 自由對正式環境操作。探索範圍、測試環境、帳號權限與操作風險都必須受到控制。安全測試也必須維持在明確授權的範圍內。

我不希望 AI 只是證明需求已經被實作出來。我更希望它去找出那些在系統以未曾預期的方式被使用時，可能浮現的問題。

這就是我對自動化測試理解改變的地方。

過去，自動化主要是在重複檢查已知問題。現在，AI 有機會幫助我們發現原本不知道該查什麼的問題。

它無法保證找出所有缺陷，也無法取代人的判斷。但自動化測試已經不必再侷限於事先撰寫好的測試案例。

3. 🌙 AI 晚上工作，人類白天做決策

這些日子，我通常會在下班前安排自動化測試任務。

之後，代理會持續在夜間執行。等我隔天早上到公司時，通常已經能看到 AI 提交了一批缺陷報告。

我的工作就是逐一審核這些問題，判斷它們是否真實存在、是否與目前需求一致，確認後再分派給適當的開發人員。

這改變了測試人員分配時間的方式。

以前，測試人員需要花大量時間操作系統、執行測試案例、觀察結果並整理報告。現在，AI 可以接手其中很大一部分重複性工作，讓人把更多心力放在問題判斷、風險分析與產品品質改善上。

不過，這個過程也揭露了另一個問題：

發現缺陷，不代表就能有效溝通缺陷。

一開始，AI 產生的缺陷報告往往只是一大段密集文字。雖然資訊很多，但對開發人員來說並不容易閱讀。

如果一份報告無法讓接收者快速理解問題，那麼即使資訊量再大，也無助於提升協作效率。

因此，我花了幾輪調整報告格式。我們需要的不只是執行過程的紀錄，而是要清楚說明發生了什麼、問題出在哪裡、實際行為與預期行為有何差異，以及如何重現與驗證。

經過幾次迭代後，報告變得更容易閱讀，也更實用。

這讓我意識到，評估 AI 產出品質時，不能只看它完成了多少工作，也要看流程中的下一個人是否真的能使用這些結果。

每次測試週期結束後，我也會讓 AI 總結這次執行中出現的問題與經驗教訓。那些已經被審核、驗證且可重複使用的經驗，會進一步萃取成通用的 Skills。

這樣一來，下一輪測試就不必從零開始，而是能建立在前一次學到的基礎上。

實務上，這會形成一個持續改善的循環：

執行 → 發現問題 → 審核 → 擷取經驗 → 將可重用知識轉成 Skills → 開始下一輪。

4. 📊 資料證明了價值，也揭示了問題

在我們的一個知識庫專案中，已經累積了一些具體成果：

也就是說，在最終確認為有效的 30 個缺陷中，AI 辨識出其中 21 個，占比 70%。

這些資料顯示，在這個專案與測試覆蓋範圍內，AI 已經不只是執行測試案例的工具，而是對缺陷發現有實質貢獻。

我們也嘗試讓代理導航頁面、擷取業務流程中涉及的 API 呼叫，並每天執行排程式的大規模 API 驗證。目前我們的測試環境涵蓋了接近 300 個與業務流程相關的 API。

這些實驗顯示，AI 能夠承擔 UI 與 API 兩個層面的持續測試工作。

但資料同時也揭露了一些問題。

例如，我們目前只有一個測試環境。當多個需求並行開發時，程式碼變更可能互相衝突，部署也可能中斷其他測試任務。我們仍需要評估是否要增加第二個測試環境，以及專門的效能測試環境。

瀏覽器相容性也還需要進一步完善，包括不同 Windows 版本與 360 瀏覽器的測試覆蓋。

這些都是基礎設施問題，可以透過增加資源與技術改善逐步處理。

但真正讓我開始思考的，是另一類問題。

5. 🧩 自動化會暴露傳統測試常常掩蓋的組織問題

某個時候，我們注意到 AI 報出的部分缺陷被歸類為無效。

我們最先的懷疑很自然：是不是 AI 誤解了需求，或是測試邏輯有問題。

但仔細看過之後，我們發現 AI 並不完全是問題來源。

有些需求其實已經在產品與開發的討論中調整過了，但正式的 PRD 並沒有更新。產品與開發可能已經達成新的理解，甚至私下改了實作，但 QA 和 AI 仍然是根據原始需求文件在工作。

結果就是，AI 根據正式需求指出了差異，但這個問題卻被認定為無效缺陷。

從測試角度來看，AI 未必做錯了什麼。從開發團隊的角度來看，根據他們對實作的最新理解，這可能也不是他們認為需要修正的問題。

真正的問題在於：團隊同時在使用同一個需求脈絡的多個版本。

這讓我得到一個重要觀察：

自動化可以暴露出傳統人工測試多年來默默吸收並掩蓋的組織問題。

過去，測試人員常常透過口頭溝通、臨時釐清，以及自身經驗，來補足需求文件中的不一致。這些工作很重要，但也可能讓組織誤以為流程本身運作得相當良好。

AI 不會自動知道某場私下對話，也無法理解某個人的最新想法。它是根據自己收到的上下文來執行任務。

當正式文件與團隊實際理解不一致時，自動化就會把這個落差暴露出來。

所以問題不只是 AI 夠不夠聰明。

我們也必須問：團隊是否有一份大家都認同、持續更新，而且 AI 能正確理解的共同需求版本？

6. 🏢 為什麼技術分享會變成對組織架構的討論？

2026 年 11 月 5 日，我們舉辦了一場內部分享，介紹本地 AI 代理與自動化測試的經驗。公司的一位創辦人也參與了這場討論。

原本的焦點是 AI 測試能力，但話題逐漸擴展到工程流程與組織結構。

我越來越認同一個觀點：

AI 正在降低產出程式碼的成本，但協調人的成本並沒有以相同速度下降。

過去，一項需求可能先由產品經理分析並寫成文件，再交給前端與後端工程師，最後由 QA 驗證。每一次交接，都意味著脈絡必須再次傳遞。

如果這條鏈上的任何一環出現誤解，後面就可能產生重工。

現在，AI 可以協助產品經理做某些程式碼修改，協助測試人員理解並修改程式，也能讓開發人員更直接參與需求分析與產品設計。

如果一個小需求只需要幾個程式修改，卻還得經過多個角色、多道流程、好幾輪溝通，那麼協調成本可能遠高於實際的編碼成本。

這並不代表專業分工失去價值，而是 AI 正在逐步降低傳統角色之間的一些能力門檻。

在討論中，我們提出了一個方向：從傳統以角色劃分的分工方式，轉向一種更彈性的模式，讓人們在 AI 的協助下跨越原本的角色邊界進行工作。

當我們談到跨團隊的全端式做法時，並不是說每個人都必須變成傳統意義上的全端工程師，也不是要大家放棄自己的專業。

我們真正的意思是：

產品、開發與 QA 的人都應該能使用 AI，跨越原本的技術邊界，去解決自己理解的問題。

例如：

• 產品經理 可以使用 AI 進行程式修改，並自行驗證較小的需求。
• 開發人員 可以更早參與需求分析，並對較大型的工作專案負起整體責任。
• 測試人員 在發現缺陷時，不必只停留在提交缺陷單，也可以用 AI 進一步調查問題，甚至修改程式，並由開發人員提供必要的審查與確認。

對於小需求，我們希望減少不必要的交接。對於大型專案，我們希望有明確的負責人來協調整體流程。

這不是要消除專業角色，而是要減少僵化邊界所造成的資訊流失。

7. 🔗 協作應該從需求階段就開始，而不是等測試發現問題之後

要讓這種工作方式成立，首先必須解決共享需求脈絡的問題。

我們討論了幾個具體方向。

首先，產品、開發和 QA 應該從一開始就參與需求對齊，而不是等 PRD 寫完、開發完成後，才讓測試人員開始理解需求。

其次，我們希望建立標準化的 PRD Skills 與結構化模板，讓需求文件能以更一致的格式呈現。

更重要的是，只要需求有變動，正式文件就必須及時更新。變更不應只存在於少數人的私下對話裡。

我們也討論了一個更進一步的想法：透過智慧徽章的錄音內容，辨識討論中哪些部分可能涉及需求變更，標記出可能影響需求的內容，並協助更新 PRD。之後，提議的變更再提交給相關人員審核與核准。

這仍然只是一個待探索的想法，還不是已經部署的功能。

但底層原則很清楚：

我們應該確保團隊實際共享的理解，能夠及時被記錄下來，並以大家都能使用的形式保存。

除了 PRD 之外，我們也需要共享的開發與測試 Skills、程式碼規範，以及 Specs。

當產品、開發與 QA 能在大致一致的脈絡下工作時，AI 就能成為連接不同工作流程的工具，而不是在角色之間製造更多彼此孤立的資訊孤島。

8. 🚀 從單一 AI 工具走向 AI 驅動的工程系統

討論最後已經不再只聚焦於某個代理或某個自動化測試工具。

我們開始把整個工程系統作為一個整體來看。

例如：

• 建立共用的開發與測試 Skills 資源庫。
• 標準化程式碼規範與 Spec 管理。
• 建立完整流程：從雲效取得缺陷，使用 AI 修復，再執行自動化回歸測試，並保留人工審核。
• 探索自動化工時估算與需求分類。
• 持續改善測試環境與瀏覽器相容性。
• 確保需求變更能即時傳達，減少不必要的討論與重工。

這些事情不可能在一場會議後就自動完成。組織轉型計畫已經啟動，後續會透過每週更新來檢視與協調進度。

當然，有了明確方向和啟動中的計畫，並不代表前方道路就會順利。

一旦真的開始落地，我們一定會遇到實際阻力：既有流程的慣性、不同角色之間已形成的協作習慣、技術基礎設施的限制，以及如何把新的工作方式嵌入現有業務節奏中的挑戰。

這些問題不可能靠一場會議或幾條新規則就解決。我們需要在問題浮現時逐一辨識、調整做法，並逐步形成真正適合團隊的工作模式。

對我來說，這正是這場討論有意義的地方。它不只是提出一個組織變革的想法，而是已經進入實作階段。

AI 驅動的工程系統，不可能只靠買幾個工具、接幾個 API、或建立幾個代理就完成。

它需要技術能力、流程標準、知識累積，以及組織協作一起演進。

如果團隊內部的資訊仍然不一致，就算是最強大的 AI，也只會更有效率地執行錯誤的上下文。

9. 💡 在 AI 時代，寫程式能力可能不再是最稀缺的資源

回頭看，一開始我只是想讓 AI 幫我自動化更多測試工作。

但當 AI 開始能理解需求、與介面互動、主動探索異常情境、提交缺陷、協助修復並執行回歸測試時，我意識到自己需要重新思考的不只是測試，而是整個軟體開發流程。

過去，很多效率問題常被歸因於某個角色能力不足，或流程中某個階段不夠快。

現在，AI 正讓越來越多任務變得更容易。

但當寫程式變得更容易之後，真正拖慢開發的，可能反而是需求沒有同步、責任不清，以及人與人之間過多的交接。

我不認為 AI 會讓每個人都變成程式設計師，也不認為軟體團隊不再需要產品、開發、QA 這些專業角色。

我認為 AI 會逐步消除這些角色之間不必要的障礙。

真正理解問題的人，應該能夠藉由 AI 更直接地朝解法前進，而不是只能等待資訊經過多個角色傳遞。

對測試人員來說，這代表不再只是執行測試案例，而是參與風險探索、問題分析與品質改善。

對開發人員來說，這代表不只是接收需求和寫程式，而是對更完整的問題負責。

對產品經理來說，這代表不只是描述需求，而是能更直接地用 AI 驗證與實作自己的構想。

最終，團隊的競爭力可能不再取決於有多少人完成多少個獨立任務，而是取決於團隊是否能快速傳遞正確資訊，並讓每個人都能使用 AI 去解決更完整的問題。

一場 AI 測試分享，最後竟然變成了對整個工程組織應如何改變的討論。

也許，這正是 AI 時代最值得關注的變化之一：

AI 正在讓寫程式變得更容易，但真正能讓軟體開發變快的，或許是我們是否願意重新設計人們彼此協作的方式。

原文出處：https://dev.to/xulingfeng/an-ai-testing-presentation-became-the-final-push-for-organizational-change-at-my-company-12ag