AI Agent不需要更多技能，需要精简

当一个编程 Agent 漏掉了什么东西时，直觉反应是给它加一个 Skill。漏了测试？写一个"运行测试"的 Skill。跳过了 review 步骤？写一个"提交前 review"的 Skill。这样搞上几个月，你的文件夹里就有四十个 Skill 文件了，而 Agent 自动做对事情的能力反而比只有十个 Skill 时更差。

这并非巧合。Skill 不会静静地躺在那里等待被调用——每次模型决定要加载什么时，它们都在争夺模型的注意力。加更多 Skill 不是免费的。

失败的原因是选择困难，而非能力不足

Agent 选择哪个 Skill 适用于某个请求，本质上是在做一个匹配问题：这条描述是否符合用户在问的内容？只有十个边界清晰（well-scoped）的 Skill 时，答案通常毫无歧义。有了四十个，多条描述开始重叠——"协助调试"、"帮助修复 bug"、"当出问题时报错"——于是 Agent 开始在几个几乎一模一样的选项之间猜来猜去，而不是果断选中一个。

你实际看到的症状不是"加载了太多 Skill"，而是走火：错误的 Skill 被触发，或者正确的 Skill 没被触发，又或者两个 Skill 各半吊子地适用，Agent 把它们混成了两者作者都没想过的东西。如果你在排查为什么某个 Skill"以前能用"现在却不稳定地触发，先别急着怀疑模型退行，检查一下是不是新 Skill 的触发描述悄悄开始和它重叠了。

什么才真正值得建一个 Skill

同一个工作流你解释到第三遍时，才值得为之建一个 Skill。如果你在一次 Agent 对话中打完同样的指令两次，记下来，等到第三次再写成 Skill——在此之前就建，你还没法确定这是一个真实 recurring 的模式，还是你过早 pattern-match 的一次性事件。

一个合理的目标结构：

每个工作流阶段一个流程 Skill。调试、代码 review、规划——每个都是一套独立 procedure，有各自的条件门控，而不是试图三合一地糟糕覆盖一切的"如何写好代码"大文件。

针对你实际 niche 的少量领域 Skill——你的技术栈、规范、你每天用的工具。

Persona 或 standing-rule 文件用于那些始终为真的东西，与任何有条件的东西分开保存。（这和 SOUL.md 与 AGENTS.md 搭配工作的逻辑相同：永远不变的身份信息不应该和下个 sprint 就会被打补丁的操作规则放在同一个文件里。）

几乎没人做的部分：淘汰 Skill

加一个 Skill 感觉像进步。删一个 Skill 感觉像损失工作量。这种不对称恰恰是库只会越来越大的原因。但是一个一个月都没被触发过的 Skill，要么是分类错误（触发描述和你实际措辞不匹配），要么是真的死了（它覆盖的工作流不再发生）——无论哪种情况，它仍然在候选池里，每次请求都要被 Agent 排除掉。

把 Skill 文件夹当代码库来对待：有版本控制，偶尔修剪，出问题时审计。在写第 41 个 Skill 之前，花五分钟检查一下第 12 个 Skill 自写成以来有没有触发过——解决方案可能是删一个文件，而不是加一个。

触发描述模糊时的快速审计

把所有 Skill 的描述列在一处，逐条并排对比。

对每一对可能同时适用于同一个真实请求的，那就是重叠——收窄其中一个或合并它们。

记下每个 Skill 上次实际触发是什么时候。超过一个月的要么修好、要么删掉，不能放任不管。

以上都不需要什么工具——对着纯 Markdown 文件过五分钟就够了。如果你维护的库比较大，希望触发描述的编写这部分能有人帮你做而不是自己手工迭代，Skill Forge 附带了 43 个预组织的 Skill，分成五个不重叠的领域，主要可以作为参考，看看触发描述要写多精准才能不再和邻居打架。

Full answer: https://agentkitworks.com/answers/how-many-skills-does-claude-code-need

For further actions, you may consider blocking this person and/or reporting abuse