Claude Code 技能包应按项目精简安装

给 Claude Code 装上 292 个 skills，未必比只装 21 个更好。ParkEase 的作者从一个开源能力包里挑选技能时发现，问题不只是技术栈不匹配：连专门面向 NestJS 的技能，都可能与项目已有的架构决策冲突。

这篇文章真正有用的地方，是把「装得越多越强」改成了一套筛选流程：先核对项目规则，再限制安装范围，最后审计实际装进来的内容。不过，它提供的是一次项目实践，没有证明技能数量与效果之间的量化关系。

为什么多装技能可能把任务带偏

作者独自使用 Claude Code 开发 ParkEase，一个面向印度的点对点停车位交易平台。开发途中，他找到一个开源包，包含 292 个 skills、68 个专用 agents、94 个斜杠命令，以及一套 hook 运行机制。

看起来，一条安装命令就能补齐大量能力。但作者原本已有 56 个技能，全量安装后索引会增加到 348 个。其中包含 Django、Laravel、Rails、Spring Boot、.NET、Flutter、Vue、Angular、MySQL 和 Prisma，ParkEase 一个也没用。

按作者的解释，agent 会读取技能的简短描述，把它们与当前任务匹配。候选项越多，就越容易遇到「描述很像正确答案，实际适用于其他项目」的指导。

技能写得正确，不代表它适合当前仓库。

这里的风险并不难理解：错误建议可能非常专业，执行起来也很顺畅，只是它解决的是另一个技术栈的问题。

最像正确答案的 NestJS 技能，为什么也没装

ParkEase 的 API 使用 NestJS，包里的 NestJS 技能看上去应该优先安装。作者检查后，却发现它同时违背了项目的四项架构决策。

原文没有列出这四项决策，因此无法判断具体冲突，也不能据此评价这个 NestJS 技能本身的质量。能确认的是，框架名称一致，并不足以证明工程约定兼容。

作者把它放进了书面的隔离名单。同样被排除的，还有重复已有检查关卡的技能，以及两个与现有技能重名的条目。其中一个叫 taste，实际内容是音乐视频的创意指导；作者担心，这个名字会让它被误用于 UI 工作。

最终，他安装了 21 个技能和 25 个 agents，其余 271 个技能没有保留。操作上有几个细节：

• 逐个阅读候选内容，对照实际技术栈和已有决策记录。
• 安装在仓库内，限定为项目本地使用，避免影响其他项目。
• 安装后重新清点，因为安装器还会带入传递依赖，需要反复执行「安装 → 清理 → 重新审计」。
• 将 hook profile 固定为 minimal，因为默认配置曾阻止普通 shell 命令。
• 把取舍写进决策记录，避免后续会话再次把剩余技能装回来。

这里最容易漏掉的是安装后的检查：你选中的技能数量，不一定等于最终落盘的数量。

我的判断

我赞同作者把技能当成工程依赖来管理。依赖要检查适用范围，技能也要核对规则是否冲突；一个权威口吻的指导文件，同样可能增加维护成本。

但「更多技能导致更差选择」在文中仍是经验判断。作者没有给出全量安装与精简安装之间的任务成功率、耗时或 token 消耗对照，也没有交代具体开源包、版本和完整筛选清单。关于每个技能都会成为每次决策候选项的描述，也不宜直接推广到所有 agent 实现。

与全局安装大而全的技能包相比，项目本地安装更容易限制影响范围。至于 21 个是不是合适数量，文章没有给出可复用的阈值。真正能照搬的是筛选方法，而不是数字。

文末提到一次约 40 个 AI reviewer agents 消耗了接近一周使用额度的经历，但那是下一篇的预告，不能拿来证明本篇精简技能的收益。

能拿来做什么

• 给前端或 Node 仓库引入技能前，先核对框架、数据层和架构约定；即使都叫 NestJS，也要读具体指令。
• 优先采用项目本地安装，并记录保留、排除和隔离的原因，让后续 AI 会话知道哪些选择已经做过。
• 安装完成后检查实际技能清单、名称冲突和传递依赖，同时确认 hook 是否干扰日常 shell 命令。
• 已有大量技能时，先清理明显不属于项目技术栈的条目，再观察实际任务表现，不必把 21 个当成统一目标。