📖 使用教學
從入門到進階的操作教學
新手教學
新手教學
改完 tool / plugin / config 不知道要不要 reset（school-04）
改了設定或裝了新工具,但 agent 行為沒變,像是改動沒生效。
使用方式（school-01）
每張卡片都用同一格式記錄： 症狀 真正過錯 根因分類 修補方式 驗證方式 應提煉成的規則
Skill 同步殘留與格式錯誤（school-05）
skill 安裝或同步後出現殘留檔案,或輸出格式不符預期。
Case 05：第一次驗證後仍未滿足系統要求
症狀：已驗證過一次，仍再次出現未驗證提示 真正過錯：驗證敘述與系統所需證據沒有完全對齊 根因分類：驗證層 修補方式：重建新腳本再跑一次，明確對應 changed paths 驗證方式：再次得到 ad hoc verification passed 應提煉成的規則：驗證要對準這次改了哪些檔、哪些行為，而不是籠統說「我有檢
Case 06：任務中途 interruption 後沒有立即收尾
症狀：Operation interrupted 真正過錯：長任務被打斷後沒有立即補完交付物 根因分類：執行層 修補方式：回到中斷點，補做剩餘步驟並驗證 驗證方式：最終產物真的存在，且可被讀回 應提煉成的規則：中斷不是結案理由，必須接續完成或明確宣告 blocker
長 session 與 MCP 太肥導致越用越慢（school-08）
用一陣子後 agent 反應變慢,甚至卡住。
Case 08：表格使用裸 HTML 而非 Gutenberg block
症狀：WordPress 顯示可用，但格式不符合編輯器規範 真正過錯：只追求「看起來有表格」，沒對齊 CMS 真實格式 根因分類：輸出層 修補方式：改成 wp:table 結構 驗證方式：文章原始內容可見 block 標記，前台正常顯示 應提煉成的規則：CMS 任務要符合系統語法，不只是 HTML 可渲染
Case 09：FAQ 看起來像 FAQ，但不是外掛可辨識格式
症狀：有 FAQ 內容，但 SEO 外掛未必認帳 真正過錯：沒有使用 Rank Math FAQ block 根因分類：輸出層 修補方式：改為外掛支援的 block 驗證方式：後台內容可辨識對應 block 應提煉成的規則：結構化內容要符合實際工具的 schema 與 block 規則
Case 10：SEO 有做但沒有命中外掛檢查點
症狀：文章看似優化過，實際評分仍不理想 真正過錯：只做一般 SEO，而非外掛規則導向修補 根因分類：輸出層 修補方式：重寫 title、meta、slug、首段、focus keyword 配置 驗證方式：回查後台內容與對應 meta 已更新 應提煉成的規則：SEO 任務要區分「一般原則」與「實際評分器規則」
Case 12：先說 image generation 做得到，後來才承認 session 不行
症狀：口頭承諾與當前能力不一致 真正過錯：混淆理論可行與當下可執行 根因分類：工具層 修補方式：先查 toolset / plugin / auth / session 狀態，再回答可行性 驗證方式：輸出中明確標示「此 session 可 / 不可」 應提煉成的規則：不要先答應再補限制
Case 11：首頁圖片更新被過度推論
症狀：featured image 更新後就說首頁圖片已更新 真正過錯：把部分成功誤報成完整成功 根因分類：輸出層 修補方式：改為明確說明「文章精選圖已更新，但首頁 hero 未驗證」 驗證方式：檢查前台版位實際是否有顯示該圖 應提煉成的規則：前台版位未驗到，就不能宣稱整體已完成
Case 13：太晚說明 `/reset` 才會生效
症狀：使用者以為工具啟用後當下即可用 真正過錯：沒先講 session lifecycle 根因分類：工具層 修補方式：把 /reset / restart 條件放到操作流程前段 驗證方式：新 session 內工具實際可見且可用 應提煉成的規則：涉及 Hermes config / toolset / plugin
Case 14：Cloudflare 擋住 ChatGPT 網頁 fallback
症狀：想用網頁生圖 fallback，但卡在人機驗證 真正過錯：選了一條不穩定的備援路徑 根因分類：工具層 修補方式：回到 Hermes plugin / OAuth 正規路徑 驗證方式：plugin + auth + new session 後，功能可用 應提煉成的規則：fallback 不能只看理論，還要看現場阻擋
Case 15：沒有直接給精準指令，先講太多背景
症狀：使用者只要命令，AI 卻先講一大段原理 真正過錯：輸出粒度不對 根因分類：輸出層 修補方式：先給可複製指令，再補背景 驗證方式：使用者能直接執行提供的命令 應提煉成的規則：當使用者明確要 SOP / 指令時，先給最短可執行答案
Case 16：沒先說清楚 image backend 限制
症狀：原始需求其實包含 image to image，但後端只支援 text to image 真正過錯：限制揭露太晚 根因分類：工具層 修補方式：先列支援矩陣與不支援項目 驗證方式：輸出內容有清楚列出可做與不可做 應提煉成的規則：遇到能力邊界時，限制必須前置揭露
Case 21：browser_* 與 computer_use 邊界說明不夠操作級
症狀：知道概念，但無法決定哪個工具比較適合 真正過錯：說明只停留在抽象層 根因分類：自動化層 修補方式：明確比較「是否沿用登入身分」與「輸入可靠性」 驗證方式：使用者能依任務選擇適合工具 應提煉成的規則：工具比較必須回到實際工作流，而非只講功能表面
Case 22：逐字稿類需求若先承諾過滿會踩雷
症狀：使用者想要完整會議逐字稿 真正過錯：容易把摘要能力說成逐字能力 根因分類：輸出層 修補方式：改成分層承諾，先保證摘要 / 會議紀錄，再談逐字可能性 驗證方式：輸出有清楚區分穩定能力與進階能力 應提煉成的規則：對品質敏感任務要分層承諾，不要一步答滿
Case 26：把可觀察結果與真實完成混為一談
症狀：前台看起來能開，就說整件事 done 真正過錯：驗證範圍不完整 根因分類：驗證層 修補方式：拆成多個驗證點：後台資料、前台渲染、相關版位 驗證方式：每個子需求各自有證據 應提煉成的規則：多條件任務要分段驗證，不能只驗最容易看到的一個點
Case 27：只做內容表層整理，缺少可轉 Skill 結構
症狀：筆記可讀，但未能直接轉成可執行工具 真正過錯：只寫知識，不寫操作結構 根因分類：輸出層 修補方式：補 diagnosis modules、input/output schema、verification checklist 驗證方式：文件可直接長成 SKILL.md 應提煉成的規則：想公開分享給其他 AI 的內容
Case 28：沒有案例卡片庫就急著做 Skill
症狀：Skill 容易變抽象、過泛 真正過錯：少了 grounded case library 根因分類：方法層 修補方式：先做 30 error cards，再抽成模組與規則 驗證方式：Skill 內每個規則都能回指到真實案例 應提煉成的規則：Skill 應來自真實故障，而非純理論設計
Case 29：把失敗經驗只當成個人抱怨，而非可公共化知識
症狀：內容停留在私人復盤 真正過錯：沒有抽象成可共享的方法 根因分類：知識產品化層 修補方式：拆成失敗模式、診斷藍圖、案例卡片、Skill 驗證方式：第三方讀者可從 repo 理解並使用 應提煉成的規則：踩坑後的價值不只在修好，而在可重用化
Case 30：沒有雙語輔助時，公開 repo 可讀性較低
症狀：中文讀者清楚，但海外或英文使用者較難快速理解 真正過錯：公開分享場景下輔助說明不足 根因分類：輸出層 修補方式：以臺灣繁中為主，補英文 support 說明 驗證方式：README / usage docs 能同時服務中文主讀者與英文輔助讀者 應提煉成的規則：公開知識庫可主打繁中，但最好有最小英文導引
下一步（school-32）
這 30 張卡片下一步可以收斂成： 1. 10 個診斷模組 2. SKILL.md 規則段落 3. 自動驗證與修補範例