我的在线工具箱继续升级：新增 Token 计算器、AI 提示词生成器和开发者格式化工具

我的在线工具箱继续升级：新增 Token 计算器、AI 提示词生成器和开发者格式化工具

之前我写过一篇文章，记录了自己给 Django 博客做在线工具箱的过程。

那篇文章主要写的是第一版工具箱的整体思路：为什么要做、哪些工具适合浏览器本地处理、Django 后端负责什么、工具页怎么做 SEO 和统计。

工具箱地址：

https://leedu.ac.cn/tools/

最近我又继续补了一批小工具，所以单独写一篇更新记录。

这篇不重复讲“为什么要做工具箱”，主要记录这次新增了哪些工具，以及新增过程中遇到的一些实现取舍。

这次新增了哪些工具？

这次新增和优化的工具主要分成三类。

第一类是图片和前端相关工具：

• 图片尺寸调整工具
• 图片取色器
• 颜色转换器

第二类是开发者常用的数据处理工具：

• CSV 转 JSON
• YAML / JSON 互转
• Cron 表达式解析器
• SQL 格式化工具
• JSON 转 TypeScript

第三类是 AI 相关工具：

• Token 计算器
• AI 提示词生成器
• AI 版 Prompt 生成接口

这些工具的定位仍然是：打开页面就能用，尽量轻量，能在浏览器本地完成的就不上传服务器。

为什么继续做这些小工具？

我发现工具箱做起来以后，真正有价值的不是“工具数量多”，而是能不能覆盖自己和用户的高频场景。

比如写博客和做网站时，经常会遇到这些需求：

• 图片太大，需要压缩或调整尺寸；
• 从图片里取一个颜色，做页面配色；
• CSV 数据想快速转成 JSON；
• 配置文件需要在 YAML 和 JSON 之间转换；
• 写定时任务时想确认 Cron 表达式是否正确；
• 复制来的 SQL 太乱，需要格式化；
• 拿到一段 JSON，希望快速生成 TypeScript 类型；
• 写 AI 提示词前，想估算 Token 数；
• 不知道怎么组织 Prompt，希望先生成一个结构化模板。

这些都是非常典型的临时任务。

如果每次都去搜索一个新网站，体验会比较割裂。

所以我更倾向于把这些轻量工具慢慢收进自己的博客里，形成一个长期维护的工具箱。

新增的图片类工具

图片工具之前已经有图片压缩和图片格式转换，这次又补了图片尺寸调整、图片取色器和颜色转换器。

图片尺寸调整工具

这个工具主要解决一个很常见的问题：

图片宽高不合适，想按固定宽度、高度或比例缩放。

比如写博客封面图、文章配图、缩略图，经常会遇到图片尺寸太大或者比例不统一的问题。

这个工具仍然是浏览器本地处理，大致流程是：

1. 用户选择图片；
2. 浏览器读取图片；
3. 创建 Canvas；
4. 按目标宽高重新绘制；
5. 导出新图片；
6. 用户下载处理后的图片。

不需要上传服务器。

图片取色器

图片取色器适合做页面配色、封面图配色和 UI 调色。

用户上传图片后，可以提取主色和调色板，也可以点击图片中的某个位置获取颜色值，比如：

• HEX；
• RGB；
• HSL。

这类工具很适合和图片工具箱放在一起，因为使用场景比较接近。

颜色转换器

颜色转换器支持 HEX、RGB、HSL 之间互转。

前端开发里经常会遇到：

• 设计稿给的是 HEX；
• CSS 里想用 RGB 或 HSL；
• 想快速预览颜色；
• 想复制不同格式的颜色值。

所以这个工具虽然简单，但实际使用频率不低。

新增的开发者数据处理工具

这次也补了一批偏开发者的小工具。

CSV 转 JSON

CSV 转 JSON 很适合处理表格数据、导出数据和临时配置。

工具支持：

• 粘贴 CSV；
• 上传 CSV；
• 选择是否首行为表头；
• 设置分隔符；
• 转成 JSON 数组。

这个工具也可以纯前端完成，不需要后端参与。

YAML / JSON 互转

YAML 和 JSON 都是开发中很常见的数据格式。

比如：

• Docker Compose；
• GitHub Actions；
• Kubernetes 配置；
• API 返回；
• 前端配置文件。

有时候需要把 YAML 转成 JSON 看结构，有时候又要把 JSON 转成 YAML 写配置。

这个工具就是为这种临时转换准备的。

Cron 表达式解析器

Cron 表达式看起来简单，但实际经常写错。

比如：

0 2 * * * */15 * * * * 0 0 * * 1

这些表达式到底什么时候执行，如果不解析一下，很容易误判。

Cron 解析器可以显示：

• 每个字段的含义；
• 表达式是否有效；
• 接下来几次运行时间。

这类工具对后端开发、运维、定时任务调试都比较实用。

SQL 格式化工具

复制出来的 SQL 经常是一整行：

selectid,name,created_atfromuserswherestatus=1orderbycreated_atdesc

格式化后会更容易阅读和排查问题。

这个工具主要用于：

• 格式化 SELECT；
• 格式化 INSERT；
• 格式化 UPDATE；
• 格式化 DELETE；
• 调试日志里的 SQL。

首版不追求做成完整 SQL IDE，只解决“快速整理格式”的高频需求。

JSON 转 TypeScript

这个工具是给前端和全栈开发准备的。

很多时候拿到接口返回：

{"id":1,"name":"Li Xun","enabled":true}

希望快速生成 TypeScript 类型：

interfaceRoot{id:number;name:string;enabled:boolean;}

虽然复杂场景还需要人工调整，但对日常接口调试已经够用。

新增的 AI 工具

这次比较重要的更新是 AI 工具。

我新增了两个方向：

• Token 计算器；
• AI 提示词生成器。

Token 计算器：为什么要做？

现在使用 ChatGPT、Claude、Gemini 这类工具时，经常会遇到上下文长度和 Token 成本问题。

比如：

• 一段 Prompt 大概多少 Token？
• 一篇文章丢给 AI 会不会太长？
• RAG 检索出来的内容能不能放进上下文？
• 系统提示词、用户输入、参考资料加起来会不会超限？

所以 Token 计算器是一个很适合放进工具箱的 AI 小工具。

工具地址：

https://leedu.ac.cn/tools/token-counter/

Token 计算器的实现取舍

Token 计算器看起来简单，但这里有一个细节：

如果想精确计算 OpenAI 模型 Token，就需要 tokenizer 词表。

我这次使用的是gpt-tokenizer，在浏览器本地运行。

支持的方向大致是：

• GPT-5 / GPT-4o / GPT-4.1：使用o200k_base；
• GPT-4 / GPT-3.5：使用cl100k_base；
• Claude：做近似估算。

为什么 Claude 是估算？

因为 Anthropic 没有像 OpenAI tiktoken 这样方便在前端离线复刻的官方 tokenizer。

所以 Claude Token 更适合做大致估算，最终还是要以官方 API 或账单统计为准。

Tokenizer 按需加载

一开始我把两个 tokenizer 静态文件都直接放在页面里加载。

后来发现这样不太合理，因为词表文件比较大：

• o200k_base大约 2MB；
• cl100k_base大约 2MB。

如果用户只是打开页面，还没有输入内容，就直接加载两个大文件，明显不够轻。

所以后面做了按需加载：

• 打开页面时不加载 tokenizer；
• 用户选择 GPT-5 / GPT-4o 类模型并输入内容时，才加载o200k_base；
• 用户选择 GPT-4 / GPT-3.5 时，才加载cl100k_base；
• 选择 Claude 时不加载 tokenizer，只做估算。

这个优化比较实用，既保留了准确性，又减少了首次打开页面的负担。

AI 提示词生成器

另一个新增工具是 AI 提示词生成器。

工具地址：

https://leedu.ac.cn/tools/ai-prompt-generator/

这个工具有两个模式：

1. 本地模板生成；
2. AI 生成 Prompt。

本地模板生成

本地模板生成不调用任何 API。

用户填写：

• 使用场景；
• AI 角色；
• 目标任务；
• 补充要求；
• 输出格式；
• 语气风格；
• 是否需要澄清问题；
• 是否需要自检清单。

然后前端用模板拼接出一个结构化 Prompt。

这个模式的好处是：

• 不需要 API Key；
• 不消耗模型额度；
• 响应很快；
• 用户内容不上传服务器。

AI 生成 Prompt

后来我又加了 AI 版。

因为我后台已经有 Gemini 相关能力，所以可以让后端调用 Gemini，生成质量更高的 Prompt。

这里的流程是：

1. 用户在页面填写需求；
2. 点击“AI 生成 Prompt”；
3. 前端把内容提交给 Django 后端；
4. 后端检查开关和限流；
5. 后端调用 Gemini；
6. 返回生成后的 Prompt；
7. 前端展示并支持复制、下载。

需要注意的是，AI 版和本地模板版不一样。

本地模板版不上传内容。

AI 版会把用户填写的内容提交给本站后端，再由后端调用模型。

所以页面里也要写清楚这个边界，避免用户误解。

为什么 AI 接口要限流？

公开工具页一旦接入 AI，就必须考虑成本和滥用问题。

如果不做限制，可能会遇到：

• 被脚本频繁调用；
• API 额度被快速消耗；
• 服务器请求压力变大；
• 正常用户体验变差。

所以我给 AI Prompt 接口加了 IP 限流。

当前策略是：

相同 IP 每分钟最多请求 1 到 2 次。

默认配置是每分钟 2 次，也可以在.env里改成 1 次。

类似配置：

PROMPT_GENERATOR_AI_ENABLED=True PROMPT_GENERATOR_AI_PROVIDER=GEMINI PROMPT_GENERATOR_AI_API_KEY=your_gemini_key PROMPT_GENERATOR_AI_RATE_LIMIT_PER_MINUTE=2

如果没有开启 AI 配置，页面仍然可以使用本地模板生成，不影响基础功能。

后端为什么不直接暴露 API Key？

AI 版 Prompt 生成不能把 API Key 放在前端。

如果把 Key 写进 JavaScript，任何人都能在浏览器里看到，风险很高。

所以正确方式是：

• 前端只提交用户输入；
• 后端保存 API Key；
• 后端调用 Gemini；
• 后端返回生成结果。

这样至少可以做到：

• API Key 不暴露；
• 可以做限流；
• 可以统一处理错误；
• 后续可以接入日志和风控。

工具箱做多之后，分类也很重要

工具数量变多以后，工具首页不能只是简单堆卡片。

所以我给工具首页加了分类筛选，比如：

• 图片处理；
• 开发工具；
• 编码转换；
• SEO 工具；
• 生成器；
• AI 工具。

这样用户进入工具箱后，可以更快找到自己需要的工具。

这对体验和 SEO 都有帮助。

工具箱首页：

https://leedu.ac.cn/tools/

这次更新后的工具方向

目前工具箱已经不只是图片压缩这种单点工具，而是慢慢扩展成几个方向：

整体思路还是一样：

能本地处理的尽量本地处理；必须走后端的功能，就明确说明边界并加限制。

这次迭代的几个收获

这次继续扩展工具箱，我有几个比较明显的感受。

1. 小工具也需要工程化

单独做一个工具很简单。

但工具越来越多以后，就需要统一处理：

• 路由；
• 模板；
• CSS；
• JS；
• SEO meta；
• sitemap；
• 工具首页入口；
• 后台访问统计；
• 移动端适配；
• 静态资源加载。

否则后面会越来越难维护。

2. 纯前端不是唯一答案

大部分工具确实适合纯前端，比如图片处理、JSON 格式化、颜色转换、Token 计算。

但像 AI Prompt 生成这种功能，就需要后端参与。

关键不是强行纯前端，而是区分清楚：

• 哪些数据可以留在浏览器本地；
• 哪些功能必须调用后端；
• 哪些内容需要提示用户会提交到服务器；
• 哪些接口必须做限流和保护。

3. 性能细节不能忽略

Token 计算器里的 tokenizer 文件比较大。

如果一开始就全部加载，会影响页面速度。

改成按需加载后，页面初始体验会更好。

这类细节虽然不是核心功能，但对长期使用体验很重要。

4. 工具页也适合做长尾 SEO

每个工具其实都有独立搜索意图。

比如：

• 在线 Token 计算器；
• AI 提示词生成器；
• CSV 转 JSON；
• YAML 转 JSON；
• SQL 格式化；
• Cron 表达式解析；
• 图片尺寸调整工具。

如果每个页面都有明确标题、描述、FAQ 和独立 URL，就比把所有工具塞在一个页面里更适合搜索收录。

后续还准备做什么？

后面我可能继续补一些更高频的小工具，比如：

• Markdown 转 HTML；
• Open Graph 预览；
• FAQ Schema 生成器；
• robots.txt 生成器；
• HTTP 状态码查询；
• Nginx rewrite 辅助工具；
• User-Agent 解析；
• 正则表达式常用示例库；
• API 请求参数格式化工具。

不过我不会为了数量盲目增加工具。

优先级还是看两个标准：

1. 我自己是否经常用；
2. 是否有明确搜索需求，适合带来长尾流量。

总结

这次工具箱更新，主要补了两类能力。

一类是开发者高频工具，比如 CSV 转 JSON、YAML / JSON 互转、Cron 解析、SQL 格式化、JSON 转 TypeScript。

另一类是 AI 相关工具，比如 Token 计算器和 AI 提示词生成器。

相比第一版，这次最大的变化是开始引入“有限后端能力”。

大部分工具仍然坚持浏览器本地处理。

但 AI Prompt 生成这种必须调用模型的功能，就放到 Django 后端，并加上开关、API Key 保护和 IP 限流。

我觉得这也是个人博客工具箱比较适合的演进方式：

先把纯前端高频工具做好，再谨慎加入少量后端增强能力。

这样既能保证工具可用，又不会让系统复杂度一下子失控。

工具箱地址：

https://leedu.ac.cn/tools/