每个数字可用命令复现:给数字留一张小票

什么叫"可用命令复现"

我们产线的做法很具体:所有留档都放在仓库的 runs/ 目录、日志文件和 git 历史里,每个对外陈述的数字都能用命令重新算出来——节数用 wc -l 数,字数用 wc -m 跑,改动处数对着 git log 逐条点。

• "这门课有 220 节"——用什么命令数出来的?
• "文档 19 万字"——wc -m 跑的是哪个目录?
• "改了 20 处引用"——git log 里是哪几条提交?

每个数字后面都该跟得上一个这样的问句,而且答得出来。这不是仪式感——下一节你会看到,正是这套机制,抓出了我们自己写错的数字。

为什么数字是最危险的内容

因为数字是最容易"凭记忆写"、又最难被读出破绽的东西。

文字写错了,读者能感觉到别扭:逻辑断了,措辞怪了,总有信号。数字写错了,读起来毫无异样——"42 节"和"48 节"在句子里同样通顺,语法、语感、上下文都不会报警。凭印象写数字,等于把最容易错的部分,交给了最不可靠的来源(你的记忆),再放进最难被发现的位置(通顺的句子里)。

所以数字不能靠"再读一遍"来质检——读多少遍都读不出 42 和 48 哪个对。它只能靠重新算一遍。

三步落地

1. 写数字时,同时写下它的来源。 不必发布出去,但底稿里要有:"220 节 ← ls content/lessons | wc -l"。写来源的成本是几秒钟,省下的是日后整段争议。
2. 来源必须是可重跑的动作。 一条命令、一个表格公式、一份逐条点数的清单,都行;"我记得是这么多"和"上次统计过"不行——它们无法被第二个人重走。
3. 发布前重跑一遍。 数据会变:课节会增删,文档会改版。上次对,不代表这次对。发布那一刻的数字,要用发布那一刻的数据重新算。

换别的工具怎么做

可核查性的本质是“给每个数字留一张小票”,跟你写不写代码无关:

• Excel 里的数字,指向具体单元格和公式,而不是手敲的常量。
• 报告里的"客户增长 30%",指向后台某个报表的截图路径和取数口径(哪个时间段、算不算退款)。
• 逐条点数的清单本身就是复现方法——只要第二个人照着点,能得出同一个数。

判断标准始终只有一个:一个不了解背景的人,照着你写的方法,能不能独立算出同一个数字。

🔧 动手做:核你自己的三个数字(8 分钟)

1. 打开你最近一份含数字的产出——周报、文章、方案都行。
2. 挑出 3 个数字,为每个写出复现方法:一条命令,或一个任何人可执行的核对步骤(公式、清单、取数口径)。
3. 照着你写的方法,实际核一遍这三个数字。
4. 核出不一致的,当场修正,并把复现方法留在底稿里。

你会看到:三个数字要么被确认,要么——别惊讶——被修正。如果三个全对,恭喜;如果核出错的,更好,把它留着,下一节直接要用。

为什么:亲手核出(或核实)自己的数字,比读十遍"数字要可核查"都有效。这一步同时给下一节的"自证式诚实条款"准备了素材。