莫潇羽@无忆研习社（www.wuyi.wiki）原创内容，转载请注明出处。
快速摘要
MiniMax M2.5 是 MiniMax（稀宇科技）于 2026 年 2 月推出的新一代 AI 编程与智能体模型，延续 MoE（混合专家）架构，总参数量约 230B，每次推理仅激活 10B 参数。 它在全栈 Web 开发、数学物理模拟、企业级系统搭建等场景中展现出接近旗舰级模型的能力，同时推理速度极快、资源占用极低。更关键的是，M2.5 兼容 OpenAI 标准接口，可以无缝接入 Claude Code、OpenClaw、OpenCode 等主流开发工具——这在国产模型中极为少见。本文将从 MoE 架构原理、CISPO 强化学习算法、Agent 原生训练框架 三个维度深入拆解 M2.5 的技术内核，并手把手演示如何将其接入 OpenClaw 等工具链，适合所有对 AI 编程感兴趣的开发者阅读。往下看，有更详细的技术拆解和实操指南。
一、开篇：2026 年初的 AI 编程格局
2026 年的开年，AI 编程赛道进入了白热化阶段。几乎每个月都有重量级模型发布，从参数规模到推理速度到价格策略，各家都在贴身肉搏。对于像莫潇羽这样长期跟踪 AI 工具链的开发者来说，局面既兴奋又纠结：模型越来越强，但选择也越来越难。
在这个节点上，MiniMax 发布了 M2.5。这个名字可能很多读者还不太熟悉，但如果你关注过 2025 年下半年的开源模型排行榜，一定见过 MiniMax M2 的名字——它在第三方评测机构 Artificial Analysis 的测试中拿下了开源模型综合排名第一。M2.5 是在 M2 和 M2.1 基础上的又一次迭代升级，主打编程与智能体（Agent）场景。
站长莫潇羽在第一时间拿到了 M2.5 的内测资格，花了几天时间把它接入日常工作流做了一轮深度测试。这篇文章就来聊聊 M2.5 到底强在哪里、技术原理是什么、普通开发者怎么用起来。
二、先搞清楚：MiniMax M2.5 到底是什么？
在聊具体技术之前，我们先把 M2.5 的基础信息理清楚，这对后面理解它的设计哲学很重要。
2.1 一张表看懂核心参数
|
指标 |
数值 |
|
模型全称 |
MiniMax-M2.5 |
|
研发团队 |
MiniMax（稀宇科技） |
|
模型架构 |
MoE（混合专家模型） |
|
总参数量 |
约 230B |
|
激活参数量 |
约 10B |
|
上下文窗口 |
约 200K tokens |
|
核心定位 |
AI 编程 + 智能体（Agent） |
|
API 兼容性 |
OpenAI 标准接口 |
|
推理速度 |
约 100 TPS（Token Per Second） |
这里最值得关注的一组数据是 230B 总参数、10B 激活参数。这是什么概念呢？打个不太严谨但容易理解的比方：你可以把它想象成一所大学里有 230 位教授（总参数），但每次学生来提问时，只会有最合适的 10 位教授（激活参数）出来回答。这就是所谓的"稀疏激活"——模型虽大，但每次推理时只调用一小部分参数，所以速度快、资源省。
2.2 从 M1 到 M2.5：一条清晰的进化路线
要理解 M2.5，有必要快速回顾一下 MiniMax 模型家族的进化脉络：
MiniMax-Text-01 是最早的基座模型，它在架构上就做出了一个大胆的选择——采用自研的 Lightning Attention（闪电注意力）机制，替代了传统 Transformer 中的 Softmax 注意力。这个选择让模型天然支持超长上下文（最高 100 万 tokens），但也带来了很多工程上的新挑战。
MiniMax-M1 在基座模型之上加入了强化学习（RL）训练，使模型具备了推理和思考能力。M1 最重要的技术贡献是提出了 CISPO 算法（后面会详细展开），这个算法让强化学习的训练效率翻了一倍。整个 RL 训练只用了 512 块 H800 GPU，三周时间，成本约 53 万美元——在动辄千万美元的大模型训练领域，这个数字相当惊人。
MiniMax-M2 进一步强化了编程和 Agent 能力，在 Artificial Analysis 的综合评测中拿下开源第一。M2 开始明确定位为"面向智能体和编程而生"的模型。
MiniMax-M2.1 在 M2 的基础上做了后训练优化，重点提升了多语言工程能力（Rust、Java、Go、C++ 等）和全栈应用开发能力（前端、后端、安卓、iOS）。M2.1 还提出了一个新的评测基准 VIBE（Visual & Interactive Benchmark for Execution），专门评估模型"从零搭建可运行应用"的能力。
MiniMax-M2.5 是最新的迭代，在编程能力和 Agent 性能上做了进一步优化，据早期测试反馈，其编程和智能体性能已经接近旗舰级模型（莫潇羽@无忆研习社注：这里说的旗舰级，指的是 Claude Opus 4.6 这个量级）。
三、核心技术拆解一：MoE 架构——"小参数大智慧"的底层逻辑
M2.5 能用 10B 激活参数跑出接近旗舰级的表现，根基在于 MoE（Mixture of Experts，混合专家模型）架构。这是当前大模型领域最重要的技术路线之一，DeepSeek、Qwen、GLM 等国产模型也都在采用类似架构。下面莫潇羽用尽可能通俗的方式，帮大家把 MoE 的核心原理讲清楚。
3.1 从"全班上课"到"专家会诊"
传统的大模型（比如早期的 GPT 系列）采用的是"稠密"（Dense）架构。所谓稠密，就是模型在处理每一个输入 token 时，所有参数都会参与计算。你可以把这想象成一所学校里，不管学生问什么问题，全校所有老师都要聚在一起讨论才能给出答案。
这种方式在模型规模不大时没问题，但当参数量达到千亿级别时，就会遇到一个很现实的问题：每次推理的计算量太大了，速度上不去，成本降不下来。
MoE 架构的思路完全不同。它把模型内部的前馈神经网络（FFN）拆分成多个独立的"专家"子网络，然后在每个专家前面加一个"路由器"（Router，也叫门控网络）。当一个 token 进入 MoE 层时，路由器会根据 token 的特征，动态选择最合适的少数几个专家来处理它，其余专家保持休眠。
这就好比：学校把老师按学科分成了很多小组（专家），学生来提问时，教务处（路由器）会判断问题的类型，然后只派最合适的两三位老师（Top-K 路由）来回答。这样既保证了回答质量，又大幅提高了效率。
3.2 MoE 的三个核心组件
用一段简化的伪代码来说明 MoE 层的工作流程（莫潇羽@无忆研习社提示：以下代码仅用于帮助理解原理，并非实际实现）：
class MoELayer:
def __init__(self, num_experts, top_k):
# num_experts: 专家数量，比如 MiniMax 有 256 个专家
# top_k: 每次激活的专家数量
self.experts = [FFN() for _ in range(num_experts)]
self.router = Router() # 路由器/门控网络
self.top_k = top_k
def forward(self, token_embedding):
# 步骤 1：路由器计算每个专家的匹配分数
scores = self.router(token_embedding)
# scores 是一个长度为 num_experts 的向量
# 步骤 2：选择分数最高的 top_k 个专家
top_k_experts, top_k_weights = select_top_k(scores, self.top_k)
# 步骤 3：只让被选中的专家处理 token
output = 0
for expert, weight in zip(top_k_experts, top_k_weights):
output += weight * expert(token_embedding)
return output这段伪代码展示了 MoE 的三个核心组件：
路由器（Router） 是整个 MoE 架构的"调度中心"。它本质上是一个小型的前馈神经网络，输入是 token 的特征向量，输出是一组概率值，表示每个专家处理这个 token 的适合程度。路由器的质量直接决定了 MoE 模型的效果——如果路由器总是把问题分配给不合适的专家，那再多的专家也白搭。
专家网络（Experts） 是实际干活的部分。在 MiniMax 的架构中，每个专家本质上就是一个标准的前馈神经网络（FFN），但不同专家在训练过程中会逐渐"学会"处理不同类型的特征。值得注意的是，这里说的"专家"并不是传统意义上某个领域的专家——它们学到的是更细粒度的特征模式，而非完整的知识领域。
Top-K 选择机制 决定了每次激活多少个专家。MiniMax M2.5 的具体 Top-K 值虽然没有公开，但参考其架构设计（256 个专家，10B 激活参数），推测每次大约激活 8 个左右的专家。
3.3 稀疏激活的"算账逻辑"
理解了 MoE 的工作原理，我们来算一笔账，看看稀疏激活到底能省多少资源。
假设一个传统的稠密模型有 230B 参数，那么它每处理一个 token，就需要对所有 230B 参数进行计算。但在 MoE 架构下，虽然模型总参数仍然是 230B，每次推理只激活其中的 10B——计算量直接降到了原来的 1/23。
这个差异体现在实际应用中就是：相同的显存预算下，MoE 模型的推理速度远快于同规模的稠密模型；同样的推理速度要求下，MoE 模型需要的硬件资源更少。MiniMax M2.5 实测能达到约 100 TPS（每秒生成 100 个 token）的推理速度，这在同级别模型中相当突出。
不过这里有一个容易被忽略的细节：虽然推理时只激活 10B 参数，但加载模型时仍然需要把全部 230B 参数载入显存。这意味着 MoE 模型在显存占用上并没有省太多，省的主要是计算量。这一点在做私有化部署时需要特别注意（莫潇羽@无忆研习社提示：如果是通过 API 调用则不需要关心这个问题）。
3.4 MiniMax 的 MoE 具体实现细节
了解了 MoE 的通用原理之后，我们再来看看 MiniMax 的 MoE 实现有哪些独特之处。
首先是混合注意力架构。MiniMax 在 M1 时代就开创性地将自研的 Lightning Attention（闪电注意力）融入了模型架构。具体来说，模型中每 7 个带有 Lightning Attention 的 Transformer 模块之后，会跟一个带有标准 Softmax 注意力的 Transformer 模块。这种 7:1 的混合比例，兼顾了 Lightning Attention 在长序列上的效率优势和 Softmax 注意力在捕获全局依赖上的精度优势。
Lightning Attention 本质上是一种线性注意力机制。传统的 Softmax 注意力的计算复杂度是 (O(n^2))——也就是说，序列长度翻一倍，计算量就翻四倍。而线性注意力通过巧妙的数学变换，将计算复杂度降到了 (O(n))，序列长度翻倍，计算量也只翻倍。这就是为什么 MiniMax 的模型能够支持高达 100 万 token 的超长上下文。
其次是专家数量和激活策略。MiniMax M2.5 拥有大量专家网络，每次推理只激活其中很少一部分。这种"高专家数 + 低激活数"的配置使得稀疏度非常高（绝大部分专家在每次推理时是休眠的），从而实现了极高的参数效率。
3.5 MoE 的工程挑战与 MiniMax 的应对
MoE 架构虽然理论上很优美，但在工程实现上有几个绕不开的难题。莫潇羽@无忆研习社认为，了解这些挑战有助于开发者理解为什么不同 MoE 模型在实际使用中的表现会有差异。
负载均衡问题。 路由器可能会"偏心"，总是把大多数 token 路由到少数几个"热门"专家，导致其他专家得不到充分训练。这就像班主任总是让同几个学生回答问题，其他学生得不到锻炼。解决方法是在损失函数中加入负载均衡惩罚项（Load Balancing Loss），鼓励路由器均匀分配任务。MiniMax 在这方面做了大量优化，确保每个专家都能得到足够的训练数据。
通信开销问题。 在分布式训练中，不同的专家可能分布在不同的 GPU 上，路由过程中需要跨 GPU 通信（AllToAll 操作），这会引入额外的延迟。MiniMax 通过优化通信调度和专家放置策略来缓解这个问题。他们还自己从零开始开发了适合 Lightning Attention 的 CUDA 内核，以及配套的各种计算框架，把硬件性能榨取到了极致。
训练稳定性问题。 MoE 模型的训练过程比稠密模型更容易出现不稳定——梯度震荡、专家崩塌（所有 token 都被路由到同一个专家）等问题时有发生。MiniMax 团队发现，传统的 GRPO 算法在混合注意力架构上的训练效果反而不如预期，长链推理能力出现了退化。正是这个发现促使他们研发了 CISPO 算法。
上下文扩展的渐进策略。 由于混合注意力架构的复杂性，过于激进的上下文长度扩展可能导致梯度爆炸。MiniMax 的解决方案是采用渐进式扩展——从 3.2 万 token 开始，逐步扩展到 100 万 token。就像训练长跑运动员时循序渐进地增加训练距离，避免运动损伤。
3.6 为什么 MoE 对 Agent 场景特别重要？
这里莫潇羽想多展开一点，聊聊 MoE 和 Agent 场景之间的天然契合。
在 Agent 场景中，模型需要在一个任务中频繁地进行工具调用、代码执行、结果分析等多种不同类型的操作。每种操作需要的"知识"和"能力"是不同的——写前端代码需要的知识和调试后端 API 需要的知识差异很大。
MoE 的路由机制恰好可以让不同类型的操作激活不同的专家组合。也就是说，当模型在写前端代码时，它会自动激活那些在前端任务上训练得最好的专家；当它切换到调试后端 API 时，路由器会自动选择另一组更擅长后端逻辑的专家。这种动态的能力切换，对 Agent 场景来说是非常理想的。
这也解释了为什么 MiniMax 从 M2 开始就把模型定位为"面向智能体和编程而生"——MoE 架构的路由机制，天然就适合需要多种能力动态切换的 Agent 场景。
相比之下，稠密模型在处理不同类型的任务时，总是用同一套参数，这在应对多样化的 Agent 任务时，反而可能出现"多而不精"的问题。
四、核心技术拆解二：CISPO 算法——让强化学习"不丢重要 token"
如果说 MoE 架构是 M2.5 的"骨架"，那么 CISPO 算法就是它的"灵魂"。这是 MiniMax 自研的强化学习算法，贯穿了从 M1 到 M2.5 的整个模型家族，也是 MiniMax 技术路线中最有辨识度的创新之一。
4.1 强化学习在大模型中扮演什么角色？
要理解 CISPO，首先要明白强化学习（Reinforcement Learning，RL）在大模型训练中的作用。
大模型的训练通常分为三个阶段：预训练（Pre-training）、监督微调（SFT）和强化学习（RL）。预训练让模型学会"说话"，SFT 让模型学会"按要求说话"，而 RL 则让模型学会"思考后再说话"。
在 AI 编程场景中，RL 的作用尤其关键。一个好的编程模型不仅要能写出语法正确的代码，还要能规划任务、分解步骤、自我检查、在出错时回溯修正。这些能力很难通过简单的监督学习获得，必须通过强化学习来"训练"模型的推理链路。
4.2 传统 RL 算法的"截断困境"
在 RL 训练中，最常用的算法是 PPO（Proximal Policy Optimization，近端策略优化）及其变体 GRPO（Group Relative Policy Optimization）。这些算法的核心思想是：在更新模型参数时，限制每次更新的幅度，防止模型"学过头"导致策略崩塌。
具体来说，PPO 使用了一个"截断"（Clipping）机制：如果某个 token 的更新幅度超过了预设的阈值，就直接把它的梯度贡献设为零。这个机制在大多数场景下效果不错，但 MiniMax 团队在实践中发现了一个严重的问题——
一些对推理至关重要的"反思型" token 总是被截断。
什么是"反思型" token？就是像 "However"（然而）、"Wait"（等等）、"Recheck"（再检查一下）、"Aha"（原来如此）这样表示思维转折、自我修正的词汇。这些 token 在基础模型中出现的概率本来就很低（因为预训练语料中这类表达相对稀少），在 RL 训练过程中，它们的"重要性采样权重"（Importance Sampling Weight）会变得很大。而 PPO 的截断机制会把权重过大的 token 一刀切掉——一旦被截断，这些 token 就永远失去了梯度更新的机会。
这就好比一个学生在做数学题时，刚要说"等等，让我重新检查一下这个步骤"，就被老师打断说"不用了，继续往下做"。长此以往，学生就再也不会主动检查自己的答案了。
MiniMax 的实验数据证实了这一点：在使用 GRPO 算法训练 MiniMax-M1 时，模型的长链推理能力出现了退化，在 AIME 数学竞赛题上的表现下降了近 30%。
4.3 CISPO 的核心创新：从"截断 token"到"调节权重"
CISPO 的全称是 Clipped Importance Sampling Policy Optimization（截断重要性采样策略优化）。从名字可以看出，它和 PPO 一样都用了"截断"，但截断的对象完全不同。
PPO 截断的是 token 的梯度贡献 ——也就是说，某些 token 直接被"消声"了，无法参与模型的学习。
CISPO 截断的是 重要性采样权重 ——它不会让任何 token 失去梯度，只是调节每个 token 的"音量大小"。
用一个更直观的比喻：PPO 就像一个严格的老师，如果学生的答案"太出格"，就直接把那页试卷撕掉；而 CISPO 更像一个开明的教练，它不会撕掉任何试卷，而是在旁边标注"这里的影响力需要适当调低/调高"，确保每个学生的尝试都能被记录、被学习。
从数学角度来看，CISPO 的目标函数与 Reinforce 算法非常相似，本质上是在 Off-policy 场景下做了重要性采样修正。CISPO 的关键区别在于，它对重要性采样的权重（即标量加权的量）进行 Clip 处理，通常是限制其上限，从而确保梯度不会过大，控制梯度的运行幅度——但不会让任何 token 完全丧失梯度。
4.4 CISPO 的实验效果
MiniMax 在 Qwen2.5-32B 模型上做了对比实验，结果相当显著：
- 在 AIME 2024 数学竞赛数据集上，CISPO 只用了 DAPO 算法一半的训练步数就达到了同等性能，训练效率提升了约 2 倍
- 训练过程中的 perplexity 波动幅度降低了 62%，稳定性大幅提升
- 超过 2 万 token 的长推理链完整度提升了 38%
- "Recheck""Hypothesis" 等反思类 token 的生成概率从 0.03% 提升至 0.17%
- 在软件工程任务（SWE-bench）中，代码修复准确率提升了 21%
这些数据说明，CISPO 不仅让模型训练更快、更稳定，还真正提升了模型的"深度思考"能力——那些在推理过程中起到关键转折作用的 token 得到了保留和强化。
4.5 CISPO 在混合注意力架构中的工程适配
CISPO 在 MiniMax 的混合注意力架构（Lightning Attention + Softmax Attention）中使用时，还遇到了一些额外的工程挑战。这些挑战和解决方案也值得开发者关注（莫潇羽@无忆研习社注：以下信息来源于 MiniMax 的技术分享）：
精度失配问题。 训练内核和推理内核之间存在浮点精度差异，导致重要性采样权重的计算出现偏差。MiniMax 的解决方案是将语言模型的输出头（LM Head）精度提升到 FP32，使得训练和推理阶段的 token 概率相关性从 0.987 提升到了 0.997。
优化器超参数敏感问题。 由于 MiniMax 模型中梯度范围极广（从 1e-18 到 1e-5），且相邻迭代间的相关性较弱，标准的 AdamW 优化器参数无法正常工作。团队将 AdamW 的参数调整为 β₁=0.9、β₂=0.95、ε=1e-15，才解决了训练不收敛的问题。
重复生成问题。 训练过程中，模型有时会陷入"无限重复"的状态（比如不断输出"我想想...我想想...我想想..."）。MiniMax 引入了一个简单但有效的规则：如果连续 3000 个 token 的概率都超过 0.99，就提前终止生成，避免资源浪费。
五、核心技术拆解三：Agent 原生训练框架——从训练阶段就为 Agent 而生
M2.5 的另一个核心竞争力，是它从训练阶段就把 Agent 场景放在了核心位置。这和大多数模型"先练通用底座，再微调到具体场景"的路线完全不同。
5.1 训练引擎与 Agent 环境的解耦设计
MiniMax 搭建了一套名为 Forge 的原生 Agent RL 训练框架。这套框架的设计思路非常清晰：把训练引擎和 Agent 环境彻底解耦。
训练引擎只负责处理 token 数据，对外暴露标准的 OpenAI 兼容接口。Agent 环境那边只需要专注于环境交互和上下文管理。即使是一个只有二进制程序的黑盒 Agent，也可以接入这套训练框架——只需要把它的 Base URL 替换为 Forge 内部的推理引擎服务即可。
这个设计带来了一个很直接的好处：任意 Agent 脚手架都能接入训练。无论是 Claude Code、OpenClaw、还是各种第三方工具，M2.5 在训练阶段就已经见过了各种脚手架和工具链的交互模式。所以到了推理阶段，它对这些工具的兼容性天然就比较好。
5.2 数据合成：从 GitHub 到 Expert-in-the-Loop
Agent 场景下的训练数据合成也很有讲究。MiniMax 的数据合成流程大致分为三个方向：
软件工程（SWE）场景的数据。 团队从 GitHub 的 Pull Request 和 Commit 中提取高质量的代码修改记录，筛选出最终被 Merge 的 PR 和带有测试用例的提交。然后通过 Agent 在代码沙盒里自动构建可运行的 Docker 镜像环境，再基于这些环境生成各种可验证的编程任务。
全栈应用开发（AppDev）场景的数据。 这个场景和 SWE 有一个本质区别：SWE 是在已有的代码库中修改代码，可以预定义测试用例；而 AppDev 是从零开始搭建应用，无法预先定义固定的测试标准。MiniMax 在这个场景中引入了 Expert-in-the-Loop（专家参与循环）的机制——公司内部的前端、后端、安卓、iOS 研发同学会作为"数据专家"参与进来，帮助设计评估标准和注入经验。
举个例子：M2 在写网页前端时有个坏习惯——会使用很丑的渐变色。专家就设计了一些先验 Prompt 来指导页面设计，模型在带有这些 System Prompt 的指导下采样出更好的训练轨迹。然后通过一种类似 Prompt Distillation（提示蒸馏）的方法，采样时带有 System 信息，但训练时去掉，这样专家的最佳实践就会变成模型的默认行为。
通用搜索场景（WebExplorer）的数据。 这部分主要用于训练模型在浏览器环境中搜索信息、导航网页的能力。
5.3 Process Reward：对中间步骤的精细打分
传统的 RL 训练通常只在任务完成后给一个最终的奖励分数（Outcome Reward）。但在 Agent 场景中，一个任务可能涉及几十轮对话和工具调用，如果只看最终结果，中间过程的质量就无法得到有效监控。
M2.5 引入了 Process Reward（过程奖励）机制——对 Agent 执行过程中每一步的生成质量进行打分，实现全链路监控。同时，通过评估 Agent 执行轨迹的耗时，在模型的"智能度"和"响应速度"之间寻找最优平衡点。这就解释了为什么 M2.5 跑起来既快又不傻。
在前端等场景中，仅根据静态代码很难判断质量。MiniMax 采用了 Agent-as-a-Verifier（智能体作为验证者）的方法：让另一个模型在沙盒环境中把项目完整部署起来，通过 Playwright 等工具与界面交互，根据交互后的状态变化对照评估标准打分。这和简单的 LLM-as-a-Judge 不同——它需要利用工具做多轮交互才能进行判断。
5.4 约 40 倍的训练加速
据 MiniMax 的技术分享，他们在工程层面实现了约 40 倍的训练加速。这个数字的具体构成虽然没有完全公开，但从已知信息来看，主要来自以下几个方面：
- Lightning Attention 架构本身带来的计算效率提升（将 Softmax 注意力的 O(n²) 复杂度降低到 O(n)）
- CISPO 算法在相同性能下只需一半的训练步数
- Forge 训练框架对 Trajectory（执行轨迹）的智能前缀合并，减少了重复计算
- 针对混合注意力架构优化的 CUDA 内核
这个训练效率是 M2.5 能以 10B 激活参数达到旗舰级表现的重要原因——参数少，但每个参数都在 Agent 场景上训练得非常充分。
六、实战场景一：全栈 Web 应用开发
理论讲完了，我们来看看 M2.5 在实际场景中的表现。莫潇羽准备了三个不同难度的测试场景，从简单到复杂依次拉通。
6.1 任务描述
第一个测试是一个实际需求：手里有一套九年级英语教材的资料——JSON 格式的单元知识点、Excel 的词汇表、PDF 的课文原文。目标是把它们做成一个可交互的学习网站，要求符合现代教育理念，能做测验、能追踪学习进度。
为了测试 M2.5 的自主执行能力（Agent 能力的核心指标），给它的 Prompt 里加了一句关键指令："做完再提醒我，如果没弄完停了就自己想办法推进。"
6.2 执行过程与结果
M2.5 独立完成了以下工作：
- 读取 JSON、Excel、PDF 三种不同格式的教材文件
- 自动安装项目依赖
- 搭建了一个完整的 FastAPI 后端项目
- 实现了三个 API 模块——单元内容查询、测验系统、进度追踪
- 编写了完整的前端页面
- 启动服务并自行测试 API
最终产出的网站包含 14 个单元的知识点结构化呈现、支持选择题/填空题/翻译题三种题型的测验系统、学习进度条和响应式布局。从下达需求到完成交付，整个过程大约 9 分钟。
6.3 自主 Debug 能力
在执行过程中出现了一个问题：首页路由返回了裸 JSON 数据，页面没有正确渲染。M2.5 发现这个问题后，自己进行了三轮 Debug：
- 第一轮：定位到路由配置问题
- 第二轮：修复模板渲染逻辑
- 第三轮：跑通自测验证
整个过程没有人工介入。三轮 Debug 说明 M2.5 的一次通过率还有提升空间，但"发现问题 → 定位原因 → 修复 → 验证"这套自主闭环能跑通，已经是 Agent 能力的硬指标了。
七、实战场景二：数学物理模拟与可视化
编程能力只是一个维度。一个真正强大的 AI 编程模型，还需要具备数学和物理的理解能力。
7.1 任务描述
给 M2.5 一段关于双摆混沌运动的数学可视化视频文案，要求它"理解这个视频的数学之美，选取最精彩的部分，用代码重现可视化动画。"
这个任务的挑战在于：模型不仅要能写物理模拟代码，还要先理解混沌理论在双摆系统中的具体表现，然后选择合适的可视化方案来复现。
7.2 一次失误与快速纠正
M2.5 第一次理解出了偏差——它以为这是一个视频剪辑任务，开始用 ffmpeg 拆帧重拼。在纠正了"不是剪视频，是用代码模拟物理过程"之后，它迅速切换到了正确的技术路径。
7.3 令人意外的数学功底
纠正后，M2.5 写出了一整套物理模拟引擎：
拉格朗日力学运动方程 ——这是描述双摆系统动力学行为的核心数学工具。双摆系统无法用简单的牛顿力学求解，需要用拉格朗日力学建立运动方程。M2.5 正确地使用了拉格朗日量 ( L = T - V )（动能减势能）来推导运动方程。
四阶龙格-库塔积分器（RK4） ——双摆系统的运动方程是一组非线性常微分方程，没有解析解，只能通过数值方法求解。M2.5 选择了经典的 RK4 方法，这是精度和计算量之间的良好折中。
# 四阶龙格-库塔方法的核心逻辑示意
# （莫潇羽@无忆研习社 简化展示，便于理解）
def rk4_step(state, dt, derivatives_func):
k1 = derivatives_func(state)
k2 = derivatives_func(state + dt/2 * k1)
k3 = derivatives_func(state + dt/2 * k2)
k4 = derivatives_func(state + dt * k3)
return state + dt/6 * (k1 + 2*k2 + 2*k3 + k4)Phase Space 颜色映射 ——把双摆的角度和角速度映射到颜色空间，让观众直观地看到不同初始条件下运动状态的差异。
混沌翻转检测 ——自动判断双摆何时从规律运动进入混沌状态（即摆臂翻转超过 360 度的时刻）。
40×40 网格模拟 ——同时模拟 1600 个双摆的运动轨迹，展现初始条件的微小差异如何导致完全不同的运动结果——这正是混沌理论最经典的可视化方式。
更让人意外的是，M2.5 准确理解了视频文案中提到的一些专业术语：比如"杏仁状稳定区"（在相空间中，某些初始条件区域内的双摆不会进入混沌状态，形成类似杏仁的形状）和"混沌海洋中的稳定岛"（大面积混沌区域中散布着的小片稳定区域），并在代码中做了对应的可视化实现。
最终，M2.5 使用 Remotion 框架搭建了一个完整的视频项目，包含 Intro（开场）、双摆阵列、网格场景三个段落。
八、实战场景三：企业级 CMS 系统搭建
前两个场景测试了全栈开发和数学理解能力。第三个场景直接上了难度天花板：让 M2.5 独立开发一套企业级 CMS（内容管理系统）。
8.1 需求规格
技术栈要求如下：
- 后端：NestJS
- 前端：Next.js
- ORM：Prisma
- 数据库：PostgreSQL
- 容器化：Docker Compose
- 编排部署：Kubernetes
- 额外要求：对接 OpenClaw 接口，支持自动发布内容
这个工程量相当于一个小型开发团队一周左右的工作量。
8.2 交付成果
M2.5 把整套系统搭了出来。后台管理界面清晰，内容可编辑、可发布，权限管理、全文搜索、统计仪表盘一应俱全。后端包含 8 个模块化服务，前端是完整的管理后台，加上 Docker 和 K8s 配置文件。
8.3 Bug 分析：跨文件一致性是共性短板
M2.5 生成的代码中存在 12 个 Bug——5 个后端、7 个前端。分析这些 Bug 后，发现它们主要集中在三类问题上：
跨文件一致性问题。 同一个 extractData 解包逻辑在 3 个不同文件中的写法不一致。这是因为模型在生成代码时，注意力需要分配到十几个文件上，在不同文件间保持写法一致对 10B 激活参数的模型来说确实有挑战。
ORM 兼容性问题。 部分 Prisma 写法在 SQLite 下能正常运行，但切换到 PostgreSQL 时会报错。这反映了模型在处理数据库差异时的经验不足。
功能完整度问题。 某些页面缺少操作按钮，影响用户体验但不影响核心逻辑。
坦率地说，这也是当前所有 AI 编程模型的共性短板。写单个文件很强，但跨十个以上文件保持一致性就容易出问题。只是 M2.5 由于激活参数更少（10B vs 旗舰模型的 40B+），这个问题会更明显一些。
8.4 实用工作流：M2.5 搭骨架 + 旗舰模型精修
这 12 个 Bug 后来交给旗舰级模型修复，38 分钟全部搞定。这验证了一个非常实用的协作工作流：
M2.5 负责快速搭建项目骨架和核心功能（利用其高速推理优势），旗舰级模型负责精修和 Debug（利用其更大的参数量在跨文件一致性上的优势）。一个冲锋、一个收尾，两者配合的效率远超单独使用任何一个模型。
九、OpenClaw 接入实战：如何把 M2.5 接入你的工具链
M2.5 最让莫潇羽眼前一亮的特性之一，是它对主流开发工具的兼容性。实测发现，它可以无缝接入 Claude Code、OpenClaw、OpenCode 等多个工具，无需任何代码适配。在
