小工具做出「专业感」的 5 个细节：从 CronLab 说起

昨天我写了个小工具 CronLab：输入 0 9 * * 1-5，它告诉你是「09:00，周一至周五」，并列出接下来 5 次运行时间。功能很小，但做完之后我意识到：同样的功能，做成"能用"和做成"看起来专业"，差别全在几个不起眼的细节上。

这篇把这几个细节拆开讲，它们和 Cron 本身无关，可以搬到任何工具类项目里。

一、错误提示要精确到"哪个字段、合法范围是多少"

最容易被忽略、但用户感知最强的就是这个。

对比两种提示：

• ❌ 表达式不合法
• ✅ 分钟字段取值 60 超出范围（0-59）

第二种为什么能做到？因为我在设计数据结构时就把元信息挂在了字段上：

{ name:'minute', label:'分钟', min:0, max:59 }

所有校验都走同一个 toInt()，失败时直接用 label + min/max 拼消息。这样提示天生精确，而且新增字段时不用再写一套文案。

这是一次设计上的"前置"：如果一开始只想着"把字符串切成数字"，遇到错误就只能给一句笼统的兜底话。

二、文案按"形态"组织，而不是按数值拼接

第一版解释是逐字段拼的，输出长这样：

每第 0 分钟，9 点，仅 周一、周二、周三、周四、周五

机器味十足。问题不在语言能力，而在描述方式：我在用"数值"描述，而人看的是"形态"。

改成先判断形态，再决定措辞：

于是同一个表达式变成了 09:00，周一至周五——一眼就懂。

方法论：把"输出什么"换成"用户脑子里想看到什么形状"，再反推渲染逻辑。

三、给"最常用"留一键入口

工具类产品的使用分布极度不均：大多数时候用户只想问那五六种经典表达式。所以我在输入框下面放了一排预设：每分钟 / 每 5 分钟 / 每小时整点 / 工作日 09:00 / 每天 02:30 / 每月 1 号 / 每周日 12:00。

点一下等于"填入 + 立即解析"，并且当前命中的预设会高亮。这一个小设计，把首次使用的成功路径从"我要先学会写 Cron"变成"我认得出哪个是我要的"。

四、把"隐含假设"显式写在界面上

所有时间计算都依赖一个隐含前提：按哪个时区算？

大多数工具不说，用户就得猜。我在右上角放了两个徽章：当前时区（含 UTC 偏移）和实时时钟。这样"接下来 5 次运行时间"这些数字立刻有了坐标，用户不用怀疑"这是服务器时间还是我的时间"。

同样的道理也适用于"数据去哪了"——我在页脚直接写明：纯前端、零依赖、不联网、所有计算在本地完成。信任是靠明示换来的，不是靠用户推断。

五、主动声明"已知边界"

这个项目只实现了标准 5 段式，没有 秒 字段、没有 @daily 这类宏、没有 L/W/# 扩展语法，也不处理夏令时切换的特殊情况。

这些我全部写进了 README 的「已知边界」一节。

看起来像自曝其短，实际效果相反：用户遇到不支持的写法时，会认为是"范围之外"，而不是"这工具坏了"。声明边界不是减分项，而是可信度的一部分——真正减分的是让人踩了坑才发现。

六、一个反面教训：块注释里的 */

最后说个真实的低级错误。我在文件头写说明时写了：

字段语法：*  数字  a-b  a-b/n  */n  a,b,c

这段注释里的 */n 直接把块注释提前闭合了，导致整个文件语法错误。我第一次跑测试就撞上。

教训很朴素：写完立刻跑一次。这个错误的发现成本是 10 秒（node test.js），如果等到发布后才发现，成本会翻几十倍。

小结

这五个细节可以浓缩成一句话：把"用户会怎么误解"当成设计输入。

• 报错精确 → 用户不用猜哪里错
• 文案按形态 → 用户不用二次翻译
• 设好预设 → 用户不用先学会语法
• 显式声明时区与数据边界 → 用户不用怀疑
• 主动写清不支持什么 → 用户不会误判成故障

功能决定工具能不能用，这些细节决定用户愿不愿意继续用。