2026年9月5日 星期六

Astro + Vue 3 的 AI 開發標準:Docs MCP、Project Rules 與 Skills

前言:AI 會寫 Vue,不代表 AI 真的懂你的 Astro + Vue 3 專案

這幾年 AI Coding Agent 發展非常快。

從最早的:

「幫我寫一個 Vue Component。」

逐漸進化成:

「幫我修改這個頁面。」

再到現在:

「分析整個專案,幫我完成這個功能。」

AI 已經不只是 Code Generator,而開始扮演 Junior Engineer 的角色。

但是問題也跟著出現。

AI 越能直接修改專案,Context 是否正確就越重要。

尤其是 Astro + Vue 3 專案。

因為這類專案通常不是單純的 Vue SPA,而是:

text
Astro
│
├── Pages
├── Layouts
├── Components
├── SSR / SSG
├── Routing
├── SEO
├── API
│
└── Vue 3
      ├── Interactive Components
      ├── State
      ├── Forms
      └── Client-side Logic

如果 AI 不理解 Astro 與 Vue 3 的責任邊界,很容易出現一個常見問題:

AI 把所有東西都 Vue 化。

這不一定是正確的做法。

Astro 的核心價值之一,就是讓頁面預設保持輕量,只有真正需要互動的部分才交給 JavaScript Framework。

因此,對 Astro + Vue 3 專案而言,真正重要的不是:

「AI 能不能寫 Vue?」

而是:

「AI 是否理解什麼時候該使用 Astro,什麼時候才應該使用 Vue 3?」

這就是 Astro + Vue 3 AI Development 真正值得討論的地方。


一、Astro + Vue 3 的 AI 開發問題

傳統 AI Coding 的流程通常是:

text
需求
 ↓
AI
 ↓
產生 Code
 ↓
完成

這個流程在小型專案可能沒有問題。

但是當專案開始變大,就會遇到:

text
AI 不知道目前 Astro 版本
        ↓
AI 使用過時 API

AI 不知道專案架構
        ↓
AI 新增重複 Component

AI 不知道 Astro / Vue 分工
        ↓
AI 把 Astro Component 改成 Vue

AI 不知道 API 架構
        ↓
AI 自己新增 fetch / axios

AI 不知道命名規則
        ↓
專案開始出現不同風格

AI 不知道既有 State 管理方式
        ↓
又新增一套 State

最後不是 AI 不會寫 Code。

而是:

AI 寫出了「可以運作」但不符合專案架構的 Code。

這才是 AI Coding 真正需要解決的問題。


二、Astro 官方正在建立自己的 AI 開發工具鏈

Astro 現在已經不是完全依賴一般 AI 模型自己理解框架。

Astro 官方提供了:

  • Astro Docs MCP
  • Astro Agent Skills
  • AI 開發指南
  • Project Rules / Coding Standards 的整合方式
  • 與各種 AI Coding Agent 的整合

其中最重要的就是:

Astro Docs MCP

它可以讓 AI Agent 在需要時直接查詢 Astro 官方文件,而不是完全依賴模型本身的訓練資料。

官方也特別指出,AI Coding 工具可能使用過時的 Astro API,因此建議讓 Agent 存取最新 Astro Documentation。

這個概念非常重要。

因為:

text
AI Model
   ↓
「我記得 Astro 是這樣寫」

跟:

text
AI Agent
   ↓
Astro Docs MCP
   ↓
最新官方文件
   ↓
確認 API

是完全不同的開發方式。


三、Astro Docs MCP:讓 AI 查詢最新 Astro 文件

Astro 官方提供 Docs MCP Server:

text
https://mcp.docs.astro.build/mcp

它的角色不是幫你寫 Code。

而是:

提供 AI 正確的 Astro 知識。

可以把它理解成:

text
AI Agent
                  │
                  ↓
           Astro Docs MCP
                  │
                  ↓
          Astro Official Docs
                  │
                  ↓
        最新 Astro API / Guide

因此當 AI 遇到 Content Collections、Routing、Actions、Middleware、SSR、Islands、Integrations、Image 等問題時,可以先取得官方資訊,再開始修改程式碼。


四、但是只有 Astro Docs MCP 還不夠

這是最容易被誤解的地方。

Astro Docs MCP 解決的是:

「Astro 官方怎麼使用?」

但它不知道:

「你的專案怎麼使用 Astro?」

例如官方文件可能告訴 AI:

text
Astro 可以使用 Vue Component。

但你的專案可能規定:

text
只有互動功能才使用 Vue。
純展示內容必須使用 Astro Component。
不要為了方便而把 Astro Component 改成 Vue Component。

這兩個資訊並不衝突。

一個是 Framework Knowledge,另一個是 Project Knowledge。

因此還需要:

Project Rules


五、Project Rules:讓 AI 知道「我們怎麼開發」

這是 Astro + Vue 3 AI 開發真正重要的一層。

例如:

text
.ai/
└── rules/
    ├── index.md
    ├── architecture.md
    ├── astro.md
    ├── vue.md
    ├── api.md
    └── performance.md

可以定義:

text
Astro 負責:
- Page
- Layout
- SEO
- SSR / SSG
- Server-side Data
- Static Content

Vue 3 負責:
- Interactive UI
- Client-side State
- Form Interaction
- Complex UI
- Browser Events

這樣 AI 在修改專案時,就不會只考慮「哪一種寫法最快」,而會考慮「哪一種寫法符合這個專案的架構」。


六、Astro 與 Vue 3 的責任邊界

這是 Astro + Vue 3 專案最值得寫進 AI Rules 的規則。

可以簡化成:

text
Astro
 ↓
負責頁面結構與 Server / Static 工作

Vue 3
 ↓
負責需要互動的 UI

例如:

text
首頁
│
├── Header              → Astro
├── Hero                → Astro
├── Article List        → Astro
├── Product Filter      → Vue 3
├── Shopping Cart       → Vue 3
└── Footer              → Astro

這就是 Astro Islands 思維。

不是整個網站都用 Vue,而是:

text
Astro Page
│
├── Static Content
│
├── Static Content
│
└── Vue Island
       ↓
    Interactive UI

這個架構如果沒有明確告訴 AI,AI 很容易為了方便,把大量內容全部轉成 Vue。


七、AI 最容易犯的錯:過度 Vue 化

例如原本:

astro
<ProductCard product={product} />

如果只是展示資料,根本不需要 Vue。

但是 AI 可能會說:

「Product Card 未來可能需要互動,所以改成 Vue Component。」

這就是典型的 AI 過度工程。

比較好的 Rule 應該是:

text
優先使用 Astro Component。

只有當 Component 需要 Client-side JavaScript
或真正的使用者互動時,才使用 Vue 3。

禁止為了方便、元件重用或預期未來需求,
將純展示型 Astro Component 改成 Vue。

這種 Rule 對 AI 的約束,往往比多裝幾個 MCP 更重要。


八、Vue 3 AI Skills

Astro 不是唯一需要 Context 的部分。

如果專案使用 Vue 3,那 AI 同樣需要知道:

  • Vue 3 Composition API
  • <script setup>
  • Reactivity
  • Props / Emits
  • Composables
  • Component Design
  • State Management
  • Vue Router
  • Pinia
  • TypeScript

因此可以進一步加入 Vue AI Skills。

它的定位比較接近:

讓 AI 更熟悉 Vue 3 的開發方式與最佳實務。

形成:

text
Astro Docs MCP
        +
Vue AI Skills
        ↓
Astro + Vue 3 Knowledge

九、MCP 與 Skills 其實解決不同問題

這兩個概念很容易混在一起。

可以簡單理解:

MCP

「AI 可以取得什麼資訊?」

text
Astro Docs MCP
    ↓
取得官方文件

Skills

「AI 遇到某種工作時應該怎麼做?」

text
Vue Component Skill
    ↓
如何建立一個符合 Vue 3 最佳實務的 Component

因此:

text
MCP → Knowledge
Skills → Workflow / Expertise

兩者搭配使用,比單獨使用其中一個更有價值。


十、再加入 Browser / DevTools Context

如果只讓 AI 看 Source Code,還是有一個問題:

AI 不知道瀏覽器裡實際發生什麼事。

例如 Source Code 看起來完全正常,但實際執行卻出現 Console Error、Network Error、Hydration Error 或 Component State Error。

這時候如果 AI 能取得 Browser Context,就可以從「猜問題」變成「看問題」。

text
TRAE
 │
 ├── Project Files
 │
 ├── Astro Docs MCP
 │
 ├── Vue Skills
 │
 └── Browser / DevTools
          │
          ├── Console
          ├── Network
          ├── DOM
          └── Runtime State

這才是真正接近「AI Debugging」。


十一、完整的 Astro + Vue 3 AI 架構

把所有東西整合起來:

text
TRAE
                           │
                     AI Coding Agent
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
   Astro Docs MCP      Vue Skills      Project Rules
          │                │                │
          ↓                ↓                ↓
    Astro Knowledge   Vue Knowledge    Project Knowledge
          │                │                │
          └────────────────┼────────────────┘
                           ↓
                    Browser / DevTools
                           │
                           ↓
                     Runtime Context
                           │
                           ↓
                    Astro + Vue 3

這時候 AI 得到的不是單一資訊,而是四種 Context:

  1. Framework Context
  2. Vue Context
  3. Project Context
  4. Runtime Context

這才是真正成熟的 AI Coding Environment。


十二、Astro + Vue 3 + Laravel

如果你的完整架構是 Laravel + Astro + Vue 3,那麼 AI 開發環境可以進一步變成:

text
TRAE
                         │
           ┌─────────────┼─────────────┐
           ↓             ↓             ↓
    Laravel Boost    Astro MCP    Vue Skills
           │             │             │
           ↓             ↓             ↓
      Laravel Context Astro Context Vue Context
           │             │             │
           └─────────────┼─────────────┘
                         ↓
                  Project Rules
                         ↓
                  Browser Context
                         ↓
                  整個 Fullstack

這個架構就非常有意思。

因為 AI 不再只懂 Laravel 或 Vue,而是開始理解:

text
Backend
   ↕
API
   ↕
Astro
   ↕
Vue

整個系統。


十三、AI Coding Workflow 應該怎麼改?

傳統方式:

text
需求 → AI → Code

我會建議改成:

text
需求
 ↓
Inspect
 ↓
Project Rules
 ↓
Framework Docs
 ↓
分析現有架構
 ↓
Plan
 ↓
Code
 ↓
Build
 ↓
Browser Test
 ↓
Verify

也就是:

Think → Inspect → Plan → Implement → Verify

而不是:

Prompt → Generate


十四、不要讓 AI 一開始就修改 Code

例如你要求:

「把商品篩選功能改成 Vue 3。」

比較好的 Agent Workflow:

  1. 確認目前 Product Filter 是 Astro 還是 Vue
  2. 確認目前資料來源
  3. 確認 API Client
  4. 確認 State Management
  5. 確認 Astro / Vue Component 邊界
  6. 查詢目前 Vue 3 / Astro 官方文件
  7. 提出修改方案
  8. 只修改必要檔案
  9. 執行 Build
  10. 使用 Browser 驗證

這樣 AI 才比較像 Junior Engineer,而不是 Code Generator。


十五、Project Rules 最值得規定的事情

如果我要建立一個 Astro + Vue 3 專案的 AI Rules,我會優先規定以下內容:

  1. Astro / Vue 邊界
    預設使用 Astro Component。只有需要 Client-side Interaction 時才使用 Vue。
  2. API
    優先使用既有 API Client。禁止在 Component 中自行建立新的 API abstraction。
  3. State
    先檢查既有 State Management。禁止建立重複的 global state。
  4. Component
    修改前先搜尋是否已有相同功能的 Component。禁止建立重複 Component。
  5. TypeScript
    優先使用現有 Type / Interface。禁止為相同資料建立第二套 Type。
  6. Styling
    優先使用現有 CSS / Utility / Design System。
  7. Performance
    避免不必要的 client-side JavaScript。避免將純展示 Component Vue 化。

這些規則會直接影響 AI 最終產生的 Code 品質。


十六、AI 的真正問題不是能力,而是 Context

這是整篇文章最核心的觀念。

很多人使用 AI Coding 時會想:

「我要怎麼讓 AI 寫得更好?」

但更值得問的是:

「我要怎麼讓 AI 在寫之前知道更多正確資訊?」

text
AI
│
├── Framework Docs
│
├── Project Rules
│
├── Existing Code
│
├── Runtime State
│
└── Tests
        │
        ↓
   Correct Context
        │
        ↓
   Better Decision
        │
        ↓
   Better Code

所以 AI Coding 的品質,很大程度上取決於 Context Quality,而不是單純 Model Size。


十七、Astro + Vue 3 的 AI 開發標準

如果今天我要建立一個新的 Astro + Vue 3 專案,我會把 AI 開發環境標準化成:

text
Astro + Vue 3 AI Development Standard

必備
────────────────────
✓ Astro Docs MCP
✓ Project Rules
✓ TypeScript
✓ Git
✓ Build Verification

建議
────────────────────
✓ Astro Agent Skills
✓ Vue AI Skills
✓ Browser / Playwright
✓ Vue DevTools Context

Fullstack
────────────────────
✓ Laravel Boost
✓ Laravel Documentation Context
✓ API Context

而不是「裝很多 MCP,希望 AI 變聰明」。

真正有效的方式是:

text
正確 Context
      ↓
正確 Rules
      ↓
正確 Tools
      ↓
AI 分析
      ↓
AI 實作
      ↓
自動驗證

十八、Astro + Vue 3 與 Laravel Boost 的差異

Laravel Boost 的核心概念是:

text
Laravel Project
      ↓
Laravel Boost
      ↓
AI

Astro + Vue 3 目前比較接近:

text
Astro Project
      │
      ├── Astro Docs MCP
      ├── Astro Skills
      ├── Vue Skills
      └── Project Rules
             ↓
            AI

也就是:

  • Laravel 生態比較集中在 Boost
  • Astro + Vue 3 目前則是由多個官方與 AI 工具能力組合成完整的 AI Development Stack

因此不要期待一定要找到一個「Astro Boost」才能完成同樣的事情。真正重要的是把這些能力組合起來。


十九、最終架構

最後,我認為一個成熟的 Astro + Vue 3 AI 專案,可以整理成:

text
AI Agent
                            │
                         TRAE
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
       ↓                    ↓                    ↓
 Framework Context    Project Context     Runtime Context
       │                    │                    │
       ↓                    ↓                    ↓
 Astro Docs MCP       Project Rules       Browser / DevTools
       │                    │                    │
       ↓                    ↓                    ↓
 Astro Knowledge      Project Standards    Actual Behavior
       │                    │                    │
       └────────────────────┼────────────────────┘
                            │
                            ↓
                       Vue 3 Skills
                            │
                            ↓
                    Astro + Vue 3 Project
                            │
                            ↓
                     Build / Test / Verify

這時候 AI 才真正從「幫我寫程式」進化成「理解我的專案後,幫我完成工程工作」。


結語:AI Coding 的下一步,是 Context Engineering

Astro + Vue 3 的 AI 開發,真正值得關注的不是「哪一個 AI Model 最強」,也不是「我要裝多少 MCP」,而是:

「我要提供多少正確 Context 給 AI?」

  • Astro Docs MCP 解決:AI 是否知道最新 Astro?
  • Vue Skills 解決:AI 是否知道正確的 Vue 3 開發方式?
  • Project Rules 解決:AI 是否知道這個專案怎麼開發?
  • Browser / DevTools 解決:AI 是否知道程式實際執行的狀況?

最後再透過 Build、Test、Verify 確認 AI 的修改真的正確。

因此,一個成熟的 Astro + Vue 3 AI Development Workflow 應該是:

text
Context First
                     ↓
              Think Before Code
                     ↓
                  Inspect
                     ↓
                   Plan
                     ↓
                 Implement
                     ↓
                  Verify

而不是:

text
Prompt → Generate → Hope

AI Coding 真正的下一個階段,不是讓 AI 寫更多 Code,而是讓 AI 在寫 Code 之前,先理解你的 Framework、你的專案、你的架構,以及你的規則。

這才是 Astro + Vue 3 AI Development 真正值得投入的方向。

Laravel Boost:從 Code Generator 進化成真正理解專案的 AI Agent

Laravel Boost 與 Laravel MCP 技術分享
讓 AI 真正進入你的 Laravel 專案,而不是只會猜

以前使用 AI 寫 Laravel,我最常遇到的問題不是 AI 不會寫 PHP,而是:

AI 根本不知道我的專案。

它不知道 Laravel 版本、不知道目前用了哪些套件、不知道資料庫 Schema、不知道既有的架構規則,也不知道某個問題其實已經有現成的 Service、Policy 或 Helper。

於是很容易出現這種情況:

AI:建議新增一個 Service。
實際上:專案裡已經有同功能的 Service。

或者:

AI:這是 Filament 3 的寫法。
實際上:專案使用的是 Filament 4。

甚至:

AI:新增一個 Permission。
實際上:專案早就有完整的 Gate + Policy + Shield + 自訂權限 Resolver。

這也是我開始關注 Laravel Boost 的原因。

Laravel Boost 是 Laravel 官方團隊提供的 AI 開發工具,核心目的就是讓 AI Coding Agent 取得 Laravel 專案真正需要的 Context、Tools、Guidelines 與 Skills。官方目前將它定位為:

Laravel-focused MCP server for augmenting your AI powered local development experience.


一、Laravel Boost 到底是什麼?

如果要用一句話解釋:

Laravel Boost 就是 Laravel 與 AI Coding Agent 之間的一座橋。

傳統 AI Coding 大概是:

text
開發者
   ↓
AI
   ↓
看你提供的程式碼
   ↓
猜測專案架構
   ↓
產生程式碼

加入 Laravel Boost 之後:

text
AI Coding Agent
                       │
                 Laravel Boost
                       │
        ┌──────────────┼──────────────┐
        ↓              ↓              ↓
     MCP Tools      Guidelines      Skills
        │              │              │
        └──────────────┼──────────────┘
                       ↓
                Laravel Application
                       │
          ┌────────────┼────────────┐
          ↓            ↓            ↓
        Code         MySQL        Logs

AI 不再只能依賴模型記憶,它可以透過 Boost:

  • 了解 Laravel / PHP 版本
  • 了解安裝了哪些 Laravel 生態套件
  • 查看 Eloquent Models
  • 查看 Database Schema
  • 執行 Database Query
  • 查看 Laravel Log
  • 查看 Browser Logs
  • 取得最後一次錯誤
  • 搜尋 Laravel / 套件官方文件

目前官方列出的 Boost MCP 工具包含 Application Info、Database Schema、Database Query、Browser Logs、Last Error、Read Log Entries、Search Docs 等。

這個差異非常大。


二、Laravel Boost 和 Laravel MCP 不一樣

這也是我覺得最容易搞混的地方。

Laravel 現在有兩個相關套件:

  • laravel/mcp
  • laravel/boost

但用途完全不同。

Laravel MCP
主要是讓你建立自己的 MCP Server

text
你的 Laravel Application
        ↓
自訂 MCP Server
        ↓
AI / 外部系統

你可以自己設計 Tool、Resource、Prompt,把業務能力暴露給任何 MCP Client。

Laravel Boost
則是讓 AI Coding Agent 更了解你的 Laravel 專案

text
TRAE / Cursor / Claude Code
            ↓
       Laravel Boost
            ↓
     你的 Laravel 專案

所以如果你的目的只是:

「我要讓 TRAE / Cursor 更懂我的 Laravel 專案,幫我寫得更準。」

那麼你真正需要研究的是 Laravel Boost

而 Laravel Boost 本身就是建立在 Laravel MCP 之上的——它提供的那些開發工具,全部都是 MCP Tools。


三、安裝 Laravel Boost

安裝非常簡單:

Bash
composer require laravel/boost --dev
php artisan boost:install

Boost 會偵測你的開發環境與 AI Agent,並產生對應的 MCP、Guidelines、Skills 等資源。

安裝之後,你會開始看到類似:

  • .mcp.json
  • .ai/
  • 不同 Agent 所需要的設定檔

這些東西的目的不是取代你的 Laravel 程式碼,而是:

把你的 Laravel 專案變成 AI 更容易理解的開發環境。

核心啟動指令:

Bash
php artisan boost:mcp

如果 IDE 需要手動註冊 MCP,官方提供的設定方式是:

JSON
{
    "mcpServers": {
        "laravel-boost": {
            "command": "php",
            "args": ["artisan", "boost:mcp"]
        }
    }
}

四、Boost 最重要的 MCP Tools

1. Application Info

AI 先了解你的環境。

假設專案是 PHP 8.2 + Laravel 11 + Filament 4 + Livewire + Spatie Media Library。
Boost 可以直接提供這些資訊,AI 不用再靠猜。

2. Database Schema

這個對企業 Laravel 專案非常重要。

很多 Bug 根本不是 PHP 語法問題,而是 Model ≠ Database。
AI 可以直接確認 table、column、type、relationship,再開始改 Code。

3. Database Query

AI 可以直接驗證資料。

以前要手動開 Tinker 查詢再貼給 AI,現在 Agent 可以自己查,工作流程變成真正的 Debugging。

4. Logs(Last Error、Read Log Entries、Browser Logs)

這是我認為 Boost 最實用的功能之一。

從「請貼錯誤訊息」變成 AI 自己去看 Log,Debug 效率明顯提升。

5. Search Docs

避免 AI 使用錯版本 API。

Boost 的 Documentation API 有超過 17,000 筆 Laravel 生態系資訊,並根據專案實際安裝的套件版本提供對應文件(支援 Laravel 10~13、Filament 2~5、Livewire 1~4 等)。


五、Boost 不只是 MCP

如果只把 Laravel Boost 理解成「一個 Laravel MCP Server」,其實低估它了。

Boost 現在還提供:

  • Guidelines:AI 啟動時就應該知道的通用規則(Laravel、Livewire、Pest、Tailwind 等)
  • Skills:需要時才載入的專業知識(例如 Livewire Development、Pest Testing)
  • Project Rules:真正適合企業專案的關鍵

Guidelines 是廣泛、基礎的規範;Skills 則是針對特定工作領域、需要時才啟用。

Project Rules 才是教 AI「你的公司系統怎麼寫」的地方。

例如:

  • 所有 Permission 使用既有命名規則
  • 不要自行新增 Repository
  • 修改權限之前必須檢查 Policy / Gate / Shield / Permission Resolver
  • 優先使用既有 Service
  • 不要重複建立 Helper
  • 修改資料庫之前必須先確認 migration

Boost 使用 .ai/rules/ 與 index.md,透過 glob 對應檔案範圍,讓 Agent 只讀取相關規則,而不是一次塞全部 Context。

甚至可以直接跟 Agent 說「記住:所有金額都使用 integer cents 儲存」,Boost 會透過 record-rule 工具把規則寫入 Project Rules。


六、對我來說,Boost 最大的價值

很多人看到 AI Coding 工具,第一個想法是「可以幫我寫 Code,所以會變快」。

但實際上,我認為更大的提升是:

減少 AI 與開發者之間反覆傳遞 Context 的時間。

沒有 Boost:

text
你:這是 Model。
AI:請給 migration。
你:這是 migration。
AI:請給 Service。
你:這是 Service。
AI:請給錯誤 Log。
你:這是 Log。

有 Boost:

text
你:找出這個問題並修正。
AI → Application Info → Database Schema → Code → Logs → Documentation → 修改

真正被加速的其實是 Context Gathering


七、我自己的 AI 開發流程

如果是 Laravel 專案,我會要求 AI 遵循:

text
Think → Inspect → Understand → Plan → Modify → Verify

而不是:

text
Prompt → Generate Code

具體流程:

  1. 先理解需求
  2. 查看現有實作
  3. 查看 Database Schema
  4. 查看相關 Permission / Policy
  5. 查官方文件
  6. 提出最小修改方案
  7. 修改
  8. 查看 Log / Error
  9. 測試
  10. 檢查 Git Diff

Laravel Boost 剛好可以把其中很多 Context Gathering 的工作交給 Agent。


八、安全性提醒

Boost 能讓 AI 查 Database、執行 Query、讀 Logs,這不代表應該讓 AI 在 Production 隨便操作。

我會建議:

  • Development → 完整 Boost
  • Production → 嚴格限制

尤其是 UPDATE、DELETE、敏感資料、Payment、Authentication 都應該非常謹慎。

AI 工具越強,權限控管反而越重要。

另外,Boost 不是取代你的架構。我會在 Project Rules 明確寫:

  • 不要過度設計
  • 優先使用既有架構
  • 修改前先搜尋現有實作
  • 如果已有相同功能,禁止重新建立
  • 只修改完成需求所必要的檔案
  • 不要進行與需求無關的重構

九、結語:AI Coding 的下一步不是更大的模型,而是更好的 Context

使用 AI 一段時間後,我越來越覺得:

AI Coding 的瓶頸不一定是模型能力,而是 Context。

模型再強,如果它不知道你的 Laravel 版本、資料庫、套件、架構、權限、Log、Coding Convention,它還是可能寫出一段「看起來正確,但不適合你的專案」的 Code。

Laravel Boost 解決的,正是這個問題。

它把 Laravel + MCP + Documentation + Guidelines + Skills + Project Rules 組合起來,最後形成:

text
AI Agent
                       │
                  Laravel Boost
                       │
       ┌───────────────┼────────────────┐
       ↓               ↓                ↓
      MCP         Guidelines          Skills
       │               │                │
       └───────────────┼────────────────┘
                       ↓
                Laravel Application
                       │
        ┌──────────────┼───────────────┐
        ↓              ↓               ↓
      Code           Database         Logs

對我來說,Laravel Boost 最有價值的地方不是「讓 AI 幫我多寫幾行 Code」,而是:

讓 AI 從一個只會產生程式碼的工具,變成真正可以在 Laravel 專案裡工作的開發 Agent。

而這也讓 AI 開發的思維開始從:

text
Prompt → Code

慢慢變成:

text
Context → Understand → Plan → Code → Verify

這才是我認為 Laravel Boost 真正值得導入 Laravel 專案的原因。

2026年9月3日 星期四

AI-First Coding:如何讓 AI 更有效率地幫你寫 Code

 AI-First Coding:如何讓 AI 更有效率地幫你寫 Code

現在的軟體開發方式正在發生根本性的轉變。

以前我們思考的核心問題是:

「怎麼把程式碼寫得最漂亮、最容易讓人維護?」

但如果現在主要由 AI 協助,甚至直接產生 Code,問題應該改成:

「怎麼讓 AI 下一次修改這份 Code 時,需要理解的 Context 最少?」

這兩件事情並不完全相同。

對 AI Coding 而言,真正昂貴的不是 Code 行數,而是:

  • AI 需要讀多少 Code
  • AI 需要理解多少關聯
  • AI 需要跨多少檔案
  • AI 需要猜多少隱藏規則
  • 修改後需要重新測試多少功能
  • 一次修改產生多少 Diff

因此,AI-first 的程式設計原則應該從「程式碼漂亮」轉向:Low Context、Low Coupling、Small Diff、Small Regression Scope


一、AI Coding 最重要的不是「少寫 Code」,而是「少讀 Code」

人類工程師可以花半小時閱讀一個專案。
AI 則會受到 Context Window、Token 成本以及推理成本的影響。

舉例來說:

需求:修改 Landing Page 的 B12 流程步驟

做法 A(傳統寫法):

text
LandingPageSchema.php
    B02
    B03
    B04
    B06
    B07
    B08
    B09
    B10
    B11
    B12
    B13
    B14
    B15
    B16

AI 必須先理解大量無關的 Block。

更好的架構是讓 AI 可以快速定位:

text
B12 → b12Steps()

然後只理解:

PHP
protected static function b12Steps(): Block
{
    ...
}

這就是 AI-first 的核心:

不是讓 Code 最小,而是讓 AI 每次修改時需要理解的 Context 最小。


二、不要過度拆檔案

傳統工程習慣很容易變成:

text
LandingPage/
├── B02.php
├── B03.php
├── B04.php
├── B06.php
├── B07.php
├── B08.php
├── B09.php
├── B10.php
├── B11.php
├── B12.php
├── B13.php
├── B14.php
├── B15.php
└── B16.php

看起來很乾淨,但 AI 修改 B12 時可能需要:

找到 B12 → 找到 Registry → 找到引用 → 找到 Base Schema → 找到 Helper → 找到相關設定

Context 反而增加。

因此:不要為了「檔案看起來乾淨」而拆檔。

比較適合 AI 的方式通常是:

text
LandingPageSchema.php
├── Registry
├── B02
├── B03
├── B04
├── B06
├── ...
├── B16
└── Helpers

這種「單檔、功能區塊化」有一個很大的優點:
AI 可以透過命名快速定位功能,同時避免跨檔案理解。


三、功能邊界比檔案數量更重要

AI-first 架構不是「全部塞在一個檔案」。

真正的原則是:一個功能應該有清楚的邏輯邊界。

例如:

PHP
protected static function b12Steps(): Block

就是非常好的 AI 定位點。

AI 收到:

B12 的步驟標題限制改成 12 字。

可以直接定位:

text
b12Steps() → 步驟標題 → maxLength()

而不是重新理解整個 CMS Builder。

因此,命名本身就是 AI 的 Navigation System


四、不要讓 AI 猜架構

AI 最容易出錯的情況不是 Code 寫錯,而是它不知道你的專案規則。

例如你的專案可能有:

  • SharedFields
  • BlockRegistry
  • BaseModel
  • HasTranslatable
  • Permission Convention
  • API Transformer
  • Cache Convention

如果沒有規則,AI 很容易自己發明:

NewHelper、NewService、NewTrait、NewRepository、NewBaseClass

最後變成:

原本 1 個檔案 → AI 新增 5 個檔案 → 跨檔案依賴增加 → Token 增加 → 維護成本增加

所以 AI Coding 必須有一個非常重要的規則:

Reuse Before Create

先搜尋現有:

Helper、Service、Trait、SharedField、Component、Repository、Enum、Transformer

確認不存在之後,才允許新增。


五、AI 修改 Code 時,Diff 必須最小化

這是 AI Coding 最重要的規則之一。

不要要求 AI:

「順便幫我重構這個檔案。」

除非你真的要重構。

應該要求:

「只修改造成這個問題所必要的程式碼,不要進行其他重構。」

因為 AI 很容易做:

需求:修改 B12 標題長度

AI 實際行為:

  • 重構 B12
  • 抽出 Helper
  • 修改命名
  • 整理 imports
  • 調整其他 Block
  • 順便最佳化 Registry

最後你得到的不是 +1 行,而是 +80 / -120。

這會直接增加 Review 成本、Token 成本、Bug 風險、Regression Scope。

因此應該建立:Minimal Diff Principle


六、不要為了 AI 未來好維護,現在就做大重構

這是非常重要的原則。

例如目前 B02~B16 已經功能正常、測試完成、Production 穩定。

這時候發現:

「如果拆成多個檔案,AI 以後可能比較好維護。」

不代表現在就應該重構。

因為:重構 → 整體重新測試 → 增加 Regression Risk → 增加開發時間

如果沒有實際需求,收益可能非常低。

更好的方式是:

現在維持現狀 → 下一次修改 B12 時順手改善 B12 → 只測 B12

這叫 Incremental Refactoring,而不是一次性大重構。


七、把「修改範圍」直接告訴 AI

一個好的 AI Prompt 不應該只有:

「幫我修 B12。」

應該明確指定:

text
修改範圍:
- 僅修改 LandingPageSchema::b12Steps()
- 不修改其他 Block
- 不新增檔案
- 不新增 Helper
- 不修改 SharedFields
- 不修改資料庫
- 不修改 API
- 不修改既有資料結構

這會大幅降低 AI 的探索範圍。


八、推薦使用「Think → Locate → Modify → Verify」

不要叫 AI 一開始就寫 Code。

推薦固定使用:

  1. Think
  2. Locate
  3. Modify
  4. Verify

Prompt 範例:

text
在修改 Code 前,先執行以下流程:

1. 分析需求的真正原因,不要立即修改。
2. 找出實際負責此功能的 Entry Point。
3. 找出最小必要修改範圍。
4. 優先使用現有的 Helper、Service、Component 與 Convention。
5. 不要建立新的抽象,除非現有架構無法合理支援。
6. 不要修改需求範圍以外的 Code。
7. 不要順便重構、重新命名或格式化無關程式碼。

修改完成後說明:
- 修改了哪個檔案
- 修改了哪個方法
- 為什麼需要修改
- 是否影響其他功能
- 建議測試範圍

核心原則:Small Context → Small Diff → Small Test Scope


九、讓 AI 優先搜尋,而不是閱讀整個專案

AI 最有效率的流程不是:

讀整個專案 → 理解全部架構 → 開始修改

而是:

需求 → 搜尋關鍵字 → 找到 Entry Point → 讀附近 Code → 追必要 Dependency → 修改

例如修改 B12:

先搜尋 b12Steps,再搜尋 steps,最後只讀 LandingPageSchema 與 SharedFields 真正需要的部分。

因此你的 Prompt 可以要求:

text
請採用「由需求反向定位」的方式處理:

1. 先搜尋與需求直接相關的 Class / Method / Field。
2. 找到 Entry Point 後,只追蹤完成需求所必要的 Dependency。
3. 不要為了理解整個專案而讀取無關檔案。
4. 優先使用現有架構。
5. 找不到必要資訊時再擴大搜尋範圍。

目標不是理解整個專案,而是以最小 Context 完成正確修改。

十、Prompt 最重要的不是「告訴 AI 怎麼寫」,而是「告訴 AI 不要做什麼」

這是一個非常重要的觀念。

一般 Prompt:

幫我修改 B12。

AI 有非常大的自由度。

好的 Prompt:

text
只修改 B12。

禁止:
- 修改其他 Block
- 新增檔案
- 新增 Service
- 新增 Helper
- 修改 DB
- 修改 API
- 重構現有 Code
- 修改命名
- 修改無關格式

這叫 Negative Constraints

在 AI Coding 裡面,限制條件往往比需求描述更重要。


十一、建立「AI Coding Contract」

可以把整個專案的規則濃縮成一份 AI-CODING-RULES.md:

Markdown
# AI Coding Rules

## 1. Core Principle
Think Before Code.  
目標不是產生最多 Code,而是以最小 Context、最小 Diff 完成需求。

## 2. Locate Before Modify
修改前必須先找到:
- Entry Point
- 實際負責功能的 Method
- 必要 Dependency
- 現有可重用元件

禁止未定位就直接修改。

## 3. Reuse Before Create
優先使用:
- Existing Helper
- Existing Service
- Existing Trait
- Existing Component
- Existing Convention

除非現有架構無法合理支援,否則不要新增抽象。

## 4. Minimal Diff
只修改完成需求所必要的 Code。

禁止:
- 順便重構
- 順便重新命名
- 順便格式化
- 修改無關功能
- 修改其他 Module

## 5. Minimal Context
不要閱讀整個專案。  
採用:Search → Locate → Read Relevant Context → Modify  
只有必要時才擴大 Context。

## 6. File Structure
不要為了理論上的 Clean Architecture 過度拆檔。  
優先考慮:Feature Boundary > File Count  
功能相關的 Schema、Helper 可以在同一個檔案內保持集中。

## 7. No Speculative Architecture
禁止因為「未來可能需要」而新增:
Service、Repository、Trait、Interface、Abstract Class、Helper  
除非目前需求已經證明需要。

## 8. Regression Scope
每次修改都應該盡可能縮小測試範圍。  
修改單一 Block → 優先測試該 Block。  
修改 SharedFields → 才需要測試所有使用該 SharedFields 的功能。

## 9. Refactoring Policy
不要因為 Code 不夠漂亮就主動重構。  
只有以下情況才進行重構:
- 已經影響目前需求
- 已經造成重複問題
- 已經造成維護問題
- 使用者明確要求重構

## 10. Final Response
完成修改後,只需要回答:
- 修改檔案
- 修改位置
- 修改原因
- 影響範圍
- 測試建議

不要描述與本次需求無關的架構。

十二、真正有效率的 AI Coding Prompt

最後,可以把日常開發 Prompt 簡化成這個:

text
AI Coding Task

Goal
[描述我要完成什麼]

Scope
只允許修改:
- [檔案 / Class / Method]

Constraints
- 不修改需求範圍以外的 Code
- 不新增檔案,除非確實必要
- 優先使用現有 Helper / Service / Component
- 不進行額外重構
- 不重新命名無關 Code
- 不修改 DB / API / Architecture,除非需求明確要求

Process
1. 先分析 Root Cause。
2. 找出 Entry Point。
3. 找出最小修改範圍。
4. 確認是否存在可重用的既有實作。
5. 執行最小修改。
6. 檢查是否產生不必要 Diff。
7. 說明需要測試的最小範圍。

Output
完成後只回報:
- Root Cause
- Modified Files
- Modified Methods
- What Changed
- Test Scope

核心原則:Do not optimize the architecture. Optimize the change.


十三、AI-first 的真正目標

最後可以把整套方法濃縮成一個公式:

AI 開發效率 = 正確率 × Context 效率 × 修改精準度 × 測試範圍控制

而不是:

AI 開發效率 = Code 寫得多快

所以你真正應該追求的是:

需求 → 最小 Context → 最小理解範圍 → 最小 Diff → 最小 Regression Scope

這也是為什麼有時候:

一個 800 行、但功能邊界清楚的檔案,可能比 15 個 50 行的小檔案更適合 AI 維護。

因為 AI 不需要一直跳來跳去。


結論

如果未來幾乎全部 Code 都由 AI 協助完成,那麼我們其實正在從:

Human-readable Architecture

逐漸轉向:

AI-navigable Architecture

好的 AI Code 不一定是最符合傳統 Clean Architecture 的 Code。

而是:

AI 能快速找到、快速理解、快速修改,而且每次修改只影響最小範圍的 Code。

因此真正值得建立的不是「讓 AI 寫更多 Code 的 Prompt」,而是:

讓 AI 少讀 Code、少猜東西、少改 Code、少產生 Diff、少需要重新測試。

這才是 AI-first Software Development。

2026年9月1日 星期二

AI-Assisted Software Engineering 從 SDD、AI Workflow 到 Architecture Governance

 

AI-Assisted Software Engineering

從 SDD、AI Workflow 到 Architecture Governance

AI 負責速度,工程師負責方向;Spec 負責約束,Architecture 負責品質。


一、背景:AI Coding 解決了什麼,又帶來了什麼問題?

生成式 AI 出現之後,軟體開發效率有了非常明顯的提升。

現在透過 AI,可以快速完成:

  • Controller

  • Service

  • Model

  • Migration

  • API

  • Vue Component

  • Filament Resource

  • Validation

  • Test

  • Refactoring

  • Debugging

以前可能需要幾個小時完成的工作,現在幾十分鐘甚至幾分鐘就能完成。

但當 AI 開始大量參與實際專案開發後,我發現一個很重要的問題:

AI 最大的風險不是寫不出 Code,而是寫太多「看起來合理」的 Code。

例如:

  • 已經存在的 Service,AI 又建立一個新的

  • 原本應該放在 Service 的邏輯被塞進 Controller

  • 為了修一個問題順便重構整個模組

  • 新增一套與既有 API 不一致的 Response Format

  • 修改功能時忽略 Permission

  • 為了符合 AI 自己熟悉的 Pattern,改變原本專案架構

  • 解決 A 問題後,引入 B、C、D 問題

  • 每次修改都合理,但長期造成 Architecture Fragmentation

所以我開始重新思考:

如果 AI 已經可以高速產生 Code,那工程師真正需要控制的是什麼?

我的答案是:

Specification、Workflow、Architecture。

因此,我逐漸建立了一套自己的 AI 輔助軟體工程流程:

                    AI-Assisted
                 Software Engineering
                         │
        ┌────────────────┼────────────────┐
        ↓                ↓                ↓
       SDD          AI Workflow     Architecture
        │                │                │
     定義問題          約束 AI           驗證結果
        │                │                │
        └────────────────┼────────────────┘
                         ↓
                  Controlled AI
                   Development

二、核心理念:我不把 AI 當 Senior Developer

我的 AI 開發方式有一個非常明確的定位:

我把 AI 當成一個速度非常快的 Junior Engineer。

AI 可以負責:

  • 搜尋

  • 分析

  • 撰寫 Code

  • Debug

  • Refactoring

  • Test

  • 文件整理

但不應該自行決定:

  • 核心 Architecture

  • Business Rule

  • Database Model

  • 大型 Refactoring

  • 技術選型

  • 需求邊界

原因很簡單。

AI 很擅長回答:

「這段 Code 怎麼寫?」

但工程師真正需要回答的是:

「這段 Code 應該放在哪裡?」

以及:

「我們真的需要這段 Code 嗎?」

這兩個問題,本質上是不同的。


三、SDD:Spec Before Code

我將第一個核心概念定義為:

Spec Before Code

也就是在讓 AI 修改 Code 之前,先把問題定義清楚。

傳統 AI Coding 通常是:

需求
 ↓
Prompt
 ↓
AI 寫 Code
 ↓
發現問題
 ↓
再叫 AI 修改
 ↓
繼續累積修改

而我的流程是:

需求
 ↓
Specification
 ↓
Existing Architecture Analysis
 ↓
Call Chain
 ↓
Data Flow
 ↓
Constraints
 ↓
Implementation Plan
 ↓
Implementation
 ↓
Verification

四、我的 SDD Template

我會讓 Specification 至少包含以下區塊。

1. Goal

這次需求真正要解決什麼問題?

不是只描述「我要新增一個功能」,而是要說明:

為什麼需要這個功能?


2. Scope

明確定義這次修改的範圍。

例如:

  • Backend

  • API

  • Database

  • Frontend

  • Permission

  • Cache

  • Queue

同時標示哪些模組受到影響。


3. Non-goals

這是我認為非常重要、而且很容易被忽略的一部分。

除了告訴 AI:

「這次要做什麼。」

也必須告訴 AI:

「這次不要做什麼。」

例如:

## Non-goals

本次需求不包含:

- 不重構現有 Service 架構
- 不修改既有 API Response Format
- 不新增 Repository Layer
- 不修改既有 Permission Naming
- 不處理無關的 Technical Debt
- 不進行 Frontend Component 重構
- 不修改其他既有模組

這可以有效降低 AI 的過度設計。

因為 AI 很容易看到一個問題後順手說:

「既然這裡可以改善,我一起重構。」

但在實際專案中:

「可以改善」不代表「現在應該改善」。


五、Existing Architecture:先理解,再修改

AI 最常見的問題之一,是直接假設架構。

例如:

「這個專案應該使用 Repository Pattern。」

然後 AI 開始新增:

Controller
 ↓
Service
 ↓
Repository
 ↓
Model

但實際專案可能根本沒有 Repository Layer。

這時候 AI 雖然寫出來的 Code 沒有錯,但它已經開始改變 Architecture。

所以我要求 AI:

先找現有架構,不要自己假設架構。

例如 Laravel 專案:

Route
 ↓
Controller
 ↓
Service
 ↓
Model
 ↓
Database

如果既有架構就是這樣,就優先延續既有模式。


六、Call Chain:不要猜,直接追

在大型專案中,我非常重視 Call Chain。

例如一個 API:

POST /api/quest/select
        ↓
QuestController
        ↓
checkEligibility()
        ↓
QuestService
        ↓
Business Rule
        ↓
Database

如果直接看到 Controller 就開始修改,很容易判斷錯誤。

因此我會要求 AI:

1. 找 Route
2. 找 Controller
3. 找實際呼叫的方法
4. 追 Service
5. 找 Model
6. 找 Database
7. 找相關 Permission
8. 找 Frontend 呼叫位置
9. 找 Test

先回答:

「這個功能實際上是怎麼運作的?」

再開始 Coding。


七、Data Flow:確認資料怎麼流動

除了 Call Chain,我也會確認 Data Flow。

例如:

Frontend
   ↓
Request
   ↓
Validation
   ↓
Controller
   ↓
Service
   ↓
Model
   ↓
Database
   ↓
Resource / Transformer
   ↓
API Response
   ↓
Frontend

這可以避免只修改 Backend,卻忘記:

  • API Response

  • Frontend Payload

  • Validation

  • Transformer

  • Database

  • Cache

等相關位置。

因此 SDD 不只是「需求文件」,它其實也是:

AI 修改系統前的 Context Boundary。


八、Constraints:告訴 AI 哪些事情不能做

AI 如果沒有約束,很容易產生過度設計。

所以我會明確設定:

Constraints

- 優先使用既有 Service
- 不建立重複功能
- 不進行無關重構
- 不修改既有 API Contract
- 不改變既有 Business Rule
- 保持既有 Permission Naming
- 修改範圍保持最小
- 如果現有架構不足,先提出方案,不直接重構

這裡的核心原則是:

AI 可以提出方案,但不能默認擴大 Scope。


九、AI Workflow:把開發流程標準化

建立 SDD 後,我再將 AI 的工作分成幾個階段。

Phase 1:Understand

AI 只負責理解。

Search
 ↓
Read
 ↓
Trace
 ↓
Understand

這個階段不修改 Code。


Phase 2:Analyze

分析:

Current Architecture
        ↓
Problem
        ↓
Root Cause
        ↓
Impact
        ↓
Possible Solutions

重點是找 Root Cause,而不是只處理表面症狀。


Phase 3:Propose

AI 提出方案。

例如:

Option A

修改既有 Service。

Option B

建立新的 Service。

Option C

重構整個模組。

然後由工程師判斷哪個方案適合目前 Architecture。


Phase 4:Implement

方案確認後,才讓 AI 實作。

此時 AI 就可以發揮最大的效率:

  • Generate Code

  • Generate Test

  • Modify Files

  • Refactor

  • Debug


Phase 5:Verify

完成後再次檢查:

Functional
 ↓
Regression
 ↓
API
 ↓
Database
 ↓
Permission
 ↓
Performance

最後才算完成。


十、最小修改原則

AI 開發中,我非常重視:

Minimal Change

例如今天只是修正一個 Business Rule。

理想情況:

Controller
 ↓
Existing Service
 ↓
修正 Business Rule

而不是:

Controller
 ↓
重構 Service
 ↓
新增 Repository
 ↓
修改 Model
 ↓
修改 API
 ↓
重寫 Frontend

即使後者「架構看起來更漂亮」,也不代表它是正確的工程決策。

因為每增加一個修改點,就增加一個 Regression Risk。

所以我的原則是:

先解決問題,再考慮重構。


十一、Architecture Check:AI 寫完不代表完成

我認為 AI Coding 最大的缺口之一,就是:

AI 可以確認 Code 能跑,但不一定能確認 Architecture 是否健康。

因此我會另外做 Architecture Check。


十二、Level 1:Daily Architecture Checklist

每次 AI Coding 完成後,可以快速檢查:

#Check問題
1Scope是否只修改需求必要範圍?
2Duplication是否新增了既有功能的第二套實作?
3ResponsibilityController / Service / Model 職責是否清楚?
4Call Chain是否確認實際呼叫鏈後才修改?
5Data FlowRequest → API → DB → Response 是否一致?
6Permission新功能是否同步檢查權限?
7Performance是否引入 N+1、重複 Query 或大量資料載入?
8Regression是否確認既有功能沒有受到影響?

這個 Checklist 的目的不是取代 Code Review。

而是建立一個最低限度的:

Architecture Quality Gate


十三、Level 2:Module Architecture Review

當修改的是重要模組,就不只做快速 Check。

會完整追:

API
 ↓
Controller
 ↓
Service
 ↓
Model
 ↓
Database

再確認:

Frontend
Permission
Cache
Queue
Test

例如一個新的 API,不只是確認 Controller 是否正確,而是確認:

Request
 ↓
Validation
 ↓
Business Logic
 ↓
Database
 ↓
Transformer
 ↓
Response
 ↓
Frontend

整條鏈是否一致。


十四、Level 3:Full Architecture Audit

大型專案或累積大量 AI 修改後,可以進行完整架構健檢。

我會將它分成:

                Architecture Audit
                       │
       ┌───────────────┼───────────────┐
       ↓               ↓               ↓
      API              DB              Auth
       │               │               │
       ↓               ↓               ↓
   Frontend       Performance       Permission
       │               │               │
       └───────────────┼───────────────┘
                       ↓
                 Technical Debt

最後不是單純列出「有問題」。

而是進一步分類:

Critical

可能影響資料正確性、安全性或核心功能。

High

可能造成重大維護成本或效能問題。

Medium

可以改善,但短期不一定需要處理。

Low

Code Quality 或未來可優化項目。

這可以避免 Architecture Review 最後變成:

「看到什麼就全部重構。」


十五、實際案例一:AI 建立重複 Service

Problem

需求是新增一個翻譯匯入功能。

AI 分析後提出:

建立新的 TranslationService

程式本身沒有明顯錯誤。

甚至測試也可以通過。

但進行 Architecture Check 後發現:

Existing TranslationService
        +
New TranslationService
        ↓
相同責任開始分散

問題不在 Code 能不能執行。

問題在:

系統開始出現兩個相同責任的入口。


修正

重新追蹤既有架構後,發現原本的 Translation Service 已經負責相關流程。

因此最後改成:

需求
 ↓
尋找 Existing Service
 ↓
確認既有責任
 ↓
擴充 Existing Service
 ↓
維持單一責任入口

這個案例讓我更加確定:

AI 產生的方案不一定是錯的,但不一定適合既有 Architecture。


十六、實際案例二:修問題前先追 Call Chain

另一類常見問題是:

表面看到的錯誤位置,不一定是真正的問題位置。

例如 API:

POST /api/xxx
 ↓
Controller
 ↓
checkEligibility()
 ↓
Service
 ↓
Business Rule

如果直接看到 Controller 就修改,很容易把 Business Logic 放到錯誤的位置。

因此我會先追完整 Call Chain。

最後可能發現:

Controller
    ↓
只負責 Request / Response

Service
    ↓
真正負責 Business Rule

所以正確的修改方式不是:

「Controller 有問題 → 修改 Controller」

而是:

「找到真正的責任邊界 → 在正確的 Layer 修改。」

這也是我在 AI Coding 中非常重視的觀念。


十七、這套流程帶來的改變

建立這套方法後,我認為 AI Coding 的工作模式產生了一個很大的變化。

以前:

工程師
 ↓
寫 Code

現在:

工程師
 ↓
定義問題
 ↓
定義 Architecture
 ↓
制定 Constraints
 ↓
指揮 AI
 ↓
Review
 ↓
Verification

工程師花在「手寫 Code」的比例下降。

但花在:

  • Requirement Analysis

  • Architecture

  • Debugging

  • Code Review

  • System Design

  • Quality Control

的比例反而提高。

我認為這並不是工程師價值下降。

反而是工程師的工作開始往更高層次移動。


十八、我對 AI Engineering 的理解

我認為 AI 時代的工程能力,可以分成三層。

第一層:AI Coding

知道怎麼讓 AI 寫 Code。

Prompt
 ↓
Code

這是最基本的能力。


第二層:AI-Assisted Development

知道怎麼把 AI 放進日常開發流程。

Requirement
 ↓
AI Analysis
 ↓
Implementation
 ↓
Test
 ↓
Review

效率會比單純 Coding 高很多。


第三層:AI Engineering

建立一套可以控制 AI 的工程方法。

Specification
       ↓
AI Workflow
       ↓
Implementation
       ↓
Verification
       ↓
Architecture Governance

這時候 AI 已經不是單純的 Coding Tool。

而是:

Software Engineering 的一部分。


十九、我的三層方法論

最後,我把整套方法濃縮成三個核心。

① SDD — Define

回答:

我們到底要做什麼?

透過:

  • Goal

  • Scope

  • Non-goals

  • Existing Architecture

  • Call Chain

  • Data Flow

  • Constraints

  • Acceptance Criteria

定義問題。


② AI Workflow — Control

回答:

AI 應該怎麼做?

透過:

Understand
 ↓
Analyze
 ↓
Propose
 ↓
Implement
 ↓
Verify

控制 AI 的行為。


③ Architecture Check — Govern

回答:

AI 做完之後,系統還健康嗎?

透過:

Daily Check
 ↓
Module Review
 ↓
Full Architecture Audit

持續控制 Architecture Quality。


二十、結語

我認為 AI Coding 真正帶來的改變,不是:

「工程師不用寫 Code 了。」

而是:

「工程師需要把更多注意力放在 Code 以外的工程問題。」

AI 可以讓 Code 產生速度提高十倍。

但如果沒有 Specification、Workflow 與 Architecture Governance,

那麼 Technical Debt 也可能累積得更快。

所以我現在對 AI 輔助開發的核心理念是:

Think Before Code.

Spec Before AI.

Minimal Change Before Refactoring.

Architecture Before Scale.

AI 負責速度。

SDD 負責方向。

Workflow 負責控制。

Architecture Check 負責品質。

而工程師真正的價值,是把這四件事情串起來,讓 AI 不只是「會寫 Code」,而是能夠在既有軟體工程規範下,持續產生正確、可維護、可演進的系統

2026年8月15日 星期六

AI Review Flow:當 AI 寫 Code 的速度超過人類 Review 的速度

 

AI Review Flow:當 AI 寫 Code 的速度超過人類 Review 的速度

不要讓 AI 只負責寫 Code,而是讓 AI 參與整個 Software Engineering 品質循環。

過去幾年,AI Coding 工具快速改變了軟體開發的方式。

以前,一個工程師可能需要花半天時間完成一個 CRUD 功能:建立 Migration、Model、Controller、Validation、API Resource,再補上 Admin 後台的 Form 與 Table。

現在,這些工作可能只需要幾分鐘。

AI 可以快速產生:

  • Migration
  • Model
  • Service
  • Controller
  • API Resource
  • Validation
  • Filament Resource
  • Form
  • Table
  • Test

甚至可以直接依照既有專案結構,模仿現有程式碼完成一整套功能。

這看起來是一件非常美好的事情。

但當程式碼產生速度提升之後,一個新的問題也開始浮現:

AI 產生程式碼的速度,已經遠遠超過人類逐行閱讀與驗證程式碼的速度。

於是,軟體開發真正的瓶頸開始從「Coding」轉移到另一件事情:

Verification

我們真正需要問的,已經不只是:

AI 能不能幫我寫 Code?

而是:

AI 寫完之後,我怎麼知道它寫對了?

這也是我認為 AI 時代非常重要的一個工程概念:

AI Review Flow


一、AI 最大的問題不是不會寫,而是太容易「寫得像對的」

很多人第一次使用 AI Coding 工具時,最容易被它的「完成度」驚艷。

你只要描述:

幫我新增一個 CMS Block。

AI 很快就可以產生一大堆程式碼。

Migration 有了。

Model 有了。

Enum 有了。

Filament Form 有了。

API Resource 有了。

Controller 也有了。

而且程式碼通常看起來非常合理。

這正是 AI 最危險的地方。

AI 最危險的錯誤,通常不是:

Parse error

這種錯誤很容易被發現。

真正危險的是:

程式碼完全合法,而且看起來非常漂亮,但商業邏輯是錯的。

例如:

if ($block->is_active) {
    return $block;
}

這段程式碼本身完全沒有問題。

但如果真正的商業規則是:

is_active = true
AND page.is_published = true
AND publish_at <= now()
AND expired_at > now()

那麼這段程式碼就是錯的。

問題不是 PHP。

不是 Laravel。

也不是 Coding Style。

而是:

AI 沒有完整理解 Specification。

所以 AI Code Review 最重要的事情,不應該只是檢查:

「這段 Code 寫得好不好?」

而應該檢查:

「這段 Code 是否真的符合規格?」

這兩件事情,看起來很接近,但其實完全不同。


二、AI Coding 時代,真正的瓶頸正在從 Coding 轉移到 Verification

傳統軟體開發流程通常是:

需求
 ↓
分析
 ↓
Coding
 ↓
Code Review
 ↓
Test
 ↓
Deploy

在這個流程裡,Coding 是很大的成本。

因此工程師會想辦法提高 Coding 效率。

例如:

  • IDE
  • Framework
  • Package
  • Code Generator
  • ORM
  • Admin Generator
  • AI Coding

但 AI 出現之後,Coding 的成本開始大幅下降。

原本需要兩個小時的 CRUD,可能變成十五分鐘。

原本需要一天的後台功能,可能幾個小時就完成。

問題是:

Review 沒有同步變快。

人類還是只有兩隻眼睛。

還是需要理解:

  • 這段程式在做什麼?
  • 為什麼這樣做?
  • 是否符合需求?
  • 有沒有漏掉條件?
  • 有沒有破壞既有功能?
  • 有沒有安全問題?
  • 有沒有資料一致性問題?

於是就產生了一個新的矛盾:

Code Generation
      ↑
      │
      │  AI:非常快
      │
      ↓
Verification
      │
      │  Human:有限速度
      ↓

如果我們只是一直提高 AI 的 Coding 能力,最後很可能會發現:

Code 寫得越快,Review 反而成為最大的瓶頸。

所以 AI 時代真正需要升級的,不只是 Coding。

而是整個 Review Flow。


三、完整的 AI Review Flow

一個比較完整的 AI Software Engineering 流程,可以變成:

需求
 ↓
Specification
 ↓
AI Implementation
 ↓
AI Self Review
 ↓
Static Analysis / Test
 ↓
AI Code Review
 ↓
Human Review
 ↓
修正
 ↓
Regression Test
 ↓
Merge

這裡最大的改變是:

AI 不再只是 Developer,而同時成為 Reviewer。

但這裡有一個非常重要的前提。

不要讓同一個 AI 同時當 Developer 和 Reviewer

如果我們叫 AI:

幫我完成這個功能。

AI 寫完之後再說:

幫我 Review 剛才的程式碼。

它很容易出現一個問題:

AI 會用自己剛才建立的假設,去驗證自己剛才建立的實作。

如果第一步理解錯需求,第二步很可能只是把錯誤合理化。

因此更好的做法,是把角色分開。

Developer AI

負責:

  • 理解 Specification
  • 建立實作
  • 修改程式碼
  • 撰寫 Test

Reviewer AI

負責:

  • 重新閱讀 Specification
  • 檢查 Implementation
  • 找出規格與實作的差異
  • 找出遺漏的 Business Rules
  • 找出 Edge Cases
  • 找出 Security 與 Data Integrity 問題

也就是:

Developer AI
     ↓
Implementation
     ↓
Reviewer AI
     ↓
Specification
     ↓
Gap Analysis

Reviewer 的核心不是:

「這份 Code 看起來不錯。」

而是:

「Specification 說了什麼,而 Implementation 做了什麼?」


四、Specification First:AI Review 的第一原則

AI Review Flow 的核心其實不是 Prompt。

而是:

Specification First

如果沒有清楚的 Specification,AI Review 很容易變成:

AI
 ↓
自己理解需求
 ↓
自己寫 Code
 ↓
自己 Review
 ↓
自己說沒問題

最後得到:

LGTM。

但問題是:

誰決定它真的符合需求?

所以在 AI 開始寫 Code 之前,應該先把規格定義清楚。

一份基本 Specification 至少應該包含:

1. 功能目的

這個功能到底要解決什麼問題?

2. Data Model

需要哪些欄位?

哪些可以是 NULL

哪些有 Default?

欄位之間有什麼關係?

3. Business Rules

什麼情況可以建立?

什麼情況可以修改?

什麼情況必須拒絕?

4. Permission

誰可以看到?

誰可以修改?

誰可以刪除?

5. API Behavior

API 應該回傳什麼?

哪些資料不能回傳?

哪些條件下資料才可以出現在 API?

6. Edge Cases

停用怎麼辦?

刪除怎麼辦?

沒有資料怎麼辦?

多語系缺少翻譯怎麼辦?

資料已經存在怎麼辦?


五、Review 不應該從 Coding Style 開始

很多 AI Code Review 最後會變成:

  • Method 太長
  • Variable 命名可以更好
  • 可以抽 Service
  • 可以使用 Collection
  • 可以重構
  • 可以減少重複程式碼

這些不是沒有價值。

但它們應該放在後面。

一個更合理的 Review 優先順序應該是:

1. Correctness

程式邏輯是否正確?

2. Security

是否有:

  • 權限漏洞
  • 資料洩漏
  • SQL Injection
  • Mass Assignment
  • 未授權資料存取

3. Data Integrity

資料是否可能:

  • 被錯誤更新
  • 被錯誤刪除
  • 產生不一致
  • 遺失關聯
  • 產生重複資料

4. Business Rules

Specification 裡面的規則是否全部實現?

5. Regression

是否破壞既有功能?

6. Performance

是否產生:

  • N+1 Query
  • 重複 Query
  • 不必要的資料載入
  • 不必要的 API Request

7. Code Quality

最後才是:

  • Naming
  • Structure
  • Readability
  • Maintainability
  • Refactoring

簡單說:

先確認「對不對」,再討論「漂不漂亮」。


六、不同風險的程式碼,不應該使用相同的 Review 強度

AI 並不是不能處理高風險程式碼。

問題是:

高風險程式碼不能只依賴 AI。

例如一般 CRUD:

建立資料
修改資料
列表
查詢

這些通常屬於相對低風險的工作。

AI 可以大量協助。

但以下功能就完全不同:

權限
金流
訂單狀態
資料隔離
多租戶
交易一致性
刪除邏輯
API 資料暴露

這些都是高風險區域。

AI 可以幫忙:

  • 分析
  • 找漏洞
  • 寫 Test
  • 做 Review
  • 提出風險

但是:

人類必須是最後決策者。

因此我認為 AI 時代非常重要的一個原則就是:

AI 負責加速,人類負責定義邊界。


七、用 Laravel CMS 看 AI Review 最容易發現什麼

假設今天我們要新增一個 CMS Block:

GroupCompany
 └── Blocks
      ├── Text Image
      ├── Card Grid
      └── Contact

AI 很快就可以建立:

Migration
Model
Enum
Filament Resource
Form
Table
API Resource
Controller

看起來非常完整。

但真正需要 Review 的問題可能是:

Block 停用之後會發生什麼?

假設資料結構是:

Page
 └── Blocks
      ├── Block A
      ├── Block B
      └── Block C

現在:

Block B
is_active = false

我們真正想要的行為是:

Block B
 ↓
保留資料
 ↓
後台仍然存在
 ↓
前台不顯示

而不是:

Block B
 ↓
被刪除

這兩個行為在技術上都完全可以被寫出來。

甚至兩段 Code 都可能沒有任何 Syntax Error。

所以:

單純檢查 Code 是抓不到這個問題的。

必須回到 Specification:

「停用」和「刪除」是不是兩種不同的操作?

如果答案是 Yes,那麼 Reviewer AI 就應該把它列為重要檢查項目。

這就是 AI Review 真正有價值的地方。


八、真正有價值的 Review 是 Gap Analysis

因此,我現在會比較不建議只對 AI 說:

Review this code.

因為這句話太模糊。

AI 很容易把任務理解成:

Code
 ↓
Style
 ↓
Best Practice
 ↓
Refactoring

更好的指令應該是:

Compare the implementation against the specification and identify any behavioral gaps.

也就是:

Specification
      ↓
      ↓
Implementation
      ↓
      ↓
Gap Analysis

Review 的重點變成:

  • Specification 有要求什麼?
  • Implementation 實際做了什麼?
  • 哪些規則沒有實作?
  • 哪些 Edge Case 沒處理?
  • 哪些行為和規格不同?
  • 哪些地方存在額外的、不被允許的行為?

這才是真正有價值的 Code Review。


九、AI Review 應該形成一個閉環

一個成熟的 AI Workflow 不應該是:

AI 寫完
 ↓
AI 說 OK
 ↓
結束

而應該是一個循環:

Specification
      ↓
AI Developer
      ↓
AI Self Review
      ↓
Test / Lint / QA
      ↓
AI Reviewer
      ↓
   PASS / FAIL
      ↓
   ┌──┴──┐
   │     │
 PASS   FAIL
   │     │
   │     ↓
   │   Fix
   │     │
   │     ↓
   │   Review
   │     │
   └─────┘
      ↓
Human Approval
      ↓
Merge

這裡最重要的是:

Review 不是一次性的動作,而是一個循環。


十、Fail Fast,Recover Faster

AI 時代有一句話反而更加重要:

Fail Fast, Recover Faster.

不要追求 AI 第一次就產生 100% 正確的 Code。

因為這不現實。

真正應該追求的是:

讓錯誤越早被發現。

因為錯誤被發現的時間越晚,修正成本通常越高。

可以把它分成五個 Level:

Level發現位置修正成本
Level 1Specification 發現需求矛盾最低
Level 2AI Review 發現邏輯問題
Level 3Automated Test 發現錯誤
Level 4Human Code Review 發現問題
Level 5Production 才發現最高

例如:

如果 Specification 就發現:

停用到底是隱藏還是刪除?

這時候修改成本幾乎是零。

但如果系統已經上線,管理員停用資料後發現資料真的被刪掉:

這時候就可能涉及:

  • 資料恢復
  • 使用者影響
  • API 錯誤
  • Production Incident
  • 客戶問題
  • 信任成本

所以:

好的 AI Workflow,不是讓 AI 永遠不犯錯,而是讓錯誤盡可能早被發現。


十一、AI Review 不是要取代 Human Review

AI Review 最容易被誤解成:

既然 AI 可以 Review,那是不是以後不需要工程師 Code Review?

我認為答案是否定的。

真正合理的架構應該是:

AI
 ↓
大量自動檢查
 ↓
篩掉明顯問題
 ↓
Human
 ↓
專注高價值決策

AI 很適合處理:

  • Naming
  • Formatting
  • CRUD Completeness
  • Nullable
  • Basic Query
  • 重複程式碼
  • 明顯的 Edge Case
  • 基本 Security Check
  • Test Coverage

而人類應該把時間留給:

  • Architecture
  • Business Logic
  • Security Boundary
  • Data Integrity
  • Trade-off
  • Product Decision
  • 系統長期維護成本

換句話說:

AI 不應該取代 Code Review,而應該提高 Code Review 的品質。


十二、真正重要的不是 Prompt Engineering,而是 Workflow Engineering

現在很多人還在研究:

哪一種 Prompt 可以讓 AI 寫出更好的 Code?

這當然有價值。

但如果只關注 Prompt,容易忽略更重要的問題:

AI 到底應該被放在整個 Software Engineering 流程的哪裡?

成熟的 AI 開發流程不應該是:

Human
 ↓
Prompt
 ↓
AI
 ↓
Code

而應該是:

Human
 ↓
Specification
 ↓
AI Implementation
 ↓
AI Review
 ↓
Automated Verification
 ↓
Human Review
 ↓
Merge

這兩種流程最大的差別是:

第一種把 AI 當成:

Code Generator

第二種把 AI 當成:

Software Engineering Team 的一個角色。

這是一個非常重要的轉變。


十三、AI Engineering 的核心其實是「角色分工」

當 AI 越來越強,我們不一定需要一個「全能 AI」。

反而可以把工作拆成不同角色:

Product / Human
      ↓
Specification
      ↓
┌─────────────────┐
│ Developer AI    │
│ 負責實作         │
└────────┬────────┘
         ↓
┌─────────────────┐
│ Reviewer AI     │
│ 負責找問題       │
└────────┬────────┘
         ↓
┌─────────────────┐
│ Testing / QA    │
│ 負責驗證         │
└────────┬────────┘
         ↓
┌─────────────────┐
│ Human Engineer  │
│ 最終決策         │
└─────────────────┘

這種架構最大的優點是:

把「產生」和「判斷」分離。

AI 非常擅長產生大量候選方案。

但工程品質真正需要的是:

判斷哪一個方案符合需求、符合架構、符合安全邊界。

而這正是 Review Flow 存在的價值。


十四、AI 時代,工程師的價值正在改變

如果 AI 可以幫我們快速寫出 CRUD,那麼:

「我會不會寫 CRUD」

這件事情本身的價值就會下降。

但另外幾種能力反而會變得更加重要:

Requirement Analysis

能不能把模糊需求變成明確規格?

System Design

能不能決定資料模型與架構?

Business Logic

能不能理解真正的商業規則?

Risk Assessment

能不能知道哪些地方不能交給 AI 自動決策?

Verification

能不能設計有效的測試與驗證流程?

AI Orchestration

能不能讓多個 AI 工作角色協同完成任務?

因此 AI 並沒有讓 Software Engineer 變得不重要。

它只是讓「工程師真正重要的能力」重新排序。


十五、我認為 AI 時代最重要的工程原則

如果要把整個 AI Review Flow 濃縮成幾個原則,我會留下這五個:

1. Specification First

沒有規格,就沒有可靠的 Review。

2. AI Developer ≠ AI Reviewer

產生與驗證應該盡可能分離。

3. Review Specification,而不只是 Review Code

真正要檢查的是:

Requirement
     ↓
Specification
     ↓
Implementation

三者是否一致。

4. 高風險邏輯必須保留 Human Decision

權限、金流、資料一致性、資料隔離等核心邏輯,不應該完全自動化。

5. Fail Fast, Recover Faster

不要追求「AI 永遠不犯錯」。

應該追求:

錯誤越早被發現,修正成本越低。


十六、最後:AI Coding 的下一個戰場不是「寫得更快」

AI Coding 的第一階段,比的是:

誰的 AI 寫 Code 比較快?

第二階段可能會變成:

誰的 AI 寫 Code 比較完整?

但我認為真正成熟之後,競爭會變成:

誰能建立更可靠的 AI Software Engineering Workflow?

因為當 Code 產生速度提升 5 倍、10 倍甚至更高之後,最大的瓶頸就不再是 Coding。

而是:

Verification

你可以讓 AI 在幾分鐘內產生數千行程式碼。

但如果沒有可靠的驗證流程,那些 Code 只是:

高速產生的風險。

反過來,如果我們建立完整的 AI Review Flow:

Specification
      ↓
Implementation
      ↓
AI Review
      ↓
Automated Verification
      ↓
Human Review
      ↓
Decision

AI 就不只是幫我們:

寫更多 Code。

而是幫我們:

更快發現錯誤。

更早修正錯誤。

把人類從低價值的重複檢查中解放出來。

讓工程師把時間放在真正重要的架構、商業邏輯與決策上。

這才是我認為 AI 真正進入 Software Engineering 之後,最值得建立的開發模式。


AI Review Flow 簡易 Specification Template

如果要把這套方法真正放進日常開發,可以從一份非常簡單的 Specification 開始:

## 功能名稱
[功能名稱]

## 1. 功能目的
- 

## 2. Data Model
- 欄位:
- Nullable:
- Default:

## 3. Business Rules
- 建立條件:
- 修改條件:
- 拒絕條件:

## 4. Permission
- 可見:
- 可修改:
- 可刪除:

## 5. API Behavior
- 回傳內容:
- 不可回傳:

## 6. Edge Cases
- 停用:
- 刪除:
- 無資料:
- 多語系:
- 其他:

接著讓 Reviewer AI 執行:

請根據以下 Specification,
對目前的實作程式碼進行 Gap Analysis。

重點檢查:

1. 是否完整實現所有 Business Rules
2. Edge Cases 是否正確處理
3. 權限與資料暴露是否符合規格
4. 是否存在資料一致性問題
5. 是否存在安全性問題
6. 是否可能破壞既有功能
7. 是否存在不必要的行為

請明確列出:

- Specification 有要求,但 Implementation 缺失的項目
- Implementation 與 Specification 不一致的項目
- 潛在的 Security / Data Integrity 問題
- 建議修改方式

不要只評論 Coding Style,
優先檢查「行為是否正確」。

當這個流程開始固定下來之後,AI 就不再只是 IDE 裡面的一個「自動補全工具」。

它會逐漸成為整個 Software Engineering Workflow 裡的一個正式角色。

而這可能才是 AI Coding 真正成熟之後,工程團隊最大的改變。

不是 AI 取代工程師。

而是:

工程師開始設計一套能夠駕馭 AI 的工程系統。

Astro + Vue 3 的 AI 開發標準:Docs MCP、Project Rules 與 Skills

前言:AI 會寫 Vue,不代表 AI 真的懂你的 Astro + Vue 3 專案 這幾年 AI Coding Agent 發展非常快。 從最早的: 「幫我寫一個 Vue Component。」 逐漸進化成: 「幫我修改這個頁面。」 再到現在: 「分析整個專案,幫我完成這個功能...