AI Coding 的下一个五年

别拿 SWE-bench 分数做选型：一个 benchmark 的死亡

背景与原理

SWE-bench（Jimenez et al., ICLR 2024）是过去两年 coding agent 的事实标尺：从真实 GitHub issue 抽 bug，让 agent 改代码、跑仓库自带测试判对错。后来 OpenAI 联合做了 SWE-bench Verified——人工筛过的 500 题子集。但 2026 年 2 月 OpenAI 发文停止报告 Verified 分数，理由值得每个工程师记住，因为它们是 benchmark 的通病：

• 污染（contamination）：全部 500 题来自公开 Python 仓库，且早于所有模型的训练截止。模型能直接「回忆」出 gold patch 和问题描述的细节——你以为在测推理，其实在测背诵。
• 题目本身是坏的：OpenAI 复查发现剩余题里超过一半有缺陷——有的测试太窄，把功能正确的提交也判错；有的太宽，要求问题描述里根本没提的额外功能。分数的天花板被噪声锁死。
• construct gap：「单仓库、有现成测试、几十行 bug-fix」的分布，和你日常的跨服务改动、需求模糊、要自己写测试差很远。榜单高分≠在你的代码库里能干活。

更隐蔽的：同一个模型换一套 scaffold（harness），SWE-bench 分数能差十几个百分点——榜单测的是「模型 + harness」的组合，不是模型本身。Scale AI 的 SWE-bench Pro 用法律上不可被训练的私有代码库做 held-out 集对抗污染，但它仍不是你的分布。结论：公开 benchmark 是厂商的军备竞赛指标，不是你的采购合同。

实战示例

唯一可信的 coding eval 是你自己的、私有的、跟你真实工作同分布的。十分钟就能起一个雏形——从你已合并的 PR 里抽：

# 从自己的 git 历史造 held-out coding eval（私有 = 抗污染）
# 挑 5 个「已知正解 + 有测试」的历史改动，回滚到改动前的 commit
for pr in ["#412 修复时区 off-by-one", "#455 加分页", ...]:
    checkout(pr.base_commit)              # 倒回改动前
    run_agent(task=pr.issue_title)        # 让被测 agent 重做
    passed = run(pr.test_files)           # 用当时真实的测试当 oracle
    log(model, harness, passed, tokens, wall_time)
# 关键：评 model+harness 组合，且 5 题不外泄、定期换新

跑两三个候选模型 / IDE 各一遍，你得到的是带成本和耗时的、对你工作有效的对比——比任何排行榜都值钱。注意把这 5 题当机密，一旦它进了任何公开渠道就被污染作废。

在涨的是「任务时长」不是「智商」：按 Time Horizon 分配自主度

背景与原理

METR 在 2025 年的研究（Measuring AI Ability to Complete Long Tasks, arXiv 2503.14499）提出一个更有工程意义的度量：50% 时间视界——人类要花多久的任务，模型能以 50% 成功率完成。他们用 170 个任务 + 800 份人类基线标定，发现这个时长过去六年一直指数上升，约每 7 个月翻一倍。更关键的是增长的来源：不是 raw reasoning 变强，而是可靠性、从错误中恢复、工具使用变好——正是这些让 agent 能撑过更长的链条而不崩。

工程含义：自主度不是开关，是一条连续曲线，横轴是「这任务人类要花多久」。别问「这活该不该交给 AI」，问「它值多少 human-time、可不可验证」，再据此选授权档位。50% 成功率意味着另一半会失败——越长的任务越需要可验证的护栏，而非盲信。

实战示例

把它变成路由规则：给每个委托任务先估一个 human-time 标签，再决定自主度，而不是凭「听起来难不难」拍脑袋。

def route(task):
    h = estimate_human_minutes(task)        # 你自己来估，5 / 30 / 180...
    verifiable = has_tests(task) or reversible(task)
    if h <= 5:                 return "auto"            # 全自动，扫一眼
    if h <= 60 and verifiable: return "plan+review"     # 先看计划再放行
    return "human-split"      # 人先拆成可验证子任务

能力的重新定价：哪些在贬值，哪些在升值

背景与原理

这是这一期最反直觉、也最该今天就行动的一点。当 code generation 的边际成本趋近于零，价值就从生产端移到两端：上游的 specification（把模糊需求变成精确、可执行的意图）和下游的 verification（在海量 AI 产出里判断对错）。Day 25 讲过 verification 已是 agentic IDE 的真正瓶颈——放大到职业尺度，就是一次能力重定价：

• 正在贬值：手写样板的速度、背 API 与语法、单点调试小技巧、快捷键肌肉记忆。这些是「生产手速」，AI 最先吃掉的。
• 正在升值：把需求写成可执行 spec / eval；大规模 code review（读懂并判断 AI 写的代码，比自己写更稀缺）；系统设计品味（架构错误会被 AI 高速放大）；harness 与工作流设计；把模糊问题分解成可验证子任务。

反直觉的推论：靠「手速」拉开身位的初级优势被抹平，靠「taste / 判断」的资深溢价反而上升。Karpathy 的 Software 3.0（2025）里，人的角色从「写指令」变成「在 partial autonomy 里把关」——你的稀缺性不在产出速度，在那个收 generation、做裁决的瓶颈位。

实战示例

做一次诚实的时间审计，倒逼自己往升值区迁移：

# 连续一周，给每段工作打一个标签，周末算占比
PROD  = 手写实现 / 样板 / 查 API / 单点调试        # ← 贬值区，目标占比↓
SPEC  = 写需求 / 定义验收标准 / 写 eval / 拆任务    # ← 升值区
VERIFY= review AI 产出 / 读代码 / 设计测试与护栏     # ← 升值区

# 多数资深工程师会发现 PROD 仍占 50%+——这正是可迁移的红利
# 行动：每周把 5% 的 PROD 时间，主动换成 SPEC / VERIFY

把 Codebase 改造成 Agent-Ready：为五年后投资的复利动作

背景与原理

agent 的吞吐量受限于 feedback loop 质量，而非模型多聪明。Karpathy 在 Software 3.0 里点明：agent 要干活，需要 docs、memory、tests 和清晰的反馈回路。换句话说——模型再强，也卡在没有 verification oracle 的环境里跑不动。所以「等更强的模型」是伪策略；真正的复利来自改造环境，这些动作今天就降低你的成本，五年后变成 agent 的 runway：

• 高覆盖、快速的测试套件：agent 最重要的资产，就是它自我验证的 oracle。没有它，agent 无法判断自己改对没有，只能等你当人肉测试。
• 把隐性知识显性化：用 AGENTS.md / CLAUDE.md 写下「怎么跑测试、有哪些坑、约定是什么」——既喂 agent，也喂新人。
• 缩小 blast radius：可逆操作、沙箱、清晰的模块边界。越能安全试错的任务，越能托管给高自主度 agent（呼应 Day 31）。
• 把模糊任务拆成可验证的子任务：这既是你 spec 能力的输出，也是 agent 能跑长链条的前提。

实战示例

一份最小的 agent-readiness 骨架——今天就能 commit 进任何 repo：

# AGENTS.md  —— 把 tacit knowledge 写成 agent 的运行手册
## 构建与测试
- 安装: `pnpm i`   跑全部测试: `pnpm test`   单测: `pnpm test <file>`
- 提交前必须绿: `pnpm lint && pnpm test`

## 架构边界（别跨）
- `core/` 不许 import `web/`；所有 IO 走 `adapters/`

## 已知坑（verification oracle）
- 时区一律用 UTC 存储；钱用整数分，禁用 float
- 改 `schema.sql` 必须同步加 migration + 回归测试

# Agent-readiness 自检：缺一项，你的「更强模型」就少一截 runway
# [ ] 测试能在 1 条命令内跑完且 <2min   [ ] 关键路径有测试覆盖
# [ ] 危险操作可逆 / 有沙箱           [ ] 约定写进了 AGENTS.md