AI测试覆盖率100%却只得4%，Gemini 3 Flash也会猜错

一张票据，总金额被胶带遮住了一半，四个视觉模型给出了四个不同的金额，其中三个还报了 92–100 的置信度。另一套测试更扎眼，行覆盖率做到 100%，变异测试得分却只有 4%。读完 2026 年 10 月 11 日这批 AI 热点，我最在意的是那些看着已经完成、实际上还没验收的工作。今天沿着结果可信度、测试、权限、成本、恢复和产品体验六条线聊，看看程序员该把检查放在哪，哪些能力可以试，哪些承诺先别信。

一、视觉模型置信度很高，为什么还不能直接用结果

先说结论，模型报出来的置信度，不能直接当成业务系统的放行条件。

票据遮挡测试里，真实总金额是 255.61，但图片上只能看到总金额末尾的 .61，而且有一项明细也被遮住了。这种输入既不能直接读出总金额，也不能靠明细相加还原，正确回答应当是无法判断。

四个视觉模型却给出了四种金额。作者报告，其中三个回答的置信度在 92–100 之间。Gemini 3 Flash 的答案是 230.61，恰好等于可见明细合计 211.03，加上它编出来的隐藏明细 19.58。结果不仅像真的，尾数还对得上。票据遮挡测试｜dev.to

这才是麻烦的地方。

如果我们做的是报销录入、订单核对或 AI 办公提效工具，一个格式合法、看起来合理的金额，很容易穿过表单校验。校验器能判断它是不是数字，却不知道这个数字有没有证据。

这项测试的设计比单张截图更值得借鉴。作者用代码生成账单和标准答案，每个条件有 48 张账单，并构造了两种接近的遮挡情况。总金额的遮挡相同，只改变另一块胶带的位置，让一张可以根据明细计算，另一张信息不足。这样才能区分模型是在算账，还是顺着图片补一个答案。

顺着上面聊，TwinBench 也在用类似思路检查 Agent。它给同一道题做配对输入，只修改一个决定结果的字段，要求两题都答对才计分，覆盖配置优先级、时区、重试条件等任务。TwinBench｜dev.to

我喜欢这种评测方法，但不会跟着文章标题推导出所有模型都不可靠。它最终保留的题目经过失败次数筛选，本来就偏向困难样本；当前这批内容也不足以让我复核模型的完整成绩。它适合帮我们找薄弱点，不能直接拿来估算整个业务的成功率。

回到这块，前端接模型结果时，应该给无法判断留一个正式出口。金额字段旁边最好能区分直接读取、明细计算和信息不足，后端再核对证据与业务规则。否则产品只允许成功和失败，模型就更容易把缺信息包装成成功。

真要当天验，我会拿十来张票据做配对样本。一组只遮总金额，一组再遮一条明细，用同样的提示词调用，分别统计计算正确率和拒绝猜测的比例。模型是否愿意停下来，比它敢报多高的置信度更有用。

二、AI 写的测试覆盖率满分，为什么改坏代码仍然全绿

覆盖率只能证明代码执行过，不能证明错误会被发现。

AI 测试文章引用了一套行覆盖率达到 100%、变异测试得分只有 4% 的测试。这个 4% 的分母是测试中植入的代码变异，不能扩写成只能发现所有真实缺陷的 4%。但它已经足够说明问题，绝大多数被植入的逻辑变化没有让测试失败。AI 测试与变异测试｜dev.to

这里有个坑，AI 编程很容易生成一套跟着实现走的测试。函数返回什么，它就断言什么；模拟对象怎么配置，它就验证模拟对象被调用。测试文件很长，报告很好看，可业务规则从来没有受到挑战。

同一篇文章还转述了 QueueMate 的案例。实现和检查交给不同模型，检查方生成了 554 个测试用例，发现 38 个缺陷，其中包括实现方自己写的测试漏掉的会话处理严重问题。这个案例支持引入独立检查，但还不能证明换个模型就一定能得到同样收益。

检查者也可能共享同一套错误理解。

函数重命名的文章给了另一个很贴近业务的例子。Agent 把 process_payment 改成 settle_payment，更新了 import 和函数定义，静态检查、单测都通过。可定时任务配置里的 jobs.process_payment 没改，任务后来失效了。字符串引用遗漏｜dev.to

对前端来说，这种问题并不陌生。事件名、动态路由注册、插件名称、配置里的组件映射，都可能靠字符串连接。符号重构处理得再漂亮，也未必覆盖这些入口。全文搜索本身能找到字符串，漏掉通常出在搜索范围、文件类型或工具处理方式上，不能把锅都甩给字符串。

要我选，我会先看测试有没有守住业务边界。比如优惠门槛刚好相等时应该怎么算，权限不足时是否返回数据，同一请求重放时会不会重复写入。比再补几十条正常输入更有价值。

下面这段 JavaScript 用一个门槛判断演示最小变异检查，重点是看测试能不能识别 >= 被改成 >。

const cases = [
  { amount: 99, expected: false },
  { amount: 100, expected: true }, // 相等边界决定能否发现这次变异
  { amount: 101, expected: true },
];

const original = amount => amount >= 100;
const mutated = amount => amount > 100;
const passes = fn =>
  cases.every(({ amount, expected }) => fn(amount) === expected);

console.log({
  originalPasses: passes(original),
  mutantSurvives: passes(mutated),
});

最容易翻车的是 amount: 100 这一行被漏掉，剩下两个用例对原实现和错误实现都会放行。

当天能做的检查很小。挑一个金额、权限或状态流转函数，手动改一个运算符，看看测试是否失败；再挑一份 AI 重命名 PR，搜完整仓库里的旧名称，实际触发一次配置注册或任务入口。这样发现的缺口，比覆盖率再涨两个点更实在。

三、编码 Agent 和 RAG 接进业务后，权限到底该拦在哪

删除防护和 Claude Code 加固两篇文章，其实在讨论同一个问题。Agent 会读到不可信内容，也可能拿得到敏感数据，还拥有执行动作的通道。三个条件凑在一起，误操作或提示注入才有机会造成损失。Claude Code 安全加固｜dev.to

只匹配 rm -rf 的规则覆盖不了全部删除写法，也判断不了变量展开后的真实目标。删除防护文章举了空变量拼接路径的例子，并建议把容器或 VM、非特权用户、只读挂载和备份放在命令规则之外。编码 Agent 删除防护｜dev.to

我的读法是，命令规则适合提前提醒，能写到哪里才决定损失有多大。

不过，路径展开成危险目标，也不等于所有环境都会真的执行成功。具体命令、系统保护和权限都会影响结果。我们应该测边界，不能拿一段命令推导必然发生的事故。

RAG 文档问答把这件事搬到了数据访问层。文章举例，一个普通问题召回了共用索引里的 HR 薪资文档，聊天机器人给出答案并附上引用。相似度只负责找相关内容，不负责判断提问者有没有权看。RAG 权限泄露｜dev.to

你要是也在做企业知识库，别把隐藏菜单当成权限控制。租户、角色和文档受众应该在服务端确定，并在检索阶段落实过滤，让未授权文本尽量不要进入后续上下文。引用、摘要和日志也要沿用这个边界。

这不是模型多提醒一句就能补上的。

提示注入清洗中间件的复盘又提供了一个反面提醒。方案设计了文本或嵌套 JSON 的清洗与审计接口，却在干净 QA 环境里、处理输入之前就崩溃了。提示注入中间件复盘｜dev.to

我对这条持保留意见。这里没有能支持清洗有效性的对照结果，所以我只把它当接口设计和部署验证的线索。清洗组件就算能正常运行，也不能替代文件权限、检索权限和执行权限。

当天验证不用真凭据。建两个测试租户，放入普通文档和带明显标记的私密文档，用普通账号提问，检查答案、引用和脱敏日志；编码 Agent 则在临时目录里测试正常清理、空变量和文档诱导三种情况。真正该看的，是越界请求有没有被执行层拦住。

四、MCP 和推理强度怎么计费，为什么一次成功仍可能很贵

说实话，我更愿意看每个验收通过任务的成本，而不是一次调用用了多少 token。

mcp-tax 0.3 修正了旧版按会话只计算一次工具定义的模型，改为按模型调用轮数累计。文章给出的例子是，工具定义占 30k token，连续 20 轮都发送这套定义，累计输入量就是 600k。MCP 逐轮成本审计｜dev.to

这里得分开两笔账。600k 是多轮累计量，不是某一轮上下文窗口里同时塞了 600k。缓存可能降低输入价格，但每轮仍要容纳实际发送的定义。客户端有没有按需加载工具、每轮到底发送哪些 schema，也会改变这个估算的适用范围。

所以我不会看到接了十个 MCP server，就按工具总数直接算账。我会先查真实请求。

mcp-lint v0.2 从另一头提醒我们，工具定义还会影响调用质量。它检测词序交换、大小写和分隔符差异，也检测编辑距离较近、同时有参数或描述相似证据的工具名。MCP 近似工具名检查｜dev.to

工具多，不一定更省事。一次选错工具，就可能增加解释、重试和人工审查。但这个检查器能指出命名风险，不代表已经量化了错误调用率下降多少。合理的相似名称也可能被标记，仍然要结合业务语义判断。

推理强度的测试则直接挑战了默认开 high 的习惯。作者固定题集、提示词和评分器，对四款模型进行了 1,800 多次评分调用。high 只在一组测试里带来统计显著提升，gpt-5.4-mini 的逻辑题准确率从 15% 升至 97.5%；12 个模型与任务组合里，7 个准确率没有变化，每个正确答案的成本却升至原来的 1.5 至 3.4 倍。推理强度对照测试｜dev.to

这个结果支持按任务选档位，不能推导成 high 没用。它测的是特定题集，而且不同模型对档位的支持和行为并不一致。

Bedrock 教程提供了更朴素的方法，读取响应里的输入、输出 token，再分别乘以对应单价。Bedrock 调用费用核算｜dev.to

回到团队选型，我会把失败尝试也计入成本。跨语言 AI 编码评测文章同样建议固定模型和等价任务，同时记录修复轮次、通过情况和交付前剩余工作，文章没有预设哪种语言更优。跨语言 AI 编码评测｜dev.to

当天可以挑五个真实任务，固定工具权限与验收条件，只改推理档位或工具集合中的一个因素。记录总费用、耗时、重试和最终通过数。哪组单次便宜不重要，哪组把活交完更便宜才值得继续试。

五、Agent 显示成功，为什么还会重复发邮件、重复花钱

n8n 文章里，一个支付通知工作流把邮件发了两遍，执行列表却仍然都是绿色。n8n 外部副作用与崩溃测试｜dev.to

绿色只能说明工作流按它记录的状态走完了，无法单独证明外部动作只发生一次。

最棘手的是请求已经到达外部服务，但本地没有观察到响应。超时以后，我们不知道动作失败了，还是动作完成、回执丢了。直接重试可能重复执行，直接标失败又可能误导用户。

另一篇 Python 管线复盘，暴露的是相似的计数问题。每条评论最多调用模型三次，文件也都采用原子写入，可两个入口并发操作时，模型调用完成后保存失败，排队进程仍可能再次调用。原子写入与重试预算｜dev.to

原子替换保住了 JSON 的完整性，却没有把读取次数、调用模型和保存结果变成一个事务。作者的修复包括共用锁、获取锁后重读状态，以及调用之前预留尝试次数。预留写不进去，就不发请求。

这个取舍会让一次未完成的尝试也占用预算，但它避免了调用已经发生、磁盘却毫无记录的情况。

下面这段 JavaScript 演示的是故障注入位置，故意在外部请求返回后、本地完成状态写入前抛错。

async function deliver(job, { provider, store, injectCrash = false }) {
  const receipt = await provider.send({
    payload: job.payload,
    idempotencyKey: job.id, // 只有服务商落实幂等语义才有保护
  });

  if (injectCrash) {
    throw new Error("故障注入：外部返回后，本地完成记录前");
  }

  await store.markDone(job.id, receipt.id);
  return receipt;
}

最容易翻车的是 provider.send 和 store.markDone 之间，外部动作与本地记录没有共同事务；这里抛异常能检查恢复分支，但还不等同于真实进程被终止。

可观测性文章建议用 run ID 串联目标、阶段、工具调用、延迟和结果，并记录重试、token 和每个完成任务的成本，配合检查点、幂等键和输出校验。Agent 工作流可观测性｜dev.to

我会给不知道结果的调用留一个「待核对」状态。只有对方支持可依赖的幂等或结果查询，恢复流程才有依据；本地多加一个状态字段，不能凭空获得恰好一次的保证。

当天就能用假服务商记录每次请求，注入返回后保存失败，再重跑一次任务。然后增加请求已提交但客户端超时的场景，检查系统会不会盲目重试。邮件、写入和模型调用都值得这么测，页面上的成功提示也应该等到结果确认后再展示。

六、世界模型和桌面 Agent 很炫，前端产品该先接哪一层

Odyssey-3 开放公共研究预览，可以根据文本实时生成交互环境。报道介绍，基础模型为 140 亿参数，在线演示使用 Odyssey-3 Flash，用户可以切换视角并在生成世界里移动。Odyssey-3 研究预览｜The Decoder

它很适合探索新的交互方式。但实时画面响应和可靠控制机器人之间，还有很长一段距离。

报道提到的 Physics-IQ Verified 66.1 分，来自单轮测试，并从每项任务的八段生成视频里筛选一段；纪录声明要求四轮测试并报告标准差。不筛选时，四轮平均分为 63.37。两项结果均由 Odyssey 自行提交，不能把最高数字直接写成控制能力已经胜过其他方案。

OpenAmer 则在解决更贴近日常工作的桌面自动化。它优先支持 Windows，尝试向目标窗口发送合成输入，让用户继续操作电脑，也讨论了 DPI、焦点和原生对话框时序的问题。OpenAmer 桌面自动化｜dev.to

我对不抢鼠标这个方向有兴趣，但文章也承认部分原生控件可能需要短暂借用焦点。它运行在用户真实会话里，能利用真实应用和登录状态，同时也要求更明确的能力边界。

对前端团队来说，接下来要设计的不是一个万能输入框，而是可看懂、可中断、可核对的任务界面。

Helicon 提供了一个具体参照。这个非官方 Muse Code 桌面客户端把跨项目会话、代码 diff、逐项审批和费用估算放在一起，使用现有 Muse 登录状态，支持 Windows、macOS、Linux 及 VS Code 扩展，当前仍是早期版本。Helicon 桌面客户端｜dev.to

它的启发是把审阅动作放回用户能理解的位置。费用估算仍然是估算，图形界面也不能替代执行层授权，但至少能让人知道 Agent 正准备改什么。

视频生成工作流文章把输入校验和扣费边界讲得更细。源视频与角色参考图分别提供不同信息，扩展名合规不代表时长、尺寸、帧率、编码和大小都合格；服务端必须在派发付费任务前再检查。视频生成输入校验｜dev.to

下面这个 JavaScript 对象适合表达界面状态，把输入是否就绪、报价是否对应当前输入、任务是否确认完成分开处理。

const generationState = {
  input: {
    status: "needsPreparation",
    reasons: ["视频尺寸需要调整"],
    revision: 3,
  },
  quote: {
    inputRevision: 2, // 输入变化后，旧报价不能继续放行
    confirmed: false,
  },
  job: {
    status: "idle",
    runId: null,
  },
};

const canSubmit =
  generationState.input.status === "ready" &&
  generationState.quote.confirmed &&
  generationState.quote.inputRevision === generationState.input.revision;

最容易翻车的是只检查 confirmed，用户换了视频或输出选项，系统却仍沿用旧报价；服务端也要核对同样的关联关系。

FitGuru 的架构给了另一个取舍。它用端侧 MediaPipe 和关节角度状态机处理实时动作与计数，一组训练结束后才让认知模块接收数值做复盘，摄像头视频不上传云端。FitGuru 端侧健身教练｜dev.to

这是黑客松作品，不能据此认定动作识别已达到成熟产品水准。但实时处理和低频模型分析分工，我认为很值得参考。

当天我会挑一个低风险流程做完整演练，从无效输入、预处理、报价变化到结果待核对都走一遍。体验世界模型时，则盯住动作后的连续响应与场景一致性，别只看第一屏好不好看。演示能吸引人，异常状态才能告诉我们产品还差什么。

总结

今天这批材料里，能确认的是几类具体观察。作者记录了遮挡票据下的高置信错误回答，报告了特定测试套件的覆盖率与变异得分差距，也复现了模型调用后保存失败导致再次调用的问题。这些都有明确条件，不能扩写成所有视觉模型、所有 AI 测试或所有工作流的整体表现。

我的判断是，AI 编程和 AI 办公提效接下来最值得投入的部分，是结果验收、权限边界和恢复流程。代码生成快不快当然重要，但如果检查与返工越来越多，程序员只是把工作从敲代码挪到了追问题。

还有一些承诺我会继续观望。提示注入清洗的效果没有在这批内容里得到证明，工具名检查减少多少错误调用也没有量化，世界模型的物理分数更不能直接兑换成可靠控制能力。

模型说完成了以后，系统还得拿得出完成的证据。

要我选，明天会先给现有流程补一个会失败的测试、一个不能越过的权限边界，以及一个能核对重试结果的记录。做完这些，再决定要不要接更多工具、开更高推理档位，账会清楚得多。

参考

一、视觉模型置信度很高，为什么还不能直接用结果

先说结论，模型报出来的置信度，不能直接当成业务系统的放行条件。

这才是麻烦的地方。

二、AI 写的测试覆盖率满分，为什么改坏代码仍然全绿

覆盖率只能证明代码执行过，不能证明错误会被发现。

检查者也可能共享同一套错误理解。

下面这段 JavaScript 用一个门槛判断演示最小变异检查，重点是看测试能不能识别 >= 被改成 >。

const cases = [
  { amount: 99, expected: false },
  { amount: 100, expected: true }, // 相等边界决定能否发现这次变异
  { amount: 101, expected: true },
];

const original = amount => amount >= 100;
const mutated = amount => amount > 100;
const passes = fn =>
  cases.every(({ amount, expected }) => fn(amount) === expected);

console.log({
  originalPasses: passes(original),
  mutantSurvives: passes(mutated),
});

最容易翻车的是 amount: 100 这一行被漏掉，剩下两个用例对原实现和错误实现都会放行。

三、编码 Agent 和 RAG 接进业务后，权限到底该拦在哪

我的读法是，命令规则适合提前提醒，能写到哪里才决定损失有多大。

这不是模型多提醒一句就能补上的。

四、MCP 和推理强度怎么计费，为什么一次成功仍可能很贵

说实话，我更愿意看每个验收通过任务的成本，而不是一次调用用了多少 token。

所以我不会看到接了十个 MCP server，就按工具总数直接算账。我会先查真实请求。

这个结果支持按任务选档位，不能推导成 high 没用。它测的是特定题集，而且不同模型对档位的支持和行为并不一致。

Bedrock 教程提供了更朴素的方法，读取响应里的输入、输出 token，再分别乘以对应单价。Bedrock 调用费用核算｜dev.to

五、Agent 显示成功，为什么还会重复发邮件、重复花钱

n8n 文章里，一个支付通知工作流把邮件发了两遍，执行列表却仍然都是绿色。n8n 外部副作用与崩溃测试｜dev.to

绿色只能说明工作流按它记录的状态走完了，无法单独证明外部动作只发生一次。

这个取舍会让一次未完成的尝试也占用预算，但它避免了调用已经发生、磁盘却毫无记录的情况。

下面这段 JavaScript 演示的是故障注入位置，故意在外部请求返回后、本地完成状态写入前抛错。

async function deliver(job, { provider, store, injectCrash = false }) {
  const receipt = await provider.send({
    payload: job.payload,
    idempotencyKey: job.id, // 只有服务商落实幂等语义才有保护
  });

  if (injectCrash) {
    throw new Error("故障注入：外部返回后，本地完成记录前");
  }

  await store.markDone(job.id, receipt.id);
  return receipt;
}

最容易翻车的是 provider.send 和 store.markDone 之间，外部动作与本地记录没有共同事务；这里抛异常能检查恢复分支，但还不等同于真实进程被终止。

六、世界模型和桌面 Agent 很炫，前端产品该先接哪一层

它很适合探索新的交互方式。但实时画面响应和可靠控制机器人之间，还有很长一段距离。

对前端团队来说，接下来要设计的不是一个万能输入框，而是可看懂、可中断、可核对的任务界面。

它的启发是把审阅动作放回用户能理解的位置。费用估算仍然是估算，图形界面也不能替代执行层授权，但至少能让人知道 Agent 正准备改什么。

下面这个 JavaScript 对象适合表达界面状态，把输入是否就绪、报价是否对应当前输入、任务是否确认完成分开处理。

const generationState = {
  input: {
    status: "needsPreparation",
    reasons: ["视频尺寸需要调整"],
    revision: 3,
  },
  quote: {
    inputRevision: 2, // 输入变化后，旧报价不能继续放行
    confirmed: false,
  },
  job: {
    status: "idle",
    runId: null,
  },
};

const canSubmit =
  generationState.input.status === "ready" &&
  generationState.quote.confirmed &&
  generationState.quote.inputRevision === generationState.input.revision;

最容易翻车的是只检查 confirmed，用户换了视频或输出选项，系统却仍沿用旧报价；服务端也要核对同样的关联关系。

这是黑客松作品，不能据此认定动作识别已达到成熟产品水准。但实时处理和低频模型分析分工，我认为很值得参考。

总结

模型说完成了以后，系统还得拿得出完成的证据。

AI雷达日报

今日看点

一、视觉模型置信度很高，为什么还不能直接用结果

二、AI 写的测试覆盖率满分，为什么改坏代码仍然全绿

三、编码 Agent 和 RAG 接进业务后，权限到底该拦在哪

四、MCP 和推理强度怎么计费，为什么一次成功仍可能很贵

五、Agent 显示成功，为什么还会重复发邮件、重复花钱

六、世界模型和桌面 Agent 很炫，前端产品该先接哪一层

总结

参考

AI雷达日报

今日看点

一、视觉模型置信度很高，为什么还不能直接用结果

二、AI 写的测试覆盖率满分，为什么改坏代码仍然全绿

三、编码 Agent 和 RAG 接进业务后，权限到底该拦在哪

四、MCP 和推理强度怎么计费，为什么一次成功仍可能很贵

五、Agent 显示成功，为什么还会重复发邮件、重复花钱

六、世界模型和桌面 Agent 很炫，前端产品该先接哪一层

总结

参考