我的知識庫

用 Claude 輔助開發：三個情境的 skill 組合

閱讀時間約 12 分鐘

知道機制是什麼還不夠，要知道在哪個情境組合哪些 skill，才能把 Claude 從「聰明的打字員」變成「懂得接哪個工具的工程夥伴」。這篇把本機安裝的 36 個 skills 對應到三個最常碰到的開發情境：開發大功能、architecture 設計、以及維護舊系統。

情境一：開發大功能

典型場景：PM 說「下季要做通知系統」，需求模糊、影響面廣、不知道從哪開始。

Skill 鏈

interview-me
    ↓ 確認「通知系統」背後的真正意圖（是要減少用戶流失？還是要讓 PM 能追蹤任務？）
spec-driven-development
    ↓ 把意圖轉成有六大核心、明確驗收標準的 spec
planning-and-task-breakdown
    ↓ 把 spec 拆成垂直切片，每個任務 ≤5 個檔案，有依賴順序
incremental-implementation（每個 slice）
    ↓ 實作 → 測試 → verify → commit，保持系統永遠可跑
test-driven-development（平行）
    ↓ spec 的驗收標準 → red test → 讓它通過
doubt-driven-development（遇到非顯然決策時）
    ↓ 對關鍵決策做對抗式審查，不讓「確定感」取代驗證

Claude Code 機制的介入點

CLAUDE.md：在 Specify 之前確認 CLAUDE.md 已涵蓋：build/test 指令、tech stack、命名慣例、DB schema 變更需先 ask。這讓後續所有 subagent 和 session 都自動繼承這些規則，不需要每次重複說。

Subagents 平行化：當 spec 已確定（特別是 API contract），可以派兩個 subagent：

  • Subagent A：實作 backend API endpoints + DB migration
  • Subagent B：實作 frontend API client + UI 元件（對著 mock data）
  • 主 session：整合、E2E 測試

前提是 api-and-interface-design skill 在 Plan 階段把介面先定清楚——合約確立後，前後端才能真正並行，不需要等對方。

Hooks（PostToolUse）：配置在每次 file edit 後自動跑 tsc --noEmit 和 lint。型別錯誤和 lint violation 在 subagent 寫完每個 slice 後立刻浮現，不會累積到最後整合時才爆。

Worktree 隔離：subagent 用 isolation: 'worktree' 在獨立 git worktree 工作，避免並行 edit 衝突；subagent 完成後主 session merge。

常見短路點

把「planning」和「tasks」合併成一步，結果任務沒有驗收標準。沒有驗收標準的任務，subagent 不知道「完成」的定義，往往會過度實作或停在一半。planning-and-task-breakdown 要求每個任務都有「驗收標準 + 驗證指令 + 預期改動檔案數」——這三項缺一，任務不算定義清楚。

情境二：Architecture 設計

典型場景：系統成長到需要考慮「要不要拆服務」、「選哪個 auth 策略」、「DB 要換嗎」這類影響深遠、reversibility 低的決策。

Skill 鏈

interview-me
    ↓ 確認：這個架構決策現在非做不可嗎？驅動力是什麼？
api-and-interface-design
    ↓ 先定介面邊界（contract first），再考慮實作
doubt-driven-development
    ↓ 對架構方案做對抗式審查——「試圖推翻它」而非「確認它沒問題」
documentation-and-adrs
    ↓ 把決策、備選方案、拒絕理由寫進 ADR，commit 進 repo
context-engineering
    ↓ 確認決策層的假設已進入 CLAUDE.md，後續 session 不需要重解釋

Claude Code 機制的介入點

Doubt-Driven 的多代理評審：架構決策是 doubt-driven 最值得用的地方。一個主 session 提出方案，派出 subagent 以對抗式 prompt 嘗試推翻它（找假設、邊界 case、隱藏耦合）。對同一個方案，可以從三個角度各派一個 subagent：scalability 角度、complexity 角度、reversibility 角度。多角度發現主 session 的盲點比同一個 context 自我審查更有效。

ADR commit 進 repo（documentation-and-adrs）：ADR 存放在 docs/decisions/ADR-XXX.md，commit 進版本庫。其重要性不只是給人看——它讓後續的 Claude session 讀到決策背景，不需要每次重解釋「為什麼不用方案 B」。沒有 ADR，六個月後新開一個 session，Claude 可能會重新建議你已經評估並拒絕的方案。

CLAUDE.md 固化架構約束：決策做好後，把核心約束（「這個 monorepo 不引入微服務架構」、「所有外部 API 呼叫要走 src/lib/api/ 這一層」）寫進 CLAUDE.md。這讓後續所有 AI session 和 subagent 都受這個約束限制，不會被無心的「我只是加一個 axios 直接呼叫」悄悄違反。

api-and-interface-design：contract-first 的價值：在定架構時，「先定介面、後定實作」的效益特別高。TypeScript interface、OpenAPI schema、GraphQL type 這些 contract 文件一旦 commit，後續的 subagent 和開發者都能對著同一份 contract 獨立工作，不需要等實作完成才能整合。

架構決策的對抗式審查格式

一個可複用的 Doubt-Driven 架構審查 prompt 框架：

## 對抗式架構審查
 
ARTIFACT（待審查的方案）：
[用 3–5 句說清楚架構方案]
 
CONTRACT（這個方案必須滿足的條件）：
1. [constraint 1]
2. [constraint 2]
3. [constraint 3]
 
→ 請試圖推翻這個方案。找出：
- 未陳述的假設
- 在哪個 scale 或邊界條件下方案會失效
- 隱藏的耦合或單點失效
- 未來 18 個月內可能讓這個決策難以逆轉的原因
→ 不要驗證，只找問題。如果真的找不到問題，明確說明「無法找到問題，因為……」

情境三：Maintenance（維護舊系統）

典型場景：生產系統偶爾出現不明原因的 timeout；有一個沒人動的模組但又不敢刪；依賴套件三個月沒更新；每次 oncall 都要花三小時才能定位問題。

Skill 鏈

debugging-and-error-recovery（有 bug 時）
    ↓ Reproduce → 隔離根因 → Fix → Guard（加測試防止回歸）
observability-and-instrumentation（fix 完之後）
    ↓ 加 structured log/metric，下次同類問題靠 query 找，不靠 grep
code-review-and-quality（定期）
    ↓ 五軸審查：correctness、readability、architecture、security、performance
deprecation-and-migration（有舊東西需要汰換時）
    ↓ 評估是否值得維護 → 建替代方案 → 遷移 → 安全移除

Claude Code 機制的介入點

CLAUDE.md + structure.md（最高槓桿）：維護工作中，Claude 最大的摩擦來源是「每次都要重解釋系統架構」。一個好的 CLAUDE.md 搭配 structure.md（系統地圖）讓 Claude 知道：哪個模組負責什麼、哪些路徑不能碰、測試在哪裡、關鍵的已知坑（known gotchas）。這是 maintenance 情境下投資報酬率最高的一次性投入。

Explore subagent（context 隔離）：除錯時，Explore subagent 可以做大範圍的 codebase 搜索（grep pattern、找呼叫鏈、追 dependency），把搜索結果摘要帶回主 session，而不是把幾十個 grep 結果直接倒進主 context。主 session 的 context 越精簡，推理品質越穩定。

Scheduled Tasks（預防性自動化）：

  • 每週：npm audit、dependency 是否有高危漏洞
  • 每天：跑完整測試套件，把失敗率趨勢記錄下來
  • 每月：跑 deprecation-and-migration skill 評估哪些模組的維護成本已超過其貢獻

這類工作不需要人在旁邊，scheduled task 的 prompt 要明確寫出「成功定義是什麼」和「結果如何呈現/通知」。

Hooks（PostToolUse 品質門）： 維護期的 regression 風險高——「只改一行」卻炸掉其他地方的情況常見。PostToolUse hook 在每次 file edit 後自動跑測試，讓 regression 在 subagent 還沒做完下一個任務前就被攔截，不會把多個問題疊在一起。

debugging-and-error-recovery 的核心原則：Stop-the-Line

這個 skill 的最重要戒律：任何意外發生時，先停止加新功能，先保留證據，先定位根因。在維護情境下，這尤其重要——因為「先快速修好、再研究為什麼」往往導致改了一個 bug 蓋住了另一個 bug，然後兩週後才發現。維護的債比功能的債更難清。

維護與遷移的決策框架（deprecation-and-migration）

在決定一個舊模組要不要汰換前，回答：

問題如果是如果否
這個模組還有唯一貢獻的功能嗎？繼續維護考慮廢棄
有替代方案嗎？可以開始遷移計畫先建替代方案
遷移成本可自動化嗎？優先做評估人工成本 vs 維護成本
廢棄後誰受影響？需要公告期 + 遷移指南—

Code is a liability（deprecation-and-migration skill 的核心主張）：每行程式碼都有持續的維護成本——測試、文件、安全 patch、依賴更新。功能的價值來自它做的事，不是來自程式碼本身。相同功能可以用更少程式碼提供時，舊程式碼應該離開。

橫切三個情境的 CLAUDE.md 策略

不論在哪個情境，CLAUDE.md 都是 Claude 輔助品質的底層保障。三個情境各有不同的 CLAUDE.md 重點：

情境CLAUDE.md 應涵蓋
開發大功能Tech stack、build/test 指令、命名慣例、「先問再做」的邊界（DB schema、新依賴）
Architecture已固化的架構決策（防止 Claude 重新建議已否決方案）、模組邊界規則
MaintenanceKnown gotchas（已知的系統陷阱）、哪些路徑高風險、oncall 相關的 runbook 指引

評估 CLAUDE.md 品質的測試：開一個新 session，只讀 CLAUDE.md，然後請 Claude 描述這個專案的 tech stack、build 方式、以及它不能做的三件事。如果回答準確，CLAUDE.md 有效；如果答不出來，它缺少了什麼就補什麼。

延伸

關係圖譜

反向連結