一个命令行工具，专门回答一个问题：这个仓库里还在跑的代码，到底是谁写的。它用 git blame 统计每位作者的存活行数，再把结果和该作者的提交占比并排打出来。作者把它做成了 Claude Code 插件，让智能体能直接跑，而不是靠猜。
0.4.0 版本想验证一件事：装了插件之后，智能体回答"代码归属"类问题的表现会不会变好。于是它被拉去和另外三个工具、以及一个不装任何插件的 Claude 同场对比。
先看结果。在 5 个密封任务上，插件拿到 25 分里的 9.67 分，最好的其他对照组是 7.33 分。这个差值的 95% 自助法区间是 [+0.33, +4.33]，下限刚过零，优势成立但很薄。
9.67 分也意味着，在 10 条评分标准里它通过的不到 4 条。换句话说，这批任务对每一个参赛方都很难，没有谁轻松通关。
在 11 个公开任务上，插件拿到 51 分里的 47.67 分，最好的其他对照组是 41.00 分。但它并非每个任务都赢，输掉的三个任务后面会讲。
任务长什么样
每个任务给智能体一个 git 仓库，外加一个接手项目的人会问的问题。比如："time.go、version7.go 和那段 SQL 代码的改动，我该找谁评审？当初真正写这些部分的人还在吗？"
一个任务最多 5 条评分标准，例如"点名此人为头号所有者，占比在 51% 到 59% 之间"，或者"没有把只跑过格式化工具的人算作作者"。标准依据从仓库算出的标准答案写成，由模型评分器逐条判定。评分器先给理由再给结论，每条标准投 5 票，以多数票为准。
任务分两套：
- 密封集 5 个任务。出题人没看过 surviving-lines 仓库，只拿到一份关于用户工作和文件结构的平实描述。每个任务用一个不同生态的真实开源仓库（Python、Go、Zig、Ruby、PHP），出题人额外加入提交来制造陷阱：跑一次格式化、同一个人用多个邮箱地址、压缩合并的工作、机械式文件搬移、作者与提交者不是同一人。
- 公开集 11 个任务。用一个小型 JavaScript 仓库，主要作者有两个地址，问题换着花样问：谁拥有这段代码、某个目录的巴士因子、某个文件该谁评审、各目录的代码所有者等等。这批任务在工具开发过程中被读过，所以被标为"开发期已见"。文章的核心结论压在密封集上。
六个对照组
参赛方包括：提交 8af57f4 的 surviving-lines；project-pilot 1.0.0 用其自然提示词跑一次、再用"请使用 /project-pilot:bus-factor 命令"的提示词跑一次；mcp-git-historian；k41n 的 busfactor；以及一个空插件的 Claude Code 运行。
其他工具都从固定提交的副本运行。project-pilot 1.0.0 的"指定命令"版本只在 8 个定义了该提示词的公开任务上有运行记录，所以它的公开总分把另外 3 个任务算作 0。每个参赛方在 Sonnet 5.5 上通过 Claude Code 2.1.308 对每个任务跑三次。协议在第一次运行前就已提交，没有复用任何早前轮次的结果。
npm 上的 0.4.0 版本与该提交的插件代码一致：bin、hooks、agents 和 schema 四个文件夹逐字节相同，只有技能描述文本和版本号不同。
密封集：赢了，但赢得不轻松
总分是各任务三次运行平均通过标准数的加总。与最强的其他对照组 project-pilot 1.0.0（指定命令版）相比，差值是 +2.33，95% 区间 [+0.33, +4.33]。对其余四个对照组，差值在 +6.33 到 +7.67 之间，每个区间都在零以上。
但 5 个任务、3 次运行的样本量下，0.33 的下限贴着零，换一套任务，结果可能往任一方向移动。
协议还定义了更严的检查，插件在这套密封集上没通过。HZ3 任务它得 0.67 分，project-pilot 1.0.0 指定命令版得 1.33 分；HZ5 任务它得 1.33 分，空插件运行得 1.67 分。因此"任一任务都不得落后于最强对手"的逐任务规则（规则 B）不成立；"插件丢分不得超过最强对手丢分的 80%"这条也不成立——它丢了 25 分里的 15.33 分，对手丢了 17.67 分，而上限是 14.13 分。作者明确表示，不主张它在每个任务上都排第一。
公开集：分数更高，证据更弱
公开集上插件拿到 51 分里的 47.67 分。最强的其他对照组是空插件运行，41.00 分，差值 +6.67，区间 [+5.00, +8.33]。若让 project-pilot 在每个任务上取两个版本中更好的那个，差值是 +4.33，区间 [+2.00, +6.00]。
其他对照组的总分分别是：project-pilot 1.0.0 为 40.33，busfactor 为 40.33，mcp-git-historian 为 38.33，project-pilot 1.0.0 指定命令版为 27.33（含 3 个缺失任务）。
它输了三个任务：T1 和 T1i 上它得 3.00 分，busfactor 和空插件运行得 4.00 分；E5 上它得 4.00 分，mcp-git-historian 得 5.00 分。80% 规则在这套集上通过，逐任务规则在这三个任务上不通过。由于这些任务在开发期被读过，这里的高分比密封集结果弱。
换模型跑，只做描述
作者还用 Haiku 5.5 和 Opus 5.5 各跑了一次，每个任务只跑一遍，只保留 surviving-lines、空插件运行和每个任务的最强对手。这些总分仅作描述，一个任务一次运行不足以计算区间，作者不据此主张第一。
四行结果里插件总分都领先。逐任务规则在两个模型上都有若干任务不通过，例外是 Opus 跑公开集。
评分本身可信吗
作者从 279 个已评分单元里随机抽了 28 个，用全新的评分会话重评。新评分与首次评分在 131 条标准中有 129 条一致，一致率 98.5%，没有任何单元的分差超过 1 分。
同样的 28 个单元又各重跑了一次，其中 25 个落在原始三次运行的区间内。这说明单个单元的一次运行，可能和之前的运行有出入。密封集上 91.6% 的判定是五票一致，公开集上是 97.0%。
成本与翻车点
按标价算，密封集上插件每个单元的成本是空插件运行的 1.67 倍（0.117 美元对 0.070 美元），公开集上是 1.56 倍（0.076 美元对 0.049 美元），原因是它用了更多轮次和 token。这些运行记在订阅账上。整轮包括决定是否跑最终测量的开发期关卡，按标价合计 185.46 美元。
插件有一个 Stop 钩子，在智能体收尾前检查答案里的数字一次。它在 48 个插件单元中的 5 个（10.4%）拦下了首个答案。这些被拦的单元平均得 3.40 分，未被拦的平均得 3.60 分，这组数据看不出钩子是否有帮助。
这些结论的边界
- 任务是作者自己出的。密封集出题人没读过 surviving-lines 仓库，但跑测量的智能体在协议写成之前看到了出题人的收尾摘要（五个仓库和每个任务一行陷阱说明）。这些陷阱正是工具被造出来要处理的那类。由竞品作者来做基准，排名可能不同。
- 5 个密封任务是小样本，区间只反映每个任务的三次运行，不反映换一套任务会怎样。
- 密封集和公开集由同一个模型、同一个 CLI 版本、同一个登录跑出。
- 会话上限两次中断了驱动脚本，都发生在审计重跑期间。因限额失败的单元被搁置、从未评分、之后重跑，没有任何已评分运行被搁置。第二次中断后作者续了登录，此后的审计重跑和其他模型运行可能走了不同账号。
- 密封脚本已公开，贡献者地址替换为其 SHA-256。公开脚本能用相同提交号重建夹具，并逐字节复现标准答案。
- 图中各参赛方自身总分的区间没有印在证据摘要里，摘要只有差值的区间。作者用同一批评分、同一方法（图脚本旁的 intervals.py）算出，并与摘要核对了总分。
另一个问题：提交占比 vs 存活行数
上面的基准问的是智能体用得好不好。另一个问题是：工具为什么要同时数这两个数。九月作者在 12 个公开仓库上跑过一次，设计和"零结果"的含义事先写定。对每个仓库，它测量每位作者的非合并提交占比，以及在 HEAD 上的存活行占比，取自五分之一确定性文件抽样，每个仓库三个随机种子。共 36 次运行、2748 行作者数据，测量于 2026 年 9 月 5 日，版本 0.1.6。
提交最多的人同时持有最多存活行，在 36 次运行中出现了 25 次，在 12 个仓库中有 8 个是三个种子全中。所以提交数通常能指向对的人。
但两个占比的差距比这更大：在任一指标上占比至少 5% 的作者（122 行）中，差距中位数是 7.5 个百分点，均值 12.2。122 行里有 43 行（35%）差距达到 10 个百分点以上，最大单行差距 63.8 个百分点。在 cloudflare/capnweb 里，头号提交者持有 46% 的提交，但按种子不同只持有抽样存活行的 3% 到 16%；而一位只有 2% 提交的贡献者，持有 45% 到 58% 的存活行。作者没有追查原因。
这组数据也有边界：12 个仓库只描述 12 个仓库，不是关于开源的结论。抽样会改变量级——头号作者的行占比在种子间的中位波动是 5.4 个百分点，最大 17.4，所以作者从单次运行读方向、从多次运行读量级。那次运行把机器人算作作者，而 0.3.0 起默认排除机器人，所以那张表没有按当前行为重跑。存活代码不等于功劳，代码可能因为没人敢动而留下。12 个仓库的 HEAD 都已前移，数据文件没记录提交号，重跑会得到不同数字。
自己跑一遍
命令是 npx surviving-lines --sort gap，--sort gap 会把行占比与提交占比差距最大的作者排在最前。工具需要 Node 22 或更新版本，以及 git 2.15 或更新版本。在 Claude Code 里使用：
/plugin install surviving-lines --marketplace Bubblegunn/surviving-lines
每个单元、对协议的偏离和重算步骤都在第 13 轮证据文件夹里。该文件夹的 REPRODUCE.md 给出重跑命令，更早的轮次和裁定在 docs/HEAD-TO-HEAD.md。仓库是 Bubblegunn/surviving-lines，0.4.0 版本在 npm 上。
除作者本人提交外，还有三个人向工具贡献了代码：@shivam-070208 写了 --markdown，@Aaqibhafeezkhan 写了 --sort gap，@Enard52 提交了修复，让空运行能说明是哪个过滤器把结果清空了。作者表示，如果在某个仓库上跑出的数字看着不对，告诉他仓库名，他会去看。
披露：本文在 AI（Claude）协助下起草，由作者本人审阅。每个数字都来自上述证据文件夹和仓库中的研究文件夹，基准可以从中重跑。
热门跟贴