0.1 版的 devpub 里有个 --graph，按下去什么都不发生；同一个时间段里，模型厂商的常规操作是先发 API、后补能力。两件事隔着行业和层位，动作是同构的：先把位置占了，再回来填东西。放在别的地方这叫偷懒，放在开源小工具的语境里，是一次很清醒的下注：接口位置比实现更值得先占。命令一旦进了别人的 muscle memory，后面补实现是加法；反过来，功能先做完再回头想参数该叫什么，就得去说服一批已经把旧命令敲进手里的人改手。多数人不愿意承认自己 0.1 阶段的产品里可以有一个按下去没反应的入口，其实该承认，模型厂商就是这么干的。
8 月 21 日那篇讲 devpub 加终端图表的文章，我读下来最值钱的不是任何一张渲染图，就是这句被轻描淡写带过去的话。但这不是我这次想讲的。我想讲的是那几个被硬编码进去的东西：看着是渲染细节，实际上是一整套关于"该怎么看数据"的立场，被人一行行写进了代码里。
把镜头拉远一点，这个工具在三层棋盘里几乎是没有体积的。最底下是数据源，Dev.to 的 API，配一个环境变量就完事，作者一行都不用维护；中间是渲染层，Rich 加上大约两百行手写的绘图逻辑，管渐变、坐标轴、sparkline；最上面是场景层，你的 shell、你的 alias、你的补全、你每天敲进去的那双手。全部分量压在第三层。而第三层那点分量还不是它自己攒的，是它不去打扰你这件事攒出来的。
作者随口交代的动机很朴素：以前查一次数据要切浏览器、点仪表盘、等加载，三步没有一步重，合起来就足以让人放弃查。这解释的其实是仪表盘这几年失宠的原因。仪表盘从来没有被谁打败，它只是需要你专门走过去一趟；一旦有东西能让你在原本就站着的地方看到同样的数字，哪怕画得丑十倍，你也会选丑的那个。上一轮发生同样搬家的是监控面板往编辑器侧栏挪，再往前是运维大屏往工程师个人面板挪。每一轮都不是因为新位置更好看，是因为新位置离手更近。
说回那几处被硬编码的判断。
最显眼的是四个 sparkline 并排，7 天、14 天、21 天、30 天。作者自己的示例数据里，30 天是 -18%，7 天是 +9%，两个数同时成立，一个说他账号在退潮，一个说在回升。任何单一周期的图都会给你一个斩钉截铁的答案，并排四个的结果是你没法只看一个。把四行字符塞进终端其实是负担，这个设计不是为了界面丰富，它的作用是在结构上逼你承认：趋势这句话必须带时间窗口，不带窗口的趋势表达是残缺的。我在这个号里讲过很多遍"单点新闻不构成判断依据"，换成工具的语言就是"单周期趋势不构成结论"；作者把它做成了默认视图，等于每打开一次就提醒一次。
再看 -p 90d 自动降采样这件事。终端宽度是有限的，90 天塞进八十列，每根柱子会窄于一个字符的物理分辨率，这时候画出来的不是 90 天的数据，是 90 天的混叠。降采样是个数据处理细节，背后的规则却是：分辨率必须跟你要看的时间尺度匹配，不匹配的时候该丢的是细节，不是尺度。反过来也一样，在终端里拿 30 天的分辨率硬看 7 天，周末周期照样看不出来。这条规则做产品的人经常忘，做分析的人经常也忘。
那条平均值虚线也值得单拎出来。作者举的例子很好：某一天 500 次浏览，跟 871 的峰值一比显得很寒酸，但它仍然高于日均。这里被点破的是件很朴素、却很少被工具设计者正面处理的事，绝对值没有意义，参照系才有意义。峰值是一个参照系，均值是另一个参照系，同样的 500 在两个参照系里是两个完全不同的故事。默认给你两个参照系，等于默认你会在它们之间来回切着看。
颜色分级也是一个道理，按当根柱高相对窗口内最大值的比例来分，95% 以上才给金色。注意是相对最大值，不是某个绝对阈值。这意味着同样的 500 次浏览，在你流量巅峰的那个月是蓝色的，在你刚起步的那个月是金色的；单看某个月的一张截图，你判断不出这个账号处在什么状态，必须先知道参照的最大值在哪。一条看着只是美化的设计，就这么变成了防止跨期误读的装置。
跟仪表盘的分野在这里就出来了。仪表盘默认你专门来看，所以它的目标是"把所有指标放在一个地方"；这东西默认你只是路过，所以它的目标是"只给你一个指标，但给你四个参照系"。同一份数据，两种默认，对应两种使用场合；场合决定什么该被默认、什么该被藏起来。
另外还有个地方不走寻常路：作者说评估过几个现成的终端图表库，最后决定自己写，理由是那些要么依赖偏重，要么输出没法跟 Rich 的标记系统整合。这两条理由都是真的，但我认为都不是最根本的。
一个 CLI 工具对依赖的克制，看着像审美，其实是分发结构逼出来的。你想让一个陌生人在三十秒内装上并跑起来，pip install 后面跟的包越少越好，因为每多一个包就多一次版本冲突的机会、多一层供应链信任审查、多一条"我们公司不让装"的可能。小工具的用户获取成本是按安装摩擦计的，不是按功能列表计的。于是作者自己写了大约两百行，配了 41 个测试，测试代码量跟实现代码量差不了多少。这个比例不是工程师洁癖，是没有 UI 兜底的人必须付的保险：终端里一个除零就是整屏崩掉，没有降级方案，所以零数据、只有一天数据、账号大到 90 天窗口放不下，这三种边界必须挨个测到。这笔账在浏览器里做产品的人不用算，因为浏览器有 DOM，实在不行还能显示个"加载失败"。
我认为这类"把读数做回手边"的工具会一波一波地继续冒出来，驱动力是结构性的：上游平台把 API 开出来的成本很低，下游每个人的注意力都在变得更容易流失、更不愿意为"专门走过去看一眼"付一次跳转。只要这两件事不变，中间那层做"顺手看一眼"的工具就持续被需要，而且会一直以小体积、零依赖、单人维护的形态出现。大公司做不了这么小的东西，边际收益太薄，做出来也没法在报表上讲。
但它的天花板不在自己的工程质量上，在上游 API 的开放程度上。这个工具的全部原料是别人的接口，它的护城河扎在场景层，原料却握在别人手里，这两件事同时为真，就是这类工具最别扭的处境。去年我讨论模型厂商向下游扩张、挤压独立工具厂商的时候，用的就是这套结构，只是那时候棋盘更大、层位更值钱；现在换到一个个人博客数据的小场景，机制没变：你能锁住的只有用户的习惯，锁不住上游愿不愿意继续喂你。这不是劝人别做，是说别把"能留住用户"和"能一直活下去"当成同一件事。
这里顺便认个错。前面我写"这个工具的全部分量压在第三层"，写着写着觉得不准确。场景层的分量是真的，但它不是这个工具自己挣来的，是借来的。用户愿意接受一个新命令，是因为这个命令解决的是他已经存在的痒处，不是工具教会了他一个新需求。准确点说，它占住了一个已经存在的入口，而不是造了一个新入口。这两件事在做判断时必须分开。我在别的地方把这两件事混过一次，把"用起来顺手"当成了"有黏性"，那次连带的判断方向也跟着偏了，记在这里。
我压的重注是这一条：这类工具的长期价值不在可视化能力上，在它默认给你哪个参照系。越是把多周期、降采样、均值参照这些判断逻辑做进默认视图的，越不容易被替换，因为换个壳容易，换个默认视角很难，用户对"第一眼看到的那个数"是有肌肉记忆的。至于绘图库、配色、sparkline 用几个字符，都是实现细节，谁都能抄。
证伪条件给出来：如果接下来一年里，Dev.to 这类平台自己开始提供等价的编辑器内嵌集成，或者收紧第三方 API 的调用口径，那这个判断就该扔掉，换成"这一层的价值会整体回流到平台手里，独立小工具只剩极窄的缝隙"，上面那套"场景层会持续被需要"的推论也就不成立了。