这是“智能体测评”系列的第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质量标尺（五
30秒看懂这篇一个高手用AI，可以把功能做得又快又好；十个Agent同时开工，也可能把冲突、越权和密钥泄露一起规模化。所以团队AI-Native化的关键，不是再买十个账号，而是建立一套让正确路径最省事、危险路径走不通、每次失败都能加固系统的研发操作系统。flowchartTBH["人：意图、风险与发
30秒看懂这篇同一个权限Bug，第一次修一行if，第二次再修一行，第三次换个接口继续修——代码越来越多，根因却从没离开过。真正省时间的做法不是更快修绿，而是先问：这次失败究竟在惩罚哪一层的错误？Spec没说清、Plan映射错、实现漏做、测试误报，止血动作看似相同，后续回写完全不同。flowchart
30秒看懂这篇42个测试全绿，仍然可能有3条需求从未被验证。绿色回答的是“这些测试通过了”，Verify回答的则是：“我们承诺的行为，有足够证据支持吗？”flowchartTBR["REQ：承诺什么"]-->T["TEST：如何检验"]T-->X["执行：在哪一层、什么环境"]X-->V["证据：结
30秒看懂这篇“测试通过了”可能是本次开发里最贵的一句谎话：它也许只跑了三个单元测试，却让你以为整套系统都安全。真正难的不是把测试跑起来，而是同时回答两个问题：测到什么深度？这次该跑多大范围？很多人把它们混成一座“测试金字塔”，结果不是反馈太慢，就是覆盖出现黑洞。flowchartTBsubgrap
