我让豆包Doubao-Seed-Evolving模拟一次火箭发射，19分42秒后，长征八号甲真在网页里“上天”了

大家好，我是蓝戒。本篇我们来聊聊：用Doubao-Seed-Evolving开发模拟长征八号甲火箭发射。

从 Three.js 3D 动画、八阶段任务流程，到代码合成引擎轰鸣，再到部署上线：这是一次不剪掉翻车可能、不拿跑分表凑字数的 Doubao-Seed-Evolving 真实开发记录。

先把能玩的版本放在前面：

在线体验：长征八号甲发射3D模拟动画：https://168116.xyz/example/changzhengbahaojia/index.html

页面支持拖动视角、滚轮缩放、八个阶段自由跳转、自动播放和语音开关。建议用电脑打开，把声音调到一个不会惊动邻居的音量，再点“自动播放”。

🎬 【项目完整演示视频】

一、事情的起因：一个模型更新，把我手里的鼠标点痒了

最近我留意到火山方舟 Agent Plan 里的一个新名字：

Doubao-Seed-Evolving｜高频迭代，持续升级。

它的定位很有意思：不是发布一次就把“模型卡”钉死，而是维持统一的 Model ID，在同一个入口上持续更新。官方介绍里重点提到三件事：

• 支持 1M 超长上下文；
• 针对 Coding 和 Agent 场景继续优化，包括代码生成、工程开发、工具调用、任务规划和长程执行；
• 新版本自动生效，不用跟着模型版本反复换 ID、迁移 Endpoint 或修改调用方式。

说人话就是：它不只要会写一段函数，还想在一个比较长的任务里记住“我们刚才改到哪儿了”，继续读项目、改文件、调用工具、检查效果，尽量把活儿做完。火山引擎豆包大模型产品页也把 Doubao-Seed-Evolving 的重点放在 Coding 与 Agent 场景上。

老实说，“1M 上下文”“长程任务”“Tokens 效率”这些词，单独看很容易像发布会里的肌肉照。普通人更关心的是：我给它一个麻烦点、步骤多点、还会中途改主意的需求，它到底能不能接得住？

于是我决定不跑榜单，也不问它“9.11 和 9.9 谁大”。我想让它做一件一眼就能看懂、做砸了也一眼能看出来的事——用 Three.js 模拟一场火箭发射。

灵感来自不久前的长征八号甲发射。根据中国航天科技集团的公开信息，长八甲火箭于 7 月 5 日 21 时 43 分在海南商业航天发射场点火升空，将千帆极轨 15 组卫星送入预定轨道。真实发射看得人热血上头，我也跟着生出一个多少有点“不知天高地厚”的念头：

能不能让大模型在浏览器里，也把这枚火箭送上去？

当然，这不是航天工程仿真，更不是拿网页替代专业飞控软件。我的目标很大众：打开网页就能看懂发射过程，有塔架、有尾焰、有分离动作、有声音，既像个科普小作品，也像一段可以亲手操作的“电子发射直播”。

二、我给它的不是一道题，而是一份会不断变卦的需求

项目使用 OpenCode，模型选择已经接入的 doubao-seed-evolving。技术栈并不花哨：HTML、CSS、JavaScript 加 Three.js，直接在浏览器运行。

一开始的需求，大致可以归纳成这几条：

1. 做一个长征八号甲火箭发射的 3D 动画；
2. 完整呈现八个关键阶段；
3. 页面要能交互，不是一张“看起来很像网页”的静态图；
4. 每个阶段都要有任务时间、说明和对应的火箭动作；
5. 后面想到什么，再继续改。

最后这一条看似最随意，其实最考验模型。现实开发很少有人一次把需求说完。常见情况是：第一版出来以后才发现布局不对；看到画面以后，又想加声音；声音有了，又觉得发射台太简陋；做完还想部署，部署以后还得绑域名。

也就是说，我测试的不是“能不能写 Three.js”，而是它能不能在连续多轮里，始终围绕同一个工程往前推进。

三、第一轮：19分42秒，先把火箭送进浏览器

第一轮从零开始，用时 19 分 42 秒。

模型完成了项目骨架、3D 场景、火箭与发射塔建模、镜头、灯光、阶段时间轴和自动播放逻辑。更重要的是，它没有只交一张“火箭站着不动”的海报，而是把整段发射流程拆成了八个可以切换的阶段：

1. 塔架待命；
2. 点火起飞；
3. 助推器分离；
4. 一级分离；
5. 抛整流罩；
6. 二级滑行；
7. 二次点火；
8. 星箭分离。

第一版给我的感觉很像刚装修完的毛坯房：墙有了，水电也通了，甚至门铃都会响，但你一眼就知道还没到“请朋友来参观”的程度。

火箭能飞、流程能跑，已经比我预想得快；可页面信息密度、右侧特写、火箭材质和镜头表现还比较朴素。它证明了方案可行，却还没让我产生“这东西可以直接发出去”的冲动。

这也是一次很真实的提醒：模型第一版能做出完整骨架，不等于第一版就是成品。 如果只截一张成功画面然后宣布“全自动完成”，那是在给开发过程开美颜。

四、第二轮：9分19秒，不推倒重来，直接在原工程上精修

第二轮我提出两类修改：

• 重排页面展示模块，让任务信息、主视图、阶段时间轴和右侧特写更协调；
• 加强火箭的 3D 细节，让机身、发动机、分离结构和不同阶段的镜头更有辨识度。

这一轮用时 9 分 19 秒，一次性完成。

最直观的变化，是页面不再把所有信息平铺在一起。中间是主场景，右侧是当前阶段的近景特写，下方是八阶段时间轴。用户不用读使用说明，基本就知道哪里能点、现在飞到了哪儿。

这轮真正让我感受到长上下文价值的，并不是它“写得更多”，而是它没有因为我改布局，就把第一轮的阶段逻辑改坏；也没有因为加强火箭细节，就忘掉时间轴和自动播放。

对工程任务来说，上下文长不只是能塞更多文字。更实用的意义是：模型需要同时记住页面结构、对象命名、动画状态、相机参数和用户刚刚提出的新要求。只要其中一处断片，就很容易出现“修好车灯，方向盘掉了”的喜剧现场。

五、第三轮：10分12秒，它不仅让火箭飞，还给现场配上了声

看着火箭无声起飞，总觉得像在办公室摸鱼时静音刷视频——画面有了，灵魂还躲在门外。

所以第三轮，我要求加入：

• 发射前倒计时；
• 八个阶段的中文旁白配音；
• 引擎轰鸣和环境音效处理；
• 页面语音配音开关控制调整。

用时 10 分 12 秒。

有意思的是，模型没有一上来就乱生成音频。它先在工程里规划了一份 Markdown 文档，把 stage_0 到 stage_7 每个阶段要说什么、文件叫什么、放在哪里都列清楚，再去生成对应文件。

最终的人声旁白使用 doubao-seed-2-0-lite-260215 生成，并保存为 stage_0.mp3 到 stage_7.mp3。页面进入不同阶段时，代码按编号加载并播放对应的人声。

但让我意外的，是“引擎轰鸣”并没有再塞一个现成音效文件。模型用浏览器自带的 Web Audio API，通过振荡器、滤波器和增益节点实时合成低频轰鸣。换句话说：

旁白是生成好的音频文件；引擎声和部分环境声，是网页运行时现场“搓”出来的。

下面是项目里的简化核心逻辑：

let audioCtx;
const voiceBuffers = [];
let rumbleOsc;
let rumbleGain;

async function initAudio() {
  audioCtx = new AudioContext();

  // 加载八个阶段的人声旁白
  for (let i = 0; i < 8; i++) {
    const response = await fetch("audio/stage_" + i + ".mp3");
    const buffer = await response.arrayBuffer();
    voiceBuffers[i] = await audioCtx.decodeAudioData(buffer);
  }

  // 用浏览器实时合成低频引擎轰鸣
  rumbleOsc = audioCtx.createOscillator();
  const filter = audioCtx.createBiquadFilter();
  rumbleGain = audioCtx.createGain();

  rumbleOsc.type = "sawtooth";
  rumbleOsc.frequency.value = 48;
  filter.type = "lowpass";
  filter.frequency.value = 120;

  rumbleOsc.connect(filter);
  filter.connect(rumbleGain);
  rumbleGain.connect(audioCtx.destination);
  rumbleOsc.start();
}

这段做法很聪明：低频持续声不需要额外下载大文件，还能跟着点火、上升和关机阶段动态调整音量。缺点也很现实——浏览器通常不允许页面未经用户操作就自动播放声音，所以必须等用户点击“自动播放”或语音按钮后，音频上下文才能可靠启动。

这是我在实践里遇到的第一个“坑”：代码没错，页面也没坏，但浏览器的自动播放策略会让你误以为声音功能失灵。知道原因以后就很好处理：把音频初始化放到用户点击事件里，并给语音状态做清晰提示。

六、第四轮：10分33秒，把“能飞”改成“有现场感”

第四轮我继续加码：

• 加入更接近海南商业航天发射场低位发射台的视觉结构；
• 为每一个阶段补充火箭机身动作的独立特写；
• 让右侧特写不是简单复制主镜头，而是根据阶段切换观察重点。

用时 10 分 33 秒。

这一步对普通观众特别重要。主场景里，火箭飞远以后，助推器分离、整流罩抛离这些动作很容易看成“几个小零件掉下去了”。右侧特写把当前重点单独放大，观众不用懂发动机型号，也能看清这一步到底发生了什么。

丢给模型参考图，按照我的参考图添加海南商业的底台：

模型精准识别后为我一次性添加成功：

实现每阶段火箭机身动作特写：

为了实现这种“同一阶段，两套镜头语言”，代码里为八个阶段分别准备了近景预设。每个预设都可以控制镜头位置、视野角、目标对象和阶段专属结构。

这里还有第二个坑：3D 页面不是“模型越精细越好”。 浏览器要实时渲染，粒子、烟雾、阴影、灯光和辉光全都往上堆，电脑风扇很快就会用实际行动参与火箭发射。

所以最终实现做的是取舍：用几何体和材质抓住火箭轮廓，用粒子与辉光制造点火氛围，把有限的计算量优先放在观众真正会注意的地方。它不是工程级复刻，却能让人一眼认出“这是一场长征八号甲火箭发射”，并且在常见电脑浏览器里顺畅操作。

七、最后一轮：继续抠细节，然后把代码从本地送上公网

最后一轮没有再做大拆大改，主要是整体细节收口：镜头衔接、字体层级、颜色对比、阶段描述、按钮状态、声音触发和不同尺寸下的布局。

这一轮完成度很高。更让我省心的是，前面几轮积累的结构没有散架。项目目录也保持得比较清楚：

项目核心结构大致如下：

changzhengbahaojia/
├─ audio/
│  ├─ stage_0.mp3
│  ├─ stage_1.mp3
│  ├─ ...
│  └─ stage_7.mp3
├─ README.md
├─ generate_audio.py （生成旁白合成语音使用的python脚本）
├─ index.html
└─ main.js

到这里，前四轮有明确记录的时间加起来是：

19:42 + 9:19 + 10:12 + 10:33 = 49 分 46 秒。

不到 50 分钟，完成了从零搭建、两轮视觉与结构修改、配音与声效、发射台和八阶段特写。最后的细节整理和上线没有计入这个数字，所以我没有写“49 分 46 秒全自动上线”——好看归好看，账还是得算明白。

OpenCode本地完成以后，我又用 Codex 中接入连接到免费领取的亚马逊云服务器，把静态项目部署到自己的云服务器；随后连接 Cloudflare 插件，将托管域名解析到服务器 IP。最终从代码目录、远程部署到域名可访问，整条链路也由 Agent 工具协助完成。

这一步让我感受到，所谓 Agent 能力并不只是“回答更长”。真正有用的地方，是它能把写代码、查目录、修改文件、执行部署命令和配置外部服务串成一件事。模型当然不会凭空拥有你的服务器权限，但在权限已经明确、工具已经接好的前提下，它可以少让人来回复制粘贴几十次。

八、这次实测，Doubao-Seed-Evolving 到底强在哪儿？

我不想用几十个指标把文章写成显卡评测。就这次用普通人看得懂的网页项目，我感受最明显的是四点。

1. 它能把需求拆成工程，而不是只吐一段代码

第一轮不是给我一坨无法落地的示例，而是建立文件、组织页面、搭 Three.js 场景、做状态机和交互入口。第三轮处理配音时，它还先生成 Markdown 规划，再生成音频和调用逻辑。

这说明它在尝试管理任务，而不是看到“配音”两个字就立刻写一个 audio 标签交差。

2. 多轮修改时，它没有轻易丢掉前文

我连续改了布局、3D 细节、音频、倒计时、发射台、右侧特写和部署方式。每一轮都建立在上一轮工程之上。

1M 上下文的价值，在这里不是让我一次塞进一本小说，而是让模型有空间保留项目结构、代码和修改历史。它能记住“哪些是已经工作的部分”，后续就更像接着装修，而不是每次都把房子炸了重盖。

3. 长程执行变得可感知，但不等于可以撒手不管

几轮任务都能自己读文件、规划修改、写代码并检查结果，说明长程任务能力确实不是一句空话。但我仍然会在每轮结束后亲手打开页面检查，为下一步在正确基础（对味了）上迭代。

模型看的是代码和工具反馈，人看的是“顺不顺眼”“像不像”“有没有情绪”。例如第一版功能齐全，但视觉还不够震撼；声音虽然接入成功，是不是复合我预期的音效。这些审美判断依然需要人来做。

4. 统一模型 ID，减少了“刚配好又换代”的折腾

Doubao-Seed-Evolving 强调持续进化与统一 Model ID。对我这种把模型接进 OpenCode 的使用方式来说，这一点很实际：后续版本更新时，不必为了一个新后缀重配工具、迁移地址，再挨个项目检查调用名称。

它像一张会更新的模型卡片。今天的体验不是永远不变的结论，但接入方式不用跟着每次升级重新装修。

九、社区里的声音，和我的结果能对上吗？

我也看了一些开发者的公开实践，大家的感受并不是清一色“神了”，反而有几个很一致的信号。

第一，从零做原型、在同一项目里连续迭代，是比较受认可的方向。 有开发者用它做价格订阅系统，经历十多轮修改、多个文件变更、UI 调整和 Bug 修复，仍能围绕已有工程继续推进；也有人用它做面试模拟平台，认为它对项目上下文和增量需求的理解比较稳。

第二，长任务不是不会停，也不是次次一遍过。 有开发者在更长的自动执行中遇到中途暂停，需要手动继续；第一版也可能留下交互 Bug，再通过后续轮次修正。

第三，不同 Agent 工具、网络和执行环境会影响最终体验。 同一个模型放进不同工具里，超时策略、命令权限、上下文组织方式都不一样，不能只凭一次失败或一次成功给模型判终身。

我的结果基本印证了这些反馈：

• 第一轮 19 分 42 秒就拿到了完整可运行骨架；
• 但“可运行”距离“可展示”还隔着四轮调整；
• 后续每轮都能承接上文，一次性完成度较高；
• 真正决定作品质感的，仍然是人是否愿意提出具体反馈。

所以我更愿意把它叫作一个执行力很强、记性更长的工程搭档，而不是“按一下按钮就能取代开发”的许愿机。

十、如果你也想试，怎么把 Doubao-Seed-Evolving 接进 OpenCode？

火山方舟的订阅套餐目前分为两个大类：Agent Plan 和 Coding Plan。截至本次实测与写稿时，我在控制台看到最新的 Doubao-Seed-Evolving 位于 Agent Plan 可用模型中；Coding Plan 更偏向专门的编程模型。模型和套餐列表可能继续更新，最终请以控制台实时展示为准。

入口在这里：

火山方舟 Agent Plan：https://console.volcengine.com/ark/region:cn-beijing/subscription/agent-plan

接入思路并不复杂：

1. 在控制台开通或确认 Agent Plan；
2. 获取对应的 API Key；
3. OpenAI 兼容工具使用 Base URL：https://ark.cn-beijing.volces.com/api/plan/v3 Anthropic 兼容工具使用 Base URL：https://ark.cn-beijing.volces.com/api/plan
4. 模型 ID 填：doubao-seed-evolving
5. 在 OpenCode 中选择该模型，新建一个小项目先验证读写文件和运行命令是否正常。

如果已经安装 ArkCLI，也可以让它为 OpenCode 写入 Plan 的 model/provider 配置。建议先确认当前状态，再执行配置：

arkcli auth status
arkcli helper list
arkcli helper configure opencode \
  --profile <你的-agent-plan-profile> \
  --model doubao-seed-evolving

ArkCLI 的公开版安装命令是：

npm i @volcengine/ark-cli -g

配置完成后重启 OpenCode，让新配置重新加载。第一次别直接让它造火箭，可以先让它建立一个最小网页、读取现有目录并启动本地预览。确认模型、文件权限和命令执行都没问题，再上复杂任务，排错会轻松很多。

还有三个经验，能少踩坑：

• 需求写“验收结果”，少写空泛形容词。 比如不要只说“更震撼”，可以说“点火阶段要有尾焰、烟雾、镜头轻微震动，右侧显示发动机特写”；
• 每轮只围绕一个主题改。 布局、声音、模型细节等分开做，更容易定位问题；
• 让模型自己检查，但人必须体验。 自动化能发现报错，却很难替你判断一段倒计时到底有没有紧张感。

十一、写在最后：这一次，我看到的不是“会写代码”，而是“能把事往前推进”

如果只看某一段 Three.js 代码，这个项目并不神秘。灯光、相机、粒子、音频、状态切换，网上都能找到教程。

真正让我觉得国产大模型进步很快的，是这些零散能力被串在了一起：

它先理解目标，再拆任务；能从零搭起工程，也能承接四轮“临时加需求”；能写 3D 动画，也会规划配音文件；能调用人声模型生成旁白，还能用 Web Audio API 合成轰鸣；最后继续处理部署和域名，让项目不只躺在本地文件夹里。

当然，它没有一次就做出终稿。第一版粗糙，声音受浏览器策略限制，3D 效果也必须在画质与性能之间妥协。可正因为这些问题都真实存在，最后的效果才更有参考价值。

大模型最像搭档的时刻，不是它用一段漂亮话告诉我“当然可以”，而是我说“这里不够像，再改一下”，十分钟后它把新的页面交回来，而且前面的东西还在。

以前看到火箭发射，我会想：真壮观。

这次看到网页里的火箭升空，我多想了一句：

原来一个普通人有了合适的 Agent，也能把脑子里那个不太靠谱的念头，做成别人点开就能玩的东西。

这大概就是 Doubao-Seed-Evolving 这张“永远更新的模型卡片”，目前给我最具体的一次答案。

本文中的 3D 页面为科普向艺术模拟，不构成真实弹道、结构或飞行参数仿真；火箭任务背景以公开信息为依据。页面旁白由模型搜集信息生成，轰鸣与部分环境声由 Web Audio API 实时合成。模型能力与套餐范围会持续更新，请以火山方舟控制台最新信息为准。