AI Coding 的下一步：把架構變成 Machine-Readable Rules

在上一篇文章〈AI 寫程式三個月後，它開始忘記你的架構了〉裡，我提到一個很多工程師正在遇到的問題：

在長期專案中，AI 很容易逐漸偏離原本的架構設計。

或在 Application Layer 直接呼叫 OS API。

這些修改通常不會立刻造成 bug，但會慢慢侵蝕系統架構。

問題是：

AI 為什麼會違反架構規則？

架構規則其實一直存在

在大多數成熟的專案裡，其實都有一套隱形的架構規則。

例如：

• 哪些 module 可以依賴哪些 module
• 哪些 layer 可以呼叫哪些 API
• 哪些地方不能做 network I/O
• 哪些函式不能在 interrupt context 執行

這些規則可能存在於：

• ARCHITECTURE.md
• 設計文件
• code review guideline
• 或資深工程師的經驗

對人類工程師來說，這些規則通常是默契。

但對 AI 來說，情況完全不同。

AI 看不到你的架構規則

AI 在生成程式碼時，主要依賴的是：

• 當前檔案
• 附近的程式碼
• 最近幾輪對話

而不是整個專案的設計文件。

換句話說，AI 的決策邏輯通常是：

Does the code compile?
Does it solve the task?

而不是：

Does this violate architecture?

因此當 AI 在修改某個檔案時，很容易做出「局部正確、整體錯誤」的修改。

一個跨平台專案的典型例子

很多跨平台專案會有這樣的結構：

Application Layer
        ↓
Platform Abstraction Layer
        ↓
Windows / macOS / Linux implementation

Application Layer 理論上不應該直接呼叫作業系統 API。

但 AI 為了快速完成任務，很可能寫出類似這樣的程式碼：

#ifdef_WIN32
CreateFile(...)
#endif

功能完成了。

但 abstraction boundary 被破壞了。

這種情況在長期專案裡非常常見。

如果架構規則只是文件，AI 就看不到它

很多團隊會在 README 或設計文件中寫下架構規則。

但問題是：

文件本身不是可執行的。

它只能靠人類在 code review 時手動檢查。

在 AI coding 的時代，這種模式開始出現一個新的問題：

AI 生成 code 的速度遠超人類審查的速度。

如果架構規則只存在於文件裡，那麼違反規則的程式碼就很容易混入系統。

這也是為什麼很多專案在使用 AI 一段時間後，會出現一種感覺：

系統沒有明顯 bug，但架構開始變得混亂。

一個可能的方向：Architecture Contracts

如果問題是：

AI 看不到架構規則

那麼一個自然的想法是：

把架構規則變成 machine-readable。

也就是所謂的 Architecture Contracts。

簡單來說，就是把架構設計中的重要約束轉成可以被工具檢查的規則。

例如：

Layer Dependency Rule

Application layer cannot depend on Infrastructure layer

Module Boundary Rule

Repository layer cannot perform network I/O

Driver IRQL Rule

DISPATCH_LEVEL functions cannot call pageable code

Firmware ISR Rule

ISR cannot perform blocking operations

當這些規則變成 machine-readable contracts 時，

AI 在修改程式碼時，就不只是依賴 prompt 或文件。

而是會受到一層 架構治理（architecture governance） 的約束。

這不是限制 AI，而是保護系統

很多人第一次聽到這個概念時會覺得：

這是不是在限制 AI？

但從另一個角度看，Architecture Contracts 的目的其實是：

保護系統架構。

AI 仍然可以：

• 重構程式碼
• 新增功能
• 改善實作

但它不能隨意跨越系統邊界。

就像人類工程師也需要遵守架構設計一樣。

為什麼低階系統更需要這件事

在 Web 或 SaaS 專案裡，架構違規通常只是技術債。

但在 Firmware 或 Driver 這類系統裡，情況完全不同。

例如：

• ISR 裡做 blocking operation
• 在錯誤 IRQL 呼叫 API
• Driver 呼叫 pageable memory

這些錯誤往往不是 code smell，而是 production crash。

當 AI 開始參與這些系統開發時，

架構規則就不只是設計建議，而是 安全邊界。

下一步：讓契約真正運作

Architecture Contracts 本身只是概念。

真正的問題是：

如何讓這些規則在開發流程中真正生效？

在接下來的文章裡，我會介紹我正在做的一個實驗：

AI Governance Framework

它嘗試把 Architecture Contracts 變成一層可執行的開發治理系統。

讓 AI 在寫程式時，不只是依賴 prompt，

而是受到可驗證的架構約束。

小結

AI coding 的下一個問題，也許不是 prompt engineering。

而是：

architecture governance。

如果架構規則只存在於文件裡，

AI 遲早會慢慢侵蝕系統設計。

但如果這些規則能變成 machine-readable contracts，

那麼 AI 就可以在既定邊界內發揮能力，

而不是無意間重寫整個系統架構。

如果你也在做長期 AI 協作開發的專案，我其實很好奇一件事：

你的專案裡，最常被破壞的架構規則是什麼？

• layer boundary
• module dependency
• concurrency rule
• platform abstraction

歡迎分享你的經驗。