通用語言落地

本提案解決導致 AI 程式碼生成失敗的術語碎片化問題。當不同團隊對同一概念使用不同術語時，AI 代理會產生需要人工修正的不一致程式碼。建立通用語言創造人類和 AI 代理都能依賴的共享詞彙。

核心洞察： AI 代理從程式碼模式學習。如果同一概念在程式庫中有五個不同名稱，AI 會持續複製這種不一致性。通用語言不僅是文件 - 它是可靠 AI 程式碼生成的基礎要求。

問題陳述

現狀：術語混亂

跨團隊回饋證據

概念	團隊 A	團隊 B	團隊 C	AI 混淆
攝影機設備	`device`	`camera`	`channel`	AI 混用術語
使用者組織	`organization`	`tenant`	`account`	API 不一致
影片片段	`clip`	`segment`	`recording`	模型不匹配
設備分組	`site`	`location`	`group`	導航混淆
警報通知	`alert`	`alarm`	`event`	處理器重複

實際案例

後端團隊：

"API 使用 'tenant' 但前端使用 'organization'。AI 生成的 API 呼叫使用錯誤的參數名稱。"

行動端團隊：

"iOS 程式碼稱為 'channel'，Android 稱為 'device'，Web 稱為 'camera'。AI 生成的程式碼不符合平台慣例。"

前端團隊：

"AI 建立了新的 RecordingList 元件，但我們已經有 ClipGallery，因為它不知道這是同一個概念。"

不一致的成本

提議解決方案：領域驅動通用語言

目標狀態

通用語言架構

glossary/
├── CLAUDE.md                    # AI 術語使用指示
├── index.md                     # 主詞彙表概覽
│
├── domains/
│   ├── device-management.md     # 設備領域術語
│   ├── video-streaming.md       # 影片領域術語
│   ├── user-identity.md         # 使用者/認證領域術語
│   ├── alerting.md              # 警報/事件領域術語
│   └── analytics.md             # 分析領域術語
│
├── mappings/
│   ├── legacy-terms.md          # 棄用術語 -> 規範術語
│   ├── platform-terms.md        # 平台特定變體
│   └── external-terms.md        # 第三方 API 術語對應
│
└── schemas/
    ├── term-schema.json         # 術語定義 schema
    └── validation.js            # 詞彙表驗證腳本

術語定義標準

術語文件模板

markdown

# Device（設備）

## 定義

捕捉影片或音訊資料並傳輸到平台的實體或虛擬攝影機、感測器或錄影設備。

## 規範名稱

- **程式碼**: `Device`
- **API**: `device`
- **UI**: "設備"

## 領域

設備管理

## 別名（已棄用）

| 別名 | 脈絡 (Context) | 遷移 |
|------|--------|------|
| `camera` | 舊版 iOS 程式碼 | 替換為 `device` |
| `channel` | 舊版 Android | 替換為 `device` |
| `equipment` | 舊 API v1 | API 已棄用 |

## 相關術語

- **DeviceGroup**: 某位置的設備集合
- **DeviceStatus**: 線上/離線/錯誤狀態
- **DeviceCapability**: 設備支援的功能

## 平台實作

| 平台 | 類別/型別 | 檔案 |
|------|----------|------|
| Web | `Device` interface | `types/device.ts` |
| iOS | `Device` struct | `Models/Device.swift` |
| Android | `Device` data class | `models/Device.kt` |
| Backend | `Device` entity | `domain/device.go` |

## API 使用

```json
{
  "device": {
    "id": "dev-123",
    "name": "Front Door Camera",
    "status": "online"
  }
}

UI 顯示

列表項目："前門攝影機"
狀態標籤："線上"
錯誤訊息："設備離線"

AI 指引

@ai-hint 攝影機/感測器實體永遠使用 Device。永遠不要使用 camera、channel 或 equipment。 @ai-hint 狀態使用 DeviceStatus，不要單獨使用 status 或 state。 @ai-hint 生成設備相關程式碼時，檢查此詞彙表確認正確命名。



## 領域詞彙表結構

### 領域：設備管理

```markdown
# 設備管理領域

## 核心實體

| 術語 | 定義 | 程式碼名稱 |
|------|------|-----------|
| **Device** | 實體/虛擬錄影設備 | `Device` |
| **DeviceGroup** | 設備的邏輯分組 | `DeviceGroup` |
| **DeviceStatus** | 當前操作狀態 | `DeviceStatus` |
| **DeviceCapability** | 支援的功能 | `DeviceCapability` |
| **DeviceConfiguration** | 設定與參數 | `DeviceConfiguration` |

## 狀態值

| 值 | 意義 | UI 顯示 |
|----|------|---------|
| `online` | 設備已連線且運作中 | "線上"（綠色）|
| `offline` | 設備無回應 | "離線"（灰色）|
| `error` | 設備報告錯誤狀況 | "錯誤"（紅色）|
| `maintenance` | 設備維護模式中 | "維護中"（黃色）|

## 操作

| 操作 | API 動詞 | 說明 |
|------|----------|------|
| 註冊 | `POST /devices` | 新增設備到平台 |
| 設定 | `PATCH /devices/{id}` | 更新設備設定 |
| 重啟 | `POST /devices/{id}/restart` | 重新開機設備 |
| 除役 | `DELETE /devices/{id}` | 從平台移除設備 |

## 反模式

| 不要使用 | 改用 | 原因 |
|----------|------|------|
| `camera` | `device` | Camera 是設備類型，不是實體 |
| `channel` | `device` | 舊系統的遺留術語 |
| `equipment` | `device` | 太籠統 |
| `unit` | `device` | 有歧義 |

領域：影片串流

markdown

# 影片串流領域

## 核心實體

| 術語 | 定義 | 程式碼名稱 |
|------|------|-----------|
| **Stream** | 即時影片傳輸 | `Stream` |
| **Recording** | 儲存的影片片段 | `Recording` |
| **Playback** | 影片觀看會話 | `Playback` |
| **Thumbnail** | 影片預覽圖 | `Thumbnail` |

## 已棄用術語

| 已棄用 | 規範 | 遷移路徑 |
|--------|------|----------|
| `clip` | `Recording` | 在新程式碼中重新命名 |
| `segment` | `Recording` | 更新變數名稱 |
| `video` | `Recording` 或 `Stream` | 根據脈絡 (Context) 選擇 |
| `feed` | `Stream` | 在 UI 文字中替換 |

遺留術語遷移

遷移策略

遺留術語對應表

markdown

# 遺留術語對應

本文件將已棄用術語對應到其規範替代。

## 嚴重等級

- **危急**: 若不修正會導致執行時期錯誤
- **高**: 經常導致 AI 混淆
- **中**: 偶爾 AI 錯誤
- **低**: 外觀不一致

## 對應

| 遺留術語 | 規範術語 | 嚴重等級 | 遷移狀態 |
|----------|----------|----------|----------|
| `camera` | `Device` | 高 | 進行中 |
| `channel` | `Device` | 高 | 進行中 |
| `tenant` | `Organization` | 危急 | 已完成 |
| `clip` | `Recording` | 中 | 規劃中 |
| `segment` | `Recording` | 中 | 規劃中 |
| `alarm` | `Alert` | 高 | 進行中 |
| `site` | `DeviceGroup` | 中 | 規劃中 |
| `location` | `DeviceGroup` | 中 | 規劃中 |

## 程式碼範例

### 之前（遺留）

```typescript
// 同一概念多個術語
interface Camera {
  cameraId: string;
  channelName: string;
}

function getChannelStatus(channelId: string): CameraStatus {
  // ...
}

之後（通用語言）

typescript

// 單一規範術語
interface Device {
  deviceId: string;
  deviceName: string;
}

function getDeviceStatus(deviceId: string): DeviceStatus {
  // ...
}



## CLAUDE.md 整合

加入專案 CLAUDE.md：

```markdown
## 通用語言

### 術語標準
- **永遠檢查** `glossary/` 再使用領域術語
- **使用規範名稱** 來自術語定義
- **永遠不要使用棄用術語** 列在 `glossary/mappings/legacy-terms.md`

### 撰寫程式碼之前
1. 識別需求中的領域術語
2. 在 `glossary/domains/` 查找規範名稱
3. 檢查要避免的棄用別名
4. 在所有層級使用一致命名（API、UI、程式碼）

### 術語使用規則

| 層級 | 慣例 | 範例 |
|------|------|------|
| 變數/屬性 | camelCase | `deviceStatus` |
| 類別/型別 | PascalCase | `DeviceStatus` |
| API 參數 | snake_case | `device_status` |
| UI 標籤 | 標題格式 | "設備狀態" |
| 資料庫欄位 | snake_case | `device_status` |

### 禁止做法
- 跨檔案對同一概念使用不同術語
- 建立新術語而不加入詞彙表
- 使用遺留術語（見 `legacy-terms.md`）
- 在同一層級混用命名慣例

### 不確定時
如果遇到詞彙表中沒有的術語：
1. 搜尋程式庫中的現有用法
2. 檢查是否是需要定義的新概念
3. 繼續前先詢問澄清
4. 不要發明新術語

實施路線圖

階段 1：發現

目標： 識別程式庫中的術語不一致。

交付物：

[ ] 術語清單試算表
[ ] 各領域不一致報告
[ ] 提議的規範術語清單

階段 2：文件化

目標： 建立帶有術語定義的詞彙表。

交付物：

[ ] 詞彙表目錄結構
[ ] 核心領域術語定義（設備、使用者、影片）
[ ] 遺留術語對應表
[ ] CLAUDE.md 術語指引

階段 3：工具化

目標： 建立驗證和強制執行工具。

交付物：

[ ] 術語驗證腳本
[ ] 術語檢查的 pre-commit hook
[ ] 規範術語的 IDE snippets
[ ] AI context 檔案生成

階段 4：遷移

目標： 更新程式庫使用規範術語。

交付物：

[ ] 各領域遷移腳本
[ ] 更新的 API 文件
[ ] 重構的型別定義
[ ] 更新的 UI 字串

階段 5：強制執行

目標： 防止回退到不一致術語。

交付物：

[ ] CI/CD 術語驗證
[ ] PR 模板含術語檢查清單
[ ] 新開發者入職指南
[ ] 季度詞彙表審查流程

驗證工具

術語驗證腳本

javascript

// validate-terms.js
const glossary = require('./glossary/schemas/terms.json');
const deprecated = require('./glossary/mappings/legacy-terms.json');

function validateFile(filePath, content) {
  const issues = [];

  // 檢查棄用術語
  for (const term of deprecated) {
    const regex = new RegExp(`\\b${term.legacy}\\b`, 'gi');
    const matches = content.match(regex);
    if (matches) {
      issues.push({
        file: filePath,
        term: term.legacy,
        canonical: term.canonical,
        severity: term.severity,
        count: matches.length
      });
    }
  }

  return issues;
}

// 作為 pre-commit hook 或 CI 步驟執行

Pre-commit Hook 設定

yaml

# .pre-commit-config.yaml
repos:
  - repo: local
    hooks:
      - id: validate-terms
        name: 驗證術語
        entry: node scripts/validate-terms.js
        language: node
        types: [javascript, typescript, markdown]
        pass_filenames: true

跨平台術語對應

平台命名慣例

概念	Web (TS)	iOS (Swift)	Android (Kotlin)	Backend (Go)
設備實體	`Device`	`Device`	`Device`	`Device`
設備列表	`DeviceList`	`DeviceListView`	`DeviceListScreen`	N/A
取得設備	`getDevice()`	`fetchDevice()`	`getDevice()`	`GetDevice()`
設備 ID 參數	`deviceId`	`deviceId`	`deviceId`	`deviceID`

API 到程式碼對應

markdown

# API 到程式碼術語對應

API 和程式碼之間的轉換：

| API (snake_case) | 程式碼 (camelCase) | 型別 (PascalCase) |
|------------------|-------------------|-------------------|
| `device_id` | `deviceId` | `DeviceId` |
| `device_status` | `deviceStatus` | `DeviceStatus` |
| `recording_start_time` | `recordingStartTime` | `RecordingStartTime` |
| `organization_name` | `organizationName` | `OrganizationName` |

## AI 使用

生成與 API 介接的程式碼時：
1. API 參數使用 snake_case
2. 內部程式碼使用 camelCase
3. 型別定義使用 PascalCase
4. 永遠不要在同一層級混用慣例

利害關係人術語協調

術語碎片化發生在多個邊界 - 不僅是工程團隊之間，而是從客戶到 AI 代理的整個價值鏈。

翻譯鏈問題

每個邊界都會創造翻譯機會，意義可能在此流失或扭曲。

利害關係人術語使用模式

利害關係人	主要關注	典型術語使用
客戶	業務成果	領域特定行話，因產業而異
業務/銷售	成交	面向客戶術語、行銷語言
PM	功能定義	客戶和技術術語混合
工程	實作	技術精確性、程式碼命名
AI 代理	模式匹配	程式庫中存在的任何術語

多利害關係人術語定義

擴展術語定義以包含所有利害關係人視角：

markdown

# Device（設備）- 規範術語

## 定義
捕捉和傳輸媒體資料的實體或虛擬設備。

## 利害關係人術語

| 情境 | 術語 | 備註 |
|------|------|------|
| **客戶（繁中）** | 攝影機、監控設備 | 用於合約、客服 |
| **客戶（英文）** | Camera, Surveillance Device | 行銷資料 |
| **業務/銷售** | 設備、裝置 | 提案、報價 |
| **PM/PRD** | Device | 需求文件 |
| **工程** | `Device` | 程式碼、API、資料庫 |
| **UI 顯示（繁中）** | 設備 | 本地化字串 |
| **UI 顯示（英文）** | Device | 本地化字串 |

## 翻譯規則

- PRD 提及「攝影機」-> 工程使用 `Device`
- 客戶說「監控設備」-> PM 文件記錄為「Device」
- API 回傳 `device` -> UI 顯示「設備」

協調機制

1. PRD 前術語對齊

撰寫需求前，對齊術語：

markdown

## PRD 前術語檢查清單

撰寫需求前：
1. [ ] 列出客戶/業務提及的所有領域概念
2. [ ] 檢查詞彙表中現有的規範術語
3. [ ] 如果是新概念，提出包含所有利害關係人對應的術語
4. [ ] 取得 PM + 工程對術語的簽核

2. PRD 模板含術語章節

每份 PRD 包含明確的術語對應：

markdown

## 術語

| 本 PRD 使用 | 規範術語 | 客戶說法 | 程式碼使用 |
|-------------|----------|----------|------------|
| 即時影像 | LiveStream | 監控畫面 | `LiveStream` |
| 設備群組 | DeviceGroup | 站點 | `DeviceGroup` |

3. 群體精煉術語解決

在 AI-DLC 群體精煉會議中，即時解決術語衝突：

markdown

## 術語解決協議

當術語衝突發生時：
1. PM 陳述客戶/業務術語
2. 工程提出規範術語
3. AI 對照現有詞彙表驗證
4. 小組決定對應方式
5. 在同一會議中更新詞彙表

治理角色

角色	責任
PM 主管	客戶/業務術語收集
技術主管	工程術語標準化
UX 主管	UI 顯示術語一致性
詞彙表負責人	衝突解決、維護

工作流程整合

核心洞察

目標是維護明確的對應，讓：

客戶可以使用熟悉的術語
業務可以說客戶的語言
PM 可以在文件中橋接兩個世界
工程有明確的程式碼命名
AI 可以正確地在各層之間翻譯

跨產品術語協調

當組織有多個產品時，術語碎片化變得更具挑戰性，因為產品獨立演進並發展出各自的「方言」。

跨產品問題

跨產品不一致的影響

情境	影響
客戶同時使用產品 A 和 B	對同一事物的不同術語感到困惑
後端 API 服務多個產品	參數命名不一致
共用元件庫	元件按產品命名不同
AI 代理跨產品工作	生成不相容的程式碼
新產品開發	重新發明術語而非重用
併購整合	兩個程式庫有衝突術語

聯邦詞彙表架構

glossary/
├── CLAUDE.md
├── index.md
│
├── core/                        # 跨產品規範術語
│   ├── entities.md              # Device, User, Organization
│   ├── operations.md            # CRUD 動詞、狀態轉換
│   └── status.md                # online, offline, error
│
├── products/
│   ├── vsaas/
│   │   ├── _product.md          # 產品特定概覽
│   │   ├── terms.md             # VSaaS 特定術語
│   │   └── mappings.md          # 對應到核心術語
│   │
│   ├── vortex/
│   │   ├── _product.md
│   │   ├── terms.md
│   │   └── mappings.md
│   │
│   └── edge-ai/
│       ├── _product.md
│       ├── terms.md
│       └── mappings.md
│
└── cross-product/
    ├── entity-mapping.md        # 跨產品的同一概念
    ├── api-contracts.md         # 共用 API 術語
    └── integration-terms.md     # 產品整合術語

跨產品實體對應

markdown

# 跨產品實體對應

## Device 概念

「錄影設備」概念存在於所有產品但使用不同名稱。

| 核心術語 | VSaaS | Vortex | Edge AI | 定義 |
|----------|-------|--------|---------|------|
| `Device` | Device | Channel | Camera | 實體/虛擬錄影設備 |
| `DeviceGroup` | Site | Location | Zone | 設備的邏輯分組 |
| `Recording` | Recording | Clip | Event | 儲存的影片片段 |
| `Stream` | LiveView | Feed | Stream | 即時影片傳輸 |

## 規範術語選擇標準

1. **最通用** - 適用於所有產品
2. **最成熟** - 用於最舊/最大的產品
3. **最精確** - 最清晰的技術意義
4. **最少歧義** - 無衝突意義

整合模式

模式 1：共用後端 API

markdown

## API 術語標準

建立服務多個產品的 API 時：

### 請求/回應
- 永遠在 API 合約中使用**核心規範術語**
- 產品在其邊界進行轉換

json

// API 回應（規範）
{
  "device": {
    "deviceId": "dev-123",
    "status": "online"
  }
}

typescript

// VSaaS 前端（無需轉換）
device.deviceId

// Vortex 前端（在 API 客戶端轉換）
channel.channelId  // 從 device.deviceId 對應

// Edge AI 前端（在 API 客戶端轉換）
camera.cameraId    // 從 device.deviceId 對應

模式 2：產品對應層

每個產品維護一個薄對應層：

typescript

// vortex/api/mappers/device.ts
export function toChannel(device: CoreDevice): VortexChannel {
  return {
    channelId: device.deviceId,
    channelName: device.deviceName,
    channelStatus: device.status,
  };
}

模式 3：共用元件庫

typescript

// @company/ui-core（規範）
export { DeviceCard } from './DeviceCard';
export { DeviceList } from './DeviceList';

// @company/ui-vsaas（原樣重新匯出）
export { DeviceCard, DeviceList } from '@company/ui-core';

// @company/ui-vortex（用別名重新匯出）
export { DeviceCard as ChannelCard } from '@company/ui-core';
export { DeviceList as ChannelList } from '@company/ui-core';

// @company/ui-edge-ai（用別名重新匯出）
export { DeviceCard as CameraCard } from '@company/ui-core';
export { DeviceList as CameraList } from '@company/ui-core';

跨產品治理

術語晉升流程

當產品特定術語應該成為核心術語時：

markdown

## 晉升標準

1. 被 2 個以上產品使用
2. 代表共享的業務概念
3. 沒有現有核心術語涵蓋它
4. 穩定定義（6 個月以上未變）

## 流程

1. 產品團隊提出術語晉升
2. 核心詞彙表團隊審查
3. 其他產品團隊評估影響
4. 定義規範形式
5. 為採用產品建立遷移計畫
6. 更新所有 CLAUDE.md 檔案

多產品情境的 CLAUDE.md

markdown

## 跨產品術語

### 在 [產品名稱] 工作時

此產品使用這些術語對應：

| 本產品 | 核心術語 | 其他產品 |
|--------|----------|----------|
| Channel | Device | VSaaS: Device, Edge AI: Camera |
| Location | DeviceGroup | VSaaS: Site, Edge AI: Zone |
| Clip | Recording | VSaaS: Recording, Edge AI: Event |

### 跨產品程式碼指引

1. **共用程式庫**：永遠使用核心規範術語
2. **產品程式碼**：可使用產品特定術語
3. **API 邊界**：在產品的 API 客戶端層轉換
4. **資料庫**：共用表使用核心術語，產品特定表使用產品術語

### 不確定時

1. 檢查 `glossary/cross-product/entity-mapping.md`
2. 如果概念存在於另一產品，使用核心術語
3. 如果是真正的新概念，向核心詞彙表團隊提出

成功指標

指標	之前	目標	如何測量
術語一致性	~60%	>95%	審計術語變體
AI 命名準確率	~70%	>90%	追蹤 AI 生成的程式碼審查
棄用術語使用	高	接近零	grep 棄用術語
跨平台對齊	低	高	比較跨平台命名
入職清晰度	天	小時	新開發者生產力調查

要避免的反模式

1. 詞彙表作為事後補救

問題： 建立詞彙表但不強制使用。

解決方案： 整合驗證到 CI/CD，作為 PR 檢查清單項目。

2. 過度工程術語

問題： 建立沒人自然使用的過度特定術語。

解決方案： 術語應該符合開發者實際討論概念的方式。

3. 忽略平台慣例

問題： 在有不同慣例的平台強制相同命名。

解決方案： 定義概念等價性同時尊重平台習慣用法。

4. 靜態詞彙表

問題： 詞彙表隨著程式庫演進而過時。

解決方案： 季度審查流程，詞彙表更新作為功能工作的一部分。

5. 無脈絡 (Context) 翻譯

問題： 直接翻譯術語而不考慮領域意義。

解決方案： 專注於概念對齊，而非字面翻譯。

快速參考卡

給 AI 生成程式碼

markdown

## 術語快速檢查

生成程式碼前：
1. [ ] 領域術語符合詞彙表？
2. [ ] 沒有使用棄用術語？
3. [ ] 命名慣例符合層級？
4. [ ] 跨平台術語對齊？

常見修正：
- `camera` -> `Device`
- `tenant` -> `Organization`
- `clip` -> `Recording`
- `alarm` -> `Alert`
- `site` -> `DeviceGroup`

相關： 持續脈絡清理 | 設計系統 | 返回： 提案概覽

參考資料

Domain-Driven Design - Eric Evans 關於通用語言的基礎著作
RFC 2119 - 用於表示需求等級的關鍵字
Claude Code 文件 - CLAUDE.md AI 指引檔案的官方文件

通用語言落地 ​

問題陳述 ​

現狀：術語混亂 ​

跨團隊回饋證據 ​

實際案例 ​

不一致的成本 ​

提議解決方案：領域驅動通用語言 ​

目標狀態 ​

通用語言架構 ​

術語定義標準 ​

術語文件模板 ​

UI 顯示 ​

AI 指引 ​

領域：影片串流 ​

遺留術語遷移 ​

遷移策略 ​

遺留術語對應表 ​

之後（通用語言） ​

實施路線圖 ​

階段 1：發現 ​

階段 2：文件化 ​

階段 3：工具化 ​

階段 4：遷移 ​

階段 5：強制執行 ​

驗證工具 ​

術語驗證腳本 ​

Pre-commit Hook 設定 ​

跨平台術語對應 ​

平台命名慣例 ​

API 到程式碼對應 ​

利害關係人術語協調 ​

翻譯鏈問題 ​

利害關係人術語使用模式 ​

多利害關係人術語定義 ​

協調機制 ​

1. PRD 前術語對齊 ​

2. PRD 模板含術語章節 ​

3. 群體精煉術語解決 ​

治理角色 ​

工作流程整合 ​

核心洞察 ​

跨產品術語協調 ​

跨產品問題 ​

跨產品不一致的影響 ​

聯邦詞彙表架構 ​

跨產品實體對應 ​

整合模式 ​

模式 1：共用後端 API ​

模式 2：產品對應層 ​

模式 3：共用元件庫 ​

跨產品治理 ​

術語晉升流程 ​

多產品情境的 CLAUDE.md ​

成功指標 ​

要避免的反模式 ​

1. 詞彙表作為事後補救 ​

2. 過度工程術語 ​

3. 忽略平台慣例 ​

4. 靜態詞彙表 ​

5. 無脈絡 (Context) 翻譯 ​

快速參考卡 ​

給 AI 生成程式碼 ​

參考資料 ​

通用語言落地

問題陳述

現狀：術語混亂

跨團隊回饋證據

實際案例

不一致的成本

提議解決方案：領域驅動通用語言

目標狀態

通用語言架構

術語定義標準

術語文件模板

UI 顯示

AI 指引

領域：影片串流

遺留術語遷移

遷移策略

遺留術語對應表

之後（通用語言）

實施路線圖

階段 1：發現

階段 2：文件化

階段 3：工具化

階段 4：遷移

階段 5：強制執行

驗證工具

術語驗證腳本

Pre-commit Hook 設定

跨平台術語對應

平台命名慣例

API 到程式碼對應

利害關係人術語協調

翻譯鏈問題

利害關係人術語使用模式

多利害關係人術語定義

協調機制

1. PRD 前術語對齊

2. PRD 模板含術語章節

3. 群體精煉術語解決

治理角色

工作流程整合

核心洞察

跨產品術語協調

跨產品問題

跨產品不一致的影響

聯邦詞彙表架構

跨產品實體對應

整合模式

模式 1：共用後端 API

模式 2：產品對應層

模式 3：共用元件庫

跨產品治理

術語晉升流程

多產品情境的 CLAUDE.md

成功指標

要避免的反模式

1. 詞彙表作為事後補救

2. 過度工程術語

3. 忽略平台慣例

4. 靜態詞彙表

5. 無脈絡 (Context) 翻譯

快速參考卡

給 AI 生成程式碼

參考資料