即使 System Prompt 經過層層優化，最難解的問題往往不是技術本身，而是「團隊共識」。今天的主題，就是如何處理命名風格、測試策略、格式偏好等衝突問題，讓 System Prompt 成為真正服務團隊的工具，而不是紛爭的根源。
| 類別 | 常見分歧 | 對 AI 輸出的影響 |
|---|---|---|
| 命名風格 | camelCase、snake_case、UPPER_CASE | 命名混亂，程式碼不一致 |
| 測試風格 | TDD vs 傳統測試，測試 coverage 標準不同 | 有的功能有測試，有的沒有 |
| 語法偏好 | 單引號 vs 雙引號、逗號有無 | 格式不一致，PR review 難以統一 |
| 工具支援 | Claude vs Cursor 解析規則不同 | 寫法在不同 AI 工具下產出不同結果 |
System Prompt 是「團隊協作語言的協議書」，每一次變更都應有流程可循。
| 步驟 | 說明 |
|---|---|
| 提案 | 任一成員提出動機、預期效益與影響範圍 |
| 試點 | 對小範圍專案或任務進行 A/B 測試驗證成效 |
| 衡量 | 收集數據：規範遵守率、PR 審核輪數、Bug 數 |
| 決議 | 由小組投票、共識或 Tech Lead 仲裁 |
| 實施 | 更新 CLAUDE.md、.cursorrules，並通知成員同步 |
| 觀察期 | 新條款預設觀察 2 週，期間可快速回退 |
System Prompt 並非只有一種真理，而是「團隊最能維持一致的做法」。
enforce: 強制執行（安全性、測試覆蓋等）prefer: 建議採用（命名風格、格式偏好）experimental: 試驗階段，不納入一致性評估# frontend/.cursorrules
@import ../../shared/prompts/base/core.md # 基礎一致性
@import ./local/overrides.md # 團隊/個人偏好
允許個別專案保留偏好差異，但不影響主體風格一致性。
npx prompt-lint ./shared/prompts
輸出例：
[WARNING] Conflict: 'snake_case' in backend conflicts with 'camelCase' in shared rules.
| 指標 | 說明 |
|---|---|
| 一致性分數 | 靜態分析與 Code Review 的準則符合度 |
| PR 修改輪數 | 平均一個功能所需的編輯次數 |
| 缺陷率 | 合併後出錯比例或 Hotfix 數量 |
| 開發 Lead Time | 開工到合併的平均工作日 |
# Proposal: 調整命名規則（RFC-2025-09-20-01）
- Motivation: 提升跨端一致性，減少 AI 命名混用
- Scope: frontend/backend 共用 module
- Metrics: ConsistencyScore>=0.85, ReviewRounds<=2
- Result: Accepted
- Rollback: 可退回至 v1.3，觀察期兩週
## Enforce
- 變數與函式命名統一 camelCase（except for DB layer）
## Prefer
- React Component 檔案採用 PascalCase 命名
## Evidence
- PRs: #1234, #1240
- Test Report: /reports/2025w38-naming.html
| 衝突類型 | 處理建議 |
|---|---|
| 命名衝突 | Enforce 一致性規則，再依技術棧 override |
| 格式爭議 | 提為 prefer 條款，交由 linter 實作 |
| 工具支援差異 | 針對 Claude / Cursor 分別測試輸出行為 |
| 偏好爭議 | 設為 experimental 條款，觀察期後決議是否納入 |
System Prompt 並不是完美規範的追求，而是為了協作而存在的實用協定。
當面對分歧與風格戰爭時，不要以爭論取代共識建立，用實驗數據說服、用流程制度落地、用版本與條款等級控管差異，才能讓 System Prompt 成為「加速團隊」而非「拖慢節奏」的工具。
iThome鐵人賽
看影片追技術