前言：規則寫得夠細，還會出什麼問題？

「一支 skill 只要把規則寫得夠詳細、夠具體，AI 應該就會用得準吧？」

這句話對了一半。規則寫得詳細，確實能讓 AI 在「該套用這支 skill」的情境下表現得更準——但它完全沒回答另一個同樣重要的問題：AI 怎麼知道現在該不該套用這支 skill？ 如果一支 skill 從頭到尾都在講「該怎麼做」，卻沒有先劃清楚「這支管什麼、不管什麼」，再詳細的規則也可能被套用到不該套用的情境，或者跟另一支處理類似問題的 skill 互相打架。今天要講的「定位」段落，處理的正是這個規則本身回答不了的問題。

今日目標

• 理解「規則寫得多詳細」跟「AI 知不知道該不該套用」是兩個獨立的問題
• 看清楚沒有定位段落時，一支寫得再仔細的 skill 會出什麼具體狀況
• 認識「定位」段落該包含的兩種劃界方式
• 建立寫 skill 時先劃邊界、再寫細節的習慣

沒有定位段落，AI 靠什麼判斷該不該套用？

想像一支處理「錯誤訊息格式」的 skill，裡面鉅細靡遺地寫了該用什麼措辭、該不該附上錯誤代碼、日誌要記哪些欄位。這支 skill 寫得很好——如果你正在處理的剛好是它設想的那種情境。問題是，AI 讀完這份文件，並不知道「這種情境」具體長什麼樣。如果專案裡同時存在另一支處理「使用者介面提示文字」的 skill，兩者對「錯誤訊息」的定義可能重疊也可能不重疊，AI 沒有辦法從規則本身推斷出邊界在哪裡——它只能憑感覺猜「這個情境聽起來有點像」，然後套用其中一支，或者更糟，兩支都套用一部分，拼出一個四不像的結果。

這不是規則寫得不夠細的問題,是規則的「適用範圍」從來沒有被明講過。 一份文件越詳細，讀者（不管是人還是 AI）越容易誤以為「詳細」等於「完整」，卻沒意識到「詳細地講清楚該怎麼做」跟「清楚地講明白這是不是該做的時候」是兩件互不涵蓋的事。

定位段落該包含的兩種劃界方式

一支寫得好的 skill，開頭的定位段落通常做兩件事：

第一，明講「這支管什麼」——用具體的觸發情境或路徑範圍框住這支 skill 的責任邊界，而不是用抽象的形容詞。「這支只負責 API 回應的錯誤格式，不管日誌記錄格式」比「這支處理錯誤相關的事」精確得多，後者聽起來涵蓋範圍很廣，AI 讀完反而更容易誤套用到不相干的情境。

第二，明講「這支不管什麼、該去哪裡找」——把容易被誤認為同一類的情境明確排除掉，並指向正確的 skill。這一步經常被省略，因為寫 skill 的人容易只想著「我要規範的這件事」，而不去設想「有哪些聽起來很像、但其實不是我要管的情境」。

用一組對照來看這個差異：

❌ 沒有定位段落，直接開始講規則：
---
name: error-response-format
description: 處理錯誤回應的格式
---
錯誤訊息要包含：錯誤代碼、使用者可讀的說明、
技術細節（僅在開發環境顯示）……
→ AI 讀完知道「錯誤回應該長什麼樣」，
  但完全不知道這支 skill 管的是「API 層級的錯誤回應」，
  還是也包含「表單驗證失敗時前端顯示的提示文字」——
  兩者聽起來都是「錯誤訊息」，套用範圍卻應該完全不同

✅ 先劃定位，再講規則：
---
name: error-response-format
description: API 錯誤回應的格式規範
---
## 定位
這支只管「後端 API 回傳給呼叫端的錯誤結構」，
不管前端表單驗證的提示文字（那是 UI 文案規範的範圍，
不在這裡）、也不管日誌該記什麼欄位（見另一支 skill）。

## 規則
錯誤訊息要包含：錯誤代碼、使用者可讀的說明、
技術細節（僅在開發環境顯示）……
→ AI 讀完先知道「這支管的是 API 回應層」，
  遇到表單驗證提示文字的情境，
  自然知道該去找別支 skill，而不是套用這支

定位段落做的事，其實跟這系列的主題句是同一件事——逼 skill 誠實標注自己的適用範圍，而不是讓 AI 憑感覺判斷「這條規則好像可以套用在這裡」。 一份沒有標注範圍的規則，就跟一個沒有標注查證範圍的結論一樣危險：看起來很有把握，實際上那份把握只涵蓋了寫的人設想到的情境，沒涵蓋所有可能被誤套用的邊緣案例。

定位段落的第二個好處：讓多支 skill 之間有分工,不是互相覆蓋

當一個專案累積到十幾、二十支 skill 之後，職責重疊的風險會急速上升——尤其是幾支 skill 是在不同時間點、為了處理不同的具體問題各自寫出來的，寫的人當下未必知道專案裡已經有一支類似的規則存在。定位段落除了幫 AI 判斷「現在該不該套用」，也幫下一個要新增 skill 的人判斷「這個情境是不是已經有別支 skill 在管了」——讀過現有 skill 的定位段落，比讀過所有規則細節更快知道「這裡有沒有空隙需要一支新規則」。

第一部小結：從「工具值得被設計」到「工具內部的邊界要清楚」

這是第一部（Day 1-7）的最後一篇。這七天走過的路徑是：先確立「AI 協作工具本身也需要被當成軟體來設計」這個立場（Day 1），拆解 CLAUDE.md 該放什麼、不該放什麼（Day 2-3），再往下一層看 Skill 這個更細粒度的規則單位——它的本質是什麼（Day 4）、該用哪一種寫法（Day 5）、從無到有怎麼誕生（Day 6）、以及今天講的「內部邊界要怎麼劃」。這七篇合起來想建立的認知是：AI 協作工具的每一層——CLAUDE.md、skill、skill 內部的定位段落——都在回答同一個問題：這條規則的適用範圍到哪裡為止,而不是只回答「這條規則的內容是什麼」。

今日思考題

回想你手上寫過的一份給 AI 用的規則文件（不管是 CLAUDE.md 還是某支 skill）：它有沒有明講「這支管什麼、不管什麼」？如果拿掉標題跟檔名，只讓 AI 讀內文，它猜得出這份規則的適用邊界在哪裡嗎？

今日重點回顧

• 「規則寫得多詳細」跟「AI 知不知道該不該套用」是兩個獨立的問題，前者解決不了後者
• 定位段落該做兩件事：明講「這支管什麼」、明講「這支不管什麼、該去哪裡找」
• 定位段落逼 skill 誠實標注適用範圍，跟這系列主題句是同一個邏輯的不同層次
• 專案累積越多 skill，定位段落越重要——它同時幫 AI 判斷該不該套用、幫寫新規則的人判斷該不該重複造輪子
• 第一部（Day 1-7）整體：從「工具值得被設計」到「工具內部的每一層都要標注適用範圍」

明日預告

明天正式進入第二部：AI 的持久記憶系統怎麼設計——user、feedback、project、reference 四種記憶類型各自負責什麼,以及為什麼把它們混在一起記會出問題。