「持续进化」的模型，「Seed-Evolving」能解决「快、稳、省」的“不可能三角”吗？

从2022年GPT发布至今，大模型的迭代速度越来越快。之前，模型发布以“年”为单位；ChatGPT引爆市场后，节奏被压缩至“季度”；而进入2024年以来的军备竞赛期，头部玩家如OpenAI、Anthropic已将重大更新的平均间隔缩短至不到两个月（约50-60天）。

尽管如此，即便模型一发布就能公开使用且无算力限制，下游的开发者或公司至少也需要2个月才能将同一家公司的新模型投入实际使用；现实中的时间往往更长——每一家模型版本的更迭，从应用、适配、迁移到测试与推广，每一个环节都意味着可观的团队精力消耗。

因此，AI在企业的应用，天然就存在着一个新的“不可能三角”——新模型应用要“快”，生产环境要“稳”，人力投入要“省”，而谁能快速解决这个问题，无疑将在企业AI市场的token大战中占据先机。

正是基于以上问题的思考，我注意到火山引擎近期刚发布了一个模型—— Doubao-seed-evolving。

什么是 Doubao-seed-evolving?

从官方的介绍来看，它是一张永远“最新”的模型卡片。

开发者只需通过一个固定模型ID（doubao-seed-evolving）发起调用，后台始终连接当前最强的版本，并且承诺按周更新。

这种设计，本质上是在用产品化的方式解构上述"不可能三角"：用固定的API接口换取生产环境的"稳"，用每周至少一次的版本更新兑现能力进化的"快"，用零摩擦的自动升级实现人力投入的"省"。

然而，目前有两个核心问题需要回答：

1. 豆包 Seed-Evolving 的真实能力如何？在Coding工程交付与Agent长链路任务两大核心场景中，它的胜任度到了什么水平？
2. "每周迭代"，是否真的能在复杂工程任务中兑现为可感知的能力提升？相比同系列最新发布的模型（如豆包 Seed-2.1-pro），效果是否有实质提升？

带着上述疑问，我开通了火山引擎的Agent Plan，从仓库理解、长程规划到受控故障修复三个维度，对Doubao-Seed-Evolving 进行了独立实测。

评测总览

本次评测共设计四个任务，分别考察模型在不同难度层级上的表现：

一句话总结：

「能干活」：Seed-evolving模型已经明显超过了”写代码“”给答案”的水平，和前沿的模型一样，它达到了「能干活」的水准。

从测评来看，它能进入代码仓库，表现出较强的仓库理解、任务规划拆解、调用浏览器和终端，并持续推进多个阶段的工作。

「人放行」：在设计和视觉，长程的代码开发最终是否成功，还需要人工进行最终审核确认。

准备工作

在进入案例之前，先说明本次评测的基建配置：

• 「订阅套餐」：Token使用的是火山 Agent Plan的medium套餐，一个月有10万燃料值（不是token）。
• 「API配置」：在codex进行了API的配置和接入。

订阅和配置方式可以参考：【教程】如何开通火山Agent Plan，接入Codex使用

下面我们来详细看下测评的案例及过程。

案例1：从HTML Studio 代码库自动生成产品介绍

任务设计

为了验证模型Agent长程任务的能力，我让它基于本地项目的代码仓库，自动化生成一份产品介绍，并设计成一个官网页面。

这个任务要求满足几方面的能力：

• 「懂项目」：能通过代码库获取到产品的关键信息
• 「调工具」：能自主调用浏览器，并进行截图和保存
• 「能输出」：会综合上述信息，进行产品介绍的编写
• 「会设计」：能按照要求，进行可视化呈现

代码和产品文档分散在多个文件里，既要理解产品，也要理解工程实现；任务无法靠单次对话完成，需要不断读取、修改、运行和检查，比较接近真实Coding Agent的工作环境。

测评说明

这个Case选用个人真实进行中的产品来做测试：

HTML Studio 是一个基于个人管理AI生成文档不断演进出来的本地HTML文档编辑器，已经持续迭代几十个版本。它可以管理和编辑 HTML、Markdown 文档，涉及文件读写、可视化编辑、管理历史版本等。

【AI Agent实战】我是如何用superpowers开发出HTML编辑器的？1个小白可以持续迭代的方法 (https://github.com/louisecxqiu-glitch/html-doc-center)

任务要求模型理解HTML Studio代码库、启动本地服务、调用浏览器完成核心功能截图，再以Claude/Anthropic风格生成产品介绍的HTML页面。

这类任务同时包含产品理解、工具调用、内容抽象、视觉设计与交付验证。

Prompt

把 HTML Studio 的页面功能做下截图，做一份产品重点功能介绍，
采用Claude 样式。

模型执行过程

1. 理解意图：—— 智商在线 👍 模型拿到任务后，没有直接开始编页面。它先把仓库定位交给一个代码探索子任务，要求只搜索和读取，不修改文件，并重点检查入口、项目结构、启动方式、README 和主要功能模块。

图 1：模型先拆出代码探索任务，而不是直接生成页面

1. 运行工具——能力在线👍 服务探活后使用Playwright批量截图，覆盖主工作台、文件树、Markdown编辑、设置、快捷键、历史、分享等功能。

dfca0d6c214c410f97e38aada9685131.png-resize250

自动运行截图脚本，完成重要功能截图；

1. 生成产品介绍页——理解在线👌

【效果评判】

产品介绍页首屏。视觉方向基本成立，产品定位和基线信息清晰。

做得好的部分

• 项目理解不是照抄旧记忆：它在代码和运行服务中校正了版本与实际能力。
• 工具链完整：子代理定位、服务探活、Playwright探测、批量截图、HTML生成形成连续工作流。
• 产品抽象较准确：local-first、HTML/Markdown、时间旅行、分享、密码保护、可视化编辑等核心能力被抓住。
• CSS问题定位：发现编辑画布透明背景问题后，能够沿iframe、editor-shell和GrapesJS画布容器定位到CSS层。

存在问题

首版页面虽然"看上去在线"，但首版有一个很实际的问题：页面里的产品截图没有正常显示。

也就是说，模型完成了“生成页面”，却没有完成“最终用户打开页面能看到完整内容”这一层验收。在我指出问题后，它重新检查浏览器请求，并进行了验收。

模型在用户指出后给出的根因与修复

最终效果视频

案例1总结

结论：通过这个测评案例，可以看到：doubao-seed-evolving已经较好地具备“读代码库-理解产品-运行产品-自主操作（截图）- 整合内容- 设计输出”的能力，而不是简单套模板；模型足够强了，但交付是否合格能正式使用，还需要我们自己来做个把关。

费用：消耗Token：2000燃料值，当前包月50元，花费约1块钱。

案例2：HTML Studio编辑器内核升级

任务设计

在确定了Seed-Evolving具备干活能力后，我决定给它布置一个更高难度的任务——对HTML Studio的HTML编辑能力进行大升级。

这个任务要求能满足几方面的能力：

• 「理解用户痛点」：不仅仅懂项目，还需要理解用户的痛点和问题；
• 「基于目标拆解」：探索解决用户痛点和问题的方法，并且进行拆解；
• 「长程编码实现」：基于以上方案进行持续迭代，直到目标实现。持续的运行时长预计是小时以上级别。

测评说明

HTML Studio 现有编辑体验不稳定，布局不够灵活，旧工具栏在编辑内容和插入表格时，经常出现问题。我已经调研了 GrapesJS、ProseMirror、CodeMirror 等开源方案，希望把工作台升级为：

• 可视化、富文本、源码三种编辑模式；
• 用户可以对HTML的布局、指定的文本进行灵活修改；
• 修改过程可见、可审核、可撤销；
• 文档出现问题时能够恢复历史版本；

任务要求

这次使用的是Codex的goal（目标）功能来进行迭代，与一个个小功能持续迭代不同，这要求模型端到端完全自主，且运行几个小时不跑偏，非常适合考验 doubao-seed-evovling的长程编码能力。

【预计运行时间】2个小时以上

模型执行过程

第一阶段：调研及改进分析

对选定的几款开源框架，进行分析，制定改进计划。

请对当前产品的下一阶段升级进行产品定义、技术调研和实施规划。
本轮工作必须从用户故事和产品目标出发，而不是直接根据 GrapesJS、ProseMirror、CodeMirror 等开源组件反推产品功能。
正确顺序是：
用户问题
→ 用户故事
→ 产品能力定义
→ 关键交互流程
→ 功能需求与优先级
→ 技术方案
→ 开源组件选型
→ 实施路线图
→ 验收标准
本轮只进行：
1. 现有产品和代码调研
2. 用户故事梳理
3. 产品定义
4. 功能方案设计
5. 技术架构分析
6. 开源组件选型
7. 风险分析
8. 分阶段实施规划
9. 输出分析报告
本轮禁止修改产品代码、安装依赖、更新版本号或 CHANGELOG。完成报告后等待我确认，再进入实施阶段。

再次强调：
本轮先根据用户故事完成产品定义，再根据产品定义制定功能和技术方案；不得从现有开源组件直接反推产品需求。本轮不得修改任何产品代码。

我在提示词里明确要求：第一轮只进行现状调研、用户故事、产品定义、架构分析、开源组件选型和实施规划，禁止修改代码。

模型遵守了这个约束。模型先做产品定义，没有急着改代码。

它先读取server.py、保存链路、编辑器桥接和现有文档，没有根据文件名判断功能是否已经完成。8 分 33 秒后，它生成了第一版分析报告，并给出一组需要我确认的产品和技术决策。

附件中可见的关键建议包括：

• HTML 优先，Markdown 后续跟进；
• 保留 GrapesJS 作为可视化编辑器；
• ProseMirror 定位为局部富文本编辑器，不作为全局文档模型；
• ……

这部分让我比较满意的，是它没有被现有开源组件牵着走。先从“用户怎样编辑、AI怎样修改、错误怎样恢复”出发，再决定GrapesJS、ProseMirror 和CodeMirror 分别承担什么角色。

第二阶段：13 分钟把报告做成可视化页面，但设计并非没有瑕疵

为了单独测试模型的网页设计能力，我要求它不使用本地设计或前端 Skill，直接把分析报告做成一个可视化单页。

13 分 33 秒后，它生成了一个深色科技风页面，完整覆盖报告的 11 个部分，包括执行摘要、当前能力、用户故事、能力地图、AI 并发、历史版本、架构、路线图、决策和风险。

整体视觉层级清楚，导航、卡片和数据状态也基本统一。但这份页面并不是“完美级别”。

在“三编辑器真实状态”区域，卡片列宽分配不合理，部分中文被挤成竖排，阅读体验明显下降。

这个缺陷还算可以接受：模型可以快速做出视觉方向完整的页面，但响应式布局、极端文本长度和真实内容密度仍然需要人工检查。

第三阶段：进入 Goal 模式，开始长程开发

完成产品定义后，我把完整开发目标交给 Codex Goal 模式，选用seed-evovling模型。

任务被拆成四个阶段：

• 三模 HTML 编辑、Markdown 升级、属性面板、组件库和复杂页面降级；
• Undo/Redo、快照、版本链和历史恢复；
• AI 选区修改、Diff、接受/拒绝/重新生成、AI 撤销和服务端代理；
• 用户与 AI 并行编辑、多 AI 任务队列和基于Hash/Rebase 的冲突检测。
• 同时设置了严格停止条件：阶段功能、P0/P1、自动化测试、版本文档和安全检查没有全部完成前，不能把任务标记为完成。

此时已经是凌晨一两点，我打开屏幕录制，第二天早上起来验收，发现项目没有全部完成。查看录制内容，发现由于token方面的限制，跑到一半就停止了。最终目标没有全部实现，只实现了部分功能。

【效果评判】

在对HTML布局修改s ，整合了GrapeJS的能力，实现了按需拖动和修改组件的布局。

最终效果视频

【结论】做得好的部分

• 规划和理解能力：理解需求，规划与架构能力上有一定经验的工程师水准；
• 长程能力和1M上下文：记录里来看，前面步骤严格遵从要求，进入到Phase1。

存在问题

• 和先前案例一样，在视觉QA上略微欠缺。
• 由于Token限制，这个任务缺少了Phase 1～4之间具体的执行情况。1M上下文的临界点没有被触发，长程能力也有待进一步挖掘。（正因如此，后续增加了case4 进行验证）

案例2总结

费用：直接触发限额，2%～10%，花费约8块钱。

案例3：seed-evolving PK seed-2.1-pro Lexical IME受控故障修复

任务设计

为了测试「按周更新」的evolving和最新的模型之间是否存在差距，本轮基于Meta Lexical v0.47.0制造一个受控回归：在segmented TextNode中间进行IME composition时，代码错误地替换节点，导致节点key与DOM身份变化。

测评说明

Lexical 是一个结构复杂的文本编辑器框架。此次故障发生在中文输入法的 composition 过程中：

当用户在一个 segmented TextNode中间进行中文组合输入时，原有逻辑会用新的普通 
TextNode替换旧节点。
从普通文本编辑角度看，这种替换似乎没有问题；但在中文输入法组合阶段，浏览器正在持续追踪原来的 DOM 和节点 key。一旦节点被替换，输入法绑定的“锚点”就可能失效，进而出现：
- 中文输入中断；
- 候选输入状态异常；
- 文本重复或光标位置错误；
- 原节点的格式和样式丢失。

这类问题的难点在于：表面上是输入法异常，真正的根因却在编辑器内部节点生命周期、Selection 更新和 composition key 的关联机制中。

为了验证模型在真实开源代码库中的 Bug 定位、代码修复和回归测试能力，我设计了一次控制变量测试：

将完全相同的Lexical代码仓库复制两份，分别交给：

• 豆包 Seed-Evolving
• 豆包 Seed-2.1-Pro

两个模型面对相同的故障、相同的测试用例和相同的验收标准，并且都被禁止访问互联网或搜索公开修复记录。

这个任务主要考察四方面能力：

• 「能定位」：能否跨文件理解IME、Selection、TextNode和composition key的关联
• 「修得准」：能否触及真正的代码根因，而不是绕过测试
• 「会验证」：能否运行目标测试、全量测试和静态检查
• 「能闭环」：能否主动补充边界测试，并如实说明尚未验证的部分

Prompt

阅读仓库根目录的 BENCHMARK_TASK.md 并完成任务。
请注意所有的操作和记录都局限在这个仓库内。
禁止：访问互联网，禁止搜索公开修复记录。
必须：保存完整对话、工具调用次数、耗时、代码差异和测试输出

为了保证对比公平，两个模型分别在独立的仓库副本中执行，不能读取对方的代码和结果。下面我们来看下两款模型的表现：

模型执行过程

两个模型都先运行测试复现问题，随后将根因定位到：

packages/lexical/src/LexicalSelection.ts

它们采用了相同方向的修复：

• 中文输入法组合期间不再替换节点；
• 将节点从segmented原地切换为normal；
• 保留原节点key、格式和样式；
• 非IME输入继续保持原有逻辑。

这说明两个模型都理解了故障根因，而不是通过修改测试或增加特殊判断绕过问题。

Seed Evolving：修复后继续补测试

Seed Evolving完成核心修复后，又主动增加了两条边界测试：

• 验证IME期间插入非空文本；
• 验证节点样式变化时仍然保留key。

最终完成：

• 4743项单元测试；
• 新增2项边界测试；
• ESLint、Prettier和TypeScript检查；
• 日志实际工具调用28次。

Seed 2.1 Pro：核心修复正确，但较早结束

Seed 2.1 Pro同样完成了正确修复，并通过：

• 4741项单元测试；
• ESLint检查；
• 日志实际工具调用34次。

它在过程中提出要补充边界测试，但最终没有真正增加测试，也未见Prettier和TypeScript检查记录。

结果对比

案例3总结

两个模型都能准确定位并修复Lexical中文输入法故障，核心代码能力差距并不明显。Seed-Evolving的优势主要体现在修复之后：它主动增加边界测试、完成更多工程检查，并以更少的工具调用形成了更完整的验证证据。

Case 4：Pixel Adventure 马里奥小游戏

任务设计

为了进一步验证模型在长程任务中的执行能力，设计了一个马里奥小游戏的编写任务，看看模型从零开始搭建一个完整游戏项目的表现。

测评说明

本次任务要求模型从零开发一款可以直接运行的2D横版平台跳跃小游戏。这是一个典型的前端全栈任务，涉及需求分析、技术设计、代码实现、测试、问题修复和最终验收等多个环节。

Prompt（摘要）

你是一名资深游戏开发工程师。请在当前空项目中，从零开发一个可以直接运行的2D横版平台跳跃小游戏。这是一次模型对比测试。请独立完成需求分析、技术设计、代码实现、测试、问题修复和最终验收。不要只给方案，也不要等待我逐步确认；在不存在实质阻塞时，请持续工作直至交付可运行版本。

完整Prompt包含十个章节，涵盖：产品定位、技术要求、核心玩法、游戏手感、关卡要求、视觉和界面、声音、数据与状态、测试与验收、交付内容。总计约2000字的需求文档。

模型执行过程

模型连续运行了1小时17分钟，最终完成了游戏创建和自动测试：

• 17个模块
• 2445行代码
• 分层架构设计
• 全部需求覆盖
• 90个测试用例

效果评判

启动后，运行顺畅，游戏操作，音效正常，可以正常通关。

但是发现了一个瑕疵：小人没法跳到平台上去。

最终效果视频

【结论】做得好的部分

• 代码生成能力上表现很强——17 个模块、2445 行代码、分层架构、全部需求覆盖、90 个测试。
• 长时间工作：连续执行了1个小时17分钟。

存在问题

1. Audio 命名冲突：在 vm 沙箱中测试全绿，到了真实浏览器就崩。测试环境和真实环境之间有一道墙。
2. 跳不上平台：跳跃参数拍脑袋定的（73px 高度），平台放了 100px 高，测试只验证了"vy < 0"而没验证"够得到"。

案例4总结

代码生成能力和持续工作能力令人印象深刻，但"测试通过"不等于"真实可玩"。物理参数的调优需要人工介入。

费用：从2.5万燃料值到3.1万燃料值，耗费6000燃料值，约3块钱。

最终结论

豆包 Seed-Evolving在本次实测中表现为一个能力较强、行动积极、尤其适合复杂Coding与Agent任务的模型。它能够理解真实仓库、构建阶段计划、组合多种工具，并在受控故障中完成正确修复与测试补强。

但 "强"不等于"免检" 。Case 1证明它可能漏掉最基本的资源可见性；Case 2证明漂亮首屏并不意味着整页通过响应式验收；Case 4证明它能写出2445行代码，却可能让玩家跳不上一个平台。它的价值在于显著降低资深人员的执行负担，而不是取消资深人员的验收责任。

回到开篇提出的"不可能三角"——豆包 Seed-Evolving用产品化的方式给出了一个值得关注的解：固定的API接口换取"稳"，每周迭代兑现"快"，零摩擦升级实现"省"。

说明：本文属于个人案例观察情况，由于时间/样例方面的限制，可能存在一定的偏差，需要理性看待和判断！