SWE-2 Flash 与 AesCode 32B：两个模型，同一个词，无共享基准

这个问题最终会出现在每个“编码模型”对比帖里：SWE-2 Flash 和 AesCode 32B 哪个更好？诚实的答案是，它们并不在同一个赛道上，而两者都被归入“代码生成”这一事实是分类学问题，而不是购买决策。Cognition 于 2026 年 11 月 4 日发布的 SWE-2 Flash 是一个软件工程智能体模型：它读取代码仓库、规划变更、运行工具并编辑文件。Microsoft 于 2026 年 10 月发布的 AesCode 32B 是一个审美代码模型：它接收规格说明，并为幻灯片、海报、仪表盘和信息图生成 HTML 和 CSS。一个负责关闭工单。另一个负责做出看起来经过设计的东西。

这种区分比一张基准测试表更有价值，因为选错并不是差几分的问题——而是模型根本没有机制来完成这项工作。

AesCode 32B 实际上是用来做什么的

AesCode 32B 是一个拥有 334 亿参数的视觉语言模型，基于 Qwen3-VL-32B-Instruct 构建，以 Apache 2.0 许可发布，上下文窗口为 32,000 个 token。它提供 8B 和 32B 两种变体，并与论文《AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards》一同推出；该论文介绍了其训练方法：为程序正确性和视觉质量分别设置奖励信号，从而不迫使模型在两者之间取舍。

预期的输入是一份设计简报。预期的输出是可渲染的标记。Microsoft 自己的示例是信息图、幻灯片、海报和仪表盘——在这些产物中，通过条件一部分是机械性的（表格中的数字是否正确，图表是否编码了正确的数据系列？），一部分是感知性的（它看起来是否像是由人设计出来的？）。

• 参数 — 33.4B，视觉语言，Apache 2.0

• 上下文 — 32,000 个 token

输出——HTML/CSS 产物；不使用 shell、不遍历仓库、不在所报告的评估中执行测试

• 内存占用——BF16 下约为 65 GB，FP8 下更低

它的 85.89 分意味着什么、又不意味着什么

AesCode 的核心指标是在作者为论文构建的 300 实例信息图基准上取得 85.89 的总体得分。其中，基于规则的检查（文本、边界、表格和图表）得分为 94.33，视觉质量得分为 77.44，后者由视觉语言评审从内容、布局和风格方面进行评分。同一基准中，Qwen3-VL-32B 主干模型的总体得分为 48.61，因此后训练发挥了巨大作用：仅在视觉部分就提升了 22.4 分。

作为背景，论文报告称，在同样的 300 个实例上，GPT-5.5 的总分为 81.28，Claude Opus 4.8 为 80.39。这些数字放在一起确实亮眼，但也正是需要仔细看表的原因：这是一个专门构建的信息图基准，而非通用能力指数。那一段中的每个数字都由厂商自行报告，尚未经过独立复现。既没有竞技场排名，也没有第三方复跑。

论文披露的失败模式比标题分数更有用。画布溢出在大约4.3%的生成中反复出现——远好于GPT-5.5的34.7%，这是一项实打实的优势——但关系结构破损出现在23.9%的输出中，图标失真或元素语义错误则占23.3%。风格仍然是共同的瓶颈：对比中的所有模型在该子项得分上都没有超过60%。如果你要生成生产环境仪表盘，真正应该驱动你审核流程的数字是四分之一概率出现关系结构破损，而不是85.89。

SWE-2 Flash 报告了什么——以及为什么这些内容没有任何重叠

SWE-2 Flash 报告了八行数据，全部都是智能体或安全评估：FrontierCode 2.0 为 24.0，FrontierCode 1.1 Main 为 45.5，DeepSWE 1.1 为 60.1，Terminal-Bench 4.0 为 20.0，Terminal-Bench 2.1 为 89.2，SWE-Atlas QA 为 50.0，SWE-Bench Pro v2 Hard 为 89.9，ExploitBench 为 34.8。每一项都是 Cognition 自己的数字，运行在发布帖未具名的测试框架上。

没有视觉质量这一行。没有布局评分，没有渲染检查，也没有设计评审。无论 SWE-2 Flash 擅长什么，它都从未在 AesCode 所围绕的维度上被衡量过，而 AesCode 也从未在智能体软件工程这一维度上被衡量过。这两张表除了一个列标题之外，没有任何共同之处。

实际投入也是如此。SWE-2 Flash 在 Devin Desktop 和 Devin CLI 中运行，免费至 2026 年 11 月 30 日，没有 API、没有模型 ID，也没有公布上下文窗口。AesCode 32B 则可在任何能加载 65 GB 权重的地方运行，或由任何提供它的推理服务商托管，其上下文窗口公布为 32,000 个 token，并采用 Apache 2.0 许可证。一个是需要订阅且无法检视的产品，另一个是可以下载并量化的制品。

它们相遇的狭窄之处

有一处真正的重叠，值得点明，因为团队实际上正是在这里出错。如果你的智能体产生面向用户的输出——一个报告页面、一个状态仪表盘、一张生成的幻灯片——那么在该流程的某个环节，模型必须决定布局。一个仓库编辑模型会乐于输出能正常工作但看起来像 2009 年的 HTML。一个设计模型会乐于输出一个漂亮的仪表盘，但里面的数字是错的，因为它无法访问你的测试套件或数据层。

那是一条承担两项任务的流水线，而不是一场只有一个赢家的比较。真正的决策是：设计这一步究竟要作为一次独立调用，配备自己的模型和自己的审核关卡，还是接受由单个通用模型产出的平庸版式。在意视觉结果的团队最终会把这步拆出来；不在意的团队则根本不该购买设计模型。

费用、获取途径以及你实际会花多少钱

• AesCode 32B —— 以 Apache 2.0 协议开放权重，因此边际成本只取决于你自己的 GPU 或服务商的按 token 计费费率；无需向厂商订阅。

• SWE-2 Flash — 在 Devin 内可免费使用至 2026 年 11 月 30 日，之后未定价，因为 Cognition 在发布时未公布每 token 费率。

• AesCode 的隐性成本——评审关卡。23.9% 的关系结构失败率，意味着每个产物都需要人工或程序化验证。

• SWE-2 Flash 的隐性成本——锁定效应。如果免费窗口以你不满意的条款关闭，就没有可回退的端点。

目前，这两款模型都无法通过 OrcaRouter 调用：SWE-2 Flash 完全没有可用端点，AesCode 32B 也不在目录中。但这项对比真正说明的是其周边路由层的形态。OrcaRouter 在一个密钥之后提供超过 200 款模型，其路由 DSL 允许你把不同的模型固定到单次组合调用的不同步骤上——这正是上文所述的“这一步做设计、那一步做工程”的分工。你无法从我们这里获得这两款模型中的任何一款。你获得的是一个统一入口，用来放置你最终选定的任意一对模型，并能在其中某个模型于凌晨两点不可用时自动故障转移。

经验法则

如果你的用户看到的产物是拉取请求，那么 SWE-2 Flash 在范围内，而 AesCode 32B 不在。如果产物是幻灯片、海报、仪表盘或信息图，那么 AesCode 32B 在范围内，而 SWE-2 Flash 根本做不了这项工作——不是做得差，不是做得慢，而是完全做不了。如果两者都需要，你需要两次调用，并对涉及设计的那次加一道评审关卡。

真正有用的比较目前还不存在：还没有人把 AesCode 32B 放进一个能对照测试套件检查自身渲染输出的智能体循环里运行过，也没有人在布局基准上运行过 SWE-2 Flash。在这两者之一发生之前，唯一站得住脚的说法就是那个平淡无奇的结论。这些模型不能相互替代，任何把它们的分数列在相邻两列的表格，都是在用同一把尺子衡量两件不同的事。