讓團隊統一使用同一套AI配置

在現代軟件開發中，團隊越來越依賴多個AI代理來輔助編碼，但如何讓所有成員和倉庫保持一致的配置成為了一個棘手的問題。一位團隊領導發現，前端和後端團隊使用相同的AI工具卻產生了截然不同的代碼。有人對比了兩個倉庫的AGENTS.md文件，發現它們對組織數月前已達成共識的規範持有不同理解。安全負責人發現某個代理擁有沒人記得批准過的權限。這些故事揭示了一個普遍現象：AI配置正在不知不覺中漂移。

問題的根源在於，團隊漂移比個人漂移更嚴重。每個新倉庫都會從其創建者最近接觸的倉庫中複製指令，因此約定像變異一樣傳播而非像發佈那樣統一。每個開發者的筆記本電腦上積累了一套私有的技能、規則和權限，這些對他自己有效，但對其他人不可見。當有人改進了某個約定，改進只落在一個倉庫中，沒有渠道讓所有人都受益。結果是，組織的真實AI配置變得不可知——無法審計、無法保障安全、無法改進。

傳統解決方案無一奏效。維基頁面只是建議而非系統，它沒有分發機制和反饋迴路。共享模板倉庫只解決第一天的問題，到了第九十天漂移就會顯現。同步腳本覆蓋每個倉庫文件會被在一週內回滾，因為每個倉庫都有自己獨特的內容。將一切集中到一份龐大的組織級指令文件中則過於泛化，對數據團隊無用，對安全團隊過於嘈雜，且無人真正負責。

可行的方案是將標準版本化，並在每個倉庫中聲明使用。具體做法是：組織將共同遵守的規範（如提交紀律、審查規則、秘密處理）打包成一個小型版本化的基線包。每個團隊擁有自己領域的包，例如前端的組件模式、安全部的硬化權限集。每個倉庫在committed的harness.json清單中聲明其使用的包和精確版本。工具將包擴展為每個代理實際讀取的文件，並且只寫入標記的管理區域，確保倉庫自己的內容不會被覆蓋。清單將無法回答的問題轉化為可查詢的數據：這個倉庫的配置是什麼？讀取文件。哪些團隊在使用當前的安全基線？比較清單中的版本。這變成了一個腳本，而非一次調查。改進一個約定變成了包發佈和版本更新Pull Request，由每個團隊按自己的節奏審查和合並。

當團隊問“如何讓所有人使用同一套配置”時，他們真正想要的是他們技術棧中其他部分已經擁有的東西：一個關於“我們在運行什麼，誰在使用它，何時發生了變化”的答案。Git為他們提供了代碼的答案，包管理器為依賴提供了答案。而驅動AI代理的指令、技能和權限仍然依賴於口口相傳，而這些配置每天都在向倉庫中寫入代碼。給予它們同樣的工具：版本化、固定版本、通過Pull Request分發、衡量採用率而非聲稱。這就是全部答案，而且它故意保持簡單。

清單規範已在github.com/baselane-sh/harness.json開源。即使沒有工具，一個人類或代理也能輕鬆讀取。而自動化審計、實現、漂移檢查和團隊級視圖的工具則通過baselane提供。如果你的團隊正在問這個問題，在一個倉庫上運行npx baselane audit只需十分鐘，就能看到你實際所處的狀況。分步推行的指南在後續文章“如何管理五個團隊的AI配置”中。