给 AI 工具做分层安装：渐进式配置的工程哲学
我曾经对 AI 工具集的配置有一种懒惰的直觉：全部装上，用到哪个再说。
这在工具数量少的时候没问题。但当 skill、rule、prompt 的数量超过二三十个，问题就出现了——上下文被大量不相关的 skill 填满，模型在选「该激活哪个」时产生歧义，某个 skill 引用了另一个未安装的 skill 导致行为奇怪。更隐蔽的是：你不知道哪些 skill 之间存在依赖关系，也不知道「project-level」的安装是否引用了只存在于 user-level 的路径。
这些问题让我开始认真对待「如何安装 AI 工具集」这件事。
分层是第一道决策
配置的第一步不应该是「装什么」，而是「装在哪一层」。
User-level（~/.claude/）和 project-level（.claude/）不只是路径差异，它们代表两种不同的作用域语义：
- User-level 是你跨所有项目都需要的通用能力——代码风格、安全审查、通用写作
- Project-level 是这个仓库特有的上下文——这个项目的技术栈约束、领域规则、团队约定
把通用 skill 堆在 project-level 是最常见的错误，不仅污染了仓库，还让其他协作者困惑。反过来，把高度项目相关的规则放 user-level，会在你切到另一个项目时产生干扰。
每个 skill 和 rule 安装前，先问自己：「这条规则只在当前项目有意义，还是我在所有项目里都应该遵守？」作用域对了，后续维护成本会低很多。
核心包与长尾包的分离
第二个关键决策是：不要一次性安装所有东西。
一个成熟的工具集可以分成两层：
核心包——无论做什么项目都需要的能力。TDD 流程、代码审查规范、安全检查清单、研究辅助、上下文压缩策略。这些应该优先安装，且几乎不需要调整。
领域包——只在特定技术栈下有意义。Django 的查询优化模式、Spring Boot 的分层架构规范、ClickHouse 的写入性能调优。这类 skill 内容再好，装在一个纯前端项目里也是噪音。
分开维护的好处是：核心包可以稳定下来，不需要频繁调整；领域包随项目新增和弃用，不影响核心。
验证是安装的一部分
我之前的习惯是安装完就算完了。后来发现这留下了一类隐性 bug：skill A 在内部引用了 skill B 的路径，但 skill B 没有被一起安装。表面上什么都正常，但在某个特定场景下，skill A 的行为会悄悄降级。
现在我把验证作为安装流程的强制步骤：
- 列出所有已安装文件，确认路径存在
- 扫描
.md文件中的路径引用，标出指向未安装依赖的引用 - 对 project-level 安装额外检查是否引用了
~/.claude/的路径——这类引用在别人的机器上会直接断掉
这三步的成本很低，但能提前暴露几乎所有的配置完整性问题。
优化是另一个维度
验证解决的是「能不能用」，优化解决的是「值不值得用」。
一个通用 skill 往往包含大量针对不同场景的分支描述。如果你的项目只用 PostgreSQL，那 skill 里关于 MySQL 和 SQLite 的部分就是纯噪音——它们消耗上下文，降低相关内容的注意力权重。
安装后对 skill 做针对性裁剪，把不适用的章节删掉，把路径引用改成项目实际结构，效果往往好过把一个「全能」skill 原封不动地用下去。
这个思路可以推广：工具的价值不在于覆盖的功能多，而在于与当前场景的匹配度。越精准的 skill，模型激活它的信号越清晰，执行也越稳定。
一句话心法
安装不是复制，是一次配置决策——分层、选择、验证、裁剪，每步都在为后续的可维护性投资。