在昨天的工作中，我們發現 AI 在處理 Web 與 iPad 兩種開發場景時的協作需求有本質差異。因此，一套通用的 System Prompt 顯然無法同時兼顧靈活性與一致性。

今天我們正式進入模組化設計階段——我們不再追求一份「全包式」的系統提示，而是打造一個 Prompt 模組工具箱，讓團隊可以根據任務場景自由組裝所需的規範。

一、模組化 System Prompt 的設計思路

為什麼要模組化？

• 團隊開發中存在大量場景差異（語言、平台、功能）
• 一份大檔案難以維護、難以重用
• AI context window 有限，必須控制輸入長度

解法：將 System Prompt 拆解成模組

• 每個模組負責單一職責
• 模組可重複使用
• 引用語法簡單、清楚
• 支援層級式組合（後續擴充 Day 14 會實作）

二、模組引用機制：@模組名 語法

我們定義了一個簡單的引用規則：

在主 System Prompt 中，任何 @模組路徑 的標記，視為引用該模組的內容。

這個語法符合幾個需求：

• 容易辨識，不易與一般內容混淆
• 易於手動編輯與維護
• 不依賴額外工具或腳本即可閱讀和預覽

模組檔案結構（範例）

system-prompt/
├── CLAUDE.md
├── .cursorrules
└── prompts/
    ├── base/
    │   ├── style.md
    │   ├── naming.md
    │   └── constraints.md
    ├── web/
    │   ├── layout.md
    │   └── interaction.md
    └── ipad/
        ├── layout.md
        └── touch.md

三、主 Prompt 實作範例：使用 @模組名 引用

.cursorrules（或 CLAUDE.md）內容如下：

# Cursor 專案開發專用 System Prompt

## 共通規範
@prompts/base/style.md
@prompts/base/naming.md
@prompts/base/constraints.md

## Web 平台開發
@prompts/web/layout.md
@prompts/web/interaction.md

優點：

• 簡潔明瞭：每一行都代表一個「邏輯模組」
• 快速調整：更換開發場景只需替換引用的模組
• 模組可以版本控制、Pull Request 審查、共享重用

四、模組內容範例

prompts/base/naming.md

## 命名規範（共通）

請遵守以下命名慣例：
- 函式：使用 camelCase
- React 元件：使用 PascalCase
- CSS class：使用 kebab-case
- 避免使用單字母變數

prompts/web/layout.md

## Web 元件 Layout 規範

- 使用 Flex 或 CSS Grid 排版
- 避免硬編碼寬高
- 實作響應式設計（RWD）
- 支援不同裝置寬度與瀏覽器尺寸

五、模組化的場景組合實例

Web 元件開發：

@prompts/base/style.md
@prompts/base/naming.md
@prompts/web/layout.md
@prompts/web/interaction.md

iPad 專案頁面開發：

@prompts/base/style.md
@prompts/base/naming.md
@prompts/ipad/layout.md
@prompts/ipad/touch.md

Python 後端 API：

@prompts/base/style.md
@prompts/base/constraints.md
@prompts/backend/error-handling.md
@prompts/backend/api-structure.md

六、版本控管與模組演進策略

我們建議每個模組都有自己的版本與作者資訊，放在模組檔案開頭：

<!-- prompts/web/layout.md -->
<!-- version: 1.1 | updated: 2025-09-11 | author: alice -->
## Web Layout 規範
...

Git 設定建議

• 將每個模組視為「獨立單元」提交
• Review 團隊可針對模組做審查而非整份 System Prompt
• 支援多專案共用模組，透過 Git Submodule 或 symbolic link 管理

下一步：多層規範的組合與優先順序控制

模組之間的內容有時會出現衝突，例如：

@base/error-handling.md 規定錯誤回傳格式應簡潔統一，但 @backend/partner-api.md 為配合外部合作方需求，需回傳更完整的錯誤資訊。

該怎麼辦？哪個模組的內容應該被優先採用？