企业官网建设流程全解析

目录

• 写在最前：这次升级到底强在哪
• 起因
• 方案：6 步 Agent 流程
• 18 分钟发生了什么
• 它做对了什么
• 它踩了什么坑
• 底稿长这样
• 方法论：这套流程可以复制
• 写在最后
• 附：本次 Case 用的资源

一次"草图 → 多页面旅行 App"的完整实测：覆盖 design2Code、Agent 跨页面一致性、Token 效率、端到端开发！

写在最前：Seed-2.1-pro 升级到 0915 后，并不是只刷了几个 benchmark——它把"看图写代码"和"Agent 长流程"真正拼到了一起。这次升级的几个关键数字我会在文中逐项实测：

• Coding 工程能力：design2Code 转向 +18%，复杂前端任务 +20%，复杂代码仓库 +12.4%，deepswe 深度软件工程 +33%
• Agent 工具调用可靠性：38.4% → 64.8%，少编造、少抢答、多等真结果
• Token 效率：输出 token −5%，思考 token −11%，工具调用次数 −43%（综合下来 Coding 任务成本降 40% 以上）
• 多模态理解：图像元素定位与 grounding 准确度比上一代 +10% 以上，密集图文文档解析更强

这次案例的几个标签：

• ✅真实任务：一张手绘草图 → 移动端旅行 App，从输入到产物全跑通，不是只列参数
• ✅多模态 Coding：design2Code 场景落地，糙图直接变设计稿
• ✅多模态 Agent：一次生成多页（首页 + 详情 + 行程 + 我的），跨页面保持视觉一致
• ✅端到端：从理解需求、写代码，到浏览器实测验证，一气呵成
• ✅Token 效率实测：单页 9480 tokens / 多页约 10000 tokens，比我之前用过的同类工具少 30%+
• ✅结果可看：产物是单文件 HTML + 浏览器实际运行截图，不是文档里贴代码片段

这个案例"经典"在哪：草图→多页面 App 是 Seed 这次升级最擅长、最值得拿出来讲的能力组合——草图理解、设计稿还原、多页一致性、Token 成本控制，刚好都在这次升级的红利区间内。

起因

上一期拿了 Seed Evolving 第二期的奖后，我对这个模型的兴趣反而更深了——不是 AI 多厉害，而是它真的能帮我干具体的活。

这次 Seed-2.1-pro 升级到 0915 版本，官方反复在讲"看图写代码"和"多模态 Agent"。我把官方通稿里的数字拎出来对着看一下：design2Code +18%、复杂前端 +20%、复杂代码仓库 +12.4%、deepswe +33%。作为一个写前端代码的人，我对这些数字很在意——因为这是我平时最痛的工作环节。

想法很朴素：画一张草图，看 AI 能不能直接把它变成能跑的页面，跳过设计稿这一步。如果它能跨页面保持一致，那就更好——做新项目时，设计师最怕的不是画一张图，是三张图风格对不上。

测试目标定得很简单：

• 输入：一张手绘的旅行 App 线框图（拍照的或者扫描的）
• 输出：一个完整 HTML 文件，双击就能在浏览器打开

模型就一个：火山方舟的 Seed-2.1-pro-0915。

草图是怎么画的

我不会 Sketch，也不打算现学。就用 AI 生成了张"模拟手绘"的线框图，反正核心是验证模型能不能读懂这种糙糙的图。

这张图里有这些信息：

• 顶部写着 “CityGo”——就是我想做的旅行 App 名
• 第二行 “杭州 ☀ 晴 25°C”——定位是杭州
• 中间一个虚线大框，标注"照片占位符"——这是首屏的大卡片
• 下面三个小卡片，写着 Day 1/2/3，里面有山、碗、塔的简单涂鸦——分别代表自然、美食、古迹三种主题
• 再下面三个圆点配横线，写着"西湖"“灵隐寺”“河坊街”——这是必打卡地点列表
• 底部一个圆角矩形，里面四个图标：房子、放大镜、心、人——下面写"首页 搜索 收藏 我的"

就这样，没了。圆圈、矩形框都是歪的，“CityGo” 的 C 和 G 写得大小不一。设计师看了估计想砸键盘。

怎么把图喂给模型

我用的是火山方舟的多模态 API，接口和上一期用的 Seed Evolving 一样，只是模型换成了 0915 版本的 endpoint。

代码本身不长，核心是把图片转成 data URL 然后塞进 messages 里：

importbase64importrequestsfromdotenvimportload_dotenv load_dotenv()withopen("sketch_design.jpg","rb")asf:image_data=base64.b64encode(f.read()).decode("utf-8")headers={"Content-Type":"application/json","Authorization":f"Bearer{os.getenv('ARK_API_KEY')}",}payload={"model":"ep-xxxxxxxx",# Seed-2.1-pro-0915 的 endpoint"messages":[{"role":"system","content":"你是一个资深前端工程师，擅长把手绘草图变成可运行的 HTML/CSS/JS 代码。仔细识别草图里的所有元素，用现代美观的样式重新表达，输出一个完整单文件 HTML。"},{"role":"user","content":[{"type":"text","text":"请分析这张草图，生成移动端旅行 App 页面"},{"type":"image_url","image_url":{"url":f"data:image/jpeg;base64,{image_data}"}}]}],"max_tokens":8000,}resp=requests.post("https://ark.cn-beijing.volces.com/api/v3/chat/completions",headers=headers,json=payload,timeout=180,)content=resp.json()["choices"][0]["message"]["content"]

提示词我写得很克制，只强调了两点：识别所有元素、输出可直接运行的 HTML。剩下的我没限制，让模型自由发挥。

等了 18 秒，发生了什么

调用过程很安静，18 秒返回。

我先把 response 解码出来看一眼数据结构：input tokens 1550，output tokens 7930，总计 9480。比我预想的少——之前用同类工具生成复杂页面，输出 token 一般得上万。

然后是扒代码。返回的内容包在html标记里，我用正则把代码部分提出来存成 index.html。

文件大小 21KB。打开来看——

我盯着屏幕愣了几秒。

这就是那张草图应该有的样子。

我不知道该怎么描述这种感觉。就好像我随手画了个房子的草图，AI 不仅按图施工，还请了个室内设计师帮我做了软装——配色、灯光、家具摆放，全是专业的活。

草图里那个歪歪扭扭的 “CityGo”，被还原成蓝色加粗字体配 EXPLORE·HANGZHOU 副标题；“杭州 ☀ 晴 25°C” 被做成了右上角的圆角天气组件；底部的四个图标做成了玻璃拟态的导航栏。整体配了一整套 brand-50 到 brand-900 的蓝色色阶，背景是淡蓝、粉、淡绿的 radial-gradient 叠加。

我把生成的代码和草图对照了一遍，然后慢慢意识到几件事。

它比我做得好在哪

元素识别是 100% 命中

我把草图里所有的元素都数了一遍——标题、天气、景点卡片、Day 1/2/3、三个地点、底部导航栏——模型一个不落，连 “CityGo” 这个品牌名都准确还原。

更让我意外的是图标：草图里 Day 1 是个山、Day 2 是碗面条、Day 3 是塔楼，模型直接对应成了"群山览胜·宝石山断桥"“杭帮美食·楼外楼·河坊街”“禅意古刹·灵隐寺·飞来峰”——它读懂了图标的语义，然后填了真实对应的主题。

注意看上面这张：每个 Day 卡片都有真实图片（虽然是占位 Unsplash 图）、主题词、地标子标题。模型不是在画卡片，它是在构建一个产品。

文案写得比我像产品

我自己都没想到 Day 1/2/3 三个卡片用什么文案合适，模型自己填了：

• Day 1 · 群山览胜 - 宝石山·断桥
• Day 2 · 杭帮美食 - 楼外楼·河坊街
• Day 3 · 禅意古刹 - 灵隐寺·飞来峰

每个都有主题、有地标、有意境，不是干巴巴的"景点1/2/3"。

地点列表那边更到位，每个地点都有"淡妆浓抹总相宜·世界文化遗产"这种文化气息的副标题，距离精确到 0.1km（1.2km、5.8km）。它甚至在评分旁边用星级符号标识。

它不只是翻译，是重新设计

草图是线框，输出是成品。

模型自己定义了一套设计系统：用 Tailwind CSS，配了一整套 brand-50 到 brand-900 的蓝色色阶，背景是淡蓝、粉、淡绿的 radial-gradient 叠加。每个卡片都有圆角、阴影、hover 效果，底部导航栏用了玻璃拟态。

这不是"还原草图"，这是"理解草图背后想要什么样的产品"。

注意上面这张地点列表：三个推荐地点分别配了不同颜色的圆形图标（蓝色波浪、橙色塔门、紫色建筑），每个都有星级评分、距离、简短描述。底部导航栏的"首页"用蓝色高亮，选中态清晰。

这些细节草图里一个都没有，全是模型自己设计决策的结果。

一次跑通，没返工

生成的代码用的是 Tailwind CSS CDN + Font Awesome + Noto Sans SC 字体，零构建依赖。

我把index.html文件直接双击，Chrome 打开——没改一行代码，页面就完整呈现了。

我以前用类似工具的经验是：生成的代码要么元素漏一半，要么样式一团糟需要大改，要么动效和草图不一致。这次基本不用动，这种"端到端"的体验正是这次升级重点强调的能力之一。

单页不够，那就上多页

首页能跑只是第一步。一个真正的旅行 App 不可能只有一个首页：用户进了首页要能点开"西湖"看景点详情，要能展开"Day 1"看完整行程，要能进"我的"查看自己的收藏和足迹。

于是我重画了一张草图——这次画了三个页面并排：景点详情页（顶部头图 + 评分 + 游玩信息 + 推荐路线 + 加入行程按钮）、行程详情页（行程标题 + 进度条 + Day 1/Day 2 时间线 + 天气）、我的页面（用户卡 + 三个统计 + 常用功能菜单）。三个页面用同一套蓝色品牌色，圆角和阴影保持一致。

把三页草图打包，发给 Seed-2.1-pro-0915，让它在一个 HTML 文件里同时输出三个页面，并通过顶部 Tab 互相切换。Prompt 里只多了一句：“三个页面要保持视觉一致性：使用同一套品牌色，同一套圆角和阴影风格。”

模型大约用了 20 秒返回。这次输出比首页多了大约 30%，接近 10000 tokens——多页面的代码量和复杂度本来就该多一些。

我扒出代码存成subpages.html，浏览器一打开，顶部一个 Tab 切换器，点哪个切哪个。三张页面看起来像同一个人做出来的：

上面这张是「景点详情」：顶部 Hero 图是西湖的实景（Unsplash），标题、5A 标识、评分、游玩信息、推荐路线，一气呵成。注意"加入今日行程"按钮的渐变蓝色和首页的主题色完全一致——这就是我在 prompt 里强调的"视觉一致性"。

这张是「行程详情」：顶部是行程概览和进度条（3/8 已完成），中间是 Day 1 / Day 2 的时间线，每个时间节点都有时间、标题、状态（已游玩 / 正在前往 / 未开始）。底部是这两天的小天气卡。

这张是「我的」：渐变蓝色用户卡显示等级和登录天数，三个统计数字（行程 / 收藏 / 足迹），下面是一组带彩色图标的菜单列表，最后是设置和帮助。

三个页面之间切换很顺滑，没有样式错位、没有品牌色偏差。我点开 DevTools 翻了翻代码，确认是模型自己建的统一设计系统——Tailwind config 里定义的 brand-50 到 brand-900 在三页里都引用同一个变量，boxShadow 的命名也一致。

这一次才真正体会到"多模态 Coding Agent"的意思。它不只是翻译一张图，它能在多张图之间建立语义关联，保证产品的一致性。换个角度看：模型在我的 prompt 里只写了一句"保持视觉一致性"，但它真的照做了——这点对人类设计师都不容易。

在豆包里我也顺手试了一下

既然手头就有最新版的 Seed-2.1-pro-0915，我顺手在豆包里用相同的草图问了一遍：让模型基于这张三页草图继续扩展"详情页"的"加入行程"动作。

我对它提了三个细节要求：(1) 详情页点"加入今日行程"后，行程页 Day 1 时间线要自动出现一个新节点；(2) 节点颜色用品牌色；(3) 弹出一个轻提示，不要打断阅读。模型大约 10 秒返回，给出的做法是：在详情页用localStorage存状态，行程页启动时读取并插入新节点——和我自己脑补的方案一致，没有用任何花哨的依赖。这种"听话、不抢答、不编造 API"的表现，跟这次升级强调的工具调用可靠性（38.4% → 64.8%）的体感是一致的。

最后完成效果如下：

哪里还有遗憾

不是没有问题，我得诚实说说。

对图标语义的解读有偏差。我画 Day 2 是个碗，模型理解为"杭帮美食"——这个解读其实合理但过于具体。我原意其实是"特色体验"或者"当地特色"，碗只是随手画的图标。从这点看，多模态模型还是偏向"按字面意思"理解。

地点列表只有三个，没做扩展。草图里就三个地点，模型老老实实只生成了三个。如果我想生成 10 个推荐地点，得自己再调一次 prompt。这其实不是模型的问题，是我没在 prompt 里说明扩展需求。

响应式断点我自己加的。生成的代码本身是 mobile-first，但没做平板/桌面端适配。当然，对一个 App 原型来说这不算问题。

整体来看，遗憾的点都是"我自己需求没提清楚"，不是"模型能力不够"。

Token 消耗实测

9480 tokens 干完一整页。我之前用过的类似工具，生成这种复杂度一般要 12000-18000，少了 30% 左右。

输出 7930 tokens，思考 token 我看不到单独数据，但响应速度很快——18 秒返回，说明思考 token 也不多。

这跟官方宣传的"输出 token 减少 5%，思考 token 减少 11%，工具调用次数降 43%"对得上。考虑到效果本身在进步（design2Code +18%，复杂前端 +20%），效率提升是真值。算上峰谷价差，Coding 任务平均成本能省 40% 以上——这把"能跑 + 省 token + 不返工"三件事一起拿下了。

一些个人感受

跑完这个 Case，我脑子里冒出来的不是"AI 又进化了"，而是"前端工程师的工作方式可能要变"。

以前做新项目，流程是：产品经理给需求 → 我画线框稿 → 给设计师 → 设计师出设计稿 → 我切图 + 写代码。光是出设计稿 + 等设计师排期，最快也得 3-5 天。

现在呢？我画个糙图，AI 18 秒给我一个能 demo 的成品。我可以直接拿去给产品经理看效果，看完一起改，改完再让 AI 重做——迭代周期从天缩短到分钟。

但这不意味着前端工程师要被替代。AI 生成的代码是"能跑的设计稿"，不是"生产代码"。生产代码要考虑性能、SEO、错误处理、可维护性、可测试性，这些 AI 不会做。AI 解决的是"从 0 到 1"，工程师的价值在"从 1 到 100"。

更现实的意义是：以前想验证一个产品想法，得先说服老板给资源、找设计师排期；现在一个人一支笔一张草图就能跑起来。这对独立开发者、小团队、想搞副业的人来说，是真的门槛降低。

几个想再试的方向

这次测了"草图→单页"和"草图→多页"，效果超出预期。我打算接下来继续挖几个场景：

• 真实截图 → 还原代码— 拿一个成熟的 App 截图，让模型反推代码，看视觉还原度
• 设计稿 + 自然语言混合— 给半成品设计稿 + 修改意见，看模型能不能基于现有代码做精准迭代
• 3D 模型理解— 这模型在 3D 物体识别上有大提升，试试拿 3D 模型截图让它生成 Three.js 代码
• 跨页面状态共享— 三个页面之间真正共享数据（比如景点详情里的"加入行程"要能影响行程页的进度），看看 Agent 流程怎么走

这些场景如果跑出来，单拎任何一个出来都能再做一篇投稿。

总结

这次升级我觉得最值得说道的不是某个 benchmark 数字，是"草图到成品"这条工作流被打通了。

以前我们说 AI 编程，是说 AI 能写代码。这次升级让 AI 不仅能写代码，还能"看图写代码"——这意味着它能参与到产品构思阶段，而不只是执行阶段。这种能力对前端开发者的影响，会比想象中更大。

有意思的是，回到豆包日常工作场景里，这种"看图 + 多页一致性 + 端到端"的能力并不只是 demo：它直接对应"草图评审 + 设计稿还原 + 多页连调"这条真实链路。换句话说，这次拿到的不是一张漂亮的截图，是能塞进团队工作流的一段流程。

想试的话，去火山方舟开个号，开通 Seed-Evolving（0915），照我这个 Case 的代码贴一遍，调下就能跑。一杯咖啡的时间，你也能体验一遍"草图变 App"。