test-independent-review-skill

Skill 寫得很開心，但它真的有用嗎？來嘗試健檢看看

大家好，我是鱈魚 🐟

現在 coding 基本上都使用 AI 了，但如果直接請 AI 審查剛寫完的程式碼，它很常就回一句「整體看起來不錯」結案，然後下一秒程式碼就壞了 ╭(°A ,°`)╮

在同一個對話裡審查自己的產出，AI 很容易老王賣瓜，是不是~~像極了某個同事~~。

整個 context 都是它「為什麼這樣寫」的理由，自然會自動護航、繞過自己埋下的地雷。(´_ゝ`)

於是腦筋一轉，召喚另一個打工仔，改由子代理人審查。( ‧ω‧)ノ╰(‧ω‧ )

子代理人的 context 沒有你跟主 AI 之前的討論，不知道這段是自己人，可以六親不認的審查。(⌐■_■)✧

試了幾次效果不錯，所以再讓兩位代理人從不同視角分工（正確性 + 測試覆蓋率、可行性 + 排程合理性...），互補性又更高 ( •̀ ω •́ )✧

最後乾脆把整套流程封裝成 skill，取名 independent-review，每次寫完東西就審查一下。

你說為甚麼不要開另外一個 AI 工具審查？抱歉我鈔能力不足。(´；ω；`)

不過寫 skill 是一回事，它到底有沒有用又是另一回事。

skill 本質上就是一段 prompt 規範，說不定一切都是 AI 幻覺。

就像人生三大錯覺：「手機震動、我能反殺、她喜歡我」，假的，都是假的。ლ(´•̥̥̥ ω •̥̥̥` ლ)

於是試著設計了一套健檢方法：預埋蟲蟲、乾淨對照組、黑盒、加上同題目跑三種審查方式互相對照，順便試試看不同模型表現差異。

本文就是這場健檢的紀錄。ヾ(◍'౪`◍)ﾉﾞ

這個 Skill 在做什麼？

independent-review 的核心流程是：

判定產出類型（程式碼 / 計畫 / 規格 / 報告 / 架構）
依類型決定兩個代理人的正交視角（例如程式碼配「正確性 + 測試完整性」，計畫配「可行性 + 排程合理性」）
並行啟動兩位 general-purpose 代理人
主 AI 整合兩份報告成三層清單
不主動修，給使用者選擇與確認

重點是「並行」、「正交視角」、「強制嚴重度標籤與位置」這三件事。

具體 skill 內容

---
name: independent-review
description: 並行啟動兩個獨立代理人對目前產出（程式碼、計畫、報告、文件、設計）做批判性審查，整合後給出優先順序行動清單
---

# Independent Review

當你完成一輪產出（不論是程式碼、設計計畫、技術報告、規格文件、PR 描述、需求評估）想避免自己的盲點時呼叫本 skill。它用**兩個獨立代理人並行**從不同角度審視同一份產出，最後由 Claude 整合為「必修 / 應補 / 延後」三層清單。

兩個代理人的視角**依產出類型動態決定**（見下方 §3），不硬綁「程式碼 + 測試覆蓋率」。

## 步驟

1. **判定產出類型**（這步決定後續兩個代理人的任務設計，不能省略）：

   先根據使用者參數或現況推論下列類別之一；不清楚就**先問使用者一個簡短問題**確認。

   | 類別 | 典型觸發 |
   |------|---------|
   | 程式碼變更 | 目前在 git 分支、有 commit diff、使用者剛完成 bug fix / feature |
   | 實作計畫 | 使用者剛寫完設計文件、plan-mode 產出的步驟列表、schema migration 規劃 |
   | 技術報告 / 分析 | 調查性文件、A/B 結果、效能分析、事故回顧 |
   | 規格 / 需求 | 功能需求文件、API 契約、使用者故事 |
   | 架構 / 設計 | 系統流程圖、元件劃分、資料流設計 |
   | 其他 / 邊界情境 | DB migration、CI/CD 設定、config 變更、純測試碼、跨類別混合——直接詢問使用者要從哪兩個視角審查 |

2. **收集審查材料**：
   - 程式碼：`git log --oneline -20` + `git diff --stat` 取得變更概觀，並將 `git diff` 全文或關鍵檔案完整內容放入 prompt（不要只給路徑讓 agent 自找，會錯讀片段）。
   - 計畫 / 報告 / 文件：取得完整檔案路徑 + 相關依賴（引用的 spec、先前版本、相關程式碼位置）。
   - 如果有**上一輪審查的結論**，整理成 checklist 傳給代理人，要求逐項驗證。

3. **依類別設計兩個代理人的視角**（原則：兩個代理人要**正交互補**，不是重疊）：

   | 類別 | 代理人 A | 代理人 B |
   |------|---------|---------|
   | 程式碼變更 | 正確性審查：驗證修復是否到位、邊界、有無新問題、API 對齊 | 測試完整性：先確認 coverage 工具可跑，可跑則實測找 0% 方法；否則檢查測試是否涵蓋新行為與邊界、品質如何 |
   | 實作計畫 | 可行性 / 技術風險：架構合理性、依賴、rollback、向後相容 | 排程 / 拆解合理性：步驟粒度、並行機會、遺漏前置條件、估工時 |
   | 技術報告 | 資料正確性 / 論證嚴謹：數據來源、推論鏈、對立假設 | 完整性 / 受眾適配：缺哪些角度、讀者能否看懂、可執行結論 |
   | 規格 / 需求 | 一致性 / 歧義：條款衝突、未定義術語、邊界行為 | 可測試性 / 驗收條件：能否寫出驗收測試、成功標準量化 |
   | 架構 / 設計 | 耦合 / 擴展性：單一職責、模組邊界、未來變動代價 | 故障模式 / 可觀察性：失敗場景、監控、性能瓶頸 |

   若情境混合（例如 PR 同時含程式碼+規格文件），**擇主要產出類型**，在另一代理人的 prompt 裡補上次要角度的檢查項。

   對於 A、B 視角天生重疊較高的類別（如「實作計畫」的可行性與排程），在每位代理人的 prompt 末段明確列出「對方負責的範圍」，要求避開重疊區、聚焦自己的視角。

4. **並行啟動兩個 `general-purpose` 代理人**（同一個 tool-use 訊息發兩個 `Agent` 呼叫 + `run_in_background: true`）。每個 prompt 應包含：

   - **背景段**：產出位置、範圍、最近的決策脈絡、上一輪結論（如有）
   - **角色段**：明確說明此代理人負責的審查視角（見 §3 表）
   - **逐項檢查清單**：把關鍵檢查點列成題目要求代理人逐一回答
   - **產出格式要求**：
     - 每項發現標示**嚴重度**（Critical / High / Medium / Low / Nitpick）
     - 每項附具體位置（file:line、段落標題、表格行）
     - 分開列出「新發現」vs「已在上一輪提出」
     - 對於 known-issue 與真正 bug 明確分辨
   - **反客套指示**：「不要說整體看起來不錯、直接指出問題」「若此項確實通過，明確標 pass」

   Prompt 應足以涵蓋背景脈絡、角色定義、5–8 條具體檢查項與產出格式；越精確產出越可用。

5. **等代理人完成**（背景任務完成會自動通知；不要主動 poll / sleep）。

6. **整合報告**（由 Claude 自己做，不要再開第三個彙整代理人）：
   - 開表格比對兩個代理人的發現是否相互印證、矛盾、或互補。
   - 將所有 action 分成三層並給明確位置：
     - **必修** — 合併 / 送出前應處理的真實 bug、破壞性變動、嚴重遺漏
     - **應補** — 短期內應追加的測試、文件段落、計畫拆解細節
     - **延後** — 另開 issue / ticket 追蹤的大型改進（架構重構、抽換 logging / 監控、共用模組拆分）
   - 每項附難度標籤（trivial / medium / hard）或預估改動規模（單行 / 單檔 / 跨檔），不要強行估時數——AI 估時普遍不準。

7. **請使用者決策**：提供明確選項（全做 / 只做必修 / 補某類別 / 僅報告）讓使用者挑，**不要擅自動手**。

## 注意事項

- **兩個代理人都用 `general-purpose` subagent_type**（需要完整讀檔與跨檔分析）；不要用 `Explore`，它只適合定位搜尋、會錯過讀取視窗外的內容，不適合批判性審查。
- **務必並行**：同一訊息裡發兩個 `Agent` 呼叫並 `run_in_background: true`，避免序列浪費時間。
- **視角要正交**：兩個代理人不能做一樣的事。程式碼是「正確性 + 覆蓋率」；計畫是「可行性 + 排程」；報告是「正確性 + 完整性」……依 §3 表選。
- **產出格式強制**：嚴重度標籤、具體位置、pass/fail 標記是必填；不符合的回報要求代理人補齊或自己標註。
- **前後端 / 跨 repo 情境**：在 prompt 中明確告知兄弟目錄路徑（例如 `../<sibling-repo>/`），讓代理人能搜相依。
- **整合階段由 Claude 親自做**：兩份報告都在脈絡裡，直接比對更準確；開第三個代理人會失真。
- **此 skill 不自動動手修復**：即使找到 Critical bug，也先呈報後等使用者指示。
- **規劃初期（從零開始）**請用 `brainstorming`；本 skill 只做「已有產出」階段的批判審查。

我書讀得不多，你不要騙我 QQ

驗證一個審查型 skill 有沒有效，最容易出現的盲點就是 AI 說的頭頭是道，實則胡說八道。(。-`ω´-)

尤其沒有足夠的背景知識可以判斷時，就很容易被 AI 拐著走。(◓Д◒)

就像「幾乎百分之百的癌症患者體內都含有大量的『氫氧基酸』，這種物質也是酸雨的主要成分，若吸入肺部甚至會導致窒息死亡，與其固體形式長時間接觸會導致嚴重的組織損傷，我們應該嚴格管制！」，聽起來很合理，但完全經不起推敲 ( ´_ゝ`)

甚麼？你說上面這段話聽起來很正確？...我敬你一杯氫氧基酸。(◐‿◑)

反之如果不用 skill、直接拋一句「請審查」也能找到相同等級的問題，此 skill 就毫無價值，徒耗 token 而已。(◞‸◟ )

於是定了四條原則：

預埋蟲蟲：每個案例事先寫好「我植入了哪些 bug、什麼嚴重度、位置在哪」當成考古題答案。代理人能不能找到，可量化打分。
加入乾淨對照組：刻意做一個沒 bug 的小案例，看代理人會不會捏造問題（誤報率）。
黑盒設計：寫一行 禁讀 GROUND_TRUTH.txt 在 prompt 裡，避免代理人偷看答案。
三組對照：對每個 case 同時跑 skill、詳細 prompt、籠統 prompt 三種審查方式，比命中率與誤報率，證明 skill 真的帶來增量價值。

評分維度三層：

結構面：skill 有沒有並行起兩個代理人？有沒有用 general-purpose？視角是不是依表格選的？
發現面：預埋蟲蟲抓到幾個？有沒有瞎掰不存在的 Critical？
流程面：最後有沒有照三層清單整合？有沒有越權自動修復？

三組 prompt 對照怎麼設計？

對每個 case 跑三組：

組別	Agent 數	Prompt 設計	對標目的
Skill	2 位並行	完整檢查清單 + 正交視角分工	實驗組
詳細 prompt	1 位	完整檢查清單 + 雙視角合一	測「並行設計是否必要」
籠統 prompt	1 位	「請審查這個」一句話 + 防污染條款	測「skill 是否必要」

「防污染條款」是哪兩條？

禁讀同資料夾 GROUND_TRUTH.txt（評分用標準答案）
禁讀 .claude/skills/ 與任何 SKILL.md（避免代理人直接抄 skill 結構）

第 1 條是黑盒測試的常識，第 2 條則是確保「籠統」這個對照組真的籠統。否則強模型會自己 ls 專案結構找到既有 skill 模板，讓對照失準 (꒪ཀ꒪)

跑完一次可同時回答兩個問題：

不用 skill 也能達到效果嗎？（籠統 vs skill）
「並行 + 正交」真的必要嗎？（詳細單 agent vs skill 並行兩位）

4 個案例設計

技術堆疊使用我熟悉的 Vue 3。(´,,•ω•,,)

Case A：Vue Composable 程式碼變更

寫了一個 usePagedList<T> composable，做陣列分頁。預埋 4 個 bug：

const items = computed(() => {
  const start = (page.value - 1) * pageSize
  const end = page.value * pageSize
  return source.value.slice(start, end + 1) // [!code error] // ← Critical：多取一筆
})

function next() {
  if (page.value <= pageCount.value) { // [!code error] // ← High：應為 <
    page.value += 1
  }
}

另外還有 pageSize = 0 無防呆、空陣列邊界沒處理。測試檔則刻意只測快樂路徑，邊界全缺。

Case B：Vue 列表分頁 composable 重構計畫

寫了一份「把三個列表頁重複的分頁邏輯抽成 usePagedList composable」的 3 天計畫。預埋：

沒有 rollback 計畫
Step 3 依賴 Step 5 才建立的 PAGE_SIZE_KEY provide token（依賴順序錯誤）
usePagedList 測試擺在 Step 4 而非緊接 Step 2（TDD 順序錯誤）
用字串 'PAGE_SIZE_KEY' 當 provide key（應改 InjectionKey<number>）
估時無拆解依據（順便埋了個計算錯誤，逐項加總 4 天卻寫「合計 3 天」(´∀`)）

Case C：`<BaseDialog>` 元件 API 規格

寫了一份共用對話框元件的 API 規格，預埋：

§2「不可關閉時不應允許點背景關閉」與 §5「重要訊息時點背景仍應允許關閉」直接衝突
「不可關閉」、「重要訊息」、「背景」全部沒對應 prop 或定義
§4「動畫應流暢」沒有量化（ms / FPS / easing 都沒）
焦點管理（focus trap、return focus、aria-*）整個沒提
「QA 跑過即可上線」不可驗收

Case D：對照組（無預埋）

刻意寫了一個乾淨的 useDebouncedRef（customRef 版 debounced ref），測試也涵蓋了初始值、延遲、連續寫入、依賴重跑、預設值。

預期：所有代理人不應標 Critical / High，至多 Nitpick / Low。

鱈魚：「對照組相當重要，以免 AI 湊字數，硬是瞎掰一堆問題 ( ・ิω・ิ)」

路人：「就像你期末考明明一題都不會，還是要硬湊幾個字那樣嗎？(´・ω・`)」

鱈魚：「說好不提這個的...(╥ω╥`)」

代理人開工

4 case × 3 組（skill 2 位 + 詳細 1 位 + 籠統 1 位）× 3 種模型（Opus 4.7、Sonnet 4.6、Haiku 4.5） = 48 位代理人，全部用 Agent + run_in_background: true 開工 ( •̀ ω •́ )✧

每位代理人的 prompt 都一致（只差 model 參數），包含：

背景段：產出位置（絕對路徑）、範圍
角色段：明確視角（如「你只負責程式碼正確性，不要評論測試覆蓋率」），籠統 prompt 組則略過
檢查清單：5–8 條要求逐條 pass / fail，籠統 prompt 組不給
產出格式：嚴重度標籤、檔案行號、通過項目分開列
反客套：「禁說『整體看起來不錯』」、「沒問題就明確標 pass」、「不要捏造，標 Critical 必須能描述觸發路徑」
禁讀 GROUND_TRUTH.txt：黑盒測試的關鍵

結果摘要

三種模型對同一份 fixture 跑同樣 prompt，光看「能不能找到蟲」差異不大，但會不會亂標 Critical / High 差很多。ԅ(´∀` ԅ)

Case A~C 預埋命中率（任一嚴重度提及該蟲蟲表示找到）

案例	模型	Skill	詳細 prompt	籠統 prompt
A 程式碼	Opus 4.7	9 / 9	9 / 9	7 / 9
A 程式碼	Sonnet 4.6	9 / 9	9 / 9	6 / 9
A 程式碼	Haiku 4.5	9 / 9	9 / 9	6 / 9
B 計畫	Opus 4.7	9 / 9	9 / 9	7 / 9
B 計畫	Sonnet 4.6	9 / 9	9 / 9	4 / 9
B 計畫	Haiku 4.5	8 / 9	8 / 9	5 / 9
C 規格	Opus 4.7	10 / 10	10 / 10	10 / 10
C 規格	Sonnet 4.6	10 / 10	10 / 10	8 / 10
C 規格	Haiku 4.5	10 / 10	10 / 10	6 / 10

Case D 對照組誤報率（預期 0 Critical / 0 High）

模型	Skill 視角 A	Skill 視角 B	詳細 prompt	籠統 prompt
Opus 4.7	0C / 3H	0C / 1H	0C / 4H	2C / 0H
Sonnet 4.6	0C / 0H ✓	0C / 1H	1C / 3H	0C / 0H ✓
Haiku 4.5	1C / 1H	1C / 0H	1C / 2H	0C / 0H ✓

其中：

C = Critical
H = High

整體看起來：

命中率：三種模型在 skill / 詳細 prompt 都接近滿分；籠統 prompt 下 Opus 還能撐到 86%，Sonnet 跟 Haiku 都掉到 6 成
Case D 誤報：Haiku 在 skill / 詳細都標 Critical，三種模型裡最愛找蟲湊字數；Opus 籠統也標了 2 個 Critical，是正式環境等級議題（onScopeDispose 缺失、timer 變數位置），但對小型 refactor 來說標太用力 (´_ゝ`)
Sonnet 4.6 最貼近標準答案：Case D skill 視角 A 與籠統 prompt 都給出 0 Critical / 0 High，跟預期一致
Opus 4.7 標 High 標得重，還常常把正式環境等級議題當 Critical：對 Case D 的 unmount cleanup、SSR、delayMs 動態調整都標 High 或 Critical，其實是設計取捨而非 bug

Case A 三種模型完整報告對照

全部例子都列出來太多了，這裡只舉 Case A 作為代表。乁( ◔ ௰◔)「

同一份 usePagedList.ts + usePagedList.spec.ts，丟給三種模型的 skill 流程（兩位代理人並行：A 視角正確性、B 視角測試完整性），三份結果濃縮如下：

Opus 4.7

視角 A（正確性）：

[Critical] usePagedList.ts:32 → next() 守衛 <= 應為 <，連續 next 會讓 page 超過 pageCount（觸發路徑：source 長度 10、pageSize 5，連按 next 兩次 page=3 → items=空）
[Critical] usePagedList.ts:22 → pageSize=0 時 pageCount=Infinity、items 切片仍回 1 筆，next 可無限累加；pageSize 負數時守衛立即失效
[High] usePagedList.ts:28 → slice(start, end + 1) 每頁多取 1 筆
[High] usePagedList.ts:21-23 → 空 source 時 pageCount=0 但 page=1，「第 1 頁／共 0 頁」不一致
[High] usePagedList.ts:47 → watch(source) 預設淺層，原地 push/splice 不會重置 page
[High] usePagedList.ts:3-6 → source / pageSize 不符 Vue 3 慣例（應為 MaybeRefOrGetter）
[Medium] pageSize 解構為純值，失去 reactivity
[Medium] 回傳型別宣告為 Ref<number> 但實際是 ComputedRef，誤導呼叫端
[Low] Math.ceil 不擋非整數 pageSize
Passed：prev 守衛、reset 行為、泛型 <T> 簽章

視角 B（測試完整性）：

[Critical] usePagedList.spec.ts:9 → 「回傳第一頁資料」斷言 [1,2,3]，但實作回 [1,2,3,4]，這代表測試從未實際 run 過
[Critical] usePagedList.spec.ts:17 → 「next 切換到下一頁」斷言 [4,5,6] 表面通過，是 source 邊界剛好掩蓋 bug 的巧合
[Critical] 未測 next 在末頁（漏掉 A2 守衛）
[Critical] 未測 source.value = [...] 變動時 page 是否重置
[High] 未測空陣列 / source 少於 pageSize
[High] 未測 pageSize = 0 / 負數
[High] 未測 prev 在第一頁
[High] reset() 整個函式零覆蓋
[Medium] next 後寫 await nextTick() 多餘
[Medium] 缺泛型 / 物件型別測試

Sonnet 4.6

視角 A（正確性）：

[Critical] usePagedList.ts:28 → slice(start, end + 1) 應為 slice(start, end)（觸發路徑：pageSize=3、source=[A,B,C,D,E,F]，第 1 頁期望 [A,B,C] 實際 [A,B,C,D]）
[High] usePagedList.ts:32 → next() 守衛 <= 允許 page 超出 pageCount
[High] usePagedList.ts:21-23 → pageSize=0 → pageCount=Infinity；pageSize 負數 → pageCount 為負
[Medium] usePagedList.ts:4 → source 型別限縮為 Ref<T[]>，不接受 Getter / Reactive
[Medium] usePagedList.ts:47-49 → watch(source) 僅 lazy，原地 push/splice 不觸發
Passed：prev 守衛、reset、pageCount computed、page 型別、回傳介面完整

視角 B（測試完整性）：

[Critical] usePagedList.ts:31-35 → 未覆蓋 next 在末頁，無法暴露 <= bug
[Critical] usePagedList.ts:28 → 第一個測試斷言應 fail 但表面通過，強烈懷疑測試套件從未成功執行
[High] 缺空陣列 / source 少於 pageSize
[High] 缺 pageSize=0 / 負數
[High] 缺 source 變動 page 是否重置（watch 行為）
[High] 完全沒有 prev 測試
[Low] 只測 number[]，未測物件陣列

Haiku 4.5

視角 A（正確性）：

[Critical] usePagedList.ts:28 → slice(start, end + 1) 邏輯錯誤，每頁多取一筆
[Critical] usePagedList.ts:32 → next() 守衛 <= 會讓 page 超過上限（觸發路徑：source=50 筆、pageSize=10，第 5 頁呼叫 next() → page=6）
[High] usePagedList.ts:22 → pageSize=0 / 負數無防禦，會 Infinity 或負無窮
[High] usePagedList.ts:4-5 → source / pageSize 型別過嚴格，應接受 MaybeRefOrGetter
[Medium] 空陣列時 pageCount 與 page 不一致
[Medium] pageCount 變化未觸發 items 邊界檢查
[Low] watch 缺 { deep: true } 選項

視角 B（測試完整性）：

[Critical] usePagedList.spec.ts:6-10 → 第一個測試 assertion 錯誤，slice(0, 4) 應返回 [1,2,3,4] 但 expect [1,2,3]，測試應該會失敗，表示測試沒實際執行過
[High] 未測 next 末頁（暴露 <= bug）
[High] 未測 prev、source 變動、空陣列
[Medium] 未測 pageSize ≤ 0 防呆
[Medium] 未測物件陣列型別

報告差異

三種模型都抓到 A1（slice +1）、A2（next 守衛）這兩個核心 bug，也都從「斷言對不上」反推到「這份測試根本沒跑過」這層更深的結論，連 Haiku 都看出來了。(｢･ω･)｢

Haiku：「說好的尊重呢？(°A ,°`)」

Opus 4.7：條目最多最細，Critical 給最多。把 A4（空陣列）、watch 淺層、MaybeRefOrGetter 全列，甚至延伸到 ComputedRef 型別宣告、Math.ceil 不擋小數。整合者要做的工作最多。

Sonnet 4.6：嚴重度最克制，只給一個 Critical（A1）。A2 只給 High，乍看保守，但 A2 標準答案就是 High，反而 Sonnet 校準到位。報告結構完整，passed 段最清楚。

Haiku 4.5：條目精煉，重點都中但描述偏淺。對 Vue 慣例（MaybeRefOrGetter、watch deep）有提到但不深入。速度則是三種模型中最快（多數 < 20s）。

簡單說就是 Haiku 愛碎碎念、Sonnet 腦子打結、Opus 有點激動。(◜௰◝)

所以此 Skill 效果如何？

1. vs 籠統 prompt：提高命中率

籠統 prompt（「請審查這個」一句話 + 防污染條款）在不同模型下命中率差距很大，但 skill 可以填平差距。

模型	籠統 prompt 平均命中率（A+B+C）	skill 平均命中率	提升
Opus 4.7	86%（24/28）	100%（28/28）	+14
Sonnet 4.6	64%（18/28）	100%（28/28）	+36
Haiku 4.5	61%（17/28）	96%（27/28）	+35

Opus 自己就能撐到 86%，籠統 prompt 都吃得下；Sonnet 跟 Haiku 都掉到 6 成上下，少了 skill 的視角分工 Sonnet 表現幾乎跟 Haiku 一樣。

skill 把不同模型拉到接近滿分，對 Sonnet 提升最大（+36），等於把它從「會漏掉三成多」拉到「幾乎不漏」( •̀ ω •́ )✧

2. vs 詳細 prompt：標記比較冷靜

詳細 prompt（單 agent + 完整檢查清單）命中率跟 skill 平手（都接近 100%），差異在 Case D 對照組標多重：

組別	三種模型 Critical 誤報合計	三種模型 High 誤報合計
Skill（兩位 agent 並行）	2	6
詳細 prompt（一位 agent + 雙視角合一）	2	9

Critical 持平，但 skill 標的 High 比詳細 prompt 少 1/3（6 vs 9）。

原因是兩個 agent 各管一個視角，每個 agent 不需要硬找超出自己範圍的問題，自然就不會標太重。(*´ω`)人(´ω`*)

3. 誰是瞎掰王

Case D 是乾淨案例，用來挖洞給模型跳，正常不該標出 Critical、High。ԅ(´∀` ԅ)

模型	Critical 誤報	High 誤報
Opus 4.7	0	8
Sonnet 4.6	1	5
Haiku 4.5	3	3

Haiku：對 unmount cleanup、SSR setTimeout、scope dispose 標 Critical，是真實 production 議題沒錯，但用在小型 refactor 上太用力
Sonnet：唯一 Critical 出在「timer 跨 instance 共享」，標完又自己澄清「實務上不會發生」
Opus：零 Critical 誤報，但 High 標得很重，立場偏向「正式環境就該處理」

小筆記

Claude Code 的 Explore 與 general-purpose

代理人類型可選 Explore 或 general-purpose。

Explore 速度快、占用 context 也少，乍看像審查的不二之選。

不過 Claude Code 官方文件提到：

Fast read-only search agent for locating code. Use it to find files by pattern, grep for symbols or keywords, or answer "where is X defined / which files reference Y." Do NOT use it for code review, design-doc auditing, cross-file consistency checks, or open-ended analysis — it reads excerpts rather than whole files and will miss content past its read window.

意思是 Explore 適合定位、搜尋，不適合 code review、設計文件審查、跨檔一致性檢查，因為它只讀片段不讀完整檔案，視窗外的內容會直接被略過。

口說無憑，我們把 Case A 丟給 Explore 跟 general-purpose 並用籠統 prompt 實驗看看。

模型	general-purpose	Explore
Opus 4.7	7/9	8/9
Sonnet 4.6	6/9	6/9
Haiku 4.5	6/9	4/9

Case A 不到 100 行，Opus 跟 Sonnet 差距吃不太出來，Haiku 倒是少抓 2 個。

文件警告的「漏看內容」風險主要在「弱模型 + 大檔案 + 跨檔分析」這種情境才會放大，小檔案上很難看出來。

審查需要完整脈絡，所以用 general-purpose，雖然慢一點、貴一點，至少不會發生「有看但是不多」這種事 ( ・ิω・ิ)

總結 🐟

Skill 可以填平模型差距：強模型（Opus）光看一句「請審查」就能撐到 86% 命中率，但弱模型（Sonnet、Haiku）會掉到 6 成左右。套上 skill 後三種模型都拉到 99%，所以 skill 對弱模型補強最大。
計畫類審查效果良好：Case B 計畫類在籠統 prompt 下 Sonnet 只剩 4/9、Opus 7/9，skill 把這兩個視角強制拆給兩位代理人後，弱模型也能做得不錯 ( •̀ ω •́ )✧
不同模型有不同毛病：Haiku 快但常亂標 Critical（瞎掰王是你）；Sonnet 嚴重度標籤最貼近實際；Opus 立場像資深 PM，所有正式環境議題都標 High。
Skill 對弱模型有副作用：逐項清單會逼 Haiku「每項都要回答」，沒問題也硬塞 Critical。skill 改進一下應該可以解決，有機會再來試試。

目前看來，可以試試模型混搭，Haiku 海撈、Sonnet 整合、Opus 最後把關，下次再來試試吧。∠( ᐛ 」∠)_

感謝您讀到這裡，如果您覺得有收穫，歡迎分享出去 (*´∀`)~♥

有錯誤或不周全之處，還請多多指教 ( ´ ▽ ` )ﾉ

Skill 寫得很開心，但它真的有用嗎？來嘗試健檢看看 ​

這個 Skill 在做什麼？ ​

我書讀得不多，你不要騙我 QQ ​

三組 prompt 對照怎麼設計？ ​

4 個案例設計 ​

Case A：Vue Composable 程式碼變更 ​

Case B：Vue 列表分頁 composable 重構計畫 ​

Case C：<BaseDialog> 元件 API 規格 ​

Case D：對照組（無預埋） ​

代理人開工 ​

結果摘要 ​

Case A~C 預埋命中率（任一嚴重度提及該蟲蟲表示找到） ​

Case D 對照組誤報率（預期 0 Critical / 0 High） ​

Case A 三種模型完整報告對照 ​

報告差異 ​

所以此 Skill 效果如何？ ​

1. vs 籠統 prompt：提高命中率 ​

2. vs 詳細 prompt：標記比較冷靜 ​

3. 誰是瞎掰王 ​

小筆記 ​

Claude Code 的 Explore 與 general-purpose ​

總結 🐟 ​

Skill 寫得很開心，但它真的有用嗎？來嘗試健檢看看

這個 Skill 在做什麼？

我書讀得不多，你不要騙我 QQ

三組 prompt 對照怎麼設計？

4 個案例設計

Case A：Vue Composable 程式碼變更

Case B：Vue 列表分頁 composable 重構計畫

Case C：`<BaseDialog>` 元件 API 規格

Case D：對照組（無預埋）

代理人開工

結果摘要

Case A~C 預埋命中率（任一嚴重度提及該蟲蟲表示找到）

Case D 對照組誤報率（預期 0 Critical / 0 High）

Case A 三種模型完整報告對照

報告差異

所以此 Skill 效果如何？

1. vs 籠統 prompt：提高命中率

2. vs 詳細 prompt：標記比較冷靜

3. 誰是瞎掰王

小筆記

Claude Code 的 Explore 與 general-purpose

總結 🐟