讓團隊統一使用同一套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配置”中。