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 AnalysisReviewer 的核心不是：
「這份 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
└── ContactAI 很快就可以建立：
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 AnalysisReview 的重點變成：
- 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 1 | Specification 發現需求矛盾 | 最低 |
| Level 2 | AI Review 發現邏輯問題 | 低 |
| Level 3 | Automated Test 發現錯誤 | 中 |
| Level 4 | Human Code Review 發現問題 | 高 |
| Level 5 | Production 才發現 | 最高 |
例如：
如果 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
↓
DecisionAI 就不只是幫我們：
寫更多 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 的工程系統。
