1个开发者切了3个标签页后，搞出个零后端工具

写博客的人有个隐秘的仪式：写完最后一行，先复制到字数统计网站，再新开标签页算阅读时间，最后扔进可读性检测器。三个工具，三份粘贴，同一篇文章。

这种摩擦感攒了三个月，直到作者干脆自己动手——造了个一站式工具ReadMetric。

从"将就着用"到"不如自己造"

内容创作者天天盯着SEO、排版、互动数据，却容易忽略一个安静但关键的信号：阅读时长。研究显示，读者会主动根据时间承诺自我筛选。知道一篇文章是"4分钟"还是"12分钟"，会改变双方决策——作者调整预期，读者决定是否点开。

作者想要一个即时反馈的仪表盘：字数、阅读时间、可读性分数，打字时实时更新。

结果他做到了，而且方式有点反直觉——零后端、零数据库、零登录。

这个决定是刻意的。文本没必要离开浏览器，没有API调用，没有数据留存，没有账户体系。粘贴，看数据，关掉。就这么简单。

技术内容需要"诚实模式"

常规算法——字数除以平均阅读速度（约200-250词/分钟）——对普通文章够用，但技术内容会露馅。代码片段、URL、重度格式化的文本，阅读感知时间与散文完全不同。

作者加了个"技术内容"开关，把WPM估算往下调，承认读代码比读段落慢。一个小细节，让估算更诚实。

句子分割也是坑。按句号切分，会把小数点、缩写、省略号都误判为边界。作者迭代了几版，最终用正则表达式处理常见边界情况：

const sentences = text.split(/[.!?]+\s/).filter(s => s.trim().length > 0);

不完美，但实用。

音节计数是场冒险

Flesch-Kincaid可读性公式需要音节数，而英语音节计数在代码里……是个难题。没有完整词典查询，算法无法完美解决。作者用了基于元音分组和常见后缀规则的启发式方法，典型散文准确率约85-90%，够用来做"这好读吗"的直觉判断。

范围蔓延在单人项目里同样存在。作者最初只想做阅读时间和字数，然后"顺手"加了字符数，又加了句子数，再加可读性。每个功能都很小，但加起来让初始开发时间翻倍。

用户反馈让他往回退。第一版选项太多，精简到核心统计后，好评立刻上来。

纯客户端被低估了

不是每个工具都需要服务器。纯客户端的性能是即时的，隐私故事干净，后端零维护。作者用这次实践验证了一个观点：有时候，少即是多。

工具上线后，有用户在评论区问：会不会加导出PDF功能？作者回复说暂时不会，"保持轻量"是核心设计原则。另一个用户反馈，技术内容开关帮他发现一篇"看起来很短"的代码教程，实际阅读时间比预估长了近40%——这正是他造这个工具时想解决的问题。

你现在写东西时，会手动算阅读时间吗，还是干脆不管这个数字？