AI Coding 的下一個問題不是 Prompt，而是 Context Governance
AI 寫程式已經不再是問題。
現在的 AI（Claude、Cursor、Copilot）可以在幾秒內生成完整功能，甚至幫你重構整個模組。但當一個專案持續兩個月、三個月之後，一個新的問題開始出現：
AI 還記得你的架構嗎？
很多工程師在長期專案中都會遇到類似的情況。
有一次，我讓 AI 幫我修一個小 bug。
那是一個很普通的 Repository 層修改。AI 很快就給出了一段看起來完全合理的程式碼。
測試通過了。
CI 也沒有任何警告。
一切看起來都很好。
直到兩週後，我在 code review 的時候發現一件奇怪的事情：
Repository 層裡出現了 HTTP request。
也就是說，那段 AI 生成的程式碼，把 network I/O、fallback 邏輯、資料存取全部混在了一起。
原本清楚的分層架構，被悄悄打破了。
而當時我完全沒有察覺。
這不是 AI 第一次幫我寫 code，但卻是第一次讓我意識到一件事：
AI coding 最大的問題，其實不是生成品質。
而是 長期專案的上下文管理（context management）。
AI 在長期專案中常見的四個問題
回顧幾個月的 AI 協作經驗，我發現長期專案裡很容易出現四個問題：
1️⃣ AI 會遺忘過去的決策
幾十輪對話之後，它可能已經不太記得之前討論過的設計理由。
2️⃣ AI 不知道專案進行到哪個階段
它可以理解 code，但不知道現在是在 Prototype、Refactor 還是 Stabilization phase。
3️⃣ AI 只看到局部程式碼
它在修改某個檔案時，可能破壞整體架構的邊界。
4️⃣ AI 不知道現在應該優先做什麼
它可以完成任務，但很難對齊整個專案的 roadmap。
這些問題其實不是「AI 不夠聰明」。
而是 上下文管理的問題。
為什麼 AI 會違反架構規則？
很多人會說：
AI 明明讀過
ARCHITECTURE.md，為什麼還會違反？
但這個描述其實不太精確。
大型語言模型在生成程式碼時，近距離 context 的權重遠高於遠距離 context。
換句話說，在 AI 正在生成第 47 行程式碼時，它的注意力主要集中在：
- 剛剛寫過的程式碼
- 當前檔案
- 最近幾輪對話
而不是 20 輪對話前讀過的架構文件。
這種現象可以理解為：
attention decay（注意力衰減）
所以問題不是：
AI 故意違反規則
而是：
在長時間對話中，遠距離的規則逐漸失去權重。
這也是為什麼很多工程師會有一種感覺：
AI 在第 20 輪對話後，開始重新發明你兩天前已經寫好的架構。
如果問題是 attention decay，解法就不是「讓 AI 記住」
如果 attention decay 是結構性問題，那解法就不能是：
讓 AI 記住規則。
因為在長時間對話中，再重要的規則都會逐漸變成遠距離 context。
更有效的方法其實是：
讓關鍵上下文持續出現在 AI 的近距離 context 裡。
我在自己的專案裡嘗試整理出一套 AI 協作的工作流程，來降低這種 context drift。
核心想法很簡單：
問題對應機制
AI 遺忘過去決策
Memory system
AI 不知道專案階段
PLAN + phase freshness
AI 破壞架構邊界
Architecture guardrails
AI 不知道優先順序
Alignment with project roadmap
換句話說：
不是讓 AI 記住專案，而是讓專案的關鍵上下文持續出現在 AI 的工作 context 裡。
一個簡單的 Chaos Demo
我做了一個小實驗來模擬 AI 在沒有治理上下文時會發生什麼。
假設有一條簡單的架構規則：
Repository 層只負責資料存取，不允許 HTTP request。
在沒有治理上下文時，AI 很容易產生類似這樣的修改：
+ import httpx
+
+ response = httpx.get(api_url)
+ data = response.json()
+
+ self.db.insert(data)
Repository 突然同時負責：
- Network I/O
- Business fallback
- Data persistence
這種 架構侵蝕（architecture erosion） 通常不會立刻造成 bug，但會在幾週後讓系統變得難以維護。
在 repo 裡的 chaos demo，可以看到另一種情況：
當 ARCHITECTURE.md 和治理規則存在時，AI 通常會提出更符合分層架構的方案，例如：
- HTTP 呼叫放在 service layer
- Repository 只保留資料操作
這其實不是 AI 更聰明，而是上下文更清楚
這個實驗讓我慢慢意識到一件事：
AI coding 的下一個問題，也許不是 prompt engineering。
而是 project context governance。
不是治理 AI 本身，而是治理 AI 能看到的上下文。
誠實的限制
這個方法並不是萬能的。
目前很多治理規則仍然是 human-enforced，而不是完全自動化。
這套流程也不是為 fully autonomous agent 設計的。
它比較適合的場景是：
當人類仍然是架構師，而 AI 是強大的實作助手。
如果你也在做長期 AI 協作的專案
我把這個實驗整理成一個 GitHub repo，裡面包含：
- AI 協作常用的文件範本（ARCHITECTURE / PLAN 等）
- 一個可以本地查看的 chaos demo
- 幾個簡單的治理檢查腳本
repo：
https://github.com/GavinWu672/ai-governance-framework
也很好奇一件事：
在你的 AI coding 專案裡，最常遇到的是哪一種問題？
- AI 忘記之前的設計
- AI 破壞架構邊界
- 還是每次都要重新解釋專案背景？
歡迎分享你的經驗。
