AC id 追溯鏈讓改規格的影響變成一個 grep
「改這條規格會影響誰」本來是一個要靠人記得的問題。給每條驗收準則一個唯一 id，並要求測試名稱引用它，這件事就變成
grep算得出來的。
三段鏈
spec 驗收準則章節
AC-03 | 額度不足時拒絕轉帳 | Given 餘額 100 且轉帳 200 / When 送出 / Then 回 400 INSUFFICIENT_BALANCE 且餘額不變
測試命名
it('[AC-03] should_reject_transfer_when_balance_insufficient')
CI 兩道檢查
(i) 每個 AC id 至少被一個測試名引用，否則紅
(ii) 測試引用不存在的 AC id 也紅 ← 防止 spec 刪了行為、測試還留著
紅利
改 AC-03 → grep AC-03 → 立刻知道哪幾條開發線要動。這把「改規格的成本」從一個感覺變成一個可估算的數字，也是規格變更 SOP 裡「影響半徑分析」能自動化的基礎。
成本極低是重點
不需要 Gherkin parser、不需要 step definition、不需要第二份文件——只是一個測試名稱前綴加兩條 CI 檢查。這也是它值得最先導入的原因。