第 24 天｜新同事找到八個問題，只有六個能開單

前言

前天，新同事找到八個疑似問題。昨天，我們把其中六個交給另一位同事獨立驗證，他也成功重現了；另外兩個還沒送驗。新同事準備把驗過的問題開成單，但在交出去之前，我們還得確認：這個行為真的不符合規格嗎？證據齊不齊？以前是不是報過了？

如果沒查清楚，開發人員收到單子後，還是得回頭追問。我們期待收到「修好了」，結果先收到的卻是「截圖呢？」所以今天要用 issue-quality-gate，也就是「開單檢查」，把前幾天的資料一起核對。六項條件全部通過才放行，沒通過的也要寫清楚缺什麼、由誰補。

開始之前

既然我們要開始核對，那我們就先把資料放在一起：第 22 天的八筆候選、第 23 天的獨立驗證結果，以及各自的證據、信心分數和比對紀錄。接著照順序查這六件事：

1. 別人也能重現嗎？ 另一位同事獨立重跑，結果是「已確認」。
2. 證據附齊了嗎？ 找問題和重現問題的同事，各自留下步驟、證據清單和必要檔案，別人拿到就知道怎麼重現。
3. 確定是缺陷嗎？ 對照規格或使用者期待後，確認行為不對，不能還在等規格或無法判定。
4. 分數過門檻了嗎？ 達到最低開單分數，評分項目沒漏算，分數上限也沒套錯。
5. 不是已知誤報嗎？ 比對誤報清單的適用條件，不能只看到相同網址就當成誤報。
6. 以前報過了嗎？ 用指紋查同專案的已開單清單；找到舊單或已併入舊單的，都不能另開新單。

這六項不能互相抵銷，分數再高也補不了缺少的證據。其中，「別人也重現了」只確認現象會發生，是否違反規格仍要另外判斷。這就是為什麼昨天驗過了，今天還要再查。

動手試試

資料和條件都準備好了，接著就請助手來查。跟前兩天一樣，我們可以直接用一句話交代任務。

這次先回到負責安排探索與驗證的對話，因為它知道候選清單和驗證結果在哪裡。第 23 天那位只收盲驗資料的同事，手上未必有完整資料，所以總檢查要交回這裡。在同一個測試工作目錄中，把下面這段貼進助手的對話輸入框：

用 issue-quality-gate 檢查剛才那輪的八筆候選，連同 bug-verifier 的結果和雙方證據一起核對。
把結果存到這一輪的 gate.yaml，回報幾筆放行、幾筆待人判斷、幾筆擋下，以及沒通過的原因。
這次只檢查和留紀錄，不開單。

這樣就把任務交出去了。技能裡已經列好六項檢查，我們不用每次重寫，只要讓助手知道要查哪一輪、去哪裡拿資料。這和第 22 天請 bug-hunter 開跑的方式相同，都能直接用自然語句呼叫。

換了對話，就把路徑寫清楚

不過，如果你換了對話，對面的助手就不知道「剛才那輪」是哪一份。這時我們把檔案位置補上，讓它照路徑去找即可，不需要從頭解釋整個流程。

下面用兩筆登入問題示範怎麼寫：F-001 是同時超過 50 筆登入請求時，逾時並回傳 502；F-002 是載入圖示一直轉。這是模擬案例，路徑依專案規則寫成，檔案並非已經存在。換你操作時，請改成自己那輪的位置：

請用 issue-quality-gate 檢查下面這一輪，只檢查和留紀錄，不開單。

工作目錄：sdet-skills/
專案：checkout-svc
輪次：20260921_login-timeout
候選清單：output/sessions/20260921_login-timeout/candidates.yaml
驗證結果：
- output/sessions/20260921_login-timeout/verdicts/V-F-001.yaml
- output/sessions/20260921_login-timeout/verdicts/V-F-002.yaml

請讀取候選與驗證結果各自指向的證據檔，依技能規則逐項檢查。
找不到檔案或資料對不上時，請回報缺什麼，不要猜。
結果存到 output/sessions/20260921_login-timeout/gate.yaml，
最後回報幾筆放行、幾筆待人判斷、幾筆擋下，以及下一步要補什麼。

有了這些位置，助手就能從 sdet-skills/ 底下讀取候選與驗證結果，再沿著裡面的證據路徑往下查。例如，原始證據放在 output/evidence/20260921-login-timeout-F-001/manifest.md，獨立驗證的證據則放在 output/evidence/20260921-login-timeout-F-001-verifier/manifest.md。兩份都得實際讀到，不能只看路徑有填就放行。

所以你只需要選一段提示詞：沿用原對話就用短版，換了對話再補上路徑。任務交代完，接下來就看助手查出了什麼。

跑完之後

助手交回 gate.yaml 後，我們先看每筆的六項檢查，再看最後怎麼分類。沿用剛才的登入範例，假設第一筆全部通過，第二筆卻查到舊單，兩筆就會有不同的去向。

下面的欄位保留英文，方便工具讀取。你可以把 pass 看成通過或放行、fail 看成未通過、hold 看成待人判斷、block 看成擋下：

# output/sessions/20260921_login-timeout/gate.yaml
- project: checkout-svc
  session: 20260921_login-timeout
  finding_id: F-001
  level: api
  evidence_levels: [api]
  candidate: "login|http-502-timeout|concurrent-login"
  checks:
    reproducible: pass
    has_evidence: pass
    oracle_passed: pass
    confidence_ok: pass
    not_false_pos: pass
    not_duplicate: pass
  result: pass
  blocked_on: null
  existing_issue: null

- project: checkout-svc
  session: 20260921_login-timeout
  finding_id: F-002
  level: ui
  evidence_levels: [ui]
  candidate: "login|loading-spinner-stuck|submit-login"
  checks:
    reproducible: pass
    has_evidence: pass
    oracle_passed: pass
    confidence_ok: pass
    not_false_pos: pass
    not_duplicate: fail
  result: block
  blocked_on: "已有相同指紋的舊單，交給負責分派問題的同事確認是否補證，不另開新單"
  existing_issue: "output/issues/482-login-loading.md"

你會看到，第二筆只有「沒有重複」這項未通過，就被擋下了。同一個問題開兩張單，通常不會修得比較快。因此，助手會回報：1 個放行、0 個待人判斷、1 個擋下。 接手的同事再順著舊單位置，確認是否要補上新證據。

但知道結果之後，我們還得能核對理由。所以正式交付時，每項判斷都要查得回驗證結果、證據、計分門檻和比對紀錄。下面回頭看原本那八筆問題，就能知道為什麼這一步不能省。

再看前面八筆問題的實際紀錄

第 22 天那輪，當時記下的是六筆放行、兩筆待人判斷。乍看都有去向，但把各項結果攤開，就會發現後兩筆的分類不太對：

問題	能重現	證據齊全	確定有缺陷	分數足夠	不是誤報	沒有重複	當時結果
C-01～C-06	✅	✅	✅	✅	✅	✅	放行
C-07	❌	✅	❌	❌	✅	✅	待人判斷，現在應先擋下
C-08	❌	❌	✅	✅	✅	✅	待人判斷，現在應先擋下

先看放行的 C-05。它有 V-C-05 的獨立驗證結果，附上 verifier-run/C-05-qty-leak.png；分數是 0.80，高於當時的 0.7 門檻，已開單清單也沒有重複問題。這些依據都查得到。

再看 C-07 和 C-08，它們在「能重現」那欄打叉，卻是因為根本還沒送驗，不能解讀成驗過但重現不了。既然缺了必要條件，就得進一步查清楚，為什麼當時只列成待人判斷。

以畫面拼字問題 C-07 為例，它當時只有 0.45 分，低於 0.7 的門檻，因此沒送盲驗，也缺少文案規格。如果我們只看分數，會覺得留給人判斷就好；但它連獨立驗證和判準都沒有，所以應先擋下。接著請人提供文案規格，或決定另走文案修改流程；要照一般缺陷流程開單，就得補齊判準和盲驗。

C-08 則缺少不同解析度下的佐證，也沒送盲驗。把狀態填成「待人判斷」，缺的證據也不會自己長出來，所以這筆同樣應先擋下，等補證據、完成驗證後再查一次。

查到這裡，我們就知道後兩筆依現在的規則都應先擋下。不過，這次只是回頭檢討分類，沒有補做驗證，因此舊紀錄仍保留「六筆放行、兩筆待人判斷、零筆擋下」，不把它改寫成重新驗過的結果。

誤報也要看適用條件

前面兩筆是該擋下卻沒擋下，C-02 則剛好相反，差一點被誤報清單裡的 /users/me 回傳 401 規則誤擋。

光看網址，兩者確實一樣；但那條規則只適用於未登入，C-02 卻是在登入後，預期回傳 200，因此不符合。這也提醒我們，比對時要把適用條件看完，再把差別記下來，下一位同事才知道它為什麼通過。

背後怎麼做

看過這幾筆結果，我們就能把前面的短提示詞和背後的流程接起來：提示詞負責交代要查哪一輪，技能則規定資料怎麼核對、條件怎麼判。

實際執行時，通常由值班協調技能（duty-oncall）收齊候選和獨立驗證結果，再交給開單檢查。助手會先讀 references/agent-handoff.md 和 references/config-resolution.md，確認候選與驗證結果的專案、輪次、問題編號一致，專案也符合探索任務書。接著讀取同專案的設定，以及 output/known-false-positives.yaml 和 output/issues-index.yaml。設定不存在或舊資料歸屬不明，就先回報，不能拿其他專案的資料代替。

核對時若發現缺少驗證結果，就由負責安排流程的助手先送盲驗，只交重現步驟、原始證據和操作限制，不附原本的評分與結論。若送不了，就記重現檢查「未通過」、整筆「擋下」，並說明待驗原因。

驗證結果找到了，接著才有辦法查雙方各自的證據。畫面操作需要關鍵截圖、步驟、主控台與網路紀錄，以及操作追蹤檔；直接呼叫程式介面則需要請求紀錄、原始回應和可重現的請求，不必補瀏覽器截圖。兩種操作都有，就兩邊都查，不能共用一份證據當成驗了兩次。

查完後，怎麼決定去向？

就算核對時已經發現缺漏，助手還是要依固定順序查完六項，才能一次交代清楚缺什麼。等每項都有結果，再決定整筆問題要交到哪裡：

結果	什麼時候用	接下來做什麼
放行	六項全部通過	交給問題分派技能（triage）依授權開單；範圍清楚、可以修，再交給缺陷修復技能（bug-fixer）
擋下	缺規格、沒有通過獨立驗證、證據不全、命中誤報或已經有單	寫清楚原因；可補的退回補齊，重複的連到舊單
待人判斷	沒有必須擋下的條件，但分數不足，或是否算缺陷仍需要人確認	寫清楚要請誰判斷什麼，暫時不開單

照這個順序，就會先把缺盲驗的問題擋下，不會像 C-07 當時那樣，只因分數低就列成待人判斷。至於分數夠不夠，則讀取設定中的 confidence.min_to_file，用同一個門檻來核對。

分好類後，我們還要交代下一步。未放行原因填在 blocked_on：如果你只寫「證據不足」，接手的人不知道要補什麼；寫成「缺少窄螢幕的操作紀錄，請原發現者補齊後送驗」，他才知道怎麼接。重複問題則另外填上 existing_issue，連回舊單。

留下紀錄，再交給下一位同事

原因和下一步都寫好了，這筆問題才算交接清楚。開單檢查的工作也到這裡為止，它不開單、不改產品程式，也不改候選內容；接下來由負責分派或修復的同事，依授權接手。

如果有人要求例外放行，就依 config/governance.yaml 留下誰、何時、為什麼。例外不能取代證據或獨立驗證，也不能讓重複問題另開新單；資料補齊或判斷修正後，仍要重跑六項檢查。

為了讓接手的人查得到，結果也要分輪存好。舊實驗放在 output/gate.yaml，現在則像範例一樣，放進各輪的 output/sessions/20260921_login-timeout/gate.yaml。

存好後，再依專案、輪次、問題編號回填第 20 天的校準紀錄；找不到或對到多筆就回報，不要猜。不過，回填時要記得：擋下只代表這次不能開單，不代表不是缺陷。 所以我們先填檢查結果，人的最終判斷則等實際收到後再補。

今天學到什麼

今天我們把「能重現」之後的開單條件補查一遍，也找出兩筆舊紀錄的分類問題。通過的交出去，沒通過的就說清楚缺什麼、找誰補，問題才有人接著處理。

有了這份交接，明天新同事就能開始修。他會先重現，再用測試抓住問題，然後才改程式；修完可以在授權範圍內提出合併請求，合併仍留給人。

---

作者備忘錄 — 正式出版前應移除

章節大綱

1. 前言：找到問題之後，為什麼還要檢查才能開單。
2. 開始之前：把六項開單條件寫成讀者能回答的問題。
3. 動手試試：先給承接前兩天的短提示詞，再補換對話時的具體路徑版本；路徑範例明確標為模擬案例。
4. 跑完之後：先看結果檔，再回顧八筆問題的歷史結果，說明兩筆待人判斷為何應先擋下，以及誤報規則的適用範圍。
5. 背後怎麼做：處理順序、交接、授權、例外與校準紀錄。
6. 今天學到什麼：未放行的問題要有下一步，銜接隔天的修復流程。

編輯注意：模擬案例與歷史紀錄分開呈現。不要把重新解讀舊結果寫成已經補做驗證。

參考資料

1. Michael E. Fagan（1976）《Design and Code Inspections to Reduce Errors in Program Development》，IBM Systems Journal 15(3) - 正式檢查要有明確的進入與結束條件，軟體業「閘門」概念的源頭
2. Watts S. Humphrey（1989）《Managing the Software Process》 - 把進入與結束條件制度化，說明為什麼判準要寫死而不是靠當下判斷
3. James Reason（1990）《Human Error》 - 瑞士起司模型：單一防線一定有洞，六條都要通過，就是多層防護而不是一道大門
4. Marilyn Strathern（1997）《'Improving Ratings': Audit in the British University System》，European Review 5(3) - 古德哈特定律的常見表述來源，說明為什麼放行率本身不能當成績效指標
5. 本專案 skills/agents/issue-quality-gate/SKILL.md - 六條判準與分流
6. 本專案 output/gate.yaml - 實跑輸出
7. 本專案 config/governance.yaml - override_gate 的留痕規則