前言：
如果把ChinaJoy看成一个拥有近900家展商、1000余款游戏的大型开放世界，你会给自己选择哪条任务线？
有人追AI游戏，有人寻找独立作品，也有人只想看国产IP和未来硬件。但现实中的逛展攻略，往往给所有人同一张清单：信息很多，真正与自己相关的内容却要重新筛选。
于是，我把一个想法交给了Doubao-Seed-Evolving：
能不能不再生成另一篇攻略，而是把整场ChinaJoy改造成一套因人而异的RPG任务系统？
它给出的答案是ChinaJoy Quest。
用户选择AI游戏、独立游戏、国产IP、智能硬件等兴趣后，系统会生成专属探索者身份，再将2026 ChinaJoy公开资料编排成主线、支线和隐藏任务。每条任务线索都能返回原始报道，完成任务后还会生成个人探索报告。
从公开资料检索、真实信息整理，到React页面开发和生产构建，Doubao-Seed-Evolving参与了完整过程。最后得到的不是一张静态页面，而是一套已经在浏览器中跑通、能根据不同兴趣生成不同探索路径的Web应用。
一、展会攻略的问题，不是信息太少
2026 ChinaJoy于7月31日至8月3日在上海新国际博览中心举办，主题是“与AI同游”。
公开资料显示，本届展会面积超过14万平方米，汇集近900家参展企业，超过500家游戏公司及团队带来1000余款游戏产品。现场内容也不只有游戏试玩，还包括AI NPC、互动叙事、独立游戏、人形机器人、智能硬件、高校作品和二次元影像。
这类大型展会有一个很现实的问题：资料越临近开展越多，攻略也越写越长。
我平时写技术文章，经常需要从大量公开资料中筛选真正有用的信息。ChinaJoy的情况很像：收藏了不少展商清单和观展攻略，最后还是要自己回答几个问题：
我到底对什么感兴趣？哪些内容值得优先看？这条消息是官方发布的，还是二次转述？
普通攻略通常按照展馆或厂商排列，默认所有人关注同一批内容。但游戏开发者、硬件玩家和二次元爱好者进入同一场展会，想看的东西显然不同。
我最初也考虑过做一个“AI逛展搭子”，很快又把这个方案放弃了。
真实路线规划需要展位号、场馆地图、活动时间和现场排队情况。这些数据不完整，硬做只会得到一条看起来合理、实际无法验证的路线。更麻烦的是，展会结束以后，这种工具也会迅速失去价值。
我把问题重新缩小：
不规划用户怎么走，只解决用户应该关注什么，以及推荐依据来自哪里。
ChinaJoy Quest就是从这里开始的。
二、我想做的不是任务小游戏，而是一套信息编排方法
ChinaJoy Quest表面上使用了RPG式设计：探索者身份、主线任务、支线任务、经验值和等级报告。这个外壳确实适合ChinaJoy，但我没有先想界面，而是先确定信息如何流动。
整个系统可以概括为一条链路：
公开展会资料
↓
结构化情报库
↓
用户兴趣与探索方式
↓
个性化任务组合
↓
原始来源核验
↓
个人探索报告
任务不是随便写几句文案。
主线任务对应用户最关注的内容，比如AI NPC、互动叙事或独立游戏；支线任务负责扩展到高校作品、国产IP和未来硬件；隐藏任务“情报鉴定师”专门检查来源，提醒用户不要把没有依据的内容当成事实。
这套设计有两个考虑。
一是降低信息筛选成本。用户不需要浏览一张很长的展商表，只需要先选择兴趣，系统会把相关内容组织起来。
二是保留检查入口。系统给出推荐时，也要让用户知道这条信息来自哪里。
我给项目设定了10个兴趣标签和4种探索方式。同一批ChinaJoy数据，会根据用户选择形成不同的身份和任务线。
例如，我选择“国产游戏、智能硬件、AIGC创作”和“轻松打卡型”后：
系统生成了“未来硬件观察者”：
换成AI游戏、高校作品、影像科技，并选择深度体验型，生成的身份变成了“AI世界侦察员”。
身份称号只是用户能看到的结果。背后真正发生的事情是：系统根据兴趣标签重新计算内容相关性，再用探索方式调整任务侧重。同一份展会资料因此可以有多种入口。
这个思路也不局限于ChinaJoy。开发者大会、动漫展和高校开放日都存在类似的信息过载问题。只要更换底层资料和任务模板，系统就能继续工作。
三、把一个模糊想法交给Seed Evolving
这次开发使用火山方舟Agent Plan。我先在控制台启用Doubao-Seed-Evolving，再通过CC Switch完成Codex的模型配置。
Doubao-Seed-Evolving使用统一的doubao-seed-evolving Model ID。模型后续升级时，不需要重复更换Endpoint或调用方式。
7月15日的更新将上下文扩展到1M tokens，主要面向大型代码仓库、长文档和多轮任务。8月3日的第二次升级集中在三个方向：Coding工程能力、Agent检索和幻觉控制。
ChinaJoy Quest恰好会同时用到这几项能力。
我没有准备详细的页面设计稿，也没有把任务拆成“先写首页、再写按钮、然后加弹窗”这种操作步骤。我只交代了目标：
开发一个结合2026 ChinaJoy的游戏化探索系统。用户选择兴趣后生成探索身份和任务线；任务必须使用真实公开资料，并保留来源；项目要在浏览器里跑通，能够生成探索报告。
我还补了几条硬约束：
- 不做账号和后台；
- 不做真实场馆导航；
- 不编造展位号和现场活动；
- 先完成可展示的闭环；
- 开发结束后必须实际构建。
这段需求并不算特别细。模型需要自己决定技术栈、页面关系、数据结构和状态流转。
Doubao-Seed-Evolving检查工作目录后，选择了Vite、React 18和lucide-react。它随后创建项目、安装依赖，开始处理资料和页面。
这里有一个细节让我印象比较深。
模型没有因为我说“做一个RPG式网页”，就先堆一堆虚构任务。它先处理数据来源。这一步决定了后面的应用到底是一套有内容依据的系统，还是一个好看的空壳。
四、20条真实信息，比200条生成内容更有用
ChinaJoy Quest目前只收录了20条真实信息。数量不算大，但每一条都有实际用途。
Doubao-Seed-Evolving阅读了上海市政府网站转载的ChinaJoy观展报道，以及新华网发布的展会信息，从中整理出展区、活动、企业、游戏和IP等不同类型的数据。
内容覆盖：
- ChinaJoy Next Play创新游戏体验场；
- Vision Future前沿科技展区；
- AGS学院游戏展区；
- AI NPC、互动叙事和生成式内容；
- 中国游戏创新大赛征集的204款作品；
- 人形机器人和智能硬件；
- 国产游戏及国漫IP；
- 影像科技与二次元文化展区。
模型将这些信息写入REAL_ITEMS数组。每条数据包括名称、类型、标签、摘要、来源标题、来源链接、来源类型和核验状态。
例如，Next Play被标记为与AI游戏、独立游戏、AIGC创作和游戏开发相关；Vision Future关联智能硬件、人形机器人和AI游戏；AGS学院游戏展区则与高校作品、游戏开发和AIGC创作相关。
任务系统并不是直接复制报道，而是根据这些标签重新组织内容。
“寻找会思考的游戏角色”会关联AI NPC、互动叙事和Next Play；“未来科技观察”会关联Vision Future、人形机器人和智能硬件；“高校创意捕手”则指向高校团队的游戏、美术和AI创新作品。
点开任务后，可以看到对应的真实线索。每张线索卡都显示核验状态，也可以打开原始资料。
这里没有做实时联网搜索。网页运行时只读取已经整理好的静态数据。我认为这是一个更稳妥的选择。让模型开发过程中检索资料，再把确认过的信息固化到项目里，比每次打开页面都让模型临时回答可靠得多，也方便演示和复现。
数据整理过程中，模型还删除了一条包含多个未单独核验品牌组合的信息。展位号、具体活动时间、排队情况、试玩体验和获奖记录同样没有进入系统。
没查到，就不写。
这个处理看起来不如新增一个功能显眼，却直接关系到Agent输出是否可信。幻觉控制不是让模型少说几句话，而是让它知道哪些内容不能进入正式结果。
五、任务系统的价值，在于同一批数据会产生不同路径
如果只是把有用的信息做成卡片列表，ChinaJoy Quest和普通攻略没有太大区别。
真正拉开差异的是任务编排。
系统会根据用户兴趣生成2个主线任务、3个支线任务和1个隐藏任务。每个任务都有推荐理由、关联线索、难度和经验值。
我选择“国产游戏、智能硬件、AIGC创作”后，系统给出的任务包括：
- 寻找会思考的游戏角色；
- 独立游戏宝藏搜寻；
- 未来科技观察；
- 国产IP收集计划；
- 高校创意捕手；
- 情报鉴定师。
乍看之下，这些名称很像游戏成就。实际点进去，会发现它们对应的是不同的信息检索目标。
“寻找会思考的游戏角色”要求检查AI NPC和互动叙事；“国产IP收集计划”关注带有中国文化元素的游戏或动漫IP；“情报鉴定师”要求查看来源和核验状态，避免被没有依据的内容误导。
任务完成后，卡片状态、总经验值和顶部进度会同步变化。
任务进度保存在localStorage中。刷新浏览器以后，身份和完成状态不会丢失。
用户也不需要完成全部内容后才能看到结果。完成1项任务时，系统会生成“初级探索者”报告；完成6项任务后，身份升级为“ChinaJoy探索大师”。
报告中会列出完成数、经验值、完成率、查看过的真实信息和公开来源。它相当于一次个性化的信息获取记录，而不是普通网页常见的结束页面。
我最初只是想让应用更有ChinaJoy氛围。做完后才发现，游戏化在这里确实解决了一个问题：它给信息增加了目标和进度。
面对20条列表，用户很容易随便看看；面对“寻找两项与AI NPC有关的内容”这样的任务，注意力会具体很多。
六、我更在意它有没有真的做完
AI编程演示中经常出现一种情况：页面看起来已经生成，按钮点不动；模型回复“已经完成”，项目却没有实际构建。
所以我在需求里单独写了一条：不能只给代码，必须启动并验证。
Doubao-Seed-Evolving完成了首页、身份生成、任务中心和探索报告四部分。兴趣选择、身份数据、任务状态和报告统计能够连续传递，页面在桌面端和移动端都可以使用。
项目开发完成后，模型调用终端执行生产构建。
构建共处理1577个模块，Vite用时3.28秒，没有报错。
这个数字本身没有太多可吹的，但它能说明一件事：模型交付的不是一张截图，而是一个可以运行和构建的React项目。整个开发中，Doubao-Seed-Evolving实际处理了几类不同任务：
- 从自然语言需求中确定功能范围；
- 阅读公开报道并整理数据；
- 设计标签和任务之间的映射关系；
- 编写React组件和状态逻辑；
- 保存用户进度；
- 调用终端完成构建验证。
这些工作连续发生在同一个任务中。中途增加真实数据和来源要求后，模型也没有推翻前面的页面，而是调整数据层和任务线索。
这更接近我对Coding Agent的期待。写代码只是其中一部分，它还要读资料、管理文件、执行命令，并对结果负责。
这次测试也有明确边界。ChinaJoy Quest没有实时地图、动态排队和在线检索，这些数据来自两个公开来源。它是一套可以交互的产品原型，不是已经投入运营的商业系统。
把这些限制写清楚，反而让结果更可信。
七、我为什么认为这件事值得继续做
写完代码以后，我又回头看了一遍最初的问题：面对接近900家参展企业和1000余款游戏，普通用户缺的真的是另一份攻略吗？
可能不是。
大家缺的是一种把公共信息重新组织成个人路径的方法。
ChinaJoy Quest目前只是一个小规模原型，但它已经跑通了这条链路：
收集公开资料
→ 判断信息是否可用
→ 转成结构化数据
→ 根据个人兴趣重新编排
→ 保留原始来源
→ 形成个人报告
换掉ChinaJoy数据，这套系统也可以用于开发者大会、动漫展或科技展。场景虽然不同，问题却很相似：信息从来不缺，缺的是一条适合自己的探索路径。
ChinaJoy Quest只用20条经过核验的信息，跑通了资料检索、兴趣识别、任务编排和结果沉淀。Doubao-Seed-Evolving在其中完成的不只是代码生成，还包括资料查证、结构化整理、功能开发和构建验证；遇到依据不足的内容，它没有继续补全，而是选择舍弃。
这让我看到，Doubao-Seed-Evolving的价值不只是“能写”，还在于能把一个模糊想法持续推进成可运行、可核验的结果。
这或许就是我理解的“与AI同游”：我负责提出真正想解决的问题，Doubao-Seed-Evolving负责理解、检索和执行，最后一起走出一条不同于普通攻略的探索路线。