universal-dev-standards 4.2.0 → 5.0.0-beta.10

package/bundled/locales/zh-TW/core/guides/anti-hallucination-guide.md

@@ -0,0 +1,779 @@
+---
+source: ../../core/anti-hallucination.md
+source_version: 1.4.0
+translation_version: 1.4.0
+last_synced: 2026-01-19
+status: current
+---
+
+# AI 協作防幻覺標準
+
+> **語言**: [English](../../../../core/anti-hallucination.md) | 繁體中文
+
+**版本**: 1.4.0
+**最後更新**: 2026-01-19
+**適用範圍**: 所有使用 AI 助理協作的軟體專案
+
+---
+
+## 目的
+
+本標準定義 AI 助理的嚴格準則，以防止在分析程式碼、提出建議或撰寫系統文件時產生幻覺（生成錯誤或未經驗證的資訊）。
+
+---
+
+## AI 助手互動規範
+
+### 對話語言
+
+AI 助手應適應使用者的偏好語言。當專案指定對話語言時，請遵循以下準則:
+
+| 情境 | 準則 | 範例 |
+|------|------|------|
+| 對話互動 | 使用專案指定語言 | 繁體中文、英文等 |
+| 確定性標籤 | 使用專案指定語言 | `[已確認]` 或 `[Confirmed]` |
+| 錯誤訊息解釋 | 使用專案指定語言 | 以使用者語言解釋編譯/執行錯誤 |
+| 技術術語 | 保留原文 | JWT、BCrypt、API、Token |
+| 程式碼註解 | 遵循專案慣例 | 通常為英文 |
+| Commit 訊息 | 遵循專案慣例 | 如 `feat(auth): 新增登入功能` |
+
+### 選項建議原則
+
+**規則**: 當提供多個選項時，必須同時提出最推薦的選項並說明理由。
+
+| 情境 | 要求 | 範例 |
+|------|------|------|
+| 提供 2+ 選項 | 必須明確標示推薦選項並說明理由 | 「推薦選項 A，因為...」 |
+| 選項優劣明顯 | 直接推薦最佳選項，說明理由 | 「建議使用 BCrypt，因為安全性較高」 |
+| 選項各有優劣 | 推薦最適合當前情境的選項，說明權衡考量 | 「考量專案需求，推薦選項 B」 |
+| 無法判斷優劣 | 說明需要哪些資訊才能給出推薦 | 「需要確認效能需求才能推薦」 |
+
+**範例**:
+
+❌ **錯誤**:
+```
+有三個選項:
+1. 使用 Redis 快取
+2. 使用記憶體快取
+3. 使用檔案快取
+
+請選擇一個。
+```
+
+✅ **正確**:
+```
+有三個選項:
+1. 使用 Redis 快取
+2. 使用記憶體快取
+3. 使用檔案快取
+
+**推薦: 選項 1 (Redis)**: 考量專案已有 Redis 基礎設施且需要跨實例共享快取，Redis 是最適合的選擇。
+```
+
+### 下一步建議
+
+**規則**: 當完成一項任務或子任務時，AI 助手**必須**建議合理的下一步工作，並明確標示**最推薦**的選項。
+
+**指引**:
+- **主動性**: 不要等待使用者問「接下來呢？」。
+- **情境相關**: 建議應遵循專案的工作流程（如：提案 -> 實作 -> 測試）。
+- **明確推薦**: 使用 `[推薦]` 或 `[Recommended]` 標示最佳路徑。
+
+**範例**:
+
+✅ **正確**:
+```
+任務完成: API 端點已實作。
+
+**建議下一步**:
+1. **[推薦]** 為新端點新增單元測試 (`src/tests/api/`)
+2. 更新 API 文件 (`docs/api-reference.md`)
+3. 開始前端整合
+```
+
+---
+
+## 核心原則
+
+### 1. 僅基於證據的分析
+
+**規則**: 僅分析和引用已明確提供或讀取的內容。
+
+**指引**:
+- ✅ 分析已使用檔案讀取工具讀取的程式碼檔案
+- ✅ 引用已擷取的文件
+- ✅ 引用已檢查的設定檔
+- ❌ 不要推測未見過的 API、函式或設定
+- ❌ 不要在未驗證的情況下假設框架行為
+- ❌ 不要捏造需求細節
+
+**範例**:
+
+✅ **正確**:
+```
+[證據] 在 src/auth/service.ts:45，JWT 驗證邏輯使用 'jsonwebtoken' 函式庫
+[證據] package.json 檔案（第 12-18 行）列出 Express 4.18.2 作為相依項目
+```
+
+❌ **錯誤**:
+```
+此系統使用 Redis 進行快取（程式碼未審查）
+UserService 應該有 authenticate() 方法（API 未驗證）
+需求指出我們需要 SSO 登入支援（需求未確認）
+```
+
+---
+
+### 2. 明確來源標註
+
+**規則**: 所有引用必須包含來源類型、位置與可驗證性資訊。
+
+#### 2.1 來源類型
+
+| 來源類型 | 標籤 | 說明 | 可靠度 |
+|---------|------|------|--------|
+| 專案程式碼 | `[來源: 程式碼]` | 直接從程式碼庫讀取 | ⭐⭐⭐⭐⭐ 最高 |
+| 專案文件 | `[來源: 文件]` | README、Wiki、程式碼註解 | ⭐⭐⭐⭐ 高 |
+| 外部文件 | `[來源: 外部]` | 官方文件（附 URL） | ⭐⭐⭐⭐ 高 |
+| 網路搜尋 | `[來源: 搜尋]` | 搜尋結果（包含日期） | ⭐⭐⭐ 中 |
+| AI 知識 | `[來源: 知識]` | AI 訓練資料（需驗證） | ⭐⭐ 低 |
+| 使用者提供 | `[來源: 使用者]` | 使用者對話中的資訊 | ⭐⭐⭐ 中 |
+
+#### 2.2 標註格式
+
+**程式碼引用**:
+```
+[來源: 程式碼] 檔案路徑:行號 - 描述
+```
+
+**外部文件**:
+```
+[來源: 外部] URL - 描述（版本: x.x.x，存取: YYYY-MM-DD）
+```
+
+**AI 知識**:
+```
+[來源: 知識] 主題 - 描述（⚠️ 需要驗證）
+```
+
+#### 2.3 範例
+
+✅ **正確**:
+```
+[來源: 程式碼] UserService.cs:142 - 密碼雜湊使用 BCrypt
+[來源: 程式碼] app.config:23-28 - 資料庫連線字串設定為 SQL Server
+[來源: 文件] README.md:15 - 專案需要 .NET 8.0 SDK
+[來源: 外部] https://react.dev/reference/react/useState - useState hook API（版本: React 18，存取: 2025-12-10）
+[來源: 搜尋] "Express.js middleware order" - 中介軟體依註冊順序執行（搜尋: 2025-12-10）
+[來源: 知識] HTTP 狀態碼 - 404 表示資源未找到（⚠️ 一般知識，請驗證您的 API）
+[來源: 使用者] 使用者在對話中表示 - 驗證必須支援 OAuth2
+```
+
+❌ **錯誤**:
+```
+驗證服務使用 BCrypt（無來源類型，無檔案引用）
+設定檔案中某處有資料庫連線（模糊引用）
+我認為 README 提到 .NET 8（不確定語言，無來源）
+React useState 的運作方式是...（無版本，無引用）
+```
+
+#### 2.4 版本敏感性
+
+**規則**: 引用函式庫、框架或 API 時，必須包含版本資訊（如有）。
+
+**為何重要**:
+- API 在不同版本間會改變
+- 已棄用的功能可能仍出現在 AI 訓練資料中
+- 安全性漏洞是版本特定的
+
+**範例**:
+```
+✅ [來源: 外部] Next.js App Router (v14.x) - Server Components 是預設值
+✅ [來源: 程式碼] package.json:12 - 使用 "express": "^4.18.2"
+❌ "Next.js 使用 Server Components"（哪個版本？v12 和 v14 行為不同）
+```
+
+---
+
+### 3. 分類確定性等級
+
+**規則**: 明確區分已確認事實、推測與未知事項。
+
+**分類標籤**:
+
+| 標籤 | 使用時機 |
+|-----|---------|
+| `[已確認]` | 直接來自程式碼/文件的證據 |
+| `[推測]` | 基於現有證據的邏輯推論 |
+| `[假設]` | 基於常見模式（需驗證）|
+| `[未知]` | 資訊不可得 |
+| `[需確認]` | 需要使用者澄清 |
+
+**範例**:
+
+✅ **正確**:
+```
+[已確認] src/database/connection.ts:12 - 使用 PostgreSQL 驅動程式 'pg'
+[推測] 基於 src/repositories/ 中的 repository 模式，可能使用依賴注入
+[假設] 專案可能使用 OAuth2，但需要審查驗證設定
+[未知] API 速率限制策略未記錄
+[需確認] 新功能是否應支援多租戶？
+```
+
+❌ **錯誤**:
+```
+系統使用 Redis（無分類，無證據）
+我們應該實作快取（以事實呈現，非建議）
+使用者需要 SSO 支援（假設以已確認需求呈現）
+```
+
+#### 統一標籤系統
+
+本標準定義兩類互補的標籤類別，用於相關標準：
+
+**類別 1：確定性標籤**（用於分析現有內容）
+
+用於分析程式碼、審查文件或討論系統時。參見[反向工程標準](../reverse-engineering-standards.md)。
+
+| 標籤 | 用途 | 範例情境 |
+|-----|------|---------|
+| `[已確認]` | 直接來自程式碼/文件的證據 | 程式碼分析、測試提取 |
+| `[推測]` | 基於模式的邏輯推論 | 行為分析、架構審查 |
+| `[假設]` | 需驗證的合理猜測 | 缺口識別、推測 |
+| `[未知]` | 無法從現有資訊判斷 | 缺少文件 |
+| `[需確認]` | 需要人類輸入 | 模糊的需求 |
+
+**類別 2：推導標籤**（用於生成新內容）
+
+用於從已核准來源生成測試、規格或文件時。參見[正向推演標準](../forward-derivation-standards.md)。
+
+| 標籤 | 用途 | 範例情境 |
+|-----|------|---------|
+| `[來源]` | 直接來自規格/需求的內容 | SPEC 標題、AC 文字原文 |
+| `[推導]` | 從來源內容轉換而來 | 從條列 AC 轉換的 GWT |
+| `[生成]` | AI 生成的結構 | 測試骨架、TODO 註解 |
+| `[待辦]` | 需要人類實作 | Step definitions、斷言 |
+
+**何時使用哪種**：
+
+| 工作流程 | 主要標籤 | 次要標籤 |
+|----------|---------|---------|
+| 程式碼分析 | 確定性標籤 | - |
+| 反向工程 | 確定性標籤 | - |
+| 正向推演 | 推導標籤 | 確定性標籤（用於缺口）|
+| 規格生成 | 推導標籤 | 確定性標籤（用於未知）|
+
+---
+
+### 4. 禁止行為
+
+**AI 助手不得**:
+
+1. **捏造 API 或函式簽名**
+   - ❌ 不要編造方法名稱、參數或回傳類型
+   - ✅ 要讀取實際原始碼或詢問使用者
+
+2. **假設需求**
+   - ❌ 不要猜測使用者需求或業務規則
+   - ✅ 當需求模糊時要提出澄清問題
+
+3. **推測未讀取的程式碼**
+   - ❌ 不要描述未審查檔案的功能
+   - ✅ 要明確表示「需要讀取 [檔案] 以確認」
+
+4. **編造設定**
+   - ❌ 不要假設環境變數、設定鍵或資料庫結構
+   - ✅ 要審查實際設定檔
+
+5. **憑空產生錯誤或 Bug**
+   - ❌ 不要在無證據的情況下聲稱程式碼有問題
+   - ✅ 要分析實際程式碼並引用特定行號
+
+6. **提出選項但不推薦**
+   - ❌ 不要列出選項後要求使用者選擇而不提供指引
+   - ✅ 要永遠包含推薦選項並附理由
+
+7. **未分析副作用即實作**
+   - ❌ 不要在未識別潛在副作用的情況下開始寫程式碼
+   - ✅ 要在實作前列出至少 3 個潛在副作用
+   - ✅ 要考慮：狀態變更、相依性、連鎖效應
+
+#### 詳細範例
+
+##### 1. 捏造 API 或函式名稱
+
+❌ **錯誤**:
+```
+助理: 「你可以呼叫 UserService.GetUserById(int id) 來取得使用者」
+```
+**問題**: 方法不存在或簽名不同。
+
+✅ **正確**:
+```
+助理: 「讓我讀取 UserService 檔案以找到正確的方法簽名。」
+
+[讀取 src/services/UserService.cs 後]
+
+[來源: 程式碼] UserService.cs:45 - 找到方法: FindUser(Guid userId)
+實際方法使用 Guid 而非 int 作為使用者 ID 參數。
+```
+
+---
+
+##### 2. 假設使用者需求
+
+❌ **錯誤**:
+```
+助理: 「系統需要支援 OAuth 和 SAML 以提供企業 SSO。」
+```
+**問題**: 使用者只詢問認證，未指定協議。
+
+✅ **正確**:
+```
+助理: 「[需確認] 您提到需要驗證功能。
+能否澄清:
+1. 這是給內部使用者、外部客戶，還是兩者都有？
+2. 您需要企業 SSO（OAuth/SAML）還是簡單的使用者名稱/密碼？
+3. 有任何需要整合的現有身分提供者嗎？
+
+這將幫助我推薦最適合的方法。」
+```
+
+---
+
+##### 3. 描述未讀取的程式碼功能
+
+❌ **錯誤**:
+```
+助理: 「PaymentService 處理信用卡處理並與 Stripe 整合。」
+```
+**問題**: 檔案未讀取，功能僅從名稱假設。
+
+✅ **正確**:
+```
+助理: 「我在您的專案結構中看到名為 PaymentService.cs 的檔案。
+
+[未知] 我尚未讀取此檔案，因此無法確認其功能。
+
+您想讓我讀取 src/services/PaymentService.cs 以了解:
+- 它使用哪個支付提供者？
+- 支援哪些支付方式？
+- 交易如何處理？」
+```
+
+---
+
+##### 4. 編造設定細節
+
+❌ **錯誤**:
+```
+助理: 「設定 DATABASE_URL 環境變數以連線到 PostgreSQL。
+您的連線字串應在 appsettings.json 的 'ConnectionStrings:DefaultConnection' 下。」
+```
+**問題**: 設定結構和變數名稱未經驗證即假設。
+
+✅ **正確**:
+```
+助理: 「讓我檢查您的實際設定檔。」
+
+[讀取 appsettings.json 後]
+
+[來源: 程式碼] appsettings.json:8-12 - 找到資料庫設定:
+- 連線字串鍵: "ConnectionStrings:MainDb"（非 "DefaultConnection"）
+- 使用 SQL Server，非 PostgreSQL
+- 額外設定 "CommandTimeout": 30
+
+您的專案使用與 .NET 預設不同的鍵名稱。
+```
+
+---
+
+##### 5. 斷言程式碼有 Bug（無證據）
+
+❌ **錯誤**:
+```
+助理: 「您的驗證程式碼有安全性漏洞 -
+您沒有正確進行密碼雜湊。」
+```
+**問題**: 未讀取實際程式碼即聲稱有 Bug。
+
+✅ **正確**:
+```
+助理: 「讓我審查您的驗證實作。」
+
+[讀取 src/auth/AuthService.cs 後]
+
+[已確認] AuthService.cs:67 - 找到密碼雜湊實作:
+- 使用 BCrypt，work factor 為 12 ✅
+- Salt 自動生成 ✅
+- 未偵測到時序攻擊漏洞 ✅
+
+您的密碼雜湊實作遵循安全性最佳實務。
+在審查的程式碼中未發現問題。
+```
+
+---
+
+##### 6. 選項未附推薦
+
+❌ **錯誤**:
+```
+助理: 「您可以使用: 1) JWT 2) Session 3) OAuth。您偏好哪個？」
+```
+**問題**: 列出選項但未提供指引或考慮情境。
+
+✅ **正確**:
+```
+助理: 「基於您的需求:
+
+**選項**:
+1. JWT - 無狀態、可擴展、適合 API
+2. Session - 伺服器端狀態、傳統 Web 應用程式
+3. OAuth - 第三方身分提供者
+
+**推薦: JWT**
+
+[推測] 基於您的微服務架構（見於 docker-compose.yml），
+JWT 是最適合的，因為:
+- 無狀態: 跨服務不需要 session 儲存
+- 可擴展: 每個服務可獨立驗證 token
+- 標準: 在您的技術堆疊（.NET、React）中有良好支援
+
+如果之後需要社交登入，可以在 JWT 之上加入 OAuth。」
+```
+
+---
+
+##### 7. 未分析副作用即實作
+
+❌ **錯誤**:
+```
+使用者: 「新增一個刪除使用者帳號的功能」
+助理: 「這是實作:
+
+public async Task DeleteUser(Guid userId) {
+    await _dbContext.Users.Where(u => u.Id == userId).DeleteAsync();
+}
+」
+```
+**問題**: 未考慮連鎖效應即直接實作。
+
+✅ **正確**:
+```
+使用者: 「新增一個刪除使用者帳號的功能」
+助理: 「在實作前，讓我先識別潛在副作用:
+
+**潛在副作用**:
+1. **資料完整性**: 相關記錄（訂單、評論、工作階段）可能變成孤立資料
+2. **外部系統**: 可能需要通知第三方服務（支付提供者、電子郵件服務）
+3. **稽核軌跡**: 刪除可能違反合規要求（GDPR 被遺忘權 vs. 稽核日誌）
+
+[需確認] 應如何處理:
+- 相關使用者資料（級聯刪除 vs. 匿名化）？
+- 活動中的工作階段？
+- 用於報表的歷史記錄？
+
+一旦確認後，我會提供實作。」
+```
+
+---
+
+## 實施檢查清單
+
+在對程式碼、需求或架構做出任何陳述前，請驗證:
+
+- [ ] **來源已驗證**
+  - 我是否已讀取實際的檔案/文件？
+
+- [ ] **來源類型已標註**
+  - 我是否已指定來源類型？（`[來源: 程式碼]`、`[來源: 外部]`、`[來源: 知識]` 等）
+
+- [ ] **引用已標註**
+  - 我是否已包含檔案路徑與行號（程式碼）？
+  - 我是否已包含 URL 與存取日期（外部文件）？
+
+- [ ] **版本已標註**
+  - 我是否已包含適用的函式庫/框架版本？
+
+- [ ] **確定性已分類**
+  - 我是否已標註為 [已確認]、[推測]、[假設]、[未知] 或 [需確認]？
+
+- [ ] **AI 知識已標記**
+  - 我是否已對 `[來源: 知識]` 標記 ⚠️ 驗證警告？
+
+- [ ] **無捏造**
+  - 我是否避免了捏造 API、設定或需求？
+
+- [ ] **使用者澄清**
+  - 我是否對模糊點請求澄清？
+
+- [ ] **包含推薦**
+  - 當提出選項時，我是否包含了推薦選項？
+
+- [ ] **已識別副作用**
+  - 我是否在實作前列出至少 3 個潛在副作用？
+  - 我是否考慮了：狀態變更、相依性、外部系統、資料完整性？
+
+---
+
+## 審查情境
+
+### 情境 1: 程式碼分析
+
+**使用者請求**: 「審查驗證邏輯」
+
+**❌ 不良回應**:
+```
+您的驗證系統使用 JWT 搭配 RS256 簽名。
+Token 在 1 小時後過期。
+您應該加入 refresh token 支援。
+```
+**問題**: 未讀取程式碼即做出聲明，假設實作細節。
+
+**✅ 良好回應**:
+```
+[需確認] 哪個檔案包含驗證邏輯？
+可能的位置包括:
+- src/auth/
+- src/services/auth
+- src/middleware/
+
+請引導我找到正確的檔案，以便我提供準確分析。
+
+或者，我可以搜尋程式碼庫中與驗證相關的檔案。
+```
+
+---
+
+### 情境 2: 架構建議
+
+**使用者請求**: 「我應該如何架構新的付款模組？」
+
+**❌ 不良回應**:
+```
+基於您現有的架構，您應該:
+1. 在 src/services/ 建立 PaymentService
+2. 使用 Stripe API
+3. 將交易儲存在 payments 資料表
+```
+**問題**: 未經證據即假設架構、支付提供者和資料庫結構。
+
+**✅ 良好回應**:
+```
+為了提供準確的建議，我需要了解您目前的架構:
+
+[需確認]
+1. 您計劃使用哪個支付提供者？（Stripe、PayPal、自訂等）
+2. 您現有的服務層結構是什麼？
+3. 您使用什麼資料庫？
+
+能否分享:
+- 專案結構（ls -R src/ 或類似）
+- 現有服務範例
+- 資料庫結構或 ORM 模型
+
+一旦我審查了這些，就能建議與您的模式一致的結構。
+```
+
+---
+
+### 情境 3: Bug 調查
+
+**使用者請求**: 「登入失敗」
+
+**❌ 不良回應**:
+```
+問題可能在您的 validateCredentials() 函式中。
+您可能需要在比對前對密碼進行雜湊。
+```
+**問題**: 未看程式碼即猜測原因。
+
+**✅ 良好回應**:
+```
+要調查登入失敗，我需要更多資訊:
+
+[需確認]
+1. 您看到什麼錯誤訊息？（主控台日誌、錯誤回應）
+2. 哪個檔案包含登入邏輯？
+3. 能否分享相關的程式碼片段或日誌？
+
+建議的除錯步驟:
+- 分享登入控制器/服務程式碼
+- 提供主控台/伺服器的錯誤日誌
+- 描述預期與實際行為
+
+一旦我審查了實際程式碼和錯誤，就能找出根本原因。
+```
+
+---
+
+### 情境 4: 技術選型
+
+**使用者請求**: 「我應該使用什麼快取解決方案？」
+
+**❌ 不良回應**:
+```
+您有幾個選項:
+1. Redis
+2. Memcached
+3. 記憶體快取
+
+讓我知道您想使用哪一個。
+```
+**問題**: 列出選項但未推薦或考慮情境。
+
+**✅ 良好回應**:
+```
+基於可用的選項:
+1. Redis - 分散式、持久化、豐富的資料結構
+2. Memcached - 簡單、快速、分散式
+3. 記憶體快取 - 僅本機、無需設定
+
+**推薦: Redis**
+
+[需確認] 在最終決定前，我想了解:
+- 您需要跨多個實例共享快取嗎？
+- 需要資料持久化嗎？
+- 您現有的基礎設施是什麼？
+
+如果您已有 Redis 基礎設施或需要跨實例共享，
+Redis 是最佳選擇。如果這是單實例應用程式且有
+簡單的快取需求，記憶體快取就足夠了。
+```
+
+---
+
+## AI 助理工作流程
+
+```
+┌─────────────────────────────────┐
+│  收到使用者請求                  │
+└─────────────┬───────────────────┘
+              │
+              ▼
+┌─────────────────────────────────┐
+│  識別所需資訊                    │
+│  - 程式碼檔案？                  │
+│  - 設定？                        │
+│  - 需求？                        │
+└─────────────┬───────────────────┘
+              │
+              ▼
+┌─────────────────────────────────┐
+│  識別潛在副作用                  │
+│  - 狀態變更？                    │
+│  - 受影響的相依性？              │
+│  - 外部系統影響？                │
+└─────────────┬───────────────────┘
+              │
+              ▼
+         ┌────┴────┐
+         │  可取得？ │
+         └────┬────┘
+              │
+      ┌───────┴───────┐
+      │               │
+     是              否
+      │               │
+      ▼               ▼
+┌──────────┐   ┌─────────────┐
+│  讀取/   │   │  向使用者   │
+│  分析    │   │  詢問資訊   │
+└────┬─────┘   └──────┬──────┘
+     │                │
+     ▼                ▼
+┌─────────────────────────────────┐
+│  為回應加上標籤:                 │
+│  - [已確認] 用於事實             │
+│  - [推測] 用於推論               │
+│  - [需確認] 用於缺口             │
+└─────────────┬───────────────────┘
+              │
+              ▼
+┌─────────────────────────────────┐
+│  引用來源（檔案:行號）           │
+└─────────────┬───────────────────┘
+              │
+              ▼
+┌─────────────────────────────────┐
+│  包含推薦                        │
+│  （如提出選項）                  │
+└─────────────┬───────────────────┘
+              │
+              ▼
+┌─────────────────────────────────┐
+│  提供回應                        │
+└─────────────────────────────────┘
+```
+
+---
+
+## 語言無關應用
+
+本標準適用於任何程式語言、框架或領域:
+
+- **Web 開發**: 未經證據不假設 Express/Django/Spring Boot
+- **行動開發**: 未經證據不假設 React Native/Flutter
+- **資料科學**: 未經證據不假設 TensorFlow/PyTorch
+- **DevOps**: 未經證據不假設 Docker/Kubernetes
+
+**通用規則**: 先讀取，再分析，永遠以證據報告。
+
+---
+
+## 與程式碼審查整合
+
+執行程式碼審查時，應用這些原則:
+
+1. **引用行號**: 所有審查評論必須引用特定行號
+2. **以證據分類嚴重性**:
+   - `[已確認 Bug]` - 程式碼明顯損壞
+   - `[潛在問題]` - 程式碼可能造成問題
+   - `[建議]` - 改善想法（非缺陷）
+3. **避免假設**: 如不確定設計意圖，詢問作者
+
+**審查評論範本**:
+```
+[檔案:行號] - [嚴重性]
+[問題描述與程式碼摘錄]
+[證據或推理]
+[建議修正或澄清問題]
+```
+
+---
+
+## 相關標準
+
+- [測試標準](../testing-standards.md) - 確保驗證 AI 分析結果（或使用 `/testing-guide` 技能）
+- [程式碼審查清單](../code-review-checklist.md) - 審查 AI 生成內容
+- [程式碼簽入標準](../checkin-standards.md) - AI 協作簽入流程
+
+---
+
+## 版本歷史
+
+| 版本 | 日期 | 變更 |
+|------|------|------|
+| 1.4.0 | 2026-01-19 | 新增: 副作用分析規則（第 7 條禁止行為）、工作流程步驟及檢查清單項目 |
+| 1.3.1 | 2025-12-24 | 新增: 相關標準章節 |
+| 1.3.0 | 2025-12-22 | 增強: 禁止行為章節，新增詳細對比範例 |
+| 1.2.0 | 2025-12-15 | 新增: AI 助手互動規範章節（對話語言、推薦原則） |
+| 1.1.0 | 2025-12-10 | 增強來源標註，新增來源類型、版本敏感性與可靠度評級 |
+| 1.0.0 | 2025-11-12 | 初版發布 |
+
+---
+
+## 授權
+
+本標準以 [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/) 授權發布。
+您可以自由調整用於您的專案，但需註明出處。
+
+---
+
+**專案特定化**
+
+專案可透過以下方式擴充本標準:
+- 領域特定驗證需求（如醫療領域的 HIPAA 合規檢查）
+- 工具特定指引（如如何驗證 Terraform 設定）
+- 團隊特定證據格式（如 JIRA ticket 引用）
+- AI 助手對話的語言偏好