MAI 从 487 万个开源 PR 里筛出了 26.5 万道可训练题目，又为它们建了一套三层判分体系。这个过程的工业化，才是 AI 编程这两年真正发生的转变。
MAI-Thinking-1 深度解读 · 第三篇（共三篇）
· [1] 训练大模型不是造火箭，是攀岩 · [2] 让模型思考不难，让它持续思考才难 · [3] vibe coding 之后：AI 编程的工业化（本篇）
两年前，如果你让 AI 写代码，场景是这样的。打开 Cursor，用自然语言描述你要什么，AI 生成一段代码。你复制粘贴，跑一下，改一改，行了。大家管这个叫”vibe coding”：你给出一个 vibe（感觉），AI 吐出代码。
现在呢？打开 GitHub，找到一个 issue。把 issue 描述粘贴给一个 coding agent。Agent 自己 clone 仓库，自己读代码，自己改文件，自己跑测试，测试挂了就自己修，直到测试全绿。
这两年发生了什么？
大多数人会说”模型能力变强了”。数字没错。但这个解释漏掉了一件更有意思的事。AI 编程真正的变化不在模型里，它发生在一个更不性感的地方：训练基础设施的工业化。
这是 MAI-Thinking-1 深度解读的第三篇。第一篇讨论了 MAI 的 pre-training 哲学：攀爬机器、Efficiency Gain、看趋势不是看点。第二篇讨论了它的 RL 训练纪律：恒温器、断路器和自蒸馏。本篇讨论最后一件事，训练所用的题目和评分信号是怎么被工业化地构建出来的。
在进入具体数字之前，先理解这套系统为什么重要。agentic 训练的核心是一个反馈循环：模型在一个环境里执行动作（写代码、跑测试、调用工具），环境给出一个 reward 信号（做对了还是做错了，做得好还是不好），模型根据这个信号调整自己，然后进入下一轮。环境是模型的老师，reward 是老师的评语。老师越多、评语越准，模型学得越快。
MAI 做的事，是把”生产老师”和”标准化评语”从手工活变成了流水线。下面先看这张考卷长什么样，再看它是怎么被批量生产出来的。
在理解 MAI 做了什么之前，需要一个锚点。
SWE-bench 的每一道题，本质上是三层东西套在一起。最里面是一个 Docker 容器，装着有一个 bug 的代码仓库。中间是一套测试，修好 bug 之后这些测试会全绿通过。最外面是一个判分逻辑，测试全绿就算你过关。
这就是一张标准化的考试卷：有题目（bug），有答题区域（代码仓库），有标准答案（测试全绿），有阅卷规则（跑了测试看结果）。你把模型扔进这张卷子里，让它自己挣扎。
SWE-bench 本身是评估用的，里面一共只有几千道题。但 RL 训练需要的东西，结构跟它完全一样：一个可执行的环境，加上一套判分逻辑。区别只在规模：评估用几千道就够了，训练需要几十万道。MAI 做的事，就是从 GitHub 上工业化地生产这些训练用的题目。
如果想用这种卷子来大规模训练一个 coding agent，你需要多少道题？不是十道，不是一百道，是几万道。这些卷子从哪来？
MAI 的答案是：从 GitHub 里炼。
具体数字是这样的：先从 GitHub 上抓出 487 万个已经合并的 PR，每个 PR 对应一个 issue 描述。理论上，每一个这样的 PR 都是一张潜在的考试卷。issue 是题目描述，代码 diff 是标准答案，通过的测试是判分依据。
但”潜在”跟”真能用”之间，隔了三刀。
第一刀砍的是能不能跑起来。你的这个 PR 能不能被装进一个 Docker 沙箱里，用正确的依赖和工具链让它执行？MAI 用自动化流程去试。487 万里面，208 万通过了这一刀。先砍掉将近六成。
第二刀砍的是能不能判分。环境跑起来了，不代表你能给模型一个明确的判分信号。测试全绿还是没绿？这个评判标准必须跟 PR 原文的诉求严格对应，不能因为环境里其他无关的东西挂了就误判。208 万里面，74.5 万通过了这个步骤。又砍掉六成多。
第三刀砍的是能不能在训练环境里稳定运行。训练沙箱比验证环境严苛得多。网络被切断。git history 被擦除。commit hash、PR 编号、discussion 链接被清洗。所有非确定性的行为被排除。同一张考卷在不同时间跑，结果必须一样。74.5 万里面，最终 26.5 万通过了全部三道关卡。
487 万进去，26.5 万出来。5.5%。每得到一张可用的考试卷，背后有十八张废卷被扔掉。
这个 5.5% 的产出率，就是”工业化”的成本。环境不是从天上掉下来的，是被筛出来的工业品。
第三刀里藏着一个非常关键的问题。这些考试卷都来自 GitHub 上的公开 PR。如果模型在训练时能连上互联网，它可以直接搜到原始 PR。不靠推理，靠搜索，直接抄答案。
MAI 的应对不止是断网。他们清洗了整个沙箱里的每一个可能暴露答案的线索。commit hash 删了。PR 编号删了。原始 repo 的引用删了。discussion 链接删了。剩下来的是一段干净的”题目描述加上一套测试”，没有东南西北。
这件事说明了一个微妙但非常重要的点。环境设计和奖励信号设计不是分开的两步工序。它们是围绕”防止作弊”这个诉求被绑定在一起的同一件事。在工业化的训练流程里，出题和防作弊是一体两面。
构建环境只是工业化的一半。另一半是打分：模型在沙箱里折腾完，你拿什么告诉它做对了还是做错了？
对于 SWE 类任务，答案是单测。全绿就是对了。MAI 的 26.5 万道题，大部分都是这种结构：你写代码改 bug，测试全绿算过关。这种叫”可验证奖励信号”，确定、干净、不用人审。
但 agentic 训练里还有一类更复杂的任务：工具使用。比如说，给模型一个数据库和一组工具，让它”查询所有在过去三个月内购买超过 500 美元的客户”。模型需要决定用哪个工具、传什么参数、怎么组合多次查询。最后返回一个结果列表。你怎么判这个列表是不是对的？
MAI 为这类任务建了一套三层判分体系。
第一层是环境特定的判分脚本。每个任务环境自带一个 grader，它检查最终状态对不对、调用的工具对不对、返回的结果对不对。这和单测是一个逻辑，只是检查的内容从”代码能不能编译”变成了”工具调用流程是否合理”。
第二层是一个 AI 裁判。它把复杂的工具使用任务拆成几个子任务，逐个子任务打分，最后汇总。比如说，“查询过去三个月”是一个子任务，“金额超过 500 美元”是另一个，“返回正确格式的列表”是第三个。每个子任务单独判，不会因为一个环节出错就全盘否定。多次判分取平均，减少单次判断的随机误差。
第三层是一个用人类偏好数据专门训练出来的奖励模型。这个模型不判”对错”，判”好不好”。同样是查到了正确的客户列表，有的查询用了一次工具调用，有的用了五次。答案都对，但效率不一样。奖励模型负责在这种”都对”的情况里，告诉模型哪个写法更值得被鼓励。
三层合在一起：可验证信号保证确定性判断，AI 裁判保证任务覆盖率，奖励模型保证质量偏好。RL 训练时，三者的权重根据任务类型动态调整。
这套判分体系在绝大多数场景下是够用的。但它有一个盲区。
MAI 的三层判分体系能覆盖后端代码和工具使用。但有一类任务，三层都够不到。前端。一个按钮长什么样，单测不知道。布局有没有崩，单测不知道。响应式断点是不是裂开了，单测不知道。
这也是为什么你会注意到一个现象：有些 AI 模型写出的前端代码格外好看、交互格外流畅，另一些模型写的虽然功能对，但界面就是”差了点意思”。这个差距不是天生的。是训练的时候决定的。
训练一个会写前端代码的模型，和训练一个会写”好看”的前端代码的模型，用的是同一种算法，但用的是不同的 reward 信号。如果你的 reward 信号只有”单测全绿”，模型只会在意功能正确性，不会在意视觉质量。如果你在 reward 信号里加了一层视觉检查——按钮对不对、布局崩不崩、交互通不通——模型才会在训练中学会这些东西。
GLM-5 里有一个叫 Agent-as-a-Judge 的系统，把这种视觉检查做成了自动化。每一个生成的前端项目先确认能 build 通过，然后被部署到一个预览页面。一个多模态 agent 在浏览器里打开页面，模拟人类的视觉和交互检查流程。这套 agent judge 的判定跟人类专业评审比对过，在可接受的范围内。
这个案例的价值不在 GLM-5 这个具体的实现上。它说明了一件事：以前被认为只能靠人来干的评审工位，可以被自动化。一旦被自动化，就可以大规模地塞进 RL 训练里。模型不是天生会写好看的前端，是你用什么样的 reward 信号训练它，它就被塑造成什么样子。
把”出题”和”批改”这两件事放在一起看，才能理解这两年 AI 编程到底被改变了什么。
“出题”被工业化了。一个训练环境不再是一个工程师手写的一行 prompt，而是一张自动生成的考卷，带着确定性的判分信号。MAI 的漏斗告诉我们，从 GitHub 上 4.87M PR 里炼出 26.5 万张这种考卷，需要三道质检，每一步砍掉六成以上。训练的规模由你能产出多少张这种考卷决定。
“批改”也被工业化了，而且它的工业化决定了模型输出的品相。如果你只用单测做 reward，模型只学会写功能正确的代码。如果你在 reward 里加了工具使用效率的判分，模型学会写更简洁的代码。如果你在 reward 里加了前端视觉质量的判断，模型学会写更好看的界面。reward 信号的丰富程度，就是模型输出品质的上限。
两件事背后是同一条逻辑：agentic engineering 的瓶颈不在模型本身，在训练基础设施。出题的质量和数量决定模型能练多少，批改的精度和维度决定模型能练得多好。这两件事都不是新的，但把它们从手工活变成流水线，才是最近两年真正发生的变化。
做一个比喻来收束。把 agentic engineering 看成一个自动化考场。两年前你有一个会写代码的学生，但没有考卷，也没有阅卷老师。考试卷的生产线建起来了，批改的流水线也搭好了。你有了几十万道题，每道题的评分标准不是”能跑就行”。单测能跑是底线，工具使用效率是及格线，视觉和交互质量是优秀线。这些标准不是评估时加进去的，是训练时就写进 reward 信号里的。模型不是在考场上考得好，是在备战时就被训练成了你想要的样子。
两年间的真正变化，不是那个学生变聪明了。是它周围那套东西第一次被从零开始搭建完成了。
下次看到一个 coding agent 刷了 SWE-bench 新高，先别问”它用了什么模型”。问三个问题。
第一，训练环境从哪里来。是人手工写的几十道题，还是从真实仓库里工业化筛出来的？筛选用了什么漏斗？每一步砍掉了多少？
第二，奖励信号是什么。单测全绿就够了，还是有个 agent 在浏览器里帮你看了前端？
第三，防作弊做了吗。模型能上网吗？能搜到标准答案吗？沙箱里的 git history 和 PR 引用清理干净了没有？
这三个问题跟模型本身的架构没有关系。但它们决定了你看到的那一串 benchmark 分数，是不是被训练基础设施撑起来的。学会了问这三个问题，你就学会了区分”模型会写代码”和”有人帮它把考场搭好了”。
本文基于 Microsoft AI 的 MAI-Thinking-1 技术报告和智谱 AI 的 GLM-5 技术报告，均发布于 2026 年。