技能装太多，会挤占编程助手上下文

装进 AI 编程工具的技能（Agent Skills），即使一次都没用过，也可能持续占用上下文。作者的核心判断是：技能管理该看描述能否完整进入模型视野，而不是只数装了多少个。描述被截掉后，文件还在，自动触发却可能失效。

这篇最有用的地方，是把「技能越来越不听使唤」拆成了可检查的问题：先区分目录与正文的成本，再清理闲置项、限制触发方式、调整项目范围。对同时使用 Claude Code、Codex 和 Cursor 的程序员，这比继续安装技能更值得花几分钟。

技能没运行，为什么也会挤占上下文

三款工具都采用渐进披露（progressive disclosure）：先让模型看到技能名称和描述，选中后再读取完整的 SKILL.md。可以把它理解成先看菜单，点菜后才拿到做法。

成本因此分成两层。技能目录每轮都会进入模型上下文；技能正文则在调用后进入对话，并继续占用空间。没有调用过，只能省掉正文，未必能省掉目录。

按原文引用的文档，Claude Code 的目录预算是上下文窗口的 1%，Codex 默认是 2%；Codex 不知道窗口大小时，使用 8,000 字符作为预算。工具没有公布统一的技能数量上限，因为十个长描述与几十个短描述的成本可能不同。

超出预算后，Claude Code 保留名称，从调用最少的技能开始丢弃描述。Codex 先缩短描述，技能很多时还可能省略部分初始目录项并给出警告。缺少描述，模型就少了匹配用户请求的依据。

正文也不保证永久完整保留。Claude Code 自动压缩对话后，会重新附加已调用技能，但每个只保留前 5,000 tokens，总预算为 25,000 tokens，优先放最近使用的技能。长会话里反复调用技能，较早的内容可能完全退出。

所以，某个技能过去能自动触发，现在只能点名调用，未必是模型突然变笨了。

先查实际加载了什么，再决定删什么

作者建议从工具自己的诊断入口开始。Claude Code 的 /doctor 可以估算目录成本并指出大户，/context 的 Skills 行展示应用预算后的大小；溢出警告可以在 claude --debug 的调试日志里找。/skill-doctor 要求 v2.1.252 或更高版本，能展示成本、使用频率和从未调用的技能。

Codex 用 /skills 查看可用项，Cursor 则从侧栏 Customize 进入 Skills。

盘点不能只看自己建的目录。Claude Code 还会加载企业、插件、--add-dir 和 claude.ai 同步来源，同步目录包括 ~/.claude/skills/synced/。Codex 除个人、项目技能外，还读取 /etc/codex/skills 和内置系统技能；Cursor 还兼容 .claude/skills、.codex/skills 及其个人目录版本。

原文附了 Python 扫描脚本，用 python3 list_skills.py 从当前项目运行，按描述长度排序，统计正文行数并标记手动技能。不过它只读取单行 description:，看不到插件、内置、企业技能，也不扫描当前目录下方的嵌套技能。作者仅说明在示例仓库测试过，脚本不会调用三款工具，不能把结果当成真实加载清单。

停用也要分工具处理。Claude Code 的 /skills 菜单支持用 Space 切换状态，Esc 保存到 .claude/settings.local.json。原文列出的配置示例是：

// .claude/settings.local.json
{
  "skillOverrides": {
    "old-helper": "off",
    "release-notes": "user-invocable-only",
    "legacy-context": "name-only"
  }
}

这里要看清 name-only：它仍保留名称，和 off 不同。插件技能不接受 skillOverrides，需要通过 /plugin 停用插件。

Codex 则在 ~/.codex/config.toml 中配置 [[skills.config]]，填写目标 SKILL.md 的 path，设置 enabled = false，然后重启。

预算确实可以调大：Claude Code 有 skillListingBudgetFraction，例如 0.02 表示 2%，也有 SLASH_COMMAND_TOOL_CHAR_BUDGET；Codex 有 skills.max_context_tokens，最高 10,000 tokens。但扩大目录是在消耗更多上下文，先清理通常更划算。

怎样让留下的技能更容易被正确调用

作者的整理方法，可以归成触发权限、描述质量和加载范围三个问题。

部署、提交、发布、发送消息这些带副作用的技能，适合要求明确调用。Claude Code 和 Cursor 可以使用下面的声明：

---
name: deploy
description: Deploys the current branch to staging or production. Only when the user asks to deploy.
disable-model-invocation: true
---

关键是最后一行。Claude Code 会把这类技能排除在目录之外，调用前不承担其目录成本；Cursor 只在用户输入 /skill-name 时包含它。Codex 对应的做法是在技能的 agents/openai.yaml 中，把 policy 下的 allow_implicit_invocation 设为 false，显式 $skill 调用仍可使用。原文明确承认：Codex 文档没有说明这样是否也会移出初始目录。

描述则应该先写具体任务，再写用户会输入的触发词。比如测试技能应交代「为修改的代码编写并运行单元测试」，再覆盖添加测试、提高覆盖率、用失败测试复现 bug 等请求，同时划清与端到端测试的边界。Claude Code 单项的 description 与 when_to_use 合计上限为 1,536 字符，关键内容放前面更稳妥。

重叠技能可以合并，但别变成万能助手。「写测试」「补覆盖率」「修失败测试」可以归入同一个明确任务；一个同时负责测试、部署、数据库设计的技能，反而难用短描述说清。

正文建议控制在 500 行以内，长示例、API 细节放进关联文件，按需读取。常驻 CLAUDE.md 中只在特定任务用到的多步骤流程，也可以迁入技能。

最后是作用域。个人目录只留跨仓库通用技能，仓库专属内容进入 .claude/skills 或 .agents/skills，并提交给团队。包级技能再往下放，但三款工具规则不同：Claude Code 在首次处理对应子目录文件时加载嵌套技能；Cursor 将嵌套技能限定在相应目录；Codex 从启动位置向仓库根扫描，例如在 services/payments 启动才会发现该服务内的 .agents/skills。

Claude Code 和 Cursor 还支持用 paths 限定匹配文件，例如 db/migrations/**，减少不相关任务中的干扰。

我的判断

我赞同先解决技能的可发现性。名称出现在列表里，不等于模型仍能读到完整用途；继续安装相似技能，也可能让同一类请求更难匹配。

但这篇给出的是文档机制整理和维护建议，没有提供清理前后的触发成功率、任务质量、延迟或费用对照。作者对扫描脚本的示例仓库测试，也不能证明整套方法能带来多少收益。清理能减少目录负担，收益多大仍需要自己验证。

还有两个前提不能混用。描述字符数适合初筛，不等于 token 成本；单次没有触发，也不足以证明目录溢出，还可能是描述含糊或范围不匹配。不同工具的手动调用配置，也不能直接推导出相同的节省效果。

作者标注官方文档核对日期为 2026-10-30，这些细节应按该时间点理解。相比直接调高预算，我更倾向先收窄范围、消除重复；如果保留下来的确实都是常用技能，再扩预算才有依据。

能拿来做什么

• 给常用编程工具做一次盘点，从一个月没用过、描述又长的技能开始停用；清理后在新会话里，用日常请求检查保留技能能否触发。
• 把前端项目、Node 服务独有的流程移进仓库；monorepo 的包级技能继续下沉，并按所用工具的启动位置和嵌套规则验证加载。
• 将部署、提交、发布类技能改为明确调用，再检查重复的测试技能，合并处理相同请求的内容。
• 缩短剩余描述，把任务和触发词放在开头；将长 API 说明移到关联文件后，再查看 /context 或 /doctor 的变化。