大多數人用 AI 寫程式像 F1 賽車——速度很快，但跑得好不好全看車手。大型專案需要的是高鐵：靠軌道，不靠車手。

1️⃣ 問題：AI 的寫法太自由

目前主流的 AI Coding 工作流大致如下：

1. 寫規格或 User Story
2. 讓 AI 生成程式碼
3. 用單元測試驗證品質
4. Code Review，發現問題再修正

這個流程在小型專案或獨立功能上運作得很好。但放到 ERP 級別的大型專案，問題就浮現了：

• 每個工程師用 AI 的方式不同，同一類功能可能有十種實作方式
• 測試覆蓋率高，不代表架構一致性高
• 隨著功能增加，維護成本以非線性速度上升
• AI 生成的程式碼沒有「記憶」，不知道專案已有的慣例

根本原因不是 AI 不夠聰明，而是 AI 可選的寫法太多——不是寫錯，而是合法的寫法太多種。我們給了它一片空白，它能寫出一百種正確但彼此不相容的答案。

2️⃣ 核心思路：縮小選擇空間，而不是加更多 Prompt

重點在於：不要試圖用更精準的 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% 全自動，而是有明確的人工介入觸發條件：

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 ｜ HackMD ｜ GitHub ｜ NuGet