基于符号链接与Git的AI编码助手统一配置管理方案

1. 项目概述：一个为多款AI编码助手统一管理配置的“中央厨房”

如果你和我一样，同时在使用 Claude Code、Codex CLI 和 Cursor 这几款 AI 编码助手，那你一定体会过那种“精神分裂”般的配置痛苦。每个工具都有自己的技能（Skills）、命令（Commands）、规则（Rules）和 MCP（Model Context Protocol）服务器配置，它们散落在各自不同的目录里。今天在 Cursor 里调教好一个写代码的规则，明天在 Claude Code 里又得重新来一遍；在 Codex CLI 里精心打磨了一个项目分析技能，却没法直接分享给其他工具使用。这种重复劳动和配置割裂，严重拖慢了我和 AI 搭档的工作流效率。

于是，我动手搭建了这个multi-agent-dotfiles项目。它的核心思想很简单：建立一个统一的“中央仓库”，集中管理所有与 AI 助手相关的配置，然后通过符号链接（symlink）的方式，将这些配置“分发”到各个工具指定的目录下。你可以把它想象成一个为多个 AI 助手服务的“中央厨房”，所有菜谱（配置）都在这里编写和存储，然后根据每个“餐厅”（工具）的菜单要求，将对应的菜品（配置文件）送达。

这个方案完美解决了我的几个痛点：

1. 配置同步：一次编写，多处生效。无论是编码规范、常用指令还是自定义技能，只需在中心仓库维护一份。
2. 版本控制：所有配置通过 Git 管理，修改历史清晰可查，随时可以回滚到任意版本。
3. 环境一致性：在新电脑上，只需克隆仓库并运行一个安装脚本，就能瞬间复现我熟悉的所有 AI 助手环境。
4. MCP 统一管理：将不同工具所需的 MCP 服务器配置集中管理，并通过环境变量安全地注入密钥，避免了敏感信息泄露。

接下来，我将详细拆解这个项目的设计思路、具体实现，并分享我在搭建和使用过程中踩过的坑和总结的经验。无论你是 AI 编程的重度用户，还是刚刚开始接触这些工具，相信这套方案都能让你的开发体验提升一个档次。

2. 核心设计思路与架构解析

2.1 为什么选择符号链接（Symlink）作为核心机制？

在决定如何统一管理配置时，我评估了几种方案：直接复制文件、使用环境变量指向公共目录、或者用脚本动态生成配置。最终，符号链接胜出了，原因如下：

• 实时性：符号链接创建的是一个指向源文件的“快捷方式”。当你在中心仓库（~/dotfiles）修改了某个技能文件，所有通过符号链接使用它的 AI 工具都会立刻“看到”这个修改，无需任何手动同步操作。这是复制文件方案无法比拟的。
• 低开销：符号链接本身只占用极小的磁盘空间（仅存储一个路径信息），不会造成数据冗余。这对于可能包含大量示例代码的技能文件来说非常友好。
• 原生兼容：Claude Code、Codex CLI、Cursor 这些工具在设计时，就是去特定目录读取特定格式的文件（如~/.cursor/rules/下的.mdc文件）。使用符号链接，可以让工具“无感知”地使用中心化配置，完全符合它们的原生行为逻辑，避免了 hack 工具内部逻辑的风险。
• 易于维护：如果我想临时为某个工具禁用某个技能，只需删除对应的符号链接，而不会影响中心仓库的源文件和其他工具的链接。恢复也只需要重新创建链接。

注意：符号链接在 Windows 原生环境（如 PowerShell, CMD）中行为可能与类 Unix 系统（Linux, macOS, WSL）不同。因此，本项目明确将WSL (Windows Subsystem for Linux)作为 Windows 下的标准运行环境，以确保符号链接和其他 shell 脚本的可靠运行。

2.2 目录结构设计：分而治之的配置管理

项目的目录结构是经过深思熟虑的，旨在清晰地区分不同类型的配置，并处理好共享与独占的关系。

dotfiles/ ├── rules/ # 规则文件：定义AI的行为准则和上下文 │ └── base.md # 基础规则，被链接到各工具对应的规则文件 ├── skills/ # 技能库：可复用的、具体的任务指令集（三者共享） ├── commands/ # 命令/提示词：快捷命令或复杂提示模板 ├── claude_plugins/ # Claude Code 专属插件配置 ├── mcp/ # MCP 服务器配置中心 │ ├── servers.json # 服务器定义（使用 ${ENV_VAR} 占位符） │ ├── secrets.json # 实际密钥（应加入 .gitignore） │ ├── secrets.json.example # 密钥文件模板 │ └── apply.sh # 将 servers.json 和 secrets.json 合并并部署到各工具 └── setup.sh # 一键安装与初始化脚本

关键设计点解析：

1. rules/与skills/的分离：

   • 规则 (Rules)更像是“宪法”或“公司文化手册”，它定义了 AI 助手在互动中应遵循的高级原则、思考框架和身份定位。例如：“你是一位资深的全栈工程师，擅长编写简洁、可维护的代码。” 这类内容通常比较稳定，一份基础规则足以覆盖多个工具。
   • 技能 (Skills)则是具体的“工作说明书”或“标准作业程序”，例如“如何为 React 组件编写单元测试”、“如何优化 Dockerfile 构建层”。技能更具体、更可复用，因此放在skills/目录下供所有工具共享是最合理的。

2. claude_plugins/的独立性： 只有 Claude Code 拥有官方的插件系统。这些插件的配置（如启用状态、自定义参数）是 Claude Code 独有的，无法与其他工具共享。因此为其设立独立目录，并通过符号链接挂载到~/.claude/plugins/。

3. MCP 配置的安全与灵活处理： MCP 配置是项目的难点和亮点。servers.json定义了服务器的结构（如类型、命令、参数），但其中包含的 API Key、访问令牌等敏感信息，绝不能提交到公开的 Git 仓库。

   • servers.json：使用${ENV_VAR}这样的占位符来标记需要注入密钥的位置。这个文件可以安全地提交。
   • secrets.json：一个本地文件，存储着与servers.json中占位符对应的真实密钥值。这个文件必须被.gitignore忽略。
   • apply.sh：这个脚本的作用是充当“装配工”，读取secrets.json中的真实值，替换掉servers.json中的占位符，生成每个 AI 工具所需的、包含真实密钥的最终配置文件（如~/.claude.json），并放置到正确的位置。

2.3 多工具路径映射表：建立连接桥梁

设计好中心仓库的结构后，下一步就是为每个 AI 工具建立与之连接的桥梁。下表是整套系统的“路由表”，它定义了源文件（在~/dotfiles/中）和目标链接位置（各工具的标准配置目录）的对应关系。

解读与注意事项：

• 路径差异：不同工具对同类配置的存放路径和文件名要求不同。例如，基础规则在 Claude Code 里是放在家目录下的CLAUDE.md文件，而在 Cursor 里则是~/.cursor/rules/目录下的base.mdc文件。setup.sh脚本需要精确处理这些差异。
• 支持度差异：Codex CLI 目前没有官方插件系统，所以claude_plugins与之无关。Cursor 的 MCP 支持可能还在演进中，因此表中标注为“暂不支持”，需要关注其官方更新。
• 技能目录的链接：对于skills/，我们不是链接单个文件，而是将整个~/dotfiles/skills/目录链接到每个工具的 skills 目录。这样，在中心仓库添加的任何新技能，都会自动在所有工具中生效。

3. 从零开始：完整部署与初始化实操

3.1 环境准备与前置检查

在运行任何脚本之前，请确保你的系统满足以下要求。这一步的检查能避免很多后续的诡异错误。

1. Git：这是管理配置仓库的基础。在终端输入git --version确认已安装。
2. Python 3：部分 MCP 服务器（如连接 Jira、Notion 的服务器）可能是用 Python 编写的，apply.sh脚本也可能依赖 Python 进行 JSON 处理。运行python3 --version或python --version检查。
3. Shell 环境：本项目脚本主要针对bash或zsh编写。macOS 和主流 Linux 发行版通常已内置。通过echo $SHELL查看当前 shell。
4. Windows 用户必读：
   • 你必须安装并设置好WSL 2（推荐 Ubuntu 发行版）。在 PowerShell（管理员）中运行wsl --install -d Ubuntu即可。
   • 所有操作都将在 WSL 的终端中进行。请确保你能熟练打开 WSL 终端。
5. AI 工具安装：
   • Claude Code：从官网下载安装。
   • Codex CLI：通常可通过pip install openai-codex或从 GitHub Release 页面安装。
   • Cursor：从官网下载安装。
   • 不必担心工具还没配置，我们的setup.sh会帮你创建必要的目录。

3.2 执行一键初始化脚本

这是最核心的一步。setup.sh脚本承担了所有繁重的工作。

# 1. 克隆仓库到你的家目录。这是推荐位置，便于管理。 git clone https://github.com/GeonheeYe/multi-agent-dotfiles.git ~/dotfiles # 2. 进入仓库目录 cd ~/dotfiles # 3. 赋予脚本执行权限（通常克隆下来已有，但确认一下更安全） chmod +x setup.sh # 4. 运行初始化脚本 ./setup.sh

setup.sh在背后为你做了什么？（深度解析）

这个脚本不是简单的复制粘贴，它是一套完整的环境部署方案。了解其步骤有助于排查问题：

1. 创建符号链接：

   • 根据上一节的路径映射表，为每个已检测到的工具创建对应的配置目录（如~/.claude,~/.cursor）。
   • 在这些目录中，为skills,commands,plugins等创建指向~/dotfiles下对应源目录的符号链接。
   • 将rules/base.md链接到~/CLAUDE.md,~/AGENTS.md等特定文件。

   • 实操心得：脚本会使用ln -sf命令创建符号链接。-s表示创建软链接，-f表示如果目标已存在则强制覆盖。如果你之前有自定义配置，请务必先备份。

2. 处理 MCP 配置：

   • 检查mcp/secrets.json文件是否存在。如果不存在，它会复制secrets.json.example作为模板，并提示你填写真实密钥。
   • 运行mcp/apply.sh，该脚本会将servers.json和secrets.json合并，生成包含真实密钥的、针对 Claude Code 和 Codex CLI 的配置文件，并放置到~/.claude.json和~/.codex/config.toml。

3. 安装命令行工具与包装脚本：

   • 在~/bin目录下创建一系列便捷的包装脚本（wrapper scripts）。例如，一个名为claude的脚本，可能只是简单地调用claude-code命令，但会确保在正确的项目上下文下运行。
   • 将~/bin添加到你的 shell 配置文件（~/.zshrc或~/.bashrc）的PATH环境变量最前面，确保你自定义的脚本优先级最高。

4. 配置 Shell 别名（Aliases）：

   • 在 shell 配置文件中添加极其有用的别名，这是提升效率的关键：

     # 示例：添加到 ~/.zshrc 末尾的内容 alias ccd='cd ~/dotfiles' # 快速进入dotfiles目录 alias ccr='cd ~/dotfiles && git pull && ./setup.sh' # 拉取更新并重新设置 alias cdd='cd $(find ~/projects -type d -maxdepth 2 | fzf)' # 使用fzf模糊搜索进入项目目录（需安装fzf） alias cdd-work='cd ~/work' # 快速进入工作目录 alias cu='cursor .' # 在当前目录打开Cursor

   • 这些别名让你用最短的指令操作环境和工具。

5. 设置 Claude Code 会话钩子（Hook）：

   • 这是一个高级技巧。脚本会配置 Claude Code，使其在每次启动新会话时，自动运行一个命令（通常是~/dotfiles/scripts/sync-dotfiles.sh）。
   • 这个钩子脚本会检查~/dotfiles仓库是否有远程更新（git fetch），如果本地落后于远程，则自动拉取更新并重新运行setup.sh来应用最新配置。这实现了配置的“静默同步”，你打开 Claude Code 时，用的永远是最新的团队共享配置。

3.3 初始化后验证与首次使用

脚本运行完毕后，务必关闭当前终端窗口，重新打开一个新的终端。这是为了让新配置的PATH和别名生效。

然后，进行以下验证：

# 验证别名是否生效 cdd-work # 应该能跳转到你的工作目录 ccd # 应该能跳转到 ~/dotfiles 目录 # 验证符号链接 ls -la ~/.claude/skills # 应该显示是一个指向 ~/dotfiles/skills 的符号链接 ls -la ~/CLAUDE.md # 应该显示是一个指向 ~/dotfiles/rules/base.md 的符号链接 # 验证MCP配置 cat ~/.claude.json | head -20 # 查看生成的Claude配置，应该能看到完整的MCP服务器配置，且没有 ${ENV_VAR} 这样的占位符。

现在，你可以打开 Claude Code 或 Cursor，检查设置界面，通常能在“Skills”、“Rules”或“MCP Servers”部分看到已经被加载的配置。尝试触发一个你定义在skills/中的技能，看看 AI 助手是否能正确响应。

4. 日常使用、维护与进阶技巧

4.1 如何添加和管理自定义技能？

这是最常用的操作。所有技能都应存放在中心仓库的~/dotfiles/skills/目录下，每个技能一个独立的子目录。

添加一个新技能的标准化流程：

# 1. 进入dotfiles目录（使用我们设置的别名） ccd # 2. 创建技能目录，建议使用kebab-case命名（如react-testing） mkdir -p skills/react-component-test # 3. 创建技能定义文件 SKILL.md cat > skills/react-component-test/SKILL.md << 'EOF' --- name: React Component Test Generator description: 根据给定的React组件文件，自动生成完整的Jest + React Testing Library测试用例。 tags: [react, testing, jest, frontend] --- 你是一个精通React前端测试的专家。当用户提供一个React组件文件（函数组件或类组件）时，你需要： 1. **分析组件**：识别组件的props、状态、生命周期方法（如有）、事件处理函数和渲染逻辑。 2. **生成测试套件**：创建一个同名的 `.test.jsx` 或 `.test.tsx` 文件。 3. **编写测试用例**： * **渲染测试**：验证组件能否正常渲染，不抛出错误。 * **Props测试**：测试组件对不同props的响应。 * **用户交互测试**：使用 `userEvent` 模拟点击、输入等操作，断言组件状态或UI的变化。 * **异步操作测试**：如果组件包含API调用，使用 `jest.mock` 和 `waitFor` 进行测试。 4. **遵循最佳实践**： * 使用 `describe` 和 `it` 组织测试。 * 查询元素优先使用 `getByRole`，其次是 `getByTestId`。 * 每个测试用例保持独立，使用 `beforeEach` 进行公共设置。 * 断言语句清晰明确。 **示例输出格式：** ```javascript import { render, screen, fireEvent } from '@testing-library/react'; import userEvent from '@testing-library/user-event'; import MyComponent from './MyComponent'; describe('MyComponent', () => { it('renders without crashing', () => { render(<MyComponent />); expect(screen.getByRole('heading')).toBeInTheDocument(); }); // ... 更多测试用例 });

EOF

4. 提交并推送到远程仓库（假设你已配置Git远程仓库）

git add skills/react-component-test/ git commit -m "feat: add React component test generation skill" git push origin main

**技能设计的经验之谈：** * **结构化元信息**：`---` 之间的 YAML 前端元信息（`name`, `description`, `tags`）非常重要。好的描述能帮助 AI 在合适的场景下自动选择或推荐这个技能。 * **提供清晰上下文和约束**：在描述中明确技能的角色、输入、输出和边界。告诉 AI“你是什么专家”、“用户会给你什么”、“你需要输出什么”、“遵循什么规范”。 * **包含示例**：在技能描述末尾提供一个或多个具体的输入输出示例，这是 few-shot learning 的关键，能极大提升 AI 响应的准确性和格式一致性。 * **原子化**：一个技能最好只做一件事，并把它做好。不要创建“万能开发助手”这种大而全的技能，效果往往不好。将其拆分为“代码审查”、“API 生成”、“错误处理”等多个原子技能。 ### 4.2 如何安全地管理 MCP 服务器与密钥？ MCP 是让 AI 助手连接外部服务（如数据库、GitHub、Jira）的桥梁。安全管理其配置是本项目的重点。 **1. 添加一个新的 MCP 服务器（以 GitHub 为例）：** 假设我们想添加一个官方的 `github` MCP 服务器。 ```bash # 1. 编辑 servers.json，添加服务器定义 ccd vim mcp/servers.json

在servers.json的servers数组中添加一个新对象：

{ "servers": [ // ... 其他已有服务器配置 { "name": "github", "type": "command", "command": "npx", "args": [ "-y", "@modelcontextprotocol/server-github" ], "env": { "GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_TOKEN}" } } ] }

• 关键点：我们使用${GITHUB_TOKEN}作为环境变量占位符，而不是直接写入令牌。

2. 在secrets.json中配置真实的令牌：

# 编辑 secrets.json （如果不存在，从 secrets.json.example 复制） vim mcp/secrets.json

确保secrets.json中有对应的键值对：

{ "GITHUB_TOKEN": "ghp_yourActualGitHubPersonalAccessTokenHere" }

重要安全警告：secrets.json文件绝对不能提交到 Git！请确保它在.gitignore列表中。项目初始的.gitignore应该已经包含了它。

3. 应用 MCP 配置：

# 运行 apply.sh 脚本，它会合并配置并部署 ./mcp/apply.sh

apply.sh的工作原理揭秘：这个脚本通常是一个 Python 或 Node.js 脚本，它执行以下操作：

1. 读取servers.json。
2. 读取secrets.json。
3. 遍历servers.json中的每个服务器配置，查找所有${ENV_VAR}格式的字符串。
4. 用secrets.json中对应的值替换这些占位符。
5. 根据当前环境（检测哪些 AI 工具已安装），生成对应格式的配置文件（如 Claude 的 JSON 格式，Codex 的 TOML 格式）。
6. 将生成的最终配置文件输出到目标位置（~/.claude.json,~/.codex/config.toml）。

4. 提交公开的服务器定义：

# 只提交不包含密钥的 servers.json git add mcp/servers.json git commit -m "feat(mcp): add github server configuration" git push

这样，你的团队其他成员克隆仓库后，只需要创建自己的secrets.json并运行apply.sh，就能安全地使用相同的 MCP 服务器定义了。

4.3 在多台机器间同步配置

这是本方案最大的优势之一。假设你在公司的台式机和家里的笔记本上都部署了这套系统。

1. 在一台机器上做出修改（如新增一个技能）：

cd ~/dotfiles # ... 创建并编辑新技能 ... git add . git commit -m "feat: add database migration review skill" git push origin main

2. 在另一台机器上获取更新：你有两种方式：

• 手动同步：运行~/dotfiles/scripts/sync-dotfiles.sh（如果已安装）。这个脚本会拉取远程更新，并判断是否需要重新运行setup.sh来更新符号链接和配置。
• 自动同步（推荐）：得益于之前setup.sh设置的 Claude CodeSessionStart Hook，当你在这台机器上打开 Claude Code 并开始一个新会话时，它会自动触发同步脚本。你会在 Claude Code 的日志或输出中看到类似“Dotfiles updated and applied”的消息。

3. 同步脚本的智能逻辑：一个健壮的sync-dotfiles.sh脚本应该包含以下逻辑：

#!/bin/bash cd ~/dotfiles # 获取远程更新信息，但不合并 git fetch origin # 检查本地分支是否落后于远程分支 if [ $(git rev-parse HEAD) != $(git rev-parse origin/main) ]; then echo "Dotfiles are out of sync. Pulling latest changes..." # 暂存本地可能的未提交修改（如果有自定义的secrets.json等） git stash # 拉取更新 git pull origin main # 重新运行安装脚本以应用新配置 ./setup.sh echo "Dotfiles have been updated and applied." git stash pop 2>/dev/null || true # 尝试恢复暂存的修改 else echo "Dotfiles are already up to date." fi

这个逻辑确保了只有在配置实际发生变更时，才会执行耗时的setup.sh重装过程。

5. 常见问题排查与实战经验

即使设计再完善，在实际操作中也会遇到各种问题。以下是我在长期使用中总结的“排坑指南”。

5.1 符号链接相关的问题

问题：AI 工具提示“找不到技能”或规则未生效。

• 检查1：链接是否存在且有效

  ls -la ~/.cursor/skills # 应该显示类似：skills -> /home/yourname/dotfiles/skills # 如果显示红色或报错，说明链接损坏（源目录被移动或删除）。

• 检查2：链接指向的源路径是否正确

  readlink -f ~/.cursor/skills # 应该输出 /home/yourname/dotfiles/skills 的绝对路径。 # 如果不正确，需要删除错误链接并重新创建。 rm ~/.cursor/skills # 删除损坏的链接 ln -s ~/dotfiles/skills ~/.cursor/skills # 重新创建

• 检查3：AI 工具是否在读取正确的位置
  • 查阅 Claude Code、Cursor 的官方文档，确认它们默认的技能/规则读取路径是否与我们的映射表一致。有时工具更新会改变路径。

问题：在 Windows 资源管理器中，符号链接显示为“快捷方式”且可能失效。

• 原因：WSL 内的 Linux 文件系统（如/home/yourname）与 Windows 文件系统（如C:\Users\yourname）之间的符号链接需要 WSL 的支持。在纯 Windows 路径中创建 Linux 符号链接会出问题。
• 解决方案：始终在 WSL 的终端（如 Ubuntu）中进行所有dotfiles相关的操作。确保你的项目代码和dotfiles仓库都存放在 WSL 的文件系统内（例如/home/yourname/projects,/home/yourname/dotfiles），而不是 Windows 的/mnt/c/目录下。这样能保证符号链接的完全兼容性。

5.2 MCP 配置与应用失败

问题：运行./mcp/apply.sh后，AI 工具仍然无法连接 MCP 服务器。

• 检查1：生成的配置文件是否正确

  cat ~/.claude.json | python3 -m json.tool # 格式化输出JSON，检查语法

  确认文件中所有的${ENV_VAR}占位符都已被替换为真实的、长的令牌字符串，而不是空字符串或仍保持占位符状态。
• 检查2：MCP 服务器命令是否可执行apply.sh生成的配置中，command和args指定的程序必须在系统的PATH中。例如，如果使用npx来运行一个 npm 包，请确保已安装 Node.js 和 npm。

  # 示例：检查 github server 的命令 which npx npx -y @modelcontextprotocol/server-github --help # 尝试直接运行，看是否报错

• 检查3：AI 工具是否支持并启用了 MCP
  • 进入 Claude Code 的设置 -> 开发者 -> MCP 服务器，查看列表是否已加载。
  • 查看工具的日志文件，通常会有连接 MCP 服务器失败的具体错误信息。

问题：secrets.json中的密钥被意外提交到了 Git 仓库。

• 立即行动：
  1. 将密钥立即在相关服务平台（如 GitHub, OpenAI）上吊销（Revoke）。
  2. 从 Git 历史中彻底删除该文件。这需要使用git filter-branch或 BFG Repo-Cleaner 等工具，操作复杂且会影响所有协作者的历史。最直接的方法是，将该仓库视为已泄露，创建一个新的私有仓库，并让所有成员重新克隆、重新配置secrets.json。
• 预防措施：
  • 在仓库根目录的.gitignore中，确保包含mcp/secrets.json。
  • 使用git status命令时，养成习惯先检查是否有不该跟踪的文件被意外添加。
  • 可以考虑使用pre-commithook 来检查是否试图提交包含敏感关键词的文件。

5.3 工具更新与兼容性

问题：更新 Claude Code/Cursor 后，部分配置失效。

• 可能原因：工具的新版本更改了配置文件的格式、位置或解析逻辑。
• 排查步骤：
  1. 查看官方更新日志，关注配置相关的变更说明。
  2. 暂时移除我们的符号链接，让工具生成一份默认配置。对比新旧配置格式的差异。
  3. 调整~/dotfiles中对应的源文件格式，或修改setup.sh中的链接路径。
• 经验之谈：对于规则文件（rules/base.md），尽量使用各工具都支持的通用 Markdown 语法，避免使用某个工具特有的扩展语法，以增强兼容性。

问题：Codex CLI 的 prompts 目录和 Claude Code 的 commands 目录结构要求不同。

• 现状：本方案假设它们的结构可以通用。但如果结构差异很大（例如 Codex 要求按类别分子目录，而 Claude 是平铺文件），则共享commands/目录可能会出问题。
• 解决方案：修改架构，为不同工具创建不同的命令源目录，例如commands_claude/,commands_codex/，然后在setup.sh中分别链接到对应的目标位置。这增加了维护成本，但保证了兼容性。

5.4 性能与组织优化建议

1. 技能库膨胀导致加载慢？当skills/目录下有成百上千个文件时，某些 AI 工具在启动时枚举所有技能可能会导致延迟。

• 优化方案：不要将所有技能都放在根目录。可以按语言、框架、任务类型建立子目录进行组织，例如skills/frontend/react/,skills/backend/nodejs/。大多数 AI 工具都支持递归读取子目录。

2. 想为特定项目使用特殊规则？rules/base.md是全局规则。有时某个项目有特殊的代码规范或技术栈要求。

• 解决方案：AI 工具通常支持项目级规则。你可以在项目根目录创建.clauderc、.cursorrules等文件。我们的全局规则可以作为基础，项目级规则进行覆盖或补充。你可以在rules/base.md中写明：“请优先遵循项目根目录下存在的.cursorrules文件中的规范。”

3. 团队协作时，如何管理个人偏好配置？有些配置（如 IDE 主题相关的指令、个人常用的代码片段）可能不适合推送到团队共享仓库。

• 解决方案：建立“个人层”覆盖机制。例如，在setup.sh中，可以检查是否存在~/dotfiles-local/目录。如果存在，则在创建完团队共享的符号链接后，再将个人目录下的特定文件或目录链接到更高的优先级位置（可能需要工具支持优先级顺序）。或者，更简单的方式是，个人配置完全不纳入本系统，直接在本地工具的配置目录中管理。