usage-audit

使用量审计

臃肿的上下文会带来双重成本：使用量限额消耗得更快，输出质量也会下降，因为模型最关注上下文的开头和结尾。这项技能会找出浪费之处，并告诉你该删掉什么。

致谢：改编自《Claude Code Context Cleanup Guide》（2026）中的 context-audit 技能。Armory 移植版增加了面向软件包的检查，并将评分标准视为可覆盖的参考，而非定论。

第 1 步：获取 /context 数据

检查对话中是否有近期的 /context 输出。如果用户在本次会话中还没有运行该命令，请询问：

"在此终端中运行 /context 并粘贴输出。我无法自行运行斜杠命令——看到详细信息后，我就能审计其中标出的所有内容。"

到此为止。 在获得真实的 /context 数据之前，不要继续第 2 步。详细信息决定了审计的内容和顺序。没有这些数据，审计就只能靠猜。输出上面的消息并等待。

第 2 步：审计臃肿之处

按照 /context 输出中各类别的大小从大到小依次检查。并行运行彼此独立的检查。

MCP 服务

每个已连接的服务都会在每轮对话中将完整的工具定义加载到上下文中（每个约 15,000–20,000 个 token），无论你是否调用工具。由于分词器更新，在 Opus 4.7 下，相同架构的这一数值可能高出 1.0–1.35 倍——请优先采用 /context 中的实测值，而非这些静态估算值。

• 统计 settings.json 和 ~/.claude/settings.json 中配置的服务数量。
• 报告 /context 中的 MCP 开销总量。
• 标出任何有 CLI 等效方案的服务（Playwright、GitHub、Google Workspace、Notion、Slack 等）——CLI 空闲时不消耗 token。
• 交叉检查已安装的 armory 软件包：如果安装了 mcp-to-skill，请明确建议使用它来替代开销最大的服务。

CLAUDE.md 文件

阅读范围内的所有 CLAUDE.md（项目根目录、.claude/、~/.claude/）。对每个文件：统计行数，然后用以下五项标准逐条检查规则。

标准	以下情况需标出……
默认行为	Claude 不用提示就会这么做（“编写干净的代码”“处理错误”）
矛盾	与同一文件或其他文件中的另一条规则冲突
冗余	重复了其他地方已有的内容
临时补丁	为修复某个特定的不良输出而添加，并未普遍改善输出
含糊	每次都会被解读成不同的意思（“自然一点”“使用良好的语气”）

如果 CLAUDE.md 超过 200 行，请检查是否有渐进式披露的机会：仅适用于特定任务的规则（API 约定、部署步骤、测试）应移至参考文件，并在核心文件中用一行指向它们。包含通用上下文、少于 200 行的精简 CLAUDE.md 可以保留为单个文件——不要为了拆分而拆分。

规则软件包（仅适用于 armory）

Armory 的 rules/ 软件包会像 CLAUDE.md 一样加载到每个会话中——它们才是真正悄无声息的基础开销。其优先级高于技能臃肿问题。

• 通过 ~/.claude/settings.json 或 armory 安装程序注册表（如果存在）列出已安装的规则软件包。
• 对每个规则软件包，阅读其 RULE.md 正文、统计行数，并应用相同的五项标准。
• 标出任何超过 300 行的规则软件包。这些内容会在每一轮对话中加载。

已安装的技能

扫描 ~/.claude/skills/*/SKILL.md 和任何项目本地技能。对每个技能：

• 仅统计 SKILL.md 正文的行数——不要统计 references/、scripts/ 或 evals/ 下的文件。这些内容会按需加载，不会在触发技能时加载。按软件包总行数惩罚会错误归因开销。
• 标出正文超过 200 行的 SKILL.md（警告）或超过 500 行的 SKILL.md（严重）。
• 使用五项标准检查技能指令：重复陈述目标、模棱两可的表述（“你可以考虑……”）、同义指令（“简洁”+“保持简短”+“不要冗长”）。
• **Frontmatter 描述审计：**统计每个技能 description 字段中的单词数。标出任何超过 60 个单词的描述。技能描述会在每次会话中加载到路由器，因此应聚焦于触发条件，而非大段说明。

设置

检查 settings.json 中的以下键：

设置项	如果	建议值
autocompact_percentage_override	缺失或 > 80	75
env.BASH_MAX_OUTPUT_LENGTH	为默认值（30-50K）	150000

文件权限

检查 settings.json 中的 permissions.deny。如果缺失，请检查项目并标记应被拒绝访问的臃肿目录：

如果存在此文件……	应拒绝访问……
package.json	node_modules、dist、build、.next、coverage
Cargo.toml	target
go.mod	vendor
pyproject.toml / requirements.txt	__pycache__、.venv、*.egg-info

第 3 步：评分并报告

以下评分标准是默认参考，并非绝对准则。封装了大量 CLI 功能的“参考”技能（例如 github、agent-builder）可能合理地超出行数阈值——应评估正文，而非文件数量。用户可以在其项目的 CLAUDE.md 中覆盖任何扣分项。

初始分数为 100。按问题扣分：

问题	分值
CLAUDE.md > 200 行	-10
CLAUDE.md > 500 行	-20
规则包正文 > 300 行	每个 -10
筛选器标记的规则，每 5 条	-5
文件之间存在矛盾	-10
缺少 autocompact_percentage_override	-10
缺少 BASH_MAX_OUTPUT_LENGTH 覆盖值	-5
技能正文 > 200 行	每个 -5
技能正文 > 500 行	每个 -10
技能描述 > 60 个词	每个 -2
每个已连接且有 CLI 替代方案的 MCP 服务	每个 -5
没有 permissions.deny 且存在臃肿目录	-10

最低为 0。按以下格式输出：

# Usage Audit

Score: {N}/100 [{CLEAN|NEEDS WORK|BLOATED|CRITICAL}]

## Context Breakdown (from /context)
{Paste the key numbers}

## Issues Found

### [{CRITICAL|WARNING|INFO}] {Category}
{What's wrong}
Fix: {One-line actionable fix}

### Rules to Cut
{Each flagged rule: quoted text, which filter, one-line reason}

### Conflicts
{Contradictions between files, with paths}

## Top 3 Fixes
1. {Highest-impact fix}
2. {Second}
3. {Third}

分数标签：90-100 CLEAN，70-89 NEEDS WORK，50-69 BLOATED，0-49 CRITICAL。 严重程度：CRITICAL > 10 分，WARNING 5-10 分，INFO < 5 分。

第 4 步：提出修复建议

报告后，提出有针对性的修复建议：

“要我应用其中任何一项吗？我可以：

• 添加缺失的 settings.json 键（autocompact_percentage_override、BASH_MAX_OUTPUT_LENGTH）
• 为检测到的臃肿目录添加 permissions.deny 规则
• 展示移除已标记规则后的 CLAUDE.md 清理版差异
• 精简冗长的技能 frontmatter 描述
• 建议本次会话断开哪些 MCP 服务”

自动应用设置和权限更改（安全且可逆）。修改任何指令文件（CLAUDE.md、RULE.md、SKILL.md）前，先展示差异并等待确认——指令编辑会影响核心行为，最终决定权应交给用户。