讲个我自己的真实感受：给图表写代码的时候，我用过各种各样把“大数字”塞给用户的方式——折线图、柱状图、词云、数字滚动动画，做得越花哨，用户越麻木。后来我意识到，问题的根源不在于图表丑不丑，而在于“量级”这两个字。
magnitude，物理里叫量级，数学里叫模，天文里直接借去当星等刻度。它描述的是一件事：一个数字到底处在宇宙坐标尺的哪一格？人类大脑对线性数量很敏感——2个苹果比1个苹果多一倍，这谁都懂；但“120泽字节”和“1.5吉字节”放在你面前时，你只知道自己看到了两个很大的词，却完全不知道它们之间隔着多少重天。
我花了两周业余时间做了一个叫 magnitude 的小工具，干的事情很简单：给任何数值自动找一个“人话版”参照系。比如你输入“1纳米”，它不会给你一个冷冰冰的科学计数法，而会告诉你“这大概是一根头发直径的八万分之一”；你输入“全球数据总量120ZB”，它会换算成“地球上每个人分到约15.7TB，相当于每人手边摞着35块3TB移动硬盘”。听起来像是会来事儿的瘦身版维基百科，对吧？但这玩意儿背后藏着一整套量级判断的算法和一堆坑，我觉得值得展开聊聊。
1. 为什么要做“量级感知”这个工具：大脑天生不擅长指数刻度
1.1 你的直觉在10^6这个数字上失效了
先做个小测试。想象一下，一栋楼高30米，珠穆朗玛峰高8848米，地球到月球的距离约38.4万公里，光走一年的距离约9.46万亿公里。现在回答我：珠峰大约是那栋楼的多少倍？地球到月球的路程又能铺多少座珠峰？
如果你和我一样，前两个问题还能靠直觉估个大概，到“光年”那里就开始犯迷糊了——不是不会算，是算了也没用。因为“9.46万亿”这个数字在脑子里没法被具象化，它只是一串需要数位数的符号。认知科学里有个经典结论：人对超过100的数量就基本丧失直觉，对超过10000的数量的感知几乎是靠语言习惯硬撑的。我们在图表里看到的“120ZB”和“1.5GB”，在视觉上都是一根一样长的数据条，人眼完全无法区分它们之间的差异。
这还不是最麻烦的。麻烦在于，当数量差异跨越好几个数量级时，线性思维会让人做出荒谬的判断。你以为“万”和“亿”差得没那么远，实际上差了1万倍，这个差距比你和蓝鲸的体重差距还大。写代码时一个数值单位写错，从MB写成GB，数据量瞬间放大1024倍，这在生产环境里就是事故。很多大数据系统跑崩了，追根溯源不是算法复杂度的问题，而是早期某个地方把一个代表“百万”的常量写成了“十亿”。
我最初想做的，其实只是给自己的数据处理工具链加一个“数值合理性提醒”：在打印日志时顺带输出这个数的量级和参照物。后来发现这功能太有用了，干脆单独拆成一个库，也就是 magnitude。
1.2 星等、震级、pH值：人类早就学会了对数思考
为什么量级这么重要？因为自然界真正有意思的变化，几乎全是数量的指数级变化，而不是线性变化。你看天文学家给星星亮度的分级——星等，每差一等亮度就差大约2.512倍。这个刻度从古希腊的喜帕恰斯一直用到现在，本质上就是一个对数刻度，因为它能让“肉眼可见的星星”和“哈勃望远镜看到的暗弱星系”都在一个好用的尺度范围内表达。
地震的里氏震级也一个道理。震级每增加1，释放的能量约增加31.6倍；震级从6到7，看起来不过跨了一格，能量差异却超过一个数量级。pH值、分贝、摄氏度的热力学温度换标，全是对数或者半对数刻度。为什么这么多学科不约而同地选择对数？因为这直接匹配了人类的感觉机制——耳朵对声音响度的感知是近似对数的，眼睛对亮度的感知也是近似对数的，我们的感官本身就是一台对数刻度仪器。
工程上更不用说。估算系统容量时，老手都会先问“现在是千兆级还是太字节级”——先确定量级，再谈具体数值。因为量级决定架构，具体数字只决定参数配置。量级判断错误的后果，远大于同一量级内30%的估算误差。所以我一直觉得，“能瞬间判断一个数在哪个量级”是数据工程师和科学传播者必须具备的素养，可惜这素养没法靠自觉获得，得靠工具辅助。
因此我给 magnitude 定的核心目标就是两件事：第一，把任意数值映射到正确的量级网格上；第二，为这个量级提供一个“有身体感”的参照物，让读者不靠计算就能重建直觉。
2. 从科学领域偷师：对数标尺的底层原理拆解
2.1 一个数字怎么从“无感”变得“可感”
先摆结论：一个数字要被感知，必须完成一次“锚定”，也就是和一个具体物体、具体事件建立换算关系。孤零零的“10^7秒”是没感觉的，但“10^7秒大约是115天”就有感觉了，如果再进一步，“115天差不多是一个半学期”，感觉就更立体了。
问题是怎么自动完成这种锚定。我最早想到的笨办法是：为每个常见的单位建一张类比表，比如“米”对应头发直径、篮球场、珠峰、地球半径等。这样输入多少米就直接查表，仿佛一本通。但很快就撞墙了——实际输入的数值是连续的，掺着各种单位（英里、光年、毫米、微米），一个亿米的数字需要的是“地球周长的四分之一”这种量级类比，而不是查表能覆盖的。
所以我换了个思路：不要试图匹配具体数值，只匹配量级。这是整个工具最核心的算法哲学。
具体来说，处理过程分三步：
- 单位规范化。把任意单位统一换算成一组基准标量（我选了秒、米、千克、字节、摄氏度等几个维度），保证后续计算可比。
- 对数取整。对规范化后的数值做 log10(x)，取整数部分，得到它在10^k网格上的位置。
- 量级匹配。在锚点库中查找同量级或邻近量级里“身体感最强”的条目，用比例关系构造类比句。
这里有一个看起来反直觉、但实际非常有效的细节：锚点库里的物体不需要精确数值，只需要一个“约莫”条目就够了。比如蓝鲸质量我记的是“约180吨”，而不是“172.4吨”（不同资料差异本来就很大）。为什么？因为量级感知本来就自带容错，只要不跨数量级，你给出的类比脂肪含量不会有可感知的错误。用户关心的是“相当于多少头蓝鲸”，而不是“相当于0.87头蓝鲸”——后者反而显得不伦不类。
2.2 参照系才是量级的灵魂：锚点、可观测对象与比例映射
锚点库的质量决定这个工具的上限。纯粹把数据库里的冷冰冰数字拿出来排一排，生成“1光年≈63241天文单位”，用户依然无感。因为天文单位本身并不比光年更好懂。要找那些身体上、生活里、直觉里已经根深蒂固的东西：头发的直径、一辆小轿车的重量（约1.5吨）、一座足球场的大小（约7000平方米）、一个成年人步行一小时的距离（约5公里）。
我因此在锚点库里给每个条目加了两个字段：一个是“基础参照度”，表示这东西在普通人心里的熟悉程度；另一个是“风险度”，表示如果类比失准会造成多大的误导。最终生成的类比句会优先选基础参照度高的条目，同时避免风险度高的条目。比如“超级大”这个概念，用“相当于多少个地球”比用“相当于多少艘航母”更容易让公众建立感知，但“多少个地球”同时也更宏大，容易让人失去比较的耐心，所以这类条目我会单独做一个“宏大模式”，在用户明确需要“宇宙尺度的震撼感”时才启用。
比例映射也很有讲究。一个数字如果是10^6.5，对数取整后落在10^6量级，锚点库里最匹配的条目可能是10^6.3的“一栋高层建筑的质量”。我不会直接说“X相当于一栋高层建筑”，而是先算比例倍数，再输出“X约等于1.6栋高层建筑”。事实上，当比值小于0.1或大于10时，我会强制向上或向下跳一个量级寻找锚点，因为这时候硬讲倍数已经超出直觉范围了。比如一个物体质量是10^5千克，对比10^6千克的“蓝鲸”会得到“0.1头蓝鲸”——这个表述太别扭，我会直接跳到10^5量级里找别的参照物，比如“一辆重卡”。
这套设计让 magnitude 的核心逻辑非常干净：它不试图“理解”数值背后的物理意义，它只负责在一个合理的参照网络上做插值。你给它一堆字节数，它不会真的明白“数据”是什么，但它能告诉你“这个量级的字节数大约是《战争与和平》全本的多少倍”。
3. 落地实现：magnitude 工具的核心模块设计与技术选型
3.1 核心数据结构：把一切量纲统一成“可比较的标量”
回到代码层面。我选了 TypeScript，没选 Python——虽然 Python 做算法原型更顺手，但 magnitude 的定位是一个可以内嵌到前端图表、命令行工具和编辑器插件里的跨环境库，TypeScript 能同时服务浏览器和 Node 端，省去来回封装。
先看核心类型设计：
type Dimension = 'time' | 'length' | 'mass' | 'bytes' | 'temperature' | 'speed'; interface Quantity { value: number; // 规范化后的数值 dimension: Dimension; // 物理量纲 } interface MagnitudeReference { id: string; magnitude: number; // log10(normalizedValue) dimension: Dimension; title: string; // 最直观的称呼，如 “一根头发直径” description: string; // 补充说明，可选 familiarity: number; // 1-10，普通人熟悉程度 risk: number; // 1-10，类比失准的误导风险 }这里最容易被忽略的是“规范化后的数值”这个字段。拿到用户输入时，第一步不是 log，而是先把单位换掉。例如输入“3.6e6 km/h”不能直接当成一个数值处理，得先转成“m/s”；输入“5 TB”要讨论清楚是十进制字节还是二进制字节。我后面单独做了个单位换算表，把同一量纲下的所有常见单位都归一化到基准单位，避免出现“5千公里”和“5×10^8厘米”被当成完全不同的量级。
这个数据结构还有一个好处：锚点库可以随插随用。默认库大概有200多条，覆盖时间、长度、质量、数据量、温度、速度六大维度。你可以自己往里面加“我家小区的面积”“常坐的那条地铁线全长”这种私人化参照物，magnitude 会自动让它们参与匹配。社区里已经有人贡献了“一只成年橘猫的平均质量是4.5公斤”这种生活化锚点，效果好得出奇。
3.2 生成“量级类比”的三步算法
算法主体很直白，核心代码如下：
function generateComparison(input: Quantity, references: MagnitudeReference[]) { const logVal = Math.log10(input.value); const baseMagnitude = Math.floor(logVal); // 取整，得到量级网格位置 let best = null; let bestScore = -Infinity; for (const ref of references) { if (ref.dimension !== input.dimension) continue; // 量级不能差太远，但允许邻近一格，以便找到更“体感”的参照物 const magDistance = Math.abs(ref.magnitude - logVal); if (magDistance > 1.2) continue; // 综合距离、熟悉度和风险，计算一个评分 const score = -magDistance * 3 + ref.familiarity * 1.5 - ref.risk * 1.8; if (score > bestScore) { bestScore = score; best = ref; } } if (!best) return fallbackMessage(input); const ratio = Math.pow(10, logVal - best.magnitude); return formatComparison(input, best, ratio); }几个值得展开的点：
第一，为什么量级距离允许到1.2而不是严格等于0？因为同一个量级里可能只有“原子核直径”这种谁也不熟的参照物，那不如跳一档找一个“一粒盐”更有体感。1.2这个阈值是我调出来的，太大容易产生“3天≈0.01年”这种语义上有道理但体感上没帮助的类比，太小则经常找不到合适的参照物。
第二，评分函数里的权重是自己试出来的。熟悉度权重1.5、风险权重1.8，说明我宁可选一个稍微陌生一点的参照物，也不选一个容易误导人的。典型的误导例子：早期锚点库里有一条“一座金字塔的质量约600万吨”，风险度很高，因为不同资料对胡夫金字塔的质量估算从500万吨到700万吨都有，差值刚好横跨一个量级边缘，输出“相当于0.9座金字塔”会给人虚假的精确感。后来我把它改成风险5、熟悉度6，匹配优先级大降。
第三，fallbackMessage。当静态锚点库找不到合适参照物时，我会退化成纯数学描述：“10^9.7量级，大约是10,000,000,000的1/5”。这不太有“人味”，但比给一个错误类比强。后来我发现，多准备几个常见维度的固定锚点（比如字节维度里“一本300页小说的纯文本约300KB”），这种fallback其实很少被触发。
3.3 技术栈与界面设计（为什么展示层要突出“差异感”）
magnitude 的 Web 端做得特别克制。页面就一个巨大的输入框，输入数值和单位后，下方输出三样东西：量级定位（一个可在数量级网格上滑动的点）、主类比句、以及“如果你觉得这个数字大/小，那请看看这些”的补充列表。没有仪表盘、没有炫光特效，因为我把所有精力都花在了一个看似不起眼的设计细节上——对数轴可视化。
对数轴是这整个工具的视觉灵魂。很多数据可视化工具默认都用线性轴，数量级差异巨大的数据一放上去，小数字直接被压成一条贴着坐标轴的线，大数字又冲出屏幕，你看不到任何结构。对数轴则不同，10^1到10^2的距离，和10^6到10^7的距离，在屏幕上是等长的。这个特性天然适合展示“跨越多数量级”的数据——它能让你直观看到“尘埃、蚂蚁、人、蓝鲸、珠峰、地球、太阳、银河系”这8个物体在对数轴上的间距分布，而不是让“地球”和“太阳”的柱子长得天差地别。
我最终用了 d3-scale 里的 scaleLog 做轴的映射，配合一个可拖拽的参考点，用户拖动数值时能听到一声轻微的“咔哒”声——这其实是量级切换的触感反馈。你拖动滑块从10^0到10^9，每一格都是一个数量级，那种“跨格”的手感，比任何图表都能有效建立量级直觉。
前端之外，这个工具还做成了一件事：一个可以直接在命令行里用的 CLI 版本。用过一次之后你就知道为什么它比 Web 端更实用——比如你正在写一个 Shell 脚本查磁盘占用，输出里面突然出现了“8.1e12 bytes”，你不太确定这意味着什么，直接管道给magnitude，一秒得到答案：“相当于大约24块4TB移动硬盘”。
4. 实战效果与典型用例：从新闻编辑辅助到课堂演示
4.1 处理“1纳米”到“137亿光年”：我的实测样本
来几个实际输出，都是我开发过程中不断用来校准的测试用例：
| 输入 | 输出类比（节选） |
|---|---|
| 1纳米 | 大约是你指甲厚度的十万分之一，比一个氢原子直径（约0.1纳米）大10倍 |
| 1光年 | 约等于9.46万亿公里；如果按日行1000公里计算，需要走2600万年 |
| 一杯水（250毫升） | 约含8.4×10^24个水分子，相当于全世界海岸线上沙粒总数的数千倍 |
| 全球数据总量（约120ZB） | 地球上每个人平均约15.7TB，人手两块3TB移动硬盘再加一台2TB笔记本才勉强装下 |
| 5G蜂窝基站的最大速率（10Gbps） | 约等于每秒下载完1.25GB，一个高清电影大约16秒下完；比当年56Kbps拨号上网快18万倍 |
第一感和第二感往往是相反的。“1纳米”的类比里，“比氢原子大10倍”其实比“指甲厚度的十万分之一”更有利于建立尺度感，因为后者是在拿一个难以量化的“指甲厚度”再去拆分，读者还得再算一层。所以我在输出主类比句时，加了自动选择逻辑：如果参照物本身的数值超出一般人的感知区间（比如“指甲厚度”虽然具体，但大部分人并不知道指甲厚度到底是0.1毫米还是1毫米），就自动补一个更底层的参照物作二阶锚定。
第二个有价值的细节是“字节类”的类比。全球数据总量这种宏大概率冲击力已经够强，反而容易让人“哦”一声就翻过去。所以我在宏大模式下会故意用“人均”来降维：120ZB除以80亿人口，得到“每人15.7TB”——这个数字依然大，但大得具体，是有形的。人可以想象自己家抽屉里堆着几块硬盘，而想象不了“ZB”这个抽象单位。
4.2 新闻编辑在数据可视化中如何使用它
做博客和新闻的朋友其实是最早一批追着我提需求的用户。新闻编辑处理数据叙事时有一个刚需：把官方通稿里的“同比增长32.4%”“累计完成投资额873亿元”之类的数字，翻译成读者能有体感的表达。
这里有个常见的错误示范：编辑喜欢用“相当于绕地球XX圈”来换算一切距离。比如“某新建公路线全长1200公里，相当于绕地球三十分之一圈”——这其实无效类比，因为读者对“绕地球一圈”同样没有身体感。magnitude 处理这类问题的思路是：先找这个数字所在的量级，再看同量级里有哪些“日常高频参照物”。
比如1200公里，它真正的量级是10^6米，锚点库里最匹配的不是“地球周长”，而是“北京到上海的高速公路距离约1200公里”和“成年人步行2万小时（约833天）”。前者直接把抽象距离映射到一条大众熟知的路线，后者则把距离折换成一种时间上的付出感——这两种类比都比“绕地球一圈”有效得多。
我在 Web 端加了一个“编辑助手”模式，专门服务这类场景：输入一组数据和单位后，会批量生成每个数对应的类比句，并按“是否具备出版价值”排序。这个模式现在已经被一些小众新闻编辑室和教育机构用在选题会上，他们在讨论数据稿时不再空对空聊“这个数字大不大”，而是争论“这个类比会不会误导读者”——这种深化，是我一开始没想到的。
教育场景则更偏重“探索感”。老师把 magnitude 挂在教室大屏上，让学生从“1米”开始拖动数值滑块往大走：1米（课桌高度）、10米（公交车长度）、1000米（一公里）、10万米（卡门线，太空边界）、3.8亿米（地月距离）。拖动过程里，学生对“每个量级之间差了整整10倍”的感受极其强烈。小学高年级到初中的孩子尤其吃这一套，因为它在动手操作和抽象概念之间架了一座桥。
5. 踩坑与优化：我对量级工具做过的三次大改
5.1 过度精确反而摧毁了量级感知
第一版 magnitude 最大的毛病不是“不够准”，而是“太准”。我当时为了让自己心里舒坦，把锚点库里的每条参照物都标上了精确到小数点后两三位的数据——蓝鲸质量188.442吨、地球质量5.9722×10^24千克。输出类比时也照着这个精度来：“全球数据总量相当于138427946123456 块移动硬盘”。
等到自己念了一遍，才发现这完全是反效果的。数字一长，人的第一反应就是停止阅读，量级感知直接归零。精确到“多少块硬盘”的荒谬感，甚至超过了“120ZB”本身的冲击力。
后来我把所有输出改成了“最多保留两位有效数字”的规则，并且强制要求类比句用文字表达，不用纯数字堆砌。一个合格的类比句一定包含“量级词+具体参照物+一个操作动词”，比如“相当于把整个故宫的砖块重新数一遍”而不是“等于3.7×10^11块砖”。文字有操作感才有体感，数字只有量感。
这次改版也让我重新理解了“精度”的角色：量级感知工具需要的是降噪，不是降精度。你把不必要的尾数砍掉，反而更容易让人记住核心的比例关系。
5.2 单位换算陷阱：公制/英制、字节、还有“万亿”
提到单位换算，这里面的坑比一般人想象得多，而且全都翻过车。
第一层是十进制与二进制的冲突。字节领域的 KB/MB/GB 有两种定义：一种按十进制（1KB=1000B），一种按二进制（1KB=1024B）。SSD制造商喜欢用十进制，操作系统显示容量时默认用二进制，两边算下来，一块标称1TB的硬盘在电脑里格式化后只显示约931GB。magnitude 早期混用过这两种定义，导致输出“相当于多少块硬盘”时出现了0.9倍的偏差，这已经足够造成一个数量级边缘的误判。
我最后采用的策略是：统一按十进制字节处理，但在输出中明确标注“按1GB=10^9字节计算”。系统内部再单独维护一个“二进制换算开关”，需要精确和计算文件系统容量时切换成1024进制。这个开关必须显式暴露给用户，否则面对“已经用掉的磁盘空间”这种场景，计算结果会莫名其妙地差出7%——量级虽然没错，但工作流会崩溃。
第二层是公制英制混用。美国用户习惯英里、磅、华氏度，欧洲用户习惯公里、公斤、摄氏度。magnitude 虽然内部统一用国际标准单位计算，但输出类比句时必须调用本地化模板，把“相当于5辆小轿车重量”翻译成“相当于0.9头亚洲象”都算好的了，最难的是处理“英里/公里”这种同一维度下数值差异极大的单位，不处理好量级都不对。
第三层是中文的“万亿”陷阱。中文里“万”和“亿”是两个独立的数量级词，英文的 thousand/million/billion/trillion 也是。用户在输入“5万亿”这种表述时，脑子里想的是5×10^12，还是5×10^8？不加解析器的话，答案完全不可预期。我在解析层专门做了一个“中文大数解析器”，负责把“万亿”“兆”“京”这类单位转换成科学计数法标记，同时允许用户输入“千万”“百万”这种混合表达。上线后这个模块一度成了 bug 最密集的地方，但修完之后用户体验质的飞跃。
5.3 性能与离线使用：为什么我最后选择了本地优先
最初版本为了减少包体积，锚点库放在远程服务器上，前端通过接口拉取。后来发现这是个糟糕决策：
一是在线依赖让工具在离线环境基本不可用。而量级类比这种功能，恰恰在用户写论文、做汇报、赶稿子时最刚需，这些场景往往发生在网络不稳定或者完全断网的会议室、图书馆里。我收到了大量“为什么加载不出来”的反馈，才意识到本地嵌入才是核心使用场景。
二是性能问题。虽然单个请求不大，但每次输入都去请求一次很蠢，体验也割裂——每敲一个数字都要等网络，这完全违背了“瞬时反馈建立直觉”的产品逻辑。
最终我改成了“本地优先”架构：锚点库编译进包体，压缩后大概25KB；纯 TypeScript 实现，零运行时依赖；Core 计算部分用 Web Worker 跑（数据量虽小，但为将来支持大量自定义锚点预留），主线程只负责渲染。Web 端和 CLI 端共用同一个核心库，保证两边的输出完全一致。这个改动让首屏加载从约1.2秒降到了几乎不可感知，离线场景也稳了。
性能优化过程中还发现一个有趣的事实：量级类比的核心运算极其轻量——200条锚点全部遍历一遍，加评分排序，也就是几十微秒的事。真正的性能瓶颈从来不在计算，而在单位解析和数值解析的正则表达式上。我最后给解析器加了缓存：同一个“数值+单位”组合第二次出现时直接走缓存，连解析都省了。
6. 后续可以怎么玩
6.1 集成到大语言模型应用里做数值校验
我最近在琢磨的一件事，是把 magnitude 作为 LLM 应用的一个“校验器”。大模型在生成包含数据的内容时，经常出现数值幻觉——它给出的“全球海洋含水量约13.2亿立方公里”“一只蚂蚁能举起超过自身重量50倍的东西”这种表述，在数值上可能是对也可能是错，但大部分情况下它自己并不知道值不值得信。
用 magnitude 做二级校验的思路是：模型生成了任何“数值+单位+名词实体”的元组，先把它丢给 magnitude 找量级锚点，再比对“该实体在现实世界中的已知量级”，差距超过一个数量级就发出警告。比如模型说“蓝鲸质量约3吨”时，magnitude 的量级匹配会发现“3吨”远低于蓝鲸锚点（约180吨），提示需要复核。这个方案落地成本很低，因为锚点库本身就是现成的“现实世界数值知识库”，但目前还没找到特别合适的接入点，我还在摸索中。
6.2 动态可视化与交互式对比
另一个更“好玩的”方向是动态对数轴交互。现在的 Web 端已经支持拖动滑块来探索数字位置，但我还想做一个“从1米到可观测宇宙半径”的纵向滚动页面——用户一路往下滚，每滚一个屏幕距离就是跨越5个数量级，沿途经过珠峰、飞机巡航高度、卫星轨道、月球、火星、太阳、太阳系边缘、奥尔特云，一直到可观测宇宙半径。这相当于把整个宇宙压缩在一根可以滚动的柱子里，每一帧都是一个量级锚点页面，视觉冲击力会比任何图表都强。
技术方案上，这个功能不需要新算法，只靠锚点库的扩展——把天文相关的条目补齐全，再给每个条目配一个全屏背景渐变图。已经搭了原型，目前卡在移动端的滚动性能上，因为对数轴滚动时每一帧的投影换算都得实时算，60帧要稳住没那么容易。不过这个方向我是铁了心要写完的，因为我自己在开发过程中就是靠这种“把一个巨大距离压缩成滚动体验”的方式，才真正建立了对宇宙尺度的敬畏感。
6.3 一句话的经验总结
如果看到这里的你也被量级迷住了，想做类似的事，我能给的最实在的建议是：不要一上来就想做“完美的单位解析器”或“无所不包的锚点库”，先把一个量纲跑通，再横向复制。我在长度量纲上花了三天就到了可用状态，但时间量纲的锚点库整整磨了一周半。因为时间的“身体感”藏在人生的刻度里——“从你出生到现在过了多少秒”这种锚点，和“地球形成至今多少秒”完全是两个层面的东西，处理起来差异极大。
还有一件事，我特别后悔当初没有一开始就加上反馈按钮。锚点库再精心，也永远会有“咦，这个类比我觉得不贴切”的时刻。让用户能一键提交“我觉得应该拿XX来比”，这个众包机制一旦运转起来，工具会自己长出最符合大众直觉的参照物库。这也是magnitude后来最活跃的社区贡献方向，贡献者里甚至有个高中物理老师，专门把每个条目的“课堂可演示性”打上了分，启发我加了 familiarity 这个字段。
量级感知这件事，说到底不是在教人数学，而是在帮人重建一种“大与小”的直觉秩序。数字本身没有意义，数字背后的参照系才赋予它意义。而 magnitude 这个工具，不过是一个帮你快速找到参照系的放大镜。
