在前一篇我們介紹了 System Prompt 的模組化與覆蓋機制設計，讓我們能透過自然語言語句達成「繼承 + 覆蓋」的效果，解決模組衝突的問題。
今天，我們要將這套架構，套用到更現實、更具挑戰的場景：一個同時包含多個技術棧的專案。

一、挑戰背景：多技術棧專案的混亂現象

在我們目前協作的一個產品中，團隊採用了以下技術棧：

• 後端：PHP
• 前端：Pure JavaScript (ES6+)
• 行動端：Flutter
• 共用 API 文件與測試：OpenAPI + Postman + Jest

問題來了：

• 命名風格不一致：PHP 偏向 snake_case，而 JavaScript 偏 camelCase。
• 測試策略不同：後端使用 PHPUnit，前端使用 Jest。
• 檔案結構邏輯不同：Flutter 採用 feature-based，JavaScript 採 module-based。
• Prompt 規則容易交叉污染：Claude/Cursor 回應時混用了不同模組的規則，導致 output 品質下降。

這使得我們原本期待 AI 幫助團隊提高一致性的目標反而被拖累。

二、解法：根據技術棧拆分模組 + 明確標註上下文

我們採取了兩個核心策略：

1. 以技術棧為單位切割 Prompt 模組
2. 為每一段任務指定「上下文定位語句」

技術棧模組設計範例

以下是我們建立的部分模組：

@prompts/lang/php.md

<!-- version: 1.0 | for: PHP 專案 -->
## 命名與程式風格（PHP）
- 變數與函式命名：snake_case
- 類別與常數命名：PascalCase
- 使用 PSR-12 標準進行排版與縮排

@prompts/lang/javascript.md

<!-- version: 1.1 | for: JavaScript 專案 -->
## 命名與程式風格（Pure JavaScript）
- 函式與變數命名：camelCase
- 建構函式與類別名稱：PascalCase
- 使用 ES6+ 語法（const/let、arrow functions、destructuring）
- 模組匯入：使用 ES6 import/export
- 使用 Prettier 設定進行排版與格式化
- 避免 var，優先使用 const，必要時使用 let

@prompts/testing/phpunit.md

## 單元測試策略（PHP 專案）
- 測試框架：PHPUnit
- 每個方法都應具備至少一個測試覆蓋
- 測試檔案與原始碼同層目錄 `__tests__`

@prompts/testing/jest.md

## 單元測試策略（JavaScript 專案）
- 測試框架：Jest
- 使用原生 DOM API 或 jsdom 進行 DOM 測試
- 檔名結尾應為 `.spec.js` 或 `.test.js`
- 測試檔案放置於 `__tests__` 目錄或與原始碼同層
- 使用 ES6 import/export 語法撰寫測試

三、System Prompt 實例：分層載入與優先順序

開發人員執行前端任務（JavaScript 模組開發）時，我們載入以下 Prompt：

## 載入模組
@prompts/base/style.md
@prompts/lang/javascript.md
@prompts/testing/jest.md

## 任務背景
此次任務為 Pure JavaScript 前端模組開發，請依據 @prompts/lang/javascript.md 所定義的命名與排版規則實作。
測試請依照 @prompts/testing/jest.md 撰寫。

## 規範優先順序
若不同模組間定義有衝突，請依以下順序處理：
1. 當前技術棧模組（lang/javascript）
2. 測試模組（testing/jest）
3. base 類共通模組

四、專案結構策略：資料夾對應 Prompt 模組

為了降低錯誤與混淆，我們將每一個技術子專案中的 System Prompt 配置文件，與程式碼本身共用資料夾，例如：

/my-app
├── backend/
│   ├── src/
│   └── prompts/
│       ├── CLAUDE.md
│       └── @prompts/lang/php.md
├── frontend/
│   ├── src/
│   │   ├── modules/
│   │   ├── utils/
│   │   └── components/
│   └── prompts/
│       ├── .cursorrules
│       └── @prompts/lang/javascript.md
├── mobile/
│   └── prompts/
│       └── @prompts/lang/flutter.md

好處是：

• 每個子團隊管理自己的規範模組
• System Prompt 隨模組版本控管
• Claude / Cursor 使用當下子資料夾內配置，自動適配規範

五、團隊協作技巧：防止「規範混用」的三個做法

六、測試實驗：混用 vs 精準指令的差異

我們做了一個簡單的測試：

七、Pure JavaScript 特殊考量事項

相較於 TypeScript 或框架，Pure JavaScript 有一些特殊的注意事項：

模組管理策略

## JavaScript 模組組織原則
- 使用 ES6 模組系統（import/export）
- 每個檔案單一職責原則
- 避免全域變數污染
- 使用工廠模式或命名空間模式組織大型應用

程式碼品質控制

## JavaScript 程式碼品質
- 使用 ESLint 進行程式碼檢查
- 配置 Prettier 自動格式化
- 強制使用嚴格模式 ('use strict')
- 適當使用 JSDoc 註解

瀏覽器相容性

## 瀏覽器支援策略
- 明確定義支援的瀏覽器版本
- 使用 Babel 轉譯 ES6+ 語法（如需支援舊瀏覽器）
- 檢查 API 相容性（如 fetch、Promise 等）

八、結論與實務建議

System Prompt 模組設計不是萬靈丹，必須搭配實務使用流程才能發揮最大價值。

建議事項：

1. 依技術棧拆模組，避免交叉污染。
2. 每個任務一定要標註用途與規則優先順序。
3. 把 Prompt 模組版本化、模組化、資料夹化，降低團隊溝通成本。
4. 讓 AI「知道自己在哪裡、要做什麼、該遵守誰的規則」。
5. Pure JavaScript 專案特別注意模組管理和瀏覽器相容性問題。