跑分榜单看多了会有一个副作用你对模型的真实能力判断会越来越钝。MMLU、HumanEval、SWE-bench 这些数字当然有参考价值但它们衡量的场景和你日常写代码的场景之间隔着一层很厚的滤镜。榜单上的题目是精心挑选的、边界清晰的、有标准答案的而你手头的任务是模糊的、上下文散落在五个文件里的、需求本身可能还在变的。Step 5 Preview 发布之后各种跑分数据铺天盖地但我更关心的是把它扔进两个真实的编程任务里它到底能不能干活。这篇文章记录的就是这两次实测的完整过程——不是跑 demo不是写个 Fibonacci 函数而是两个有实际工程意义的任务。一个偏前端交互逻辑一个偏后端数据处理。我会把任务设计、提示词、中间过程、踩到的坑、以及最终结论全部摊开来讲。如果你正在纠结要不要把 Step 5 Preview 纳入日常工具链或者你只是好奇一个主打 MoE 架构和 1M Token 上下文的模型在真实场景里表现如何这篇实测应该能给你一些跑分之外的参考。1. 为什么我选择用真实任务而不是跑分来评估1.1 跑分高不等于能干活这个差距比你想的大先说一个我反复验证过的观察一个模型在 HumanEval 上能拿 90 分不代表它能帮你改一个真实项目里的 bug。原因很简单——HumanEval 的题目是请实现一个函数输入是 X输出是 Y函数签名给你了边界条件暗示了甚至测试用例都写好了。但真实任务是什么样是这个页面在移动端滚动的时候偶尔会闪一下你帮我看看然后你得自己去定位问题在哪个组件、哪个生命周期、哪个 CSS 属性上。这中间的差距本质上是问题定义能力和上下文理解能力的差距。跑分考的是给定明确问题你能不能写出正确代码而真实任务考的是你能不能从模糊描述中提取出明确问题再写出正确代码。后者难得多。Step 5 Preview 的几个关键词里我特别关注两个MoE 架构和1M Token 上下文。MoE 意味着它在推理时只激活部分参数理论上在保持能力的同时有更高的效率1M Token 上下文意味着它可以一次性吞下整个中型项目的代码库。这两个特性如果真能在实际任务中兑现那价值比跑分高几分要大得多。1.2 我设计的两个任务分别考什么我刻意选了两种不同性质的任务避免只测一个维度任务一前端交互组件开发。具体来说是做一个带搜索过滤、多选、键盘导航的下拉选择器组件。这个任务考的是对交互细节的理解、对边界情况的覆盖、对无障碍访问的处理、以及代码组织是否合理。它没有标准答案但有很多明显不对的做法。任务二后端数据清洗管道。给定一份格式混乱的 CSV 数据包含缺失值、编码问题、日期格式不统一、重复记录要求写一个可复用的清洗脚本并输出清洗报告。这个任务考的是对数据异常的处理策略、代码的健壮性、以及是否能主动发现需求描述里没提到的潜在问题。两个任务都不算特别复杂但都有足够的模糊地带来观察模型的判断力。我全程使用相同的提示词策略尽量模拟一个真实开发者的使用方式——不会把需求写得像考试题一样精确而是像跟同事交代任务一样自然。2. 任务一带键盘导航的多选下拉组件实测2.1 任务描述与初始提示词我给 Step 5 Preview 的提示词是这样的帮我写一个 React 的多选下拉选择器组件要求 1. 支持输入关键词过滤选项 2. 支持键盘上下键导航、Enter 选中、Esc 关闭 3. 已选中的项显示为标签可以单独删除 4. 点击外部区域关闭下拉 5. 用 TypeScript 写不要用任何第三方 UI 库这个提示词故意留了几个模糊点没说样式怎么处理、没说选项数据从哪来、没说无障碍访问要不要做、没说移动端怎么适配。我想看看它会不会主动问还是会自己做一些合理假设。结果它没有追问直接开始写代码。这一点我不意外——大多数模型都会选择直接输出而不是反问。但关键在于它做的假设是否合理。2.2 它主动处理了哪些我没提的细节拿到代码后我逐段读了一遍发现它主动处理了几个我没在提示词里提到的点第一ARIA 属性。它给输入框加了rolecombobox、aria-expanded、aria-activedescendant给下拉列表加了rolelistbox给每个选项加了roleoption和aria-selected。这些是无障碍访问的标准做法我提示词里完全没提。这说明它在训练数据里见过足够多的真实组件代码知道一个合格的下拉组件应该包含什么。第二键盘导航的边界处理。上下键在列表首尾时的行为它做了循环处理——按上键在第一个选项时跳到最后一个按下键在最后一个选项时跳到第一个。这个行为不是唯一的正确做法有些组件选择在边界处停住但它是一个合理的选择而且它没有在代码里留 TODO。第三输入过滤的防抖。它给过滤逻辑加了一个简单的防抖处理。虽然对于本地数组过滤来说防抖不是必须的但考虑到真实场景中选项可能来自远程搜索这个预判是合理的。第四点击外部的处理。它用了mousedown而不是click来监听外部点击。这个细节很关键——如果用click当用户点击下拉选项时mousedown先触发导致下拉关闭然后click事件就落不到选项上了。用mousedown配合contains判断可以避免这个经典问题。这个细节能说明它对实际交互中的事件时序有理解。2.3 代码质量与结构分析整体代码大约 180 行结构上分成了几个部分类型定义、主组件、样式对象内联样式、以及一个小的工具函数。没有过度拆分也没有把所有逻辑堆在一个函数里。我特别注意到它在状态管理上的选择。它用了三个useState一个存输入值一个存是否展开一个存高亮索引。已选中的项则是通过 props 传入和回调传出的受控模式。这个设计是合理的——受控组件在 React 生态里更灵活也更容易测试。但它有一个小问题高亮索引在过滤后的列表变化时没有重置。比如你输入关键词过滤后高亮索引可能指向一个不存在的位置。这是一个真实的 bug我在实测中触发了。具体场景是列表有 10 项你用下键移动到第 8 项然后输入一个关键词把列表过滤到只剩 3 项此时高亮索引还是 7但列表只有 3 项导致高亮消失且键盘导航行为异常。这个问题不是致命的但它暴露了一个模式模型在处理多个状态之间的联动时容易漏掉某些状态同步。这不是 Step 5 Preview 独有的问题但值得注意。2.4 实测中发现的三个问题及修复过程除了上面说的高亮索引问题我还发现了两个问题问题二标签删除后的焦点管理。当你用键盘删除一个已选标签后焦点会丢失用户需要重新点击输入框才能继续操作。正确的做法是删除后把焦点还给输入框。这个问题在纯鼠标操作下不明显但键盘用户会立刻感受到。问题三中文输入法兼容。在中文输入法下输入拼音时onChange会频繁触发过滤导致下拉列表在拼音未上屏时就闪烁变化。正确的做法是监听compositionstart和compositionend事件在组合输入期间不触发过滤。我把这三个问题反馈给 Step 5 Preview让它修复。它的修复方案高亮索引问题在过滤逻辑中用useEffect监听过滤结果变化重置高亮索引到 0。焦点管理在删除标签的回调中加inputRef.current?.focus()。输入法兼容加了isComposing状态在compositionstart时设为 truecompositionend时设为 false过滤逻辑中判断该状态。三个修复都一次到位没有引入新问题。这说明它的迭代修复能力是可靠的——你指出问题它能理解问题并给出正确修复而不是胡乱改一通。3. 任务二混乱 CSV 数据清洗管道实测3.1 数据集的脏程度设计第二个任务我准备了一份刻意做脏的 CSV 数据大约 2000 行包含以下问题问题类型具体表现出现频率缺失值某些列为空字符串或 N/A约 15% 的行日期格式混乱混用2024-01-15、01/15/2024、15-Jan-2024约 40% 的行编码问题部分中文出现乱码约 5% 的行重复记录完全相同的行重复出现约 8% 的行数值列含单位如 1,234.56 元、$789.00约 30% 的行前后空格字符串列首尾有空格约 25% 的行我给它的提示词是我有一个 CSV 文件 data.csv格式比较乱帮我写一个 Python 脚本清洗它 输出一个干净的 CSV 和一个清洗报告。具体要求你看着办尽量健壮一点。注意我故意说了具体要求你看着办——这是为了测试它的主动性和判断力。3.2 它自己推断出的清洗策略Step 5 Preview 拿到任务后先输出了一段分析列出了它认为需要处理的几个维度缺失值、日期格式、数值格式、重复行、字符串规范化。然后它写了一个脚本核心策略如下缺失值处理它没有直接删除含缺失值的行也没有统一填充一个固定值而是分列处理——数值列用中位数填充字符串列用空字符串填充并在报告中记录每列的缺失数量。这个策略是合理的因为不同列的最佳填充方式不同。日期解析它用了一个多格式尝试的策略依次尝试几种常见格式解析成功就返回标准化的YYYY-MM-DD格式。解析失败的记录会被标记而不是丢弃。这个做法比我预期的要好——很多模型会直接pd.to_datetime然后让解析失败的变成 NaT 就不管了。数值清洗它写了一个正则来提取数值部分去掉货币符号、千分位逗号、单位文字。这个逻辑覆盖了我数据集里的所有数值格式。重复检测它用了全列比较来检测完全重复的行保留第一条。但它额外做了一个我认为很聪明的处理——在报告中输出了疑似重复的记录即除了某一列不同之外其他列都相同的行。这个是我没要求的但它主动做了。编码处理它用chardet检测编码然后用检测到的编码读取。对于已经乱码的字符它没有尝试修复因为不可逆而是在报告中标记出来。3.3 清洗报告的设计与实用性它生成的清洗报告是一个 Markdown 文件包含以下部分原始数据概览行数、列数、各列数据类型各列缺失值统计数量 百分比日期解析结果成功数、失败数、失败样例数值清洗结果成功数、失败数、失败样例重复行统计完全重复 疑似重复编码问题记录清洗后数据概览这个报告的结构是实用的。特别是失败样例这一项——它不只告诉你有多少条失败还给你看具体哪些记录失败了方便你判断是数据问题还是脚本问题。3.4 一个它没考虑到的问题时区与夏令时在日期处理上它有一个盲区没有考虑时区。我的数据集里其实混了一些带时区信息的日期比如2024-01-15T10:30:0008:00它的多格式尝试策略没有覆盖 ISO 8601 带时区的格式导致这些记录被标记为解析失败。这个问题不算严重因为它在报告中标记了失败记录你一眼就能看到。但如果它能主动考虑到时区问题那就更完善了。这也说明一个点模型在处理日期时默认假设是简单日期对时区、夏令时、闰秒这些边缘情况缺乏主动意识。我后来让它补充时区处理它加了dateutil.parser作为兜底解析器并统一转换为 UTC 存储。修复是到位的。4. MoE 架构和 1M 上下文在实测中的真实体感4.1 MoE 架构带来的响应速度差异Step 5 Preview 采用 MoE混合专家架构这意味着它在推理时不会激活全部参数而是根据输入内容路由到相关的专家子网络。这个架构带来的最直接体感是响应速度。在我这两个任务中第一个任务前端组件的首次响应大约在 3-5 秒内开始输出完整代码输出大约 15 秒。第二个任务数据清洗脚本因为涉及更多逻辑分支首次响应稍慢大约 5-8 秒完整输出约 25 秒。这个速度在同类模型中属于中上水平。但 MoE 架构有一个需要留意的地方不同任务类型之间的表现可能有波动。因为路由机制决定了哪些专家被激活如果任务恰好落在某个专家的擅长区表现会很好如果任务比较偏门可能激活的专家组合不是最优的。我在两个任务中都感觉表现稳定但这需要更多样本来验证。4.2 1M Token 上下文在实际使用中的意义1M Token 上下文是一个很大的数字。换算一下大约相当于 70-80 万英文单词或者 50-60 万中文字符。对于代码来说大约可以容纳一个中型项目的全部源码。但在实际使用中上下文长度和上下文利用率是两回事。我把一个约 3000 行的项目代码库约 15 万 Token一次性喂给它让它在这个上下文中完成一个修改任务。它确实能看到所有代码但在定位相关文件时它的表现并不是完美的——它会优先关注与任务关键词直接匹配的文件对于一些间接相关的文件比如工具函数、类型定义有时会遗漏。这不是 Step 5 Preview 独有的问题而是所有长上下文模型面临的共同挑战注意力在超长上下文中的分配是不均匀的。一个实用的技巧是即使模型支持 1M 上下文也不要真的把所有东西都塞进去。把最相关的文件放在上下文的开头和结尾这两个位置的注意力权重通常更高把次要文件放在中间效果会更好。4.3 视觉输入能力在编程场景的潜在用法Step 5 Preview 支持视觉输入这意味着你可以给它截图。在编程场景中这个能力有几个实用方向UI 还原给一张设计稿截图让它生成对应的组件代码。我试了一个简单的卡片布局它生成的代码在结构上是合理的但间距和颜色需要微调。报错截图给一张控制台报错截图让它分析原因。这个场景它表现不错能准确识别错误类型和关键信息。流程图转代码给一张流程图截图让它生成对应的逻辑代码。这个场景比较复杂它生成的代码框架是对的但细节需要大量补充。视觉输入目前还是一个锦上添花的能力不适合作为主要工作流。但在某些特定场景下比如快速原型、报错分析它能省不少事。5. 两次实测后的选型建议与使用心得5.1 什么场景下我会优先选 Step 5 Preview经过这两个任务我对它的能力边界有了一个大致判断。以下场景我会优先考虑用它场景一从零写一个中等复杂度的组件或模块。它的代码组织能力和对边界情况的覆盖是不错的能给你一个 80 分的初版你在此基础上改比从零写要快。场景二代码审查和问题定位。把一段代码给它让它找问题它通常能找出几个你没想到的点。特别是交互逻辑和边界条件方面。场景三数据清洗和格式转换。这类任务有明确的输入输出它的表现很稳定而且会主动做一些你没要求的健壮性处理。场景四需要长上下文的任务。如果你需要模型理解一个较大的代码库1M 上下文确实有用但要注意上下文的组织方式。5.2 什么场景下我会犹豫场景一对精确性要求极高的任务。比如涉及金额计算、安全相关的代码它生成的代码需要仔细审查不能直接用。场景二需要深度领域知识的任务。比如特定的业务逻辑、行业规范它可能缺乏足够的上下文来做出正确判断。场景三需要多轮复杂交互的任务。虽然它的迭代修复能力不错但如果任务需要十几轮来回后期可能会出现上下文漂移。5.3 提示词层面的三个实用技巧基于这两次实测我总结了三个在使用 Step 5 Preview 时比较有效的提示词技巧技巧一给它一个角色和约束。比如你是一个有 5 年经验的前端工程师请用 React TypeScript 写一个组件不要用任何第三方库。角色设定能让它更好地对齐你的期望约束条件能减少它引入你不想要的东西。技巧二明确说出你没提到的也要考虑。比如请考虑无障碍访问、键盘导航、移动端适配这些方面。这句话能显著提升它主动处理边缘情况的概率。技巧三分阶段给任务。不要一次性把一个大任务全丢给它而是分成先写核心逻辑、再加边界处理、最后加测试几个阶段。这样每一阶段的输出质量更可控也更容易定位问题。5.4 一个容易被忽略的细节它的沉默假设在实测中我发现一个有意思的现象Step 5 Preview 在写代码时会做很多沉默假设——它不会告诉你它假设了什么但代码里体现了这些假设。比如在任务一中它假设了选项数据是一个{label: string, value: string}[]的数组在任务二中它假设了 CSV 文件有表头。这些假设大多数时候是合理的但偶尔会和你的实际情况不符。一个实用的做法是在拿到代码后先快速扫一遍它的类型定义和函数签名这些地方最能暴露它的假设。如果假设不对在下一轮对话中明确指出它会调整。这个细节看起来小但能帮你省很多来回调试的时间。我现在养成的习惯是拿到模型生成的代码后先看类型和接口再看核心逻辑最后看边界处理。这个顺序能最快地发现不匹配的地方。6. 关于跑分之外的评估方法论6.1 我如何设计一个有效的实测任务如果你也想自己做模型实测我的经验是任务要真实但要有明确的评估维度。完全开放的任务比如帮我写一个网站很难评估因为好坏标准太主观。但太具体的任务比如实现一个快排又回到了跑分模式。一个好的实测任务应该满足有明确的输入和期望输出、有多个合理的实现路径、有可以客观判断的对错点比如 bug、以及有可以主观评价的质量维度比如代码可读性。我这两个任务都满足这些条件。任务一的对错点是那三个 bug质量维度是代码组织和无障碍处理任务二的对错点是清洗逻辑是否正确质量维度是报告的实用性。6.2 评估时我关注的五个维度在这两次实测中我主要关注五个维度第一首次输出的可用度。它第一次给出的代码有多少比例是可以直接用的有多少需要改。任务一中大约 85% 可用任务二中大约 90% 可用。第二主动处理的边缘情况数量。它主动处理了多少我没提到的边缘情况。任务一中它主动处理了 4 个任务二中主动处理了 3 个。第三迭代修复的准确率。我指出问题后它一次修复成功的比例。这两个任务中它 6 次修复全部一次成功。第四代码的可读性和组织。命名是否清晰、结构是否合理、注释是否恰当。这方面它的表现是合格的没有出现明显的坏味道。第五对模糊需求的判断力。当需求不明确时它做的假设是否合理。这方面它的表现不错大部分假设是合理的少数不合理的也能通过一轮反馈纠正。6.3 跑分和实测的互补关系最后说一个观点跑分和实测不是对立的而是互补的。跑分帮你快速筛选出大概率能用的模型实测帮你确认在你的具体场景下是否真的好用。跑分是粗筛实测是精筛。我的建议是先用跑分缩小候选范围然后针对你的核心使用场景设计 2-3 个实测任务跑一遍。这个过程花不了多少时间但能帮你避免跑分很高但用起来别扭的尴尬。Step 5 Preview 在这两个任务中的表现让我愿意把它纳入日常工具链。它不是完美的——在状态联动、时区处理这些细节上还有提升空间——但它的整体判断力和代码质量是可靠的。特别是它在主动处理边缘情况方面的表现说明它不只是一个代码生成器而是一个有一定工程意识的助手。如果你也在用类似的工具我建议你不要只看它能不能写出正确代码还要看它能不能在你没说的地方也想到。后者才是真正拉开差距的地方。 
长河君 · 2026/11/3 17:42:40 · 阅读 1.2k Step 5 Preview 真实编程任务实测：MoE 架构与 1M 上下文能否替代跑分？
跑分榜单看多了会有一个副作用你对模型的真实能力判断会越来越钝。MMLU、HumanEval、SWE-bench 这些数字当然有参考价值但它们衡量的场景和你日常写代码的场景之间隔着一层很厚的滤镜。榜单上的题目是精心挑选的、边界清晰的、有标准答案的而你手头的任务是模糊的、上下文散落在五个文件里的、需求本身可能还在变的。Step 5 Preview 发布之后各种跑分数据铺天盖地但我更关心的是把它扔进两个真实的编程任务里它到底能不能干活。这篇文章记录的就是这两次实测的完整过程——不是跑 demo不是写个 Fibonacci 函数而是两个有实际工程意义的任务。一个偏前端交互逻辑一个偏后端数据处理。我会把任务设计、提示词、中间过程、踩到的坑、以及最终结论全部摊开来讲。如果你正在纠结要不要把 Step 5 Preview 纳入日常工具链或者你只是好奇一个主打 MoE 架构和 1M Token 上下文的模型在真实场景里表现如何这篇实测应该能给你一些跑分之外的参考。1. 为什么我选择用真实任务而不是跑分来评估1.1 跑分高不等于能干活这个差距比你想的大先说一个我反复验证过的观察一个模型在 HumanEval 上能拿 90 分不代表它能帮你改一个真实项目里的 bug。原因很简单——HumanEval 的题目是请实现一个函数输入是 X输出是 Y函数签名给你了边界条件暗示了甚至测试用例都写好了。但真实任务是什么样是这个页面在移动端滚动的时候偶尔会闪一下你帮我看看然后你得自己去定位问题在哪个组件、哪个生命周期、哪个 CSS 属性上。这中间的差距本质上是问题定义能力和上下文理解能力的差距。跑分考的是给定明确问题你能不能写出正确代码而真实任务考的是你能不能从模糊描述中提取出明确问题再写出正确代码。后者难得多。Step 5 Preview 的几个关键词里我特别关注两个MoE 架构和1M Token 上下文。MoE 意味着它在推理时只激活部分参数理论上在保持能力的同时有更高的效率1M Token 上下文意味着它可以一次性吞下整个中型项目的代码库。这两个特性如果真能在实际任务中兑现那价值比跑分高几分要大得多。1.2 我设计的两个任务分别考什么我刻意选了两种不同性质的任务避免只测一个维度任务一前端交互组件开发。具体来说是做一个带搜索过滤、多选、键盘导航的下拉选择器组件。这个任务考的是对交互细节的理解、对边界情况的覆盖、对无障碍访问的处理、以及代码组织是否合理。它没有标准答案但有很多明显不对的做法。任务二后端数据清洗管道。给定一份格式混乱的 CSV 数据包含缺失值、编码问题、日期格式不统一、重复记录要求写一个可复用的清洗脚本并输出清洗报告。这个任务考的是对数据异常的处理策略、代码的健壮性、以及是否能主动发现需求描述里没提到的潜在问题。两个任务都不算特别复杂但都有足够的模糊地带来观察模型的判断力。我全程使用相同的提示词策略尽量模拟一个真实开发者的使用方式——不会把需求写得像考试题一样精确而是像跟同事交代任务一样自然。2. 任务一带键盘导航的多选下拉组件实测2.1 任务描述与初始提示词我给 Step 5 Preview 的提示词是这样的帮我写一个 React 的多选下拉选择器组件要求 1. 支持输入关键词过滤选项 2. 支持键盘上下键导航、Enter 选中、Esc 关闭 3. 已选中的项显示为标签可以单独删除 4. 点击外部区域关闭下拉 5. 用 TypeScript 写不要用任何第三方 UI 库这个提示词故意留了几个模糊点没说样式怎么处理、没说选项数据从哪来、没说无障碍访问要不要做、没说移动端怎么适配。我想看看它会不会主动问还是会自己做一些合理假设。结果它没有追问直接开始写代码。这一点我不意外——大多数模型都会选择直接输出而不是反问。但关键在于它做的假设是否合理。2.2 它主动处理了哪些我没提的细节拿到代码后我逐段读了一遍发现它主动处理了几个我没在提示词里提到的点第一ARIA 属性。它给输入框加了rolecombobox、aria-expanded、aria-activedescendant给下拉列表加了rolelistbox给每个选项加了roleoption和aria-selected。这些是无障碍访问的标准做法我提示词里完全没提。这说明它在训练数据里见过足够多的真实组件代码知道一个合格的下拉组件应该包含什么。第二键盘导航的边界处理。上下键在列表首尾时的行为它做了循环处理——按上键在第一个选项时跳到最后一个按下键在最后一个选项时跳到第一个。这个行为不是唯一的正确做法有些组件选择在边界处停住但它是一个合理的选择而且它没有在代码里留 TODO。第三输入过滤的防抖。它给过滤逻辑加了一个简单的防抖处理。虽然对于本地数组过滤来说防抖不是必须的但考虑到真实场景中选项可能来自远程搜索这个预判是合理的。第四点击外部的处理。它用了mousedown而不是click来监听外部点击。这个细节很关键——如果用click当用户点击下拉选项时mousedown先触发导致下拉关闭然后click事件就落不到选项上了。用mousedown配合contains判断可以避免这个经典问题。这个细节能说明它对实际交互中的事件时序有理解。2.3 代码质量与结构分析整体代码大约 180 行结构上分成了几个部分类型定义、主组件、样式对象内联样式、以及一个小的工具函数。没有过度拆分也没有把所有逻辑堆在一个函数里。我特别注意到它在状态管理上的选择。它用了三个useState一个存输入值一个存是否展开一个存高亮索引。已选中的项则是通过 props 传入和回调传出的受控模式。这个设计是合理的——受控组件在 React 生态里更灵活也更容易测试。但它有一个小问题高亮索引在过滤后的列表变化时没有重置。比如你输入关键词过滤后高亮索引可能指向一个不存在的位置。这是一个真实的 bug我在实测中触发了。具体场景是列表有 10 项你用下键移动到第 8 项然后输入一个关键词把列表过滤到只剩 3 项此时高亮索引还是 7但列表只有 3 项导致高亮消失且键盘导航行为异常。这个问题不是致命的但它暴露了一个模式模型在处理多个状态之间的联动时容易漏掉某些状态同步。这不是 Step 5 Preview 独有的问题但值得注意。2.4 实测中发现的三个问题及修复过程除了上面说的高亮索引问题我还发现了两个问题问题二标签删除后的焦点管理。当你用键盘删除一个已选标签后焦点会丢失用户需要重新点击输入框才能继续操作。正确的做法是删除后把焦点还给输入框。这个问题在纯鼠标操作下不明显但键盘用户会立刻感受到。问题三中文输入法兼容。在中文输入法下输入拼音时onChange会频繁触发过滤导致下拉列表在拼音未上屏时就闪烁变化。正确的做法是监听compositionstart和compositionend事件在组合输入期间不触发过滤。我把这三个问题反馈给 Step 5 Preview让它修复。它的修复方案高亮索引问题在过滤逻辑中用useEffect监听过滤结果变化重置高亮索引到 0。焦点管理在删除标签的回调中加inputRef.current?.focus()。输入法兼容加了isComposing状态在compositionstart时设为 truecompositionend时设为 false过滤逻辑中判断该状态。三个修复都一次到位没有引入新问题。这说明它的迭代修复能力是可靠的——你指出问题它能理解问题并给出正确修复而不是胡乱改一通。3. 任务二混乱 CSV 数据清洗管道实测3.1 数据集的脏程度设计第二个任务我准备了一份刻意做脏的 CSV 数据大约 2000 行包含以下问题问题类型具体表现出现频率缺失值某些列为空字符串或 N/A约 15% 的行日期格式混乱混用2024-01-15、01/15/2024、15-Jan-2024约 40% 的行编码问题部分中文出现乱码约 5% 的行重复记录完全相同的行重复出现约 8% 的行数值列含单位如 1,234.56 元、$789.00约 30% 的行前后空格字符串列首尾有空格约 25% 的行我给它的提示词是我有一个 CSV 文件 data.csv格式比较乱帮我写一个 Python 脚本清洗它 输出一个干净的 CSV 和一个清洗报告。具体要求你看着办尽量健壮一点。注意我故意说了具体要求你看着办——这是为了测试它的主动性和判断力。3.2 它自己推断出的清洗策略Step 5 Preview 拿到任务后先输出了一段分析列出了它认为需要处理的几个维度缺失值、日期格式、数值格式、重复行、字符串规范化。然后它写了一个脚本核心策略如下缺失值处理它没有直接删除含缺失值的行也没有统一填充一个固定值而是分列处理——数值列用中位数填充字符串列用空字符串填充并在报告中记录每列的缺失数量。这个策略是合理的因为不同列的最佳填充方式不同。日期解析它用了一个多格式尝试的策略依次尝试几种常见格式解析成功就返回标准化的YYYY-MM-DD格式。解析失败的记录会被标记而不是丢弃。这个做法比我预期的要好——很多模型会直接pd.to_datetime然后让解析失败的变成 NaT 就不管了。数值清洗它写了一个正则来提取数值部分去掉货币符号、千分位逗号、单位文字。这个逻辑覆盖了我数据集里的所有数值格式。重复检测它用了全列比较来检测完全重复的行保留第一条。但它额外做了一个我认为很聪明的处理——在报告中输出了疑似重复的记录即除了某一列不同之外其他列都相同的行。这个是我没要求的但它主动做了。编码处理它用chardet检测编码然后用检测到的编码读取。对于已经乱码的字符它没有尝试修复因为不可逆而是在报告中标记出来。3.3 清洗报告的设计与实用性它生成的清洗报告是一个 Markdown 文件包含以下部分原始数据概览行数、列数、各列数据类型各列缺失值统计数量 百分比日期解析结果成功数、失败数、失败样例数值清洗结果成功数、失败数、失败样例重复行统计完全重复 疑似重复编码问题记录清洗后数据概览这个报告的结构是实用的。特别是失败样例这一项——它不只告诉你有多少条失败还给你看具体哪些记录失败了方便你判断是数据问题还是脚本问题。3.4 一个它没考虑到的问题时区与夏令时在日期处理上它有一个盲区没有考虑时区。我的数据集里其实混了一些带时区信息的日期比如2024-01-15T10:30:0008:00它的多格式尝试策略没有覆盖 ISO 8601 带时区的格式导致这些记录被标记为解析失败。这个问题不算严重因为它在报告中标记了失败记录你一眼就能看到。但如果它能主动考虑到时区问题那就更完善了。这也说明一个点模型在处理日期时默认假设是简单日期对时区、夏令时、闰秒这些边缘情况缺乏主动意识。我后来让它补充时区处理它加了dateutil.parser作为兜底解析器并统一转换为 UTC 存储。修复是到位的。4. MoE 架构和 1M 上下文在实测中的真实体感4.1 MoE 架构带来的响应速度差异Step 5 Preview 采用 MoE混合专家架构这意味着它在推理时不会激活全部参数而是根据输入内容路由到相关的专家子网络。这个架构带来的最直接体感是响应速度。在我这两个任务中第一个任务前端组件的首次响应大约在 3-5 秒内开始输出完整代码输出大约 15 秒。第二个任务数据清洗脚本因为涉及更多逻辑分支首次响应稍慢大约 5-8 秒完整输出约 25 秒。这个速度在同类模型中属于中上水平。但 MoE 架构有一个需要留意的地方不同任务类型之间的表现可能有波动。因为路由机制决定了哪些专家被激活如果任务恰好落在某个专家的擅长区表现会很好如果任务比较偏门可能激活的专家组合不是最优的。我在两个任务中都感觉表现稳定但这需要更多样本来验证。4.2 1M Token 上下文在实际使用中的意义1M Token 上下文是一个很大的数字。换算一下大约相当于 70-80 万英文单词或者 50-60 万中文字符。对于代码来说大约可以容纳一个中型项目的全部源码。但在实际使用中上下文长度和上下文利用率是两回事。我把一个约 3000 行的项目代码库约 15 万 Token一次性喂给它让它在这个上下文中完成一个修改任务。它确实能看到所有代码但在定位相关文件时它的表现并不是完美的——它会优先关注与任务关键词直接匹配的文件对于一些间接相关的文件比如工具函数、类型定义有时会遗漏。这不是 Step 5 Preview 独有的问题而是所有长上下文模型面临的共同挑战注意力在超长上下文中的分配是不均匀的。一个实用的技巧是即使模型支持 1M 上下文也不要真的把所有东西都塞进去。把最相关的文件放在上下文的开头和结尾这两个位置的注意力权重通常更高把次要文件放在中间效果会更好。4.3 视觉输入能力在编程场景的潜在用法Step 5 Preview 支持视觉输入这意味着你可以给它截图。在编程场景中这个能力有几个实用方向UI 还原给一张设计稿截图让它生成对应的组件代码。我试了一个简单的卡片布局它生成的代码在结构上是合理的但间距和颜色需要微调。报错截图给一张控制台报错截图让它分析原因。这个场景它表现不错能准确识别错误类型和关键信息。流程图转代码给一张流程图截图让它生成对应的逻辑代码。这个场景比较复杂它生成的代码框架是对的但细节需要大量补充。视觉输入目前还是一个锦上添花的能力不适合作为主要工作流。但在某些特定场景下比如快速原型、报错分析它能省不少事。5. 两次实测后的选型建议与使用心得5.1 什么场景下我会优先选 Step 5 Preview经过这两个任务我对它的能力边界有了一个大致判断。以下场景我会优先考虑用它场景一从零写一个中等复杂度的组件或模块。它的代码组织能力和对边界情况的覆盖是不错的能给你一个 80 分的初版你在此基础上改比从零写要快。场景二代码审查和问题定位。把一段代码给它让它找问题它通常能找出几个你没想到的点。特别是交互逻辑和边界条件方面。场景三数据清洗和格式转换。这类任务有明确的输入输出它的表现很稳定而且会主动做一些你没要求的健壮性处理。场景四需要长上下文的任务。如果你需要模型理解一个较大的代码库1M 上下文确实有用但要注意上下文的组织方式。5.2 什么场景下我会犹豫场景一对精确性要求极高的任务。比如涉及金额计算、安全相关的代码它生成的代码需要仔细审查不能直接用。场景二需要深度领域知识的任务。比如特定的业务逻辑、行业规范它可能缺乏足够的上下文来做出正确判断。场景三需要多轮复杂交互的任务。虽然它的迭代修复能力不错但如果任务需要十几轮来回后期可能会出现上下文漂移。5.3 提示词层面的三个实用技巧基于这两次实测我总结了三个在使用 Step 5 Preview 时比较有效的提示词技巧技巧一给它一个角色和约束。比如你是一个有 5 年经验的前端工程师请用 React TypeScript 写一个组件不要用任何第三方库。角色设定能让它更好地对齐你的期望约束条件能减少它引入你不想要的东西。技巧二明确说出你没提到的也要考虑。比如请考虑无障碍访问、键盘导航、移动端适配这些方面。这句话能显著提升它主动处理边缘情况的概率。技巧三分阶段给任务。不要一次性把一个大任务全丢给它而是分成先写核心逻辑、再加边界处理、最后加测试几个阶段。这样每一阶段的输出质量更可控也更容易定位问题。5.4 一个容易被忽略的细节它的沉默假设在实测中我发现一个有意思的现象Step 5 Preview 在写代码时会做很多沉默假设——它不会告诉你它假设了什么但代码里体现了这些假设。比如在任务一中它假设了选项数据是一个{label: string, value: string}[]的数组在任务二中它假设了 CSV 文件有表头。这些假设大多数时候是合理的但偶尔会和你的实际情况不符。一个实用的做法是在拿到代码后先快速扫一遍它的类型定义和函数签名这些地方最能暴露它的假设。如果假设不对在下一轮对话中明确指出它会调整。这个细节看起来小但能帮你省很多来回调试的时间。我现在养成的习惯是拿到模型生成的代码后先看类型和接口再看核心逻辑最后看边界处理。这个顺序能最快地发现不匹配的地方。6. 关于跑分之外的评估方法论6.1 我如何设计一个有效的实测任务如果你也想自己做模型实测我的经验是任务要真实但要有明确的评估维度。完全开放的任务比如帮我写一个网站很难评估因为好坏标准太主观。但太具体的任务比如实现一个快排又回到了跑分模式。一个好的实测任务应该满足有明确的输入和期望输出、有多个合理的实现路径、有可以客观判断的对错点比如 bug、以及有可以主观评价的质量维度比如代码可读性。我这两个任务都满足这些条件。任务一的对错点是那三个 bug质量维度是代码组织和无障碍处理任务二的对错点是清洗逻辑是否正确质量维度是报告的实用性。6.2 评估时我关注的五个维度在这两次实测中我主要关注五个维度第一首次输出的可用度。它第一次给出的代码有多少比例是可以直接用的有多少需要改。任务一中大约 85% 可用任务二中大约 90% 可用。第二主动处理的边缘情况数量。它主动处理了多少我没提到的边缘情况。任务一中它主动处理了 4 个任务二中主动处理了 3 个。第三迭代修复的准确率。我指出问题后它一次修复成功的比例。这两个任务中它 6 次修复全部一次成功。第四代码的可读性和组织。命名是否清晰、结构是否合理、注释是否恰当。这方面它的表现是合格的没有出现明显的坏味道。第五对模糊需求的判断力。当需求不明确时它做的假设是否合理。这方面它的表现不错大部分假设是合理的少数不合理的也能通过一轮反馈纠正。6.3 跑分和实测的互补关系最后说一个观点跑分和实测不是对立的而是互补的。跑分帮你快速筛选出大概率能用的模型实测帮你确认在你的具体场景下是否真的好用。跑分是粗筛实测是精筛。我的建议是先用跑分缩小候选范围然后针对你的核心使用场景设计 2-3 个实测任务跑一遍。这个过程花不了多少时间但能帮你避免跑分很高但用起来别扭的尴尬。Step 5 Preview 在这两个任务中的表现让我愿意把它纳入日常工具链。它不是完美的——在状态联动、时区处理这些细节上还有提升空间——但它的整体判断力和代码质量是可靠的。特别是它在主动处理边缘情况方面的表现说明它不只是一个代码生成器而是一个有一定工程意识的助手。如果你也在用类似的工具我建议你不要只看它能不能写出正确代码还要看它能不能在你没说的地方也想到。后者才是真正拉开差距的地方。