让团队统一使用同一套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配置”中。