AI 规则部署器

团队 AI 协作的规则治理痛点

当 AI 编程工具进入团队协作后，第一个问题不是模型能力不足，而是行为不一致：有人让模型生成 camelCase 变量，有人习惯 snake_case；有人要求函数必须写 JSDoc，有人只在关键路径补注释。这些差异会体现在代码审查里、合并请求里，甚至生产环境的低级错误上。更麻烦的是，规则散落在个人笔记、聊天记录和各自的 prompts 里，没有统一的载体，新成员加入时只能靠“口口相传”。

本地调整和团队规则的冲突也很常见：开发者为了让模型适配个人习惯，会在自己的分支里加一些临时规则，但这些调整不会被团队感知，反而在合并时制造混乱。全局规则的需求也很直接：同一个用户可能有多个项目，如果每个项目都要重复设置同样的偏好，维护成本会越来越高。

技能如何帮你落地规则

AI Rule Deployer 的核心能力，是按照 TRAE 和 WORKBUDDY 平台的规范，生成结构化的规则文件，覆盖四个层级：

• 全局层：~/.trae/TRAE.md 或 ~/.workbuddy/WORKBUDDY.md，作用于当前用户的所有项目，适合放跨项目的通用偏好（比如代码风格、Git 提交规范）。
• 项目层：项目根目录的 TRAE.md 或 WORKBUDDY.md，用于团队共享的项目约定（比如 API 设计规范、依赖管理策略）。
• 团队规则层：.trae/rules/golden.md 或 .workbuddy/rules/golden.md，专门存放团队行为准则（比如代码审查流程、PR 描述模板）。
• 本地层：TRAE.local.md 或 WORKBUDDY.local.md，用于个人临时调整（比如测试时的特殊规则），不会提交到团队仓库。

技能支持按需部署：你可以选择只生成全局规则，避免污染项目仓库；也可以只部署项目层规则，让规则跟着项目走。平台切换也很简单：调用时指定目标平台，技能会自动匹配对应的配置文件和目录结构。

适用边界与注意事项

这个技能不是通用的 AI 规则管理工具，只支持 TRAE 和 WORKBUDDY 两个平台——如果你用的是 Cursor、Claude Code 等其他工具，规则文件的结构可能不兼容。

规则的内容需要你自己定义：技能只负责生成文件框架和层级结构，具体的规则条目需要团队协商后填写。生成的规则文件不会自动生效，需要对应的 AI 工具支持读取这些配置文件（比如 TRAE 会加载 .trae/ 目录下的规则）。

部署全局层时要格外小心：全局规则会覆盖所有项目的默认设置，如果已经有同名文件，建议先备份再部署。本地层规则适合临时调试，不建议长期保留，否则可能和其他开发者的行为产生冲突。