昨天我們談到 Context 過長 會讓 AI 忘規則、失焦，輸出結果不一致。但就算解決了 Context 問題，還有另一個挑戰：性能。

如果規範過於冗長、缺乏重點排序，AI 不僅回應慢，還可能忽略部分規則。下面我整理了幾個常用的調整方法。

一、精簡規範

1. 移除不必要的修辭

錯誤：

Always remember to try your best to avoid SQL injection.

改進：

Validate inputs. Prevent SQL injection.

Token 減半，語意更直接。

2. 規則代碼化（使用縮寫代號）

舊寫法：

• Always validate inputs and sanitize user data before executing SQL.
• Ensure consistent snake_case naming in all variables and functions.
• Write unit tests for every function.

新寫法：

PRIORITY_SYSTEM:
  - P1_SECURITY: Validate input (SQLi safe).
  - P2_CONSISTENCY: snake_case naming.
  - P3_TEST: Unit test for all functions.

用代號管理規則，縮短內容又保持一致性，團隊共享代碼表即可。

二、規則排序

1. 關鍵規則放最前（安全性、正確性優先）
2. 尾端重申一次重點

實務範例：多技術棧專案的規則優先順序

以我們的多技術棧專案結構為例：

frontend/.cursorrules

# === P1 關鍵規則（最前面）===
SECURITY: Input validation required.
CONSISTENCY: JavaScript camelCase only.

# === 載入模組 ===
@import ../shared/prompts/lang/javascript.md
@import ../shared/prompts/testing/jest.md

# === P1 關鍵規則重申（最後面）===
REMINDER: All variables must use camelCase.

backend/.cursorrules

# === P1 關鍵規則（最前面）===
SECURITY: SQL injection prevention.
CONSISTENCY: PHP snake_case only.

# === 載入模組 ===
@import ../shared/prompts/lang/php.md
@import ../shared/prompts/testing/phpunit.md

# === P1 關鍵規則重申（最後面）===
REMINDER: All identifiers must follow snake_case.

測試顯示這樣更能強化規則遵守率。

三、分層與模組優化

共用模組精簡化

shared/prompts/base/style.md（精簡版）

<!-- version: 2.0 | optimized for performance -->
STYLE_CORE:
  - P1: Input validation
  - P2: Consistent naming
  - P3: Test coverage
  
FORMAT:
  - 2-space indent
  - No trailing spaces
  - UTF-8 encoding

shared/prompts/lang/javascript.md（代碼化版）

JS_RULES:
  - NAMING: camelCase (vars/functions), PascalCase (classes)
  - SYNTAX: ES6+, const>let>var
  - MODULES: import/export only
  - DOM: Native API preferred

模組載入策略優化

# 載入順序
@import ../shared/prompts/base/style.md      # 基礎規則
@import ../shared/prompts/lang/javascript.md # 技術棧特定
@import ./project-specific.md                # 專案特殊需求（如果有）

四、A/B 測試：多技術棧環境

測試方法與指標

• 版本 A：完整版。
• 版本 B：精簡代碼化版。

執行相同的指令，使用不同的System Prompt，並進行測試。

比較指標

• 規範遵守率（命名正確 %）。
• Bug 數量（單元測試通過率）。

五、實務目錄結構優化

配置檔案結構

/my-app
├── shared/prompts/
│   ├── base/
│   │   └── core.md                     #  核心規則
│   ├── lang/
│   │   ├── js-optimized.md            # JS精簡版
│   │   ├── php-optimized.md           #  PHP精簡版
│   │   └── flutter-optimized.md       #  Flutter精簡版
│   └── testing/
│       ├── jest-compact.md            #  Jest精簡版
│       └── phpunit-compact.md         #  PHPUnit精簡版
│
├── frontend/
│   └── .cursorrules                  
│
├── backend/
│   └── .cursorrules                   
│
└── mobile/
    └── .cursorrules                  

六、Debug Checklist（多技術棧版本）

技術棧專用檢查清單

JavaScript專案：

• [ ] 冗詞是否刪除？（"always remember to" → 直接刪）
• [ ] 是否使用JS代碼規則（camelCase, ES6+）？
• [ ] Jest測試規範是否精簡載入？
• [ ] 是否避免載入PHP/Flutter規範？

PHP專案：

• [ ] 是否使用PHP代碼規則（snake_case, PSR-12）？
• [ ] PHPUnit測試規範是否精簡載入？
• [ ] 是否避免載入JS/Flutter規範？
• [ ] 特定規範是否按需載入？

跨技術棧任務：

• [ ] 是否拆分成多次提示？
• [ ] 每次提示是否明確標註技術棧？
• [ ] 是否使用最精簡的模組組合？

七、結論與最佳實踐

性能調校在多技術棧環境下更加關鍵，因為錯誤的模組載入會導致規範混用和性能下降。

核心原則：

1. 技術棧隔離 → 每個目錄只載入必要的規範模組
2. 極致精簡 → 用代號和關鍵字取代冗長描述
3. 智慧排序 → P1規則前後呼應，中間載入模組
4. 數據驗證 → 定期A/B測試，以規範遵守率和準確率為指標