这是“智能体测评”系列的第0篇（总纲）。我们会在这篇里讲清楚一个问题：当我们谈论“测评一个智能体”时，到底在测什么、怎么测、以及为什么不能只看一个成功率。后面的十篇文章，都是对这个体系的逐层拆解。从一次版本发布说起假设你负责一个Agent产品，今天改了两行prompt：把系统提示词里的“请仔细思考”
这是“LLM测评”系列的第8篇，也是收尾篇。前7篇教你怎么读别人的榜，这一篇告诉你：公开榜终归是别人的考试，真正决定你产品能不能发版的，是你自己的评测集。摘要本文回答三个问题：公开基准和自建评测集各该承担什么职责、自建评测的五步流程是什么、以及为什么门槛要卡在“每次都能成功”而不是“碰巧成功”。核心
这是“LLM测评”系列的第7篇。前几篇在讲“怎么读分”，这一篇讲“为什么很多分根本不值得读”——基准会腐烂，而且腐烂得比你想象中快。摘要本文回答三个问题：一个基准为什么会失效、失效有哪几种机制、以及读榜时怎么判断一个基准“还活着吗”。核心论点：benchmark是软件系统，不是数据集。它会腐化、会被
这是“LLM测评”系列的第6篇。前几篇讲的都是“答题型”基准，这一篇进入2026年最热也最复杂的赛道——Agent测评：当AI不再只回答，而是去操作，分数还怎么打？摘要本文回答三个问题：Agent测评和模型测评有什么本质区别、GAIA与τ²-bench各自在测什么、以及为什么“完成任务”不等于“成功
这是“LLM测评”系列的第5篇。这一篇聊程序员最关心的维度——代码：AI写代码的能力是怎么测的，以及“能写函数”和“能修好仓库”差多远。摘要本文回答三个问题：代码评测是怎么演进的、SWE-bench为什么是“最像真实工作”的代码考试、以及读代码类榜单时该注意什么。核心论点：代码评测正在从“考试”走向
这是“LLM测评”系列的第4篇。上一篇我们讲了推理基准GPQA，这一篇沿着能力维度继续：数学。为什么“会做小学数学题”和“会做竞赛题”是两个时代的声明？摘要本文回答三个问题：数学基准为什么分了好几个档、每档各测什么、以及怎么判断一个“数学95%”的声明值多少钱。核心论点：数学是推理能力最干净的试验场
这是“LLM测评”系列的第3篇。前两篇讲了benchmark的基本框架和“饱和”概念，这一篇进入最难测的能力之一——推理，以GPQA为例。摘要本文回答三个问题：为什么选择题考不出“推理”、GPQA是怎么设计出“考不倒、背不着”的题目的、以及AI的高分到底算不算会推理。核心论点：“答对”不等于“会推理
这是“LLM测评”系列的第2篇。上一篇我们学会了怎么读跑分表，这一篇解剖一个最有名的基准MMLU，以及一个所有基准都逃不过的宿命：饱和。摘要本文回答三个问题：MMLU到底在考什么、为什么它曾是“通用能力”的代名词、以及“饱和”是什么意思、对读榜有什么影响。核心论点：一个基准的区分度会随时间衰减。MM
这是“LLM测评”系列的第1篇。上一篇我们建立了基准测试的直觉，这一篇拿一份真实的跑分表来解剖：分数旁边，还藏着哪些必须读懂的细节？摘要本文回答三个问题：一个benchmark分数由哪些配置决定、为什么同一个模型会有多个不同的分数、以及拿到任何跑分时应该核对的五项配置。核心论点：一个分数不是模型的属
这是“LLM测评”系列的第0篇。这个系列回答一个问题：AI模型的能力到底怎么量？从为什么需要考试讲起，一路拆到主流基准各自在测什么、榜单怎么读、以及怎么给自家模型出题。摘要本文回答三个问题：为什么AI也需要“考试”、一场AI考试由什么组成、以及“一个分数”和“一份榜单”之间差了什么。核心论点：没有测
这是“AINative开发”系列的第4篇。**案例说明：**本文的API、鉴权和自动化测试契约属于假想全栈项目示例；本博客当前是Astro静态站，真实内容变更通过本地CMS/Git工作流完成。上一篇解决了“AI怎么理解项目现状”，这一篇解决“AI怎么理解你要做什么”。第1篇给出了Spec质量标尺（五
摘要这是系列的收官篇。前面15篇讲的是一个人怎么用SDD+AI把软件做对。但一个人用得好，不等于一个团队用得起来。个人方法靠自觉，团队系统靠机制——这一篇讲怎么把散落的好习惯，固化成团队共享、可执行、可审计的研发系统。核心论点：团队规模化的本质，是把”靠人记得”变成”机制强制”。个人靠每次记得”要写
摘要Verify的价值不只是发现失败，更是判断失败发生在哪一层。一个失败出现后，“把它修好”是本能，但最贵的习惯就是就地把它修绿——因为很多失败的根因在上游：需求没写清、方案错了、测试理解错了，代码只是把上游的错误忠实地呈现出来。核心论点：代码是契约的下游。很多”代码bug”其实是Spec缺口、Pl
摘要所有命令变绿，依然不代表产品正确。Verify是SDD四道闸门的最后一道，它要回答的不是”测试过了吗”，而是”Spec里的每条需求，是否都有证据证明被满足了”。核心论点：测试通过是手段，需求被证明是目的。一个功能可能所有测试都绿，但漏测了某条需求、或测试本身是陪跑、或存在根本没被任何用例覆盖的行
摘要会调试单个失败之后，面对的是规模问题：一个功能几十上百个测试，一次改动可能影响任何地方。这一篇讲怎么把测试组织成分层、分批、可复现的执行体系，让”跑了测试”变成一份能支撑发布决策的证据。核心论点：测试要按反馈速度分层，不是一股脑全跑。冒烟、受影响用例、全量回归三层，各有触发时机和用途。把慢测试放
