当开源旗舰开始做工程题：Step 5 Preview 真实能力实测

开源大模型竞争日趋白热化，阶跃星辰最新旗舰 Step 5 Preview 甫一发布便引发行业热议。相比于跑分榜单，普通开发者更关心一个核心问题：这些开源旗舰在真实工程场景中到底能做什么？我决定用一道标准的工程师考题来实测：陌生的项目、能复现的 Bug、顺手加上的需求，三者叠加才是日常开发的真实模样。这个测试不考数学、不考推理，考的是模型能不能像真正的工程师一样理解代码、定位问题、给出可维护的解决方案。

测试对象是一个叫 OrderHub 的订单管理系统，Python 加 Flask，四百多行代码，带 SQLite 数据库和一套 pytest 测试。这道题有三层考验：第一层，导出功能存在两个串联 Bug，路由层没把筛选参数传给查询层，而查询方法默认只返回第一页二十条；第二层，存储层有个隐藏故障点，首次写入必然失败，必须实现最多三次的重试逻辑；第三层，补测必须全绿，十项验收标准每项对应一条 curl 命令或测试用例。三个模型在完全相同的提示词、代码包和验收清单下独立运行，不许中途提问，不给任何人工提示。

测试设计：三层考验叠加的真实工程任务

Step 5 Preview 用时 328 秒、28 次迭代，十项验收一次全过。它没有在路由层打补丁，而是在数据访问层新增专门的 query_all 方法，语义上把“不分页、取全部”说清楚，导出走新方法，列表的分页逻辑原样保留。分层边界是这类问题最容易糊弄的地方，它处理得干净。测试方面它主动补了两个用例，其中一个模拟存储彻底挂掉，验证重试耗尽后导出目录完全干净、临时文件全部清除。唯一不足是持续失败时错误信息只有“export failed”，运维显然更想要重试次数和底层原因。Qwen 3.8 Max 最快，206 秒、18 次迭代，同样十项全过，但采用先查总数再一次性取回的方式绕开分页，查询层默认只给二十条的行为被保留。Kimi K3 解法与 Qwen 基本一致，重试封装更讲究，错误信息带底层原因。

三家横评：一步快与步步到位的权衡

三层缺陷、十个硬性验收，这道题放在去年足以难倒绝大多数模型，现在三家都能一次通过。但快一分钟慢两分钟，对真实工程来说没那么重要；留在查询层里的分页默认值，在现实的工程里总会坑下一个人。Step 5 Preview 让人记住的是它的工程品味：它是唯一一个把 fix 放回原位的选手。看模型发布数据，它的单任务成本是 GLM-5.3 和 Kimi K3 的 35%、Claude Opus 5 的 12.5%，这个数字对需要频繁调用模型的业务场景很有意义。很多团队算得过来的账，可能要因此重算了。用明显更低的价格提供前沿级别的能力，这大概就是“帕累托前沿”的真实含义。

真实项目中的附加收获

趁着无限 Token，我用这个模型改进了两个真实项目。第一个是开源工具 Agent Hud，用来优雅展示 Agent 使用额度，但刘海屏 MacBook 接外屏后会强制给外屏画一个刘海，且下拉菜单没有退出选项。让 Step 5 Preview 修复后，非刘海外屏只显示菜单项和退出，笔记本屏才出现灵动岛交互，完成得又快又准。第二个是 CatReader 的主题阅读功能，用 Codex 加上 Astra 与 Step 5 Preview 交叉设计、实现和 review：Step 5 Preview 会对其他模型的实现给出自己的看法和建议，后者据此修复。目前功能已推到测试环境，用户点击确认后 AskCat 会自动筛选文章、加收藏、做研究，直接保存到墨问里。模型测试过程中遇到的中断、安全护栏问题反馈给厂商后很快得到处理，这个阅读 Agent 是这次内测的附加收获。

更强的模型能以更低的成本进入日常开发，我们就能把更多时间花在那些一直想做、还没做完的事情上。这也是“帕累托前沿”这句口号的真正含义：不是追求单点极限，而是找到智能与成本的最优平衡。开源大模型在 Coding Agent 领域正在快速成熟，模型的价值不在跑分里，在能不能帮开发者省出时间。