不要期待 AI 自己知道架構規則，而是把規則變成 AI 可以遵循的 Engineering Constraint

昨天看到 AI 很會寫 UI，卻不一定知道專案已經有這個 UI 實戰中這是很典型的問題，例如要求 AI 做一個 Dialog，它可能直接建立：

<ConfirmDialog />

但專案裡其實已經存在：

<BaseDialog />

問題開始從 UI 實作轉向 Architecture：

• 哪些 Component 應該重用？
• 哪些差異應該用 Props / Slots / Variants 處理？
• 什麼情況才值得建立新的 Boundary？

如果這些規則只存在工程師腦中，AI 很難穩定遵守。

Prompt：把架構規則寫成 Decision Rule

最基本的做法，是把規則直接寫進 AI 的 Instructions，例如，建立 Dialog 前：

Before creating a new Dialog:

1. Check existing Dialog components.
2. Prefer existing variants.
3. Use props or slots for content variation.
4. Do not create a new Dialog for styling differences.
5. Create a new component only when behavior
   or responsibility is structurally different.

這比單純寫 Do not create duplicate Dialog components. 有效得多。

因為後者只有限制，前者提供了判斷順序，但這裡還有一個問題：

AI 要去哪裡找既有 Component？

假設專案裡有：

components/
├── BaseDialog.vue
├── ConfirmDialog.vue
├── WarningDialog.vue
└── FormDialog.vue

光看檔名，AI 很難知道它們各自的 Boundary，例如：

ConfirmDialog
├── DeleteUser
├── DeleteAccount
└── RemoveItem

這些需求可能都屬於同一種 Interaction Pattern，真正需要重用的，是 Dialog 的 結構與行為。

Vue 的 Props、Slots 與 Component Composition 本身就提供了這種拆分方式：

固定結構留在 Component，變動內容交給使用端。

所以 Prompt 解決的是 遇到需求時，AI 應該遵循什麼判斷規則？

Design System：讓 AI 看得到可以使用的 Boundary

只有規則還不夠，如果告訴 AI：Prefer existing components. 卻沒有清楚描述有哪些元件可以使用，AI 還是只能從 Repository 裡猜，這就是 Design System 的另一個作用。

例如：

Design System

Dialog
├── BaseDialog
├── Confirm
├── Warning
└── Form

Button
├── Primary
├── Secondary
└── Danger

Form
├── FormField
├── Select
└── DatePicker

當需求變成建立刪除帳號確認視窗，AI 可以沿著既有 Architecture 找：

Delete Account
      ↓
Confirmation
      ↓
Confirm Dialog
      ↓
BaseDialog
      ├── title
      ├── message
      └── actions

而不是從零開始建立 AccountDeleteDialog.vue，這就是 Design System 對 AI Coding 的實際價值：

把 Architecture 轉成可以被選擇與組合的元件。

Storybook 之類的工具也可以協助整理 Component、Variants、Stories 與使用方式，讓這些資訊更容易被工程師與 AI 查找。

Code Review：檢查新的 Boundary 有沒有必要

即使 Design System 很完整，AI 還是可能建立 AccountDeleteDialog.vue，理由可能是：

The title is different.
The button color is different.
The button text is different.

這時 Code Review 可以增加一個 Architecture 問題：Why does this need to be a new Component?

可以先判斷 Component 之間差異是否可以透過 Props、Slots、Variants 或是 Composition 設定？

如果差異涉及 Lifecycle、State Model、Interaction Flow、Responsibility，就需要進一步判斷是否形成新的 Component Boundary。

因此 Code Review 可以從 Code 正不正確，增加「 Boundary 為什麼存在？」這個問題。

Architecture 要變成 Repository 裡的規則

到這裡可以把三層責任分開：

例如把 Component Architecture 直接寫成規則：

Component Rules

1. Prefer existing shared components.
2. Prefer variants over duplicated components.
3. Use slots for content variation.
4. Use props for data variation.
5. Create a new component when responsibility
   or behavior is structurally different.
6. Every new shared component requires
   a boundary rationale.

這些規則可以進一步放進：

Repository
├── AI Instructions
├── Design System
├── Component Docs
└── Code Review Rules

Architecture 就從口頭規範，變成 Repository 裡可以被查詢、遵循、Review 的 Engineering Constraint。

Prompt × Design System × Code Review

三層放在一起，就形成一個很實際的流程：

昨天處理 AI 為什麼一直產生重複 UI？

今天進一步處理 怎麼讓 AI 在既有 Architecture 裡做決策？

答案可以收斂成三件事：

Prompt 定義規則，Design System 提供選項，Code Review 驗證 Boundary。

這套機制的目的，也就從要求 AI 少寫一點 Code，轉成讓 AI 在既有 Architecture 中選擇正確的 Code。

參考資料

• Storybook Vue 教程