從 Office 到 AI,我們又走了一次同樣的路
二十年前,履歷上會寫「熟悉 Office」是一種專長;十年前變成基本要求;到了今天,沒有人會在面試問你會不會用 Word。Office 從「能力」變成「識字率」,只花了一個世代。
但會 Office,從來沒讓任何一個業務員拿到大單、沒讓任何一個會計師升職、沒讓任何一個工程師升等。真正讓人有價值的,是他用 Office 「裝什麼進去」——是業務員的客戶洞察、會計師的稅務知識、工程師的領域專業。Office 只是放這些東西的容器。
AI 工具現在正在快速走完同一條路——只是速度比 Office 快十倍。三年內,「我會用 Cursor / Claude Code」會跟「我會打字」一樣不值得寫進履歷。真正會被定價的,是你腦袋裡裝什麼。
AI 不會幫你「無中生有」,它只能放大你「本來就有」的東西。
AI 只會做他「以為」的事
這句話值得放大,因為它點到了一個常被忽略的技術細節:LLM 沒有「目標」,只有「機率上最像答案的輸出」。
當你叫 AI「幫我寫測試案例」,它會給你一堆——看起來很完整、看起來很合理、看起來很專業。但它測的是它「猜你想測」的東西,不是這個系統真正的風險點。
如果你不知道這個模組真正的風險在哪、不知道上下游怎麼串、不知道使用者怎麼用錯,你拿到的就是一份「測試形狀的東西」,不是「測試」。
最糟的是,它會給你一種已經測過的錯覺——這比沒測還危險。沒測你還會緊張,測了你就放心了。
兩個範例,看「會測試的人」和「不會測試的人」差在哪裡
光講觀念太抽象,我用兩個真實情境來對照。
範例一:測試案例設計
不會測試的人會這樣問:
「幫我針對這個 API 寫測試案例。」
AI 會給你 10 到 20 個案例,大部分是 Happy Path 加上一兩個 null 檢查。你拿到了「看起來很多」的東西,但這個 API 真正會壞的地方,一個都沒測到。
會測試的人會這樣問:
「請用 Decision Table Testing 產生重要條件的組合,然後用 Pairwise Testing 減少組合數。」
這句話背後藏了三層 Domain 知識:
- 第一層:選對技法。你知道這個 API 的行為是「多條件決定多結果」的型態,所以決策表是對的工具,而不是邊界值、不是等價類、不是狀態轉換。
- 第二層:預見爆炸。你知道決策表會組合爆炸——4 個布林條件就 16 列、6 個條件就 64 列。所以你接著用 Pairwise(成對覆蓋)壓下來,這個技法在大多數情境下能抓到 70 ~ 90% 的缺陷。
- 第三層:順序對。先用決策表「窮舉條件」,再用 Pairwise「壓縮」。如果反過來,就完全沒意義——而 AI 不會糾正你,它會照著你錯的順序做。
一個不懂測試的人,連這句話的「形狀」都問不出來。他能問的極限就是「幫我寫測試案例」。
範例二:Code Review
不會測試的人會這樣做:
「請 AI 幫我做 Code Review。」
AI 會給你一份報告,講變數命名、註解、潛在 null pointer。看起來很專業,但其實只是表層的 lint。
會測試的人會這樣設計:
A Agent 生成程式 → B Agent 生成 test case 去測試 → C Agent 做 Mutation Testing → D Agent 做 Code Scan 和修復。
這個拆法展現的 Domain 深度,比範例一還要深:
- 為什麼 A 和 B 要分開? 因為寫程式的人不該寫自己的測試。30 年前 Glenford Myers 的《軟體測試藝術》就講過——A 寫程式時的盲點,A 寫測試時也會有同款盲點。讓 B 用獨立的 context 去寫測試,等於做了一次「概念上的對抗」。
- 為什麼需要 C 做 Mutation Testing? 這是整個設計裡最高段的一手。B 寫的測試可能跑得過,但跑得過不代表有效。Mutation Testing 會故意改壞 A 的程式碼(把 > 改成 >=、+ 改成 -),如果 B 的測試還是全綠,這套測試就是裝飾。C 在做的事情是「測試你的測試」。
- 為什麼 D 放在最後? Code Scan(SAST、SCA)抓的是安全和供應鏈問題,跟前面 ABC 的功能正確性是不同維度。放最後是對的——功能還沒對的時候就 scan,真正的安全洞會被雜訊蓋掉。
四個 Agent 對應品質的四個獨立維度:功能實作、功能驗證、驗證有效性、安全性。這個拆法本身就是一份完整的品質策略,而且每一刀都切在「人類盲點 vs AI 能力」的接縫處。
AI 是士兵,Domain 是地圖
把上面兩個範例濃縮成一句話:
AI 的能力是執行,Domain 是編排。
差別不是「會不會用 AI」,而是腦袋裡有沒有那張地圖——
- 知道測試這個領域有哪些武器:Decision Table、Pairwise、Boundary Value、Equivalence Class、State Transition、Mutation Testing、Property-Based Testing、Metamorphic Testing⋯⋯
- 知道什麼情境用什麼武器
- 知道武器之間怎麼組合
- 知道哪些活動該分給不同的「人」(現在是不同的 Agent)來避免盲點
這張地圖,AI 沒辦法給你——因為它不知道你在問什麼,它只知道你在「輸入什麼字」。
測試的「設計」與「執行」正在分家
過去十年我們把 QA 的價值講錯了。很多公司把 QA 等同於「執行測試 + 寫 case + 跑 regression」。結果 AI 一進來,這些事 80% 可以自動化,大家就喊「QA 要被取代了」。
但 QA 真正的價值從來不是執行,而是測試設計——也就是「面對這個需求、這段程式碼,該怎麼問問題、該怎麼挑風險、該怎麼證明它沒壞」。這件事 AI 做不來,因為它沒有對這個產品、這個團隊、這群使用者的脈絡。
AI 時代,測試「執行」的價值貶值,測試「設計」的價值升值。而能做測試設計的人,是本來就懂測試的人——AI 只是讓他做得更快、更廣。
不懂測試的人,加了 AI 還是不懂測試,只是錯得比較快、量比較大、看起來比較專業而已。
結語
如果要把這篇文章濃縮成一句話送給每一位想在 AI 時代繼續被需要的軟體工程師、QA、測試經理,那會是:
AI 不會把不會測試的人變成會測試,只會把會測試的人變成超人,並把不會測試的人變成寫得很快的災難。
所以,如果你今天還在想「我要不要花時間學 AI 工具」,問題其實問錯了。
正確的問題是:我腦袋裡那張地圖,夠完整嗎? 因為當 AI 變成識字率,Domain 就是你唯一的武器。
發表迴響