Vercel 发布 DeepsecBench，HumanLayer 跑了 SlopCodeBench 子集，GitHub 则把 Copilot 的使用经验压到一个词上：harness。三条信息不属于同一个产品发布，却在同一天指向同一个工程问题：如果 AI 真的要进入代码库和安全流程，评测就不能只问模型能否答对一道题。
更有用的问题是：它在什么环境里工作，是否能看到足够上下文，失败会不会沿着后续任务累积，成本和耗时能不能被团队接受，以及人类复审在哪里介入。这个变化对中文技术团队很实际。公开排行榜仍有参考价值，但它很难回答一个生产团队最关心的问题：这个模型放进我的仓库、我的权限边界和我的发布节奏后，还可靠吗？
安全扫描把召回率和预算放在一起
DeepsecBench 的设计是典型的可执行评测。Vercel 选择了一个漏洞修复前的开源代码库，抽出 50 个入口文件，构建 231 条人工判定的发现项作为黄金集。模型结果不只看找到了多少问题，还同时记录召回率、精确率、成本和总时间，再用偏重召回的 F2 分数合成一个主指标。这个权重选择有现实含义：安全场景里，漏掉漏洞比多看几个误报更危险。
它也刻意没有公开仓库、commit、文件和漏洞明细。这样做牺牲了外部复现的便利，但能降低模型背诵训练样本的可能。Vercel 报告的最好成绩也没有接近满分：榜首配置的召回率是 30.7%，分数 35.58，50 个文件成本 55.98 美元、耗时 3 小时 39 分钟。Kimi K3 高推理设置分数 17.56，成本 12.38 美元。Vercel 进一步估算，生产代码库规模可能达到这次评测的大约 100 倍，一次全量扫描会从一千多美元到五千多美元以上不等。
这些数字不能直接证明某个模型就是企业安全扫描的最优解，因为它们来自 Vercel 自己构造的基准，尚不是第三方复现。但它们把问题问得更接近工程现实：团队不是买一个最高分，而是在不同服务、不同发布阶段和不同预算下组合扫描策略。
长期维护任务会让缺陷带着走
HumanLayer 的实验补上了另一个缺口：代码生成模型在一个需求里过关，不等于能长期维护一个演进中的代码库。它使用 SlopCodeBench 的 3 个问题、17 个 checkpoint，模型每次只看到当前要求，不知道后续需求。严格通过标准也很硬：当前 checkpoint 的新测试要过，前面继承下来的回归测试也要继续过。
结果并不乐观。Opus 5 在这组小样本里拿到 4/17 个严格通过点，Opus 4.8 和 Sonnet 5 各拿到 1 个；没有一个模型完成任一完整挑战。这个样本不大，不能外推成模型排行榜，但它抓住了普通 SWE-bench 类任务较难覆盖的失败方式：早期设计欠债会在后续 checkpoint 里持续收费。
HumanLayer 还记录了 41 个代码质量指标，包括规模、复杂度、重复、依赖图和规则命中。作者也承认这些指标不能单独代表可维护性，甚至可能被模型 reward hack。但确定性指标配合黑盒测试，至少让“代码越写越难改”这件事不再只是工程师的直觉。
Harness 正在变成模型之外的控制面
GitHub 的文章不是基准测试，而是把 harness 解释成 Copilot 工作流的承载层：选定工具，尽量使用 sandbox，让 agent 先做原型，再进入 plan、Autopilot 实现和人工迭代，必要时用不同模型做复审。它的重点不是“提示词更神”，而是把模型放进一个可观察、可中断、可复盘的过程。
这与 DeepsecBench 和 SlopCodeBench 形成了互补。前两者回答“怎样测”，GitHub 回答“怎样把测出来的风险放回日常工作”。如果 agent 可以运行命令、访问文件、调用工具，harness 就不只是外壳，而是权限、上下文、反馈和审查的集合。团队真正要投资的也不是某个一次性 prompt，而是让每次 AI 改动都能被测试、日志和人类判断接住。
对团队的直接含义
今天这组三条信息给出的结论很克制：模型确实能承担更多安全和开发工作，但距离无人值守仍有明显缺口。对工程团队来说，比较实际的做法是把公开评测当成候选过滤器，再用自己的私有样本建一个小型 harness。安全扫描可以按服务重要性分层，核心服务周期性跑昂贵模型，普通变更用便宜模型做高频检查。代码 agent 则要让失败能在下一步暴露，而不是等到 PR 末尾才发现架构已经偏了。
更重要的是保留人工位置。人类不应该只是在终端里连续点批准，也不应该把所有质量判断交给另一个模型。好 harness 的价值，是把模型能力转化成可审计的工程过程；差 harness 则会把错误自动化得更快。