造一个功能 到底要花多少钱?

一个功能造两遍,是一则带回执的轶事。这有它的价值,但比一个比率的价值要小。这些局限被写在页面上,是因为反正你自己也会发现。

1. 01

   n = 1。

   一个功能。这是一次演示,永远不是一个比率。不管结果难看、混杂,还是某一条路直接失败:原样发出来。

2. 02

   对照组不可复现。

   一个人驱动 Claude,这一次和下一次就是不一样。我们把提示词和子 agent 配置写死并公开了会话记录,这缩小了差异。但没有消除它。

3. 03

   功能由外部人士挑选,规则修订过两次。

   谁挑任务谁就挑了赢家,所以从这里开始挑选的人不是我们。规则在列出任何候选项之前就已公布,第一次执行排除了所有未关闭议题,得到空集。随后在公开场合删掉了其中一条,即排除本团队自己开的议题那一条,规则再次对八个候选项执行:全部因为没有改动本仓库自己的 Ruby 而被跳过。针对这一死胡同的两个处置方案在它发生之前就已命名。第二个于 2026-09-17 采取,时间早于外部人士被告知、也早于其查看仓库,因此先后次序可在议题历史中核对,而不必听我们自述。它的代价是失去日历为那八个候选项提供的论据,即它们都不可能是为这项研究而开的;换来的是挑选的人不是我们。议题正文从未编辑过;所有版本都按发布顺序公开。

4. 04

   两条路都是我们自己跑的。

   造出 B 路的那些人,正是在驾驶 A 路的人,而 A 路是我们要去比的那个对照组。一次独立的运行会比我们这次更有价值,我们宁愿把这句说出来,也不愿意让人误会。

5. 05

   日历时间不等于投入的工作量。

   我们的钟里包含了你现实中真的要等的排队时间。对照组的钟是一个人不被打断的专注时间。这个口径是在抬高对照组,不是抬高我们。

6. 06

   审查者是我们自己人。

   一个审查者,是我们团队的人。他同时也是驾驶对照组那条路的人,所以在打开任何一个 PR 之前,他就认得出自己写的那份 diff。两份 diff 送到他手上时都去掉了分支名和提交作者信息,而所谓“盲审”在这里就只是这个意思。一个外部审查者会直接消除这条局限,而不是把它说软;我们没有这样一个人。

7. 07

   场地是我们维护的。

   两条路都跑在一个我们维护的公开仓库上:我们的组织、我们的 CI、我们的机器人守着合并通道。换一个外部仓库会消除这条局限。那需要一个不是我们的维护者,愿意让两条路在他的仓库上开 PR、跑 CI、并且合并,而我们没有这样一个人。