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 | 問題 |
|---|---|---|
| 1 | Scope | 是否只修改需求必要範圍？ |
| 2 | Duplication | 是否新增了既有功能的第二套實作？ |
| 3 | Responsibility | Controller / Service / Model 職責是否清楚？ |
| 4 | Call Chain | 是否確認實際呼叫鏈後才修改？ |
| 5 | Data Flow | Request → API → DB → Response 是否一致？ |
| 6 | Permission | 新功能是否同步檢查權限？ |
| 7 | Performance | 是否引入 N+1、重複 Query 或大量資料載入？ |
| 8 | Regression | 是否確認既有功能沒有受到影響？ |
這個 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」，而是能夠在既有軟體工程規範下，持續產生正確、可維護、可演進的系統。
