# AI 只懂 React？Vue.js 也能 Vibe Coding！- Kuro Hsu

{%hackmd o8oUosN0QnqMSkF1_6kH7g %}

#### 📚 議程介紹

{%preview https://webconf.tw/agenda/38 %}

#### 🔗 講者回顧

[WebConf 2025 延伸閱讀：Vue.js 與 AI 協作的開發新思維](https://kurohsu.dev/misc/webconf-2025-vue-sdd-ai-development.html?media_id=3787373774338372733_63320049424&media_author_id=63320049424&ranking_info_token=GCBjMDdiNjE0YzgxMTQ0ZjAyYTUzZWRiYjk1ZTM2ODlkOSXG3KgEFZADFvCD9pMNGBMzNzg3MzczNzE4Nzg4OTc2NTg3KANjY28A&utm_source=ig_text_post_permalink)

###### ▼▼▼ 開始筆記 ▼▼▼

> AI 真的不懂 Vue 嗎？

## Vibe Conding：快，但有代價

快速產出=>快速累積技術債

AI 訓練資料太雜，導致會寫出有 React 味的 Vue

## Vue SFC 的 AI 優勢

SFC 比 JSX 更適合用 AI 輔助

JSX：邏輯 條件 UI 混合在 return 區塊
SFC：邏輯 視圖 樣式 清楚分離

天然的邊界

## 為什麼這對 AI 很重要？

- 明確的邊界（比較不用跟 AI 描述太多）
- 樣式改 style
- 邏輯改 script
- AI 不容易改錯地方
- 語意化模板
- v-if v-for 比三元運算子更易讀
- AI 更容易理解意圖

- Scoped Style
- AI 寫的 CSS 不會影響其他元件
- 更安全可控

## Context Window 的現實
- JSX 的問題與SFC優勢
- AI 可能改錯地方，或改 A 壞 B
- SFC
- 精準定位

## AI 注意力的視覺化

結構化=更少幻覺+更精準的修改+更可預測的結果

<spec></spec>
>文件也放到ＳＦＣ架構下

## Tech Stack 選擇：對 AI 友善的軍火庫

### CSS 方案

Ｏ Tailwind CSS/ UnoCSS
X 傳統 CSS/SCSS

### UI Library

O Shadcn-vue/ Nuxt UI
▵ Element Plus//Vuetify

## Vue SFC 的殺手鐧：`<spec>` Custom Block

告訴 AI 應該生成什麼樣的東西

### 設定 `<spec>` 環境

SFC 本來就可以包含一些自定義的元素

1. 自訂 Vite Plugin：打包時移除 `<spec>`
2. TS 宣告：消除 IDE 警告

### 為什麼不用註解就好？

#### `<spec>`

- md 標題分層
- AI 精準找到標籤
- 語意明確表示這是規格

`<spec>` 給ＡＩ看 註解給人看

## 進階：用Tailwind Config 管理視覺規範

- tailwind.config.js = Design Token
- Spec 引用視覺 Token

## 規範的兩層架構

- 專案層：CLAUDE.md
- 全專案適用
- 元件層：`<spec>`
- 各個元件各自表述

## 為什麼 `<spec>` 是 Vue 的獨家優勢？

### Vue

- spec 與程式碼同檔案(SDD效益最大化)
- AI 自動讀取上下文
- Zero runtime cost
- git 版控一起追蹤（spec 和 code 一起進 git）
- 原生支援，不用其他工具或套件

### React
額外的.spec.md 或 JSDoc
手動維護文件與程式碼連結
需要自動 loader 或 plugin
沒有標準做法
沒有原生 Custom Block 概念

## Spec-Driven Development 規格驅動

### 從 TDD 到 SDD

- 傳統 TDD
- 優點：測試是最後防線
- 寫測試
- 寫程式碼
- 重構
- Vibe Coding
- Accept All 不看 diff，改 A 壞 B
- 技術債快速累積
- 上下文靠臨時 prompt ，下次就忘記
- 每次生成結果都不同
- 只能做 throwarway 專案
- SDD
- spec 明確定義行為，AI 修改有邊界
- spec 就是文件，變更歷史可追溯
- `<spec>` 區塊常駐檔案， AI 自動讀取
- spec 作為驗收標準，不依賴 AI 的一致性
- 可維護可追溯的 workflow

### 什麼是好的 spec ？
好的 Spec = 完整的上下文

#### X 模糊的 prompt

#### O 結構化的 Spec

# XXXX Component

## Props
- user: { name, avatar, role }

## Behavior
- role='admin' -> 金色邊框（amber-400）
- role='user' -> 灰色邊框（gray-e00）

## Unteraction
- 點擊觸發 select 事件

上下文要讓ＡＩ能理解

### SDD 開發閉環

- 傳統模式：程式碼改了->文件過期->沒人維護文件
- SDD 模式：改需求->先改 spec -> AI 更新程式碼 -> **文件永遠是新的**

人類一定要介入
> 減少幻覺的部分

1. Spec（人定義意圖）
2. AI 生成（code + test）
3. Verify（自動化驗收）
4. Sync -> 需求的迭代變更（觸發條件）回到第一點

要把跟ＡＩ溝通完還有手動作的修改同步回spec

- 核心價值：人只專注在 spec ，其他都交給 AI
- Test 的角色轉變：不是「額外寫的測試」，而是「Spec 的可執行版本」

## Spec -> 是 Test 的可執行的規格

## Interaction
- Hover 時顯示 "Hack" 按鈕
- 點擊 Hack 按鈕觸發 `hack-attempt` 事件

## SDD 核心原則：雙重 SSOT 與閉環控制

以前:規格跟程式碼不一致的時候 只能相信程式碼
現在:要改啥先改spec 變成從spec去改程式
> 這邊我理解是這樣Orz

## 需求變更時的 SDD 流程

PM 提出新需求 ->

## Interaction
- Hover 時顯示 "Hack" 按鈕
- 點擊 Hack 按鈕觸發 `hack-attempt` 事件

**就把需求改到 spec 裡讓 AI 生成**

## SDD 實務建議：分層策略
· 核心層（spec + test）
· 業務層（spec only）
· 顯示層（vibe coding）

跟「錢」有相關的一定要測試

## 實戰反思：理想 v.s. 現實

- 理想
- Spec = 單一真理（SSOT）
- 先改 spec 再改 code
- 文件永遠同步
- 現實
- Debug 直接改 Code（趕時間忘記改 spec）
- 全域重構讓 spec 過時
- 引入 Interceptor、改架構
- spec v.s. Code 衝突

## SDD 的彈性策略

- 輕量化 Spec
- Prompt 約束
- 反向同步

### 反向同步的關鍵：蒸餾，不是複製（抽象化）

Prompt 關鍵字：保留業務意圖與視覺規範，移除程式庫與佈局實作

## 跨元件的 Spec 整合

- 父元件：描述「我如何使用子元件」
- 子元件：描述「我提供什麼介面」

## 你必須比 AI 更懂 Vue

## Vue 開發者的王牌：SFC + `<spec>` ！！

## 3個takeaway

Template
https://gist.github.com/kurotanshi/2e59e6c6ff543697fca1309165b2a8fd

---
#### 聊天室

JSDC 2025 演講回顧：讓 AI 寫前端，我們來寫未來
https://kurohsu.dev/misc/jsdc-2025-ai-frontend-development.html

這個圖的積木 逼死強迫症ＸＤＤ

{%preview https://www.facebook.com/share/p/1DbXuEnmwe/ %}

再過不久 <test lang="vitest"></test> 都要出來了嗎ＸＤ