看 dev.to 单篇数据时，我只认三条口径

整理说明：本文整理自本系列发布后的复查记录，非新实测。口径是多轮复查里实际用过的办法，不是平台文档的转述；数字只作口径示例，不作当前数据的断言。

第一条：只认单篇 /stats 的 Infinity 口径

复查时每篇都打开它自己的 /stats 页，并切换到 Infinity。仪表盘上的区间显示（比如“<25”）不作精确数认定——它只说明落在某个区间，不等于一个具体数字。账号级的周 Analytics 也不归因到单篇：周总数涨了，不能说成是某一篇涨了。平均阅读时长只在卡片显示时记录，未显示的不推断；评论只记计数，不展开评论正文、不推断评论性质。

这条口径的实际意义是：同一批文章换一轮复查，数字必须能在同一口径下对上。上一轮合计与这一轮合计差多少，要能说出增量来自哪一篇、而不是笼统说“涨了”。例如有一轮里合计的增量全部来自新增的那一篇，旧篇合计与上一轮完全一致——这种对账只有在口径固定时才成立，口径一换，对账就没法做。

第二条：发布后 1 小时的数不作判定

本系列每篇发布后约 1 小时都会复查一次，但那次的数只记、不判定。样本不足时，一篇读数为 0 说明不了成败；一篇读数为 10 也说明不了趋势。判定要等后续多轮的同一口径复查，看它是否还在动、动了多少。

反例很容易犯：新篇刚发 1 小时读数是 0，就写“这篇没人看”；或者新篇 1 小时读数 10，就写“这篇成了”。本系列的复查记录里，这两种写法都没有用过——1 小时那次的记录永远只写“样本不足，不据此判定成败”，判定留给后面的轮次。

第三条：来源合计必须与读者合计对上

每篇的来源（Direct/Unknown、dev.to 等）加起来，要与该篇的读者数一致；全部篇的来源合计，也要与读者合计一致。对不上时先怀疑转写或口径，而不是先写结论。有一轮复查里，回执正文一处曾把 dev.to 来源写成 4，随后自行核对更正为 3——本系列采用更正后的 3，因为来源合计 74＋3＝77 才与读者合计 77 对得上。

同样，标题措辞以公开页实测为准。复查回执转写的部分篇名措辞与已发布标题不完全一致时，主题顺序与单篇计数不受影响，但引用篇名时不直接沿用转写，要以公开页为准。转写差异不掩盖，记下来、不用它作结论就行。

不用场景

如果你只关心某一篇写了什么，不需要这三条口径；它们服务的是连续复查、需要多轮对账的人。命令本身的用法看本系列各单篇，不在这篇里重复。

价格

中文 AI 编程 CLI 工作流包完整版：早鸟 ¥9.90，限前 100 份；正式 ¥19.90。Lite 版免费版已含 /test、/review、/commit 3 条命令与安装脚本，完整版为 10 条全量。

完整版购买：https://afdian.com/item/8c9c0932bd7711f19eb852540025c377
免费 Lite 版：https://github.com/alapha888/cn-ai-coding-workflow-lite