在 Day 13｜可組合的規範架構 中，我們完成了 System Prompt 的模組化設計雛形，每一段規範變成可引用的模組，像拼積木一樣建構出一份符合任務場景的 Prompt。

但今天我們要解決一個更關鍵的問題：
當多個模組之間定義出現衝突，AI 要依照誰的為主？

一、從實務中出現的衝突說起

我們的專案中，原本引入了：
@prompts/base/naming.md

此模組中定義如下：

## 命名規範（共通）
- 函式：使用 camelCase
- 變數：使用 camelCase
- CSS class：使用 kebab-case

但某個專案因為沿用舊有 API 結構與團隊慣例，希望使用 snake_case 變數命名，因此引入：
@prompts/legacy/naming-override.md

二、解法：語句式的「繼承與覆蓋」原則

目前 Claude / Cursor 的 .cursorrules 與 CLAUDE.md 並不支援條件語法（如 @if / @when），因此我們採用以下 純語句式策略：

模組覆蓋優先規則語句（寫入 System Prompt 中）

若不同模組之間產生重疊或衝突，請依以下優先順序處理：

1. 以當前任務所指定的「專案專用模組」為主；
2. 若無指定模組，則以 base 類模組為預設規範；
3. 若有特定覆蓋模組（如 naming-override），請忽略對應的 base 規則。

System Prompt 實例引用

## 載入模組
@prompts/base/style.md
@prompts/base/naming.md
@prompts/base/constraints.md

## Legacy PHP 專案需求
@prompts/legacy/naming-override.md

## 規範合併原則
若 base/naming 與 legacy/naming-override 出現矛盾，請以後者為準。

三、模組內容實作方式（檔案內容）

@prompts/base/naming.md

<!-- version: 1.0 | author: core-team -->
## 命名規範（共通）
- 函式命名使用 camelCase
- 變數命名使用 camelCase
- CSS class 使用 kebab-case

@prompts/legacy/naming-override.md

<!-- version: 1.1 | author: legacy-team -->
## 命名規範（Legacy 專案覆蓋）
- **變數命名請改為 snake_case**
- 其他規則遵守 base/naming.md 的設定

四、推廣的應用場景

五、可讀性高、免腳本的模組策略優勢

六、實務提醒：一定要清楚標註「優先規則」

因為 Claude / Cursor 無法推理你引用模組的意圖順序，所以每次使用模組疊加時，務必加上像這樣的說明：

請使用以下模組完成此次任務：
@prompts/base/naming.md
@prompts/legacy/naming-override.md

當命名規範衝突時，請以 legacy 模組為主。

否則很容易混用內容，導致產出不一致的程式碼。