构建一个功能 实际要花多少钱?

同一个功能构建两次,只是一个有凭证的个案。它有参考价值,但不如一个普遍比率有说服力。我们把局限写在页面上,因为你迟早也会发现它们。

1. 01

   n = 1。

   只有一个功能。这是一次演示,不代表任何普遍比率。无论结果不利、好坏参半,还是任一组失败,均按原样公开。

2. 02

   对照组不可复现。

   人操作 Claude Code,每次运行都不会完全相同。我们以书面形式固定了提示词和子智能体配置,并公开会话记录,这缩小了差异,但并不能消除差异。

3. 03

   功能由我们自己选定,规则修订过四次。

   谁来选题,谁就决定了胜者,而这里选题的是我们。规则在列出任何候选之前就已公开,首次执行结果为空集。随后我们公开删除了其中一个条款,即排除本团队创建的 issue 的那一条,并将规则重新应用于八个候选:每一个都因为不改动本仓库自身的 Ruby 代码而被跳过。事先指定的备选方案是由外部人士提交该功能,但实际上没有外部人士可以承担。于是规则再次公开修订,且在功能 issue 创建之前,改为由开展本研究的团队提交。实际情况就是如此。针对这项对比最有力的质疑,是任务可能偏向我们这一组;对此,目前只能依靠读者可以自行核查的两点:修订发布在 issue 创建之前,且该功能取自本仓库此前已在文档中记录的一处缺口。issue 正文未经编辑,规则的每个版本都按发布顺序公开。

4. 04

   两组都由我们运行。

   构建 B 组的人,也是操作 A 组(即我们与之对比的对照组)的人。独立第三方的运行会比我们自己的更有说服力,我们宁愿明确说出这一点,也不愿让人产生误解。

5. 05

   日历时间不等于工作量。

   我们的计时包含你在实际中确实需要等待的排队时间。对照组的计时则是一个人不受打断的专注时间。这种口径对对照组有利,而不是对我们有利。

6. 06

   评审人是我们团队的成员。

   只有一位评审人,来自我们团队。他同时也是操作对照组的人,因此在打开任何一个 PR 之前,他就能认出自己的 diff。两份 diff 送到他手上时都去掉了分支名和提交作者信息,这里所说的"盲评"仅限于此。外部评审人能够消除这一局限,而不仅仅是减轻它;但我们没有这样的评审人。

7. 07

   试验仓库由我们维护。

   两组都在一个由我们维护的公开仓库上运行:组织是我们的,CI 是我们的,合并通道上的机器人也是我们的。换用外部仓库可以消除这一局限。这需要一位不属于我们团队的维护者,愿意让两组在他的仓库上发起 PR、运行 CI 并合并,而我们没有这样的维护者。

8. 08

   固定的模型改动过两次,之后又改回原样。

   预注册上有三条标有日期的评论,先改动了模型,后又恢复。前两次改动基于一个错误的判断:该模型的所有账户凭据均已吊销,这是事实,但与此无关,因为编码环节运行在机器自身的后端上,而试验仓库全程都在提供该模型。每个版本都已公开并标有日期,均早于任一组开始运行,当时没有任何结果可供参照,因此这里没有任何数字是先看到结果再做选择的。模型在两组之间始终保持一致,因此它改变的是两组各自运行的内容,而不是区分两组的因素;规则 6 仍然禁止重新选题。请按发布顺序阅读该讨论,自行判断这件事执行得是否严谨。

9. 09

   预测时已知道任务,但不知道结果。

   我们在任一组开始运行之前就公布了对记录的预期,因为一个只在事后才公布数字的页面,无法要求你相信这些数字没有出乎任何人的意料。这些预测不会受到结果的影响,但写预测时已经知道任务,因为筛选规则先确定了功能。正是这种不对称,决定了它只能称为预测,而不能称为预注册。没有任何规则在事后锁定这组预测:规则 6 禁止的是重新选题,而不是改写预测,因此起保护作用的是公开发布本身。这些预测及其评分规则是标有日期的公开评论,发布在任何记录产生之前,所在 issue 的编辑历史公开,任何修改都会以修改的形式留下痕迹。与记录相差甚远的预测,会与推翻它的记录一同保留在页面上。有一件事我们刻意不做预测:评审人更倾向于哪个 PR,因为这是本研究中唯一没有测量来源支撑的判断。