最近一年，AI coding 工具的進步速度非常快。
從 GitHub Copilot、Cursor，到各種 AI coding agent，現在很多工程師的工作流程都已經變成：- 用 AI 產生程式
- 自己 review
- 再修改
對很多軟體工程師來說，這其實是一個很大的生產力提升。
但在實際使用 AI 寫程式的過程中，我慢慢發現一個問題：
AI 很會寫 code，但它不知道哪些地方不能亂寫。
AI coding 的另一面：架構破壞
AI 寫 code 最大的問題不是 syntax。
大部分時候，AI 生成的程式碼其實：
- 可以編譯
- 邏輯看起來合理
- 甚至測試也能通過
真正的問題通常發生在 系統架構層級。
例如：
- AI refactor 了一段 code，但破壞了原本的 architecture boundary
- AI 修改了一個 struct，但沒有意識到其他模組也依賴它
- AI 改了一個流程，但忽略了某些隱含的 constraint
這些問題在小專案可能沒什麼，但在大型專案中，很容易變成：
AI 改了 code
↓
架構被破壞
↓
問題很久之後才出現
我在幾個實際專案使用 AI coding 的過程中，常常遇到類似的情況。
於是我開始思考一個問題：
如果 AI 已經會寫程式，那工程師的角色會變成什麼？
AI 需要的不只是 prompt，而是邊界
很多人現在談 AI coding，討論的重點通常是：
- prompt engineering
- 如何讓 AI 產生更好的 code
- 哪個模型寫 code 最強
但在實際專案裡，我發現一件更重要的事：
AI 不需要更好的 prompt，它需要更清楚的邊界。
也就是：
- 哪些地方 AI 可以修改
- 哪些地方 AI 不能碰
- 哪些修改一定要驗證
如果沒有這些規則，AI 很容易在不知情的情況下破壞系統設計。
於是我開始嘗試做一件事情：
為 AI 寫程式設計一套工程治理規則。
把 AI collaboration 變成工程系統
我把這套方法整理成一個簡單的 framework，核心概念其實很單純：
AI 可以參與開發，但必須遵守工程規則。
例如：
- AI 不可以猜測 hardware facts
- AI 不可以自動 refactor architecture-sensitive code
- 高風險修改必須附上 validation evidence
這些規則看起來很簡單，但在實際專案中其實很有效。
我在幾個軟體專案裡導入這套做法後，發現：
- AI refactor 造成的架構破壞明顯減少
- 團隊對 AI coding 的信任度提高
- AI collaboration 變得更穩定
這也讓我開始思考：
這其實不只是使用 AI，而是在設計 AI 如何參與工程開發。
Firmware 世界的 AI 風險更高
後來我又想到另一個領域：
Firmware。
在 Firmware 或 IC 相關開發中，AI 的風險其實更高。
例如：
- USB descriptor layout
- interrupt service routine
- power sequence
- protocol struct
如果 AI 在這些地方「合理猜測」，結果很可能是：
AI 改 code
↓
硬體行為錯誤
↓
enumeration fail
這類 bug 有時候很難 debug。
所以我又做了一個實驗：
為 firmware 專案設計一套 architecture contract。
也就是：
- 哪些 code 是 architecture-sensitive
- 哪些地方 AI 不能自動 refactor
- 哪些修改必須經過 validation
這其實就是把資深工程師的經驗，轉化成 AI 可以遵守的規則。
IC 設計領域其實有很多地方可以導入
後來我慢慢意識到，這件事情其實不只適用於 firmware。
在 IC 設計產業裡，其實有大量工作需要寫程式，例如：
- verification script
- simulation automation
- ATE test program
- bring-up tool
- validation tool
很多時候，這些程式真正困難的不是語法，而是 domain know-how。
例如：
- register access sequence
- reset flow
- timing constraint
- power dependency
這些知識通常只存在於資深工程師的經驗裡。
AI 可以幫忙寫 code，但如果沒有這些規則限制，AI 很容易寫出「看起來合理但實際不可用」的程式。
因此，一個很自然的想法是：
把資深工程師的 know-how 轉化為治理文件。
例如：
- FACTS.md
- ARCHITECTURE.md
- VALIDATION_RULE.md
讓 AI 在寫程式時能遵守這些規則。
這可能是一種新的工程角色
在做這些事情的過程中，我慢慢發現一件事：
我做的工作，其實不是寫 code。
而是：
- 設計 AI collaboration workflow
- 定義 architecture boundary
- 建立工程治理規則
- 與不同領域工程師合作
簡單說，就是：
設計 AI 如何安全地寫程式。
如果 AI coding 繼續發展下去，未來很多工程團隊可能會需要這樣一種角色：
一個專門設計 AI engineering workflow 的工程師。
他的工作不只是寫 code，而是：
- 把 domain knowledge 轉化為工程規則
- 建立 AI collaboration guardrail
- 讓 AI 可以安全地參與開發
這個角色有點像當年的 DevOps。
在 2010 年左右，很多人覺得 CI/CD 只是工具，但後來 DevOps 變成一個新的工程職能。
AI engineering governance 也許會走向類似的方向。
未來工程師的價值可能不只是寫程式
AI coding 的出現，確實會改變工程師的工作方式。
但我越來越覺得：
未來工程師真正重要的能力，可能不是寫更多 code，而是：
設計 AI 可以如何寫 code。
因為 AI 可以生成程式碼，但只有工程師知道：
- 哪些地方可以改
- 哪些地方不能碰
- 哪些修改需要驗證
也許未來每個工程團隊都會需要一個人，專門設計這些規則。
如果是這樣的話，我們可能正在看到一種新的工程角色出現。
而這個角色的工作，就是把工程領域的 know-how，轉化成 AI 可以遵守的系統。
