★ FEATURED ARTICLE 1. 为什么我决定用两道编程题来测 Step 5 Preview跑分这东西看多了会麻木。MMLU、HumanEval、MBPP 刷到九十多分实际写业务代码的时候该卡壳还是卡壳。我最近拿到 Step 5 Preview 的测试权限第一反应不是去跑那些标准 benchmark而是直接扔了两道有代表性的编程题进去——一道是算法逻辑题倒推法求杨辉三角一道是偏工程实现的综合题。原因很简单跑分高只能说明模型见过类似的题但真实编程场景里你能不能理解一个非典型的解题约束、能不能在上下文里保持逻辑一致、能不能输出可直接运行的代码这些才是分水岭。Step 5 Preview 这个版本号本身就值得琢磨。从命名来看它大概率是某个大版本迭代前的预览版通常这种版本会重点验证架构调整的效果。结合热词里反复出现的 MoE 架构、上下文窗口、AI 编程助手对比这些关键词我判断这次测试的重点应该放在两个维度一是 MoE 架构下模型对编程任务的处理效率二是长上下文对代码逻辑连贯性的影响。杨辉三角这道题看起来简单但它有一个很关键的约束——用倒推法。这个约束会逼着模型不能直接套用最常见的递推公式必须理解“倒推”这个逻辑方向然后重新组织代码结构。这恰好能测出模型是真的理解了问题还是只是在做模式匹配。另一道综合编程任务我设计得更贴近实际开发场景需要模型在给定的上下文里维护多个函数之间的调用关系同时处理边界条件。这道题没有标准答案但能看出模型在代码组织、变量命名、异常处理这些工程细节上的水平。两道题一前一后基本能覆盖从算法思维到工程实现的完整链路。提示如果你也想做类似的模型评测建议不要只跑标准数据集。自己设计 2-3 道有明确约束条件的题目比跑一百道 LeetCode 原题更能看出模型的真实水平。2. 倒推法求杨辉三角一道题暴露的逻辑理解力2.1 题目约束到底在考什么先看题目本身用倒推法求杨辉三角并输出测试输入是行数预期输出是格式化后的三角阵列。大多数人看到杨辉三角第一反应是递推——从第一行开始每行根据上一行计算下一行。这是正推。但题目明确要求“倒推法”这意味着解题方向要反过来从目标行出发反向推导出每一行的值。这个约束为什么关键因为正推和倒推在代码结构上完全不同。正推是迭代从 row[0] 开始逐行生成倒推则需要先确定最后一行然后反向计算。对于杨辉三角来说倒推其实有一个天然的切入点杨辉三角的每一行其实是对称的而且第 n 行的第 k 个数等于 C(n-1, k-1)。如果从最后一行倒着推可以利用组合数的性质从中间向两边展开。但更直接的倒推思路是已知第 n 行的所有值可以反推出第 n-1 行的值——因为第 n 行的第 i 个数等于第 n-1 行的第 i-1 个数加上第 i 个数。这是一个线性方程组理论上可以解。我实际测试时Step 5 Preview 给出的第一版代码用的是正推。它生成了一个标准的杨辉三角然后输出。这说明模型在第一次尝试时优先匹配了最常见的模式而没有真正理解“倒推法”这个约束。当我明确指出“必须用倒推法不能从第一行开始正推”之后它才调整了策略。2.2 模型第二版代码的逻辑拆解第二版代码的核心思路是这样的先根据输入的行数 n直接构造出第 n 行的所有组合数然后利用杨辉三角的对称性和相邻行之间的关系反向计算出第 n-1 行再继续倒推到第一行。具体实现上它用了一个二维数组来存储每一行但从最后一行开始填充。def reverse_pascal(n): # 先构造最后一行 last_row [1] * n for i in range(1, n): last_row[i] last_row[i-1] * (n - i) // i # 存储所有行 rows [None] * n rows[n-1] last_row # 倒推 for i in range(n-2, -1, -1): row [1] * (i1) for j in range(1, i): row[j] rows[i1][j] - row[j-1] rows[i] row return rows这段代码的逻辑是已知下一行的值通过row[j] next_row[j] - row[j-1]来反推当前行。这个公式的推导其实很简单杨辉三角中next_row[j] row[j-1] row[j]所以row[j] next_row[j] - row[j-1]。但这里有一个隐含条件row[j-1]必须已经计算出来。由于row[0]永远是 1所以从左到右依次计算是可行的。这个实现能跑通但有一个小问题它先构造了最后一行用的是组合数公式。这其实是一种混合策略——最后一行用正推组合数其余行用倒推。严格来说这不算纯粹的倒推法但确实满足了“从后往前计算”的核心要求。我在测试时特意检查了 n3 的情况输出是1 1 1 1 2 1格式上基本正确但空格的数量和题目预期的输出格式有细微差异。题目预期输出里第一行的 1 前面有 21 个空格第二行是 17 个空格加两个数字之间 5 个空格。Step 5 Preview 的输出在空格数量上没有完全对齐但数值全部正确。这说明模型在格式化输出这种细节上还需要更精确的指令。2.3 从这道题看模型的上下文保持能力这道题还有一个值得注意的地方当我在对话中追加要求“输出格式必须和预期完全一致包括空格数量”之后模型在后续的回复里确实调整了空格计算逻辑。它开始用 * (2 * (n - i - 1))这样的表达式来控制每行前面的空格数并且用 * 5来控制数字之间的间隔。这说明模型能够在多轮对话中保持对格式要求的记忆并且把新的约束应用到代码生成里。但这里也暴露了一个问题模型第一次生成代码时并没有主动去检查输出格式的精确性。它只保证了数值正确格式上用了比较随意的对齐方式。这在真实开发里其实很常见——很多开发者也是先保证逻辑正确再调格式。但作为评测这提醒我模型的“默认行为”是优先保证功能正确格式细节需要显式要求才会被重视。注意如果你用 AI 编程助手做算法题建议在提示词里把输出格式的要求写清楚包括空格、换行、缩进这些细节。否则模型大概率会给你一个“能跑但格式不对”的版本。3. 第二道综合编程任务工程实现里的隐藏考点3.1 任务设计思路与预期难点第二道题我设计得更贴近实际开发要求模型实现一个简单的任务调度器支持添加任务、按优先级执行、处理任务依赖关系并且要在给定的上下文里维护任务状态。这道题没有标准答案但有几个明确的考点第一模型能不能设计出合理的数据结构来存储任务和依赖关系第二能不能正确处理循环依赖这种边界情况第三代码的可读性和可扩展性如何。我特意在提示词里加了一个约束“请在一个文件内完成不要引入外部依赖但要求代码结构清晰方便后续扩展。”这个约束的目的是看模型会不会为了简洁而牺牲可读性或者为了可读性而写出过于冗长的代码。Step 5 Preview 给出的实现用了字典来存储任务每个任务是一个包含priority、dependencies、status的字典。调度逻辑用了一个简单的拓扑排序变体每次从待执行任务里选出优先级最高且依赖已满足的任务执行。循环依赖的检测用了深度优先搜索在添加依赖时检查是否会形成环。class TaskScheduler: def __init__(self): self.tasks {} self.graph {} def add_task(self, task_id, priority0, dependenciesNone): if task_id in self.tasks: raise ValueError(fTask {task_id} already exists) self.tasks[task_id] { priority: priority, dependencies: dependencies or [], status: pending } self.graph[task_id] dependencies or [] if self._has_cycle(): del self.tasks[task_id] del self.graph[task_id] raise ValueError(Adding this task creates a cycle) def _has_cycle(self): visited set() rec_stack set() def dfs(node): visited.add(node) rec_stack.add(node) for dep in self.graph.get(node, []): if dep not in visited: if dfs(dep): return True elif dep in rec_stack: return True rec_stack.remove(node) return False for node in self.graph: if node not in visited: if dfs(node): return True return False这段代码的逻辑是完整的但有一个细节值得注意它在add_task里先添加任务然后检查是否有环如果有环就回滚。这个“先添加再检查再回滚”的模式在工程上是可以接受的但更优雅的做法是在添加之前就检查。不过考虑到实现复杂度这个方案也算合理。3.2 模型在边界条件上的表现我特意测试了几个边界情况空任务列表、只有一个任务、任务依赖自身、两个任务互相依赖。Step 5 Preview 在空列表和单任务的情况下表现正常但在“任务依赖自身”这个 case 上它的第一版代码没有正确处理。add_task(A, dependencies[A])应该直接报错但模型的第一版实现里_has_cycle函数在遇到自依赖时dfs(A)会先访问A然后检查依赖A发现A已经在rec_stack里返回True。逻辑上是对的但实际运行时因为visited和rec_stack的更新顺序问题导致自依赖没有被正确检测到。我指出这个问题后模型在第二版里调整了dfs的实现把rec_stack.remove(node)移到了循环结束之后并且增加了对自依赖的显式检查。这个修正过程说明模型能够根据反馈定位逻辑漏洞但第一次生成时对边界条件的覆盖不够全面。另一个值得说的点是优先级处理。模型用了简单的整数比较来选优先级最高的任务但没有处理优先级相同的情况。在实际调度里优先级相同的任务应该按照添加顺序执行FIFO。模型的第一版实现里相同优先级的任务执行顺序是不确定的因为它用了max()函数从字典里选而字典的遍历顺序在 Python 3.7 里是插入顺序但max()在遇到相同值时返回第一个遇到的所以实际上还是 FIFO。这个行为是隐式的模型没有在代码里显式说明也没有加注释。如果换一个语言或者换一个数据结构这个隐式行为可能就不成立了。3.3 代码风格与可维护性观察从代码风格上看Step 5 Preview 生成的代码比较规范变量命名清晰函数职责单一关键逻辑有注释。但它有一个习惯喜欢用嵌套函数比如_has_cycle里的dfs。这在 Python 里是合法的但对于不熟悉闭包的开发者来说阅读成本会高一些。我在实际项目里更倾向于把dfs抽成一个独立的方法或者模块级函数这样更容易测试和复用。另外模型在异常处理上用了raise ValueError但没有定义自定义异常类。对于一个小型调度器来说这没问题但如果要扩展成生产级代码自定义异常会让错误处理更清晰。这个细节说明模型在“快速实现”和“工程规范”之间默认偏向了前者。提示用 AI 生成工程代码时建议在提示词里明确要求“定义自定义异常类”或者“把嵌套函数抽成独立方法”。这些细节模型不会主动做但你说出来它就能做到。4. MoE 架构与上下文窗口对编程任务的实际影响4.1 MoE 架构在代码生成中的表现特征热词里反复出现 MoE 架构这让我在测试时特别留意了模型在代码生成过程中的“激活模式”。MoE混合专家的核心思想是模型由多个专家网络组成每次输入只激活其中一部分专家。对于编程任务来说这意味着模型可能会根据任务类型动态调用不同的“专家”——比如算法题激活逻辑推理相关的专家工程题激活代码组织相关的专家。从实际测试来看Step 5 Preview 在两道题上的表现确实有差异。杨辉三角那道题它的第一版代码逻辑正确但格式粗糙调度器那道题它的第一版代码结构完整但边界条件有漏洞。这种差异可能反映了不同专家网络在“逻辑严谨性”和“工程完整性”上的训练侧重不同。当然这只是我的推测没有内部数据支撑但从行为模式上看MoE 架构确实让模型在不同任务上表现出了不同的“性格”。另一个观察是响应速度。两道题的生成时间都在可接受范围内没有出现明显的卡顿。考虑到 MoE 架构每次只激活部分参数推理效率理论上会比稠密模型高。但这也带来一个问题如果任务需要跨领域的知识比如既需要算法逻辑又需要工程规范MoE 可能需要激活更多专家这时候效率优势就会减弱。我在调度器那道题里追加了“请同时考虑性能和可读性”的要求后模型的生成时间确实略有增加但输出质量也相应提升了。4.2 上下文窗口对多轮代码迭代的影响热词里还有“1M 上下文已经全量可用”“上下文影响”“上下文工程”这些关键词。我在测试时特意做了多轮迭代第一轮让模型生成代码第二轮指出问题第三轮要求优化第四轮要求添加测试用例。整个对话下来上下文长度大概在几千 token 的量级远没有触及 1M 的上限。但即使在这个量级上我也能感觉到上下文对代码一致性的影响。具体来说当我在第三轮要求“把调度器的优先级比较改成支持自定义比较函数”时模型能够准确地引用第二轮里定义的TaskScheduler类并且在原有代码基础上做增量修改而不是重新生成一个全新的类。这说明模型在长上下文里保持了代码结构的连贯性。但有一个小问题它在修改add_task方法时没有同步更新_has_cycle里的逻辑导致新加的comparator参数在环检测里没有被用到。这个遗漏说明模型在长上下文里虽然能记住主要结构但对细节的同步更新还不够完美。如果上下文再长一些比如把整个项目的代码都放进去模型能不能保持这种连贯性从目前的表现看大概率是可以的但可能会有更多的细节遗漏。这也是“上下文工程”这个热词背后的核心问题上下文越长模型能记住的信息越多但信息之间的干扰也可能越大。在实际使用中我建议把关键约束和接口定义放在上下文的靠前位置把具体的实现细节放在后面这样模型在生成时更容易抓住重点。4.3 提示词工程在编程任务中的实际作用热词里还有“大模型提示词工程与上下文工程”“AI 编程提示词”这些关键词。从这两道题的测试来看提示词的质量对输出结果影响很大。杨辉三角那道题我第一版提示词只写了“用倒推法求杨辉三角”模型就用了正推。第二版我改成“必须从最后一行开始计算利用相邻行之间的关系反向推导不能从第一行正推”模型才给出了符合要求的实现。调度器那道题我第一版提示词写了“实现一个任务调度器支持优先级和依赖”模型给出了一个基本可用的版本。第二版我加了“请处理循环依赖并在添加任务时检测”模型才补上了环检测逻辑。第三版我加了“请考虑优先级相同时的 FIFO 顺序”模型才在代码里显式处理了这个情况。这些迭代说明一个事实对于编程任务提示词里的约束越具体模型的输出越接近预期。但约束也不能太细否则模型会变成“填空机器”失去自主设计的能力。我的经验是把核心需求和关键约束写清楚把实现细节留给模型然后在多轮对话里逐步收紧要求。这样既能保证输出质量又能观察模型的自主决策能力。5. 两道题跑完之后的一些实操心得5.1 模型在算法题和工程题上的能力差异两道题跑下来最直观的感受是Step 5 Preview 在算法题上的表现更“稳”在工程题上的表现更“活”。杨辉三角那道题虽然第一版没理解“倒推法”但一旦理解了生成的代码逻辑严谨边界条件比如 n1、n0都处理了。调度器那道题模型展现出了更强的设计能力——它自己决定了用字典存任务、用拓扑排序做调度、用 DFS 做环检测这些选择都不是我指定的而是它根据问题特点自主做出的。这种差异可能和训练数据的分布有关。算法题有标准答案模型在训练时见过大量类似题目所以更容易匹配到正确的模式。工程题没有标准答案模型需要根据约束条件自主设计这时候它的“设计能力”就体现出来了。从实际使用角度看这意味着用 AI 做算法题你可以期待它一次给出接近正确的答案用 AI 做工程题你需要准备好迭代和反馈但它的设计思路往往能给你启发。5.2 多轮对话里的上下文管理技巧在多轮迭代过程中我总结了一个小技巧每次要求模型修改代码时不要只说“这里有问题”而是把“问题现象 期望行为 约束条件”一起说清楚。比如调度器的环检测问题我第一轮只说“自依赖没检测到”模型改了一版但还是不对。第二轮我改成“当任务 A 依赖自身时add_task 应该抛出异常并且在抛出异常前不能修改 tasks 和 graph 的状态”模型立刻就改对了。这个技巧背后的逻辑是模型在长上下文里需要明确的“锚点”来定位问题。你给的约束越具体它越容易找到正确的修改方向。另外我建议在每轮修改后让模型自己总结一下“这次改了什么”这样既能确认它理解了你的要求也能在上下文里留下一个清晰的变更记录方便后续追溯。5.3 对 Step 5 Preview 的整体评价如果只用一句话总结Step 5 Preview 在编程任务上的表现已经超出了“代码补全工具”的范畴更接近一个“能理解约束、能自主设计、能根据反馈迭代”的编程助手。它在算法题上的逻辑严谨性、在工程题上的设计灵活性、在多轮对话里的上下文保持能力都达到了可用的水平。但也有一些明显的短板第一对输出格式的精确性不够重视需要显式要求才会调整第二对边界条件的覆盖不够全面第一版代码往往只处理主流程第三在长上下文里对细节的同步更新还不够完美修改一个地方可能会遗漏关联的地方。这些短板在实际使用中可以通过提示词和迭代来弥补但如果你期待“一次生成完美代码”可能会失望。从 MoE 架构和上下文窗口的角度看Step 5 Preview 的表现符合预期MoE 让它在不同任务上展现出不同的能力侧重长上下文让它能保持多轮对话的连贯性。但这两个特性也带来了新的使用门槛——你需要学会“上下文工程”知道把什么信息放在什么位置才能让模型发挥出最佳水平。提示如果你打算把 Step 5 Preview 接入日常开发流程建议先从算法题和独立函数生成开始熟悉它的输出风格和迭代节奏再逐步过渡到模块级和项目级的代码生成。直接让它写整个项目大概率会得到一堆需要大量修改的代码。5.4 一个容易被忽略的细节代码注释的质量最后说一个我在测试中注意到的细节Step 5 Preview 生成的代码注释质量参差不齐。杨辉三角那道题它在关键的计算步骤上加了注释比如# 利用组合数公式构造最后一行但在倒推循环里没有注释读者需要自己理解row[j] rows[i1][j] - row[j-1]这个公式的推导。调度器那道题它在类和方法级别有 docstring但在具体的逻辑分支里注释很少。这个细节在实际使用中影响不大因为代码本身可读性还可以。但如果你要把生成的代码直接放进项目里建议自己补一下关键逻辑的注释特别是那些“为什么这样做”而不是“做了什么”的注释。模型擅长写“做了什么”的注释但“为什么这样做”的注释需要你自己加因为只有你知道业务背景和设计取舍。另外模型在生成代码时偶尔会用一些“聪明”的写法比如列表推导式嵌套、三元表达式链式调用。这些写法在 Python 里是合法的但可读性不一定好。如果你团队里有新手建议在提示词里加一句“请用清晰易懂的写法避免过度使用列表推导式和三元表达式”。这个要求模型能理解也会照做。
阅读完成 · 觉得有帮助？
