回看 2025 年 Q2 到 2026 年 Q1，AI 的发展路径清晰得惊人：上下文扩充、成本降低，最终催生了 Agent 的爆发。在这场狂奔中，MiniMax 仅用 270 余天就迭代了五个模型版本，点亮了从上下文长度到 Agent 能力所有的“技能点”，甚至跑走完了上市流程——对于一家只有四百余名员工的公司，这本身就是一场 AI Native 组织的极限实验。
我们都在等待 MiniMax 证明一个问题：一个 AI-Native 型的创业组织，能跑多久，到达何种位置？
这也是我们为何必须测试一下 MiniMax M2.7 。
为了验证这一点，我在 3 月 18 日发布前一天拿到的测试资格，第一时间把 API 接入了 Cursor，同时在 MaxClaw 上加载了 MiniMax 自己开源的应用开发系列的 Skills，基本就算完成了所有测试准备。
这个过程我没考虑 Claude Code，也没选择 OpenClaw —— MiniMax 自始至终都是一家对 C 端 /D 端体验比较关注的 AI 平台型公司，那就不妨让这种体验再平权一些：价格高的、部署复杂的，咱都不考虑。
从官方消息来看，MiniMax M2.7 的更新重点有四类：
更真实的软件工程能力，包括 Agent 场景下的 Cowork 能力；
专业办公能力；
自我进化能力；
更好的互动娱乐表现，包括人设保持和情商；
除了互动娱乐表现，其他三项都在本次测试计划内。我避开了写游记、做网页等常规 Demo，设计了一套更贴近真实业务“烂摊子”的测试题：
输入端（办公测试）：扔给它一份包含非标数据、公式断裂的“圆明园式” Excel，看它能不能像 BI 一样挖掘数据价值；
生产端（工程测试）：不给详细需求文档，让它从零开发一套管理系统，并在报错中自主迭代，验证其“自我进化”能力；
协作端（MaxClaw 测试）：体验多 Agent 协同，看它能否真正理解并执行复杂的技能流。
从数据处理到系统构建再到多智能体协作，最终指向一个终极问题：AI 能否真正“干活”而非“演示”？ 测试结果，出乎我的意料。
它比 BI 更懂业务
谈及专业办公，一个事实情况是，大语言模型不能很好的处理表格数据。因此业内有许多大数据团队、BI 类产品，正在进行低调的二次创业，产品理念就是 AI + BI，处理 Excel 数据。
看起来， Excel 呈现的是一些结构化数据；实际上，Excel 更像一个“压缩包”，里面包含了公式、格式、引用关系、命名区域等杂七杂八的对象。而大模型的输入只是 Token 序列，两者之间存在结构性错位。
此外，当数据以 Excel 的形式输入大模型，消耗的 Token 量轻松翻倍，即使上下文窗口达到 100K ，很容易导致一个中等大小的 Excel 报表被截断。
最后，所谓的结构化数据，放在实际业务场景中，一般都是非结构化的……以媒体业务为例，内容类型的标准写法通常是：图文、视频、音频、博文……实际的填写情况一般是：头条、三条、单推、微博置顶三天……这种混乱是真实业务的常态，也是大模型最容易翻车的地方。
总结一下，在我们眼里一个结构精美的 Excel 报表，在大模型眼里可能就跟圆明园差不多——所以我特地准备了一份结构有“一点”复杂的真实业务报表，200 多行，100 多列，包含文字、数字、日期、公式、表格合并等要素，涵盖 InfoQ 过去一年的主要合作情况。
这份报表在经过基本的脱敏工作以后，我投喂过 ChatGPT 等一众主流 ChatBot，会被截断，无法正常解读；投喂过一家创业公司的 Agent 平台，导致对话卡死，无法回复，报了 Bug。现在又被我投喂给了 M2.7。
我们先来看看上下文问题。
MiniMax 比较精巧的一点是，官网默认访问 MiniMax Agent，而非一个 ChatBot，所以面对这个问题直接拉起 Agent 开始写 Python 脚本。
最终输出为：
交付物统计：406 行 × 147 列（列数最多）
2025 年 项目看板：405 行 × 130 列
这个数字证明，Excel 不但没有被截断，数据量比我预想的还要大。仔细检查表格后我才发现，在上百空行后，存在一个孤零零的误录入数据，此前一直没有被发现过：
这其实是个非常模糊的提问，我并未说明所谓的合作规模用什么数据界定。同时子业务与集团的关系，需要模型自己去查证判断。
M2.7 没有被这份'烂数据'带偏——分类逻辑、金额汇总、集团归并全部正确。
这属于业务经营的常规问题，但标准同样模糊，同时考验对数据的整体理解和分析。
M2.7 的数据解读无误：
同时模型也提供了业务发展的四个关键洞察，且都有数据佐证：
Q2 和 Q4 是交付旺季，需提前储备人力和资源；
xx 的已交付项目尚未回款，建议加强应收账款管理（数据不准确，但是数据源的问题，而非解析问题）；
2025 年新项目金额同比增长 58%，业务增长强劲；
内容能力是核心，深度稿件贡献超 1/4 收入；
至此，数据分析的结论已经有了，但如何将结论以专业、直观的形式呈现，是办公场景的另一大挑战。于是我提出了第四个问题：
M2.7 调用了 Excel 处理技能，构建了透视表框架，准确设置了行、列及多个值字段，并按要求分项目经理创建了对比视图。最终交付物是一个结构清晰、可直接用于对比分析的工作报表稽核，以及一份关于专班组建策略的业务洞察和分析报告。
（受限于业务敏感数据，仅展示部分分析结果）
从读懂数据、理解业务逻辑，到直接生成可汇报的分析图表——对办公能力的考察可以告一段落了。尤其是 Excel 数据处理的能力考察，我觉得可以告一段落了，同时也给行业留下了几个问题：
我一度想采购智能 BI 产品做数据分析，但现在觉得用 MiniMax 就够了，如果这是普遍情况，那么 BI 类产品对小微企业的商业逻辑是否面临调整？
MiniMax 不做 ChatBot ，但做了 Agent 平台。在 AI 办公领域，ChatBot “水土不服”的情况早已出现，MiniMax 做了很好地产品演示。
MiniMax Agent 免费版每天提供 200 积分，上述交互一共开销 117 积分，智能成本还在降低。
根据 MiniMax 财报电话会的情况看，压注 2026 AI 办公赛道，是个确凿无疑的事情。紧接着另一个大命题就是软件工程能力——VibeCoding 因为代码太过随性而遭受诟病，正在走向台前的是 Harness Engineering，这也成为了对 MiniMax M2.7 的测试重点。
看见“自我进化”的雏形
关于软件工程，我的测试方向是开发一款业务流管理软件。众所周知，在国内做类似的软件开发是不赚钱的——钱少事儿多难复制。比如对于一家媒体公司而言，选题就是生命线，但市面上还没有成熟的选题管理工具。媒体公司要么自研，要么降级使用表格或多维表格。
于是我给了 MiniMax M2.7 一个非常笼统的指令，调用平台为 Cursor——
过往应用构建平台，遇见此类笼统问题，大概有两种处理模式，一种是蒙，既然 Prompt 不够好，那就随便做，质量不能保证；还有一种是对话式询问，需要用户阶段性提供关键信息和指令。
在我看来两种都不够科学。许多 AI Builder 不具备软件工程能力和产品能力，意味着他们天然无法很好地描述一个软件架构。如果 AI 不能根据模糊指令产出一个质量足够高的软件作品，使用上就会面临很大的限制，不叫 AI Coworker，应该叫 AI Codeveloper。
M2.7 的交付物至少具备完整的功能设计，以及进一步优化和迭代的基础。至少对于小团队来说，是绝对可以投入使用的：
这里有一些 UI 问题，我们留到后面解决。关于软件逻辑的优化，也一并放在后续测试中。
添加日志系统，是为了尽量填补非职业开发者和职业开发者之间的界限，实现非职业开发者也能一定程度上尝试定位系统问题。
这次开发遇见报错，指使 M2.7 自查并修复了问题：
修复后，可以看到日志系统已添加，且可以将选题数据导出为 Json 文件：
这是本次测试最值得记录的一个瞬间——M2.7 没有等我提问，没有停留在简单的指令遵循层面，而是自己重写了存储架构，自主完成了进化。
但同时，这次自主进化也导致了新的 Bug 出现，页面再一次无法正常显示了。
这次的修复比较复杂，非开发者已经看不懂了，内容如下：
问题分析与修复
发现的问题
Logger 异步初始化问题：之前的 logger.js 使用了复杂的 async/await 和 .bind() 模式，导致 Logger 方法在 IndexedDB 初始化完成前不可用
全局错误处理器的同步调用：在模块加载时直接调用异步的 logger.logError() 会导致问题
修复内容
Logger 重写为同步优先架构：
即使 IndexedDB 不可用，内存存储仍能正常工作
后台异步尝试持久化到 IndexedDB
所有日志方法立即写入内存（同步操作）
全局错误处理器安全包装：
window.onerror = (message, ..., error) => { safeLog.log(error, 'Uncaught JavaScript Error'); // 不会崩溃 };降级方案：
最多保存 100 条内存日志
IndexedDB 不可用时自动降级到内存存储
值得肯定的是，M2.7 工程判断能力在线，它重新设计了日志系统的架构，采用了生产级日志系统的标准设计模式。一个 AI 在没有被明确要求的情况下，自主收敛到了这个方案，说明它对"日志系统应该长什么样"有真实的工程认知，不只是在修 bug。
不过问题是，走到正确判断的路途是相对曲折的——M2.7 的推理过程更像是“试错”，充斥着大量类似词汇："The issue is likely...""Wait, let me re-read...""Actually the bigger problem...""But wait...""Let me reconsider..."，注意力焦点有些漂移，中途一度想加一个安全检查，打补丁了事。
但换个角度想，只要推理不是过于漫长，那么对于 AI 来说，时间不是个稀缺资源——AI 可以 24 小时工作，保障正确即可：
至此，可以说 MiniMax M2.7 有足够的工程能力去做应用，而不是 Demo。但作为业务负责人，我已经厌倦了不停驱使它调试 Bug，我需要它自己设计好升级节奏。
M2.7 规划了一个“7 天改进计划”：
关于生产级软件开发评测的最后一 Part，我想增加两个极限压力测试。这里“极限”的概念与软件研发领域的“极限”概念不同，我无意写 Python 脚本去考验这个作品的读写性能，但想把业务场景真实的混乱和矛盾带给它，看看它的“智能极限”在哪里。比如：
如果一次性给出 8 条含约束条件的复杂指令，它还能做好指令遵循吗？
如果给出一条自相矛盾的指令，它会如何处理？
于是问题 6 和 7 应运而生：
Q6：在现有工具基础上增加以下功能：
① 新增'预计阅读量'字段，只接受数字输入；
② 状态字段新增'已归档'选项；
③ 热度评分改为 1-10 分制，低于 6 分自动标红；
④ 新增选题导出功能，导出为 md 格式；
⑤ 导出时自动过滤掉'已归档'状态的选题；
⑥ 页面顶部显示当前未归档选题总数；
⑦ 所有时间字段统一显示为 MM-DD 格式；
⑧ 新增一个'备注'字段，支持多行文本输入
Q7：导出功能需要同时满足：① 选题导出的范围，要包括已归档的选题；② 已归档的选题为废弃选题，不能导出；③ 只有一个导出按钮
第六个问题，指令全部完成，没有丢失。第七个问题则彻底把 M2.7 绕进去了，它没有再次跟我确认指令的矛盾之处，而是选择把已归档选题直接过滤掉。
这延伸出一个直观问题：如果要构建一个生产级的复杂系统，自洽的产品设计仍然应该是前置的、必须的，全部扔给模型边看边做，很可能会出现问题——毕竟 AI 可以支持长上下文，人却可能自相矛盾。
MaxClaw多步骤Agent测试
在 Agent 社区“龙虾模式”爆火的当下，MiniMax 顺势也推出了 自己的龙虾模式：MaxClaw，内置模型也更新成了 M2.7。
就在 M2.7 发布的同一天，被龙虾带火的第三方测评榜单 PinchBench 更新了排名。
在 Best Score 口径下，M2.7 以 86.2% 的任务完成率挤进全球第四，超越了 NVIDIA 的 Nemotron 3，与第一名 Sonnet 4.6 的差距只有 0.7 个百分点，进一步验证了其在复杂 Agent 任务上的竞争力。
说实在的，用了接 M2.7 的 MaxClaw 以后，我已经完全不想体验其他的 OpenClaw 产品了。
切换会话环境以后导致 Skill 无法正常触发，因为权限问题导致对话无响应，出现问题无法自查只能穷举原因……最近调试各路 “OpenClaw”让我仿佛回到了程序员时代，不是不能 Debug，而是厌倦 Debug。MaxClaw 让我重新找到了“寄存大脑”的感觉。
- 安装 Skills 直接抛链接，遇到网络问题自己重试
- 完全抛弃配置页面，只负责对话框给信息
- 一句话拉起四个 Agent 开始干活
- 遇见问题自主解决，自主推进流程
必须要强调，在我看来，AI 时代所有软件层面的使用困难，都是产品力和研发效能不足的直观体现，用“动手能力” PUA 用户的时代应该结束了。在这点上，MaxClaw 做得很好。
综合来看，MiniMax M2.7 在办公场景的能力，软件工程能力，与自家 MaxClaw 的适配度都超出我的预期。应该说，上市前后，MiniMax 管理团队面向资本市场抛出了许多“故事”和“大饼”，但实现速度也比市场预期的更快——至少帮我节省了许多 BI 工具和 Coding 产品的订阅费用。
核心待优化点，仍然是最复杂事件的处理，包括相对复杂的 Bug 的快速定位；大规模改写代码时，如何降低出错概率；多轮对话中，针对自相矛盾的 Prompt，如何更妥善的进行处理。这些恐怕也是当下所有 Coding Agents 面对的共同课题。
如果你是一个“一人公司”的实践者、小微公司的管理层，MiniMax M2.7 可能会在一个统一的平台上，帮你解决多个维度的问题，同时不需要支出大笔的订阅费用，也不需要到处跑会，学习“龙虾部署”。
这次测试给我留下最深印象的，不是某一个具体的答对或答错，而是一种感觉——AI 正在悄悄越过'辅助工具'的边界，开始侵蚀专业人员的领域。MiniMax 的 Agent 平台，正让这条边界变得越来越模糊。至于这对 BI 赛道、对 AI 办公、对创业公司意味着什么——答案已经在数据里了。
