eleanoe75227 測試計畫產製（RFP可追溯）
這個skill在解決什麼問題
AI寫測試步驟最容易「歪掉」的原因，不是能力不夠，是餵的輸入層級錯了。RFP或需求規格書通常只寫「系統要提供什麼功能」，不會寫畫面長怎樣、按鈕叫什麼、欄位怎麼排、操作幾步完成。如果只拿RFP文字叫AI寫測試步驟，AI沒有真正的依據，只能憑常識腦補一套「聽起來合理但跟系統實際長相沒關係」的流程——這就是歪掉的來源。
真正決定測試計畫品質的，不是「有沒有把RFP條文抄進去」，而是每一條測試案例的內容能不能指出具體依據：這條案例在測哪一條RFP需求、對應SA文件哪一段設計、範圍深淺是不是查過驗收條款而不是憑經驗猜的。這份skill把這幾個「容易被跳過的檢查點」寫成固定流程，逼自己在對的階段回頭找對的來源，而不是靠AI一次生成就假設是對的。
追溯鏈的完整樣貌：RFP需求（條文通常抽象）→ 透過需求訪談與會議紀錄具體化（這一步通常是SA主導，不是PM或AI）→ SA文件描述系統實際設計 → SD依SA文件開發出功能 → 測試計畫驗證功能是否符合SA文件，進而回推是否滿足RFP需求。好的測試計畫要能雙向查：從RFP條文查到對應的測試案例，也能從案例回推是在回應哪一條RFP。
開工前：先做素材盤點（不要跳過）
在動筆寫任何一條測試案例之前，先確認手上有沒有這幾樣東西，缺了要明確跟使用者說缺什麼、為什麼需要，不要用「假設」或「業界常見做法」頂替：
| 素材 | 用途 | 缺了怎麼辦 |
|---|---|---|
| RFP需求清單/編號表 | 決定「測什麼」，需求範圍的骨架 | 若專案已有PM與SA協同定案的分類，直接沿用；沒有的話，這通常該由PM+SA協同產出，不要自己發明一套編號規則頂上去，提醒使用者先去對齊 |
| SA文件全文 | 決定「怎麼測」，步驟與畫面細節的唯一依據 | 沒有就先停下來要，不能靠RFP文字腦補操作流程 |
| 歷次會議紀錄／訪談紀錄 | 把RFP抽象條文具體化的實際內容，往往比RFP原文更準 | 沒有的話，複雜的需求細節可能寫不準，要提醒使用者這塊可能有缺口 |
| RFP驗收條款原文 | 決定測試範圍要多深（見下方「定測試範圍」） | 沒有就不能自己判斷範圍，先問使用者要 |
| （可選）歷史參考文件 | 舊版測試計畫或客戶既有範本，決定文件排版格式 | 沒有就先提醒使用者需要先決定排版依據，不要憑空生一套格式 |
定測試範圍：查驗收條款原文，不要憑經驗猜
測試要測多深、要不要包含既有功能的迴歸驗證，必須回頭讀RFP驗收條款的字面用詞，不能用「測試常識」或「保險起見多測一點比較安全」的直覺去補。同一份RFP裡，不同系統/模組適用的條款常常不一樣——例如「新建／再造」系統跟「增修既有」系統的驗收要求文字通常不同，增修部分往往只要求驗證異動範圍本身，不代表要對沒異動的既有功能重新出具一輪完整測試。
真實案例：某系統建置案的一次增修案裡，把沒有異動的既有功能測試案例整批當「迴歸測試」塞進測試計畫，理由是「迴歸測試比較保險」。事後翻驗收條款原文才發現契約根本沒要求這樣做，結果134份多餘案例全部作廢重寫，文件從263頁砍到161頁。教訓：範圍決策要能指出「契約哪一條要求這樣做」，指不出來就先問，不要自己加碼。
範圍決策做完後，用一句話寫下依據（例如「依RFP驗收條款X條，本模組屬增修，僅測異動範圍」），而不是直接跳進去寫案例——這句話寫不出來，代表範圍還沒想清楚。
建需求↔測試案例對應
需求編號沿用專案既有的分類（通常是PM與SA已協同定案的清單），不要自己發明新編號規則——自訂的編號查不回原始需求，會讓整份文件失去可追溯性。
每一條測試案例動筆前，先確認它對應SA文件的具體段落／章節／附件，對不到出處就先跳過或標記待確認，不要憑案例名稱聯想「大概是這個功能」就寫下去。建議先產出一份精簡的「需求編號｜對應SA文件出處｜測試案例編號」對照表，自己（或請使用者）掃一眼有沒有大範圍對不到出處的情況，再展開每條案例的詳細步驟。
寫測試步驟與規格
步驟、畫面欄位、操作流程一律依SA文件描述的實際設計寫，不要只靠RFP文字去猜操作流程——RFP通常只講「要做什麼」，不會講「畫面長怎樣、按幾下」。這是AI寫測試步驟最容易「歪掉」的根因，也是本skill存在的核心理由。
處理落差與不確定項：標記，不要自己選邊
實際做的時候一定會遇到兩種狀況，處理方式都一樣：標記出來交還人判斷，不要自己拍板。
- RFP原文與SA文件描述對不上（例如角色權限、功能架構描述不一致）：不要自己選一個版本寫死，列入待確認清單。
- 沒有明確依據的預期結果／判定標準：不要發明一個「聽起來合理」的答案，一樣標記待確認。
輸出時建議用視覺上明顯可辨識的方式跟確定內容區分開（例如變色文字、統一的標記符號如「〔待確認〕」），讓使用者或SA一眼就能抓出哪些是還沒拍板的內容，而不是混在正文裡容易被忽略。這不是額外的裝飾，是防止「沒有依據的內容被誤當成定案內容發出去」的最後一道防線。
文件產出格式
先問：單一文件，還是拆成多份子計畫？
不同專案的協作方式不一樣，這件事要在開始寫內容之前先問使用者，不要自己預設：這次測試計畫有幾位負責人／SA參與審閱？是各自只看自己負責的模組，還是少數人通篇審閱整份文件？
這個決策要趁早問、不要等寫完再拆，理由是結構安排要在寫內容的當下就決定，不是事後補救的問題——跨系統共用的章節（例如專案概述、測試方法、整合測試）要在寫的時候就標明「共用，不要在子檔案裡修改」，各系統自己的章節要維持乾淨獨立、方便整段抽換，這些都是下筆時的編排習慣，寫完才想拆，共用內容跟各模組內容常常已經糾纏在一起，拆不乾淨。
- 多人各自負責不同模組 → 建議產出「單一完整主文件」當正式版本，另外切出「每人一份、只含自己模組章節＋共用章節（標明請勿修改）」的子檔案給各自審閱／編輯。子檔案改完後，用章節標題比對的方式把有變動的段落整段取代回主文件（同標題整段替換，不是逐字手動貼），避免漏改或重複。這個抽換/合併技巧的具體做法見
references/chapter_split_merge.md。 - 只有一人或少數人通篇審閱 → 不需要拆，直接單一文件即可，不要為了拆而拆。
若使用者提供了歷史參考文件（舊版測試計畫、客戶既有範本），優先沿用它的架構與排版慣例產出新文件，不要另外設計一套。這麼做除了省事，更重要的是延續性——同一個客戶/專案的文件家族保持一致格式，對方審閱時才不會多一層適應成本。
若文件涉及目錄與頁碼，常見的坑是「產出時就假設頁碼正確」——實際上內容定案前頁碼會一直變動，一次生成填死頁碼幾乎必錯。建議走「先產出→轉PDF確認實際頁碼→回填目錄→重新產出」的修正流程，反覆到頁碼與內容一致為止，而不是手動猜頁碼填死。若原始格式是Word（.docx），要保留既有排版時優先直接編輯壓縮檔內的XML，而不是用文件處理套件另存——另存常會把頁首頁尾的參照關係、版面設定重新實體化，導致跑版。這個技巧的完整說明見 references/docx_reference_reuse.md。
若使用者沒有提供參考文件，先提醒需要決定排版依據，不要憑空生一套格式。
最終覆核：這一步無法被自動化
明確告知使用者：以上檢查點能防住「跳步驟、憑空編造」這類容易犯的錯，防不住範圍或架構本身判斷錯誤這種需要通盤理解才看得出來的問題（就是前面提到的114年迴歸案例那種——那個問題不是被流程擋下來的，是使用者事後把完整草稿從頭看過一遍才抓到的）。
所以在開工前，或至少在產出完整草稿後，要明白告訴使用者：這份文件仍然需要使用者或SA對完整內容做一次通篇人工審閱，這不是這個skill、也不是任何自動化流程能取代的一步。
補充資源
references/docx_reference_reuse.md：延用既有Word文件排版時的XML編輯技巧、目錄頁碼多輪修正流程的具體做法（來自實際專案經驗，適用於任何需要延用舊版格式的正式文件產出，不限測試計畫）。references/chapter_split_merge.md：單一主文件跟多份子檔案之間互相抽換／合併章節的具體做法（按標題比對整段取代），適用於任何需要「多人各自編輯一部分、最後合併回同一份文件」的情境，不限測試計畫。