跑分榜单看多了人会麻木。一个模型在 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单个文件也别太大。实测中超过几百行的文件处理质量会下降。该拆的拆对模型对你都好。第三视觉任务要配文字说明。光给图不够技术栈、命名规范、交互状态这些都要说清楚。视觉输入是辅助文字说明才是主导。第四永远保留人工审查环节。尤其是隐式依赖、运行时行为、文档同步这几块模型的输出必须过一遍人眼。它是个很强的助手但不是可以完全放手的自动驾驶。第五善用多轮迭代。它响应快你就多问几轮。第一版不满意指出问题让它改往往第二版、第三版质量会明显提升。别指望一次成型把多轮对话当成正常工作方式。这套用法我跑下来整体是满意的。它没有解决所有问题但在它擅长的场景里确实能省下大量时间。工具的价值不在于全能而在于你在对的场景用对它。 
长河君 · 2026/11/3 8:39:39 · 阅读 1.2k Step 5 Preview 实测：MoE 架构与 1M 上下文如何搞定真实编程任务
跑分榜单看多了人会麻木。一个模型在 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单个文件也别太大。实测中超过几百行的文件处理质量会下降。该拆的拆对模型对你都好。第三视觉任务要配文字说明。光给图不够技术栈、命名规范、交互状态这些都要说清楚。视觉输入是辅助文字说明才是主导。第四永远保留人工审查环节。尤其是隐式依赖、运行时行为、文档同步这几块模型的输出必须过一遍人眼。它是个很强的助手但不是可以完全放手的自动驾驶。第五善用多轮迭代。它响应快你就多问几轮。第一版不满意指出问题让它改往往第二版、第三版质量会明显提升。别指望一次成型把多轮对话当成正常工作方式。这套用法我跑下来整体是满意的。它没有解决所有问题但在它擅长的场景里确实能省下大量时间。工具的价值不在于全能而在于你在对的场景用对它。