大家好，我是老刘
最近老刘受邀提前测试了豆包的 Seed-2.1-pro-0915 模型。这次不是全新发布，是一次升级迭代，主打 Coding、Agent 和多模态能力的提升，API 已经在火山方舟上线。
说实话，之前也用过豆包的模型，实际体验并不算好，所以这次测试没抱太大期望。
但一个真实需求做下来，结果确实超出预期。虽然还有两个明显的瑕疵，但总体来说，它已经能当主力模型用了。
这篇文章就完整复盘这次实战测试，不吹不黑，给正在选模型的同学一个参考。
老刘的测试方案
正好老刘团队自用的开源项目有一个不大不小的需求要改。
项目是我们团队自用的一个 AI Gateway 管理工具，主要使用 JS 开发。地址在这，感兴趣的同学可以看看。
这次的需求是这样的。
原先这个 aigd 工具主要管理的是 Cloudflare AI Gateway。但是 Cloudflare 的网关运行在边缘节点上，用户量又比较大。
所以结果就是在工作日高峰时期，通过 Cloudflare 的网关访问很多模型会更容易触发 429。
特别是针对一些供应商的免费层，比如 opencode，因为这些免费层不仅基于账号或者 token 限流，还会叠加基于 IP 的限流。
之前确实没有注意过这个问题，有人跟老刘反馈后，我自己测试了一下，opencode 的免费模型在高峰期确实非常容易触发 429。
所以这次的需求就是增加一个本地 AI 网关。如果通过 Cloudflare 的网关调用免费模型触发了限流，可以转为使用本地网关。这样原始 IP 就是本机 IP，可以在一定程度上规避 429 的问题。
总结下来，需求就是一句话，给这个 AI Gateway 管理工具增加一个本地网关的功能。
开发工具全程使用 opencode，模型全程都是 Seed-2.1-pro-0915。
这里要特别说明一下开发流程。老刘目前的开发流程基本上是这样的，先用顶级模型把需求拆解成多个功能点，再用主力模型完成每个功能点的单独开发和测试。
但这次为了测试模型，需求拆解和功能点开发全部都交给了 Seed-2.1-pro-0915。
接下来就看看这个模型在实战中的效果。
Seed-2.1-pro-0915 的实际效果
先看需求拆解
这部分的能力超出我的预期。
我把需求交给 Seed-2.1-pro-0915 后，经过几轮对话和功能确认，它输出了一套相对来说已经非常完备的设计方案。
老刘之前也用很多 flash 级模型尝试过需求拆解，结果都比较差强人意，基本都需要我做大量修正和补充才能用。
但 Seed-2.1-pro-0915 最让我惊喜的地方是，它一次性输出的方案就已经非常完备了。
只有一个功能点有些问题。它提供了一个本地网关到云端 Worker 的隧道功能，我觉得这个功能完全没有意义，后来让它删除了。
不过这个功能点并不能全怪模型。因为在最开始确认需求细节的时候，它提到过这一点，只是当时我没有认真看就直接确认了。等到功能开发完，我才发现这个功能是多余的。
下面这个链接就是它输出的方案持久化后的文档。
感兴趣的同学可以看它输出的方案怎么样。
再看具体编码能力
老刘的整体评价是，编码能力和 glm-5.3-flash 处在同一水平。
整个 feat/dual-gateway 分支都是 Seed-2.1-pro-0915 设计和开发完成的，感兴趣的同学可以直接看代码如何。
为什么老刘会判断它和 glm-5.3-flash 在同一水平呢？主要从两个方面考虑。
1. 功能完成度
对比在一个独立上下文中一次性完成一个功能点的效果，比如逻辑功能是否完备，还有哪些细节需要二次调整。
总体感觉和之前在这个项目中用 glm-5.3-flash 开发的效果和体验差不多。
都是主体部分一次通过，有少量细节因为老刘自己的使用习惯进行微调。
2. 出现的缺陷
这一点也是我觉得它和 glm-5.3-flash 能力比较接近的重要原因。
之前功能开发的过程中，glm-5.3-flash 就在测试中写坏了我的 provider 订阅列表，导致 provider 列表完全展示不出来。
这次 Seed-2.1-pro-0915 犯的是同样的错误，也是在执行测试的过程中把 provider 列表写坏了。
也就是说，这两个模型都没有注意到测试数据覆盖正常数据的问题。
所以总的来看，老刘的评价是 Seed-2.1-pro-0915 在逻辑思考方面已经接近顶级模型，在实际编码方面和 glm-5.3-flash 持平。
一句话概括，需求拆解省下来的沟通成本，很多时候比编码本身更值钱。
多模态能力也顺便试了试
这次升级官方主打的就是多模态 Coding 能力，所以老刘在功能开发之外，专门加了一个视觉理解的小测试。
这次新增的功能一开始布局描述很模糊，功能能用，但布局比较糙。这次老刘直接把页面截图丢给 Seed-2.1-pro-0915，在提示词里明确要求它参考截图来优化页面布局。
从截图里它能准确认出页面的功能区块，指出的布局问题也基本都成立，比如操作区挤在一起、信息层级不清晰这类。按它的方案调整之后，页面明显清爽了不少。
最终效果老刘截了图，大家可以直观感受一下。
Seed-2.1-pro-0915 的瑕疵
评价一个模型的好坏，不能只看思考能力这一项指标，还要综合考虑效率、成本和稳定性。
从 Qwen 3.8max 到 DeepSeek v4.1 flash，再到现在的 Seed-2.1-pro-0915。
老刘有一个挺明显的感觉，它们的思考链都相对比较长。
目前的研究结论也证实了，通过更多的思考轮次，可以提升模型的得分表现。
所以当前很多新模型，似乎都选择了用加长思考轮次来换取更高测试表现这条路。
但这样给用户带来的负面体验就是更多的 token 消耗，以及更慢的任务完成时间。
另一个在这次测试中比较明显的感受是中断，需要手工输入继续才能接着执行。
在最开始讨论方案的对话中，Seed-2.1-pro-0915 多次思考到一半就直接终止了会话。
特别是在读取大文件和读取大量网页的时候，这种情况的概率明显升高。
老刘把 opencode.db 里本会话的记录翻了出来，问题看得很清楚。
所有以 finish=stop 结束的 assistant 回合：
| 时间 | 模型 | provider | input | output | reasoning |
|---|---|---|---|---|---|
| 17:53:32 | Seed-2.1-pro-0915 | fang_zhou | 1861 | 1313 | 2234 |
| 00:05:35 | Seed-2.1-pro-0915 | fang_zhou | 1714 | 0 | 843 |
| 00:09:32 | Seed-2.1-pro-0915 | fang_zhou | 8554 | 0 | 740 |
| 00:25:18 | Seed-2.1-pro-0915 | fang_zhou | 325 | 660 | 315 |
| 00:41:59 | Seed-2.1-pro-0915 | fang_zhou | 27437 | 0 | 671 |
以 00:41:59 那次为例：
该步 reasoning 完整（736 字符）："I'll read the Portkey CLAUDE.md... and ask the exploration agent to analyze..."，即模型想好了要读 CLAUDE.md + 派 explore agent；
但 text 部分不存在、没有任何 tool 调用，output: 0、finish: stop；
于是它「说了要做什么」但什么都没做，回合结束。
模型 Seed-2.1-pro-0915 间歇性返回「空回复」，只产出 reasoning、正文和工具调用都是空的，却报 finish: stop。这类回合被记录为 output: 0，等于任务原地停住，所以你才需要反复输入「继续」。
总结
老刘先说明一下，在一个项目上的测试结果不代表能泛化到所有项目，感兴趣的同学还是需要在自己的项目中实际用一下看看效果。
就这次测试来说，我认为 Seed-2.1-pro-0915 可以平替主力模型进行具体功能点的开发。
而且因为它比 flash 级模型有更好的需求拆解能力，所以在需求拆解不够精细的场景下，可能会收获更好的效果。
最大的问题在于容易中断，但这也不是没有解决方法。有些 Agent 已经开始对这种零输出的返回做重试等容错处理。
如果你常用的 Agent 还没有这个功能，也可以搜索一下相关插件，甚至用 AI 自己开发一个简单的插件也很容易。
建议正在用 flash 级模型当主力的同学，可以拿自己项目里一个中等规模的需求试一下 Seed-2.1-pro-0915，重点感受它在需求拆解环节的差异。
你现在的主力开发模型是哪个？有没有遇到过类似的空回复中断问题？欢迎评论区聊聊。
🤝 如果看到这里的同学对客户端或者Flutter开发感兴趣，欢迎联系老刘，我们互相学习。
🎁 私信免费领老刘整理的《Flutter开发手册》，覆盖90%应用开发场景。可以作为Flutter学习的知识地图。
💬 : laoliu_dev
📂 老刘也把自己历史文章整理在GitHub仓库里，方便大家查阅。
