steelan9199 token-auditor-yashu
Token 消耗审计器
功能概述
在用户使用某技能完成任务后，回顾整个对话执行过程，从多个维度分析 token 消耗点，找出"消耗大量 token 且可优化"的场景，输出结构化优化报告。
核心原则：只读审计，不修改任何文件。
触发条件
用户消息包含以下关键词之一时触发：
分析token消耗审计token优化tokentoken审计分析token优化token消耗
工作流程
阶段 1：回顾对话过程
- 识别本次对话中执行了哪个技能任务（如 license-checker 检测、js-obfuscator 加密等）
- 回顾执行过程中的关键步骤：
- 读取了哪些文件（文件名、大致行数）
- 运行了哪些命令（命令本身、输出内容）
- 执行了多少次重复操作
- 使用了什么搜索方式（全文读取 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：输出优化报告
报告格式如下：
报告结构
- 头部：分析的技能任务名称、对话回顾范围
- 优化项列表（按预计节约量从大到小排序），每项包含：
- 优化点名称
- 消耗量估算（粗略估算 token 或行数）
- 为什么消耗大（具体行为描述）
- 优化建议（具体的改进方法）
- 预计节约量
- 总结表格：
| 优化项 | 预计节约 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 |
重要规则
- 只读审计：绝不修改任何文件，只输出分析报告
- 两条件法则：只列出同时满足"消耗大量 token"和"可以想办法节约"的场景
- 基于对话回顾：不读取文件，完全基于 AI 对对话过程的回顾
- 量化估算：尽量给出粗略的 token 消耗量估算（可以按行数估算，每行约 10-15 token）
- 可操作建议：优化建议必须具体可操作，不能是"减少读取"这种空话
- 按节约量排序：优化项按预计节约量从大到小排序，让用户优先关注收益最大的优化
- 不列不可避免项：必须读取的配置文件、必须执行的命令等不可避免的大 token 消耗，不列入报告
使用示例
用户说"分析 token 消耗"，AI 回顾本次对话中执行 license-checker 检测的过程，找出 3 个可优化点（读取 references 文档、读取完整 SKILL.md、重复授权错误输出），输出结构化报告。