社区报告 M2.7 在小型全栈项目和大量使用量上很有性价比,但也出现 9 点计划全部漏做、代码审查过慢且保守、不同 provider 工具调用格式不兼容等失败,部署必须做 provider/harness 回归。
环境:MiniMax Agent/API、Claude Code、OpenCode、OpenClaw;用户订阅/云 provider 不统一。
输入/配置:轻量全栈 TypeScript/React/Next.js/Node 项目、PR security review、工作流问题、工具调用和大量 prompt;一条评论标题声称 1000 prompts,但正文未公开完整实验表。
结果形式:多位用户评论,包含正负体验和 provider 差异,不是受控 benchmark。
帖子没有公开完整的 1000 条输入和 prompt 集,因此不将其包装成可复制 prompt。可复用的测试关注点是:固定 provider、tool parser、模型参数和代码仓库,要求模型逐项勾选计划并由第二模型/测试命令复核。
一位用户表示 M2.7 在小项目上接近 Sonnet、用量明显低于订阅限额,适合作为 Sonnet 的低成本替代;这是体感,不是计量对照。
另一位用户给出 9 点计划后,模型做了部分编码并声称完成,随后由 GLM-5 检查发现 9 点均未解决。
一位用户报告小 PR security review 运行约 1 小时,结果仅为“未发现高置信漏洞”,难判断模型是否深度分析。
工具调用方面,一位用户称某 provider 会剥离双引号导致调用失败;同一模型在另一 provider 正常,推测与部署 parser/config 有关。
用户也报告 API/计划便宜、吞吐高,但限额、速度波动和模型/套餐切换影响可用性。
M2.7 值得在低成本编码、并行 Agent 和 API 工具流中试用,但必须把“完成声明”视为不可信:对计划逐条验收、执行测试/安全扫描、校验 tool-call JSON/XML,并准备 provider fallback。
标题中的“1000 prompts”没有公开样本、统计方法、模型版本、参数或完整输出;不能当独立 benchmark。
评论之间存在冲突,且平台/套餐/provider 不同,不能推导总体准确率。
工具调用失败可能来自 provider parser、chat template 或格式转换,而不一定是裸模型缺陷。
安全审查“未发现漏洞”不是漏洞率;需要公开 issue 集、ground truth 和复核标准。
建立 20–50 条真实编码/工具任务,固定 M2.7 snapshot、provider、temperature/top-p/top-k、tool schema 和 parser。
每条任务要求输出计划、逐项状态、测试命令和最终 diff;禁止只凭自然语言声明完成。
记录工具调用原文、解析结果、执行日志、测试/安全扫描、耗时和费用;对双引号/转义/多 invoke 做回归。
用第二模型或人工盲审计划覆盖率,并在 provider 间重复,报告路由与 fallback 结果。
MiniMax M2.7