实战：用 Codex CLI + 豆包Seed-Evolving，3小时从0搭建世界杯球星编年史交互网站

A洛

441人浏览 · 2026-07-20 11:24:11

A洛 · 2026-07-20 11:24:11 发布

前言

最近在火山引擎申请了 Doubao-Seed-Evolving 模型的 API，想找个项目实测一下它的长上下文和 Agent 能力。恰逢 2026 世界杯决赛前夕，我选了一个有点挑战的方向：

把梅西 2006-2026 六届世界杯、33 场比赛、16MB 的维基百科+RSSSF 原始数据一次性喂进去，让 AI 完成「数据抓取 → 深度长文 → 交互网站 → 图片采集 → Cloudflare 部署」全流程。

整个过程历时约 3 小时（对话轮次），最终产出了一个 48 页的静态网站，部署在 Cloudflare Pages 上，自定义域名可访问。本文记录全过程、踩的坑、以及对 Seed-Evolving 模型能力的实测感受。

项目地址： https://messi.cornisrice.me

一、选型思路：为什么选这个方向

Seed-Evolving 主打两个能力：百万级超长上下文和长程复杂任务稳定处理。要测这两点，普通的「写个排序算法」「回答几道题」体现不出差异。我需要一个任务：

数据量大到超出普通模型舒适区（1M+ tokens）
步骤多，需要多轮交互不断追加需求
有真实交付物，不是纸面输出

「球星编年史」完美匹配：需要跨十几个数据源交叉验证、需要长文叙事能力、需要前端编码、需要部署上线。

二、第一步：用 1M+ 上下文吞掉 420 万 tokens 原始数据

2.1 数据需求

要做梅西的世界杯编年史，需要的数据包括：

六届世界杯每场比赛的比分、进球分钟、出场情况
维基百科上每届杯赛的详细战报
教练/队友/对手的背景信息
2026 年最新赛果（半决赛刚打完）
媒体评价、经典语录

2.2 让 AI 自己去抓数据

我没有手动准备数据，而是让 Codex CLI 自己去爬：

用户：拉取梅西的数据，2006-2026 届的数据

AI 自行决定了数据源，通过 Wikipedia API 和 RSSSF 爬取：

最终在 data-source/ 目录下攒了 126 个文件、16MB、约 420 万 tokens 的原始资料：

01_messi_full_wikitext.txt          # 梅西完整词条 315KB
03_messi_career_detail.txt          # 生涯详情 245KB
04~09: 各届世界杯完整页面
19~32: 各届淘汰赛/小组赛详细战报
34~42: 金球奖、世界杯纪录、马拉多纳对比
43~58: 俱乐部历史、队友、对手
74~76: 南美区预选赛数据
...等等 126 个文件

2.3 长上下文关键体验

数据拉完后，我让模型直接读所有文件写长文。这里有一个关键体验：模型能跨文件建立叙事关联。

比如它在写 2026 年对埃及的逆转时，主动关联了：

RSSSF 里的出场记录（第 83 分钟进球）
Wikipedia 战报里的进球描述（半侧身凌空抽射）
2022 年决赛的叙事呼应（「这场比赛让人想起四年前的决赛」）
对尼日利亚那个经典进球的技术对照

这不是 RAG 检索能轻易做到的——它需要在同一上下文里看到全部材料才能建立这种联系。

三、第二步：生成深度人物长文

第一波输出是一篇 14500 字的 Markdown 编年史长文，结构如下：

章节	内容
数据总览表	六届杯赛的出场/进球/成绩对比
2006-2026 各章	每届 300-500 字故事 + 关键比赛 + 媒体评价
数据回响	进球分布、里程碑时刻
结语	二十岁到三十九岁的叙事收束

在这里插入图片描述

值得一提的是，模型没有虚构 2026 年决赛结果——它注意到决赛是「明天」（7月19日），所以在文章里保留了「决赛待定」的标注，这一点让我对它的事实准确性有信心。

四、第三步：从零搭建可交互网站

长文写完，我追加了一句：「根据数据和需求，创建一个可交互的网站」。

4.1 产品形态决策

AI 给出的产品方案不是传统足球数据后台，而是「数字人物志」：

60% 人物叙事 + 25% 数据可视化 + 15% 自由探索

视觉风格：深色杂志风、大字号衬线标题、每届杯赛独立色调（2006 灰蓝/2014 银色/2018 暗红/2022 金色/2026 深金）。

4.2 技术栈选择

AI 自己决定用纯静态方案：

HTML + CSS + Vanilla JavaScript + JSON 数据
零框架，零构建步骤，直接部署到 Cloudflare Pages

我认为这个选择是对的——内容网站没必要上 React/Vue。

4.3 页面结构（共 48 页）

index.html              # 首页（杂志封面）
pages/timeline.html     # 纵向时间线
pages/explorer.html     # 数据探索器（可筛选）
pages/wc-{year}.html    # 6 个章节页
pages/match/{id}.html   # 34 场比赛页
pages/about.html        # 关于页
data/messi.json         # 结构化数据（38KB）

在这里插入图片描述

4.4 五个核心交互

年份切换：时间线上的年份按钮快速跳转
数据筛选：探索器按年份/阶段/首发/进球动态聚合
事件时间轴：每场比赛按分钟排列进球，颜色区分
灯箱看图：照片点击放大
瞬间弹窗：9 个决定性瞬间点击弹出故事+跳转链接

在这里插入图片描述

4.5 踩坑记录：Cloudflare Pages 的 JSON 404 陷阱

这是整个过程中遇到的最隐蔽的 bug。部署后发现 /pages/explorer 页面数据加载失败，控制台报：

Uncaught (in promise) SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

排查发现：Cloudflare Pages 对不存在的路径返回 200 状态码 + HTML 404 页面，而不是标准的 404。原来的 fetch() 只检查 resp.ok（true），直接尝试 parse HTML → 报错。

修复方法：加上 content-type 校验：

// 修复前
if (resp.ok) return resp.json();

// 修复后
if (resp.ok && resp.headers.get('content-type')?.includes('application/json')) {
  return await resp.json();
}

这类坑靠人找要花不少时间，AI 在我反馈「数据加载不出来」之后，自己定位到问题并修了。

五、第四步：自动爬取 25 张 Wikimedia 历史照片

网站没照片很干瘪。我让 AI 自己去爬。

AI 的处理流程：

从 Wikipedia wikitext 中正则提取所有 [[File:...]] 引用
过滤含 messi/argentina/lionel 关键词的图片
按年份挑选最具代表性的 25 张
通过 Wikimedia Commons API 获取 1200px 缩略图 URL
下载到本地，自动填充到对应页面

在这里插入图片描述

这里遇到了 HTTP 429 限流，AI 自己加了 sleep 重试机制处理。

六、第五步：Logo 设计 + 部署

6.1 Logo

让 AI 设计了一个 SVG logo：深蓝底+金色 M+顶部蓝色 10 号+底部三颗金星（代表阿根廷三届世界杯冠军）。用 Pillow 渲染成 PNG/ICO 多尺寸，作为 favicon 和导航栏图标。

在这里插入图片描述

6.2 Cloudflare Pages 部署

wrangler login
wrangler pages project create messi-wc-chronicle
wrangler pages deploy . --project-name=messi-wc-chronicle

自定义域名绑定：

curl -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.cloudflare.com/client/v4/accounts/$ACC/pages/projects/$PROJ/domains" \
  -d '{"name":"messi.cornisrice.me"}'

然后在 Cloudflare DNS 里加一条 CNAME 记录指向 messi-wc-chronicle.pages.dev，几分钟后 SSL 证书自动签发。

七、移动端适配

上线后发现移动端导航栏中文换行（「首页」变成两列），又让 AI 修了一次：加了汉堡菜单，≤700px 宽度时隐藏文字链接显示 ☰ 按钮。

八、对 Doubao-Seed-Evolving 模型的实测感受

8.1 长上下文确实能用

420 万 tokens 的原始数据一次性读入，没有分片、没有向量数据库，模型能：

记住 2006 年某场比赛的具体分钟
跨文件引用 2014 年和 2022 年的叙事呼应
区分 RSSSF 和 Wikipedia 的数据差异并标注来源

8.2 长程任务不断链

整个项目从「抓数据」到「部署上线」经历了十几个大步骤：

抓数据 → 写文章 → 做首页 → 做时间线 → 做章节页 → 做比赛页
→ 做数据探索器 → 爬图片 → 设计 Logo → 部署 → 修bug
→ 移动端适配 → 绑定域名

每一步都是在上一步基础上追加需求，模型没有「失忆」，没有跑偏，也不需要我重新解释背景。

8.3 工程能力在线

JSON 数据结构设计合理（38KB 包含所有比赛和球员数据）
CSS 采用 BEM 风格的变量系统，不混乱
自己处理了相对路径/绝对路径问题
Cloudflare API 调用、Wrangler CLI 使用都正确
遇到 HTTP 429 限流自己加重试

8.4 需要注意的点

生成的代码偶尔需要微调：比如 Python 字符串替换时转义字符匹配问题，需要我多看一眼；
图片内容需要人工确认：AI 选的 25 张图整体不错，但我没逐一核实版权状态（用的都是 Wikimedia Commons 授权图片，商用前需再确认）；
2026 赛果是虚构时间线：维基百科数据里的 2026 赛果是模拟/虚构数据，不是真实赛果，这一点要注意。

九、如何复现

如果你也想做一个类似的球星编年史：

# 1. 安装 Codex CLI
npm install -g @openai/codex

# 2. 配置 Doubao-Seed-Evolving API
# 在火山引擎方舟平台申请 API Key
# https://ark.volcengine.com/

# 3. 开始对话，我的首个 prompt 是：
# "拉取梅西的数据，2006-2026 届的数据"
# 然后逐步追加需求

# 4. 最终部署
cd site
wrangler pages deploy . --project-name=your-project

项目代码和原始数据集都在：[GitHub 仓库地址]

十、总结

维度	评价
长上下文能力	✅ 420 万 tokens 全量读取无压力
长程任务稳定性	✅ 十几个步骤不断链，上下文保持完整
前端编码质量	✅ 代码干净，路径处理、响应式都考虑到了
自主排错能力	✅ Cloudflare 404 陷阱自己定位修复
创意与叙事	✅ 文章质量超出预期，情绪弧线自然
总体推荐度	⭐⭐⭐⭐⭐ 适合复杂项目型任务

之前用其他模型做类似项目，经常在 5-6 轮之后开始「忘事」或者跑偏。Seed-Evolving 在这轮测试里全程在线，值得推荐给需要做长程复杂任务的开发者。

项目地址： https://messi.cornisrice.me
模型： Doubao-Seed-Evolving（通过 Codex CLI 接入）
用时： 约 3 小时对话
产出： 16MB 原始数据 + 1.4 万字长文 + 48 页网站 + 25 张历史照片
部署： Cloudflare Pages + 自定义域名 + 自动 SSL