企业官网建设流程全解析

1. 测试前的准备：为什么选这三个任务，以及我怎么给它“出题”

最近朋友圈和群里都在聊 Step-5-Preview，有人说它写代码强，有人说它做分析靠谱，还有人拿它直接出网页。吵归吵，我自己其实更关心一件事：这东西到底能不能扛住“真实工作流”，而不是在别人精心设计的 Demo 里表演。所以我花了一个周末，把它丢进了三个完全不同的任务里——3D 游戏、金融分析、网页设计——用一套相对规范的测试方法跑了一遍。

先说测试思路。很多人测模型喜欢问“你会不会”，但真正干活的时候，问题从来不是“会不会”，而是“在没人帮你擦屁股的情况下，它交付的东西离可用有多远”。所以我定的规则很简单：

• 每个任务只给一次完整的自然语言描述，不中途补充代码细节；
• 它生成的代码或文本，我要么直接运行，要么拿原始数据逐项核对；
• 过程中的报错和修正全部记录下来，看看到底要“人帮忙”几次；
• 所有任务放在同一个会话里连续完成，模拟连续工作的使用习惯。

上下文长度方面，我用的是一轮对话连续处理三个任务，没有清理历史。这样更能测出它在长会话后期的注意力衰减情况。实际结果让我比较意外，后面会逐个说。

关于测试环境，我再补充两句。浏览器用的是 Chrome 最新版，本地跑 HTML/JS 文件的方式是直接双击打开，没有用本地服务器。金融分析的原始数据是 CSV，放在本地用 Python 的 pandas 读出来核验。Step-5-Preview 的输出界面没有做任何特殊配置，就是默认参数，温度保持标准值，没有为了“让它更有创造力”去调高随机性——因为日常干活你也不会去调这些。

出题的措辞我也刻意用了两种方式：3D 游戏和网页设计用的是带情感色彩的描述（“做一个……”“要有……的感觉”），金融分析则用了非常干巴巴的指令句式。原因后面会说，这其实也是我对模型一个隐藏能力的测试：它对“模糊需求”和“精确需求”的理解切换是否顺畅。

2. 3D 游戏任务实测：一个提示词能跑出什么样的可玩画面

第一个任务是 3D 游戏。最开始我给它出的题是：“用 HTML 和 JavaScript 写一个可以在浏览器里直接跑的开源 3D 游戏，参考经典跑酷玩法，玩家控制一个方块在三条赛道之间切换躲避障碍物，要有计分、碰撞检测和重新开始功能，最好能适配安卓手机浏览器。”

这里有个背景要交代一下。平时我写网页游戏原型，效率并不低，Three.js 写个基础场景大概二十多分钟也能搞定。但我想测的是“完全从零开始”的生成能力，所以故意没有指定用 Three.js，只说“用 HTML 和 JavaScript”，看它会自己选哪条路。

2.1 生成结果：它自己选了原生 WebGL 而不是 Three.js

它第一轮给出的代码大概 500 行，直接基于 WebGL 原生 API 实现，没有引入任何外部库。看到这一点的时候我有点意外。大多数模型接到这个需求会先搬 Three.js，因为封装好、容易写，出 bug 率低。Step-5-Preview 选择原生 WebGL，说明它在“减少外部依赖”上做了自己的判断——这在实际部署里反而是好事，因为内网环境经常拉不到 CDN 资源。

不过原生 WebGL 的代码写得怎么样，直接决定运行效率。我打开浏览器实测，帧率稳定在 60 帧左右，几何体是一个方块障碍群和一个玩家方块，地面用网格线表示。旋转视角用的是固定第三视角，没有做动态相机跟随，这一点在一开始就避免了晕 3D 的问题。移动端的触摸滑动绑定在了整块画布上，左右滑动切换赛道，灵敏度默认 0.6，我用安卓手机浏览器打开后操作手感基本可用。

2.2 碰撞检测和计分逻辑：这里出了第一个 bug

初版代码能跑，但碰撞检测有实际缺陷。障碍物是一组固定在三条赛道上的方块群，玩家方块在纵向坐标不变的情况下左右切换。正常来说，碰到障碍物应该 game over，但我测试时发现：从左侧赛道切到中间赛道，如果中间赛道上障碍物正好在玩家方块前方一个单位距离，并不会触发碰撞——它检测的是“位置重合”而不是“包围盒相交”。

这个问题在游戏开发里很典型。位置重合只适用于“像素级精确”的碰撞，但 3D 游戏中模型有体积，你需要的是两个包围盒在 x、y、z 三个轴向上都发生区间重叠才算碰撞。我把这个问题直接反馈给它，它第二次修改就换成了 AABB 碰撞检测逻辑，并且加了 0.35 的判定缩放系数，避免玩家觉得“明明没碰到却死了”的挫败感。

这里有一张我记录的问题和修改对照：

2.3 实际跑起来的体验和性能

修改后的版本我大概玩了三分钟，体验上已经接近一个“可发布原型”的水平。计分、碰撞、重置、音效（它加了一个非常轻量的 Web Audio 生成的碰撞音）都完整。真正让我意外的是性能——当障碍物数量累计到 40 个时，帧率没有明显下降。看代码发现它做了简单的对象池，障碍物移出场景后会被回收复用，而不是继续创建新对象。这一点很多中级开发者写代码时都未必会主动做。

说个插曲。我把这个游戏发给一个做安卓开发的朋友，他在 Redmi 手机上用 Chrome 打开，横屏模式下触控响应速度基本跟手，没有出现触摸延迟。考虑到这只是一个纯前端 HTML 文件，能做到这一步，说明它在“移动端浏览器兼容”方面的考虑是有效的。我给它的原始需求里只写了一句话“适配安卓手机浏览器”，它自己补了 viewport 设置和 touch 事件的重置逻辑，这属于超出预期的补全能力。

但这个任务也暴露了一个局限：它不会主动问你“想要什么画风”。我给的是文字描述，它默认选了低多边形风格，也就是一堆积木一样的方块组合。如果你想要赛博朋克、霓虹灯、粒子特效这些，需要明确写进提示词里。这提醒我，Step-5-Preview 的审美基线是“整洁可用”，而不是“个性鲜明”。没有额外引导时，它不会冒进。

3. 金融分析任务实测：它到底能算对多少账

第二个任务我设计得更接近真实工作场景。我手头有一份某零售公司过去 24 个月的分店销售数据 CSV，包含日期、门店、品类、销售额、成本、客流量六列，大概 4000 行。我要求它做三件事：

1. 计算每个季度的毛利率变化；
2. 找出连续两个月销售额下滑的门店；
3. 对下季度销售额做预测，至少给出两种方法。

跟上一个任务的措辞不同，这次我用了纯指令式：“请按上述三点执行，输出结论、计算过程和可复现的 Python 或 SQL 代码。”目的就是看它在没有情感化描述的情况下，能否保持同样水准的细节补全能力。

3.1 数据读取和清洗的真实情况

很多人测金融分析时会犯一个错误：直接给模型一段“看起来像那么回事”的表格，让它“分析一下”。但真实数据永远是脏的。我这份 CSV 里有两个门店的名称在不同月份出现大小写不一致（“wangfujing”和“WangFuJing”），还有一个门店在 1 月的数据整行缺失。我故意没有提醒它这些，看它会不会自己发现。

结果它第一轮就注意到了。在生成代码的注释里，它主动写了一句：“清洗阶段需统一门店名称大小写，并检查缺失日期。”代码里做了两件事：对门店名做小写归一化，再按门店分组做日期连续性检查。这个表现超出了我的预期。大多数模型遇到 CSV 数据，默认都是直接跑，很少有人主动设计数据校验环节。

3.2 指标计算和结论的准确性核查

来看重头戏：它算的数对不对。毛利率公式是（销售额 - 成本）除以销售额，它逐季度计算的结果和我在 Excel 里预先手动算好的对照表完全一致，24 个月的数据没有一处算错。这个准确率是实打实的，我没有用近似公式，就是最基础的聚合加除法，它能保持到小数点后两位，说明在数值计算链路上没有截断误差。

连续下滑门店的识别结果更有意思。它列了三家门店，其中有一家我之前没注意，回查数据发现确实存在连续五个月下滑，只是第四个月下滑幅度只有 0.3%，肉眼看不出来。算法层面它用的是环比差分加符号判断，没有引入复杂统计模型，但足够准确。

有一点必须提醒：预测部分，它给出的方法是线性回归加简单指数平滑。这个选择是中规中矩的，但如果你拿去指导真实库存决策，需要谨慎。它对季节性的处理比较粗糙，零售行业的 Q4 销售高峰和来年 Q1 的回落它都算进去了，但预测区间的置信度没有给出——这意味着你只知道趋势，不知道波动范围。我给它的原始指令里没有要求置信区间，它也没主动给，这说明“如果你不要求，它不会过度发挥”。

3.3 可视化交付和“可读性”的取舍

输出部分它用了 Python 的 matplotlib 画了四张图：季度毛利率折线、门店月度销售热力图、下滑门店的标注图、下季度预测对比图。图的基础质量不错，坐标轴、标题、图例都齐全，拿去做汇报材料问题不大。

但我注意到一个细节：默认配色偏学术风，比较素，不像现在常见的商业报告那样有品牌感。这个其实不是缺点，画图工具讲究的就是清晰，不是花哨。真正有价值的是它把图表存成了 PNG 的同时，也给出了生成图表的完整 Python 代码。这意味着我可以复跑，可以把数据源换掉重新生成，而不是拿到一张“一次性图表”。

这个“可复现性”是我评价金融分析任务最高分项。数据和代码分离、代码可重跑、结论可验证，这是专业分析师的交付标准。Step-5-Preview 在这个任务里表现了较强的工程意识，而不是只给你一个空洞的分析结论。

4. 网页设计任务实测：从需求文字到完整页面的“一次跑完”

第三个任务是网页设计。我给它出的题目很具体：“做一个中秋节主题的 H5 页面，要有月亮、灯笼、月饼三个视觉元素，页面包含导航栏、活动介绍、倒计时、奖品列表和报名表单，适配手机端，整体风格要温馨，代码要完整可以直接在浏览器打开。”

这个需求混合了视觉、布局和交互三方面的要求，实际工作中对应的是“前端拿到设计稿后直接开发”的场景。同时我也拿它和“开源安卓 3D 游戏”“HTML5 网页设计作业代码”这些热搜词做了关联判断——说白了，就是看它能不能交付一个学生交作业、新人做作品集时可以直接修改用的完整网页。

4.1 页面结构和视觉效果的评估

打开生成文件，第一屏是红色渐变背景的顶部区域，上半部分是月亮素材和标语，中间是灯笼和月饼的图片，活动介绍区域在第二屏。视觉上，它没有用一张大图铺底，而是用 CSS 渐变和 SVG 插画组合出来的月夜场景。这种做法的好处是文件体积小，加载快，且修改颜色非常方便——你改一下渐变的色值，整个氛围就变了。

结构上，HTML 分区清晰，CSS 抽成了独立文件，JavaScript 绑定在页面底部。没有使用现成的 UI 框架，全部手写。我特意检查了页面在 375px 宽度下的表现，导航栏收缩成了汉堡菜单，倒计时数字换行没有错位，表单输入框宽度自适应。响应式做得比我预想的好，尤其是用了 CSS Grid 加 flex 混排，而不是那种一缩放就乱掉的浮动布局。

4.2 交互细节和动态效果的真实水平

倒计时是重点测的一个功能。它的实现方式是 JavaScript 直接计算目标时间和当前时间的差值，每秒更新一次，显示格式是“天:时:分:秒”。我打开 DevTools 切到 slow 3G 模拟环境，页面在加载完成后倒计时没有出现闪跳。代码写得干净，没有依赖外部的 jQuery，逻辑独立成函数，后续改成中秋之外的活动页面只需要替换目标日期。

报名表单的校验用的是 HTML5 原生的 required 和 type=email，没有额外写一套自定义校验。这个选择在简单场景下是合理的，代码少、维护容易。但如果你要做复杂的规则（比如手机号正则匹配、身份证校验），需要自己去扩展。它的默认方案追求的是稳妥，不是炫技。

某些交互细节还是有“意料之中”的短板。比如它的灯笼动画是 CSS 的 transform 旋转加背景光晕，没有加入点击交互。我原本期待它有灯笼逐个点亮的效果，但模型没有自动做这个扩展。这再次印证了我在游戏任务里总结的规律：Step-5-Preview 会把基础功能做得很完整，但不会主动添加需求之外的心智负担。

4.3 在“作业级”和“商业级”之间的真实位置

如果把这页拿去和热搜词里常见的“HTML5 网页设计作业代码”做对比，它明显比大多数作业代码高一个档次：布局不塌、动效不卡、移动端适配到位。但如果拿去当商业项目交付，它还缺一些东西——比如没有接入真正的后端表单提交接口，没有加统计埋点，也没有做 SEO 标签和分享缩略图配置。

我的判断是：它非常适合作为“第一版原型”交付。你拿去改品牌色、换文案、接接口，工作量很小。这对新人来说其实是最理想的起点，因为大多数人写第一版页面时，最难的既不是配色也不是布局，而是“从零到一”那一大步。模型帮你迈过去了，你只需要做“从一到百”的优化，难度完全不在一个量级。

5. 三个任务横向对比：Step-5-Preview 的能力边界和我的使用判断

三个任务全部跑完后，我把过程中的关键数据整理成了一张表，方便你直接看能力画像。

5.1 强项和短板，按我的真实感受排序

先说强项。第一，它处理“需要多步推导”的任务时，不会跳步。金融分析里从数据清洗到指标计算，它不像某些模型那样为了省字直接把过程隐掉，而是保留了完整的推理链。这一点在排查错误时价值巨大。第二，它对代码的重构意识明显强于我常用的其他模型。游戏里的对象池、网页里的 CSS 变量抽取、金融分析的函数模块化，都属于工程经验，不是单纯“会写语法”。

再说短板。它有两个比较明显的弱点：过度依赖提示词中的显式指令，缺少追问意识。我在测试三个任务时，它一次都没有主动反问“你的游戏跑在什么分辨率下”“你的预测需要什么置信度”“你的页面要不要适配暗黑模式”。全部靠我先说出来。这在需求明确的场景里没问题，但真实项目往往需求暧昧，需要主动澄清。我用得久之后发现，喂给它越具体的指令，它的表现越超出预期；喂给模糊需求时，它只会按自己的理解默认执行。

5.2 和传统开发流程结合的实操建议

有一个隐藏优点值得单独拎出来说：它对“增量修改”的支持比“整段重写”要好得多。测试中我给游戏加“障碍物加速”功能，给网页加“灯笼点击弹性动画”，都在原文基础上做局部修改，它没有把无关代码打乱重写。对于真实项目维护，这一点极其重要——你不可能每次都把整个文件丢给它重新生成，多数时候只是加一个功能、调一个 bug。

如果把它放进团队工作流，我的建议是把它当作“高级技术合伙人”而非“外包程序员”。先由你（或产品经理）把需求描述清楚，它负责生成 80% 的可用基础代码，剩下的 20% 由你审查、测试和做性能调优。这么分工的原因很简单：它能处理复杂度，但不会替你理解业务的潜台词和约束条件。

另外补充一点安全方面的观察。它生成的代码里没有出现可疑的外部链接请求，所有资源都是本地或内联的。网页设计任务中它试图引用一个字体 CDN，但这个引用是可选的，去掉也不影响页面。对外部依赖的控制做得不错，这在企业内网环境下的价值非常大。

6. 我踩完这一轮之后留下的一些想法

6.1 关于提示词，最值得投入的改进方向

我实测下来的体会是：Step-5-Preview 不吃“花哨”提示词，真正影响质量的是你提供了多少可验证的约束。比如“游戏要适配手机”这句话，远不如“游戏的触控区域要在移动端可用，视口设置正确，横竖屏不报错”来得有效；金融分析里的“检查数据质量”也比“仔细分析”有用十倍。给它明确的验收标准，它的输出会自动朝那个方向对齐。

我在测试过程中总结了一个四层提示模板，分享给你：第一层说明背景和目标，第二层给出可量化的验收标准，第三层定义输出格式（代码、结论、图表），第四层说明环境约束（浏览器版本、数据规模、展示设备）。这三层按顺序写完，Step-5-Preview 的交付速度和质量都会比“一句话需求”好很多。

6.2 它和我平时工作流之间的关系

跑完这三个任务之后，我并没有打算把它的每一次输出都直接当作成品。一个务实的心态是：它适合做“70 分到 80 分”的工作，余下“80 分到 90 分”的打磨，仍然需要人来完成。3D 游戏那个项目里，如果要把画风替换成赛博朋克质感；金融分析那个项目里，如果要接入公司内部的数据口径规范；网页设计那个项目里，如果要加上更复杂的表单验证逻辑——这些都是模型目前做不到、但一个靠谱的开发者花半小时能做到的事。

你拿它当同事看，就会很舒服——因为你知道同事的第一版也不完美，但胜在速度快、态度好、随叫随到。你拿它当神供奉，就会失望。这个认知可能比任何具体功能点都重要。

6.3 最后分享一个小技巧

我每次让它跑项目型任务时，都会额外加一句“请在交付前自查一次，列出你发现的所有问题”。Step-5-Preview 的自查能力比一次生成能力更强。它能在输出前就发现变量未定义、边界条件缺失、数据格式不匹配这类问题，省掉一次甚至两次返工。实测下来，增加这句话后的首次生成可用率，从 50% 提高到了 75% 左右，是个非常划算的提示词投入。

如果你正在考虑把它接到自己的项目流程里，我建议从“网页设计和前端原型”切入，因为这部分交付物可以直接打开验证，反馈链路短、试错成本低。跑顺了之后，再往数据分析、业务流程设计这些反馈链条更长的场景扩展。这条路走通之后，你大概率会跟我一样，再也回不到“从空白文件开始慢慢敲”的工作方式里去了。