前言：一個聽起來很合理的提案
某次會議，測試主管講了一個聽起來非常合理的構想：
「現在不是流行 vibe coding 嗎？開發那邊都會留一份
specs.md，我們就拿那個丟給 AI，請它幫我們生測試案例。這樣 QA 也可以加速。」
會議室點頭的人不少。看起來這提案幾乎沒有缺點——有現成的文件、有 AI 工具、有產出物（測試案例）、有效率提升（QA 不用從零寫）。我當下也沒有反對，但回到位置上，我心裡有一個聲音越來越大聲：
如果那份
specs.md在功能上線那一刻起，就再也沒有人動過呢？
如果是那樣，那我們不是在「用 AI 加速 QA」。我們是在用 AI 加速一份過期文件——加速地產生一堆驗證舊需求的測試案例，然後拿它去測一個已經改過三輪需求的產品。
這篇文章想認真聊聊這件事。因為這個「specs.md 給 AI 生測試案例」的提案，真正的問題不在 AI，也不在 QA——它在整個組織有沒有人願意做一件不性感的事：維護文件。
一、AI 生測試案例這條鏈，最弱的一環是哪裡？
我先把這條鏈拆開看：
- PM 寫需求 / RD 寫實作 → 產出
specs.md specs.md跟著功能演化持續更新- QA 把
specs.md餵給 AI - AI 產出測試案例
- QA 執行（或交給自動化執行）測試案例
- 測試案例反映出真實的品質風險
主管的提案，是在優化第 3、4 步——這兩步是整條鏈裡最容易優化的，因為它們是純粹的工程問題：給好的輸入、選好的模型、調好的 prompt。
但這條鏈的可靠度，從來不是由最強的一環決定的。它是由最弱的一環決定的。
而我認為這條鏈最弱的一環，幾乎不會是第 3、4 步。它通常是第 2 步——「specs.md 跟著功能演化持續更新」。
因為這一步：
- 不寫程式——所以 RD 不覺得是自己的事
- 沒有交付物——所以 PM 不覺得是自己的事
- 不在測試範圍內——所以 QA 不覺得是自己的事
- 看不到 KPI——所以主管也很難排進排序
於是第 2 步就漂浮在組織的灰色地帶裡。它屬於每一個人，所以實際上不屬於任何人。
而 AI 生測試案例這個提案，本質上是假設第 2 步永遠成立。一旦這個假設不成立，後面所有的工程優化都是在優化一台引擎漏油的車。
二、文件不會自己過期，是「沒人負責」讓它過期
我見過太多份 specs.md、README.md、API.md、需求規格書 v3.7 final final.docx 走過一樣的人生：
- 誕生：專案啟動時，PM 跟 RD 一起寫得很認真。文件清楚、流程圖漂亮、有版本號。
- 黃金期：前兩個 sprint，大家都會回去更新。
- 拐點：某次需求臨時改，時程很趕，「先做了再回頭補文件」。
- 滑坡：第二次、第三次、第十次的「先做了再回頭補」之後，文件已經跟現實對不上。
- 遺棄期：團隊心照不宣地知道「那份文件不能信」，新人 onboarding 的時候會被告知「程式才是真相，文件僅供參考」。
- 詭異復活：某天有人說：「欸我們有
specs.md對吧？拿去餵 AI 吧。」
第 6 步是最危險的。因為當你把一份已經沒人信的文件，重新塞給 AI 當「真相來源」，你做的事不是「重新利用文件」，而是把一個組織內部已經知道的問題，外包給機器，讓機器以權威的姿態幫你重新製造出垃圾。
這就是 GIGO（Garbage In, Garbage Out）的 AI 時代版本——而且更糟糕，因為 AI 產出的東西外觀非常專業，反而讓人忘了去懷疑它的來源。
三、「維護文件」為什麼是一份典型的灰色地帶工作？
我在前一篇 〈如果主管想用 AI 取代我，我會給他看的四份「當責清單」〉 裡寫過：當責不是能力，是身分；它問的不是「你會不會做」，而是「事情出了問題，誰簽名」。
文件維護就是一份沒有人想簽名的工作。原因有三：
1. 它沒有交付儀式
寫程式有 PR 可以 merge、有 demo 可以亮給主管看。寫文件不會。沒有人會在 sprint review 時鼓掌說「這個 README 寫得真好」。沒有掌聲，就沒有動機。
2. 它的價值是負面證明的
文件維護好，看不出來有什麼差別——因為「沒有人因此誤會需求」這件事，永遠不會被報導。但文件爛掉造成的損失（新人 ramp up 慢、跨團隊溝通失誤、AI 生出垃圾測試案例）會被歸因到別的環節，不會回頭追到「文件沒維護」這個源頭。
這就是 〈我們真的跑了太多無意義的回歸測試嗎〉 裡那種典型的負面價值困境：你做對了沒人看到，你做錯了會被怪到其他地方。
3. 它不是任何人的「主業」
PM 的主業是定義產品方向。RD 的主業是寫出可運行的程式。QA 的主業是把關品質。文件維護對每個角色來說都是「順便」——而「順便」這兩個字在組織裡的命運，就是被擺在 backlog 最底下，然後永遠不會被翻上來。
四、再往上一層：這其實是「公司怎麼看待產品」的問題
寫到這裡其實還沒寫到最深。「文件沒人維護」只是症狀。真正的根源是——這家公司把產品看成「完成品」還是「活物」？
這兩種看法，會長出兩種完全不同的組織。
把產品當「完成品」的公司：
- 績效是 ship 出去的 feature 數
- 上線那一刻，責任就跟維運／客服交接了
- 文件是上線前的副產品，不是日常的伴生
- 「維護」這個詞通常出現在「維運成本」這種偏負面的語境裡
- 技術債、文件落差、迴歸風險都被當成「下一版再說」
把產品當「活物」的公司：
- 產品有長期 owner，對它的健康度負責
- 文件、測試、監控、回饋都是產品的器官，不是裝飾
- 維護有專屬的時間預算（10% time、tech debt sprint、定期的 spec review week）
- KPI 不只看「ship 出多少」，也看「現有的功能還活著嗎」
specs.md 餵 AI 這個提案——在第一種公司會失敗（因為文件早就死了），在第二種公司會成功（因為文件本來就是活的）。
問題從來不在 AI，差別也不在工具，差別在「這家公司怎麼定義『完成』」。
而一家公司怎麼定義「完成」，是文化問題，不是流程問題。流程可以改、KPI 可以調、職責可以重切——但文化要改，從來不是寫一份新 SOP 就能改的。它需要主管的主管帶頭、需要好幾年的耐心，甚至需要一兩次大規模的痛——客訴爆量、技術債失控、新人三個月就離職——才會真正鬆動。
這就是為什麼 QA 推「文件先行」會這麼挫折。你不是在推一個流程，你是在挑戰一家公司對「產品」的定義。而挑戰文化這件事，從來不該是初階 QA 的工作——這話我等等會回來認真講。
五、所以「specs.md 餵 AI」不是 AI 的問題，是組織的問題
回到主管的提案。
我反對的不是「用 AI 生測試案例」這件事。事實上我相信兩三年內，AI 生測試案例會變成標配——就像當年自動化測試框架變成標配一樣。
我反對的是——在文件維護這件事沒有歸屬之前就用 AI 生測試案例。因為這樣做會發生兩件事：
第一，組織會誤以為「我們已經解決測試案例的問題了」，於是更不會去面對文件維護的灰色地帶。AI 變成一個讓組織持續忽略真問題的鴉片。
第二，當測試案例真的漏掉一個關鍵 bug 時，這個鍋會被丟給 QA——「為什麼 AI 生的案例沒測到？」「為什麼你沒有檢查 AI 的輸出？」沒有人會回頭問「為什麼 specs.md 半年沒更新了？」 因為這個問題沒有歸屬，沒有歸屬就沒有人有義務回答。
到頭來，QA 變成那個用過期文件被 AI 害的人，再用自己的名譽幫整個組織的文件荒墊背。這個結構性的不公平，沒有人會在會議室裡點破，但它會每一次出包都重演一次。
六、那這件事「應該」是誰的責任？
我想了很久，誠實的答案是：應該是 PM 跟 RD 共同負責，而不是 QA。
因為：
- PM 是需求的源頭，沒有人比 PM 更清楚「這次改版動到了哪些原本的假設」
- RD 是實作的執行者，沒有人比 RD 更清楚「文件上寫的跟實際長出來的有什麼差異」
- QA 是下游的驗證者，QA 看到文件跟現實有落差時，往往已經太晚——下游能做的只是「發現過期」，不是「避免過期」
但組織的現實是，PM 跟 RD 都在以「交付」為績效——交完這個版本，注意力就跳到下一個版本。文件維護這件事，沒有發生在他們的績效視野裡。
這時候真正應該動作的，不是 QA 跑去要求 PM 跟 RD 維護文件（那只會被當成龜毛），而是主管的主管、或更高一層，把「文件維護」明確地寫進某一個角色的 KPI 裡。
可以是 PM 的（每次需求變更必須同步更新 spec）。
可以是 RD 的（每次 PR merge 必須附帶文件 diff）。
甚至可以是設一個專職的 Tech Writer——很多歐美工程組織有這個角色，就是因為他們意識到「文件維護是專業，不是順便」。
但不應該預設是 QA 的。因為 QA 一旦扛了這個，就同時扛了「定義」跟「驗證」兩端——這在任何體系裡都是利益衝突。自己定義需求然後自己驗收，這份報告誰會信？
但這裡有一個常被忽略的區分——QA 跟 SDET 的權責設計其實不一樣。
QA 跟 SDET（Software Development Engineer in Test）在中文裡常常被一起講成「測試工程師」，但兩個角色在組織裡的權責設計差很多，反映在「該不該寫／維護 spec」這件事上會落出兩個不同的結論：
| 維度 | 傳統 QA | SDET |
|---|---|---|
| 主要產出 | 測試案例、bug report、品質報告 | 測試框架、自動化基礎設施、把測試寫成 code |
| 在開發流程的位置 | 下游驗證者 | 上下游同時參與，常常進設計會 |
| 跟 spec 的關係 | 讀 spec 來測 | 寫 spec、改 spec、把 spec 變成可執行的測試 |
| 程式能力預期 | 看得懂、會用工具 | 等同 RD，能寫 production-grade 程式碼 |
| 「定義 + 驗收」衝突 | 高（因此原則上不該扛 spec 維護） | 低（角色設計上就同時在兩端，是組織明知並接受的 trade-off） |
換句話說：
- 如果你是傳統 QA：原則上不該扛 spec 維護，因為這會讓你同時當定義者跟驗收者，利益衝突
- 如果你是 SDET：spec 的維護本來就在你工作的射程內——組織給你的權責設計就是「邊定義邊驗證」，因為 SDET 被預期跟 RD 同等深入產品
這個區別不是誰高誰低，是組織給每個角色的權責設計不一樣。把 SDET 的責任套在 QA 身上不公平（QA 沒那個位置、沒那個薪水、沒那個信任授權）；反過來把 QA 的「不該扛 spec」原則套在 SDET 身上也是錯的（SDET 的工作本來就包含這件事）。
實務上很多公司沒有區分清楚——掛著 QA title 的人實際被當 SDET 用，掛著 SDET 的人其實只在做 QA 的事。這時候第一件要釐清的是：你目前在組織裡實質上是哪一種角色？ 這個答案會直接決定，你扛 spec 維護是合理的工作分配，還是組織把灰色地帶塞進你的盤子。
回到原本的論點——
但這是原則層面的答案——對組織說的話。對 QA 自己說的話則不一樣：原則上不公平的事情，並不會因為原則就消失。當你身在其中，主動跨進這片灰色地帶反而可能是擴大你測試視野最快的路徑。§ 八會接著講這件事。
七、如果我是那個有話語權的 QA，我會說什麼？
先講前提：這一段的回答需要有一定的話語權——資深、跟主管有信任、講話主管會聽。如果你還沒到那個位置，下一節會講初階 QA 的版本。
我不會直接反對主管「用 AI 生測試案例」的提案。那會讓我看起來像是抗拒新工具的恐龍。
我會接著主管的話說下去：
「這個方向我同意，但我想先問一個前置問題——我們最新一次更新
specs.md是什麼時候？如果它跟現實的差距超過兩個 sprint，我們用它生出來的測試案例，驗證的會是兩個月前的產品，不是今天的產品。在跑這個 AI 流程之前，我建議先確認誰負責讓 spec 保持新鮮。這件事如果沒有歸屬，AI 加速的不是品質，是錯誤。
我可以協助設計『spec 更新 → 測試案例重生 → 驗證』的流程，但spec 更新這個源頭，需要 PM 或 RD 簽名負責——不然測出來的綠燈是假綠燈，紅燈也找不到該找誰修。」
這個說法的精神是：我不擋你的工具，但我擋這個工具的盲區。
而盲區從來不是技術問題，是組織問題。
八、那一個還沒有取得大家信任的初階 QA，到底能做什麼？
我必須誠實地承認：前面那段「我會在會議室這樣回答主管」——對一個初階 QA 來說，不一定能講得出口。
話語權這東西，不是道理對就會有的。它需要年資、需要過往幾次「我講對了」的紀錄、需要主管心裡建立起「這個人開口我得聽」的累積。一個剛入行兩年的 QA 在會議室裡講上面那段話，最常見的反應不是被採納，是：
- PM 笑笑說「對啊我也想啊⋯⋯但時程嘛你知道的」
- RD 說「文件就你寫吧反正你最熟」
- 主管說「先把測試案例寫完再說，這個之後再 review」
然後事情就過去了。下次出包還是會出，責任還是會落到 QA 身上。
更殘酷的是——「推廣文件先行的文化」這件事，從本質上就不該由初階 QA 來扛。文化是組織層級的問題，要動的是主管的主管的視野與 KPI；初階 QA 用力推，最後得到的多半不是文化變革，是同事覺得你龜毛、主管覺得你不識相。
所以更誠實的問題是：一個初階 QA，在這個結構下，到底能做什麼？
我給自己（也給你）的三個答案：
1. 默默記錄，不要默默挨打
每次你發現「文件跟現實對不上」，把那個落差寫下來——工作日誌、ticket 註解、自己的 OneNote 或 Notion 都好。不是為了告狀，是為了當有一天出包時，你有資料可以指出問題出在源頭，而不是被當成 QA 的疏失。
QA 最大的職涯風險，從來不是漏測。是漏測之後沒有人記得「為什麼會漏」。你的紀錄，就是你未來的保險。
2. 在自己的小範圍裡示範「文件先行」
你改變不了整家公司，但你可以改變自己負責的那一塊。
你經手的功能，自己整理一份「真正可信的 spec」——可能只是一頁的檢查清單、一張流程圖、一份「這個功能會跟哪些舊模組互相影響」的關聯表。每次需求變更時，主動更新它，當作自己的 source of truth。
下次主管說「我們來餵 AI 生測試案例吧」的時候，你的小範圍裡有可以用的文件，其他人沒有。這份差距不會立刻被看見，但它會慢慢累積——直到某次出包，主管心裡浮出一個問題：「為什麼 Elijah 那塊沒事？」
那個時候，你的影響力才真正開始。文化通常不是從上而下被宣告出來的，是從某一個小角落被示範出來的。
而且這件事還有一個常被低估的副作用——它會直接擴大你的測試視野。
當你開始整理「這個功能跟哪些舊模組互相影響」、「失敗時畫面長什麼樣」、「這個邊界值會碰到哪些東西」，你是在被迫把整個系統梳理一次——而梳理過的範圍，就是你能測的範圍。寫文件這個動作，本質上是把你從「跑案例的人」推向「懂這個產品的人」的過程。
寫文件原則上是 PM/RD 的事，但實務上——主動跨進這個灰色地帶的 QA，反而是能把測試範圍最快擴大的人。這是初階 QA 在沒有話語權、無法強推流程改革的情況下，能最快替自己累積專業視野的可行路徑之一。
是的，這仍然不太公平（原則上這責任不該預設在你身上）。但你不是在無償為公司做白工——你是在替自己鋪一條路。如果有一天你升上去了，這份視野會變成你比別人快的本錢。
3. 把這份觀察當作自己的職涯資本
你能看出「文件維護是組織灰色地帶」這件事——這個洞察本身，就已經超越了一個初階 QA 通常該有的視野。不要把它消耗在自我責備或內耗上。
把它累積成：
- 一篇可以拿出來分享的心得（例如這篇文章）
- 一次面試的故事（「我前一份工作觀察到一個結構性問題⋯⋯」）
- 一份未來換工作時挑公司的判斷標準。面試時你可以反問：「貴公司的 spec 多久 review 一次？」「需求改了，文件會跟著改嗎？是誰負責？」對方的回答會告訴你很多——它告訴你的不是「制度有沒有」，是「這家公司怎麼看待產品」
很多時候，初階 QA 推不動文化，真正的解法不是「再用力一點推」，是「等你升上去」、或是「換到一家肯做這件事的公司」。在那之前——
把該記錄的記錄好、該守的小範圍守好、該累積的洞察累積好。不要把整個組織的失靈背在自己肩上。
那不是你的責任。那是整家公司怎麼看待產品的責任。
九、結語：AI 不會幫一個不維護文件的組織加速，它只會放大放任的後果
寫到最後，我想講一句可能會得罪人的話：
一個組織願不願意有人專職維護文件，是這個組織願不願意對「真相」負責的指標。
維護文件這件事，看起來只是技術工作的副產品。但它其實是一個組織對「我們現在到底在做什麼」這個問題願不願意保持誠實的測試。
一個半年沒更新 spec 的團隊，本質上是這樣的團隊——做完就丟，做的當下沒有人想記住自己做了什麼。這種團隊餵 AI 不會加速，餵 AI 只會讓「假裝有 spec 可以參考」這個謊言變得更難拆穿。
QA 的工作，從來不只是寫測試案例、跑測試案例。QA 的工作是替一個組織保留「對真相負責」的最後一道紀律。當組織想用 AI 抄近路的時候，QA 要做的不是抗拒 AI，是指出那條路有沒有橋墩在底下撐著。
橋墩——就是有沒有人簽名負責讓 spec 保持真實。
如果有，AI 會是一個極好的加速器。
如果沒有，AI 會是一個極好的自欺加速器。
而我此刻在這個位置上，至少要把這件事說出來。
不是因為我反對 AI，是因為我知道有些灰色地帶的事如果沒有人做，AI 做再多也是徒勞。
這就是為什麼我相信——未來的 QA 不會被 AI 取代，但會被那些「願意管灰色地帶」的 QA 取代。因為那些灰色地帶，正是 AI 暫時還照不到的地方。