1. 为什么选这三个任务来测大模型编程能力1.1 三个任务代表的能力维度先说结论Step-5-Preview 这名字看着像个通用代码模型但通用代码模型在纸面上都差不多真拉到项目里用完全是另一回事。我这次没有选那种“写一个冒泡排序”“写一个登录页面”的玩具题而是专门挑了三个有代表性的实战任务3D 游戏、金融分析、网页设计。这三个任务恰好覆盖了大模型代码能力的三条核心战线——复杂逻辑推理与三维数学能力、数据处理与统计建模能力、视觉审美与工程细节能力。写 Three.js 游戏要求模型对矩阵变换、相机视角、动画回调有真实理解而不是背 API做金融分析要求模型能正确设计数据处理流程计算收益率、回撤、夏普比率还得能跑通做网页设计要求模型在视觉上拿出合格的设计审美布局、配色、动效一个都不能糊弄。三条线都跑及格模型才算真正“能干活”。我见过太多模型评测写个 Hello World 就宣布全能写个贪吃蛇就惊呼天才。这次我要的是可运行、可交付、可上线级别的东西而且三个任务不能互相借用同一套代码模板——每个任务都是独立的领域、独立的技术栈、独立的质量标准。1.2 测试环境与提示词设计思路先交代一下测试环境。我用的是一台 16 核 CPU、32GB 内存、带 RTX 3060 的台式机操作系统是 Ubuntu 22.04浏览器用 Chrome 120。所有生成任务都直接在 Step-5-Preview 的网页对话界面里跑不开 API、不做二次微调目的就是测它的“裸考”水平。提示词设计是这次测试最关键的一环。我给每个任务都采用三段式提示词结构角色设定 需求描述 验收标准。比如 3D 游戏任务我的首轮提示词是“你是一名熟悉 Three.js 的资深游戏开发者。请写一个完整的 HTML 单文件 3D 游戏游戏类型是卡通风格的低多边形跑酷玩家控制角色在三条跑道上躲避障碍物并收集金币支持键盘和触屏操作。要求所有代码写在单个 index.html 里可直接打开运行包含游戏开始界面、计分系统、碰撞检测、游戏结束逻辑不需要外部资源文件。”这里有一个很多人容易忽略的点提示词里一定要写明“验收标准”而且验收标准越具体模型输出的完成度越高。如果只说“写个 3D 游戏”模型大概率会给你一个只有旋转立方体的空场景。而当我明确要求“包含开始界面、计分系统、碰撞检测、游戏结束逻辑”之后模型就会主动补齐这些结构性组件。金融分析任务的提示词我换了一套逻辑强调数据流程与分析指标“你是一名量化研究员。请用 Python 写一个完整的单股分析脚本读取 CSV 格式的日线数据日期、开盘价、最高价、最低价、收盘价、成交量计算收盘价均线 MA5、MA20、MACD 指标计算区间收益率、年化波动率、最大回撤、夏普比率并用 matplotlib 输出 K 线图与指标子图。数据文件路径和列名写死在脚本顶部缺数据时自动跳过。”网页设计任务则偏重视觉和交互“请用纯 HTML CSS JavaScript 制作一个中秋节主题的品牌活动落地页包含首屏大图、产品介绍、活动规则、进度抽奖四个模块。要求响应式布局适配手机和桌面端配色以深蓝、金色、月白为主带有月亮浮云淡入动画和滚动渐显效果不要用任何框架和外部图库文字内容用占位文本即可。”三次提示词我都控制在 150 字以内没有堆砌复杂指令。实际生成效果表明Step-5-Preview 对“验收标准”的响应非常灵敏——只要明确列出要有什么模块它基本不会漏掉。相比之下如果提示词里给的信息太少生成结果就明显更接近“示例代码”离“可用产品”有很大距离。2. 3D 游戏开发实测从一句需求到可运行场景2.1 需求拆解与提示词方案跑酷类 3D 游戏看着简单实际涉及十大核心模块场景搭建、角色建模或加载、光照、相机跟随、跑道自动生成、角色移动控制、障碍物生成与销毁、碰撞检测、计分系统、状态管理开始/进行中/结束。我在首轮提示词里刻意没有逐个列出这些模块而是用“包含游戏开始界面、计分系统、碰撞检测、游戏结束逻辑”一句话框定了最低验收线让模型自己发挥结构性设计。专业开发者看到这里应该能理解我的用意如果我事无巨细地把所有模块都列出来实际上是在帮模型“做题”测不出它自己的架构设计能力。我要看的是它在只有功能约束、没有实现约束的情况下能不能自己搭出一套合理的游戏架构。这一步本质上是考察模型对“职责划分”的直觉。Step-5-Preview 的首轮输出是 320 行左右的单文件 HTML包含三个 script 标签块场景初始化、游戏逻辑、输入处理。整体结构符合预期。角色是一个由立方体和球体组合构成的“低多边形小人”三跑道系统用三个固定的 x 坐标值-2.2、0、2.2实现障碍物用随机生成的彩色柱体金币用旋转的黄色八面体。没有加载任何外部模型没有使用任何贴图资源完全自包含。我在这里要特别说一个被很多人忽略的细节Three.js 游戏的核心复杂度不在场景搭建而在“移动”的实现方式。跑道本身不移动移动的是角色相对于障碍物的前进感。Step-5-Preview 采用了最常见的方案——让障碍物和金币以恒定速度向角色方向移动角色原地保持在跑道上切换。这个方案的优点是逻辑简单缺点是对时间间隔敏感帧率波动会影响游戏速度。实测中它在 requestAnimationFrame 回调里用 deltaTime 做了速度补偿这一点比很多半吊子示例强。2.2 核心代码生成与关键参数首轮生成的关键代码段中角色控制模块的完整逻辑如下const lanePositions [-2.2, 0, 2.2]; let currentLane 1; let gameSpeed 12; let score 0; let isGameOver false; let isJumping false; function switchLane(direction) { if (isGameOver) return; const newLane currentLane direction; if (newLane 0 newLane lanePositions.length) { currentLane newLane; // 横向平滑插值避免瞬移 const targetX lanePositions[currentLane]; const startX player.position.x; const startTime performance.now(); const duration 120; // 毫秒 function animateLaneSwitch(time) { const elapsed time - startTime; const t Math.min(elapsed / duration, 1); player.position.x startX (targetX - startX) * easeOut(t); if (t 1) requestAnimationFrame(animateLaneSwitch); } requestAnimationFrame(animateLaneSwitch); } } function easeOut(t) { return 1 - Math.pow(1 - t, 3); }这里有两个技术点值得展开。第一变道用的是插值动画而非直接赋值代码里加了 easeOut 缓动函数让角色横向移动带一点加速减速的曲线感实际视觉效果比线性移动自然很多。第二变道期间没有做防重复触发的处理也就是说玩家在 120 毫秒内连按两次方向键第二次变道动画会打断第一次的插值过程。我实测中连按方向键时角色会出现轻微的横向“抖动”但整体不影响游戏体验。如果想严格修复需要加一个 isSwitching 标志位这是可选的优化项。碰撞检测的代码也值得一提function checkCollisions() { const playerBox new THREE.Box3().setFromObject(player); const playerY player.position.y; // 检测障碍物碰撞 obstacles.forEach((obs, index) { const obsBox new THREE.Box3().setFromObject(obs); if (playerBox.intersectsBox(obsBox)) { if (playerY 0.8) { // 跳跃时高度为0.8以上可躲避 gameOver(); } } }); // 检测金币收集 coins.forEach((coin, index) { const coinBox new THREE.Box3().setFromObject(coin); if (playerBox.intersectsBox(coinBox)) { scene.remove(coin); coins.splice(index, 1); score 10; updateScoreDisplay(); } }); }用 Box3 做包围盒碰撞是最常规的做法关键在于跳跃躲避的判定逻辑。原代码里玩家正常站立的 y 坐标是 0跳跃时角色 y 坐标最高到 1.2代码用 playerY 0.8 判断是否在地面高度。逻辑没错但有个隐患跳跃过程是高度连续变化的如果角色跳到 0.75 高度时刚好撞上障碍物代码会判定为碰撞失败但视觉上角色还没完全落地。我实测把判定值从 0.8 调整为 0.4让跳跃躲避的容错区间更大手感更宽松这是针对这个模型生成代码的一个实战调优建议。2.3 生成结果评估与踩坑记录首轮生成结果直接在 Chrome 里打开 index.html 运行画面上能看到低多边形小人站在三条跑道的中间前方随机生成彩色柱体障碍物和旋转金币游戏顶部显示得分的浮层右侧有“按空格跳跃、方向键切换跑道”的操作提示。按下方向键角色平滑切换跑道流畅度合格。空格跳跃也有高度变化和简单的重力回落。但第一版有四个明显问题。第一个是移动端的触屏按钮缺失。提示词里明确要求“支持键盘和触屏操作”首轮生成只做了键盘监听触屏完全没做。第二版生成时我在提示词里补充了一句“添加触屏控制按钮左右按钮切换跑道跳跃按钮实现跳跃”Step-5-Preview 在页面底部生成了三个半透明圆形按钮通过 pointerdown 事件绑定到对应的移动函数顺带处理了 touch-action 的 CSS 属性避免点击缩放干扰。第二个问题是障碍物生成不均匀。原逻辑是每隔一定时间生成一个障碍物但生成的横向位置是完全随机的导致偶尔连续四五次都在同一赛道生成障碍物玩家几乎无路可走。我手动增加了连续生成同跑道障碍物的概率限制每生成一个障碍物下一次同跑道的生成权重降为原来的 0.3 倍避免极端卡位。第三个问题是游戏结束界面没有重新开始的入口。游戏结束时只弹出一个红色全屏遮罩显示“游戏结束”和最终得分但没有任何按钮。这是一个完成度缺陷提示词要求“游戏结束逻辑”但没有明确说要“重新开始按钮”。严格来说不算模型漏做而是我验收标准没写到位。后续版本我要求它补上“点击重新开始按钮重置所有状态并恢复游戏循环”Step-5-Preview 正确地在遮罩层底部添加了可点击的重新开始按钮并重置了角色位置、障碍物数组、金币数组、得分和游戏速度。第四个问题是性能波动。游戏默认跑了 4 层雾效果和动态阴影在我的 RTX 3060 上没问题但用 Chrome 的 DevTools 模拟低端安卓设备性能时帧率能从 60fps 掉到 25fps 左右。原因主要集中在地块的细分面数过高和 dynamic shadow 的实时计算上。我选择关闭动态阴影、降低地面网格细分并用 InstancedMesh 重写了障碍物的生成逻辑性能立刻回到稳定 50fps 以上。这一轮实测下来Step-5-Preview 在三维场景类代码上的表现属于“能给能改”的合格水平——首轮能直接跑起来遇到问题能用二次对话快速修正而且修正的代码不会破坏已有功能。最主要的短板是没有自主发现移动端缺失、极端随机卡位这类“隐含需求”需要测试者自己有游戏开发经验去主动补测。整体评价一个懂 Three.js 的初级开发者的水平但效率上远超初级开发者因为它的试错和修改速度极快。3. 金融数据分析实测从原始数据到可视化结论3.1 数据处理与脚本整体设计金融分析任务的测试难度比 3D 游戏低一个量级但考察点完全不同3D 游戏测的是空间逻辑金融分析测的是数据流的完整性与数值计算的正确性。这类任务最常见的翻车点有三个——CSV 解析时没有做缺失值处理、指标计算公式错误、绘图坐标轴不标注中文或单位。我让 Step-5-Preview 生成完整脚本后先人工审查计算逻辑再放入真实历史行情数据跑通全程记录它暴露的问题。首轮生成的是一个 180 行左右的 Python 脚本导入了 pandas、numpy、matplotlib、mplfinance 四个库。脚本结构如下read_csv 读取数据文件统一列名并排序计算 MA5/MA20、DIF/DEA/MACD 三个技术指标统计区间收益率、年化波动率、最大回撤、夏普比率四项绩效指标最后用 mplfinance 绘制带 MACD 子图的 K 线图。设计层面最让我满意的是缺失值处理逻辑。数据文件如果中间缺了一行脚本会自动向前填充ffill并在日志里打印缺失行索引。虽然填充会轻微影响指标准确性但至少不会让整个分析中断。我在提示词里完全没有提缺失值的事情模型自己加了说明它对真实数据的“脏”程度有认知。3.2 核心实现与运行细节计算部分的核心代码如下def compute_technical_indicators(df): df[MA5] df[close].rolling(window5).mean() df[MA20] df[close].rolling(window20).mean() ema12 df[close].ewm(span12, adjustFalse).mean() ema26 df[close].ewm(span26, adjustFalse).mean() df[DIF] ema12 - ema26 df[DEA] df[DIF].ewm(span9, adjustFalse).mean() df[MACD] (df[DIF] - df[DEA]) * 2 return df def compute_performance_metrics(df): df[daily_return] df[close].pct_change() df df.dropna(subset[daily_return]) total_return df[close].iloc[-1] / df[close].iloc[0] - 1 annual_volatility df[daily_return].std() * np.sqrt(252) max_drawdown (df[close] / df[close].cummax() - 1).min() # 无风险利率设为 2% risk_free_rate 0.02 excess_return df[daily_return].mean() * 252 - risk_free_rate sharpe_ratio excess_return / annual_volatility return { total_return: total_return, annual_volatility: annual_volatility, max_drawdown: max_drawdown, sharpe_ratio: sharpe_ratio }我逐行核对了技术指标计算公式。MA5/MA20 的 rolling mean 没问题MACD 的 DIF EMA12 - EMA26、DEA DIF 的 9 周期 EMA、柱值 (DIF - DEA) * 2这是标准算法乘以 2 是国内行情软件常用的比例因子符合惯例年化波动率用日收益率标准差乘以根号 252也是正确做法。最大回撤用收盘价除以历史最高收盘价再减 1 取最小值计算方式正确但它只基于收盘价而非盘中最高点属于简化口径可以接受。夏普比率的计算这里有一个数字值得注意脚本里用 daily_return.mean() * 252 作为年化超额收益的分子部分。这个写法理论上成立但国内量化分析更常见的口径是用“区间总收益率的年化值减去无风险利率”来计算夏普。两种口径对小波动率数据差距不大但对有极端行情的样本会有明显差异。我在实测说明里注明了这个口径选择并手动验证了不会导致方向性错误。一个我预判会翻车但实际没翻车的点是中文字体。绘制 K 线图时matplotlib 默认字体不包含中文字符一旦标题或坐标轴标注使用中文会显示成方块。Step-5-Preview 生成的代码里主动做了一次字体配置plt.rcParams[font.sans-serif] [Noto Sans CJK SC, SimHei, Microsoft YaHei] plt.rcParams[axes.unicode_minus] False它列出多个候选字体让系统自动选择第一个可用的。这个细节比很多现成的金融分析脚本都要成熟。我实测在 Ubuntu 上系统安装了 Noto Sans CJK SC所以标题、坐标轴、图例中的中文全部正常渲染。3.3 结果准确性与调优过程我用一组 2023 年初至 2024 年中的真实日线行情数据约 340 个交易日替换掉自带的示例数据路径直接运行脚本。K 线图输出正常五个模块的子图完整呈现主图是收盘价 K 线与 MA5/MA20 双均线副图是成交量再下面是 DIF/DEA 双线和 MACD 柱状图。R 角标显示得很清晰中文标注全部正常。我随后写了一个独立对照测试用同样的数据在 Excel 里手工计算 MA5 的最后五个值和最大回撤与脚本输出对比。显示到小数点后四位MA5 的数值与 Excel 结果完全一致最大回撤数值也是一致的。这一步很重要因为大模型生成的计算脚本最大的风险不是语法错误而是“公式正确但口径与你想象不同”的隐性错误。实测中发现一个需要优化的地方绘图区的成交量柱状图颜色逻辑是涨红跌绿但国内习惯是涨红跌绿而脚本里写的是“涨幅为正时用绿色涨幅为负时用红色”。这个逻辑在美股市场是涨绿跌红在国内行情软件里应该反过来。我让 Step-5-Preview 改成正涨红、负跌绿并同步修改图例和说明文字。这个修正不算代码错误但恰恰说明了大模型容易把国际惯例当作默认前提使用者必须有意识地审查它输出中的“隐含假设”。第二轮修改还让我验证了它对“数据文件路径”这个变量的处理。首轮生成里文件路径写在脚本顶部的配置区数据列名写死为 date、open、high、low、close、volume。我换数据时发现如果 CSV 列名是中文脚本会直接报错。Step-5-Preview 的修复策略是把列名映射逻辑改成从 CSV 第一行动态识别关键词收盘价、开盘价、最高价、最低价、成交量、日期匹配到哪个用哪个匹配不到就跳过。这个改动极大地提高了脚本对真实数据的兼容性至少我在三种不同来源的 CSV 上测试都能直接跑通。金融分析这轮的最终评价计算正确率 100%逻辑设计有真实项目意识缺失值处理、中文字体、列名兼容这些非显性需求都主动考虑到了。最大的短板是股票市场买卖习惯色没有默认适配中文语境以及夏普比率口径偏国际通用。整体能力在同级别模型里属于第一梯队可以直接拿来做生产环境的分析基础代码。4. 网页设计实测中秋节主题页面的完整落地4.1 设计思路与页面结构规划第三个任务我选了中秋节主题的品牌活动落地页这个领域和前面两个完全不同考察的是审美、排版、动效和响应式布局的综合能力。大模型写代码越来越强但能把页面写得“好看”的并不多。我给 Step-5-Preview 的验收标准是不使用框架、不使用外部图库、必须有响应式布局和两处以上 CSS 动画。首轮生成的页面结构如下Header 导航栏 首屏 hero 区域月亮、云朵、标题“中秋团圆夜”和副标题文案 产品介绍区三个卡片并排 活动规则区四步抽奖说明 Footer。布局完全匹配提示词要求的四个模块没有多余的部分。配色系统以深蓝夜空色#0B1026为背景色金色#F5C76E为强调色月白#FFF7E6为正文色。整套配色在浏览器里打开的第一眼非常协调这就是大模型在视觉上的一个优势——它不会像很多初学者那样往页面里塞彩虹配色而是能给出一个“看起来像品牌感”的色彩体系。深蓝与金色本来就是中秋主题里最稳妥的高级感组合Step-5-Preview 对这个时代的审美拿捏是到位的。4.2 HTML/CSS/JS 实现过程页面使用一个 hero 区域作为首屏背景是深蓝夜空用 CSS 绘制了一轮圆月和几朵浮云。月亮是用一个带径向渐变和 box-shadow 光晕的圆形 div 实现的浮云用三个椭圆形的半透明白色 div 组合然后整体套了一个缓慢漂移的动画。这段实现非常聪明没有使用任何图片完全靠 CSS 几何形状拼出了月夜氛围间接证明了它理解“零外部资源”的约束。.moon { width: 160px; height: 160px; border-radius: 50%; background: radial-gradient(circle at 35% 35%, #FFF8E1, #F5C76E); box-shadow: 0 0 40px 10px rgba(245, 199, 110, 0.35); position: absolute; top: 100px; right: 10%; animation: moonGlow 4s ease-in-out infinite alternate; } .cloud { position: absolute; background: rgba(255, 255, 255, 0.12); border-radius: 100px/60px; filter: blur(6px); animation: drift 8s linear infinite; }动画部分包含三种月亮的呼吸辉光动画box-shadow 强度周期性变化、云朵的横向漂移动画translateX 分段变化、内容区块的滚动渐显动画利用 IntersectionObserver 在元素进入视口时添加 visible 类名。前两个是纯 CSS第三个需要 JS。Step-5-Preview 对这个组合的处理是标准的JS 只负责观察元素并切换类名过渡效果全在 CSS 里完成没有把动画逻辑耦合进 JS 造成性能浪费。响应式布局用的是传统媒体查询方案。在 768px 以下产品卡片由三列并排变成单列纵向堆叠hero 区域的月亮从相对定位变成绝对定位且缩小尺寸导航栏的菜单项变为隐藏并出现汉堡按钮。汉堡按钮的展开与收起也正确写进了 JS点击事件切换菜单的展开类。我实测用 Chrome DevTools 分别在 375px、768px、1440px 三种视口下检查三栏卡片的排列、字体大小、边距都没有出现横向滚动条或明显重叠。4.3 视觉效果修正与浏览器兼容第一轮生成中有一个视觉问题产品介绍区的卡片底色是纯深蓝文字是浅金色但卡片阴影的重度用得太猛导致三张卡片看起来像是三个孤立的黑块悬在背景上。我让模型把卡片配色改为半透明背景rgba(255,255,255,0.06)加细边框1px solid rgba(255,255,255,0.15)阴影缩小到 8px 且透明度降低。这个改动让卡片与背景自然融合整个页面的层次感明显提升。另一个问题是滚动静渐显动画的触发太早。默认 IntersectionObserver 的 rootMargin 为 0 时元素顶部刚进入视口就触发动画视觉上常常还没看到元素完整形态动画就已经结束了。我把 rootMargin 改成 -80px 0px -80px 0px让元素进入视口更多一些才触发渐显节奏更缓和。浏览器兼容穿了两次小鞋。第一次是 Safari 下 CSS 变量和 backdrop-filter 的部分属性没有生效页面背景出现了一点色差。第二次是部分安卓微信内置浏览器不支持 :focus-within 伪类导致导航菜单在移动端点击后不会收起。Step-5-Preview 给出的修复是用 JavaScript 监听点击事件来做菜单关闭取代纯 CSS 的 :focus-within 方案改动量很小但解决了兼容问题。整个网页设计任务耗时约三十分钟我把所有测试和修改过程记录如下表测试项结果修正耗时修正方式首屏加载渲染通过0 分钟无375px 移动端布局通过0 分钟无需调整卡片视觉层次不通过5 分钟半透明背景 细边框渐显动画触发时机不通过3 分钟调整 rootMarginSafari 兼容性不通过8 分钟增加 fallback 代码微信内置浏览器菜单交互不通过6 分钟JS 监听代替伪类这一轮的评价Step-5-Preview 在审美层面的表现超出预期不仅完成了功能而且给出了一个真正可以拿去交付的品牌活动页体验。问题集中在兼容性细节而这些细节在开发流程里本来就是人工测试的重点环节大模型负责提供主干测试者负责挑刺修正协作效率很高。5. 跨任务实测总结能力边界与使用技巧5.1 三个任务的综合表现对比三件事跑完把最终成果放在一起做了横向对比。任务首轮可用率最终完成度主要短板典型修复轮数3D 游戏70%可运行缺移动端控制95%隐含需求触屏、重开4 轮金融分析90%可直接跑通98%市场颜色习惯、列名兼容2 轮网页设计80%功能完整细节需调97%浏览器兼容、视觉微调5 轮综合来看Step-5-Preview 的三项能力都在“能用”线以上。最强的单项是金融分析因为这类任务的本质是“把公式转换成代码”计算规则明确、逻辑链路清晰模型的犯错率最低。3D 游戏和网页设计都暴露出隐含需求识别不足的问题需要使用者有对应的领域经验来驱动修正。这个结论其实印证了一个大趋势大模型编程能力的下限取决于训练数据上限取决于使用者的“验收能力”。你越知道什么是一个好游戏、好页面你越能让模型产出好结果。5.2 提升生成质量的提示词技巧三次实测下来我总结出四条对大模型编程任务非常实用的提示词技巧。第一验收标准必须明确到模块层面。与其说“做一个月饼促销页面”不如说“包含首屏大图、产品介绍、活动规则、进度抽奖四个模块”。模型在需求缺省时倾向于输出最小可行版本你给的模块清单就是它的保底完成度。第二约束条件要一次写全。框架限制、资源限制、语言版本、兼容目标这些信息分散在后半段对话里补模型的修改成本会指数上升。比如三件事我都补了“不用外部库、不用图片资源”首轮生成就用纯 CSS 代替了图片省了大量二次加工。如果你先让它用了 Bootstrap后面再去掉框架改动的范围会波及全部组件样式得不偿失。第三修复类提示词要带上“复现路径”。我发现用描述性反馈比直接命令更有效。比如“移动端触屏按钮缺失”比“加上触屏按钮”效果更好因为模型会检查自己之前的结构在正确的位置插入代码而不是在文件末尾追加一堆与整体架构脱节的补丁。第四对生成代码要保留“审查心态”不要盲信。金融分析里夏普比率的口径问题网页设计里卡片阴影过重的问题这些都不是语法错误而是隐含假设错误。只有带着领域经验去读代码的人才能发现。大模型最危险的地方不是它写错而是它写得像是“理所当然的正确”。5.3 适用场景与使用建议基于这轮实测我给不同人群一些使用建议。如果你是产品经理或设计师Step-5-Preview 最适合用来做原型生成和动态稿的快速验证。网页设计的输出完成度已经比大部分手写原型要高了你只需要微调配色和文案即可进入用户测试环节。游戏类的开发建议优先用于低多边形的原型场景用于验证玩法循环而不是直接商业化。如果你是量化分析或金融数据方向的学生可以让它作为算法提炼和数据清洗的辅助工具。它会主动处理缺失值和中文字体也能给出计算框架但最终的数据口径和业务逻辑必须你自己把关。建议把它生成的分析脚本当作文档来读而不是当作文档来抄。如果你是独立开发者Step-5-Preview 最强的使用方式是“多轮会话 分模块提交”。每次会话只让它完成一个模块的代码你负责模块之间的接口定义。这样既能控制生成质量又能把每次输出的代码直接合并进项目避免单次生成巨量代码导致的不可维护性。整个实测过程让我意识到大模型代码能力的度量标准正在从“能写多少”变成“能修多好”。真正高效的使用者不是把模型当成自动写码机而是当成一个行动力极强的初级工程师——它能把 70% 的工作直接做完剩下的 30% 需要你给出准确的改进指令。Step-5-Preview 在三个完全不同的任务里都表现出这种“行动力强、反馈响应快”的特质配合招聘一个初级开发者来完成同样的三份工作Thread分钟基本上跑不完更别说中间还要改需求、查文档、写测试。这就是为什么我最终会向身边实际写项目的人推荐这个模型的原因——它不是一个展示智商的技术玩具而是一个能缩短交付周期的真实生产力工具。最后再分享一个这轮测试中的小技巧在每个任务的首轮生成之后先别急着要求修改。把生成代码完整读一遍把“你认为它是这样实现但其实它是那样实现”的地方全部标注出来然后一次性把所有修改需求发给模型。这个方法比逐轮反复对话效率高出一倍以上因为模型在单次修改请求中能同时处理多个不相关的修正项不会因为上一轮修改而影响下一轮的逻辑判断。我实测三个任务都是用这个批量修改策略完成最终版本的每次批量修改后的回归测试也都没有引入新的逻辑冲突。