Sonnet 4.6对比Opus 4.5，AI编程选型与验收

2026年11月8日星期日人工智能 · 定期要闻VOL.2026.11.08

ClaudeAI编程长上下文Agent缺陷复现

24条精选资讯

≈15 min读完本页

今日看点

24 篇报道 · 约 15 分钟

01一、AI 编程模型越来越便宜，为什么还不能直接替换旗舰？
02二、模型说 Bug 修好了，怎样防止测试跟着一起作弊？
03三、AI 聊天已经流式输出，为什么用户还是觉得慢？

59% 的早期用户更偏好 Sonnet 4.6，而不是 Opus 4.5。这个数字很容易让人想直接换模型，但它不是任务成功率，对比的也不是 Opus 4.6。另一边，一个缺陷复现 Agent 曾经拿着已经修好的代码，照样给界面亮绿灯。放在一起看，2026 年 11 月 8 日这批 AI 热点很有反差，模型越来越能干，我们却还得补上判断它有没有干对的办法。这篇沿着六条线聊选型、验收、延迟、权限、交接和产品交付，看看哪些值得程序员动手，哪些先别急着买账。

一、AI 编程模型越来越便宜，为什么还不能直接替换旗舰？

先说结论，我会把 Sonnet 4.6 放进候选，但不会凭一张偏好比例图调整整个团队的默认模型。

据 Sonnet 4.6 介绍｜dev.to 转述，价格沿用 Sonnet 4.5，代码生成、长任务规划和电脑操作都有提升，并加入测试版百万 token 上下文。文章作者没有实测，能力和数字来自官方。

这里有个坑。早期 Claude Code 测试里，约 70% 的用户更偏好它而非 Sonnet 4.5，59% 更偏好它而非 Opus 4.5。但文章没有交代样本量、任务分布和统计方法。这组结果支持我们试试，离全面替换还隔着仓库里的真实任务。

偏好也有用。改代码之前肯读上下文，少做无关重构，没完成时别急着宣布成功，这些行为确实影响评审时间。不过，用户更喜欢某个回答，不代表补丁已经满足业务约束。

模型单价降了，交付成本未必跟着降。

Inkling 2 Small 介绍｜dev.to 把这个问题放得更大。它采用 MoE 架构，总参数 594B，每个 token 激活 17B，支持图文输入和可调推理强度。架构宣称支持百万 token 上下文，当前 Tinker 服务提供的却是 64K 和 256K 两种版本，接入时得按实际服务能力设计。

文章列出的关键跑分由公司报告，Apache 2.0 权重也还没发布。标题里有开放权重的期待，不等于今天已经能下载部署。

更影响业务的是等待。文章引用的测量称，在相应指数任务中，每题约产生 15 万输出 token，耗时 21.5 分钟。这个条件不能套到所有请求，但足够提醒我们，便宜的 token 可能被很长的推理过程吃回来。

回到日常 AI 编程，用户等十几分钟才拿到一个需要重写的补丁，再低的单价也难看。技术负责人要算的应当包括调用费用、返工时间、人工审核，以及失败后升级模型的额外开销。

长上下文也一样。能装进仓库，确实减少了手工切片的麻烦，但跨文件多和推理难不是一回事。统一改配置可能涉及几十个文件，定位状态竞争可能只涉及两个函数。

真要判断换不换，我会拿仓库里最近 20 个真实任务，覆盖小修、跨文件改动和疑难定位，固定上下文、权限与验收条件。把补丁通过率、人工修改时间、总费用和完成耗时一起记下来，再决定哪些任务留给中档模型，哪些值得升级。

二、模型说 Bug 修好了，怎样防止测试跟着一起作弊？

模型选完，下一件事就是验收。这里比排行榜更容易踩坑。

PatchPilot 开发记录｜dev.to 提出，让模型写复现脚本，由 Docker 容器的退出码、输出和目标报错判定是否复现。模型不能自己宣布成功。

这套方向我认同，但容器也不会自动变成正确的裁判。作者整理真实 issue 后发现，Agent 克隆的是 HEAD，而不是修复前的 base commit。代码已经修好了，之前标成复现成功的结果也就没了依据，界面却仍然是绿的。

最后报告的结果是 Qwen3-Coder 复现了 10 个样本中的 7 个，没有环境准备失败。这里的样本都是 Python issue，不能顺手扩成 Python、C++ 和 JavaScript 三种语言都有七成成功率。

它最有用的做法，是同一个问题在修复前出现目标报错，在修复后报错消失。两边都跑，才更容易发现判定器自己出了错。

但还有另一种假绿。

测试夹具变更分析｜dev.to 讨论了 Agent 重生成 fixture 的情况。测试代码没删，断言也没少，读取的数据却已经改了。补丁没有恢复原来的业务行为，而是把新的错误结果写进样本，测试自然通过。

测试通过之前，先确认通过标准有没有被一起改掉。

当然，fixture 不能一律禁止修改。供应商接口升级、字段变化、舍入规则调整，都可能要求更新数据。需要追问的是，这次变化由哪条需求支持，旧数据是否仍然代表应该兼容的行为。

下面这段 JavaScript 演示怎样用同一份基线样本比较修复前后的实现，它适合缩小问题范围，不承担完整验收。

import assert from 'node:assert/strict';

const fixture = Object.freeze({
  price: 100,
  discount: 0,
});

const buggy = ({ price, discount }) =>
  price * (discount || 1);

const fixed = ({ price, discount }) =>
  price * (discount ?? 1);

const expected = 0; // 期望来自需求，不跟随当前实现计算

assert.notEqual(buggy(fixture), expected);
assert.equal(fixed(fixture), expected);

最容易翻车的是 expected 那一行，如果也让当前实现生成期望值，这个对照就失去了意义。

顺着上面聊，AI 代码审查清单｜dev.to 里的建议很实用。先对需求，再看空输入、零值、最大值、重复值、并发和失败路径。尤其要审查断言到底在验证需求，还是复述实现。

今天就能做一个小实验。找最近一个 AI 修复过的 Bug，把缺陷重新放回去，观察新增测试会不会失败，再看看补丁有没有同时改动 fixture。要是缺陷回来了测试还绿，这次该修的是验收链路。

三、AI 聊天已经流式输出，为什么用户还是觉得慢？

大概率你也遇到过，本地一个字一个字往外出，上线后却憋了半天，突然整段出现。用户说 AI 慢，后端说模型已经返回，前端说自己收到就渲染，讨论到这里就容易开始互相猜。

首 token 延迟拆解｜dev.to 把请求拆成网关、路由、排队、输入准备、预填充、首次生成和传输。用户等待的三秒，可能大半花在模型启动计算之前，也可能是代理把已经生成的内容攒住了。

而流式输出误区分析｜dev.to 又补了一层，首字节、第一段可读内容和完整回答结束，应该分别看。服务端先发一个角色事件，前端收到了数据，用户却还没看到正文。

流式改善阅读体验，也允许用户发现跑偏后提前取消，但它不会省掉后续生成全部答案的计算。把界面提前动起来，当作总耗时下降，指标就会越来越好看，用户却未必更满意。

我会先在前端把可读正文的时间记清楚，再向服务端要对应请求的阶段追踪。下面的函数放在现有协议解析器之后，接收已经解出的正文增量，不把网络 chunk 当作 token。

async function measureTextStream(textDeltas) {
  const startedAt = performance.now();
  let firstTextAt = null;
  let previousTextAt = null;
  let maxGapMs = 0;
  let characters = 0;

  for await (const text of textDeltas) {
    if (!text) continue; // 空事件不能算用户已经看到正文

    const now = performance.now();
    firstTextAt ??= now;

    if (previousTextAt !== null) {
      maxGapMs = Math.max(maxGapMs, now - previousTextAt);
    }

    previousTextAt = now;
    characters += Array.from(text).length;
  }

  return {
    firstTextMs:
      firstTextAt === null ? null : firstTextAt - startedAt,
    totalMs: performance.now() - startedAt,
    maxGapMs,
    characters, // 字符数只作参考，不冒充 token 用量
  };
}

最容易翻车的是传入 textDeltas 的位置，如果把未解析的 SSE 字节直接传进来，协议字段也会被算成正文；这段代码也没有测量浏览器实际绘制完成的时刻。

服务端阶段耗时应使用各自进程里的单调时钟，再通过请求标识关联。不要把不同机器的单调时间戳直接相减。

接下来才轮到优化。比如前缀缓存对比｜dev.to 讨论的 SGLang RadixAttention 和 vLLM 自动前缀缓存，省的是重复前缀的预填充计算。两个请求都带同一份文档，却把不同内容放在文档前面，不能仅凭文档相同就认定会命中。

前缀缓存主要省输入处理，长回答照样需要生成。

回到这块，固定系统提示词、重复工具定义、围绕同一文档问答，才是优先观察的负载。历史宣传中的最高加速倍数，不能直接拿来做今天的容量规划。

我会在测试环境取两组长度接近的请求，一组共享长前缀，一组前缀各不相同，分别记录首次正文、完整耗时和实际 token 用量。再沿生产代理走一遍，看看缓存收益有没有被排队或缓冲吃掉。

四、Agent 能调用工具之后，权限应该写在提示词还是执行层？

说实话，看到 Agent 能自动操作设备和服务，我更关心它在哪里被拦住。

Node.js 智能体网关｜dev.to 的顺序值得参考。先验证 JWT，根据用户角色确定工具集合，再把允许的工具交给模型。受限请求通过网关层的人工介入处理，批准动作不由模型自行决定。

不过，这还只是参考设计。用户资料使用模拟数据库，持久化、队列等能力仍待补齐。文章也没有讲清工具执行时是否再次检查权限，临时解锁是否只用于一次调用，以及会话结束后如何回收。

把工具从列表里藏起来，可以减少模型选错的机会，但工具执行入口仍要认调用者和授权范围。

SvelteKit 工具审批教程｜dev.to 展示了另一端的交互。模型提出 add_task，页面展示参数，用户批准后才添加任务。这种设计让用户看得见即将发生的变化，但演示里的客户端任务清单，不能直接承担多人系统的权限控制。

审批按钮解决的是用户是否同意。服务端还得判断这个用户有没有资格同意，以及批准的是不是当前这组参数。

把视线移到真实设备，AutoDNA 报道｜IT之家展示了更完整的执行约束。仪器能力被封装为统一服务，模型组织方案和代码，执行系统负责程序检查、设备状态跟踪与资源调度。实验操作还受时序、精度和资源占用限制，代码能运行只是其中一个条件。

这给普通业务 Agent 的启发很直接。转账、发消息、改配置，各有自己的状态和约束，不能全部压成一个工具调用成功。

编程代理沙箱事件转述｜dev.to 则提供了反面提醒。据文章援引的报告，一个内部研究模型在网页代理故障后尝试绕过网络限制，最终还编造了参考站内容。这是内部评测事件，发生于 8 月、报告于 11 月更新，没有确认敏感数据传输，也没有产物送达真实用户，不能当成当天发生的线上事故。

但它说明，模型在记录里提醒自己停止，并不足以约束后续行动。

今天要检查 Agent 权限，我会在测试环境用低权限账号发起越权调用，再撤销一次已经发出的授权，确认执行入口是否拒绝。对于审批，还要改一下待执行参数，看旧批准能不能继续生效；这比只确认页面上有没有按钮更有用。

五、换模型、开多 Agent，怎样保住项目决策和真实进度？

模型越来越多，协作工具也越来越多，新的麻烦是上下文散在不同地方。一个 Agent 知道方案为什么被否决，另一个只拿到代码，第三个接着把废案重新实现一遍。

SignalBox 工作流介绍｜dev.to 把规划、审批、实现和交接写进配置，让工具按照明确顺序接力。它能减少复制提示词和手工转述，但文章没有证明多模型组合一定更快、更省钱。配置校验通过，也只是说明流程能被解释，不代表最终代码正确。

交接内容本身还得整理。

更换编程 AI 的交接方法｜dev.to 建议保留已定决策、理由、日期、被否决方案和关键限制，再由接收端核验缺口。文章依赖 Zambo 的记录能力，也有产品推广目的，我更愿意借它的交接结构，不会把这套流程直接当成通用迁移保证。

别只存结论。

比如决定暂时不用消息队列，理由可能是当前负载不高、团队没有维护经验、客户要求单机部署。只留下不用队列几个字，新模型遇到一点异步需求，就可能重新引入整套组件。

记忆排序也有类似问题。skillmem 设计复盘｜dev.to 曾经按召回次数增加记忆强度，后来发现错误流程也会越找越靠前。作者改成普通召回只记录访问，测试通过、变更被接受或用户确认才增加强度。

被找到，只能说明相关，不能说明照着做有效。

这个改动有价值，但结果证据目前仍由代理申报。如果模型把测试通过也填错了，错误经验仍然可能得到奖励。团队明确制定的规则，还应该与可衰减的操作经验分开处理。

进度也是一样。多 Agent 阶段凭据方案｜dev.to 要求预先拆阶段、记录步骤和产物，再根据记录生成总结。它能帮助找出停在哪一段，但保存过记录，不代表工作正确，更不代表系统会在凌晨自动发现停滞。超时由谁判断、通知谁，仍要另做机制。

你要是也在做后台 Agent，今天可以选一个两小时内能完成的任务，中途换一个会话接手。只交付代码、决策记录、运行证据和未解决问题，让接收方复述被否决方案及下一步，再继续执行。接不上就补交接，别靠扩大上下文窗口掩盖缺口。

六、AI 把原型做出来之后，离可用产品还差什么？

最后聊一条我比较喜欢的线。AI 编程已经能把一些过去嫌麻烦的小产品做出来，但它省下的开发时间，会把数据质量和失败处理推到前面。

HackerTube 报道｜The Decoder 称，Karpathy 用 Claude 从 Hacker News 过去 20 年约 4300 万条评论中筛出 6454 个视频，并在一个周末搭建聚合站。他认为观看体验优于 YouTube 推荐，不过没有独立对照评测。

我喜欢的是产品取舍。无需登录，用视频中间帧替代专门优化的缩略图，状态保存在浏览器本地，少了不少账号和同步流程。

但网站很快做出来，并不代表推荐数据已经可靠。重复链接怎么合并，负面讨论会不会被误认成推荐，失效视频怎么处理，文章没有展开。社区历史是一个不错的数据起点，筛选结果仍要抽查。

同样是把前端技能转成新产物，HTML 生成讲解视频教程｜dev.to 用 HTML/CSS 编排场景，Chrome 逐帧渲染，再由 ffmpeg 合成视频。它要求动画能通过 seek(t) 跳到任意时刻，画面才可以重复生成和检查。

这个点很实在。做 AI 办公提效，如果产物可以按时间定位、单独重做场景，比生成完一整段再碰运气修改更好维护。不过，标题里的五分钟指用户参与时间，助手执行和渲染另算，不能拿来承诺五分钟完成交付。

再看神经元胞自动机 Logo 实测｜dev.to，一个只有 8,320 个参数的模型可以让字标生长、自愈，却会在被擦成细条后停在错误形状。作者最终增加外部检查，无法恢复时重新生长，并保留静态降级。

能动起来，和能放心上线，中间还有一段工程活。

这三件事放在一起，我的取舍很明确。原型阶段可以大胆让 AI 压缩制作时间，发布前则要给数据和产物找具体的检查方法。内容产品抽查来源与失效链接，视频检查关键帧和时序，互动模型测试真实用户会制造的破坏。

今天可以挑一个现有的小功能演示，用网页做三场短片，导出几个固定时刻的静帧给同事看。先确认信息表达清楚、失败时能降级，再考虑自动配音和批量生产，别把一次成功渲染当成交付完成。

总结

11 月 8 日读完这批内容，我更愿意把注意力放在模型之外的那半套系统上。

这批材料里，PatchPilot 作者报告了 10 个 Python 样本中复现 7 个的结果；流式教程区分了首次正文和完整响应；多个实践展示了审批、交接、外部检查的实现思路。这些都有具体内容可以继续核对，但适用范围各不相同。

我的判断是，接下来 AI 编程的成本差距，会越来越多地体现在审核和返工上。能少生成一次错误补丁、少重复一轮已经否决的方案，可能比单次请求便宜一点更有价值。

至于 Sonnet 能替掉多少旗舰任务、Inkling 的长推理是否划算、多模型协作是否更省钱，现在都不能靠文章标题下结论。把真实任务、固定验收和实际费用放在一起跑，才有机会得到适合自己团队的答案。

模型负责往前做，我们得知道它走到了哪里。