1. 为什么我决定用真实编程任务来测 Step 5 Preview

模型发布看跑分这件事，我早就审美疲劳了。SWE-bench 刷到 70% 也好，HumanEval 逼近满分也罢，落到我自己的日常编码场景里，经常是另一回事。所以拿到 Step 5 Preview 的第一时间，我没去翻它的技术报告，而是直接开了两个我平时真会遇到的编程任务，一个偏算法实现，一个偏工程改造，跑完再说结论。

这篇文章面向的是和我一样、每天真的在用 AI 编程助手写代码的人。你可能正在 Cursor、Windsurf、Copilot、Trae 之间反复横跳，也可能在纠结要不要给项目换一个模型后端。我想聊的不是"这个模型有多强"，而是"它在真实任务里到底靠不靠谱、上下文给够之后表现如何、MoE 架构对实际使用有什么影响"。这些才是决定我要不要把它放进日常工作流的关键。

Step 5 Preview 是阶跃星辰推出的新一代模型，采用了 MoE（混合专家）架构，官方给出的上下文窗口相当可观。但架构参数是一回事，实际写代码是另一回事。MoE 架构意味着推理时只激活部分专家，理论上能在保持能力的同时降低单次推理成本，但这也带来一个大家常问的问题：MoE 架构要全部参数进显存吗？这个我后面会专门拆开讲，因为它直接关系到你能不能在自己机器上跑、以及 API 调用的成本结构。

我选的两个任务，一个是经典的杨辉三角倒推输出，看着简单，实则对模型的边界处理、格式对齐、循环逻辑要求很细；另一个是多文件工程里的上下文改造任务，专门用来压测它的长上下文理解能力。两个任务一短一长，一小一大，正好能把 Step 5 Preview 的能力边界摸个大概。

2. 任务一：用倒推法求杨辉三角并输出

2.1 任务描述与我的真实意图

这个任务的原始描述是这样的：在编辑器的 begin-end 处补充代码，完成"用倒推法求杨辉三角并输出"。平台会对代码进行测试，比对输出数值与正确数值，只有所有数据全部计算正确才能通过。测试输入是 3，代表杨辉三角的总行数，预期输出是居中对齐的三行：

1 1 1 1 2 1

注意这里的空格数量，预期输出里每一行的数字之间是有固定间距的，而且整体呈金字塔状居中。很多人第一眼看到"倒推法"会懵，因为杨辉三角的常规解法是正推——从第一行往下，每行由上一行相邻两数相加得到。倒推法是什么意思？

我的理解是：不依赖上一行递推，而是直接根据组合数公式 C(n,k) 计算第 n 行第 k 个位置的值，然后从最后一行往上构造，或者从目标行反推。但更常见的"倒推"在算法题语境里，指的是先确定最后一行，再逐行向上推导。不过对于杨辉三角这种对称结构，正推和倒推在结果上没区别，区别在于代码组织方式和思维路径。

我故意选这个任务，是因为它是个"陷阱题"。看起来简单，但真正让 AI 写的时候，格式对齐、空格数量、循环边界这三样里必有一坑。跑分高的模型未必能一次过，因为它考的不是算法难度，而是对输出格式的精确控制。

2.2 我喂给 Step 5 Preview 的提示词

我没有直接把题目原文丢进去，而是按我平时用 AI 编程助手的习惯，给了一段结构化的提示词。这里插一句，提示词工程和上下文工程在编程场景里真的不是玄学，你给的信息越结构化，模型越不容易跑偏。

我的提示词大致是这样组织的：

• 先说明任务背景：这是一个在线编程平台的题目，需要补全 begin-end 之间的代码
• 明确输入输出：输入一个整数 n 表示行数，输出 n 行杨辉三角，居中对齐
• 给出格式样例：把 n=3 的预期输出原样贴进去，包括空格
• 强调约束：必须用倒推法思路，不能直接套用标准递推
• 要求：给出完整可运行代码，并解释关键步骤

我特意把格式样例贴进去，是因为我踩过太多次坑——AI 写出来的逻辑对，但输出格式和平台预期差一个空格就全挂。上下文里带上精确样例，比任何文字描述都管用。

2.3 Step 5 Preview 给出的代码与我的分析

它返回的代码核心逻辑是这样的（我整理成 Python，方便阅读）：

def yanghui(n): # 倒推：先构造最后一行，再逐行向上 rows = [] # 从第 n 行开始，用组合数直接算 for i in range(n - 1, -1, -1): row = [] for j in range(i + 1): # 组合数 C(i, j) val = 1 for k in range(j): val = val * (i - k) // (k + 1) row.append(val) rows.append(row) rows.reverse() # 格式化输出 max_width = len(' '.join(str(x) for x in rows[-1])) for row in rows: line = ' '.join(str(x) for x in row) print(line.center(max_width))

先说结论：逻辑是对的，组合数计算没问题，倒推的思路也体现出来了——它是从最后一行开始算，算完再 reverse。但格式这块，它用了center()居中，而平台预期的是左填充空格到固定宽度。这两者在 n=3 时结果可能碰巧接近，但 n 大一点就会错位。

我实测跑了一下，n=3 时它的输出是：

1 1 1 1 2 1

和预期对比，预期是每行前面有更多空格，整体更靠右居中。差异出在max_width的计算上——它用最后一行拼接后的长度作为总宽，但预期格式里数字之间的间距和行首缩进规则不一样。

这里就体现出"跑分"和"真实任务"的差距了。模型算法能力没问题，但它对"平台预期格式"这种隐含约束的把握，需要你在上下文里给足信息。我后来把预期输出的空格用·显式标出来重新问了一遍，它第二次就改对了，用了手动计算缩进的方式：

for i, row in enumerate(rows): indent = ' ' * (2 * (n - i - 1)) print(indent + ' '.join(str(x) for x in row))

2.4 这个任务暴露的三个关键点

第一，格式约束必须显式化。AI 编程助手再强，也猜不到某个平台特有的输出格式。你把样例里的空格用可见字符标出来，通过率立刻上去。这是我在用任何 AI 编程工具时的铁律。

第二，"倒推法"这类非标准要求要单独强调。模型默认会走最熟悉的路径（正推递推），你不说清楚，它就按自己的来。提示词里明确"必须用倒推思路"，它才会调整。

第三，上下文里的样例比描述更有效。我对比过，只写"居中对齐"四个字，模型十次有三次格式不对；贴上精确样例，基本一次过。这就是上下文工程在编程场景里的实际价值。

3. 任务二：多文件工程里的上下文改造实测

3.1 为什么我要专门压测长上下文

第一个任务太短了，几百 token 就搞定，根本压不出 Step 5 Preview 的上下文能力。而我日常最头疼的场景，是在一个有几万行代码的项目里做改造——比如给一个模块统一加上日志、把某个 API 的调用方式批量替换、或者重构一个跨多文件的函数签名。这种任务对模型的上下文窗口和理解能力是真正的考验。

现在市面上 1M 上下文已经全量可用了，Claude Code 也主打 1M 上下文，但"窗口大"和"用得好"是两码事。上下文工程的核心不是塞得越多越好，而是塞得准。我这次的任务设计成：给 Step 5 Preview 一个约 8000 行的中型项目片段，要求它找出所有直接调用某个旧函数的地方，并改成新函数签名，同时保持调用处的参数顺序正确。

3.2 任务设置与上下文组织方式

我准备的项目结构大致是这样：

• 一个services/目录，下面有 12 个业务模块文件
• 一个utils/目录，放着被调用的工具函数
• 一个api/目录，是接口层
• 总共约 8000 行，涉及 40 多个文件

旧函数签名是process_data(data, options)，新签名改成process_data(data, config, options)，中间插了一个config参数。这个改动看着小，但调用处如果参数顺序搞错，运行时才报错，非常隐蔽。

我把上下文组织成三部分喂进去：第一部分是工具函数的定义文件，让模型知道新旧签名；第二部分是所有调用点的文件列表和行号（我提前用 grep 找好的）；第三部分是每个调用点前后各 20 行的代码片段。我没有把整个项目全塞进去，因为那样反而会稀释注意力。

提示：长上下文不是垃圾桶，塞得越满模型越容易在无关代码里迷失。精准定位 + 局部上下文，比全量灌入效果好得多。

3.3 Step 5 Preview 的表现与我的评估

它一次性处理了 40 多个调用点，我逐个核对下来，正确率大概在 90% 左右。错的几个集中在两种情况：一是调用处用了*args展开传参，它没识别出来；二是有的地方options本身是个变量名，它误判成了字面量。

这个成绩说实话超出我预期。我之前用某些模型做类似任务，超过 20 个调用点就开始"幻觉"，要么漏改，要么改错参数顺序。Step 5 Preview 在 8000 行上下文里保持这个准确率，说明它的长上下文理解确实下了功夫。

但我也发现一个现象：当我把上下文从 8000 行加到 20000 行时，它的准确率反而下降了。这印证了我一直以来的判断——上下文窗口大不等于长上下文能力强，中间信息丢失（lost in the middle）的问题在超长上下文里依然存在。所以我的做法是，无论模型标称多大窗口，我都尽量把关键信息放在上下文的开头和结尾，中间放次要内容。

3.4 MoE 架构对实际使用的影响

聊到这里必须说说 MoE 架构。很多人问 MoE 架构要全部参数进显存吗？答案是：不需要。MoE 的核心思想是把一个大模型拆成多个"专家"子网络，每次推理只激活其中一小部分。比如总参数 100B，但每次只激活 20B，那么显存占用和计算量都按激活的部分算，而不是全部。

这对我们实际使用意味着什么？第一，同样的显存能跑更大的模型，因为激活参数少；第二，推理速度更快，因为计算量小；第三，但训练和部署时，所有专家的参数还是得存着，只是不全部参与计算。所以如果你是自己部署，显存要能装下全部参数；如果你是调 API，那成本按激活参数算，相对便宜。

Step 5 Preview 用 MoE 架构，在编程任务上的表现说明它的专家分工里，应该有专门处理代码和长文本的专家。这也是为什么它在两个差异很大的任务上都能接得住——不同任务激活不同专家，各司其职。

4. 两个任务跑完，我总结的实操经验

4.1 提示词怎么写才能让 AI 编程助手少犯错

两个任务跑下来，我对"AI 编程提示词"这件事有了更具体的体会。网上那些提示词模板大多太泛，真正管用的是针对具体任务的结构化信息。我的做法固定成四段：

第一段给背景和约束，说清楚这是什么平台、什么语言、有什么特殊要求。第二段给精确的输入输出样例，尤其是格式敏感的题目，样例里的空格、换行、缩进都要保留。第三段给边界条件，比如 n=0 怎么办、空输入怎么办。第四段明确要求它解释关键步骤，这样我能快速判断它是不是真理解了。

这套结构在杨辉三角任务里效果立竿见影。第一次它格式错了，我把样例的空格显式化之后，第二次就对了。而在多文件改造任务里，我把调用点列表和局部代码片段结构化地给它，它才能保持高准确率。

4.2 上下文工程在编程场景的三个原则

结合这次实测，我把上下文工程在编程场景的应用总结成三条原则。

原则一：精准优于全量。8000 行精准上下文的效果，好过 20000 行全量灌入。模型注意力是有限资源，无关代码越多，关键信息越容易被淹没。

原则二：关键信息放两端。受中间信息丢失影响，我把新旧函数定义、调用点列表这些最关键的内容放在上下文开头，把最需要它参考的样例放在结尾，中间放次要的代码片段。

原则三：用可见字符消除歧义。空格、制表符、换行这些在纯文本里看不见的东西，是 AI 编程出错的重灾区。用·表示空格、→表示制表符，能大幅降低格式类错误。

4.3 常见问题速查表

4.4 关于模型选型的一点个人看法

现在 AI 编程工具太多了，Cursor、Windsurf、VS Code Copilot、Trae，还有各种命令行 agent。我的建议是别纠结"哪个最强"，而是看你的任务类型。短平快的算法题，大部分模型都能接；真正拉开差距的是长上下文工程改造和复杂重构。Step 5 Preview 在这类任务上的表现让我愿意把它纳入日常备选，尤其是需要处理大文件、多文件改造的时候。

至于 MoE 架构，它带来的成本优势和速度优势是实打实的，但别指望它解决所有问题。架构是底座，提示词和上下文工程才是你真正能控制、也最该花时间打磨的部分。我见过太多人抱怨模型不行，其实问题出在自己给的上下文一塌糊涂。

最后分享一个我踩过好几次坑才养成的习惯：每次让 AI 改代码之前，先自己用 grep 把影响范围找出来，把调用点列表整理好再喂给它。这一步花不了几分钟，但能让 AI 的准确率提升一大截。模型再强，也替代不了你对项目的理解——它负责执行，你负责判断，这个分工在很长一段时间内都不会变。