本文深入分析阶跃星辰Step-5-Preview模型在AI编程场景下的真实能力：其核心优势在于1M上下文支持、长任务续航（22小时自主优化）与工程级稀疏激活设计（600B总参/27B激活/92层窄而深架构），但智能指数仅44（AA校准后），与Qwen3.8-Max（45）基本同档；关键成本特征为输入侧便宜42%、输出侧因1.78倍冗长抵消，实际仅提供1.74轮容错；适用场景聚焦长上下文任务（如全仓理解、跨文件重构、截图转页面），不适用于短判断类任务（如schema设计、SRE排障）。
Step-5-Preview 在编程领域到底怎样？
先说清楚这次的一格长什么样
飞算JavaAI 的模型框里，这次只多了一行：
Step-5-Preview 1.0× 0.5×
1.0× 划掉，实收 0.5×，后面挂着一个绿色的角标。
和前面几篇不一样，这次没有同厂兄弟可以对比。DeepSeek 那次是四行、GLM 三行、Kimi 三行、MiMo 两行、Qwen3.8 两行，MiniMax-M3 和这次的 Step-5-Preview 都是单行。单行意味着少了一次"内部比价"的机会，也意味着判断的难度变了：你没办法用同一家的两个型号互相锚定，只能拿它跟框里已有的、同样标 0.5× 的那个模型比。
目前这张表上标 0.5× 的，除了它就是 Qwen3.8-Max。
于是问题变得非常具体：同样的 0.5×，我为什么要多留一格给 Step-5-Preview？
这篇文章要回答四件事：
- 那个"44 分"到底是高还是低——先得确认别人嘴里的 56、58 跟你看到的 44 是不是同一把尺子；
- 它强在哪、弱在哪，强弱之间的边界有多硬；
0.5×这格钱到底买到了什么，以及那 42% 的单价便宜能撑几轮试错；- 在飞算JavaAI 的四阶段流水线里，哪几段该交给它、哪几段必须拦下来。
先把三个时间点摆出来，因为它们直接决定你现在看到的是不是一个稳定产品：
- 9 月 20 日：API 与 Studio 全量开放，编号直接跳过 Step 4.x；
- 10 月 14 日 – 10 月 17 日：BF16 与 FP8 权重陆续上线 Hugging Face 与 ModelScope（不同信源给的日期不一致，后文单列）；
- 今天：它仍然叫 Preview。
Preview 不是"测试版"这么简单的一个词。它意味着定价、倍率、甚至能力都会变。这一点在后面算账和结论里会反复出现。
一、先校准尺子：44 和 45 能比，44 和 58 不能比
这是本篇最该先讲的一条，因为它会直接改写你对这张表的判断。
Artificial Analysis 的智能指数在 2026 年 9 月 7 日做过一次重校准，把整个场子的分数压了一遍。压完之后：
- Qwen3.8-Max = 45
- Step-5-Preview = 44（原始值 43.7，部分页面取整为 44）
但你在网上会看到 Qwen3.8-Max 被写成 53、56、58。这不是造谣，是同一件事的三个历史切片：
| 时间 | 数值 | 发生了什么 |
|---|---|---|
| 发布时 | 53 | 首测 |
| 之后 | 撤回 | AA 称被测端点存在间歇性问题 |
| 重跑 | 56 | 改测阿里公网 API |
| 被引用 | 58 | 二次转述时的写法 |
| 9 月 7 日重校准后 | 45 | 当前刻度 |
所以规则很简单：
45 和 44 可比，差 1 分。45 和任何一个 9 月 7 日之前的数字都不可比。
凡是把 Qwen3.8-Max 的 58 和 Step-5-Preview 的 44 并排放的页面，都是在用两把尺子。按那个比法，你会得出"Step 差 14 分，不值得试"的结论；按正确的比法，是"差 1 分，几乎等价"。
这一个纠正，就把结论从"别用"翻转成了"该认真算钱"。 后面所有的成本讨论，都建立在"智能接近"这个前提上。如果智能真的差 14 分，那 42% 的单价便宜根本不值得讨论。
第二把尺子：Vals AI
AA 不是唯一的第三方。Vals AI 把 Step-5-Preview 放上了榜，给的是另一套数：
- Vals Index 49.35%，平均每题成本 $2.63，单题延迟约 70 分钟；
- Terminal-Bench 4.0 31.82%（官方自报 33.3%），总榜第 13、开源模型第 3；
- 在同一个榜上，它压过了 Grok 4.7、Claude Opus 4.8、GPT-5.6 Terra（后者每题 $3.11）；
- 但 GLM-5.3 的 38.9% 和 Qwen3.8-Max 的 34.3% 仍然更高，代价是约 3 倍的花费。
两个第三方、两套测法、两个方向略有出入的结论，但指向同一件事：
智能水平基本同一档；差别在成本结构和耐力。
这就是本文的骨架。
二、底牌：600B 里只点亮 27B，92 层"窄而深"
先把硬件账本摊开。以下数字来自官方技术报告、Hugging Face 模型卡与 ModelScope 页面。
| 项目 | 数值 |
|---|---|
| 架构 | 稀疏 MoE |
| 总参数 | 600B（ModelScope 文件标 604.34B） |
| 每 token 激活 | 27B（稀疏度约 4.5%） |
| 层数 | 92 层 Transformer，“窄而深” |
| 上下文 | 最高 1M tokens |
| 最大输出 | 最高 1M tokens |
| 输入模态 | 文本、图像（视频口径不一，见文末） |
| 注意力 | 门控滑动窗口 + 稀疏全注意力，3∶1 交错 |
| 全注意力路径 | Sparse GQA，块大小 B=8，top-k k=4096（即 512 个块） |
| 投机解码 | MTP-3 头，端到端约 +30% |
| 训练精度 | FP8 混合精度，原生 FP8 MoE 推理约 +20% |
| KV 容量 | 通过 EP 协调、KV CPU offload、MXFP4 权重存储、FP8 KV QAT 扩大 8–12 倍 |
| 实测输出速度 | 99.8 tok/s |
| 首 token 延迟 | 2.96 s（同表 Opus 5 在 max effort 下为 56.84 s） |
| 权重体积 | FP8 检查点 650.32 GB |
| 许可 | StepFun Model License 1.0（另有信源写作 StepFun Community License，非 Apache 2.0） |
2.1 为什么"窄而深"不是营销词
这一条我觉得是整份技术报告里最值得抄进工程笔记的推理。
Agent 干活的时候，绝大部分算力花在 prefilling 上：每调一次工具、每读一个文件、每贴一次报错，都是一次新的预填充。模型没有多少机会像人那样"停下来想想"——它的显式思维链被频繁的工具往返切碎了。
而 Transformer 的预填充信息流，在时间和深度两个轴上都是单向的。多跳依赖链要一环一环往深处传：第 3 层知道的事，第 40 层才用得上。层数不够，长预填充场景下的隐式多跳推理就根本发生不了。
所以"深"是为了在没有显式思考预算的时候还能推理；"窄"是为了便宜。600B 总参 / 27B 激活，参数量不到某些 2.8T 巨物的四分之一，激活量不到三分之一，但深度持平——这是一个非常明确的取舍：用深度换宽度，用稀疏换成本。
2.2 稀疏注意力那 8 倍，别直接乘以 8
官方在技术博客里写了一个我觉得很罕见的、主动降温的句子：
索引与 top-k 选择开销降到原来的八分之一，并不等于完整推理流程提速八倍，也不能直接推导服务成本按同样比例降低。
实际部署还要承担权重读取、注意力计算、跨设备通信和工具执行的成本。这句话值得单独拎出来，因为它是判断"厂商是否可信"的一个信号：愿意主动削弱自己数字的团队，其他数字更值得看。
同一段里还有一个数字对：块大小 B=8、top-k k=4096 的配置下，token 覆盖度是 78.06%，而 B=1、k=2048 的参考配置是 79.09%。也就是说，用八分之一的索引成本，换来了不到 1.1 个百分点的覆盖率损失。
这个 78.06% 后面会变成一个很重要的直觉：1M 上下文不是"每个 token 都能被看见"。全注意力层每个查询只看 4096 个历史 token。窗口是 1M，注意力预算是 4K。这两件事必须分开记。
2.3 27B 激活省的是算力，不是显存
这一条经常被误读成"27B 就能跑"。
稀疏激活降低的是每 token 的计算量（所以 API 单价便宜、速度能到 100 tok/s），但没被激活的专家权重仍然要待在显存里。650.32 GB 的 FP8 检查点就是证据。
官方给的最低配置：
- FP8 + vLLM/SGLang：单节点 4× B300 或 8× H200；
- BF16 + vLLM：单节点 8× B300，或两节点 16× H200；
- Transformers 只支持离线生成，完整 BF16 分片流程官方说"尚未端到端验证"。
这不是"工作站能跑"的量级。自托管的账我们放到第五节一起算。
三、它的"续航"是从哪来的：四个工程决策
如果只看跑分，你没法解释为什么一个 44 分的模型敢说自己能连续跑 22 小时。答案在四个训练/系统工程决策里，不在基准表里。
3.1 上下文压缩被塞进了端到端策略训练
绝大多数模型的"上下文管理"是外层 harness 干的活：写个摘要函数、到了阈值就压一下。Step-5-Preview 把这件事变成了模型自己要学会的动作——而且用同一套任务奖励一起优化。
效果是：当上下文预算接近耗尽时，模型不是简单地把旧消息扔掉，而是把工作整理成一个可恢复的状态，然后继续干。
这个设计的好处和风险是同一枚硬币：
- 好处：长任务不会在"第 87 轮"突然失忆；
- 风险：压缩是模型自己判断该保留什么的。它可能把"客户要求金额必须保留两位小数"这条约束当成冗余压掉，然后一路错下去。
这一点在后面代码实战里会变成一条具体的操作纪律：永远自己维护一份"不可压缩清单"。
3.2 百万级可验证环境，以及官方自己承认的奖励漏洞
训练用了"百万级"的可验证环境，覆盖科学推理、软件工程、机器学习研发、专业工作。技术博客里有两句话很实在：
- Agent 合成数据容易偏向简单、重复的任务，所以要显式控制难度和多样性；
- 要检查模型是否利用了评测漏洞获得奖励。
官方原话的意思是：测试通过可能意味着代码正确，也可能意味着测试根本没覆盖关键条件；任务得分提升可能来自能力，也可能来自模型找到了评分规则的捷径。
这句话对使用者的启示不是"这模型会作弊"，而是：如果拿它跑你的私有评测，先检查你的测试是否可被绕过。
3.3 训练-推理逐位对齐：长轨迹 RL 不塌的地基
这部分比较硬核，但对理解"为什么它能跑长任务"很关键。
在线 RL 里，同一个模型要跑在两套引擎上：训练侧用 FSDP/Megatron（TP=1 起步），推理侧为了吞吐上多卡 TP。浮点加法不满足结合律，归约顺序不同，同一个 token 的 logprob 就有偏差。MoE 上更糟——微小的数值差异经过路由分发被放大，再叠加 off-policy 的陈旧性，重要性采样权重就系统性偏离 1，PPO 的裁剪区间也就失去了保护意义。
Step-5 的处理是把失配按陈旧度分流：
- 陈旧度 = 0：训练与推理算子完全对齐，logprob 差异精确为零，用一棵优化过的树形归约做到与 TP 规模无关（TP=1 训练 vs TP=8 推理逐位一致），总开销 <10%；
- 陈旧度 > 0：精确对齐不可能了，就回放——冻结 MoE router 用推理时记录的专家索引与系数重放；回放 top-p 候选集，只在候选上重算 logprob；logit 梯度加零中心投影消除共模漂移。
对齐之后的行为变化很直观：FP8 策略复现了 BF16 的行为，每轮 token 数稳定、轮次稳步增长、熵稳定；未对齐版本则漂移成"臃肿、无结构的单轮输出"。
“臃肿、无结构的单轮输出”——这句话建议记下来。 后面讲它的"话痨"毛病时，你会看到同一个词。
3.4 样本不丢：lifecycle ledger
还有一个容易被忽略的事实：rollout 从生成到进训练要经过很长的链条，每个边界都是样本可能静默丢失的地方，而且丢失是不均匀的——集中在最长、最难的那些轨迹上。这会直接造成训练分布偏移：模型越练越擅长简单任务。
它的解法是 lifecycle ledger：追踪每个预期 rollout 直到一个具名终止状态，配合 turn 级别的事件记录，把端到端样本丢失率压到 1% 以下。
四条加起来，才是"22 小时"这个数字的地基。而这个数字本身是：
一个自主优化 GPU kernel 的任务，模型连续工作约 22 小时，自己实现、自己跑、自己看吞吐曲线、方案退化就回滚到最优版本，最终做到 508 TFLOPS，超过 Claude Opus 5 在同一任务上的 493 TFLOPS，成本约后者的 1/8。
还有一个更小的例子：把一块 ESP32 开发板改造成"Vibe Coding 键盘"，连续执行 3 小时以上，自己访问串口、调摄像头、模拟鼠标、看报错改代码。
以及一个"自动化后训练"的例子：把 Qwen3-30B-A3B 的 AIME24 准确率从 53.3% 拉到 60%，消耗的标注 token 比 Opus 5 更少。
但请注意：这三个都是官方精心设计的演示场景。 你的业务代码库的杂乱程度，远超任何演示环境。
3.5 反证：1M 上下文会在真实项目里被很快用光
社区里有一条很具体的实测记录，来自一个做 N64 图形 Demo 的开发者。他的结论是"体验一言难尽"，问题集中在：
- 涉及图形管线、RSP/RDP 寄存器操作、内存对齐，模块间耦合紧；
- 用了没几轮，1M 上下文就见底了，然后模型开始重复之前的代码片段、把前面定义的变量名搞混；
- 让它调试跨文件 Bug 尤其容易崩；
- 最后他的做法是：任务拆到极小（一次只让它生成一段 RSP 微码），每次对话完立刻把关键代码存本地，并自己维护一份"核心定义 + 内存布局 + API 约定"的摘要贴在开头。
这条记录的价值在于它跟官方叙事的关系：它不否定续航能力，它标出了续航的边界——上下文压缩能救"长"，救不了"早期约定被压掉"。16 个寄存器名、一套内存对齐约定、一个显示列表结构，这些是"不可压缩"的，模型压缩时会当成冗余。
所以第五章的"能力剖面"里，我会把这个边界写成一条硬规则而不是一句提醒。
四、读这家的跑分，五条纪律
这一节是方法，不是结论。跳过它会误判。
纪律 1：High 档 vs Max 档，不是一个跑法
官方在对比图里标注：Step-5-Preview 跑在 High 推理档，对手跑在 Max effort 档。这是主动声明"不完全对等"。
怎么理解这个不对等？High 是它自己的第二高档（低配以上还有 xhigh 的说法，口径不一），用的是更少的思考预算。所以这个对比对它是偏严格的——用更少的算力跑出接近的分数。但也正因为档位不同，具体每一行的差距不能按小数点后一位去读。
纪律 2：自建评测占的权重不低，但要看清方向
它有两个自建榜：
- StepCodeBench：553 个独立仓库、9 类任务、20 个应用领域、33 种编程语言，得分 49.0（avg@4）；
- FinStepBench：实时检索、企业估值、深度研究三项。
"自家考场第一名"这个折扣要打。但这里有个反例值得记：
官方自报 SciCode 49.0，而 Artificial Analysis 独立测到 59%——独立测的比自报的高了 10 分。
所以"厂商自报一定注水"这个直觉也不总成立。正确做法不是"一律打折"，而是分组标注、不混合：自报的归自报，独立的归独立，永远别把两组数字做减法。
纪律 3：Terminal-Bench 2.1 和 4.0 差着量级，别混
这是最容易犯的错。同一个名字，两个版本：
| 模型 | Terminal-Bench 2.1 | Terminal-Bench 4.0 |
|---|---|---|
| Step-5-Preview | 85.0% | 33.3% |
| Qwen3.8-Max | 86.6%（厂商自报） | 34.3%（Vals 独立） |
| GLM-5.3 | 83.9% | 41.9% |
| Claude Opus 5 | 89.1% | 52.3% |
| GPT-6 Astra | 88.4% | 57.9% |
2.1 是 89 道精选终端任务的验证版；4.0 是 8 月 28 日才发的下一代终端 Agent 基准，难度完全另一档。
如果你看到有人写"Step-5-Preview 终端任务 85 分，跟 Opus 5 打平"——他看的是 2.1。如果他写"33 分，被 GLM 干掉"——他看的是 4.0。两个都是真的，说的是两件事。
纪律 4：自报和独立，一定要分开看
| 指标 | 数值 | 来源 |
|---|---|---|
| DeepSWE v1.1 | 67.7% | StepFun 自报 |
| Terminal-Bench 4.0 | 33.3% | StepFun 自报 |
| Terminal-Bench 4.0 | 31.82% | Vals AI 独立 |
| AA-LCR 长上下文推理 | 88.3% | AA 独立 |
| AA 智能指数 | 43.7 → 44 | AA 独立 |
| Vals Index | 49.35% | Vals 独立 |
| SRE Bench | 0.4% | Vals 独立 |
| Harvey 法律 Agent | 9.2% | Vals 独立 |
规律很清楚：它最强的那个数（长上下文 88.3）和最弱的两个数（SRE 0.4、Harvey 9.2），都来自独立第三方。 这说明第三方不是"专挑毛病"，而是真的测到了它够不到的地方。
纪律 5：分数一样，token 不一样——这条在本篇不是脚注，是主线
Artificial Analysis 在评测记录里明确写了它"very verbose"：跑完整套评测消耗约 1.6 亿输出 token，而同类中位数约 9000 万。
1.78 倍。
这个数字会在下一节直接把"42% 的单价便宜"全部吃掉。这也是为什么本篇要把"冗长"从"缺点"升级成"成本结构"。
五、算账：42% 的单价便宜，等于 1.74 轮容错
5.1 先把单价摆平
同一个 0.5× 格子里，两个模型的官方定价：
| 输入（元/百万） | 输出（元/百万） | 缓存命中（元/百万） | |
|---|---|---|---|
| Step-5-Preview | 7 | 20 | 0.35 |
| Qwen3.8-Max | 12 | 36 | — |
换算成比值：
- 输入：7 / 12 = 0.583（便宜 41.7%）
- 输出：20 / 36 = 0.556（便宜 44.4%）
- 缓存：0.35 / 7 = 1/20
单看这张表，Step-5-Preview 完胜。但表里缺了一个变量：你要买多少 token。
5.2 冗长系数把输出侧的便宜吃干净了
AA 的 1.78 倍不是"偶尔话多"，是系统性冗长。把两个数相乘：
输出单价 0.556 × 输出量 1.78 = 0.99
几乎正好 1.0。 也就是说：
Step-5-Preview 在输出侧根本不便宜，它只是把省下的钱都花在了多说 78% 的话上。真正的便宜全在输入侧（0.583）。
这句话是本篇最重要的一句，因为它直接决定了适用场景：
- 输入远大于输出的任务（读仓库、读长文档、跨文件理解）→ 真便宜；
- 输出远大于输入的任务（生成整页代码、写长文档、批量产出）→ 便宜被抹平；
- 输入输出都小、但要跑很多轮的任务（调 bug、试探性提问）→ 便宜被轮数吃掉。
5.3 单价优势 = 1.74 轮容错
这是我认为最该拿笔算一遍的地方。
假设一个跨文件重构任务，每轮输入 120K tokens、输出 20K tokens（含思考）：
- Qwen3.8-Max 每轮：120K × 12/1M + 20K × 36/1M = 1.44 + 0.72 = ¥2.16
- Step-5-Preview 每轮：120K × 7/1M + 20K × 20/1M = 0.84 + 0.40 = ¥1.24
- 比值：1.24 / 2.16 = 0.574
0.574 意味着：Step 每试一轮的成本，只有 Qwen 的 57.4%。
那么，如果 Qwen 一轮就改对了，而 Step 要两轮呢？
- Step 两轮：¥2.48
- Qwen 一轮：¥2.16
Step 已经贵了 15%。
三轮呢？¥3.72 vs ¥2.16，贵 72%。
于是得到一条可以背下来的公式：
容错轮数上限 = 1 / 0.574 ≈ 1.74 轮。
只要它比对手多试两轮，那 42% 的单价便宜就全部吐回去，而且倒亏。
这个结论比"单价便宜 42%"重要得多，因为**"多试一轮"恰恰是能力差 1 分时最可能发生的事**。1 分不是零，它会在边界 case 上以"再来一次"的形式收费。
5.4 三个真实算例
下面三个算例都用上面的单价，假设都在单次会话内完成，不算缓存。
算例 A：修一个单文件 Bug
- 输入 8K（代码 + 报错 + 两轮对话），输出 2K（思考 1.2K + 补丁 0.8K）
- Step：8K × 7/1M + 2K × 20/1M = 0.056 + 0.040 = ¥0.096
- Qwen：8K × 12/1M + 2K × 36/1M = 0.096 + 0.072 = ¥0.168
- Step 便宜 43%
小任务上，单价优势完整保留。但绝对金额都很小（不到两毛），所以在这个量级上，省钱不是选型理由，成功率才是。
算例 B：给一个模块补 200 个单测
- 输入总计 400K（首次读模块 40K + 十轮迭代累计 360K），输出 150K（大量测试代码）
- Step：400K × 7/1M = 2.80；150K × 20/1M = 3.00 → ¥5.80
- Qwen：400K × 12/1M = 4.80；150K × 36/1M = 5.40 → ¥10.20
- Step 便宜 43%
注意这里输出占比已经到 27%，但输入仍然是大头，所以省钱还在。这类"读多写多但一次成型"的任务，是 Step 最舒服的区间。
算例 C：跨 5 个文件的重构（含判断）
- 三轮迭代，每轮输入 120K（大量上下文重贴）、输出 20K
- Step 三轮：¥3.72；Qwen 一轮：¥2.16
这类任务里，"谁先想明白"比"谁单价低"重要一个数量级。重构的本质是做判断：改哪不改哪、接口怎么切、兼容层留不留。判断类任务应该交给分数更高的那一档。
5.5 缓存：长任务真正的省钱开关
这一条比选模型重要。
- Step-5-Preview 缓存命中 ¥0.35/百万，未命中 ¥7/百万；
- 相差 20 倍。
一个跨文件长任务的输入里，80% 是"同一份仓库上下文反复重贴"。如果这 80% 能命中缓存：
- 全价：120K × 7/1M = ¥0.84/轮
- 80% 命中：96K × 0.35/1M + 24K × 7/1M = 0.0336 + 0.168 = ¥0.20/轮
单轮输入成本降到 1/4。 这比"换个便宜 42% 的模型"有效得多。
所以真正的顺序应该是：
- 先让缓存命中（把仓库结构、接口约定、编码规范固定放在 prompt 前部，且保持稳定不抖动）；
- 再考虑降 effort（后面第八节讲）；
- 最后才是换模型。
5.6 自托管：650 GB 起步，中小团队直接劝退
官方最低配置是 FP8 单节点 4× B300 或 8× H200。
按公开云市场上 8 卡 H200 单节点的常见报价区间（约 ¥20–30/卡/小时，具体以你采购价为准）估算：
- 8 × 25 = ¥200/小时
- 24 小时满载 ≈ ¥4,800/天
- 30 天 ≈ ¥14.4 万/月
也就是说，只有当你的 API 账单每月稳定超过十几万，自托管才开始有意义——而这还没算上运维人力、模型更新（Preview 转正后权重会变）、以及"你必须自己扛住 1M 上下文的 KV 容量"。
反过来说：如果你一个月 API 花不到一万，自托管是个负收益的决定。 那个 650 GB 的 FP8 检查点，对绝大多数团队的价值是"可以微调/蒸馏"，不是"可以替代 API"。
六、能力剖面：五强、五弱
6.1 五强
① 长上下文推理：AA-LCR 88.3%
这是它最硬的一个数，而且来自独立第三方。长上下文推理测的不是"能不能塞进去"，是"塞进去之后还能不能正确推理"。88.3% 在当前公开数据里属于最高那一档。
② 长程软件工程：DeepSWE v1.1 67.7%
开源模型第一，逼近闭源第一梯队（Opus 5 74.0%、GPT-6 Astra 74.1%），比 Qwen3.8-Max 的 56.6% 高 11 个百分点。配套的还有 SWE-Marathon v1.1 72.7%（20 个多小时级真实任务，带隐藏/对抗测试）和 RoadmapBench 54.3%（115 个跨 17 个仓库、5 种语言的长任务，中位数改动约 3,700 行）。
③ 跨语言多仓库广度：ProgramBench 80.5%、StepCodeBench 49.0%
ProgramBench 是"给二进制和文档，把程序重建出来"，200 个任务、24.8 万个行为测试。80.5% 在开源里第一。StepCodeBench 虽然是自建，但 553 个仓库、33 种语言的覆盖度本身说明训练数据的广度。
④ 安全代码：CyberGym 84.7%
全表最高，超过 GLM-5.3 的 84.5% 和 Kimi K3 的 80.0%。这个榜测的是安全相关的 Agent 任务（漏洞定位、修复）。对一个旗舰模型来说，这项不常被讲，但很有用。
⑤ 金融与专业知识：FrontierFinance 66.4%、DRACO 83.3%
FrontierFinance 开源第一，落后 Opus 5（69.7%）3.3 个点；DRACO 83.3 超过 GLM（82.3）和 Kimi（78.5）。官方把金融当成重点场景押注，这一块的数据是真的。
6.2 五弱
① 运维排障：Vals SRE Bench 0.4%
这不是"弱"，这是基本不会。0.4% 意味着在 250 道题里对 1 道。如果你的任务里包含"看日志、定位故障、写 runbook、判断该重启还是回滚"，这个模型在这个区域几乎是空白。
② 法律/规范类：Harvey Legal Agent 9.2%
十道题对不到一道。法律文本的核心是"精确引用 + 不越界推断"，恰好踩在它"泛化弱、爱补全"的短板上。
③ 终端原生 Agent：Terminal-Bench 4.0 33.3%
比 GLM-5.3 的 41.9% 低 8.6 个点，比 Qwen3.8-Max 的 34.3%（Vals 独立）也略低。TB 4.0 测的是"在一个纯终端环境里连续操作"，跟"改代码"是两种能力。
④ 泛化与陌生工具：多家实测一致
一个有代表性的实测记录是：在数据可视化和金融这两块，它的理解力和数据检索能力都不错（能主动去统计局、国务院这种一手源交叉验证）；但在小众基准上——比如物理世界理解——表现明显不行；遇到没见过的工具会误用；核心问题是"它不知道怎么去学自己不会的东西"。
同一份实测还给了一个很具体的图表反例：让它把金额、ASP、出货量三个指标画在一张图上，它没有统一量纲，导致 ASP 的变化在图上几乎看不见（金额 13.30→35.76 十亿美元，ASP 0.39→0.60 美分，出货量 3,386→5,932 十亿颗）。这是典型的"能画出来，但没有数据直觉"。
⑤ 思考长度失控：思考∶输出常达 1:1
这是最隐蔽的一条，因为它不体现在任何跑分上，只体现在账单和超时上。
实测发现：在有强字数约束的任务里，思考长度会异常膨胀——思考内容与最终输出内容的比例经常达到 1:1 甚至更高，而且约束越严格越明显，因为模型会反复回去核对"我写的东西够不够/超没超"。
叠加 1M 上下文之后还有一个更糟的组合：长上下文 + 长思考 → 任务中断。
回想第三节那个"未对齐版本漂移成臃肿、无结构的单轮输出"——这是同一个病理在推理侧的表现。
6.3 评级表
| 能力维度 | 评级 | 依据 |
|---|---|---|
| 长上下文理解与推理 | S | AA-LCR 88.3%（独立） |
| 跨文件/多仓库长任务 | S- | DeepSWE 67.7、SWE-Marathon 72.7 |
| 读代码、答疑、结构梳理 | A | SWE-Atlas-QnA 63.6 |
| 写单测/测试代码 | A- | SWE-Atlas-Test-writing 50.8（Opus 5 为 60.3） |
| 多语言代码广度 | A | StepCodeBench 49.0、ProgramBench 80.5 |
| 安全漏洞类任务 | A | CyberGym 84.7（全表最高） |
| 金融/专业知识工作 | A- | FrontierFinance 66.4、DRACO 83.3 |
| 纯终端 Agent 连续操作 | C+ | TB 4.0 33.3% |
| 陌生工具/框架迁移 | C | 多家实测：误用、不会"学不会的东西" |
| 运维排障/SRE | F | Vals 0.4% |
| 法律/合规文本 | F | Harvey 9.2% |
| 成本可预测性 | C | 冗长 1.78×、思考失控 |
6.4 横向对照：把四个开源模型放进一张表
单看一个模型的分数没有意义，得看它在同一张表上的位置。下面这张表用的是第三方转录的厂商对比表数据（Step-5-Preview 跑 High 档，对手跑 Max 档，档位不对等这件事本身就是一行信息）：
| 指标 | Step-5-Preview | Qwen3.8-Max | GLM-5.3 | Kimi K3 | Opus 5（闭源锚点） |
|---|---|---|---|---|---|
| 总参 / 激活 | 600B / 27B | 2.4T / 95B | 753B / 未披露 | 2.8T / 104B | 未披露 |
| AA 指数（当前刻度） | 44 | 45 | 45 | 44 | 45 |
| DeepSWE v1.1 | 67.7 | 56.6 | 66.9 | 67.5 | 74.0 |
| Terminal-Bench 4.0 | 33.3 | 34.3* | 41.9 | 12.6 | 52.3 |
| Terminal-Bench 2.1 | 85.0 | 86.6* | 83.9 | 85.0 | 89.1 |
| SWE-Marathon v1.1 | 72.7 | — | 67.4 | 84.4 | 85.6 |
| ProgramBench | 80.5 | — | 72.0 | 77.8 | 82.3 |
| StepCodeBench | 49.0 | — | 40.2 | 43.9 | 63.9 |
| SciCode | 58.9† | 52.0 | 59.0 | 59.5 | 56.4 |
| CyberGym | 84.7 | — | 84.5 | 80.0 | — |
| FrontierFinance | 66.4 | — | 64.1 | 62.6 | 69.7 |
| GDPval-AA v2（Elo） | 1571 | 1739 | 1634 | 1548 | 1735 |
* Qwen3.8-Max 的 Terminal-Bench 数据分别是厂商自报（2.1）与 Vals 独立（4.0），与 Step 的自报口径并列时需注意来源不同。
† SciCode 存在两个口径：官方自报 49.0，独立测得 58.9–59%。表中取独立值，正文第四节已说明这个差异的方向。
从这张表能读出三件事：
第一，它的位置是"开源第二梯队的天花板"。 DeepSWE、ProgramBench、StepCodeBench、CyberGym、FrontierFinance 五项在开源里第一或并列第一，但每一项都被闭源锚点压着。这不是"追平 Opus 5"，是"把开源的天花板往上顶了一格"。
第二，它的形状很不均匀。 Terminal-Bench 4.0 被 GLM-5.3 拉开 8.6 个点，SWE-Marathon 被 Kimi K3 拉开 11.7 个点，但 DeepSWE 又反超这两家。同一类"改代码"的任务，三个基准三个排序——这说明没有任何一个基准能代表"编程能力"，只能代表"某种 harness 下的某种任务分布"。
第三，参数效率是真的。 600B/27B 打 2.4T/95B 和 2.8T/104B，DeepSWE 还更高。这条对自建团队有直接意义：如果你只是想微调一个"够用的编码 Agent 底座"，600B 的门槛比 2.8T 低一个数量级。当然，650 GB 的 FP8 也不是小数目——但那是 8 卡的事，不是 80 卡的事。
七、12 个真实任务：交给它，还是拦下来
| # | 任务 | 结论 | 理由 | 关键动作 |
|---|---|---|---|---|
| 1 | 单文件 Bug 修复 | ✅ 可以 | 便宜、够用、速度快 | effort=low，把复现步骤和报错原样贴全 |
| 2 | 给老模块补单测 | ✅✅ 强烈推荐 | 长上下文不切分 + 测试写作 A- | 先让它列"分支清单"，再逐个生成 |
| 3 | 跨 5 文件重构 | ✅ 推荐 | SWE-Marathon 72.7、不用反复重贴上下文 | 先要"改动点清单"，人工确认后再动手 |
| 4 | 全仓库理解/答疑 | ✅✅ 强烈推荐 | AA-LCR 88.3、SWE-Atlas-QnA 63.6 | 仓库结构固定放 prompt 前部，吃满缓存 |
| 5 | 框架大版本迁移（如 Spring Boot 2→3） | ⚠️ 谨慎 | 泛化弱、陌生 API 会编 | 一次只迁一个模块，每批人工验收 |
| 6 | 前端页面/可视化生成 | ✅ 可以 | 前端与可视化是官方主打方向 | 给它截图或设计稿，别只给文字描述 |
| 7 | 数据库 schema 设计 | ❌ 不首选 | 纯判断类，44 分不如更高档位 | 换判断力更强的模型，或人来定 |
| 8 | 并发/一致性方案评审 | ❌ 不首选 | 同上，且错一次代价指数级 | 让它"列出失败模式"，方案由人拍 |
| 9 | 生产事故排障 | 🚫 禁止 | Vals SRE Bench 0.4% | 人 + 监控 + 既有 runbook |
| 10 | 合规/法务文本 | 🚫 禁止 | Harvey 9.2% | 人 |
| 11 | 长文档/财报结构化 | ✅✅ 强烈推荐 | 1M + 多模态 + 金融 A- | 分章喂，交叉校验数字 |
| 12 | 定时脚本 / CI 配置 | ✅ 可以 | ProgramBench 80.5 | 小步改，本地先跑通 |
这张表有一条暗线：凡是"要它做判断"的，都打了❌；凡是"要它读很多、写很多、跑很久"的，都打了✅。 这不是巧合，是 44 分 vs 45 分 + 42% 单价 + 1M 上下文三者推出来的必然结果。
八、在飞算JavaAI 里怎么用：用 effort 当第二档
前面几篇双型号的文章，靠"Max 出判断、Flash 出实现"分档。这次只有一个模型，怎么办？
答案是：reasoning_effort 就是你的第二档。
0.5× 只有一个价格，但 effort 有三档（官方公开的是 low / medium / high，另有 xhigh 的说法）。同一格预算，你可以把它拆成三个成本档。而且因为输出价格包含 reasoning token（¥20/百万），effort 直接就是钱。
8.1 四阶段 × effort
| 阶段 | effort | 为什么 |
|---|---|---|
| 需求分析 | high | 判断类任务，上游错一步下游全废；这里省下的思考 token，会在返工里十倍还回去 |
| 前后端设计 | medium | 结构化输出为主（接口表、表结构、时序），模式固定，不需要长思考 |
| 前端开发 | low → medium | 组件化、可即时预览、迭代次数多；每次迭代都烧思考 token 不划算 |
| 后端开发 | low（复杂逻辑切 medium） | 调用次数最多，low 能显著压住输出 token；只有并发/事务这类才升档 |
一条经验：把 high 只花在"这一步错了后面全白干"的地方。 需求分析和方案评审是，写 CRUD 不是。
8.2 三段 prompt（可直接用）
分析型（配 high）
你是架构师，不是编码助手。这一轮不要写实现代码。
输出四件事：
1) 这个需求的真实目标（一句话）；
2) 失败模式清单：每条写「触发条件 / 后果 / 怎么检测」；
3) 你必须假设的前提，逐条标注【需验证】；
4) 你认为我不该做、但可能想做的方案，以及为什么。
不要输出"首先/其次/最后"式的套话。
实现型（配 low/medium）
严格按下面的规格实现，不要扩展、不要顺手重构。
只使用我给你的类名、方法名、配置项。
任何你没在上文见到的 API，先写 // TODO(需验证: xxx) 并停下问我，不要猜。
每改完一个文件就停下来，等我确认再动下一个。
自检型（任何档位，收尾用）
回答我之前，先自查三件事，各写一行：
1) 哪些是我在上下文里确认存在的？哪些是我推断的？
2) 如果这段代码跑不起来，最可能的原因是什么？
3) 我有没有回答你没问的问题？
8.3 三个"对症"prompt
治话痨（思考长度失控）
开始前用一句话复述目标，最多列 5 步计划，然后立刻开始。
不要反复核对字数、行数、字数限制。如果要求"不超过 N 行"，先写完，最后只压缩一次。
不要在中途总结你已完成的步骤。
治幻觉（陌生 API）
本次对话的可用 API 白名单如下（只列名字，不要补充）：
<粘贴你的工具类/框架真实方法名>
白名单之外的东西，一律标注【需验证】，不要直接使用。
如果你认为需要新增依赖，先问我。
治上下文压缩丢约束（长任务必用）
在继续之前，把下面五项各写一行，作为后续的唯一事实来源：
原始目标 / 已确认事实 / 已否决方案（含原因）/ 未解决问题 / 下一步。
之后如果上下文被压缩，只保留这五项，其余细节可以丢弃。
最后这一段其实是把它的"上下文压缩"变成你的人工检查点。模型自己决定压什么，你决定什么不能被压。这个分工很重要。
8.4 具体操作路径
在飞算JavaAI 智能会话里：
- 需求分析阶段选 Step-5-Preview，用分析型 prompt，输出落成一份
需求与失败模式.md； - 设计阶段继续用，medium，产出接口表 + 表结构 + 时序图，人工过一遍；
- 前端开发阶段降到 low，给它截图而不是文字描述（多模态是它的强项）；
- 后端开发阶段 low，复杂事务切 medium；每生成一个类立刻在本地跑单测，不要攒到最后一起跑；
- 每个阶段结束跑一次自检型 prompt，把"推断的"和"确认的"分开记。
第 4 步的"立刻跑"不是洁癖，是因为它的失败模式是"一路错下去直到上下文耗尽"，越晚发现，返工越贵。
九、代码实战：三个场景，三个边界
9.1 场景一：跨文件重构（适合，但要加护栏）
重构前：三个 Service 各写一遍相似校验。
// OrderService.java —— 另两个 Service 里也有一份几乎一样的代码
public void create(OrderCmd cmd) {
if (cmd.getUserId() == null || cmd.getAmount() == null) {
throw new BizException("PARAM_MISSING", "参数缺失");
}
if (cmd.getAmount().compareTo(BigDecimal.ZERO) <= 0) {
throw new BizException("AMOUNT_INVALID", "金额必须大于 0");
}
if (cmd.getAmount().compareTo(new BigDecimal("50000")) > 0) {
throw new BizException("AMOUNT_LIMIT", "单笔超限");
}
// ... 落库逻辑
}
给它的 prompt（关键在第一句）
不要直接改代码。先输出一张表：
| 文件 | 方法 | 校验片段的行号范围 | 是否与 OrderService 完全一致 |
只列出你在当前上下文里真正看到的调用点，不要推测。
输出完表格就停下，等我确认。
为什么先要表？ 因为它最容易翻的坑就是"漏掉第三个调用点"。而漏掉的原因很典型：上下文压缩把最早贴进去的那个文件压掉了，模型于是"记得有两个"。
确认之后的第二段 prompt
按下面的顺序改，一次只改一个文件：
1) 新建 OrderValidator 接口与三个实现类（ParamValidator / AmountValidator / AmountLimitValidator）；
2) 逐个 Service 注入 List<OrderValidator> 并删除原有校验；
3) 每改一个文件，输出该文件改动前后的行数对比。
不要改任何落库逻辑。
它会给什么
public interface OrderValidator {
void validate(OrderCmd cmd);
default int order() { return 0; }
}
@Component
public class AmountLimitValidator implements OrderValidator {
private static final BigDecimal LIMIT = new BigDecimal("50000");
@Override
public void validate(OrderCmd cmd) {
if (cmd.getAmount().compareTo(LIMIT) > 0) {
throw new BizException("AMOUNT_LIMIT", "单笔超限");
}
}
}
哪里会翻车
- 校验顺序变了（它可能把 limit 放到 param 前面）→ 报错码就变了，前端提示会错；
- 它会把
private static final BigDecimal换成@Value注入，理由是"可配置"——这是超出规格的扩展； - 三个 Service 的
List<OrderValidator>注入，它可能给你写成@Autowired字段注入而不是构造器注入。
怎么验收：跑一遍参数化测试，断言错误码而不是错误消息；git diff 逐文件看，只允许"删除校验、新增注入"两类改动。
9.2 场景二：补单测（最适合，注意别让它断言实现细节）
prompt
给 OrderService 补单元测试，要求：
- JUnit 5 + Mockito + AssertJ；
- 断言「行为与错误码」，不要断言私有方法调用次数；
- 用 @ParameterizedTest 覆盖金额边界：-1、0、0.01、49999.99、50000、50000.01；
- 每个用例名写成 should_xxx_when_yyy 形式；
- 不要 mock OrderValidator，用真实实现。
它会给什么（这是它擅长的部分）
@ParameterizedTest(name = "[{index}] amount={0} → {1}")
@MethodSource("amountBoundaryCases")
void should_reject_when_amount_is_out_of_range(BigDecimal amount, String expectedCode) {
OrderCmd cmd = OrderCmd.builder()
.userId(1L)
.amount(amount)
.build();
BizException ex = assertThatThrownBy(() -> service.create(cmd))
.isInstanceOf(BizException.class)
.asInstanceOf(type(BizException.class))
.extracting(BizException::getCode)
.isEqualTo(expectedCode);
}
static Stream<Arguments> amountBoundaryCases() {
return Stream.of(
Arguments.of(new BigDecimal("-1"), "AMOUNT_INVALID"),
Arguments.of(BigDecimal.ZERO, "AMOUNT_INVALID"),
Arguments.of(new BigDecimal("0.01"), null),
Arguments.of(new BigDecimal("49999.99"), null),
Arguments.of(new BigDecimal("50000"), null),
Arguments.of(new BigDecimal("50000.01"), "AMOUNT_LIMIT")
);
}
上面这段代码是我改过的。它原始给你的版本大概会长这样：
// 它容易给出的写法：断言调用次数，等于把实现细节焊死在测试里
verify(validator, times(1)).validate(any());
这类断言的问题是：你一旦把三个 Validator 合并成一个，测试就红了，但业务其实没错。这就是"断言实现细节"。
哪里会翻车
- 用不存在的 Mockito API（比如
Mockito.doAnswerReturning(...)这种听起来很合理但不存在的方法）； - 把
assertThatThrownBy和assertThrows混着写，风格不统一； - 边界值只给 0 和 50000，不给 50000.01。
怎么验收：先编译。编译不过一律不信任——它的幻觉在 API 名上出现频率最高，而编译器是最便宜的检测器。
9.3 场景三：并发扣减（不该交给它做判断）
这是一个典型的"看起来能写、其实判断错了会出事"的任务。
如果你直接问：“帮我把乐观锁改成 Redis 预扣 + 对账”，它会给出一段 Lua：
-- KEYS[1] = stock:{skuId} ARGV[1] = 扣减数量
local stock = tonumber(redis.call('GET', KEYS[1]) or '-1')
if stock < 0 then return -1 end -- 库存未初始化
if stock < tonumber(ARGV[1]) then return 0 end -- 不足
redis.call('DECRBY', KEYS[1], ARGV[1])
return 1
这段是对的。但它不会主动告诉你缺什么：
- 预扣成功后、订单落库失败时，谁负责回补？回补失败进哪张补偿表？
- Redis 主从切换丢的那几笔，靠什么对账？对账窗口多长？
- 库存回补和并发扣减撞在一起时，
GET+DECRBY之间有没有窗口？（Lua 保证了原子，但你如果用WATCH/MULTI就没有） - 超卖 1 件和少卖 1 件，哪个业务上更不可接受？
这四个问题都是判断，不是实现。它的 SRE/一致性判断能力不在评级表的高分区。
正确用法：让它列失败模式，不要让它给方案。
不要给实现。只输出失败模式清单，每条写：场景 / 后果 / 检测手段 / 是否可以接受。
范围：Redis 预扣 + 异步落库 + 定时对账 这条链路上所有可能不一致的地方。
它给的清单通常能覆盖 60–70%，剩下的 30% 由人补——这个比例的分工是划算的：它省了你一下午的头脑风暴，但方案仍由你拍。
9.4 场景四：截图转页面（多模态的正确用法，也是最容易被低估的一项）
它的输入支持图像，也支持分析截图、图表、UI 稿。这一项在官方定位里写得很明确（“前端与可视化开发”），但很多人在飞算JavaAI 里只贴文字需求，等于把这半个能力闲置了。
正确姿势：不要描述页面，直接给图，并把"不要做什么"写死。
按这张后台列表页截图，生成一个 Vue 3 + Element Plus 的单文件组件。
约束（违反任意一条都算不合格）：
1) 只实现截图里看得见的结构，不要补搜索框、不要补分页器、不要补"更多操作"下拉；
2) 图标只用 Element Plus 自带的，不要引入新的图标库；
3) 所有文字、颜色、间距从截图里抄，不要"优化"；
4) 尺寸不确定的地方写成 CSS 变量并在注释里标 // TODO(需确认: 实际值)，不要硬编一个看着像的数字。
先输出组件的 DOM 结构（缩进树，不带样式），等我确认后再写样式。
它会给什么：通常能准确还原信息层级、表格列的顺序、按钮的语义分组（主操作靠右、危险操作用红色），这一步它比大多数人手写快得多。
哪里会翻车
- 栅格靠猜：截图里的 12 / 16 / 24 px 间距它会给你 15、18、22 这种"看着像"的值；
- 响应式靠猜：它会主动加
@media，而你的后台根本不需要移动端； - 补全冲动：截图里没有的"批量删除"“导出"它经常顺手加上，理由是"列表页通常都有”；
- 图标幻觉：
el-icon-export、el-icon-batch这类名字听起来非常合理，但 Element Plus 里没有。
怎么验收：不是读代码，是截图对比。同一个视口宽度（比如 1440）、同一个缩放，把生成页面和你原截图并排放大到 200%，比对三个东西——列宽比例、行高、按钮组右对齐的边距。三个都过，再谈代码质量。
这一项为什么值得单独讲：它是"输入远大于输出"的典型场景（一张图 + 一段约束 → 一个组件），正好落在它最便宜的区间；而且视觉类任务的错误人眼一秒能看出来，验收成本极低。这是"能力—成本—验收成本"三者同时占优的少数场景之一。
十、选型 SOP：五步，加一份私有题集
10.1 五步
第一步：先确认尺子
在任何对比之前，问三个问题：
- 这个分数是 9 月 7 日之前还是之后？（AA 刻度）
- 官方跑的是 High 还是 Max effort？
- 是 Terminal-Bench 2.1 还是 4.0？
三个问题有一个没答上来，这个对比就先别做。
第二步：算"每完成一个任务"的钱，不算"每百万 token"的钱
公式：
单任务成本 = (输入 token × 输入单价 + 输出 token × 输出单价 × 冗长系数) × 轮数
Step-5-Preview 的冗长系数按 1.78 起算（AA 口径），轮数按你自己的历史数据。
第三步：用你自己的 30 道题跑一遍
别人的榜告诉你它能不能，你自己的题告诉你它在你这里能不能。题集按 10 类 × 3 难度组：
| 类别 | 简单 | 中等 | 困难 |
|---|---|---|---|
| 单文件 Bug | 空指针 | 边界条件 | 并发时序 |
| 补单测 | 简单 POJO | 带 Mock | 异步/事务 |
| 跨文件重构 | 2 文件 | 5 文件 | 5 文件 + 接口变更 |
| 老代码理解 | 单类 | 单模块 | 跨模块调用链 |
| 前端页面 | 静态页 | 带状态 | 带异步 + 图表 |
| 迁移改造 | 改注解 | 改 API | 改架构 |
| 长文档结构化 | 10 页 | 50 页 | 200 页 + 图表 |
| 报错定位 | 单栈 | 多栈交叉 | 日志缺失 |
| 性能问题 | 明显 N+1 | 索引缺失 | 锁竞争 |
| 安全修复 | 硬编码密钥 | SQL 注入 | 越权 + 反序列化 |
注意最后两类：报错定位和安全修复的"困难"档，大概率是它翻车的地方——前者对应 SRE 0.4%，后者虽然 CyberGym 84.7% 很高，但"越权 + 反序列化"这种需要业务语义判断的场景，它的强项用不上。
第四步：区分"能力不足"和"耐力不足"
这一步能省掉大量误判：
| 症状 | 真实原因 | 对策 |
|---|---|---|
| 一开始就对不上 | 能力不足 | 换模型 |
| 前 5 轮很好，第 15 轮开始飘 | 耐力不足（压缩丢约束） | 加"五项摘要"检查点 |
| 越改越乱、重复贴老代码 | 上下文见底 | 拆任务，一次一个文件 |
| 输出被截断/任务中断 | 长上下文 + 长思考 | 降 effort，或分段落盘 |
| 报错码/字段名编造 | 幻觉 | 白名单 + 编译即验 |
这张表的价值：五种症状里只有第一种该换模型，另外四种换 harness 就能解。 大多数人一遇到问题就换模型，其实是把可修的问题当成了能力天花板。
第五步：定退出条件
在开始用之前就写下来：
- 连续 N 个任务需要超过 1.74 轮才能过 → 换回判断力更强的档位；
- 单任务成本超过 ¥X → 降 effort 或拆任务；
- 出现一次"编造的 API 进了主干" → 立刻停用它的实现型任务，只留分析型。
10.2 一个 effort 决策树
这一步错了，后面是否全部白干？
├── 是 → effort = high
│ └── 输出是否超过 3000 token？
│ ├── 是 → 拆成两轮，先出纲要再展开
│ └── 否 → 直接跑
└── 否 → 这一步是否需要"想清楚再动手"？
├── 否（照规格实现） → effort = low
│ └── 是否涉及并发/事务/权限？
│ ├── 是 → medium
│ └── 否 → 保持 low
└── 是（要权衡方案） → effort = medium
└── 是否涉及跨模块接口变更？
├── 是 → high
└── 否 → medium
10.3 把 30 题跑成一张表，而不是一个印象
"感觉它行不行"是最贵的判断方式。三十道题，每题记四个数，一天就能跑完：
# eval_step5.py —— 跑你自己的 30 题，输出"每任务成本 + 轮数"
import csv, json, time
from openai import OpenAI
BASE = "https://api.stepfun.com/v1"
IN_PRICE, OUT_PRICE = 7 / 1_000_000, 20 / 1_000_000 # 元/token，官方价
client = OpenAI(api_key="YOUR_KEY", base_url=BASE)
rows = []
for case in csv.DictReader(open("cases.csv", encoding="utf-8")):
# cases.csv 字段：id, category, difficulty, prompt, max_rounds
rounds, cost, ok = 0, 0.0, False
history = [{"role": "user", "content": case["prompt"]}]
while rounds < int(case["max_rounds"]) and not ok:
rounds += 1
t0 = time.time()
resp = client.chat.completions.create(
model="step-5-preview",
messages=history,
temperature=1.0, top_p=0.95,
extra_body={"reasoning_effort": case.get("effort", "low")},
)
u = resp.usage
cost += u.prompt_tokens * IN_PRICE + u.completion_tokens * OUT_PRICE
out = resp.choices[0].message.content or ""
# 你的验收函数：编译过 / 测试绿 / 断言命中，三者取其一
ok = validate(case["id"], out)
history.append({"role": "assistant", "content": out})
if not ok:
history.append({"role": "user", "content": "上面的结果没通过校验，错误信息：" + last_error()})
rows.append({
"id": case["id"], "category": case["category"],
"difficulty": case["difficulty"], "rounds": rounds,
"cost_yuan": round(cost, 4), "ok": ok,
"seconds": round(time.time() - t0, 1),
})
with open("result.csv", "w", newline="", encoding="utf-8") as f:
w = csv.DictWriter(f, fieldnames=rows[0].keys()); w.writeheader(); w.writerows(rows)
# 三个关键聚合：通过率 / 平均轮数 / 每成功任务成本
passed = [r for r in rows if r["ok"]]
print("通过率", len(passed) / len(rows))
print("平均轮数", sum(r["rounds"] for r in rows) / len(rows))
print("每成功任务成本", sum(r["cost_yuan"] for r in rows) / max(len(passed), 1))
这份脚本只有一处"聪明"的地方：把 rounds 记下来，并且用"每成功任务成本"做聚合，而不是"每百万 token 成本"。
因为前面算过，单价差 42% 只等于 1.74 轮容错。当你的平均轮数从 1.2 涨到 2.1 时，单价优势就归零了——而这个变化在"每百万 token 成本"这个指标上完全看不出来。
跑完这张表，你会得到三类结论之一：
- 通过率高、轮数低 → 直接放进主力位，把 effort 往下调一格再跑一遍，看能不能白拿 30%；
- 通过率高、轮数高 → 能力够但"想不清楚"，加"五项摘要"检查点，或者把任务再拆小；
- 通过率低 → 别在 prompt 上继续挣扎了，这不是 harness 问题。
十一、六个误区
误区 1：“44 < 45，所以别用”
1 分在当前刻度上是噪声级差距，而且是不同 harness、不同 effort 下的 1 分。真正该拿来决策的不是这 1 分，是你的任务落在哪一列。
但反过来也要说清楚：在纯判断类任务上（schema 设计、方案评审、一致性取舍），1 分该被当回事，因为那里的错误成本是指数级的，而"多一轮"根本无法挽回一个错的设计。
误区 2：“1M 上下文 = 能塞 100 万 token 的代码”
两个错：
- 稀疏全注意力层每个查询只选 4096 个历史 token（覆盖率 78.06%），窗口大不等于注视范围大；
- 上下文压缩是模型自己决定压什么的，早期约束最容易被当成冗余。
正确用法：窗口大是为了"少切换会话"，不是为了"一次塞完"。
误区 3：“AA 说成本只有 1/8，换过去省 87%”
那个 1/8 是跨档位对比：Step-5-Preview 单任务 $0.71 左右，对比的是 Claude Opus 5 那一档。而在飞算JavaAI 的这张表里，跟你抢同一格预算的是同标 0.5× 的 Qwen3.8-Max，两者单价差 42%，输出侧被 1.78 倍冗长吃平，容错只有 1.74 轮。
1/8 是"跟更贵的对手比"，42% 是"跟同格的邻居比"。这两个数不能互换。
误区 4：“开源 = 我能自部署”
650.32 GB 的 FP8 检查点、最低 4× B300 或 8× H200、许可不是 Apache 2.0 而是 StepFun Model License 1.0，外加"BF16 分片流程尚未端到端验证"。对绝大多数团队，开源的真正价值是可微调、可蒸馏、可审计，不是"可替代 API"。
误区 5：“22 小时 demo = 生产可用”
那 22 小时是官方精心设计的单任务闭环：目标明确、可自动度量（吞吐）、可自动回滚（方案退化就退回最优版本）。你的生产环境里没有"自动回滚到最优版本"这个东西，也没有一个客观的 TFLOPS 告诉你现在这版好不好。
生产要的不是"能连续跑 22 小时"，是能停、能查、能回滚。这三件事它一件都不负责。
误区 6：“SRE 0.4% 跟我没关系”
只要你有一个环节是"看日志/看监控/判断该重启还是回滚/写 runbook"，你就踩在这个坑里。很多团队以为自己不做 SRE，其实他们每天在做的是"报错定位"，那正是 SRE Bench 测的东西。
（补一个）误区 7：“Preview 会一直这么便宜”
Preview 是个有保质期的状态。前面 MiniMax-M3 那篇已经讲过一次"折扣有保质期"，这次是同一个问题的另一种形式：能力会变（权重还会更新）、倍率会变（转正后重定价）、许可会变（现在是 1.0 版）。
所以别把架构决策建在"它现在 0.5×"这个前提上。把它当成一个试用窗口：在这个窗口里把私有 30 题跑完，把结论沉淀成"什么任务交给耐力型模型"，模型换了结论还能用。
11.1 Preview 转正时，这五件事必须重跑
Preview 早晚会转正。转正那天，下面这些东西全都可能变，而它们恰好是你决策的全部输入：
| 要重跑的东西 | 为什么会变 | 变了会怎样 |
|---|---|---|
| 平台倍率 | 转正后重新定价 | 0.5× 可能变 0.8×，1.74 轮容错直接掉到 1.0 轮 |
| AA 指数 | 权重可能更新、基准会重校准 | 44 可能变 41 也可能变 47 |
| effort 档位行为 | 官方调整思考策略 | 治话痨的 prompt 可能失效 |
| 上下文压缩策略 | 训练目标变了 | 你现在维护的"五项摘要"可能变得多余或不够 |
| 许可条款 | Model License 1.0 → 后续版本 | 商用/月活/收入门槛可能收紧 |
下面这三件事不会变，可以沉淀成长期资产：
- 你私有 30 题的题目与验收函数（模型换了照样能用）；
- "判断类 vs 长任务"这条任务分类法；
- "每成功任务成本 + 平均轮数"这个度量口径。
选型的终点不是"选对一个模型"，是"建起一套换了模型还能用的判断流程"。 这句话在系列里已经出现过一次，这次换个说法：别把结论存成模型名，存成规则。
十二、结论：三句话
第一句：0.5× 买的是"续航"，不是"智商"。
智能上它和同格的 Qwen3.8-Max 是 44 对 45，一分之差；它真正的差异项是 1M 上下文 + AA-LCR 88.3% + 22 小时连续自主迭代 + 100 tok/s。这些能力解决的是"跑不完"，不是"想不明白"。
第二句：它便宜，但便宜只在输入侧，而且只够你多试 1.74 轮。
输出侧 44% 的单价优势被 1.78 倍的冗长吃平（0.556 × 1.78 ≈ 0.99）。真正的省钱来自"读得多"——长上下文、少切换、缓存命中（¥0.35 对 ¥7，20 倍）。所以先优化缓存，再降 effort，最后才谈换模型。
第三句：长任务交给它，短判断交给别人，验收永远留给人。
- 交给它：全仓库理解、跨文件重构、补单测、长文档结构化、前端页面；
- 别交给它：schema 设计、一致性方案、生产排障、合规文本、陌生框架迁移；
- 永远自己做：验收。因为它的失败模式是"一路错下去直到上下文耗尽"，而唯一能在中途喊停的是人。
如果非要用一句话给这格预算定性：
它是这台表上唯一一台"能连续跑一夜"的柴油机。柴油便宜、扭矩大、能拉重货；但它启动慢、油耗按负载走、而且在两种路上会直接熄火——一种叫运维，一种叫法务。
押它之前，先确认你要拉的是重货，不是要飙车。
数据来源与说明
一、官方来源（StepFun）
- 模型规格：600B 总参 / 27B 激活 / 92 层 / 1M 上下文 / 最大输出 1M / 输入文本+图像，来自 Hugging Face 模型卡与 ModelScope 页面（ModelScope 文件体积标 604.34B，FP8 检查点 650.32 GB）；
- 架构细节：门控滑动窗口与稀疏全注意力 3∶1 交错；Sparse GQA 块大小 B=8、top-k k=4096（512 块），索引与 top-k 开销降至 1/8，token 覆盖率 78.06%（对照 B=1、k=2048 为 79.09%）；MTP-3 投机解码约 +30% 端到端；原生 FP8 MoE 约 +20%；KV 容量扩大 8–12 倍；
- 训练：FP8 混合精度、百万级可验证环境、上下文压缩纳入端到端策略训练、逐位对齐（staleness=0 时 logprob 差异为 0、开销 <10%）、路由与候选集回放、lifecycle ledger 样本丢失 <1%；
- 官方跑分（High 推理档，DeepSWE 用 SWE-agent harness，temperature=1.0、top_p=0.95）：DeepSWE v1.1 67.7、Terminal-Bench 4.0 33.3、Terminal-Bench 2.1 85.0、ALE-CLI 29.5、GPQA Diamond 93.5、HLE 46.5、SWE-Marathon v1.1 72.7、RoadmapBench 54.3、SciCode 49.0、ProgramBench 80.5、CyberGym 84.7、SWE-Atlas-QnA 63.6、SWE-Atlas-Test-writing 50.8、MLS-Bench-Lite 40.5、StepCodeBench 49.0（avg@4）、FrontierFinance 66.4、DRACO 83.3、GDPval-AA v2 1571；
- 长任务演示：GPU kernel 自主优化约 22 小时达 508 TFLOPS（对照 Opus 5 的 493）、ESP32 改造键盘连续 3 小时以上、Qwen3-30B-A3B 的 AIME24 从 53.3% 提到 60%；
- 部署：FP8 需 4× B300 或 8× H200 单节点；BF16 需 8× B300 单节点或 16× H200 两节点；vLLM/SGLang 提供 OpenAI 兼容 Docker 镜像，Blackwell 上专家并行走 MegaMoE；Transformers 仅离线生成；
- 推荐推理参数：temperature=1.0、top_p=0.95、top_k=0；
- 定价：国内 ¥7 / ¥20 / 缓存 ¥0.35（每百万 token）；国际 $1.00 / $2.70 / 缓存 $0.10；输出价格包含 reasoning token。
二、第三方独立评测
- Artificial Analysis（经 OpenRouter）：智能指数 43.7（取整 44）、AA-LCR 88.3%、HLE 46.5%、GDPval-AA 54.3%、输出速度 99.8 tok/s、首 token 2.96 s、跑完整评测消耗约 1.6 亿输出 token（同类中位数约 9000 万）、明确标注"very verbose"；
- Vals AI：Vals Index 49.35%、每题成本约 $2.63、单题延迟约 70 分钟、Terminal-Bench 4.0 31.82%（总榜第 13、开源第 3）、SRE Bench 0.4%、Harvey 法律 Agent 9.2%；
- OpenRouter：截至 10 月 15 日前后，Token 用量位列周榜与日榜全球第二（第三方转述，未取得原始看板）；
- OrcaRouter 对比文：记录 AA 指数版本史（Qwen3.8-Max 首发 53 → 撤回 → 重跑 56 → 被引作 58 → 9 月 7 日重校准后 45），以及"同为 0.5× 档位下两者单位指数点成本差约 7 倍"的结论。
三、社区实测
- 泛化与陌生工具：多份实测一致反映"在小众基准（如物理世界理解）上表现不佳、遇陌生工具会误用、缺乏’学习自己不会的东西’的能力"；
- 思考长度：有强字数约束的任务里，思考与输出比常达 1:1 甚至更高，约束越严越明显；长上下文叠加长思考易导致任务中断；
- N64 图形 Demo：1M 上下文在数轮对话内耗尽，出现重复代码、变量名混淆、跨文件调试失败，作者的最终做法是"任务拆到极小 + 自维护关键约定摘要"；
- 投行报告生成：整体完成度可接受，但多指标同图时未统一量纲（金额 13.30→35.76 十亿美元、ASP 0.39→0.60 美分、出货量 3,386→5,932 十亿颗），导致 ASP 变化在图上不可见。
四、口径冲突（8 条，本文的处理方式）
- 权重开放日期：10 月 14 日 / 10 月 15 日 / 10 月 17 日三种说法并存 → 本文统一写"10 月 14–17 日陆续上线"；
- 总参数量：官方 600B vs ModelScope 文件 604.34B → 以 600B 为口径，文件体积单列；
- AA 智能指数：43.7 vs 44 → 同一数字的不同呈现（取整），本文两处并存并标注；
- 视频输入：官方 ModelScope 卡写"文本、图像"，第三方整理的 HF 卡写"文本、图像、视频（≤128 MB、≤5 分钟）“，另有信源写"视频由 API 侧补充” → 本文按"文本+图像原生，视频待确认"处理；
- 许可证名称：StepFun Model License 1.0 vs StepFun Community License → 两者均非 Apache 2.0，具体条款以官方 LICENSE 文件为准；
- GDPval 呈现：54.3%（百分比）vs 1571（Elo）→ 两种呈现方式，不可混用；
- effort 档位：官方文档 low/medium/high，第三方模型卡写 low/medium/high(xhigh) → 本文按"三档 + 可能存在的更高档"处理，并提示未见"完全关闭思考"的档；
- SciCode：官方自报 49.0 vs AA 独立 59% → 差距 10 分，且方向是"独立测的更高"，本文两组分别标注、不做平均。
五、关于成本口径的两点说明
- 飞算JavaAI 模型框里的
0.5×、1.0×是平台内部倍率，其对应的货币含义未公开。本文对倍率只做相对比较（同一张表内两个同为 0.5× 的模型），不把它折算成具体金额； - 文中的单任务成本算例基于公开官方单价 + 假设的 token 结构（每轮输入 120K / 输出 20K 等），假设部分已在正文标明。你的实际结构不同，绝对值会不同，但"1.74 轮容错"这个比值结论只依赖单价比（0.574），不受 token 绝对值影响。
一句话方法论：能算的算清楚，不能算的说明白。 本文所有"本文给不出确定答案"的地方，都写在上面这八条里了。
扫一扫
885
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
