MiniMax M3.1 Flash开放权重，Claude生成1.8亿行证明代码

1.8 亿行证明代码，和一张靠「CFO 已批准」就突破额度的发票，出现在同一天的阅读列表里，反差挺大。一边是 Claude 尝试用数学证明程序满足条件，另一边是付款 Agent 把业务材料里的话当成了授权。两件事放一起，我更关心的问题变了。AI 能多写多少代码，已经不足以解释它能不能上线。这份 2026 年 10 月 23 日的 AI 热点日报，我想沿着六条线聊聊模型部署、代码验收、权限、选型、扩容和业务规则，给程序员留下一些当天就能核对的判断依据。

一、MiniMax M3.1 Flash 开放权重后，自部署到底要算多少显存？

先说结论，看到「激活参数 23B」，别按一个总参数 23B 的模型准备机器。

据 IT之家报道，MiniMax 在 10 月 23 日开放 M3.1 Flash 权重，总参数 428B，每个 token 激活约 23B 参数。MoE 每次只让部分专家参与计算，能减少计算量，但没有让其余权重凭空消失。对自部署团队，总参数、量化格式、缓存和框架适配都得进预算。

另一篇 dev.to 部署分析把这个问题讲得更具体。文中介绍，模型支持最高百万 token 上下文，稀疏注意力每次查询最多读取 2,048 个 key。

很容易在这里产生错觉。每次只读这么一点，长上下文应该便宜多了吧？

读得少，不代表存得少。

按文中的解释，历史 token 的 K、V 仍然需要保留。稀疏注意力减少的是访问和计算，缓存容量依然会随上下文增长。对面向用户的服务，单个请求能塞进去，和几十个人同时使用，是两道题。

这篇文章引用的 NVFP4 KV cache 数据是每 token 34,560 字节。只按这个数字估算，256K 若按 262,144 tokens 计算，一条序列的 KV cache 就约为 8.44 GiB。这里还没有算模型权重、运行时开销和其他缓冲区，也不能把估算直接当成部署结果。

同样要带着条件读的，是 vLLM 的容量示例。在 4 张 B300、256K 上下文的配置下，M3 配 FP8 KV cache 能容纳 28 条并发序列，M3.1 对应 76 条，约为 2.7 倍。这是特定配置下的序列容量比较，业务吞吐、首 token 延迟和用户等待时间，不会自动跟着变成 2.7 倍。

回到这块，开放权重的实际价值，是团队多了一个能自行评估的选项。IT之家列出的芯片、云服务和推理框架生态，也值得看，但合作名单不能替代当前版本能否跑通、量化格式是否支持、具体硬件有没有优化内核这些问题。

要我选，我会先拿业务里最常见的上下文长度算容量，再测一组高位长度。固定硬件和框架版本，逐档增加并发，同时记录峰值显存、首 token 延迟、生成速度和失败率。百万上下文先放在能力表里，别急着放进默认配置。

二、AI 写的代码越来越多，怎样审查才不会只剩「测试通过」？

Claude 生成约 1.8 亿行形式化证明代码，听起来很像「代码正确性终于能自动解决了」。我对这个读法持保留意见。

The Decoder报道，Anthropic 与 Theorem 从 OSS-Fuzz 取用了涉及 123 个开源库的测试程序，由 Claude 分析编译后的机器码、生成证明，再交给独立程序 Rocq 检查。

这里的 1.8 亿行是证明代码。涉及 123 个库，也不等于这些库的所有行为都被完整证明。

更关键的是条件。报道提到特定处理器架构、单线程程序和小于 64 MB 的输入。结论离开这些前提，不能继续照搬。团队还报告发现了数百个常规测试遗漏的 bug，但部分案例没有公开具体软件名称和漏洞明细，我不会据此认定这套方法已经能普遍替代现有测试。

它仍然给了 AI 编程一个很有用的方向。

模型说自己做对了，和独立程序检查它做对了，是两种证据。

顺着上面聊，AI 代码审查文章讨论的是更贴近日常开发的流程。它转述的 Claude Code 团队做法，包括提交前运行测试、构建和 lint，再让使用全新上下文的 Agent 审查 diff，结合独立安全审查和人工批准处理变更。

我比较赞成把设计决定提前。组件边界、状态归属、接口契约、失败路径，最好在人让 Agent 开始实现之前就说清楚。否则审查时看到的只是一个内部逻辑挺完整、但可能解决错问题的补丁。

全新上下文审查有帮助，也有上限。两个 Agent 读到同一份含糊需求，仍然可能认可同一个错误假设。自动审查多跑一遍，并没有自动增加一个正确的需求来源。

AI 调试拆分指南提供了另一种补法，把复现、定位、解释原因、验证修复拆开。大概率你也遇到过，Agent 连续改了三轮，报错消失了，原来的问题却没被解释清楚。此时继续催它修，往往只会让改动范围继续扩大。

我会要求它先给最短复现路径，再说明每项检查能排除什么，找到原因之后才给补丁。对于权限、订单和数据写入，这个顺序尤其有价值。

当天就能试的办法，是挑一个最近的真实 bug，先固定复现输入和预期行为，让实现 Agent 修复，再把需求与 diff 交给独立上下文审查。验收时重点看它能否解释原先哪个假设失效，以及新测试为什么能抓住旧实现，而不是只数新增了几个测试。

三、Agent 能调用付款工具，为什么还必须在服务端再查一次权限？

一张 75,000 美元的发票，写着「CFO 已预先批准」，就突破了 50,000 美元额度。这件事发生在 OWASP FinBot CTF 场景里，不是真实企业付款事故，但暴露的问题很具体。

FinBot 攻击分析转述，发票 Agent 接受了外部文本里的授权说法，下游付款 Agent 又直接调用 transfer 工具，绕过发票状态检查。

这里有个坑，很多团队会把这两次失败当成一次提示注入。

其实得分开修。发票里的声明不能充当审批记录，这是信息可信度问题。底层转账入口允许绕过审批，这是执行权限问题。把 system prompt 写得更严格，修不了后者。

文章引用的本地 14B 模型测试是 5 次运行全部批准超限发票，另一组针对 gpt-5-nano 的迭代攻击测试则是 166 次中成功 4 次。这些数字不能拿来估算生产事故率，但足够说明，不能把「通常会遵守」当成支付系统的约束。

购物 Agent 分析把边界又往前推了一步。它用假设案例说明，即使付款权限没问题，也可能买错规格、漏掉数量，把标价当成到手总价。支付成功，只能证明钱付出去了，不能证明用户的采购需求完成了。

所以，买家意图、商品选择、订单条款、支付授权最好分别留记录。运费未知就保留未知，规格缺失就继续查，别让模型顺手填成一个看起来合理的值。

这段 JavaScript 展示的是付款入口应该检查哪些关系，假定订单和授权记录都已经由服务端从可信存储中读取。

function assertPaymentAllowed(order, grant) {
  if (order.status !== 'approved') {
    throw new Error('订单尚未获批');
  }
  if (grant.expiresAt <= Date.now()) {
    throw new Error('授权已过期');
  }
  if (
    order.id !== grant.orderId ||
    order.version !== grant.orderVersion
  ) {
    throw new Error('订单已超出本次授权范围');
  }
  if (
    order.payee !== grant.payee ||
    order.currency !== grant.currency
  ) {
    throw new Error('收款方或币种不符');
  }
  // 金额使用最小货币单位，不能拿模型生成的描述付款
  if (
    !Number.isSafeInteger(order.amountMinor) ||
    order.amountMinor <= 0 ||
    order.amountMinor > grant.maxAmountMinor
  ) {
    throw new Error('付款金额不合法或超限');
  }
}

最容易翻车的是 order.version 这一行，如果调用方能伪造记录，或者检查后订单还能被修改，这些比较就挡不住越权，实际执行还得绑定同一个不可变快照并处理重复付款。

OpenShell 权限分析讨论的也是类似原则，由 Agent 信任边界之外的 supervisor 检查网络策略。文章同时提醒，省略 --policy 不代表严格回退策略一定生效，镜像、已保存配置和 provider 规则仍可能影响最终权限。

这篇是文档分析，没有部署和逃逸测试，不能拿来宣称沙箱已经安全。真要落地，我会在隔离测试环境里伪造一条「领导已批准」的业务输入，再尝试绕过上层流程直接调用写入工具，检查服务端是否仍然拒绝。付款测试用桩替代真实转账，把最终生效的权限和拒绝原因一起记下来。

四、低价模型和多模型兜底，为什么可能一起增加成本？

据 IT之家关于 Decisions API 的报道，OpenAI 开放了基于 GPT-6 Luna、面向限定答案任务的接口。报道给出的价格是输入每百万 token 0.10 美元、输出免费，单次最多提交 400 个问题，并称相比通过 Responses API 调用同一模型，响应速度最高提升 10 倍。

对分类、路由、标签判断，这种产品方向挺有吸引力。前端和全栈业务里，需要模型长篇生成的步骤并没有想象中那么多，很多地方只需要从几个结果里选一个。

但「最高 10 倍」缺少输入长度、问题数量和延迟分布，暂时不能写进项目收益预估。报道也没展开模糊输入怎样拒答，接口能输出固定选项，不代表每次选择都可靠。

工单分类项目记录刚好补上了这半边。作者在 2,000 张留出工单上得到 94% 准确率，但日处理量约 4,000 张时，若线上分布与测试集相近，6% 错误就可能对应每天约 240 张错分。错误被发现前，SLA 可能已经受到影响。

最终他用 TF-IDF 加 logistic regression 做主分类器，校准分数、扫描阈值，并在不确定时交回人工。文中的 0.60 是那个项目的选择，不是其他分类系统能直接复制的默认值。

单次调用便宜，不代表整条业务处理便宜。

说实话，我更想看的是每正确处理一张工单的总成本。模型费、错误返工、人工复核、等待时间，都在里面。

再看低价接口输入计数测试。作者用约 90 tokens 的固定提示，测试了 4 个服务商的 107 条路由，部分响应报告数千输入 tokens，两条达到 14,111。

每条路由只有一次采样，部分还是第三方修改版本。额外计数究竟来自隐藏前缀、实现差异还是其他原因，尚未查明；响应里的 usage 也要和实际账单核对。我会把它当成检查供应商的理由，不会直接认定服务商在多收费。

多接一家能不能兜底？多模型失败相关性文章提醒，不同模型可能在同一批输入上一起出错。文章给出了测量思路，没有跨模型实测结果，但这个问题本身就值得加入验收。

下面这段代码统计同一批评测题里，备用模型救回了多少主模型失败的样本。

function compareFallback(rows) {
  if (!rows.length) throw new Error('评测集不能为空');

  const failedA = rows.filter(row => !row.aPassed);
  const shared = failedA.filter(row => !row.bPassed).length;
  const rescued = failedA.length - shared;

  return {
    samples: rows.length,
    primaryFailures: failedA.length,
    sharedFailures: shared,
    // 这是已知主模型答错后的救回比例，不是线上路由收益
    rescueRate: failedA.length ? rescued / failedA.length : null,
    oraclePassRate: (rows.length - shared) / rows.length,
  };
}

最容易误用的是 oraclePassRate，它假定你能识别主模型什么时候答错，线上如果没有可靠的触发信号，就实现不了这个理想结果。

我会拿同一批真实输入比较候选接口，固定提示和任务要求，同时核对 usage、账单、错误类型、人工接管率和延迟。服务不可用时切换供应商，与答案错误时切换模型，分两张表看，别揉成一个「兜底成功率」。

五、聊天 Agent 扩到多人使用，为什么先坏的是状态和延迟？

你要是也在做聊天入口，大概率已经发现，页面上的流式输出只是最容易看见的部分。会话放哪、请求能跑多久、失败后从哪里继续，才决定后台能不能扛住使用量。

Spring AI 扩容文章举了一个直接的问题。历史记录留在当前 JVM，用户下一条消息被分配到另一个实例，就找不到前文。

把会话移到 Redis 能处理实例间共享，但还没完。文章里的示例读取末尾 lastN 条消息，并不会删除更早的内容；活跃会话不断续期，存储仍可能增长。示例对工具调用消息能否完整恢复，也没有交代清楚。

这和前端关系很近。用户看到的是「它突然忘了我刚才说的话」，后台看到的可能只是一次成功的 HTTP 请求。只监控接口错误率，很难发现这种失败。

Hindsight 记忆压测则展示了另一种退化。作者用本地 Ollama、ChromaDB、5 万条对话片段，在 32GB 内存、Ryzen 9 5950X、没有 GPU 卸载的配置下测试。并发从 10 升到 25，吞吐由 8.2 增到 14.1 请求/秒，p95 延迟也从 420 升到 890 毫秒。

这里计时包含记忆检索到模型首 token，不能当成向量库查询耗时。文章后续的读写负载和内存变化还有交代不完整的地方，我不会照着这些阈值定生产容量。但它提醒得很实在，吞吐还在上涨时，慢请求体验可能已经明显变差。

长任务还得考虑中途退出。持久工作流对比区分了任务队列和流程恢复。队列可以重试任务，但任务内部已经创建资源、更新数据、发送邮件到哪一步，未必由队列替你记录。

Temporal 的确定性回放也不是保存进程内存，更不能替业务副作用自动保证只发生一次。外部写入仍然得考虑幂等、重复执行和补偿。

回到用户体验这条线，我会先用两个应用实例交替处理同一段对话，检查普通消息与工具结果能否完整恢复，再在长任务中途终止 Worker。当天把这两种故障跑一遍，比先堆缓存更容易看清状态缺口；压测时同步看 p95、会话完整性和重复写入，别只盯每秒请求数。

六、AI 客服说得流利，为什么还会把 30 天改成 90 天？

多语言客服案例里，作者检查了 300 段西班牙语对话，发现退款限制、效果承诺和价格有效期出现偏移。文中称，已有 11 位客户依据错误的 90 天有效期预约，另有 4 位客户要求退还被告知可以退的定金。

这是作者报告的单个案例，不能据此推算多语言客服的普遍错误率。但它让一个容易被演示掩盖的问题露出来了。

表达顺畅，和业务条款一致，没有必然关系。

如果验收只看对话自然不自然、回答有没有礼貌，数字和否定词的变化反而可能被漏掉。英文测过了，也不能替西班牙语、日语或其他语言签字。

作者建议把涉及钱、期限、退款和保证的句子维护成已审核的平行政策表，让模型引用固定译文。我倾向于采用这个方向，不过源政策也得先写清楚。原文示例中的「within 48 hours」没有明确起算点，源句有歧义，固定下来只会把歧义稳定地传下去。

AI 系统七项任务定义能帮忙补上更前面的决定。任务由什么触发，读什么，事实以谁为准，输出什么，送到哪里，哪些动作不能做，异常由谁处理，都应该在开发前讲明白。

我喜欢其中的事实来源这一栏。退款资格听订单系统的，用户诉求从邮件提取，价格有效期取哪一版政策，来源冲突时怎么办，这些都能提前决定。留给模型临场取舍，未必能省掉工程工作，只是把决定推迟到了更难复查的地方。

RAG 工程指南也在谈类似的问题。回答错了，未必是生成模型能力不足，可能是扫描件没解析出来、表格结构丢失、旧文档没删除，或者索引没有跟着权限变化。文章列了混合检索、重排等路线，但现有节选不足以判断哪种组合收益最好。

所以做 AI 办公提效，我会先确认系统有没有拿到正确版本、正确权限下的资料，再谈提示词怎么写。当天可以挑退款、报价、期限三类政策，每类准备几种表达和一次语言切换，逐条比对数字、否定和承诺；证据缺失或来源冲突时，还要看任务是否真的进入有人处理的队列，而不是静静留在日志里。

总结

今天这些报道里，能落到具体对象上的进展不少。MiniMax 开放了新的部署选项，Claude 的形式化验证实验展示了可独立检查的证明路径，限定答案接口也开始瞄准高频业务判断。不过，容量示例有硬件条件，证明有适用前提，低价和速度声明也还需要真实请求来核对。

我的取舍是，接下来少看一点生成量，多看一点错误怎么被发现、权限怎么被执行、失败之后怎么收场。对于前端工程师，页面可以很快搭出来，但提交、重试、转人工和多语言承诺，迟早都会回到交互里。技术管理者如果只统计 AI 写了多少代码，很可能看不到审查和返工已经挪到了哪里。

有些结论现在还不能下。M3.1 Flash 在自家硬件上的单位任务成本、多模型能救回多少真实错误、那些异常输入计数是否进入账单，都需要补测试。今天最值得带回工位的判断，是把「模型给出了结果」和「业务已经完成」分别验收。这中间差的几步，往往才是上线要花时间的地方。

参考

一、MiniMax M3.1 Flash 开放权重后，自部署到底要算多少显存？

先说结论，看到「激活参数 23B」，别按一个总参数 23B 的模型准备机器。

另一篇 dev.to 部署分析把这个问题讲得更具体。文中介绍，模型支持最高百万 token 上下文，稀疏注意力每次查询最多读取 2,048 个 key。

很容易在这里产生错觉。每次只读这么一点，长上下文应该便宜多了吧？

读得少，不代表存得少。

二、AI 写的代码越来越多，怎样审查才不会只剩「测试通过」？

Claude 生成约 1.8 亿行形式化证明代码，听起来很像「代码正确性终于能自动解决了」。我对这个读法持保留意见。

The Decoder报道，Anthropic 与 Theorem 从 OSS-Fuzz 取用了涉及 123 个开源库的测试程序，由 Claude 分析编译后的机器码、生成证明，再交给独立程序 Rocq 检查。

这里的 1.8 亿行是证明代码。涉及 123 个库，也不等于这些库的所有行为都被完整证明。

它仍然给了 AI 编程一个很有用的方向。

模型说自己做对了，和独立程序检查它做对了，是两种证据。

我会要求它先给最短复现路径，再说明每项检查能排除什么，找到原因之后才给补丁。对于权限、订单和数据写入，这个顺序尤其有价值。

三、Agent 能调用付款工具，为什么还必须在服务端再查一次权限？

FinBot 攻击分析转述，发票 Agent 接受了外部文本里的授权说法，下游付款 Agent 又直接调用 transfer 工具，绕过发票状态检查。

这里有个坑，很多团队会把这两次失败当成一次提示注入。

这段 JavaScript 展示的是付款入口应该检查哪些关系，假定订单和授权记录都已经由服务端从可信存储中读取。

function assertPaymentAllowed(order, grant) {
  if (order.status !== 'approved') {
    throw new Error('订单尚未获批');
  }
  if (grant.expiresAt <= Date.now()) {
    throw new Error('授权已过期');
  }
  if (
    order.id !== grant.orderId ||
    order.version !== grant.orderVersion
  ) {
    throw new Error('订单已超出本次授权范围');
  }
  if (
    order.payee !== grant.payee ||
    order.currency !== grant.currency
  ) {
    throw new Error('收款方或币种不符');
  }
  // 金额使用最小货币单位，不能拿模型生成的描述付款
  if (
    !Number.isSafeInteger(order.amountMinor) ||
    order.amountMinor <= 0 ||
    order.amountMinor > grant.maxAmountMinor
  ) {
    throw new Error('付款金额不合法或超限');
  }
}

四、低价模型和多模型兜底，为什么可能一起增加成本？

单次调用便宜，不代表整条业务处理便宜。

说实话，我更想看的是每正确处理一张工单的总成本。模型费、错误返工、人工复核、等待时间，都在里面。

再看低价接口输入计数测试。作者用约 90 tokens 的固定提示，测试了 4 个服务商的 107 条路由，部分响应报告数千输入 tokens，两条达到 14,111。

下面这段代码统计同一批评测题里，备用模型救回了多少主模型失败的样本。

function compareFallback(rows) {
  if (!rows.length) throw new Error('评测集不能为空');

  const failedA = rows.filter(row => !row.aPassed);
  const shared = failedA.filter(row => !row.bPassed).length;
  const rescued = failedA.length - shared;

  return {
    samples: rows.length,
    primaryFailures: failedA.length,
    sharedFailures: shared,
    // 这是已知主模型答错后的救回比例，不是线上路由收益
    rescueRate: failedA.length ? rescued / failedA.length : null,
    oraclePassRate: (rows.length - shared) / rows.length,
  };
}

最容易误用的是 oraclePassRate，它假定你能识别主模型什么时候答错，线上如果没有可靠的触发信号，就实现不了这个理想结果。

五、聊天 Agent 扩到多人使用，为什么先坏的是状态和延迟？

Spring AI 扩容文章举了一个直接的问题。历史记录留在当前 JVM，用户下一条消息被分配到另一个实例，就找不到前文。

这和前端关系很近。用户看到的是「它突然忘了我刚才说的话」，后台看到的可能只是一次成功的 HTTP 请求。只监控接口错误率，很难发现这种失败。

Temporal 的确定性回放也不是保存进程内存，更不能替业务副作用自动保证只发生一次。外部写入仍然得考虑幂等、重复执行和补偿。

六、AI 客服说得流利，为什么还会把 30 天改成 90 天？

这是作者报告的单个案例，不能据此推算多语言客服的普遍错误率。但它让一个容易被演示掩盖的问题露出来了。

表达顺畅，和业务条款一致，没有必然关系。

如果验收只看对话自然不自然、回答有没有礼貌，数字和否定词的变化反而可能被漏掉。英文测过了，也不能替西班牙语、日语或其他语言签字。

AI日报

今日看点

一、MiniMax M3.1 Flash 开放权重后，自部署到底要算多少显存？

二、AI 写的代码越来越多，怎样审查才不会只剩「测试通过」？

三、Agent 能调用付款工具，为什么还必须在服务端再查一次权限？

四、低价模型和多模型兜底，为什么可能一起增加成本？

五、聊天 Agent 扩到多人使用，为什么先坏的是状态和延迟？

六、AI 客服说得流利，为什么还会把 30 天改成 90 天？

总结

参考

AI日报

今日看点

一、MiniMax M3.1 Flash 开放权重后，自部署到底要算多少显存？

二、AI 写的代码越来越多，怎样审查才不会只剩「测试通过」？

三、Agent 能调用付款工具，为什么还必须在服务端再查一次权限？

四、低价模型和多模型兜底，为什么可能一起增加成本？

五、聊天 Agent 扩到多人使用，为什么先坏的是状态和延迟？

六、AI 客服说得流利，为什么还会把 30 天改成 90 天？

总结

参考