豆包新模型写代码，实测能做到哪一步？

昨天看到 Kevin Ma 发了一条豆包新模型的实测。他用的是 Doubao-Seed-2.1-Pro，入口放在 TRAE Work CN 里。主推里先给了一个结果：一段 prompt，让模型生成完整的产品落地页，hero 、桌面 app mockup 、价格表、 FAQ 都在，能直接跑起来。

我把主推、长文展开内容和视频素材都下载下来，又把它提到的几个后续案例一起拆开看了一遍。这个帖子的重点不在“跑分”，而在一个更接近普通开发者的问题：如果手里只有一个产品想法，或者一个界面截图、一个失败测试，模型到底能帮到哪一步。

下面按教程来写。你可以照着跑一遍，再决定要不要把它放进自己的开发流程。

先准备：下载 TRAE Work CN，选豆包模型

Kevin 给的入口很直接：下载 TRAE Work CN，模型选择 Doubao-Seed-2.1-Pro。

你可以这样开始：

安装 TRAE Work CN 。
新建一个空项目，推荐先用 Vite 、 Next.js 、 Astro 这类前端模板。
在模型列表里选择 Doubao-Seed-2.1-Pro。
打开 Agent / Chat 面板，把需求写成完整任务，别只丢一句“帮我做个网页”。

如果只是试水，先从纯前端页面开始。它不需要后端、不碰数据库，最容易看出模型的审美、代码组织和一次性完成度。

案例一：一句话做产品落地页

主推里展示的是“内容系统产品落地页”。这个任务很适合测试模型，因为它同时考验几件事：

会不会把产品定位讲清楚；
会不会做视觉层级；
会不会把 hero 、功能区、价格表、 FAQ 放到合理位置；
生成的代码能不能跑；
组件命名和样式会不会乱。

可以直接用下面这段 prompt：

请为一个 AI 内容管理系统生成一个现代 SaaS 产品落地页。

要求：
1. 使用 React + Tailwind CSS。
2. 页面包含 hero、产品截图或桌面 app mockup、核心功能、使用流程、价格表、FAQ 和 CTA。
3. 视觉风格偏 Linear / Vercel / Raycast，背景干净，有轻微渐变和卡片阴影。
4. 文案要像真实产品官网，不要写成占位符。
5. 所有组件放在当前项目里，可以直接运行。
6. 如果缺少依赖，请告诉我需要安装什么，并给出命令。

跑完以后先别急着改文案，先看三个地方：首屏能不能在 5 秒内说清产品；价格表是否真的像能卖的套餐；FAQ 有没有回答用户会在意的问题。如果这三块都过得去，再让模型继续细化。

案例二：用 VLM 还原界面

主推展开里提到的第二个案例是 VLM 界面还原。这类任务的用法很实在：给模型一张参考图，让它把布局、颜色、间距、组件状态还原成可运行页面。

建议这样写：

我会上传一张界面截图。请你根据截图还原一个可运行的前端页面。

要求：
1. 不要只描述截图，要直接写代码。
2. 优先还原布局、字号、颜色、间距和组件层级。
3. 图标可以用 lucide-react 或 CSS 形状代替，不要依赖我没有提供的素材。
4. 如果截图里有表格、卡片、侧边栏、顶部导航，请拆成清晰的 React 组件。
5. 最后告诉我哪些地方是近似实现，哪些地方需要人工替换真实数据。

这个场景很适合做内部后台、运营工具、数据面板。不要期待一次生成就像设计稿一样精确，但它能把 70% 到 80% 的骨架先搭出来，剩下的就是人工校准。

案例三：让模型看 failing test，自己定位和修复

第三个案例是 failing test 自定位自修。这个比做页面更接近日常开发：你写测试，模型根据失败信息修代码。

推荐流程是：

先跑测试，保留完整报错。
把失败测试文件、相关源码和终端输出一起给模型。
要求它先解释失败原因，再改代码。
改完以后继续跑测试，不通过就让它根据新报错迭代。

可用 prompt：

下面是一个失败测试。请先阅读测试、源码和报错，再定位问题。

要求：
1. 先用几句话说明失败原因，不要马上改代码。
2. 只修改和这个失败测试直接相关的文件。
3. 保持现有 API 不变，除非测试本身要求调整。
4. 修改后告诉我需要重新运行哪条测试命令。
5. 如果你认为测试写错了，也要说明理由，不要直接绕过测试。

失败测试输出：
[把终端报错贴在这里]

这里最重要的是加上“不要绕过测试”。很多模型为了让测试变绿，会把断言改松、把错误吞掉，甚至删掉边界检查。更稳的做法是让它解释原因，再让它动手。

案例四：做 3D 小游戏，让它自测自修

第四个案例是 3D 小游戏自测自修。这个任务看起来像玩具，但很适合测模型的工程完整度：它要处理场景、相机、碰撞、交互、状态和性能。

可以从一个很小的游戏开始：

请用 Three.js 做一个可以直接运行的 3D 小游戏。

玩法：
1. 玩家控制一个小球在平台上移动。
2. 平台上有金币和障碍物。
3. 吃到金币加分，碰到障碍物扣血。
4. 有开始、暂停、重开和得分显示。

工程要求：
1. 使用 Vite + React + Three.js。
2. 代码结构清晰，游戏状态、场景渲染、键盘控制分开写。
3. 加上基础自测说明：我应该怎么运行、怎么检查玩法是否正常。
4. 如果你发现生成的代码有 bug，请自己先修一轮再给我最终版本。

这类任务不要一开始就做大型游戏。先让模型完成最小可玩版本：能跑、能动、有输赢反馈。它跑通以后，再让它加关卡、粒子、音效和排行榜。

这次实测里比较有价值的地方

从 Kevin 的主推和后续案例看，Doubao-Seed-2.1-Pro 在 TRAE 里的价值主要有三块。

第一，它适合快速搭一个“能看的前端原型”。产品落地页、后台界面、工具型页面，都可以先让它出第一版。

第二，它可以吃截图和错误信息。 VLM 还原界面、 failing test 修复，都是开发者每天会遇到的任务，发 demo 之外也有实际用途。

第三，它更适合放进迭代流程，别把一整个项目一次性外包给模型。你给它越明确的边界、测试和验收标准，结果越稳定。

我建议你这样用

如果你想认真试一次，不要只问“帮我做个网站”。按下面这个顺序跑：

先让它做一个单页产品官网。
再给它一张你喜欢的界面截图，让它还原一个组件。
接着写一个会失败的测试，让它修。
最后做一个小型交互 demo，看它能不能维持代码结构。

四轮下来，基本就能判断它适不适合你的工作流。

注意几个坑

不要直接把公司代码、客户数据、密钥贴进去。需要调试时，先脱敏，把 API Key 、 token 、用户数据和内部域名去掉。

不要把生成结果当最终代码。前端页面可以先跑起来，但仍然要人工检查可访问性、响应式、异常状态和依赖安全。

不要让模型同时做太多事。一个 prompt 同时要求设计、后端、数据库、登录、支付、部署，失败率会明显升高。把任务拆小，效果会好很多。

测试要自己跑。模型说“已修复”不算数，终端里的测试结果才算数。

小结

这条帖子最值得借鉴的地方，是把模型放到真实开发动作里看：生成页面、看图还原、读测试、修 bug 、做交互 demo 。这样的测试比单纯问答更接近开发者每天的工作。

如果你已经在用 TRAE Work CN，可以直接选 Doubao-Seed-2.1-Pro，把上面的 prompt 跑一遍。不要只看第一眼效果，重点看它在第二轮、第三轮修改里还能不能保持结构清楚、代码能跑、测试能过。

我会更愿意把它当成一个“前期原型 + 局部修复”的助手，暂时别指望它完全替代开发者。这样用，收益更稳定。

来源：https://x.com/kevinma_dev_zh/status/2069800387171983698