Agent 在一長串執行結果中寫了「整合測試因為缺少憑證而略過」，最後卻只留下「修改完成」。接手的人若只讀結尾，就可能把未驗證的工作送進合併佇列。這種遺漏不需要模型編造事實；資訊已經出現，只是沒有進入人的決策。

Claude 官方開發者帳號在 2026 年 10 月 2 日的貼文介紹 You should know，讓另一個代理觀察 Claude 的輸出，挑出使用者可能漏看的資訊。同串補充說明它是以 mod 實作的 side agent。

我的判斷是：這類功能值得用來降低翻找紀錄的成本，但驗收必須包含「它沒提醒的時候」。只收集成功抓到問題的截圖，無法回答團隊最需要知道的漏報風險。本文閱讀官方公告、文件與教學，沒有啟用 plugin，也沒有取得準確率、延遲或額外用量的實測結果。

先確認能不能啟用，再談放進工作流

Claude Code v2.1.287 發布說明加入 mods 與 You should know，並將後者的啟用條件寫為 first-party sessions with telemetry on。這個限制不能在轉貼指令時省略，也不能解讀成所有帳號、模型供應商與執行介面都適用。

先在 shell 查版本：

claude --version

確認至少為 2.1.287，再檢查目前帳號、組織與 telemetry 政策是否符合條件。不要只為了試用提醒功能，未經同意就改變團隊的資料收集設定。

依內建 mods 文件，You should know 預設關閉；可用的組織能在 /plugin 的 Installed 頁籤開啟 Show disabled 找到它。確認可用後，在 Claude Code 對話輸入：

/plugin enable cc-plugin-you-should-know@builtin

官方描述的呈現方式，是在較長任務中由 side agent 觀察，將值得注意的資訊放到 prompt 上方。關閉也從 /plugin 操作。若清單沒有出現，就停在可用性查核，不要另裝名稱相似的第三方套件來代替。

這裡要留下第一個驗收紀錄：版本、執行介面、是否可用、是否啟用。否則一次「沒有提醒」，可能只是功能根本沒有載入，卻被誤算成模型漏報。

一則提醒必須回到原始證據

以開頭的整合測試案例來看，提醒如果只是說「請留意測試」，人仍要重新讀完整串紀錄。比較有用的交接應能指出：哪個檢查被略過、為什麼略過，以及它會影響哪個決定。

下面是本文建議的人工評估紀錄，屬於概念格式，不是 You should know 的設定檔或回傳 schema：

case_id: integration-test-skipped
expected_attention:
  fact: 整合測試未執行，單元測試通過
  evidence: tests/integration.log 的 skip 原因
  decision: 合併前補跑整合測試，或由負責人接受缺口
observed_note: 待填入實際提醒；未出現則記為 none
review:
  evidence_matches: null
  arrived_before_decision: null
  changed_human_action: null

null 是尚未評估，不能替換成 true 來湊一份完成報告。提醒出現後，也要回到該次執行的 log、diff 或 CI 結果核對；模型指出一個疑點，並沒有替那份證據背書。

我會把「讓人重新打開了哪一段證據」當成初步收益。若每則提醒都只是重複最後摘要，或迫使人再做一次無方向的搜尋，它增加的是閱讀量。這與把人能否理解寫進交付條件相連：提醒負責把注意力帶到問題，解說還要讓接手者知道該如何判斷。

沉默有多種原因，不能直接轉成綠燈

沒有出現提醒，至少有幾種需要分開記錄的情況：功能未載入、任務沒有需要提醒的事項、觀察者沒有抓到事項，或提醒晚於人已經作出決定的時間。這些是本文的驗收分類，不代表官方已提供對應狀態或診斷 API。

尤其是最後一種：部署已經執行，提醒才指出某個假設未確認。即使內容完全正確，對阻止這次部署而言也已太晚。評估時除了有沒有提醒，還要標記它出現在哪個決策點之前或之後。

因此，合併與部署仍應讀取既有的驗收證據：必要檢查是否真的執行、結果是否對應這個 commit，以及需要的核准是否存在。沒有提醒，不得補成「所有檢查通過」或「風險已接受」。 這是團隊應另外實作的停止規則，不能只交給觀察代理記住。

站內的 Herdr 注意力佇列處理「哪個任務正在等人」。本篇多了一個更細的問題：同一個任務裡，哪些已出現的資訊需要人介入？兩者都能改善交接，但都需要可追溯的完成條件。

用已知案例檢查漏報，別只數提醒次數

第一次評估可以選一個不會觸及正式服務的練習 repository，固定任務與驗收條件。先由人寫下哪些資訊應影響交付，再觀察 plugin 實際提供什麼。不要看完提醒才決定什麼算重要，那會把評分標準往結果靠攏。

我會準備這幾類案例；它們是測試設計，不是宣稱 plugin 已能辨識的功能：

檢查被略過，但結尾像是完成

保留一份明確標示 skipped 的測試輸出，以及只提到成功項目的任務摘要。要觀察的是它能否把「未執行」帶回人的視野；未執行不能被改寫成失敗，也不能被省略成成功。

實作偏離原本的限制

任務要求維持公開介面，變更卻修改了回傳欄位。檢查提醒是否指向原限制與實際差異。若只是泛泛建議多寫測試，仍沒有交付足夠的決策脈絡。

問題已經解決，舊訊息仍留在紀錄

前段檢查失敗，後段修正並重跑成功。觀察者若仍反覆引用舊失敗，會製造過期提醒。評分需要核對時間與版本，不能只搜尋 log 是否曾有 error。

正常任務沒有值得升級處理的事項

準備檢查完整、限制明確且結果符合要求的控制案例，觀察是否仍產生大量沒有後續動作的提醒。沒有這組案例，就無法估計人要花多少時間排除噪音。

每次記錄應提醒事項、實際提醒、證據是否吻合，以及人工處理時間。漏掉一個已知重要事項，和多提醒一個無害疑點，成本通常不同；門檻應在試跑前由工作負責人決定，不能以單一「準確率」掩蓋差異。少量案例適合發現明顯問題，還不足以宣稱正式工作負載中的可靠性。

如果工具沒有提供重播歷史任務的介面，就在受控的新 session 建立這些情境，不要把手工貼入一段舊 log 的結果當成完整執行的等價測試。每次保留版本與實際輸入，之後才有條件比較更新前後的差異。

mod 的程式隔離，不是權限保證

官方入門教學介紹 mods 為 plugin 內的 JavaScript／TypeScript 模組，透過事件處理器與 API 改變 Claude Code 的行為。這讓提醒能靠近使用者正在工作的介面，也使「安裝一個小功能」需要接受程式碼信任評估。

mods 權限文件明確警告：mods 並未受到安全沙盒隔離；它們可透過 API 以使用者權限操作檔案、程序與網路，並消耗模型用量。mod 啟動的程序也不受 Claude Code 的 Bash sandbox 保護。

這是 mods 平台的能力範圍，不能反推 You should know 已經使用了其中所有能力；但「只做提醒」的產品用途，同樣不能證明任何同類第三方 mod 都只有唯讀權限。本文沒有審計 You should know 的實作，也未核實其模型選擇或每次提醒的成本。

團隊若要自行寫觀察 mod，我會把輸出限制在提示與證據入口，避免讓同一段程式同時負責觀察、代替使用者核准，再執行部署。額外的權限越多，評估重點就越不能只看提醒文案是否貼心。

第一輪只問：它有沒有改善一次真實交接？

先挑一種經常漏看的資訊，例如「哪些檢查沒有跑」，保留原本的 CI 與人工核准，完成一小批受控案例。比較有提醒與沒有提醒時，人找到證據並作出正確決定所需的時間，同時列出漏報、過期提醒與無效打擾。

若重要資訊仍反覆漏掉，不能靠「多看一眼通知區」補救；應把該項條件放入確定性的交付檢查。若噪音使人開始忽略提醒，就從 /plugin 關閉，再調整工作流或等待功能改善。

下一次 Agent 說完成時，先找一條你最容易漏看的驗收資訊，寫出它的證據位置與影響的決定。用這條案例測試提醒，才知道多一個觀察者究竟省下了多少人工搜尋。