这个工具解决什么问题
大模型API几乎都按Token计费与限流。中文场景下，用户习惯按「字数」思考，容易低估真实占用：一段3000字中文，在常见分词下可能接近2000+ Token，再叠加系统提示与检索片段，很快触达上下文上限。
本工具用于在编写提示、裁剪知识片段、评估多轮对话膨胀时，快速得到数量级判断，减少上线后账单失控。
估算原理（务必读懂）
- 汉字通常比英文单词更「碎」，经验上约 1.5–2 字接近 1 Token（因模型而异）。
- 英文按词与子词切分，代码、URL、数字串往往更耗Token。
- 本页采用保守启发式：汉字/1.5 + 英文词×1.3，用于规划，不用于对账。
推荐用法
- 把系统提示与用户模板分别统计，相加得到单次请求基线。
- 对RAG召回片段设硬上限（例如合计不超过上下文的40%）。
- 结合API成本估算器换算月费用。
- 正式上线前用目标模型的官方Tokenizer复核关键路径。
延伸阅读：大语言模型工作原理（Token章节）、Prompt工程方法论。
常见问题
为什么和官网Tokenizer不一致？
不同模型分词表不同。本工具给数量级参考，对账请用目标模型官方工具。
中文大概多少字等于1个Token？
常见约1.5–2字接近1 Token，代码与罕见词更耗。以实测为准。
会上传我的文本吗？
不会，统计仅在浏览器本地完成。
上下文窗口该怎么预留？
建议系统提示+检索+历史合计不超过窗口的70%，留给输出与余量。