Simon Willison 在 2026 年 4 月 24 日发布了一个小工具：Millisecond Converter。起因很简单，他使用的 LLM 工具会用 milliseconds 报告 prompt durations，他厌烦了每次都要手动把毫秒换算成秒和分钟。

这事很小，小到不像一条“大新闻”。但它暴露的问题不小：AI 工具链正在变复杂，指标越来越多，日志越来越密，偏偏最基础的可读性还经常靠用户脑补。

Millisecond Converter 解决的是一个每天割人的小麻烦

原文信息很短：工具名是 Millisecond Converter，作者是 Simon Willison，发布时间是 2026-04-24。它服务的场景也很明确：频繁查看 LLM 调用耗时、调试 prompt 性能的开发者。

项目信息影响
工具Millisecond Converter把毫秒耗时转成人更直观的秒、分钟
作者Simon Willison长期关注 LLM、开发者工具和 Datasette 生态
触发原因LLM 报告 prompt durations 使用 milliseconds开发者要反复心算或另开工具
受影响对象LLM 工具链开发者、prompt 调试者排查延迟、比较调用成本时更省脑力

毫秒不是错。系统日志、监控指标、API 返回值用毫秒很正常。错在工具把机器友好的单位当成用户界面，默认让开发者自己完成最后一米翻译。

这类摩擦不会让系统崩溃，却会让人烦。一次换算只要两秒，一天几十次就开始磨人。开发者体验的坏，很多时候不是一个巨大缺陷，而是一堆没人愿意修的小刺。

AI 工具链越复杂，越不能把可读性外包给用户

LLM 开发和传统后端调试不太一样。开发者盯的不只是错误码，还要看 token、上下文长度、模型延迟、工具调用链、缓存命中、成本估算。指标本来就多，再把基础单位做得不顺手，就是在加税。

行业里常见的做法是：底层系统输出原始指标，开发者自己接 Grafana、写脚本、开计算器。云服务监控早就经历过这一轮。早年的服务器指标也爱把字节、毫秒、请求数原样倒出来，后来成熟产品学会了同时给 raw value 和 human-readable value。不是因为工程师不会算，而是好工具不该逼人算。

“工欲善其事，必先利其器。”这句话用在这里不宏大。器不一定是 IDE、框架、模型平台，也可以是一个单位换算器。利器的标准很朴素：它把重复、低价值、容易出错的脑力劳动拿走。

这也是我更在意的点。AI 产品今天爱讲 agent、workflow、autonomy，听起来都很大。但大量开发者每天真正碰到的，是日志难读、耗时不直观、错误信息含混、trace 断在半路。大叙事很满，手边工具很糙。

小工具不该被拔高，但它指向了一个观察变量

不能把 Millisecond Converter 夸成什么行业转折。它只是一个小工具，也没有原文证据显示它有复杂功能、用户规模或商业计划。把它写成产品发布会级别的事件，是对事实不负责。

但它适合拿来当一面小镜子。接下来真正该观察的，不是这个换算器会不会火，而是 LLM 工具链会不会把类似能力内置进去：耗时能不能自动显示为 1.7s、2m 13s；成本能不能直接对应到一次调用；trace 能不能让人一眼看出慢在哪里。

对 AI/LLM 工具链开发者来说，这影响的是日常动作：调 prompt 时少一次心算，排延迟时少一次复制粘贴，和同事沟通性能时少一次“等一下我换算一下”。这些动作微小，但它们决定一个工具是顺手，还是硌手。

历史上很多好工具都从烦躁里长出来。Unix 管道、浏览器开发者工具、Git 的各种别名，本质上都在回答同一个问题：人不该为机器的表达方式长期让路。今天的 AI 工具也一样。模型可以复杂，界面不能偷懒。