返工溯源

發現處不是產生處

你上週的返工，有幾成其實在派工那一刻就注定了？

在多代理流程裡，返工多半在審查階段才曝光，例如攻擊者加裁判的對抗式審查把產出打回。

但發現問題的地方，不一定是問題產生的地方。

審查只是最後一道看得到缺陷的關卡。缺陷本身，可能早在派工時就埋下了。

只在審查端加碼的代價

直覺反應是把審查準則加嚴，讓攻擊者更兇、裁判更挑。

問題是，這等於每次都在下游攔截同一類缺陷。缺陷照樣產生，只是被擋下來。

人工監控成本也降不下來，因為每張任務仍要靠審查兜底。

相對地，改進可重複使用的派工範本，是從源頭預防。

依序回溯三個環節

每一筆返工，都依序往回追三站：派工、執行、審查。

先看派工規格：目標、限制、驗收條件、上下文有沒有給齊。

規格齊全，再看代理執行是否出錯。執行也沒問題，才懷疑審查誤判。

這個順序能分辨：是代理能力不足，還是派工時資訊沒給齊。

派工規格的四種缺口

派工環節的根因，通常長成四種樣子。

目標模糊、限制沒寫、驗收條件缺漏、上下文不足。

例如沒說要相容舊 API，屬於限制沒寫；沒給測試指令，屬於驗收條件缺漏。

回溯時拿這四項逐一對照派工單，判斷會快很多。

假設案例：8 筆返工

假設你上週用 Claude Code 和 Codex 派出 20 張任務，其中 8 張被攻擊者加裁判的審查打回重做。

逐張回溯，每筆都問：派工單裡有沒有寫清楚驗收條件和限制？

結果 5 筆是派工漏寫，2 筆是代理執行出錯，1 筆是審查誤判。

也就是 5/8 ≈ 63% 的返工，在派工那一刻就注定了。

把修正放在最上游

根因集中在派工，下週該先改的就是派工範本，而不是把審查加嚴。

在範本裡加入兩個必填欄位：相容性限制、驗收指令。

同一類缺口就在源頭被擋住，不必每次靠審查攔截。

修正放在最上游，成本最低。

一張任務在攻擊者加裁判的對抗式審查中被打回。這是否代表問題就產生在審查階段？

• 是，問題產生在審查階段
• 不一定，問題可能更早產生

答案: 不一定，問題可能更早產生

審查只是發現問題的地方，不一定是產生問題的地方。很多缺陷早在派工時就注定了，例如派工單漏寫限制或驗收條件。因此要往上游回溯，才能找出真正的根因。

派工單內容依類別歸類：「把結帳 API 的回應時間降到 200ms 以下」屬於_____；「必須相容舊版 API」屬於_____；「執行 npm test 須全數通過」屬於_____；「附上相關模組路徑與架構說明」屬於_____。

答案: 派工單內容依類別歸類：「把結帳 API 的回應時間降到 200ms 以下」屬於目標；「必須相容舊版 API」屬於限制；「執行 npm test 須全數通過」屬於驗收條件；「附上相關模組路徑與架構說明」屬於上下文。

完整的派工規格包含四個要素：目標（要達成什麼）、限制（不能違反什麼）、驗收條件（如何判定完成）、上下文（代理需要的背景資訊）。回溯返工時，就是逐項檢查這四個要素有沒有寫清楚。

你用 Codex 派工新增一個 API 端點，審查時被打回，原因是新端點繞過了既有的速率限制。回頭查看派工單，發現裡面完全沒提到要遵守速率限制。這筆返工最可能的根因是什麼？

• 派工規格漏寫限制
• 代理執行能力不足
• 審查準則過於嚴格
• 審查裁判判定錯誤

答案: 派工規格漏寫限制

代理沒被告知要遵守速率限制，派工單缺少關鍵的限制，代理自然無從遵守。這是派工時資訊沒給齊，而不是代理能力不足。審查正確抓出了問題，所以也不是審查誤判。