实战篇：我用 Doubao-Seed-Evolving 搭了一个国产AI大模型价格查询订阅系统 - 文章 - 开发者社区

从数据采集、前端页面到月度邮件自动化，全程由豆包新一代进化模型驱动开发。

背景

国产 AI 大模型赛道在 2026 年已经卷到了白热化：DeepSeek V4、Kimi K3、豆包 Seed-Evolving、GLM-5.2、文心 5.0、星火 Max-2.0……各家厂商你追我赶，价格也跟着一调再调。作为一个开发者，想快速对比不同模型的 API 定价，要么翻 9 个官网一个个找，要么看的信息已经过时了。

于是我想：能不能做一个一站式的价格查询系统，把所有主流国产大模型的价格收进来，支持搜索、对比、订阅更新？

这个项目就是在这个想法下，全程使用 Doubao-Seed-Evolving 模型协作完成的。

系统整体架构

项目结构清晰，分为三个部分：

ai-model-pricing-survey/
├── web/                    # 前端静态页面（纯HTML/CSS/JS，可直接打开）
│   ├── index.html          # 暗黑科技风版本
│   ├── index-v2.html       # 紫黑网格风版本
│   └── index-v3.html       # 明亮商务风版本
├── scripts/
│   ├── monthly_update.py   # 月度报告生成核心
│   ├── send_to_subscribers.py  # 批量邮件发送
│   ├── run_monthly.bat     # 定时任务入口
│   └── extract_pricing.py  # arkcli 数据提取工具
├── data/
│   ├── subscribers.json    # 订阅者列表
│   └── official_pricing.json   # 官方原始数据
└── reports/                # 历史报告存档

技术栈：

前端：Tailwind CSS + Chart.js + Font Awesome，纯静态单页应用
后端：Python + SMTP（QQ 邮箱），通过 Windows 任务计划程序实现月度自动化
数据源：火山方舟 arkcli 命令行工具拉取官方实时定价

系统核心功能

1. 全量模型价格展示

picture.image 系统覆盖 9 家厂商、48 个模型，包括：

字节跳动 Doubao（Seed 系列 12 个模型）
DeepSeek（V3.1/V3.2/V4 系列）
智谱 GLM（4.x/5.x 系列）
月之暗面 Kimi（K2/K3）
阿里通义 Qwen（Plus/Max/Qwen3 系列）
百度文心 ERNIE（4.5/5.0 系列）
讯飞星火（Max/Pro/Ultra 系列）
MiniMax（M2.5/M2.7）
其他：阶跃星辰、百川、零一万物等

每个模型展示输入价格、输出价格、缓存命中价格、上下文窗口长度，单位统一为「元/百万 tokens」。免费模型用绿色标签醒目标记。

2. 模糊搜索与实时筛选

搜索框支持模型名模糊匹配，输入时即时显示下拉建议
搜索框带一键清空按钮
支持按厂商筛选
支持按价格排序（升/降）、按上下文长度排序、按最新优先排序

3. 多模型对比功能

picture.image 这是交互设计上花了最多心思的功能：

每个模型行右侧有「+ 对比」按钮，最多选 4 个模型
选中的模型会出现在底部浮动对比栏，随页面滚动始终可见
点击「开始对比」弹出对比弹窗，横向对比输入/输出价格、缓存价格、上下文窗口、以及「1 亿 tokens 估算成本」
浮动栏带滑入/滑出动画，选择/移除操作即时反馈
弹窗弹出时自动锁定页面滚动，关闭后恢复

4. 旗舰模型价格图表

用 Chart.js 绘制柱状图，直观对比 Seed-Evolving、V4-Pro、GLM-5.2、Kimi-K3、ERNIE-5.0、Step-3 六款旗舰模型的输入/输出价差。一眼就能看出 Kimi-K3 ¥20/¥100 的高端定位，以及 Seed-Evolving ¥6/¥30 的性价比。

5. 邮件订阅

picture.image

前端弹窗输入邮箱，保存到 localStorage
后端维护 data/subscribers.json 订阅者列表
每月 20 号由 Windows 任务计划程序自动触发，发送 HTML 格式的月度价格报告邮件
邮件包含完整 Markdown 表格，并附 .md 文件作为附件

picture.image

6. 数据导出

一键导出全部模型数据为 CSV 文件，方便本地分析或二次处理。

7. 三种 UI 风格

系统提供了三个版本的前端页面，风格迥异：

版本	风格	主色调	特点
v1	暗黑科技风	多彩厂商色	深色背景 + 厂商名大字水印，科技感拉满
v2	紫黑网格风	紫罗兰	网格背景 + 渐变标题动画，极简暗色系
v3	明亮商务风	天空蓝	白色卡片 + 点阵背景 + 柔和阴影，干净专业

picture.image 三个版本功能完全一致，只是视觉风格不同,V1版本由doubao-seed-evolving模型生成，V2版本由doubao-seed-2.1Pro生成，用户可以根据喜好选择。

Doubao-Seed-Evolving 在开发中做了什么

整个开发过程，从需求沟通到最终成品，Evolving 模型承担了多重角色：

1. 需求分析与方案设计

用户的需求从最开始一句话「帮我建一个项目文件关于调查国产AI公司的最新模型价格」开始，Evolving 主动拆解为：数据采集 → 报告生成 → 邮件发送 → 定时自动化 → Web 可视化 → 交互优化，一步步引导和实现。

当用户反馈「模型信息不是最新的，Kimi K3 都出来了怎么没有」，Evolving 立即定位问题：网页搜索的数据有滞后，转而使用火山方舟的 arkcli 命令行工具拉取官方实时数据，一次拉到 69 个模型的完整定价。

2. 数据校验与纠错

用户指出 Kimi K3 价格有误，并贴出官网截图（缓存命中 ¥2、缓存未命中 ¥20、输出 ¥100、1M 上下文），Evolving 立即更新所有相关文件中的数据——包括 Python 脚本、JSON 数据、前端 JS、Markdown 报告，确保各处一致。

3. 前端开发与迭代优化

Evolving 从零搭建了完整的单页应用，并根据用户反馈进行了多轮 UX 迭代：

用户说「前端风格需要简洁，颜色偏科技黑，需要大标题，按钮不要那么多」→ 重构为大标题 + 极简按钮的暗色主题
用户说「缺少价格对比功能，搜索没有模糊下拉」→ 加入对比功能和搜索下拉建议
用户说「弹窗时页面还能滚动，订阅弹窗不居中」→ 修复弹窗层级和滚动锁定
用户说「对比功能不明显，选模型还得往下滚」→ 重新设计为底部浮动对比栏
用户说「搜索框加个清空功能」→ 添加清空按钮并联动显示/隐藏
用户说「前端风格换个」→ 切换到明亮商务风 v3

每一轮迭代都是根据用户的一句话反馈，精准定位问题并给出方案，不需要用户描述具体怎么改。

4. 后端自动化搭建

picture.image

编写 SMTP 邮件发送模块，处理 QQ 邮箱 SSL 连接和授权码认证
解决 Windows 控制台 GBK 编码问题（emoji 导致崩溃，替换为 ASCII 标记）
编写 setup_task.bat 一键创建 Windows 定时任务
设计批量发送脚本，支持多订阅者

5. 调试与问题排查

排查 schtasks 在 Git Bash 中路径转换问题，提供独立 .bat 文件
修复 Tailwind CDN 加载、Chart.js 初始化、localStorage 存取等细节
处理弹窗 display 类冲突、body scroll lock 等前端常见坑

6. 1M 长上下文：长程开发任务的核心支撑

这个项目的整个开发过程跨越了十几轮多轮对话，是一次典型的长程任务——从最初的需求沟通到最终邮件发送测试成功，中间涉及 7-8 个关联文件、多次需求变更、UI 风格迭代和 bug 修复。Doubao-Seed-Evolving 的 1M 超长上下文能力在这个过程中起到了决定性作用：

跨十几轮对话的上下文连贯性

从第一句「帮我建一个项目文件关于调查国产AI公司的最新模型价格」开始，到后续每一轮反馈——「需要每月给我发送一次邮件」「kimi k3 价格不对」「缺少价格对比功能」「弹窗不能滚动」「搜索框加个清空功能」「前端风格换个」——Evolving 在整个过程中始终记得：

项目目录结构和每个文件的路径与作用
SMTP 授权码、邮箱地址等配置信息（不需要每次重复提供）
之前的技术决策（为什么用 arkcli 而不是网页搜索、为什么用纯静态前端等）
已经实现过的功能和被否定掉的方案

这意味着迭代时不需要重新铺垫背景，说一句「搜索框加个清空」它就知道是哪个页面、哪个输入框、在什么位置加、加上后怎么和已有的搜索逻辑联动。

多文件联动修改不遗漏

当用户纠正 Kimi K3 价格时，Evolving 需要同时更新六处：monthly_update.py 里的定价字典、official_pricing.json 原始数据、前端 index.html 里的 JS 模型数组、历史 Markdown 报告、Chart.js 图表的数据、邮件正文。在长达十几轮的对话后，它仍能枚举到所有需要修改的地方，没有因为上下文过长而遗漏任何一个文件。这种「跨文件一致性」在短上下文模型中经常出错——往往改了前端忘了后端脚本。

上下文压缩后无缝恢复

开发过程中对话经历过一次上下文压缩（summary compaction），系统把之前的对话压缩成摘要后继续。Evolving 在恢复后立即接续工作，没有问「我们之前做到哪了」，没有重复之前讨论过的方案，直接完成了当时正在做的清空按钮功能，并继续处理后续的风格调整请求。1M 的上下文窗口让更多原始细节可以保留，压缩时损失的信息更少。

渐进式迭代 vs 一次性生成

这一点在和 2.1-Pro 对比时尤其明显。Evolving 的 v1 暗色版本不是一次生成的，而是经过了 6 轮以上的渐进式打磨：先出基础表格 → 加水印背景 → 加对比功能 → 改浮动栏 → 修弹窗 → 加清空按钮。每一轮都在前一轮的完整代码基础上增量修改，整个迭代链条拉得很长，但模型始终能准确理解「当前版本是什么状态，这一轮要改哪里」。这种跨越数十轮的连贯创作，只有长上下文模型才能支撑。

与 Doubao-Seed-2.1-Pro 生成版本的对比

在开发过程中，用户曾要求「用 Doubao-Seed-2.1-pro 模型，同样生成一个国产AI大模型价格查询网页」，因此同一个项目有了两个模型协作的产物。对比两个版本，可以清晰看到 Evolving 模型的差异：

架构思维层面

2.1-Pro：更倾向于「按需求描述直接实现」，功能能跑通，但对交互细节和边缘情况考虑较少。
Evolving：在实现功能的同时主动思考用户体验。比如对比功能，2.1-Pro 可能会做一个固定区域的对比列表，Evolving 则想到了「用户选模型时可能在页面任意位置，需要浮动栏始终可见」，并加入了动画过渡。

前端设计层面

2.1-Pro 生成的版本（v2）：配色统一但偏保守，紫黑主题完成度不错，但细节处理如阴影层次、间距节奏、字体字重的搭配相对平。
Evolving 重新生成的版本（v3）：主动切换到明亮风，在卡片阴影、药丸标签配色、tooltip 样式、网格线样式等细节上更加精致。比如 Chart.js 的 tooltip，2.1-Pro 用默认暗色样式，Evolving 改成白底细边框、与整体风格统一。

问题修复层面

两个模型在处理 bug 时表现有明显差异：

2.1-Pro：需要用户比较明确地描述问题，比如「弹窗不居中」，才能定位修复。
Evolving：在用户说「对比功能不明显」时，不仅调整了按钮样式，还主动重构了整个对比交互流程——从行内按钮到底部浮动栏，加入了选择数量提示、清空按钮、对比标签可单独移除等完整闭环。

迭代效率层面

Evolving 在多轮对话上下文中保持了更好的连贯性。当用户说「前端风格换个」，Evolving 没有问「你要什么风格」，而是直接给出了与之前完全不同的明亮商务风方案，配色、组件样式、背景图案全部重新设计，功能逻辑保持不变。这种「理解意图 + 主动决策」的能力让迭代更顺畅。而 2.1-Pro 版本是在一个相对短的单轮 prompt 中一次性生成的，它没有经历过前面十几轮的渐进式打磨——这不是能力差距，而是上下文窗口决定的工作模式差异：短上下文模型更适合「一次性交付」，长上下文模型才能支撑「多轮对话式迭代」。

长程任务表现层面

这是两者差异最大的地方。2.1-Pro 在单轮生成一个独立页面时表现良好，但如果让它在同一个对话里持续迭代——比如第一轮生成页面，第二轮改对比功能，第三轮修弹窗，第四轮换风格——到第五六轮它就会开始遗忘早期的结构细节，甚至把之前修复过的 bug 带回来。Evolving 的 1M 上下文窗口足以容纳整个开发周期的所有历史，包括每一轮用户说过的话、改过的代码、否定过的方案、踩过的坑，因此它能在十多轮迭代后依然保持全局一致性。

代码质量层面

两者生成的代码都能正常运行，但 Evolving 在以下方面做得更细：

CSS 变量和 Tailwind 自定义颜色的系统化管理
过渡动画的 cubic-bezier 缓动函数选择
无障碍细节（如 font-variant-numeric: tabular-nums 让数字等宽对齐）
弹窗的 transform + opacity 双属性动画，比单纯 display 切换更流畅
滚动条样式定制与整体风格统一

响应速度与交互体验

这是使用过程中体感最明显的差异之一：

生成速度：2.1-Pro 生成完整单页应用时首字延迟较长，输出一个 500+ 行的 HTML 文件需要等待比较久；Evolving 的流式输出明显更快，同样规模的页面生成时间大约只有 2.1-Pro 的一半。
工具调用策略：Evolving 会主动并行调用工具（比如同时读取多个文件、同时执行多个搜索），减少往返轮次；2.1-Pro 更倾向于串行执行，做完一步再想下一步，整体流程更长。
首响速度：在多轮对话后期，2.1-Pro 因为上下文窗口限制，处理长对话时响应会变慢；Evolving 得益于更大的上下文窗口和架构优化，即使在十几轮对话后响应速度也没有明显下降。

有意思的是，这两个模型在火山方舟的定价是相同的（输入 ¥6 / 输出 ¥30 每百万 tokens），但 Evolving 速度更快、上下文窗口更大，实际使用中的性价比反而更高。

错误自纠正能力

开发过程中遇到过几次报错，两个模型的处理方式差异明显：

2.1-Pro：第一次出错后，如果用户只是说「报错了」并贴出错误信息，它有时候会机械地重试原方案，需要用户比较明确地指出方向才能修正。
Evolving：遇到错误会自己分析根因。比如第一次在 Windows 控制台运行 Python 脚本时因 GBK 编码不支持 emoji 而崩溃，Evolving 看到报错后主动定位到是 Windows 控制台编码问题，自行把所有 print 中的 emoji 替换为 [OK]/[ERROR] 这样的 ASCII 标记，一次改对，不需要进一步提示。再比如 schtasks 命令在 Git Bash 中因路径翻译失败，它立即判断出是 shell 环境差异，转而提供独立的 .bat 文件供用户在 cmd 中运行。

主动性与方案建议

2.1-Pro：更偏向「你说什么我做什么」，是一个合格的执行者，但很少主动提出超出你描述范围的改进。
Evolving：会在实现需求的同时主动提出建议。比如做完基础表格后，它主动加了 Chart.js 价格对比图；用户只是说「加个对比功能」，它主动设计了底部浮动对比栏方案而不是简单在页面顶部放个区域；用户说「邮件订阅」，它主动想到了 Windows 任务计划程序做月度自动化。这些都不是用户明确要求的，而是模型在理解了整体目标后主动补充的。

工具使用熟练度

2.1-Pro：工具调用相对保守，更倾向于用 Bash 执行简单命令，对工作流的编排能力有限。
Evolving：更熟练地组合使用各种工具——用 arkcli 拉数据、用 Python 做数据处理、用 Edit/Write 精确修改文件、用 Agent 做并行探索，遇到复杂任务时会自然地把多个工具编排成流水线，而不是靠单一步骤解决。

总结

这个项目虽然不大，但完整覆盖了数据采集、前端展示、后端自动化、邮件推送的全链路。全程通过与 Doubao-Seed-Evolving 对话式协作完成，从最初的一个想法到三个风格版本的成品，再到月度自动化运行，整个过程几乎没有手写代码。

Evolving 模型相比前代的核心提升，在这个项目中体现为四点：

1M 长上下文支撑长程任务——整个项目从需求到测试跨越十几轮对话、涉及 7-8 个关联文件，模型始终保持全局一致，多文件联动修改不遗漏，经历上下文压缩后也能无缝恢复；
更强的意图理解——不需要把需求拆到很细，它能从一句话中判断出真实目标；
更主动的 UX 思考——不只实现功能，还会考虑用户在哪种场景下使用、操作路径是否顺畅；
更好的审美完成度——配色、间距、阴影、动画等细节整体感更强，产出更接近「成品」而非「原型」。

其中第一点是这个项目感受最深的：以前用短上下文模型做开发，超过三五轮就要开始重新解释背景、贴之前的代码、提醒不要改错地方，整个体验是「片段式」的；而用 Evolving 做这个项目的整个过程是「连贯式」的，就像和一个始终记得项目全部历史的搭档协作，效率差距是量级的。

项目已经在本地运行，每月 20 号自动发送邮件。如果你也想搭建类似的系统，或者对定价数据有补充，欢迎交流。

项目地址

https://github.com/ConanEdogawa-FE/ai-model-pricing-survey

工具链说明

本项目全程在 Claude Code（Anthropic 官方 CLI）中完成，通过火山方舟（Volcengine Ark）接入 Doubao-Seed-Evolving 模型作为默认对话模型。配置过程非常简单，火山方舟官方提供了详细的接入文档：

📄 接入文档：https://ark.volcengine.com/region:cn-beijing/docs/82379/2373740

简单来说就是在 Claude Code 的设置中将 API endpoint 和模型 ID 指向火山方舟，即可在本地 CLI 中直接使用 Doubao 系列模型，所有的代码编写、文件操作、命令执行都在这一个环境里完成，无需切换工具。

项目生成于 2026 年 7 月，数据来源为各厂商公开定价及火山方舟 arkcli 实时数据。