---
title: 從賽車到高鐵：AI Coding 在大型專案的框架思維
tags: [ai-coding, architecture, erp, framework-design, software-engineering]
---
# 從賽車到高鐵：AI Coding 在大型專案的框架思維
> 大多數人用 AI 寫程式像 F1 賽車——速度很快，但跑得好不好全看車手。大型專案需要的是高鐵：靠軌道，不靠車手。
# 1️⃣ 問題：AI 的寫法太自由
目前主流的 AI Coding 工作流大致如下：
1. 寫規格或 User Story
2. 讓 AI 生成程式碼
3. 用單元測試驗證品質
4. Code Review，發現問題再修正
這個流程在小型專案或獨立功能上運作得很好。但放到 ERP 級別的大型專案，問題就浮現了：
- 每個工程師用 AI 的方式不同，**同一類功能可能有十種實作方式**
- 測試覆蓋率高，不代表架構一致性高
- 隨著功能增加，維護成本以非線性速度上升
- AI 生成的程式碼沒有「記憶」，不知道專案已有的慣例
根本原因不是 AI 不夠聰明，而是 **AI 可選的寫法太多**——不是寫錯，而是合法的寫法太多種。我們給了它一片空白，它能寫出一百種正確但彼此不相容的答案。
---
# 2️⃣ 核心思路：縮小選擇空間，而不是加更多 Prompt
| F1 賽車模型（現況） | 高鐵模型（目標） |
|---|---|
| 結果取決於車手（工程師）技術 | 結果取決於軌道（框架）規範 |
| AI 自由選擇實作方式 | AI 只能填空，不能選路 |
| 每個功能都長得不一樣 | 所有功能共享骨架 |
| 靠測試事後補救 | 框架本身就是 constraint |
| 維護人員需讀懂 AI 的意圖 | 維護人員只需懂框架 |
重點在於：**不要試圖用更精準的 Prompt 控制 AI，而是先建一條 AI 只能在上面跑的鐵軌。**
這條鐵軌，就是開發框架。
---
# 3️⃣ 解法：Framework-First，AI-Second
### 角色分工
```
Feature Layer ← 工程師 / PM 用 AI 填空，只寫業務邏輯
─────────────────
Framework Layer ← 架構師建置，Transaction / Auth / Audit / Routing
─────────────────
Infrastructure Layer ← DB / Queue / Cache / API GW
↑ 越往下越需要高品質，越往上越需要簡單
```
架構師負責建鐵軌，其他開發參與者在上面開列車。
### 框架設計的核心原則：讓錯誤的寫法無法編譯
框架不是「建議大家這樣寫」，而是「其他寫法根本跑不起來」。
框架對外只暴露必要的抽象介面，隱藏所有底層實作細節。開發者無法繞過框架直接操作資料庫、無法跳過驗證層、無法忽略權限檢查——不是因為有人盯著，而是因為框架根本沒有提供那條路。
AI 的任務因此從「自由發揮」變成「在框架定義的邊界內填入業務邏輯」。AI 可選的寫法從整個程式語言，縮小到業務邏輯本身。
### 用靜態分析機器強制執行架構規範
框架的約束力必須是機器強制的，不能依賴 Code Review 的人工自律。
透過靜態分析工具，可以在編譯期或 CI 階段自動檢查：跨模組是否透過正確的通道溝通、業務邏輯是否混入了不該有的基礎設施操作、單一功能的規模是否超出合理範圍。
AI 生成的程式碼如果違反框架規範，在 CI 就直接擋下來，不進入人工審核流程。
---
# 4️⃣ 終極目標：AI 開發閉環
框架建好之後，才有可能實現真正的 AI 開發閉環：
```
結構化需求（PM 填寫 YAML / 表單）
│
▼
AI Orchestrator
識別 Pattern → 生成骨架 → 填入業務邏輯 → 測試 → 自動修正重試
│
▼
Human Review
人只審核業務邏輯，架構與安全性由框架保證
```
### 閉環成立的三個前提
**1. Pattern 可識別性**
框架需要明確定義功能 Pattern 清單，AI 才能判斷「這個需求套哪條鐵軌」：
```
Pattern Taxonomy（以 ERP 為例）
├── SimpleCrud → 基本主檔維護（供應商、客戶）
├── ApprovalFlow → 需審核的單據（採購單、請假）
├── Calculation → 批次運算（薪資、成本分攤）
├── Integration → 對接外部系統（EDI、銀行）
├── Report → 查詢報表（唯讀）
└── Composite → 以上組合（需人介入拆解）
```
**2. 需求結構化**
PM 的自然語言無法直接餵給閉環。需求必須先結構化——明確定義功能名稱、對應的 Pattern、欄位定義、審核規則、業務規則。這個格式比自然語言精確，比程式碼容易讓非工程師填寫，是閉環的起點。
**3. 可量測的閉環成功率**
閉環不是 100% 全自動，而是有明確的人工介入觸發條件：
| 狀態 | 條件 |
|------|------|
| **閉環成功（全自動）** | Pattern 識別信心度達門檻、Build + Test 全過、無跨模組新依賴 |
| **需人介入（半自動）** | Pattern 為 Composite、需求涉及現有邏輯修改、Test coverage 不足 |
| **退回重新設計** | 需求隱含框架尚未支援的 Pattern → 這是框架演進的 signal |
---
# 5️⃣ 對組織的影響
導入框架驅動的 AI 開發後，開發流程會從：
```
PM → 需求文件 → 工程師 → 程式碼 → QA → 部署
```
轉變為：
```
PM → 結構化需求 → AI Pipeline → PR → 人工審核 → 部署
```
知識不再只存在工程師腦中，而是沉澱在框架和 Pattern 庫裡。人員異動的衝擊降低，新人學會框架就能上手，技術債也集中在框架層統一管理。
---
# 6️⃣ 框架建置的優先順序
框架不是一次建完，而是漸進建置：
```
Phase 1 — 鐵軌鋪設（最重要）
├── Base classes / interfaces 定義
├── Scaffolding CLI（一個指令生成模組骨架）
└── Reference Implementation（給 AI 學習的 few-shot 範本）
Phase 2 — 邊界強制化
├── 靜態分析規則（編譯期檢查架構規範）
├── Architecture unit test
└── Code review checklist → 轉成自動化檢查
Phase 3 — AI Prompt 標準化
├── 每類 Pattern 各一套 system prompt template
├── Context injection（自動帶入相關 Entity 定義）
└── Output validation（產出的 code 跑 build + 靜態分析）
```
---
# 7️⃣ 框架方法的風險與取捨
框架不是銀彈，選擇這條路也有代價：
- **框架設計錯的成本很高**：框架是地基，地基歪了，上面蓋的功能全部跟著歪。修正框架往往意味著大範圍的連鎖調整，不像單一功能改完就結束。
- **框架需要持續演進**：業務需求會變，框架也得跟著調整。向後相容、版本遷移、deprecation 策略——這些都是持續的維護負擔，不會因為「框架建好了」就停止。
- **過度約束會綁住手腳**：不是所有功能都能套進預定義的 Pattern。如果框架沒有留給例外情境合理的逃生出口，開發者就會被迫用扭曲的方式硬套，反而製造更多問題。
這些風險不是說框架方法不可行，而是框架的設計品質直接決定了整套方法的成敗。
建議框架在開放使用前，先用三個差異很大的真實功能來驗證：
1. **簡單 CRUD**（最基本的情境）
2. **複雜審核流程**（有狀態、有規則）
3. **跨模組整合**（有依賴、有副作用）
如果框架能優雅地容納這三種情境，才算真正完成。
---
# ✅ 結語
**框架設計本身的品質，決定了一切。**
架構師的最終產出不是程式碼，而是一條讓整個組織可以持續高速運行的鐵軌。框架建得好，換誰來開都能準點到站。
這套做法不一定適合所有專案——如果你的專案規模不大、團隊人數固定、AI 使用方式已經有默契，靠 F1 模式也能跑得很好。但如果你面對的是持續擴張、人員流動頻繁的大型系統，或許值得認真考慮：先把鐵軌鋪好，再讓 AI 上路。
---
📘 **HackMD 原文筆記：**
👉 https://hackmd.io/@jeff377/ai-coding-railway-model
**📢 歡迎轉載，請註明出處**
**📬 歡迎追蹤我的技術筆記與實戰經驗分享**
[Facebook](https://www.facebook.com/profile.php?id=61574839666569) ｜ [HackMD](https://hackmd.io/@jeff377) ｜ [GitHub](https://github.com/jeff377) ｜ [NuGet](https://www.nuget.org/profiles/jeff377)
Sign in via Facebook
Sign in via X(Twitter)
Sign in via GitHub
Sign in via Dropbox
Sign in with Wallet
Connect another wallet