---
source: ../../../core/ai-agreement-standards.md
source_version: 1.0.0
translation_version: 1.0.0
last_synced: 2026-03-24
status: current
---

# AI 協議標準

> **語言**: [English](../../../core/ai-agreement-standards.md) | 繁體中文

**版本**: 1.0.0
**最後更新**: 2026-01-29
**適用性**: 所有 AI 輔助開發工作階段
**範圍**: 通用 (Universal)
**業界標準**: ISO 12207 §6.1
**ISO 12207 對應**: 協議程序 (6.1)

---

## 目的

本標準將人類（需求方）與 AI（供應方）之間的互動形式化為可驗證的協議。在「Vibe Coding」中，prompt 上下文作為管控 AI 行為和交付物的合約。

---

## 1. 上下文合約

每個 AI 工作階段必須以清晰的上下文合約開始。通常透過系統 prompt 檔案實現（如 `CLAUDE.md`、`.cursorrules`）。

### 1.1 合約組成

有效的上下文合約必須定義：

| 組成部分 | 說明 | 範例 |
|----------|------|------|
| **角色定義** | 使用者 vs. AI 的代表身份 | 「你是一位資深後端工程師...」 |
| **工作範圍** | 操作邊界 | 「只修改 `src/utils/` 中的檔案，不要碰 `config/`。」 |
| **約束法則** | 不可協商的規則 | 「不可硬編碼密鑰。必須使用 TypeScript。」 |
| **驗收條件** | 完成定義 | 「程式碼必須通過 `npm test` 和 `npm run lint`。」 |

## 2. 需求提案（RFP）標準

複雜任務應以「RFP」（需求提案）格式組織，而非簡單的對話訊息。

### RFP 範本

```markdown
## 背景
[描述現狀和為什麼需要此變更]

## 範圍
[明確列出要修改的檔案和功能]

## 驗收條件
- [ ] 條件 1
- [ ] 條件 2

## 約束
- [不可做的事項]
- [技術限制]
```

## 3. 變更管理

| 變更類型 | 處理方式 |
|----------|----------|
| **範圍擴增** | AI 必須標示超出原始合約的請求 |
| **需求變更** | 必須更新上下文合約後才能執行 |
| **緊急修復** | 可繞過合約但必須事後補充文件 |

## 4. 交付驗證

每次交付必須包含：

| 項目 | 說明 |
|------|------|
| **自我驗證** | AI 在交付前執行合約中定義的驗收條件 |
| **變更摘要** | 列出所有修改的檔案和變更原因 |
| **風險揭露** | 標示任何潛在風險或未解決的問題 |

## 相關標準

- [虛擬組織標準](virtual-organization-standards.md)
- [反幻覺標準](anti-hallucination.md)
- [驗證證據](verification-evidence.md)
