AI 技能生态治理：做减法比做加法难

五条治理原则#

1. 按需取用，禁止堆砌。 不因为”热门”就装。先问：这个技能解决什么具体问题？没有它我现在能不能完成？

2. 同类只留一个。 功能重叠的技能会互相调用、关系混乱，每次选型都是浪费。同类对比后只留最好用的一个，不共存。

3. 安装前安全扫描。 技能和 MCP server 权限很大（能碰文件、网络、Shell）。来源不明的，先扫一遍它的定义文件再决定装不装。

4. 先用现有工具，再补新技能。 遇到新需求，第一反应不是”装个新技能”，而是”现有能力里有没有能覆盖的”。搜索有搜索的、深度研究有深度研究的、办公有办公的——先翻自己兜里。

5. 定期审计。 每季度清点一次已装技能的使用频率，低使用率且可替代的，下架归档。

一次真实清理：5 个重叠技能#

有一次，我发现自己装了 5 个功能高度重叠的技能（并行 agent 分发、子代理驱动开发、写计划、追问、再一个追问），互相调用关系混乱，导致每次让 AI 干活时选型都纠结，token 白白浪费。

处理方式：

1. 把 5 个重叠技能归档到备份目录
2. 只保留功能最完整的一个同类技能
3. 其他工作流能力用更轻量的方式替代

结果是：技能选择变清晰了，调用路径变明确了，AI 不再”不知道用哪个”。

一次反面教材：重型工具草率引入#

另一次，未经充分评估就装了一个”全量安装”的压缩/模型类工具。依赖链巨大（CUDA + 模型文件），国内下载极慢，最后整个安装卡死。

代价是一整套卸载：清依赖、清配置、清注册的钩子。教训很直接：

• 重型工具先看依赖体积和离线可用性
• 生产环境 / 主会话不要试验重型工具
• 评估不了就先不装，别”试试再说”

推荐安装流程#

社区发现新技能 → 静态扫描定义文件 → 判断现有技能是否已覆盖 → 小步试用（本地、非生产）→ 确认有效才正式引入 → 定期回顾，低使用率下架。

选型决策树#

1
需要新能力？
2
  ├─ 现有技能能覆盖？            → 直接用，不装
3
  ├─ 同类产品已存在？            → 对比后替换，不共存
4
  ├─ 来源可信？                → 先扫描再安装
5
  ├─ 依赖可接受？              → 小步试，能离线最好
6
  └─ 确认有效后沉淀取舍原因       → 下次不用重新纠结

结论#

技能生态治理的本质是对抗”囤积本能”。每一个技能都是你 Agent 的一项”可选项”，选项越多，决策成本越高。

装得快是本能，删得狠是能力。

定期给 Agent 的技能库做减法，和给代码仓库做重构一样，都是长期健康的一部分。