統一語言就是最好的 system prompt

🔖標籤 #ddd #ddd思考 #ai

[!AI] 本文摘要
團隊導入 AI 助理或 coding agent 時常出現答非所問或相似概念混淆的情況，根因往往是詞彙沒有對齊。每個限界上下文都該有一份專屬詞彙表，記錄術語的定義、應避免的同義詞，以及該詞彙在邊界外不適用的情形。這份詞彙表可以直接成為 AI 助理的上下文檔，讓通用語言精確地被放大成正確的程式碼。本文說明如何將限界上下文的詞彙表轉化為 AI 的 system prompt，並提供維護這份文件的具體做法。

團隊導入 AI 助理或 coding agent 時，常遇到一個狀況：你下了一個指令，AI 自信滿滿地產出程式碼，結果卻與你的預期有落差。問題往往不在於 AI 的推論能力不夠，而在於它對詞彙的詮釋與你的認知不同。當你說「刪除訂單」時，AI 不會舉手反問你指的是採購單還是出貨單，它會直接挑選一個解釋，產生看起來合理的程式碼，然後繼續往下做。

在傳統開發中，語意模糊會在程式碼審查、結對設計或白板討論的過程中被摩擦力攔截。然而，與 AI 協作時這層摩擦力消失了，程式碼能編譯、測試能通過，語意不符往往要等到下游系統出錯才會浮現。Daniel Schleicher 在 How Creating a Ubiquitous Language Ensures AI Builds What You Actually Want 一文中指出，當我們給予 AI 模糊的指令時，它會放大這份混亂並產生反映我們困惑的程式碼。相反地，精確的詞彙也會被放大成正確的類別名稱、生命週期狀態與邊界。

詞彙表是限界上下文的語意邊界

通用語言雖然名稱裡有「通用」二字，但它的適用範圍並非全公司通用。Vaughn Vernon 在《Implementing Domain-Driven Design》一書中強調，每個限界上下文都有自己的一份通用語言。這意味著同一個詞在不同上下文裡可以有不同的意義，團隊不應強行將所有子領域的詞彙統一成同一套。

以「顧客」為例，行銷部門稱之為潛在客戶，業務部門稱之為準客戶，倉儲部門稱之為收件人，財務部門稱之為債務人。這些詞彙並非單純的同義詞，它們帶有不同的屬性、生命週期狀態、不變量與行為。若將這些概念全部壓平成一個帶有類型欄位的顧客類別，反而會抹除每個領域長期累積的精確度。

因此，每個限界上下文都該維護一份詞彙表。這份詞彙表不只是名詞解釋，更要明確標註哪些詞在本上下文裡不適用，以及哪些看似同義的詞應避免混用。這份文件就是該上下文語意邊界的具體展現。

把詞彙表交給 AI 作為 system prompt

當 AI coding agent 讀取你的提示、系統指令或專案規則時，它的行為類似於一個每次重新報到的新開發者。它沒有上一次釐清詞彙的記憶，也沒有在遇到模糊術語時主動發問的直覺。如果你給它的上下文缺乏明確定義，它就會自行詮釋。

這份限界上下文的詞彙表，正好可以直接作為 AI 的 system prompt 或專案規則檔。當詞彙表明確記載了每個術語的定義、同義詞的禁用說明，以及跨上下文邊界的不適用情形時，AI 就能在正確的語意框架下運作。

以下是示意，展示一份最小限度的詞彙表如何以 markdown 格式提供給 AI 助理：

# 訂單管理上下文詞彙表

## 訂單
- 定義：顧客在結帳時建立的購買承諾，包含品項、數量、價格與配送地址。
- 避免使用：避免與付款記錄或出貨清單混用。
- 邊界外不適用：在付款上下文中，相同的現實概念應使用「付款請求」。

## 潛在客戶
- 定義：行銷活動中捕捉到的尚未確認購買意願的對象。
- 避免使用：不應與業務上下文的「準客戶」交替使用。

Martin Fowler 在 Pragmatic Summit 2026 的演講中提到，有同事正在發展一套精確的語言來與 agent 溝通領域知識，這基本上就是領域驅動設計中常見的模型建構與語言建構工作，但能讓他更有效率地與 agent 對話。這說明把通用語言整理成 AI 可讀的上下文檔，已經是業界正在實踐的方向。

維護詞彙表的做法

詞彙表不是寫一次就固定的文件，它需要隨著專案演進。Daniel Schleicher 提出了 Spec Ambiguity Resolver 模式，做法是維護一份活的詞彙表檔案，讓 AI 在規格撰寫、設計文件、任務拆解與實作階段都能主動標記模糊術語、提出定義建議，然後等待人工確認。一旦確認，整個專案就強制遵守這份一致性。

這種做法的核心在於，AI 不會自主創造定義，而是基於上下文提出建議並等待人工批准。這確保了通用語言代表的是真正的語意共識，而非單純由 AI 生成的文件。當團隊後續發現需要不同的概念時，可以建立不同的詞彙並各自給予精確定義。

在非英語領域的實務中，詞彙表的維護還涉及語言轉換的課題。Stack Exchange 上 Programming and Ubiquitous Language (DDD) in a non-English domain 的討論裡，提問者 Sandor Drieënhuizen 最終採用了維護對照表的做法：開發者與領域專家以母語溝通，同時將通用語言翻譯為英文並寫入程式碼。他發現翻譯的過程反而促使團隊更仔細地定義通用語言，甚至在不知如何翻譯某個詞彙而需要查閱字典時，回頭重新思考領域模型決策。

• 建立單一事實來源：詞彙表檔案應該是專案通用語言的唯一事實來源，所有規格、設計文件與程式碼都以此為準。
• 讓 AI 參與標記：讓 AI 在撰寫規格與實作時主動標記模糊詞彙，但最終定義權保留給人類。

重點

1. 限界上下文的詞彙表是 AI 協作的 system prompt 基礎。每個上下文一份詞彙表，記錄定義、避免使用的同義詞、以及該詞彙在邊界外不適用的情形，能讓 AI 在正確的語意框架下運作。
2. AI 不會主動釐清模糊詞彙，它會自行詮釋並產生程式碼。把詞彙表整理成上下文檔交給 AI，能讓精確的詞彙被放大成正確的類別名稱、生命週期狀態與邊界。
3. 詞彙表是活的文件，需要持續維護。讓 AI 標記模糊術語並提出定義建議，由人類確認後強制全專案遵守，確保語意共識而非 AI 自主生成的文件。
4. 在非英語領域中，維護母語與英文程式碼的對照表不僅解決溝通問題，翻譯過程本身也能促使團隊更深入思考領域模型的正確性。