跑分榜单看多了，人会麻木。一个模型在 HumanEval 上刷到 90 多分，在 SWE-bench 上多涨几个点，这些数字对真正每天写代码的人来说，参考价值其实很有限。原因很简单：跑分题是被人为裁剪过的，输入干净、目标明确、边界清晰，而真实项目里的编程任务是另一回事——需求模糊、上下文散落在十几个文件里、改一处崩三处。所以我一直有个习惯，新模型出来先不看榜单，直接扔两个自己手头真实的活儿进去跑一遍，看它到底能不能干活。
这次上手的是 Step 5 Preview。官方给的几个关键标签挺有意思：MoE 架构、1M Token 上下文、支持视觉输入。这三个点恰好对应了真实编程任务里最痛的三个地方——推理成本、长上下文理解、以及"看着截图改 UI"这种多模态需求。我挑了两个任务来实测：一个是偏工程的长上下文重构，一个是偏多模态的界面还原。下面把整个过程、踩到的坑、以及我对这套东西的理解完整写出来，给同样在观望的人一个参考。
1. 为什么我放弃了跑分，改用真实任务做评测
1.1 跑分题和真实编程任务之间隔着一道鸿沟
先说清楚我为什么不信任跑分。跑分题的设计逻辑是"可自动判定"，所以它必须把问题简化成有唯一正确答案的形式。函数签名给你、输入输出格式给你、甚至连注释都帮你写好了。但真实工作里，你拿到手的往往是一句"这个页面加载太慢了，你看看"，然后你得自己去翻代码、定位瓶颈、判断是数据库查询问题还是前端渲染问题，最后才动手改。
这中间的差距，本质上是问题定义能力和上下文整合能力的差距。跑分考的是"给定明确问题，你能不能写出正确代码"，而真实任务考的是"你能不能从一堆模糊信息里把问题定义清楚，再写出不破坏其他部分的代码"。后者才是日常工作的主战场。
所以我评测模型有个原则：任务必须来自我真实的工作队列，不能是为了测试而编的题。这样测出来的结论才能直接指导我"这个模型能不能进我的工具箱"。
1.2 我选这两个任务的标准
这次选的两个任务，分别压测 Step 5 Preview 的两个核心卖点。
第一个任务是长上下文代码重构。我手上有个模块，逻辑分散在多个文件里，互相引用关系复杂，我想把它整理成一个内聚的模块。这种任务的特点是：需要同时理解大量代码，且改动必须保持全局一致性。这正好压测 1M Token 上下文到底是不是噱头——如果模型只能看到局部，重构必然出错。
第二个任务是视觉输入驱动的界面还原。我有一张设计稿截图，需要把它变成可运行的页面代码。这种任务压测的是视觉理解能力：模型能不能准确识别布局结构、间距、颜色、组件层级，而不是把截图当成一张"大概长这样"的模糊参考。
这两个任务一个偏"深"（长上下文），一个偏"广"（多模态），基本能覆盖一个编程助手在实际工作中的主要使用场景。
1.3 MoE 架构对实际使用意味着什么
在动手之前，有必要把 MoE 这个点讲清楚，因为它直接关系到你"用不用得起"。
MoE 全称是 Mixture of Experts，混合专家。传统稠密模型处理每个 token 时，所有参数都要参与计算；MoE 则是把模型拆成很多个"专家"子网络，每个 token 只激活其中一小部分。打个比方：稠密模型像一个所有科室都得上班的医院，不管你看什么病，全院医生都得待命；MoE 则像分诊制，你挂哪个科就只叫哪个科的医生，其他科室该休息休息。
这对实际使用的影响是推理成本大幅下降。同样规模的总参数量，MoE 每次前向传播实际参与计算的参数少得多，所以响应更快、单位算力能服务的请求更多。但这里有个很多人搞混的点，也是热搜里反复出现的疑问：MoE 架构要全部参数进显存吗？
答案是：要。这是 MoE 最容易被误解的地方。MoE 省的是"计算量"，不是"显存占用"。因为虽然每个 token 只激活部分专家，但你不知道下一个 token 会路由到哪个专家，所以所有专家的权重都得加载在显存里随时待命。省计算不省显存，这是 MoE 的基本特征。理解了这一点，你就能明白为什么 MoE 模型往往"跑起来快，但部署门槛不低"。
对普通使用者来说，这个细节的意义在于：如果你是通过 API 调用，那 MoE 带来的成本优势会体现在价格和速度上；如果你是想本地部署，那显存需求并不会因为 MoE 而降低，别被"稀疏激活"这个词误导了。
2. 任务一：跨文件长上下文重构实测
2.1 任务背景与代码规模
这个任务来自我一个真实项目。项目里有个数据处理模块，最初是赶工期堆出来的，逻辑散落在 6 个文件里：有工具函数、有配置、有主流程、有错误处理，互相之间还有循环引用。代码总量大概在 3000 行左右，加上注释和空行，实际喂给模型的上下文接近 4000 行。
我的目标很明确：把这些散落的逻辑合并成一个内聚的模块，消除循环引用，保持对外接口不变。这个任务对模型的要求是：它必须同时"看到"所有相关文件，理解它们之间的依赖关系，然后做出全局一致的改动。如果它只能看到局部，就会出现"改了 A 文件，但 B 文件里还在用旧接口"这种典型错误。
2.2 我是怎么组织上下文的
这里有个实操细节值得展开。虽然 Step 5 Preview 号称支持 1M Token，但能塞进去不等于能理解好。我的经验是，上下文组织方式对结果影响极大。
我的做法是分三层组织：
- 第一层是任务说明：用自然语言写清楚我要做什么、约束是什么、哪些不能改。这部分放在最前面，因为模型对开头和结尾的信息注意力最集中。
- 第二层是文件清单和依赖关系：我先自己梳理了一遍文件之间的引用关系，用文字描述出来，相当于给模型一张地图。
- 第三层才是代码本体：按依赖顺序排列，被依赖的放前面。
这么做的理由是：长上下文模型不是"看得越多越好"，而是"结构越清晰越好"。你把 4000 行代码一股脑倒进去，模型确实能读，但它在做决策时容易迷失在细节里。先给它一张地图，它就知道该往哪看。
提示：组织长上下文时，把"任务目标"和"约束条件"放在最前面和最后面各强调一次，中间放代码。这个"首尾强调"的技巧在实测中能明显降低模型跑偏的概率。
2.3 模型给出的重构方案拆解
Step 5 Preview 给出的方案，整体思路是对的。它先输出了一份重构计划，把 6 个文件重新划分成 3 个职责清晰的模块，然后逐个给出改动后的代码。
让我比较满意的是几点：
第一，它正确识别了循环引用。有两个文件互相 import，它没有简单地删掉其中一个 import 了事，而是指出这两个文件里的函数其实属于同一个职责，应该合并。这说明它确实理解了依赖关系，而不是在做表面文章。
第二，它保持了对外接口不变。我在任务说明里强调了"外部调用方不能改"，它在重构时把原来的接口函数保留为薄封装层，内部实现换掉。这个处理很专业，是真实重构里常用的手法。
第三，它主动标注了风险点。比如它指出某个函数被外部以反射方式调用，静态分析看不出来，建议我人工确认。这种"知道自己不知道什么"的表现，比闷头改完更让人放心。
2.4 实测中暴露的问题
当然不是完美的。实测下来有几个问题需要说。
问题一：对隐式依赖的处理不够稳。项目里有个配置是通过环境变量注入的，代码里没有显式引用，但运行时依赖。模型在重构时把这个配置的读取逻辑挪了位置，导致加载时机变了。这个错误很隐蔽，静态看代码看不出来，得跑起来才发现。
问题二：注释和文档的更新滞后。它改了代码逻辑，但有些函数的 docstring 没同步更新，还是旧的描述。这个在大型重构里是常见问题，但作为助手应该做得更好。
问题三：对超长文件的处理有截断迹象。我有个文件接近 800 行，模型在重构这个文件时，中间部分有几处改动明显不如其他部分细致，像是注意力衰减了。这提示我：即使标称 1M 上下文，实际有效理解长度也是有限的，关键文件最好还是拆小一点喂。
2.5 长上下文能力的真实边界
这次实测让我对"1M Token 上下文"有了更清醒的认识。
标称 1M 意味着物理上能装下，但"能装下"和"能同等质量地理解"是两回事。实测中，当上下文在几万 Token 以内时，模型的表现很稳定；到了十几万 Token，开始出现注意力分配不均的迹象；再往上，边缘信息的处理质量会下降。
所以我的结论是：1M 上下文的价值在于"不用频繁切分"，而不是"可以无脑塞"。它让你能把一个中等规模的项目整体放进去，避免来回切换文件丢失上下文，这是实打实的提升。但如果你指望把整个代码库塞进去让它通盘理解，那还是想多了。
实际使用建议是：把 1M 当成"舒适区很大"来用，而不是"无限大"来用。关键任务控制在几万 Token 的上下文内，质量最有保障。
3. 任务二：视觉输入还原界面的实测
3.1 从截图到代码的完整流程
第二个任务更贴近日常。我拿到一张后台管理页面的设计稿截图，需要把它变成可运行的 HTML + CSS。这种任务在真实工作里非常常见——设计师给图，前端还原。
我的操作流程是：把截图作为视觉输入传给模型，附上一段说明，讲清楚技术栈要求（比如用 Flexbox 还是 Grid、要不要响应式、用什么 CSS 方案），然后让它输出代码。
这里有个关键点：视觉输入任务里，文字说明的作用被很多人低估了。光给一张图，模型只能猜你的技术偏好；加上明确的约束说明，输出质量会高一个档次。我通常会说明：布局方案、命名规范、是否需要兼容旧浏览器、颜色是用变量还是硬编码。
3.2 布局识别的准确度
先说结论：布局结构的识别相当准。
模型正确识别出了页面的整体框架：顶部导航栏、左侧菜单、右侧内容区、内容区里的卡片网格。它甚至判断出了左侧菜单是固定宽度、右侧内容区自适应，这个判断从截图里其实不太容易看出来，说明它对常见后台布局模式有先验知识。
间距的处理也让我意外。设计稿里卡片之间的间距，它给出的值和我用取色器量出来的很接近。这说明它不是随便填个数，而是真的在"看"图。
但也不是全对。有个地方它把两个视觉上相邻但逻辑上独立的区域合并成了一个容器，导致后续的样式作用域出了问题。这个错误的原因是：视觉上的相邻不等于结构上的同级，模型在这方面的判断还不够细。
3.3 视觉理解踩到的坑
实测下来，视觉输入有几个坑必须提前知道。
坑一：颜色识别的精度问题。截图经过压缩后，颜色会有偏差。模型识别出的颜色和设计稿原始色值可能有几个色阶的差异。我的做法是：让模型给出它识别的色值，然后我自己对照设计规范修正。不要指望模型直接给出精确的品牌色值，这个环节人工介入更靠谱。
坑二：文字内容的识别。截图里的文字，模型能读出来，但遇到小字号或者特殊字体时会有误读。如果页面里有重要的文案，建议在说明里直接给出文字内容，不要让模型去"认"。
坑三：交互状态的缺失。截图是静态的，但真实页面有 hover、focus、disabled 等各种状态。模型默认只会还原静态样式，交互状态需要你在说明里明确要求。我一般会列一个状态清单，让它一并处理。
注意：视觉输入任务里，把截图当成"布局参考"而不是"像素级还原目标"。像素级还原需要设计稿源文件，截图做不到，模型也做不到。
3.4 视觉输入适合什么、不适合什么
经过这次实测，我对视觉输入能力的适用边界有了判断。
适合的场景：快速搭建页面骨架、还原常见布局模式、从草图生成初版代码、把设计稿转成可讨论的原型。这些场景下，视觉输入能大幅提升效率，省去大量手写样板代码的时间。
不适合的场景：像素级精确还原、复杂交互动效、需要严格遵循设计系统的场景。这些场景下，视觉输入的输出只能作为起点，后续必须人工精修。
一句话总结：视觉输入是"加速器"，不是"替代品"。它帮你跳过从零到一的阶段，但从一到十的打磨还是得自己来。
4. MoE 与 1M 上下文组合起来的实际体验
4.1 响应速度的主观感受
把 MoE 和 1M 上下文放在一起用，最直观的感受是快。
我做过对比：同样一个几万 Token 的重构任务，用传统稠密模型跑，等待时间明显更长；Step 5 Preview 的响应速度要快不少。这个差异在交互式使用中很关键——你等 30 秒和等 10 秒，工作节奏完全不一样。等待时间短，你就更愿意多轮迭代，而多轮迭代恰恰是让输出质量提升的关键。
MoE 带来的这个速度优势，本质上是把"计算量"这个瓶颈缓解了。前面说过，MoE 不省显存但省计算，而计算量直接决定响应时间。所以对通过 API 使用的场景，MoE 的收益是实打实的。
4.2 长上下文下的稳定性观察
1M 上下文在长任务里的稳定性，我观察到一个有意思的现象：上下文越长，模型越倾向于"保守"。
具体表现是：当上下文很短时，模型敢于做较大的改动；当上下文很长时，它更倾向于小步修改，甚至有些该改的地方它选择不动。这个行为可以理解为一种"风险规避"——上下文里的信息越多，它越担心改动会破坏某些它没完全理解的部分。
这个特性有好有坏。好处是不容易闯大祸，长上下文任务里最怕的就是模型大刀阔斧改一通结果全崩；坏处是有时候不够果断，该重构的地方它绕着走。
我的应对方法是：在任务说明里明确授权范围。比如告诉它"这几个文件可以自由重构，那几个文件只允许改接口"，给它清晰的边界，它反而更敢在授权范围内动手。
4.3 成本与效率的权衡
最后说说成本。MoE 架构在成本上的优势，对高频使用的人来说是决定性的。
我算过一笔账：如果每天有几十次代码辅助请求，稠密模型和 MoE 模型的成本差异会累积成可观的数字。而且 MoE 的快，意味着同样时间内你能完成更多轮迭代，这本身就是效率提升。
但要注意，成本优势不等于可以滥用。长上下文任务里，塞进去的 Token 越多，成本越高。所以"1M 上下文"和"省成本"之间是有张力的：你能塞很多，但塞得多就贵。理性的做法是按需组织上下文，该给的给全，不该给的别硬塞。
5. 两个任务跑完后我的选型判断
5.1 什么场景下我会优先用它
跑完这两个任务，我心里对 Step 5 Preview 的定位清晰了。
优先使用的场景：中等规模的重构任务、需要同时理解多个文件的任务、从设计稿快速生成页面骨架、需要快速多轮迭代的探索性任务。这些场景下，它的长上下文和速度优势能充分发挥。
谨慎使用的场景：涉及隐式依赖和运行时行为的改动、需要像素级精确的还原、对文档同步要求高的任务。这些场景下，它的输出需要更仔细的人工审查。
5.2 和其他编程助手的差异
市面上编程助手不少，各有侧重。我的观察是，Step 5 Preview 的差异化在于长上下文和视觉输入的组合。
很多助手在单文件、短上下文场景下表现都很好，但一旦任务跨多个文件、需要全局视角，差距就出来了。Step 5 Preview 在这方面的表现，加上视觉输入能力，让它在"从设计到代码"这类端到端任务上有独特价值。
当然，工具没有绝对的好坏，关键是匹配你的工作流。如果你的任务大多是单文件小改动，那长上下文的优势体现不出来；如果你经常处理跨文件重构或者设计稿还原，那它的价值就很明显。
5.3 给准备上手的人几条实操建议
最后给几条我踩过坑之后总结的建议。
第一，上下文要组织，不要堆砌。给它一张地图，比给它一堆散装代码有用得多。任务目标、约束条件、文件依赖关系，这些"元信息"要主动提供。
第二，关键文件拆小。即使支持 1M，单个文件也别太大。实测中超过几百行的文件，处理质量会下降。该拆的拆，对模型对你都好。
第三，视觉任务要配文字说明。光给图不够，技术栈、命名规范、交互状态这些都要说清楚。视觉输入是辅助，文字说明才是主导。
第四，永远保留人工审查环节。尤其是隐式依赖、运行时行为、文档同步这几块，模型的输出必须过一遍人眼。它是个很强的助手，但不是可以完全放手的自动驾驶。
第五，善用多轮迭代。它响应快，你就多问几轮。第一版不满意，指出问题让它改，往往第二版、第三版质量会明显提升。别指望一次成型，把多轮对话当成正常工作方式。
这套用法我跑下来，整体是满意的。它没有解决所有问题，但在它擅长的场景里，确实能省下大量时间。工具的价值不在于全能，而在于你在对的场景用对它。
