M2.5“AI全栈员工”来了：汽车软件与座舱体验如何用起来

2026-02-13，MiniMax 把一件“很工程化、也很现实”的事摆到了台面上：开源了 M2.5，一个10B 激活参数的 coding 模型，在 SWE-Bench Verified 上拿到 80.2%，推理速度 100+ tokens/s，官方给出的连续运行成本是约 1 美元/小时（50 tokens/s 时约 0.3 美元/小时）。更夸张的是，它上线 MiniMax Agent 后，24 小时内平台就出现了 10,000+ 个专家 Agent。

很多人看到这些数字，第一反应是“又一个写代码很强的大模型”。我反而更在意另一个描述：M2.5 强调 native spec behavior——先拆架构、先做功能规划，再进入编码，像个“人类架构师”。这件事对**汽车软件、智能座舱用户体验（UX）**尤其关键：车不是网页，容错率更低、链路更长、跨域更多（座舱、车控、云端、诊断、门店）。一个会“先写设计再写代码”的模型，才有机会真正进入生产系统。

这篇文章放在《人工智能在机器人产业》系列里讲，是因为同一套“Agent 化”能力，正在让机器人与汽车的软件工程发生同构：感知—规划—执行—反馈的闭环越来越像，区别只是执行端一个是机械臂，一个是车机与车辆控制域。

M2.5 的关键不是 80.2%，而是“原生 Agent 行为”

先把结论放前面：对企业工程团队而言，M2.5 更大的价值不是能写多少行代码，而是能按规范推进任务。

SWE-Bench Verified 80.2% 当然亮眼，但真正能落到汽车业务里的，是它把“规格（spec）”当作第一输入，而不是把提示词当作一次性指令。

从“写函数”到“做系统”：汽车软件需要的是后者

汽车软件典型特点是：

• 跨域集成：座舱 UI、车控服务、语音/多模态、云端账户与内容、数据闭环
• 强约束：启动时间、离线可用、网络抖动、功耗、隐私合规
• 长周期演进：平台化、OTA、版本兼容、灰度策略

所以“会写代码”的 AI 只是入门；能把需求拆成模块、接口、数据模型、测试方案，并持续自洽迭代的 AI，才可能成为汽车团队的生产力。

100 tokens/s 与 1 美元/小时：为什么汽车团队应该算这笔账

把它翻译成工程语言：更快的吞吐 + 更低的单位时间成本，意味着你可以把 AI 放进更多“持续运行”的环节里，而不是只在开发者 IDE 里“偶尔问一句”。

例如：

• PR 进入主干前，Agent 反复跑“静态检查 → 单测生成 → 回归建议 → 变更影响分析”
• 每次座舱版本升级，Agent 自动生成“兼容性风险清单”和“回滚策略草案”
• 需求评审后，Agent 产出“可执行的系统设计文档（含 API/数据库/埋点）”

这些都需要模型长时间在线、持续执行。成本如果不可控，就很难规模化。

一句话：在车企里，AI 要从“工具”变成“流程节点”，成本和吞吐决定了它能不能进流程。

从“全栈 AI 员工”到“汽车软件流水线员工”：三类最值得先落地的场景

结论先说：不要一上来就让 Agent 写整车系统；先让它接管高频、可验证、可回滚的环节。

下面这三类场景，最符合“可控、可评估、可扩展”。

1）座舱 UX：从需求到原型再到埋点，做成一条线

座舱体验的坑，往往不在“界面好不好看”，而在“需求变了十次后，信息架构、交互逻辑、埋点口径、推荐策略是否仍一致”。

你可以把 M2.5 这类原生 Agent 放在“体验-工程”交界处：

• 把 PRD/用户故事自动拆解成：页面结构、状态机、异常分支（无网/弱网/账号失效）
• 生成前后端契约：API、字段校验、错误码、缓存策略
• 同步生成埋点方案：事件名、属性、触发时机、A/B 实验开关位

这样做的收益很直接：UX 不是“改界面”，而是“改系统”。Agent 擅长把系统串起来。

2）车云一体：让 Agent 当“接口与数据一致性警察”

很多车企的真实问题是：云端和车端节奏不同步、字段变更没人通知、灰度策略没人维护，最后体验问题都落在用户头上。

Agent 化模型可以专门盯这些事情：

• 扫描接口变更，自动生成“车端影响评估”与“兼容性策略（新增字段/弃用字段）”
• 对比埋点口径与数据仓库表结构，发现“统计口径漂移”
• 生成面向门店/客服的“问题定位问诊脚本”（这也是用户体验的一部分）

这类工作很琐碎，但对体验很致命。人做容易漏，Agent 做反而稳定。

3）软件工程提效：把“写代码”变成“写规格”

M2.5 强调先规划再编码，这对工程管理很友好：你可以把团队的交付方式从“凭经验写”迁移到“按规格交付”。

我建议的落地顺序是：

1. 规格模板化：统一模块边界、接口规范、测试标准、日志与诊断要求
2. Agent 产物标准化：设计文档、代码变更、测试用例、回归报告格式一致
3. 门禁自动化：产物不满足门禁就不能合并（质量是被流程“夹”出来的）

当“写规格”成为主要工作，工程师更像系统设计师；而 Agent 更像可复制的执行团队。

108 天迭代与 Agent 强化学习：对汽车 OTA 节奏的启示

结论先讲：汽车软件的竞争，越来越像互联网，但必须比互联网更守纪律。

MiniMax 提到从 M2 到 M2.5 用了 108 天，SWE-Bench 从 69.4 提升到 80.2，背后是大规模 Agent 强化学习（RL Scaling）与 Forge 框架（训练引擎与 Agent 解耦、异步调度、树状合并带来 40x 加速）。

把它映射到汽车领域，有三个直接启示：

1）“快”不是频繁发布，而是更快闭环

车企常见误区是把 OTA 频率当指标。真正重要的是：

• 需求是否能快速验证（数据闭环）
• 问题是否能快速定位（可观测性）
• 风险是否能快速隔离（灰度与回滚）

Agent 的价值在于把闭环压缩：自动生成回归、自动分析日志、自动给出影响范围与修复建议。

2）多语言、多环境胜出：车端生态就是“复杂环境”

Multi-SWE-Bench 强调多语言复杂环境。汽车软件天然就是：C/C++（底层）、Java/Kotlin（Android）、Rust/Go（服务端）、Python（数据/工具链）、SQL（数据），再加上供应商 SDK、不同 SoC、不同车型分支。

一个能跨语言、跨工程形态做规划与落地的 Agent，才配得上“车规软件生产力”。

3）“原生 spec 行为”能减少跨部门扯皮

汽车公司里，体验问题经常是“产品说做了、研发说改了、测试说没复现、数据说口径不一致”。

让 Agent 先产出统一 spec（接口、状态、异常、埋点、验收标准），再编码，会明显减少扯皮成本。

People Also Ask：车企把 coding Agent 引入生产，需要回答的 4 个问题

1）会不会把不安全的代码带进主干？

会，所以要用“门禁”而不是“相信”。建议至少三道门：

• 静态检查与依赖漏洞扫描（SAST/SCA）
• 自动化测试（单测+关键链路回归）
• 变更影响分析（接口/数据库/权限/隐私）

2）隐私与数据合规怎么办？

车端数据、定位、语音等都敏感。落地方式通常是：

• 内部私有化部署或混合部署
• 训练/推理数据脱敏
• 对 Agent 工具权限做最小化（只读优先）

3）怎么评估 Agent 的 ROI？

别只看“写了多少代码”。更可量化的指标是：

• 需求到上线周期缩短（天）
• 缺陷密度（每千行/每个版本）
• 回归用例覆盖率与自动化比例
• 线上故障 MTTR（平均修复时间）

4）工程师会被替代吗？

我更相信会发生“分工迁移”：工程师更聚焦架构、约束与体验，Agent 负责执行与验证。对汽车这种高约束行业，这是更健康的形态。

写在系列里：机器人与汽车正在共享同一套“Agent 操作系统”

《人工智能在机器人产业》这条主线，本质是“让 AI 具备行动能力”。机器人靠 Agent 把规划变成动作；汽车靠 Agent 把需求变成软件、把软件变成体验。M2.5 这类模型把“先规划再执行”做成了默认行为，意味着它更适合进入真实业务链路，而不是停留在演示。

如果你在车企/供应链团队里负责软件平台、智能座舱、车云一体或工具链，我建议从一个小切口开始：选一个高频流程（比如接口变更评估或回归生成），给 Agent 明确边界、接入真实工具、设好门禁，然后用两周时间看数据。

下一次 OTA 的竞争点，可能不是“多一个功能”，而是谁能把软件迭代变成更短、更稳、更懂用户的闭环。你准备把 AI 放在哪个闭环节点上？