90% 程式碼由 AI 產出，我如何建立可靠情境體系

90% 代碼由 AI 產出，我如何構建可靠上下文體系

從21年開始使用 copilot，能夠用 AI 代碼補全，到現在操作複雜專案模塊級別的代碼生成，它們對於使用者的視角和心態已經不在一個維度。同樣的工具，不同的 AI 使用者我發現也能拉開巨大的差距。所以寫一篇文章和大家交流一下心得，如果有更佳的實踐也非常歡迎一起交流。

Context is all you need

僅依賴 vibe coding（模型自行聯想 → 自行搜尋 → 直接改動）在一些場景下效果會不穩定：可能出現理解偏差、語義不一致，token 消耗也偏高，產出與預期不完全一致。直接使用對話 AI 更像是你臨時拉來了一個專家級別的外包，他很聰明，但是剛來很容易還水土不服，還有可能誤解你的意圖寫了一堆不想要的東西。本質上是 context，Garbage In, Garbage Out 輸入質量直接影響輸出質量。優化的第一性原則是 attention 機制：無關/模糊/矛盾的信息會分散 attention，影響結果穩定性。而上下文不足：只給單輪粗略描述時，模型不了解專案歷史、代碼風格與約束，也很難有高質量輸出。

更穩妥的做法，是提供“合適的 context”，讓模型在清晰邊界內工作。這裡的“合適”指最小但充分、結構化的信息，就像我們設計函數一樣——對外只暴露接口，隱藏內部實現；context 的“精妙”也在於此：給模型的，應該是完成任務所需的接口面，而不是把實現細節一股腦兒倒進去。少了容易歧義、多了會稀釋 attention，極端情況下還會撐爆上下文窗口。

這也是我為什麼會做工程級別的 Context Engineering 的原因：把長期知識（架構/職責/規範）沉到“工程樹”，每次按任務打包“頂層規則 + 模塊 README（索引） + 任務 spec”的最小集，讓模型在清晰邊界內工作。現在在 IM 模塊裡，約 90% 的代碼可以由 AI 穩定產出，複雜改動也能跨幾十個檔案一次到位，整體效率提升數倍。

我通常會關注下面三個層級：

單行/函數級：這個可以自由發揮，通常我會讓 AI 針對複雜的函數寫好註釋。
檔案級：通常在一個資料夾內，我會有一個 README，它用於描述這個資料夾下每個檔案的職責和約束，AI 通過這個 README 快速定位相關檔案。檔案內部也會補充註釋，幫助 AI 理解細節。
工程級（跨模塊/跨多檔案）：使用“頂層規則 + 模塊 README（索引） + spec-driven 生成規劃，可以做到橫跨幾十檔案的複雜改動。

上面的作用是一個給人/AI 來看的索引，我們也是我們主要需要維護和關注的點。把長期知識（架構/職責/規範）組織成可索引的樹。每次任務只打最小包——頂層規則 + 當前模塊 README（作為索引）+ 本次任務 spec——減少無效搜尋與反覆推斷，降低 token 消耗，同時提升對齊度與可複現性。

當我們構建好一套自動化的 context provider 機制之後，我們只需要考慮每次的需求需要哪個 scope 的文檔參與，並不需要每次都手敲一堆 context 進去，這也是“專案級 Context Engineering”的價值所在。

當然也不是所有問題都要動用“牛刀”，簡單任務用 vibe coding 更快；但層級越高，複雜度和對 AI 的可控性要求越強，方法論需要從“靈感驅動”轉為“context 驅動”。

在一個複雜專案中我是如何實踐的

此實踐並非從專案一開始就這麼設計，而是在模塊開發中途逐步完善，中間也經歷了非常大的改造過程。到目前已經跑得非常穩定，能夠 cover 絕大部分需求的自動化產出。好的設計才能讓 AI 長期穩定地輸出，我的經驗是要做到以下幾點：

每一個檔案儘量不要特別大，主要是在給 AI 的時候省上下文，避免 attention 被稀釋
每一個模塊職責清晰，避免 AI 在職責邊界上猶豫
每一個資料夾級別都有 README，承擔索引定位的職責
頂層有長期規則，沉澱通用約束
一定要保持對專案的掌控力度，不要 accept 你看不懂的架構級別的內容，保持代碼架構的可維護性

為了實現這一點我經歷了一波比較大的重構，把整個模塊拆的非常細。演進到現在的結構大概是這樣：

層級	內容	示例	作用
App 頂層	通用約束（全模塊生效）	路由註冊規範、螢幕適配（fit 策略）、文字枚舉	新人/新 AI 快速上手
模塊頂層	職責定義與拆分	IM 模塊 README：業務職責、子模塊劃分、維護規則	索引定位
子模塊	具體的實現信息	`controller/`、`build/`、`model/` 等資料夾規範	提供最底層的實現層面的信息