模型参数、芯片数量和训练耗时都很容易比较，却不能直接回答一个更重要的问题：AI 是否正在更快、更独立地完成真实研发工作？Anthropic 提出的三份方法论式度量，价值正在于把讨论从基础设施竞赛拉回可重复的任务、成功率和人工参与程度。
公开介绍中，信息最具体的一项是“AI 主导研发（AI-led R&D）”。它借用了 Epoch AI 的 AL0 到 AL5 自动化分级，其中 AL3 表示 AI 与人类协作。其余度量的名称和完整规则无法从现有摘要中可靠还原，因此不宜自行补写定义；但这套思路已经足以说明，怎样把“AI 发展很快”改造成一个可审计的工程命题。
算力增长不等于研发自动化
GPU 数量、训练 FLOPs 和推理吞吐量属于投入或系统性能指标。它们能说明团队投入了多少资源，却无法证明 AI 可以完成多少研发工作。
例如，一个模型生成代码的速度提高十倍，但如果工程师仍然需要逐行检查、反复修复测试，并在每次失败后重新规划，那么研发自动化程度未必发生了同等幅度的提升。
更有解释力的测量至少需要记录以下对象：
- 任务边界：AI 接到的是补全一行代码、修复一个缺陷，还是从需求到部署的完整任务？
- 成功条件：通过单元测试是否足够，还是还要经过代码审查、安全扫描和线上验证？
- 人工投入：人类花了多少时间提示、纠错、审批和接管？
- 成功频率：模型偶尔成功一次，还是在大量重复实验中稳定成功？
- 任务难度变化：本月测试集是否比上月更简单，或者已经出现在训练数据中？
这也是自动化等级比单纯 benchmark 分数更接近实际研发的原因。它关心的不只是“答对了吗”，还关心“工作是怎样被完成的”。
不要把 AL0 到 AL5 粗暴平均
AL0 到 AL5 是有顺序的等级，但相邻等级之间未必具有相同距离。把三次实验的 AL1、AL3、AL5 算成平均值 AL3，会掩盖完全不同的运行模式。
团队更适合报告“稳定前沿”：在预先规定的任务集合中，某个等级至少运行多少次，并达到多少成功率，才认为系统稳定抵达该等级。例如：
在不少于 20 次独立实验中成功率达到 80%，并且人工干预中位数不超过两次，才算稳定达到某个自动化等级。
这条规则不是 Anthropic 方法的原文定义，而是一种可以落地的内部实践。关键是先冻结阈值，再运行实验，避免看到结果以后调整标准。
同时，等级之外仍要保留原始数据。两个系统都可能达到 AL3，但其中一个每次只需要人类确认方案，另一个却要工程师持续纠错；只看等级无法区分这种差异。
可以这样建立一份最小研发度量表
下面的 Python 脚本演示如何按月份和自动化等级统计实验，并找出达到成功率门槛的最高稳定等级。示例中的 AL0、AL1、AL2、AL4、AL5 含义是本地假设；已知信息只明确指出 AL3 代表 AI 协作，因此实际使用前应替换成组织批准的正式量表。
将脚本保存为 measure_ai_rnd.py，然后运行 python measure_ai_rnd.py：
from collections import defaultdict
from statistics import median
# 示例数据：实际使用时可改为读取实验平台导出的 CSV。
records = [
{"date": "2025-01-03", "level": 2, "success": 1, "human_minutes": 31, "interventions": 3},
{"date": "2025-01-08", "level": 2, "success": 1, "human_minutes": 24, "interventions": 2},
{"date": "2025-01-15", "level": 2, "success": 0, "human_minutes": 47, "interventions": 6},
{"date": "2025-01-27", "level": 2, "success": 1, "human_minutes": 20, "interventions": 2},
{"date": "2025-02-04", "level": 3, "success": 1, "human_minutes": 18, "interventions": 2},
{"date": "2025-02-10", "level": 3, "success": 1, "human_minutes": 14, "interventions": 1},
{"date": "2025-02-19", "level": 3, "success": 0, "human_minutes": 42, "interventions": 5},
{"date": "2025-02-26", "level": 3, "success": 1, "human_minutes": 12, "interventions": 1},
]
MIN_TRIALS = 4
MIN_SUCCESS_RATE = 0.75
MAX_MEDIAN_INTERVENTIONS = 2
groups = defaultdict(list)
for row in records:
month = row["date"][:7]
groups[(month, row["level"])].append(row)
qualified = defaultdict(list)
for (month, level), rows in sorted(groups.items()):
trials = len(rows)
success_rate = sum(r["success"] for r in rows) / trials
median_human_minutes = median(r["human_minutes"] for r in rows)
median_interventions = median(r["interventions"] for r in rows)
stable = (
trials >= MIN_TRIALS
and success_rate >= MIN_SUCCESS_RATE
and median_interventions <= MAX_MEDIAN_INTERVENTIONS
)
if stable:
qualified[month].append(level)
print(
f"{month} AL{level}: trials={trials}, "
f"success={success_rate:.0%}, "
f"median_human_minutes={median_human_minutes}, "
f"median_interventions={median_interventions}, "
f"stable={stable}"
)
for month in sorted(qualified):
print(f"{month} stable frontier: AL{max(qualified[month])}")
这段代码刻意没有计算“平均 AL”。它同时检查样本量、成功率和人工干预次数，避免一次幸运运行把曲线抬高。生产环境还应增加任务 ID、代码仓库版本、模型版本、工具权限、失败类型和评测器版本等字段。
三类混淆因素必须单独处理
任务选择偏差
如果实验团队只把适合 AI 的任务交给模型，自动化等级会上升，但这不能代表全部研发工作。更稳妥的做法是从真实任务队列随机抽样，并公开排除规则。
能力提升与流程优化混在一起
成功率上升可能来自新模型，也可能来自更好的提示词、测试工具或人工培训。实验记录应固定模型版本和工具配置；如果工作流发生变化，就创建新的实验组，而不是直接续接旧曲线。
速度与安全性并非同一个指标
AI 更快完成代码修改，不代表修改可以安全上线。涉及依赖升级、权限系统、基础设施和安全策略的任务，仍需要独立的审查门槛。自动化等级不能代替安全评估，也不能自动成为裁员或绩效依据。
落地时先做一张可信的小表
团队不必一开始就追求覆盖所有研发活动。可以先选择 20 到 50 个边界明确、能够自动验收的任务，连续记录数周，再逐步扩展范围。
采用这类指标前，建议检查：
- 自动化等级是否有书面定义和正反例；
- 成功条件是否在实验开始前冻结；
- 是否同时报告成功率、样本量和人工投入；
- 任务集合是否保持稳定，变更是否有版本号；
- 模型、脚手架和工具升级是否分别记录；
- 失败、人工接管和安全事件是否保留，而非只展示最佳结果。
真正有价值的度量不会给出一句简单的“AI 每年快多少倍”。它应当让另一支团队能够复现实验、质疑任务边界，并看清能力提升究竟来自模型、工具还是人类流程。相比继续比较芯片和口号，这种可审计的进展曲线更接近工程事实。