1. 项目概述一个AI智能体配置的“中央厨房”如果你和我一样同时在使用Cursor、Claude Code、OpenCode这些新一代的AI编程工具那你一定体会过那种“配置分裂”的痛苦。每个工具都有自己的规则文件、技能目录和配置文件它们散落在~/.cursor、~/.claude、~/.config/opencode这些不同的角落里。当你精心调教好一套适用于自己工作流的规则想在另一个工具里复用或者想分享给团队时就得手动复制粘贴版本管理更是一团乱麻。更别提那些从社区淘来的优秀规则更新起来简直是一场噩梦。我最近在用的这个cdbattags/ai项目就是来解决这个问题的。你可以把它理解为一个为AI编程工具打造的“中央厨房”或“配置中心”。它的核心思想非常极客也极其有效用一个Git仓库通过符号链接统一管理你所有AI工具的配置。无论是Cursor的.mdc规则文件、跨工具的SKILL.md技能还是Claude Code的CLAUDE.md设置甚至是新兴的MCP服务器配置现在都可以放在同一个地方编写、版本控制和同步。这个项目不只是简单的文件聚合。它引入了“构建”的概念。你写在src/目录下的原始内容和通过git submodule引入的社区“食材”vendor会经过一个link.ts脚本的处理被“烹饪”成一份份针对不同工具Cursor, Claude, OpenCode的完整配置树放在dist/你的名字/目录下。最后再通过符号链接“上菜”到各个工具原本的配置目录。这样一来你的配置有了唯一的“真相源”修改一处所有工具即刻生效。对于需要为不同项目比如前端Web和后端服务配置不同MCP服务器组合的场景它也能通过“配置文件”轻松应对。2. 核心设计思路与架构解析2.1 为什么是“符号链接构建”而不是直接复制这是理解整个项目设计的关键。直接复制文件是最简单的方案但会带来几个无法忍受的问题更新同步困难如果你在工具A的目录里修改了某个规则必须记得手动复制回中心仓库否则下次构建时修改会被覆盖。无法跟踪社区更新对于引入的第三方vendor规则直接复制意味着你冻结了它的版本无法通过git pull轻松获取作者的更新。灵活性差难以实现“按需组合”。比如你可能希望在工作项目中使用全套MCP服务器而在个人小项目里只启用基础功能。直接复制需要维护多套完整的文件。cdbattags/ai采用的“源码 - 构建 - 链接”模式完美解决了这些问题src/目录是你的创作区所有改动在这里进行受Git管理。vendor/目录是社区素材库通过Git Submodule引入你可以随时更新子模块来获取社区的最新成果。link.ts脚本是构建引擎它根据vendor.json的声明“采摘”cherry-pick你想要的社区规则将它们和你的src/内容一起按照每个工具要求的目录结构在dist/name/下生成一棵由符号链接构成的树。这些符号链接指向src/和vendor/的真实文件。安装步骤创建最终链接最后脚本在~/.cursor/等位置创建指向dist/目录下对应文件的符号链接。这样做的好处是dist/目录本身也是由Git跟踪的但跟踪的是链接关系。你在GitHub上查看dist/cdbattags/时看到的是所有链接解析后的完整文件树非常直观。而真正的文件始终只在src/和vendor/里有一份。2.2 目录结构一切皆清晰项目的目录结构是其设计思想的直观体现ai/ ├── src/ # 你的专属配置源码 │ ├── rules/ # Cursor规则 (.mdc文件) │ ├── skills/ # 跨工具技能 (SKILL.md) │ ├── cursor/commands/ # Cursor专属命令 │ ├── claude/ # Claude Code配置 │ ├── opencode/ # OpenCode配置 │ └── mcp/ # MCP服务器配置 │ ├── servers/ # 单个服务器定义 │ └── profiles/ # 服务器组合配置文件 ├── vendor/ # Git子模块社区配置库 ├── vendor.json # 声明要从vendor中选取哪些内容 ├── dist/ # 构建输出目录 │ └── cdbattags/ # 示例用户构建结果全是符号链接 │ ├── cursor/ - ~/.cursor/ │ ├── claude/ - ~/.claude/ │ └── opencode/ - ~/.config/opencode/ └── link.ts # 构建和安装脚本一个关键细节dist/cdbattags/是被Git跟踪的。这非常聪明它让项目的README页面可以直接展示最终生成的、可用的配置是什么样子相当于一份活的文档。而当你fork这个项目后你可以用--name参数构建属于自己的dist/myname/目录这个目录会被.gitignore忽略不会污染原项目。2.3 MCP配置的模块化设计像搭积木一样组合功能MCPModel Context Protocol是让AI模型安全、可控地使用外部工具和数据的协议。不同的开发场景需要不同的MCP服务器。这个项目对MCP配置的处理体现了极强的工程化思维。它没有把所有的MCP服务器配置堆在一个文件里而是分成了两层基础单元src/mcp/servers/每个MCP服务器如playwright用于浏览器自动化docker用于容器管理github用于仓库操作都有自己独立的配置定义。组合配置src/mcp/profiles/通过“配置文件”来组合这些服务器。例如一个名为web的配置文件可能包含base基础套件加上playwright而backend配置文件则包含base加上docker和sentry。当你运行node link.ts build --mcp web时构建脚本会根据web这个配置文件只链接相关的MCP服务器定义到最终配置中。这意味着你可以为前端、后端、数据分析等不同工作区快速切换完全不同的AI能力上下文而无需手动编辑繁琐的JSON配置。实操心得这种“基础组件配置文件”的模式非常适用于管理不断增长的MCP生态。当有新的、好用的MCP服务器出现时你只需要在servers/下添加它的定义然后在需要的profiles/里引用它即可不会影响其他配置。3. 从零开始部署与深度配置指南3.1 环境准备与项目克隆首先确保你的系统满足基础要求。项目需要Node.js 22.6或更高版本因为它依赖原生的TypeScript执行能力即node可以直接运行.ts文件。你可以通过node -v检查版本。# 克隆项目注意使用 --recurse-submodules 参数 # 这个参数至关重要它会自动初始化并更新 vendor/ 目录下的所有Git子模块。 git clone --recurse-submodules gitgithub.com:cdbattags/ai.git ~/ai # 进入项目目录 cd ~/ai # 安装项目依赖link.ts脚本可能需要的工具包 npm install注意事项如果你克隆时忘记了--recurse-submodules参数会发现vendor/目录是空的。此时需要执行以下命令来补救git submodule init git submodule update社区规则和技能都存放在这些子模块中缺少它们构建过程将无法“采摘”到任何第三方内容。3.2 首次构建与全局安装项目提供了高度自动化的脚本。最简单的使用方式是直接运行node link.ts不带任何参数这将执行默认的“构建安装全部”操作。# 在项目根目录下执行 node link.ts这条命令背后发生了两件事构建阶段脚本会以默认名称cdbattags在dist/目录下创建配置树。它会读取src/和vendor.json在dist/cdbattags/下创建指向源文件的符号链接。安装阶段脚本会在你的用户主目录~下创建必要的符号链接将dist/cdbattags/cursor链接到~/.cursor/rules或其他对应位置使得Cursor等工具能直接读取到配置。强烈建议在第一次正式运行前先进行预演node link.ts --dry-run--dry-run干跑参数会让脚本打印出它将要执行的所有操作创建哪些链接链接到哪里但不会实际修改文件系统。这是避免操作失误的黄金法则。3.3 个性化你的配置空间你很可能不想使用默认的cdbattags这个名称。作为项目的分叉者forker或深度使用者你应该创建属于自己的配置空间。# 使用你自己的名字例如“myconfig”来构建配置 node link.ts build --name myconfig # 将构建好的“myconfig”配置安装到系统 node link.ts install --name myconfig执行完上述命令后你会发现在dist/目录下新生成了一个myconfig/文件夹里面是你的个性化配置树。而link.ts install命令则会根据--name myconfig参数将dist/myconfig/下的内容链接到你的家目录。这里有一个精妙的设计项目本身的Git仓库只跟踪dist/cdbattags/作为示例。当你用--name指定其他名称时生成的dist/myname/目录会被自动添加到.gitignore中。这意味着你可以在不污染上游仓库的情况下自由地管理和版本控制你自己的配置。你可以将自己的dist/myname/目录添加到你自己fork的仓库中进行管理。3.4 按需安装与工作区模式你并非必须一次性安装所有工具的配置。link.ts允许你单独为某个工具安装配置。# 只安装Cursor的配置 node link.ts install cursor # 只安装Claude Code的配置 node link.ts install claude # 安装Cursor和OpenCode的配置 node link.ts install cursor opencode工作区项目级安装模式是这个项目的一大亮点。有时你可能希望某个特定项目使用一套特殊的AI规则而不是全局配置。例如一个开源项目可能希望所有贡献者使用统一的代码生成规则。# 进入你的项目目录 cd /path/to/your-project # 将AI配置安装到当前项目而非用户主目录 npx cdbattags/ai install --workspace这条命令做了以下几件事它使用npx直接运行仓库的脚本假设已发布到npm。--workspace参数指示脚本在当前工作目录cwd下创建.cursor/、.claude/等文件夹并建立指向你dist/name/目录的符号链接。这样当你在这个项目目录下使用Cursor时它会优先读取项目内的.cursor/rules/从而实现项目级别的配置覆盖。你可以用它来分享团队规范或者为某个特定技术栈如Rust项目、React项目配置专属的AI助手行为。4. 核心配置详解规则、技能与MCP4.1 编写与理解Cursor规则.mdcCursor规则文件.mdc本质上是给AI助手的行为指令集。在src/rules/目录下每个.mdc文件都代表一条独立的规则。项目自带了一套非常实用的默认规则我们可以深入看几条git-commit-confirmation.mdc这条规则要求AI在每次执行git commit命令前必须获得用户的明确批准。这有效防止了AI在自动修复代码或重构时未经你审阅就提交代码的情况。其实现原理通常是在规则中设置一个触发条件当AI生成包含git commit的命令时插入一个暂停并提示用户确认的步骤。use-trash-not-rm.mdc这条规则强制AI使用trash或类似回收站功能的命令代替直接的rm -rf来删除文件。这是一个安全最佳实践避免了因AI误解而误删重要文件且无法恢复的灾难性后果。规则里可能会重写AI生成的删除命令。no-sleep-process-monitoring.mdc这条规则禁止AI在脚本中使用sleep进行轮询等待而是鼓励使用更高效的进程监控方式如wait命令或inotifywait工具。这体现了对生成代码质量和效率的重视。如何添加自己的规则在src/rules/目录下创建一个新文件例如my-awesome-rule.mdc。使用Markdown语法编写规则描述。一个简单的规则可能长这样# 优先使用异步/等待语法 在编写JavaScript/TypeScript代码时如果遇到Promise操作必须优先使用 async/await 语法而不是 .then().catch() 链式调用除非有明确的理由如需要同时发起多个请求。 理由async/await 语法更清晰更易于阅读和错误处理。保存文件然后重新运行node link.ts build --name yourname和node link.ts install你的新规则就会生效。4.2 创建跨工具技能SKILL.md技能Skills是比规则更复杂、更强大的指令集通常用于指导AI完成一个多步骤的、特定的任务。它们被设计成可以在不同AI工具间共享。技能文件放在src/skills/目录下命名为SKILL.md。项目内置的技能展示了其深度github-repo-triage.skill.md这个技能可能定义了一整套处理GitHub Issue和PR的标准化流程。例如如何给Issue打标签如何回复常见问题模板如何进行Cherry-pick操作等。AI在激活此技能后处理仓库维护任务时会更加规范和专业。process-monitoring.skill.md详细阐述了如何不通过sleep来监控进程、文件或端口。它可能提供了多种实现方案如使用timeout命令结合循环检查或使用fuser、lsof等工具并解释了每种方案的适用场景。技能与规则的区别规则通常是禁止性或强制性的单点约束“不要这样做要那样做”而技能是赋能性的任务指南“如果你想做X可以按照Y这个流程其中要注意A、B、C点”。技能文件的结构更自由可以包含用例、代码片段、常见陷阱等丰富内容。4.3 管理MCP服务器与配置文件MCP服务器的配置是AI能力扩展的核心。在src/mcp/servers/目录下每个服务器都有一个对应的JSON配置文件。例如一个playwright.mcp.json文件可能包含以下关键内容{ mcpServers: { playwright: { command: npx, args: [-y, modelcontextprotocol/server-playwright], env: { BROWSER: chromium } } } }配置文件Profiles的魔力在于组合。查看src/mcp/profiles/目录你会看到像base.json、web.json这样的文件。web.json的内容可能非常简单{ extends: base, servers: [playwright] }这表示web配置继承了base配置中的所有服务器并额外添加了playwright服务器。操作流程当你执行node link.ts build --mcp web时脚本会 a. 读取base.json获取基础服务器列表如context7,memory等。 b. 添加playwright服务器。 c. 将所有涉及的服务器配置从src/mcp/servers/合并生成一个最终的mcp.json文件并链接到dist/name/目录下的合适位置。这样当你为Web开发项目启动AI会话时AI就具备了浏览器自动化的能力可以帮你测试页面、截图甚至执行用户交互脚本。4.4 集成社区资源Vendor Submodules项目的vendor/机制让你能轻松享用社区智慧。目前它集成了像hutchic/.cursor这样的优秀配置库。工作原理vendor/目录通过Git Submodule链接到外部仓库。vendor.json文件是一个“采摘清单”它指定了从每个子模块仓库中提取哪些具体的规则或技能文件。构建时link.ts脚本会根据vendor.json将指定的文件从vendor/目录链接到dist/目录中对应的位置。例如vendor.json可能包含{ hutchic/.cursor: [ rules/karpathy-guidelines.mdc, skills/logging-best-practices.skill.md ] }这意味着尽管hutchic/.cursor子模块里可能有几十个文件但只有karpathy-guidelines.mdc这条规则和logging-best-practices.skill.md这个技能会被纳入你的构建。添加新的社区资源添加子模块git submodule add https://github.com/xxx/yyy.git vendor/yyy编辑vendor.json添加你想要“采摘”的文件路径。运行node link.ts build。脚本会自动处理链接让你无缝使用新集成的社区配置。5. 高级用法、问题排查与维护心得5.1 链接失效与修复符号链接是项目的核心但也可能因移动目录或误删除而断裂。如果发现AI工具不读取你的规则了首先检查链接状态。# 检查 ~/.cursor/rules 是否是一个有效的符号链接以及它指向何处 ls -la ~/.cursor/rules # 如果链接断裂显示红色或指向不存在的路径可以清理后重新安装 node link.ts install --clean # 移除所有由本项目创建的符号链接 node link.ts install # 重新建立链接踩坑记录有时在Windows的WSL或某些Linux发行版上如果dist/name/目录是通过NTFS或网络驱动器挂载的创建跨文件系统的符号链接可能需要管理员权限或特殊参数。如果遇到“Operation not permitted”错误可以尝试在link.ts的symlink函数调用中寻找是否使用了fs.symlink并确认其兼容性。通常项目脚本已经考虑了跨平台性。5.2 解决工具间的配置冲突当你同时使用全局安装和工作区安装时可能会遇到配置优先级问题。通常AI工具的读取顺序是项目级配置 用户级配置 默认配置。症状你在项目A中设置了特殊规则但AI似乎还在使用全局规则。排查进入项目A目录检查是否存在.cursor/rules目录以及里面的规则文件是否生效。用node link.ts install --workspace --dry-run查看工作区链接是否正确建立。解决确保工作区安装命令是在项目根目录执行的。有时需要重启你的AI编程工具如Cursor以使其重新加载配置文件。5.3 更新社区子模块社区规则在不断改进你需要定期更新vendor/下的子模块来获取这些改进。# 进入项目根目录 cd ~/ai # 更新所有子模块到其远程仓库的最新提交 git submodule update --remote # 如果子模块有嵌套的子模块使用递归更新 git submodule update --remote --recursive # 更新后重新构建你的配置以应用更改 node link.ts build --name myconfig node link.ts install --name myconfig注意更新子模块可能会引入破坏性变更。建议在更新后仔细查看git diff的变化或者先在测试配置中构建确认无误后再应用到主配置。5.4 贡献与分享你的配置如果你创建了非常有用的规则或技能可以考虑回馈社区。优化你的src/内容确保你的规则和技能描述清晰、通用性强。考虑发布为独立的子模块如果你的配置集合足够丰富可以创建一个独立的Git仓库来存放它们然后通过vendor.json引入。这样其他人就可以像你引入hutchic/.cursor一样引入你的配置。提交Pull Request如果你认为你的某个配置对原项目cdbattags/ai的默认集合src/下的内容有普遍价值可以向原项目提交PR。但请注意这通常要求你的贡献具有很高的通用性和代码质量。5.5 性能与兼容性考量启动速度由于配置全部通过符号链接引用AI工具在启动时读取配置的速度与直接读取文件无异没有性能损耗。工具兼容性该项目主要面向支持文件系统配置的AI编程工具Cursor, Claude Code, OpenCode。对于仅支持通过UI界面配置的AI工具此方案不适用。版本控制将整个ai目录置于Git控制下可以完美追溯每一次配置的变更。你可以为不同的配置状态打上标签例如v1.0-web-profile、v1.1-add-new-rule方便回滚。经过数月的使用我将自己的开发习惯、团队规范以及对AI助手的期望都固化到了这套配置体系中。它不仅仅是一个配置管理工具更像是一个不断成长、可编程的“AI助手行为引擎”。每次当我发现AI在某些重复性任务上表现不佳时我的第一反应不再是去手动纠正它而是思考“我能否写一条规则或一个技能让AI以后永远正确地处理这类问题” 这种从“使用工具”到“塑造工具”的转变极大地提升了我和AI协同编程的效率和愉悦感。如果你也厌倦了在不同AI工具间反复进行相同的配置强烈建议你尝试建立这样一个属于你自己的“AI配置中心”这可能是你对AI编程工作流最具杠杆效应的投资之一。