Tokensift：开源 LLM 提示词 token 效率静态分析工具
开发者推出开源工具 Tokensift，可在本地对 LLM 提示词做 tokenizer 级静态分析，定位 token…
近日在 Hacker News 上亮相的开源项目 Tokensift，是一款面向 LLM 提示词的「token 效率 linter」。它通过对提示字符串、消息数组以及工具 schema 进行 tokenizer 级别的静态分析，定位实际可压缩的 token 浪费点，并给出每处修复可节省的美元成本。整套引擎采用本地确定性分析，可作为库在代码或测试中调用，也可作为 CLI 接入 CI。
项目现状与定位
Tokensift 目前仍处于早期阶段，作者表示核心引擎、20 条规则、美元成本估算、CLI 以及 vitest/jest 的 matchers 均已可用。其中 OpenAI 模型使用真实 BPE 词表，结果为「精确（exact）」；由于 Claude 没有公开 tokenizer，Claude 路径采用经验校准估算，每条 finding 上都会标注 confidence 为 estimate。项目模仿 ESLint 的理念，把分析目标从代码风格转向 token 成本与上下文窗口占用。
内置规则与示例分析
以一段支持工单分类的 few-shot 提示为例，调用 analyze() 并指定 gpt-4o 作为模型，工具一次性抛出三条 finding：
- uuid-bloat：UUID「550e8400-e29b-41d4-a716-446655440000」消耗 18 个 token（2.0 字符/token），改用短 id 仅需 3 个 token，单次调用可节省 0.0000375 美元，置信度 exact。
- pretty-json：格式化 JSON 区域消耗 16 个 token，压缩后仅 9 个，单次节省 0.0000175 美元，工具直接给出 minified 替换串。
- repeated-block：12 token 的重复片段出现 3 次，共 36 token，建议改为只陈述一次并引用，单次节省 0.00006 美元。
整段 prompt 共 150 个 token，其中 46 个被识别为可消除的浪费。规则集合覆盖 UUID/base64 等不可压缩字符序列、重复片段、格式化 JSON、冗余工具描述、空消息等常见问题，并可通过 builtinRules 自行筛选。
使用方式与边界
- 库调用：通过 pnpm add tokensift 引入，对字符串或消息数组运行 analyze()。
- CLI 与 CI：init 生成基线，check + budget 强制每次变更的 token 上限，calibrate 用于调整非 OpenAI 模型的估算系数。
- 边缘部署：支持 Supabase、Netlify、Cloudflare、Vercel 等 Edge Functions，作者专门写了 bundle-size 注意事项，说明哪些规则会引入较重的依赖。
- 明确非目标：不取代完整的 prompt 评测框架，也不做模型输出质量评估，仅聚焦 token 与成本层面的静态检查。
局限与适用场景
作者在 DESIGN.md 中坦率列出了多项权衡：Claude 估算依赖抽样校准，存在偏差风险；规则对编码敏感字符的判定基于当前主流 tokenizer，未来模型版本可能需要重新 calibrate；项目也尚未覆盖输出侧成本或更复杂的 agent 消息流。对于高频调用商业 LLM API、且希望在 PR 阶段就拦截 prompt 回归的团队，Tokensift 可作为轻量补充；对于以本地模型或批量任务为主的场景，其边际收益有限。