九張未分類的 issue，擺在一個開源專案的 GitHub 頁面上。有的是使用者含糊描述的 bug，有的是天馬行空的功能許願，有的甚至只是抱怨。維護者要做的第一件事，往往不是寫程式，而是判斷：這個值得做嗎？這是 bug 還是需求？我現在能處理，還是要先問清楚？這個決策動作，在軟體工程裡有個專有名詞——triage（檢傷分類），借自急診室的語彙，意思是在資源有限的情況下，先決定誰先被救。
Matt Pocock 在這支影片裡談的，表面上是一個他自己寫的 Claude Code 技能（skill），名字就叫 triage。但真正有意思的地方不在工具本身，而在於它揭露了一個正在發生的轉變：當 AI agent 已經有能力獨立完成整張票券的工作——診斷、寫測試、修復、推送——這時候，團隊的瓶頸不再是「誰來寫程式」，而是「誰來決定這張票值不值得被寫」。分類本身，變成了新的稀缺資源。
個人開發者的方法論，為什麼在團隊裡會失靈
Matt 開場點出一個容易被忽略的落差：許多針對個人開發者設計的技能配置，拿到團隊場景裡會直接卡住。一個人單打獨鬥時，你腦子裡本來就有一份隱形的優先順序清單，不需要外顯出來。但一旦牽涉到團隊協作、處理別人的想法，或是替別人的 codebase 做決策，那份隱形清單就必須變成可以溝通、可以稽核的東西。誰提的這個功能該做？這份 bug report 到底有沒有重現？這件事現在能不能丟給 agent 去做，還是得先有人看過？
這其實是任何維運過一定規模專案的人都懂的日常煩惱，只是過去這套判斷全靠人腦記憶與直覺，沒有留下痕跡。等到專案規模變大、issue 越堆越多，這種全靠記憶的分類方式會先崩潰——不是因為判斷力不夠，而是因為沒有一個穩定的結構讓判斷可以被重複、被交接、被自動化。
用標籤做出一台狀態機
Triage 技能的核心設計，說穿了就是把 GitHub 的 label 系統，拿來當成一台簡單的有限狀態機用。這裡有兩層分類邏輯疊在一起。
第一層是「這是什麼類型的問題」，目前只有兩種：bug 與 enhancement。這一層基本上是業界共識，沒什麼新意。
真正有意思的是第二層——「這張票現在處於什麼狀態」，一共五種：needs triage（還沒人看過，等維護者判斷）、needs info（卡在等回報者補充資訊）、ready for agent（規格已經寫清楚，可以直接丟給無人看管的 agent 去做）、ready for human（需要人親自介入實作）、won't fix（不會被處理）。
規則很簡單但很硬：每張經過分類的票，必須同時攜帶「恰好一個」類型標籤與「恰好一個」狀態標籤，不能又是 ready for human 又是 needs triage。這種互斥性正是狀態機的精神——任何時刻，系統只能處在一個明確定義的狀態，不存在模糊地帶。Matt 直言這是他個人偏好的設計哲學，熟悉他過往內容的人大概不會意外：狀態機幾乎是他看待一切工程問題的預設鏡片。
這套設計真正的巧思，其實藏在 ready for agent 這個狀態的門檻裡。要把一張票推進這個狀態，不是隨手貼個標籤就好，你必須先寫出一份給 agent 看的工作說明（agent brief）。換句話說，狀態的轉換本身內建了一道品質關卡——逼迫人（或負責初步分類的 AI）先把模糊的訴求轉譯成一份 agent 能夠獨立執行的具體任務。這比單純的看板欄位移動更有約束力，因為欄位可以隨手拖動，但寫一份說明書需要真正想清楚問題是什麼。
分類的「已知邊界」哪裡來：一份不會做的事的清單
一個自然會浮現的疑問是：agent 怎麼知道一個功能請求算不算合理？它又不是專案的原作者，憑什麼判斷這東西該不該做？
Matt 的答案是一個叫 out-of-scope 的目錄，裡面存放的是他過去用這個技能處理過、已經明確決定「不會做」的功能與需求，每一條都寫成類似架構決策紀錄（ADR）的格式——但專門用來記錄「不做什麼」，而不是「做了什麼」。舉例來說，他明確寫下 Sandcastle 不會提供一層抽象來組裝 Dockerfile 或管理基礎映像檔。
這個設計解決的問題其實很本質：AI agent 沒有記憶，每次對話都是一張白紙，如果沒有外部化的決策紀錄，它就無法「記得」上一次已經拒絕過類似的請求，只能每次都從零開始判斷，甚至給出前後矛盾的建議。把「拒絕的理由」寫成持久化的文件，等於是把維護者的品味與判斷力，轉譯成一份可以被檢索、可以被引用的知識庫。agent 在看到新的 enhancement 類型 issue 時，會去比對這份清單，一旦命中，就可以直接關閉，不需要每次都驚動人類重新裁決。
這裡其實暗示了一件更大的事：AI 協作要規模化，靠的從來不是模型變聰明，而是有沒有把組織裡那些「本來只存在某個人腦子裡」的隱性知識，系統性地寫下來、變成 agent 能讀取的外部記憶。
實際跑一次：從九張未分類票券到一個修好的 bug
影片中段，Matt 直接示範在自己的 Sandcastle repo 上跑這個技能。他打開一個新的 Claude session，輸入 triage，再補一句「只給我還沒分類過的 open issue」。agent 自己去探索 repo 結構，判斷出這是用 GitHub issues 管理，抓出九張未分類的票，然後被要求「幫我把基本標籤都貼上」——先做最初步的分類，減少 Matt 自己需要做的決策量。agent 隨即把票分成 bug 與 enhancement，並統一標成 needs triage。
接下來 Matt 挑了一張具體的 bug（編號 477）深入處理。agent 先給出建議：判定為 bug，並建議直接推進到 ready for agent，附上它認為已經找到的根因與 stack trace。但 Matt 在這裡做了一個關鍵的介入——他沒有照單全收，而是懷疑 agent 對回報者提供的資訊「太輕信」了，於是要求它換用另一個診斷技能，親自重現這個 bug，而不是只採信別人的描述。
這個小動作其實是整支影片裡最值得留意的細節：分類技能推薦的結論，不是拿來直接執行的指令，而是一份需要人類再篩一層的草案。Matt 全程盯著左下角的 context 用量（46.5K，budget 抓 100K），清楚知道這個對話還有多少餘裕可以拿來做診斷與修復，而不是無限制地把工作丟給 agent 自由發揮。
後續 agent 確認了根因——某幾個變數裡混入了未替換的任務 ID 佔位符語法，若使用者沒有實際傳入對應值，就會直接拋出錯誤。修法是把這個語法換成一種不會報錯的佔位符寫法。agent 接著自己補上了回歸測試，斷言修好之後產出的檔案裡不會再殘留未解析的任務 ID——這個做法與 Matt 另一個 TDD 技能的模式如出一轍：先建好回饋迴圈（失敗的測試），再在這個迴圈裡把問題修好。最後整組測試通過、型別檢查也過關，Matt 讓 agent 把變更推上 main，關閉原本的 issue。
分類的本質：排隊管理，而非技術判斷
Matt 講出一句頗有分量的觀察：管理無人看管的（AFK）agent，本質上很大一部分工作其實是排隊管理。分類這件事，做的不是解決問題，而是修剪一條隊列，並且在提出想法的人類與執行想法的 AI 之間，充當一層翻譯。
這個框架有意思的地方在於，它把「觸發 agent 去做事」這個看似技術性的動作，重新定義成一種資源調度問題——需要決定的不是「怎麼做」，而是「現在該讓誰做、以什麼順序做」。他提到自己的執行 agent（Sandcastle，他所謂的無人值守軟體工廠）只會去抓 ready for agent 這個標籤的票，完全不碰其他狀態的票。這代表整套系統的安全閥，其實不在 agent 的判斷力上，而在標籤系統這個看得見、可審計的閘門上——agent 再強，沒有明確標記為「可以做」的票，它就不會碰。
這套機制也不局限於 issue。Matt 展示了同樣的邏輯延伸到 PRD（產品需求文件）與依附在 PRD 底下的具體 ticket——一份關於 worktree 鎖定機制、避免多個 agent 同時存取造成衝突的 PRD，同樣被標成 ready for agent，等著 agent 撿走執行。這說明 triage 不是一個只服務 GitHub issue 的小工具，而是一套可以套用在任何「人類產生模糊想法、agent 消化成具體產出」場景的通用協定。
這件事真正在說什麼
把整支影片抽離具體的標籤與指令來看，它其實回答了一個更根本的問題：當 AI 已經能夠端到端完成一張票的診斷、修復、測試，團隊真正需要投資的能力，不再是「怎麼寫出更好的 prompt 叫它做事」，而是「怎麼設計一套讓判斷可以被記錄、被複用、被交接的分類制度」。狀態機式的標籤系統、記錄拒絕理由的 out-of-scope 清單、要求先寫工作說明才能放行的 ready for agent 關卡——這些都不是花俏的自動化技巧，而是把原本活在資深維護者腦中的判斷力，轉換成一套外部化、可被團隊與 agent 共同依循的結構。
模型會不斷變強，但誰有資格決定「這件事現在值得做」，以及這個決定如何被寫下來讓下一個人（或下一個 agent）看懂，恐怕才是接下來真正稀缺的東西。