这两年做 AI 开发，有一个变化很明显：我们不再只是在和一个大模型对话，而是在给 AI Agent 不断加能力。

今天装一个写作 skill，明天装一个公众号发布 skill，后天又补一个图片生成、网页抓取、PPT、图谱、MCP 服务。刚开始很爽，像给自己的开发环境装上了外骨骼。

但装到一定数量之后，问题就来了。

你突然发现：不是没有工具，而是不知道该用哪个工具；不是缺少能力，而是能力开始互相重叠、过期、失控。

我们真正遇到的问题，是 skill 生命周期失控

一个 skill 从安装到长期使用，至少会经历五件事：

• • 它被安装进某个 AI 编程工具。
• • 它被扫描、识别、分类。
• • 它在某个任务里被推荐或调用。
• • 它逐渐沉淀使用记录，也可能长期闲置。
• • 它需要更新、审计、禁用，甚至被清理。

如果这些动作都靠记忆，人很快就会崩。

尤其当你同时使用 Claude Code、Codex、Cursor、Gemini 这类工具时，每个工具都有自己的 skill 目录、MCP 配置、会话记录和插件生态。它们看起来都在增强生产力，但背后其实形成了一套本地能力资产。

资产越多，治理就越重要。

第一层治理：先看清楚自己到底装了什么

很多人低估了“看清楚”这件事。

真正开始扫描本机 skill 之后，你可能会第一次发现：

• • 同一个 skill 在多个工具里重复安装。
• • 某些 skill 名字不同，但功能高度相似。
• • 有些 MCP 服务长期配置着，却几乎没有被真实使用。
• • 有些 skill 的描述很长，常驻上下文开销并不低。
• • 有些来源和版本信息并不完整，后续很难判断是否需要更新。

这不是洁癖。

AI Agent 的上下文是成本，工具调用是风险，重复能力会制造选择困难。一个本地 skill 生态如果长期没有体检，最后会变成“看似强大，实际混乱”的工具堆。

第二层治理：不是搜索 skill，而是根据任务推荐 skill

当 skill 数量变多，用户最自然的问题不是“我装了哪些 skill”，而是：

“我要做这件事，应该用哪一个？”

这也是 skill 管理从清单工具走向治理工具的关键一步。

一个好的推荐不应该只做关键词匹配。它需要结合：

• • skill 的名称和描述。
• • 当前任务的真实意图。
• • 同义词、方向性和语言差异。
• • skill 是否在多个 AIDE 工具中都可用。
• • 历史使用频率带来的个人偏好。

比如“把网页转成 Markdown”和“把 Markdown 发布到公众号”看起来都与内容处理有关，但方向完全不同。推荐系统如果只看“Markdown”这个词，很容易把反向能力推荐出来。

真正有用的推荐，应该减少人的选择负担，而不是再给人一堆候选项。

第三层治理：安全审计必须前置

skill 的本质，是让 AI Agent 拿到更具体的操作说明、脚本能力和外部服务连接。能力越强，越不能只看它“能做什么”，还要看它“可能做什么”。

安全审计至少要关注这些信号：

• • 是否包含敏感信息外发倾向。
• • 是否出现危险 shell 命令。
• • 是否存在可疑下载、执行、删除逻辑。
• • MCP 命令里是否夹带密钥参数。
• • 是否有来源不明、版本不清的本地能力。

这不是说 skill 不可信，而是说本地能力栈需要可解释、可追踪、可复查。

第四层治理：重复、闲置、上下文开销，都应该被看见

AI 工具最容易让人产生一种错觉：只要多装几个 skill，总会更强。

但真实体验往往相反。

重复安装会让推荐变乱；长期闲置会让维护成本变高；描述过长会增加上下文开销；会话日志无限增长，也会让审计和回溯变慢。

所以治理工具不应该只告诉你“装了多少”，还应该告诉你：

• • 哪些能力重复。
• • 哪些长期没用。
• • 哪些可能造成上下文负担。
• • 哪些配置可以先软禁用观察。
• • 哪些日志可以在安全窗口之后清理。

好的治理不是一键删除，而是给出可理解的建议，并保留确认、备份和安全窗口。

第五层治理：版本和来源，是长期使用的底线

skill 会更新。

新版本可能修 bug、补安全问题、优化提示词、增加能力。但很多来自公开仓库的 skill，一旦被复制到本机，后续作者更新了，使用者未必知道。

所以版本治理需要两步：

• • 能判断的，直接告诉用户是否落后。
• • 判断不了的，让用户补充来源映射，并持久化保存。

这件事看起来小，但它决定了一个 skill 能不能从“复制来的文件夹”变成“可维护的本地能力资产”。

我越来越相信：AI 开发环境也需要资产负债表

过去我们管理代码依赖，有包管理器、锁文件、漏洞扫描、版本升级提示。

现在 AI Agent 也开始拥有自己的“能力依赖”。

skill、MCP、插件、会话日志、推荐记录、知识图谱、版本来源，这些东西加在一起，就是一个开发者的本地 AI 能力栈。

只要它继续增长，就必然需要治理。

不是为了把工具变复杂，而是为了让复杂性被看见、被解释、被控制。

真正成熟的 AI 开发环境，不应该只是“能装很多 skill”。

它还应该知道：哪些值得保留，哪些需要审计，哪些已经过期，哪些应该推荐给当前任务，哪些该被暂时放下。

这就是 skill 生命周期治理的价值。

它不是给 AI Agent 再装一个玩具。

它是在给越来越复杂的本地 AI 能力栈，补上一套秩序。

阅读原文：点击这里​