# Token Auditor Yashu

> 回顾对话过程，找出消耗大量token且可优化的场景，给出优化建议。激活条件：用户消息须包含以下关键词之一:`分析token消耗`、`审计token`、`优化token`、`token审计`、`分析token`、`优化token消耗`。

- Skill: `steelan9199/token-auditor-yashu` (Agent Skill)
- Install (CLI): `npx skillmds add steelan9199/token-auditor-yashu`
- Raw SKILL.md: https://api.skillmd.com/api/skills/steelan9199/token-auditor-yashu/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: steelan9199 (https://skillmd.com/u/steelan9199)
- Updated: 2026-09-09
- Page: https://skillmd.com/skills/steelan9199/token-auditor-yashu

---


# token-auditor-yashu

Token 消耗审计器

## 功能概述

在用户使用某技能完成任务后，回顾整个对话执行过程，从多个维度分析 token 消耗点，找出"消耗大量 token 且可优化"的场景，输出结构化优化报告。

**核心原则**：只读审计，不修改任何文件。

## 触发条件

用户消息包含以下关键词之一时触发：
- `分析token消耗`
- `审计token`
- `优化token`
- `token审计`
- `分析token`
- `优化token消耗`

## 工作流程

### 阶段 1：回顾对话过程

1. 识别本次对话中执行了哪个技能任务（如 license-checker 检测、js-obfuscator 加密等）
2. 回顾执行过程中的关键步骤：
   - 读取了哪些文件（文件名、大致行数）
   - 运行了哪些命令（命令本身、输出内容）
   - 执行了多少次重复操作
   - 使用了什么搜索方式（全文读取 vs Grep/Glob）

> 如果对话历史较长，重点回顾消耗 token 最多的几个关键步骤，不必逐条列举所有操作。

### 阶段 2：多维度分析

从以下 5 个维度分析 token 消耗点：

#### 维度 1：文件读取
- **是否读取了不必要的文件**：有些文件对任务完成没有帮助，读取它们纯属浪费 token
- **是否读取了过长的文件**：有些文件很长，但任务只需要其中一小部分，可以用 Grep 搜索或只读取特定行范围
- **是否可以用 Grep 搜索代替全文读取**：如果只需要文件中的特定内容，Grep 比 Read 更省 token

#### 维度 2：命令输出
- **是否有冗余输出**：多个命令输出相同或高度相似的内容（如重复的错误信息）
- **是否可以精简输出**：可以在命令中用正则匹配关键字，只输出验证结果，而不是完整输出
- **是否可以用管道过滤输出**：用 `Select-String` 或 `Where-Object` 过滤输出

#### 维度 3：重复操作
- **是否有可以批量化的重复操作**：多次运行相同命令，输出可以合并
- **是否有可以合并的命令**：多个独立命令可以用 `;` 合并为一条

#### 维度 4：搜索方式
- **是否用了全文读取代替精准搜索**：用 Read 读取整个文件，而用 Grep 只搜索关键字更省
- **是否可以用 Glob/Grep 代替 LS/Read**：LS 列出目录后再 Read 文件，不如直接 Glob 匹配

#### 维度 5：文档读取
- **是否读取了不必要的参考文档**：有些参考文档对任务完成没有帮助
- **是否可以只读取文档的关键部分**：用 Grep 搜索关键字，或只读取特定章节

### 阶段 3：筛选优化项

对每个分析出的 token 消耗点，应用"两条件法则"筛选：

| 条件 | 说明 |
|------|------|
| 条件 1：消耗大量 token | 该场景消耗的 token 量较大（粗略估算行数或字符数） |
| 条件 2：可以想办法节约 | 该场景的 token 消耗是可以通过改变操作方式来节约的 |

**只有同时满足两个条件的场景才列入优化报告。**

以下场景不列入报告：
- 消耗大量 token 但无法避免的（如必须读取的配置文件）
- 消耗少量 token 的场景（即使可以优化也不值得）

### 阶段 4：输出优化报告

报告格式如下：

#### 报告结构

1. **头部**：分析的技能任务名称、对话回顾范围
2. **优化项列表**（按预计节约量从大到小排序），每项包含：
   - 优化点名称
   - 消耗量估算（粗略估算 token 或行数）
   - 为什么消耗大（具体行为描述）
   - 优化建议（具体的改进方法）
   - 预计节约量
3. **总结表格**：

```
| 优化项 | 预计节约 token |
| ------ | ------------- |
| ...    | ...           |
| 合计   | ...           |
```

#### 报告示例

参考以下格式输出：

---

## 优化项 1：读取 references 目录下的 8 个参考文档

**消耗量估算**：约 9000-14000 token（8 个文档共约 937 行）

**为什么消耗大**：读取了 8 个完整的参考文档（createSession.md、sendMessage.md 等），每个文档 50-200 行，总计约 937 行。

**优化建议**：不读取 references 文档，直接使用占位参数。因为授权检查在参数验证之前执行，占位参数对于拦截场景测试完全够用。

**预计节约量**：约 9000-14000 token

---

## 总结表格

| 优化项 | 预计节约 token |
| ------ | ------------- |
| 不读取 references 文档 | ~9000-14000 |
| 只读取 SKILL.md 关键部分 | ~2500-4000 |
| 精简重复输出 | ~2400-3600 |
| **合计** | **~14000-21000** |

---

## 重要规则

1. **只读审计**：绝不修改任何文件，只输出分析报告
2. **两条件法则**：只列出同时满足"消耗大量 token"和"可以想办法节约"的场景
3. **基于对话回顾**：不读取文件，完全基于 AI 对对话过程的回顾
4. **量化估算**：尽量给出粗略的 token 消耗量估算（可以按行数估算，每行约 10-15 token）
5. **可操作建议**：优化建议必须具体可操作，不能是"减少读取"这种空话
6. **按节约量排序**：优化项按预计节约量从大到小排序，让用户优先关注收益最大的优化
7. **不列不可避免项**：必须读取的配置文件、必须执行的命令等不可避免的大 token 消耗，不列入报告

## 使用示例

用户说"分析 token 消耗"，AI 回顾本次对话中执行 license-checker 检测的过程，找出 3 个可优化点（读取 references 文档、读取完整 SKILL.md、重复授权错误输出），输出结构化报告。