企业官网建设流程全解析

1. 为什么我决定用真实项目来测 Step 5 Preview

跑分这东西，看多了就麻木了。MMLU、HumanEval、SWE-bench，榜单上你追我赶，小数点后两位都能卷出花来，但真到了自己手里写业务代码，该卡壳还是卡壳，该胡编还是胡编。我做了十多年一线开发，带过团队也接过私活，见过太多“榜单王者、实战青铜”的模型。所以当 Step 5 Preview 出来的时候，我第一反应不是去看它又刷了多少分，而是想找个真实场景，把它按在键盘前，看它到底能不能干活。

这次我挑了两个任务，都是我自己手头真实遇到的需求，不是那种“写一个快排”或者“实现一个 LRU”的玩具题。第一个是带视觉输入的界面还原任务——我手里有一张设计稿截图，需要生成一套能跑的响应式页面代码；第二个是MoE 架构下的负载均衡模块实现——涉及专家路由、容量因子、token 丢弃策略这些容易踩坑的地方。两个任务一个偏前端视觉，一个偏后端架构，正好能把 Step 5 Preview 的几个核心卖点——1M Token 上下文、视觉输入、MoE 架构理解——都拉出来遛遛。

先说结论，免得你往下翻得太累：这模型在真实任务里的表现，比我预期要稳，但也不是没有翻车的地方。下面我把两个任务的完整过程、关键代码、踩坑记录都摊开讲，你看完大概能判断它适不适合你的工作流。

2. 任务一：从设计稿截图到可运行页面

2.1 任务背景与输入准备

这个任务的起因很简单。我接了一个小项目，客户给了一张 Figma 导出的设计稿截图，要求两天内出一个能点击的原型页面。设计稿不算复杂，一个落地页，包含导航栏、Hero 区、三列特性卡片、一个表单区和页脚。但问题在于，客户只给了图，没有给任何标注、没有切图、没有设计规范文档。按传统流程，我得手动量间距、吸色值、猜字体，一套下来至少半天就没了。

我决定试试 Step 5 Preview 的视觉输入能力。输入方式很直接：把设计稿截图作为图片附件传进去，配上一段提示词。这里有个细节值得说——提示词的质量直接决定输出质量。我第一版提示词写得很随意：“帮我根据这张图生成 HTML 和 CSS”，结果出来的东西能用但很粗糙，间距全靠猜，颜色也偏得厉害。后来我调整了策略，把提示词拆成几个明确的部分：

你是一名资深前端工程师。请根据提供的设计稿截图，生成一个完整的响应式落地页。要求：1）使用语义化 HTML5 标签；2）CSS 使用 Flexbox 和 Grid 混合布局，不依赖任何框架；3）颜色值尽量从截图中提取，如果无法精确提取请给出最接近的十六进制值并标注；4）字体使用系统字体栈，字号和行高根据视觉层级推断；5）所有间距使用 8px 基准网格；6）输出单个 HTML 文件，内联 CSS。

这段提示词的关键在于约束。你不给约束，模型就自由发挥，出来的东西看着像那么回事，但改起来要命。给了约束之后，它至少在一个可预期的框架里干活。

2.2 视觉输入的实际表现与关键细节

Step 5 Preview 对这张截图的解析能力，说实话超出我预期。它准确识别出了导航栏的 logo 位置、菜单项数量（5 个）、Hero 区的主标题和副标题层级关系，甚至把三列卡片里的图标占位符都标出来了。颜色方面，它从截图中提取的主色是#2563EB，我后来用取色器核对，实际值是#2564EB，差了一个色阶，基本可以接受。背景灰它给的是#F9FAFB，实际是#F9FAFB，完全一致。

但有几个地方它判断错了。第一，字体权重。设计稿里主标题用的是 Bold，它生成的是 600（Semi-Bold），视觉上偏细。第二，卡片阴影。截图里的阴影很微妙，它直接给了一个box-shadow: 0 4px 6px rgba(0,0,0,0.1)，实际效果偏重，后来我手动调成了0 1px 3px rgba(0,0,0,0.08)。第三，响应式断点。它默认给了 768px 和 1024px 两个断点，但设计稿明显是移动优先的，应该从 640px 开始断。这些偏差不算致命，但说明视觉输入不是万能的，它更像一个理解力很强的实习生，能帮你完成 80% 的体力活，剩下 20% 的精细调整还得你自己来。

这里插一句关于1M Token 上下文的体验。我这个任务其实没用到那么长的上下文，整个对话加起来也就几千 Token。但我在测试过程中故意把一份 3000 行的旧 CSS 文件贴进去，让它参考现有风格生成新页面，它确实能记住并复用里面的变量命名和类名规范。这个能力在大型项目里会很实用——你可以把整个组件库的代码贴进去，让它按统一风格生成新组件，不用反复交代规范。

2.3 生成代码的结构分析与手动优化

它生成的 HTML 结构是这样的：

<header class="navbar"> <div class="logo">Brand</div> <nav class="nav-links"> <a href="#">产品</a> <a href="#">方案</a> <a href="#">定价</a> <a href="#">文档</a> <a href="#">关于</a> </nav> <button class="cta-btn">免费试用</button> </header> <section class="hero"> <h1>让开发效率提升十倍</h1> <p>从设计到代码，只需几秒钟</p> <div class="hero-actions"> <button class="primary">开始使用</button> <button class="secondary">观看演示</button> </div> </section> <section class="features"> <div class="feature-card"> <div class="icon"></div> <h3>智能生成</h3> <p>基于视觉输入自动生成可运行代码</p> </div> <!-- 另外两张卡片 --> </section>

结构本身没问题，语义化标签用得也对。但 CSS 部分有几个坑。第一，它给.navbar用了position: fixed，但没有给 body 加padding-top，导致 Hero 区被导航栏遮住了一截。第二，.features用了display: flex但没有设flex-wrap，在窄屏下三张卡片会挤成一条线。第三，按钮的 hover 状态只改了背景色，没有过渡动画，交互感很生硬。

我手动改了这几处，顺便把它的 CSS 变量抽了出来：

:root { --primary: #2563EB; --primary-hover: #1D4ED8; --bg-gray: #F9FAFB; --text-main: #111827; --text-sub: #6B7280; --radius: 8px; --shadow-sm: 0 1px 3px rgba(0,0,0,0.08); }

改完之后，整个页面的还原度大概在 90% 左右。从拿到截图到出可运行页面，总共花了不到 40 分钟，其中还包括我手动调优的时间。如果纯手写，这个页面我至少得花两个半小时。效率提升是实打实的，但前提是你得懂前端，能看出它哪里写错了、哪里可以优化。如果你完全不懂，直接拿它生成的代码上线，那几个布局 bug 在移动端会很难看。

2.4 这个任务暴露的能力边界

做完这个任务，我对 Step 5 Preview 的视觉能力有了比较清晰的认知。它强在整体结构理解和语义化生成，弱在像素级精确还原和响应式细节。具体来说：

这个表你可以直接拿去参考。如果你要做的是快速原型或者内部工具页面，它生成的代码改改就能用。如果是面向用户的商业项目，建议把它当第一稿，后面必须有人工精修。

3. 任务二：MoE 负载均衡模块的实现

3.1 为什么选这个任务来测

第二个任务是我自己最近在折腾的一个东西。我在做一个多专家混合架构的实验项目，需要实现一个负载均衡模块，核心逻辑是：给定一批 token 和一组专家，如何把 token 分配给专家，使得每个专家处理的 token 数量尽量均衡，同时不超出容量限制。这个问题在 MoE 架构里很经典，涉及专家路由、容量因子、token 丢弃、负载均衡损失几个关键概念。

我选这个任务，是因为它能同时测出 Step 5 Preview 的几个能力：对 MoE 架构的理解深度、算法实现能力、边界条件处理。而且这个任务有明确的对错标准——分配是否均衡、是否超容量、丢弃策略是否合理，都能验证。

3.2 提示词设计与架构理解测试

我给的提示词是这样的：

实现一个 MoE 负载均衡模块，要求：1）输入为 token 隐状态矩阵和专家网络列表；2）使用 top-k 路由（k=2），计算每个 token 对每个专家的亲和度；3）引入容量因子 capacity_factor，每个专家的容量 = (总 token 数 / 专家数) * capacity_factor；4）如果某个专家接收的 token 超过容量，超出部分按亲和度从低到高丢弃；5）输出每个 token 被分配到的专家索引，以及被丢弃 token 的掩码；6）附带一个负载均衡辅助损失的计算函数。

这段提示词里，我故意把几个容易混淆的点写清楚了。比如容量因子的定义，很多实现里会把它和“每个专家最多处理的 token 数”搞混。再比如丢弃策略，是按亲和度丢弃还是按到达顺序丢弃，结果完全不同。我写清楚这些，是想看它能不能理解这些细节，而不是生成一个“看起来像那么回事”的代码。

它的第一版输出，整体框架是对的，但有几个问题。第一，它把 top-k 路由的亲和度计算写成了 softmax 之后的概率，但实际上路由亲和度应该是原始 logits，softmax 是在专家内部做加权用的。第二，容量计算里它用了ceil而不是floor，导致容量偏大，丢弃策略形同虚设。第三，负载均衡损失它写成了sum(f_i * P_i)的形式，但标准写法应该是num_experts * sum(f_i * P_i)，少了一个缩放系数。

我把这几个问题指出来之后，它第二版改对了。这说明它能理解反馈并修正，但第一版不会主动去抠这些细节。这跟人的行为很像——你交代任务，他先搭框架，细节得你盯着。

3.3 核心代码实现与参数计算

下面是它第二版输出的核心代码，我加了一些注释说明关键点：

import torch import torch.nn.functional as F def moe_load_balance( hidden_states, # [num_tokens, hidden_dim] expert_weights, # [num_experts, hidden_dim, hidden_dim] num_experts, top_k=2, capacity_factor=1.25 ): num_tokens = hidden_states.shape[0] # 计算路由 logits # 这里用一个简单的线性层模拟 router router_logits = hidden_states @ expert_weights.mean(dim=0).T # [num_tokens, num_experts] # top-k 路由 top_k_logits, top_k_indices = torch.topk(router_logits, top_k, dim=-1) # [num_tokens, top_k] # 计算容量 # 注意：这里用 floor 而不是 ceil，避免容量虚高 capacity = int((num_tokens / num_experts) * capacity_factor) # 统计每个专家被选中的次数 expert_counts = torch.zeros(num_experts, dtype=torch.long) for i in range(num_tokens): for j in range(top_k): expert_counts[top_k_indices[i][j]] += 1 # 确定每个专家的实际容量 # 如果某个专家被选次数超过容量，需要丢弃 expert_capacity = torch.full((num_experts,), capacity, dtype=torch.long) # 构建分配掩码 token_mask = torch.zeros(num_tokens, top_k, dtype=torch.bool) expert_usage = torch.zeros(num_experts, dtype=torch.long) # 按亲和度排序，优先保留高亲和度的 token # 这里需要遍历所有 token-expert 对 assignments = [] for i in range(num_tokens): for j in range(top_k): expert_idx = top_k_indices[i][j] affinity = top_k_logits[i][j] assignments.append((affinity, i, j, expert_idx)) # 按亲和度从高到低排序 assignments.sort(key=lambda x: x[0], reverse=True) for affinity, token_idx, k_idx, expert_idx in assignments: if expert_usage[expert_idx] < expert_capacity[expert_idx]: token_mask[token_idx][k_idx] = True expert_usage[expert_idx] += 1 # 计算负载均衡损失 # f_i: 每个专家实际处理的 token 比例 # P_i: 每个专家的平均路由概率 f = expert_usage.float() / num_tokens P = F.softmax(router_logits, dim=-1).mean(dim=0) aux_loss = num_experts * torch.sum(f * P) return top_k_indices, token_mask, aux_loss

这段代码有几个地方值得展开说。容量计算那里，capacity = int((num_tokens / num_experts) * capacity_factor)，假设有 1000 个 token、8 个专家、capacity_factor=1.25，那么每个专家的容量是int(125 * 1.25) = 156。这个数字意味着，如果所有 token 均匀分配，每个专家处理 125 个，容量 156 留了 25% 的余量。如果某个专家被选中的次数超过 156，多出来的 token 就会被丢弃。

丢弃策略这里，它用了按亲和度全局排序的方式。这个做法是对的，但效率不高——assignments.sort是 O(N log N) 的，在 token 数量大的时候会慢。实际生产环境里，通常会按专家分组，每组内部排序，然后取前 capacity 个。不过作为教学示例，这个写法足够清晰。

负载均衡损失那里，aux_loss = num_experts * torch.sum(f * P)，这个缩放系数很重要。如果不乘num_experts，损失值会很小，梯度信号弱，起不到均衡作用。这个细节它第一版漏了，第二版补上了。

3.4 实测结果与性能观察

我用随机生成的 1000 个 token、8 个专家跑了这个模块，capacity_factor 分别取 1.0、1.25、1.5，观察丢弃率和负载均衡情况。结果如下：

这个结果很有意思。capacity_factor=1.0 的时候，丢弃率很高，但负载完全均衡（标准差为 0，因为每个专家都塞满了）。capacity_factor=1.5 的时候，没有丢弃，但负载不均衡，有的专家处理得多，有的少。1.25 是一个比较平衡的点，丢弃率可接受，负载也相对均匀。这也解释了为什么很多 MoE 实现里默认 capacity_factor 取 1.25 左右。

这里有个坑我得提醒你：丢弃率不是越低越好。如果 capacity_factor 设得太大，虽然不丢 token，但专家利用率低，计算浪费。如果设得太小，丢 token 太多，模型效果会下降。这个参数需要根据实际任务调，没有万能值。

3.5 这个任务暴露的架构理解深度

做完这个任务，我对 Step 5 Preview 在 MoE 方面的理解能力有了判断。它能正确理解 MoE 的核心概念——专家、路由、容量、丢弃、负载均衡损失，这些它都没搞混。但在实现细节上，第一版会有偏差，需要人工指正。具体来说：

• 概念理解：优秀。它知道 top-k 路由、容量因子、辅助损失这些术语的含义。
• 代码框架：良好。整体结构对，但边界条件处理需要加强。
• 参数计算：中等。容量计算、损失缩放这些地方容易出错。
• 效率意识：偏弱。它优先保证正确性，不太考虑大规模场景下的性能。

如果你要拿它来写 MoE 相关代码，我的建议是：把它当架构师用，别当实现工程师用。让它搭框架、写核心逻辑，然后你自己去优化性能、处理边界。这样配合下来，效率提升很明显。

4. 两个任务交叉对比：Step 5 Preview 的真实能力画像

4.1 视觉任务 vs 架构任务的表现差异

把两个任务放在一起看，能看出一些有意思的差异。视觉任务里，它的第一版输出可用度更高，大概 80% 的内容可以直接用，剩下 20% 需要调优。架构任务里，第一版可用度大概 60%，核心逻辑对，但细节错误比较多，需要一轮反馈修正。

这个差异的原因我琢磨了一下。视觉任务有明确的参照物——设计稿就在那里，它只需要“翻译”成代码，不需要“创造”逻辑。架构任务没有参照物，它需要从零构建逻辑，这时候它对细节的把握就不如对视觉元素的识别那么准。换句话说，它更擅长“转换”，不太擅长“创造”。这个判断对你选择使用场景很重要。

4.2 1M Token 上下文在真实场景中的价值

1M Token 这个卖点，我在两个任务里都做了针对性测试。视觉任务里，我把一份 3000 行的旧 CSS 贴进去让它参考风格，它确实能记住并复用变量命名。架构任务里，我把一份 5000 行的 MoE 相关代码库贴进去，让它在这个基础上实现新模块，它也能理解现有代码的结构和约定。

但这里有个现实问题：1M Token 的上下文，实际用起来很贵。虽然 Step 5 Preview 的定价我没看到官方数据，但按行业惯例，长上下文的推理成本是指数级上升的。我的建议是：只在真正需要的时候用长上下文。比如你要让它理解一个大型项目的代码规范，或者要它参考一份很长的设计文档，这时候长上下文有价值。如果只是写个独立函数，没必要塞那么多东西进去，反而会稀释注意力。

4.3 和主流 AI 编程工具的配合策略

我平时也用 Cursor、Windsurf、VS Code Copilot 这些工具，Step 5 Preview 和它们不是替代关系，而是互补关系。我的用法是这样的：

• Cursor：日常写代码的主力，补全快，交互流畅，适合边写边改。
• Windsurf：做重构和跨文件修改的时候用，它的上下文理解能力比较强。
• Step 5 Preview：遇到需要深度理解的任务时用，比如从设计稿生成页面、实现复杂算法模块。它的优势在于单次任务的深度，而不是日常编码的流畅度。

这个组合用下来，我的整体效率大概提升了 40% 左右。不是某一个工具特别神，而是它们各自覆盖了不同的场景。

5. 实操避坑指南与常见问题

5.1 视觉输入任务的避坑要点

做视觉输入任务的时候，有几个坑我踩过，你直接避开：

第一，截图质量决定输出质量。我试过用一张压缩得很厉害的截图，结果它把颜色识别错了，把#2563EB认成了#3B82F6，偏差很大。后来我换成原图，颜色就准了。所以给图的时候尽量给清晰的、没有压缩痕迹的图。

第二，提示词里要明确“不要做什么”。比如你不想要它用某个框架，就要明确说“不要使用 Bootstrap”。你不想要它生成 JavaScript，就要说“只生成 HTML 和 CSS”。它默认会加一些交互脚本，如果你不需要，得提前说。

第三，生成后先检查布局 bug。最常见的三个问题：导航栏遮挡内容、Flex 容器不换行、图片没有设max-width: 100%。这三个我每次都能遇到，你生成完先扫一眼这几处。

5.2 MoE 实现任务的避坑要点

MoE 这个任务里，我总结了几条经验：

第一，容量因子别设太大也别太小。我实测下来，1.25 到 1.5 之间比较合理。具体取多少，看你的任务对丢弃的敏感度。如果丢 token 影响很大，就取 1.5；如果计算资源紧张，就取 1.25。

第二，负载均衡损失一定要加缩放系数。就是那个num_experts的乘数，不加的话损失值太小，梯度信号弱，训练的时候起不到均衡作用。这个坑我踩过，后来看训练日志才发现专家负载一直不均衡。

第三，丢弃策略要按亲和度排序，不要按到达顺序。按到达顺序丢弃的话，后面的 token 永远被丢，前面的永远保留，这会导致位置偏差。按亲和度排序，保证高置信度的 token 优先被处理，效果更好。

第四，top-k 的 k 值不要设太大。k=2 是常见选择，k=1 太激进，k=3 以上计算量上去了但效果提升不明显。我试过 k=4，训练时间多了 30%，效果只好了不到 2%。

5.3 常见问题速查表

6. 我个人的使用体会

Step 5 Preview 给我的感觉，像是一个理解力很强但需要明确指令的搭档。你不能指望它自己悟出你想要什么，但你把要求说清楚了，它能给你一个相当不错的起点。视觉任务里，它帮我省掉了大量体力活；架构任务里，它帮我快速搭出了框架。但两个任务都证明了一件事：它不能替代你的判断。颜色偏了要你调，容量算错了要你改，边界条件漏了要你补。

我现在的用法是：用它做第一稿，然后自己精修。第一稿的质量越高，我精修的时间越少。而第一稿的质量，取决于我的提示词写得够不够细、给的约束够不够明确。这个规律，我用过的所有 AI 编程工具都适用。

最后分享一个小技巧：如果你不确定提示词怎么写，先让它生成一版，然后根据它的输出反推提示词。比如它生成的代码里少了某个约束，你就在下一轮提示词里补上。两三轮下来，你就能摸清它的脾气，后面用起来会顺手很多。这个技巧我在两个任务里都用了，效果很直接。