创作者：Code_流苏（CSDN）（一个喜欢古诗词和编程的 Coder）

目录

• • 一、为什么要做一个“AI 朋友圈”？
  • 二、测试环境和方法
  • 三、Case 1：只给目标，看它怎么拆任务
  • 四、Case 2：把第一版真正跑起来
  • 五、Case 3：最难的其实不是搜索，而是敢不敢删
  • 六、Case 4：让它每天自己跑，还要允许失败
  • 七、最后让模型自己做一次升级&验收
  • 八、效果到底怎么样？
  • 总结

哈喽，大家好，我是流苏。

最近 AI 圈的更新，快得有点让人跟不上。

早上刚刷到一个新模型，下午可能就多了个 Agent；GitHub 里刚收藏完几个项目，时间线又被另一条技术路线刷满。消息一条接一条，但真正值得花时间看的，常常夹在转发、标题党和重复报道中间。

我以前看 AI 资讯，基本靠刷公众号、逛技术社区和翻社交平台。看到有用的就先丢进收藏夹，结果收藏夹越堆越满，真正回头读的没几篇。

所以这次测试 Doubao-Seed-Evolving 时，我想做一个自己会长期打开的东西：

一个每天自动更新的 AI 情报 Agent。它会帮我搜集 AI 动态，合并重复新闻，核对来源，再整理成一条像“朋友圈”一样的信息流。

打开网页，刷几分钟，今天 AI 圈发生了什么，大概就能有个数。

一、为什么要做一个“AI 朋友圈”？

我不缺 AI 新闻，缺的是筛选。

同一条模型发布消息，可能被十几个账号换着标题转发；一张未经证实的截图，几小时后也可能变成“重磅更新”。如果只是做个 RSS 阅读器，抓回来的内容越多，我反而看得越累。

我希望这个 Agent 做好四件事：

1. 每天从官方博客、RSS 和公开网页中收集 AI 动态；
2. 判断多篇内容是否在说同一件事，合并重复信息；
3. 保留原始来源，标记证据不足或相互冲突的消息；
4. 生成方便浏览的中文简报，并按日期保存。

这类任务正适合测试 Seed Evolving。它不只要写代码，还要检索、判断和核验信息。持续升级后的版本，在代码生成、检索准确性和幻觉控制上到底有没有进步，实际跑一遍就知道了。

这不只是写个页面。模型要先吃透需求，再把前后端、数据存储、定时任务、模型调用和异常恢复串起来。

任何一环掉链子，最后都只是个好看的 Demo，所以就比较考验模型的长程任务能力，以及全链路问题处理的能力。

OK，话不多说，我们先看一下本次测试的测试环境和方法

二、测试环境和方法

项目	测试信息
主要模型	Doubao-Seed-Evolving（火山Agent plan）
开发方式	Zcode
项目类型	AI 情报聚合网站 + 每日任务
数据来源	官方博客、RSS/Atom 和允许访问的公开页面
模型调用	通过环境变量配置火山方舟模型接口
数据存储	由模型根据环境自己选择，建议 SQLite
定时规则	每天固定时间运行，也支持手动刷新

和第一期一样，我没有提前写好技术方案让模型照着执行。在刚开始，只给了目标、参考链接和几条边界，让它先检查环境、自己拟定计划。

为了方便观察，我把测试分成四轮，每轮都留下一个可以截图记录的阶段成果。

三、Case 1：只给目标，看它怎么拆任务

第一轮我没有让 Seed Evolving 立刻写代码，而是先分析参考网站和公开 Skill，再设计自己的实现方案。

我使用的提示词如下：

我要做一个名为“AI 朋友圈”的个人非商业项目。它每天自动收集 AI 圈动态，完成清洗、去重、来源核验、分类和中文摘要，再用类似朋友圈的信息流展示。
参考 Skill：https://github.com/KKKKhazix/khazix-skills/blob/main/aihot/SKILL.md
请先阅读参考内容并检查当前项目目录，不要马上写代码。参考它们的信息架构和工作流，但不要复制 AIHOT 的品牌、Logo、文案、数据、接口响应或源代码，也不要把项目做成公开镜像，要自研完成。
请先输出：需求理解、功能边界、数据流、页面结构、技术方案、风险点和分阶段执行计划。说明哪些信息来自参考资料，哪些是你为本项目提出的设计。等我确认后再实现。

初始对话界面：

这里我主要观察两件事。

第一，它会不会一上来就生成一个只有静态卡片的首页。

第二，它能不能意识到“每天自动更新”涉及数据源、模型输出结构、持久化、任务调度和失败回退，不是加一个定时器按钮就结束了。

case1 实测结果：显然，它并没有这样做，给出了详细的设计，并且对于需要确认的信息寻求我的确认。

那么确认完之后，我希望它能把MVP（最小可行性产品）先跑起来。

四、Case 2：把第一版真正跑起来

我使用的提示词如下：

这次我没有指定死技术栈。已有项目就沿用原来的结构；如果目录为空，则优先选择轻量的技术栈，具体的你来决定，减少构建和部署成本。
核心要求包括：
- 信源清单要确保合规、稳定，不稳定地暂不接入；
- LLM用火山引擎的Agent plan的 doubao-seed-evolving 模型
- 首页按日期展示 AI 动态；
- 有今日精选、全部动态、热点、日报、主题和收藏；
- 支持关键词搜索、分类筛选、深浅色模式和移动端；
- 每条内容必须保留来源、原文链接和时间；
- 没有真实数据时可以提供明确标注的演示模式，不能把演示数据伪装成当天新闻。
- 部署倾向：先实现本地打开使用

初始对话界面：

从截图上看，页面效果当然重要，但我更关心它有没有把功能接起来。

比如收藏刷新后是否还在，筛选条件是否真的改变列表，手动刷新是否触发后端任务，而不是所有按钮都只能点一下。

case2 实测结果：


页面刷新一下，收藏状态依然存在，说明并不是刷新一下就消失的"毛坯房"。

五、Case 3：最难的其实不是搜索，而是敢不敢删

资讯聚合最容易出现一种假象：页面上有几十条内容，看起来很热闹，实际一半都在说同一件事。

所以第三轮我把重点放在数据处理上，让 Seed Evolving 给每条候选信息保留完整证据链，并把“精选”变成一套能解释的规则。

我要求它按以下顺序处理：

采集候选内容 → 统一字段 → 规范链接 → 重复检测 → 来源核验 → 分类与评分 → 生成摘要 → 写入数据库 → 生成日报

其中，来源状态分为三种：

• 找到官方原始来源，标记为“官方来源”；
• 没有官方来源，但有两个相互独立的可靠来源，标记为“交叉验证”；
• 只有单一二手来源，标记为“单一来源”，不能写成已经确认的事实。

如果不同来源在发布时间、版本名称或具体数字上互相冲突，Agent 要保留分歧，不替它们强行编一个统一答案。

这次我的提示词就长了一些，也尽可能让模型在执行长程任务时目标比较精准：

现在继续完善“AI 朋友圈”，这一轮重点处理资讯去重、来源核验和幻觉控制。

请先检查当前项目已经实现的数据结构、采集流程和数据库，不要推翻 Case 2 的已有架构，也不要重做无关页面。在现有项目上完成改造，并保证原有功能继续可用。

请将情报处理流程调整为：

采集候选内容 → 统一字段 → 规范链接 → 重复检测与事件聚类 → 来源核验 → 分类与评分 → 生成中文摘要 → 写入数据库 → 生成日报

具体要求如下。

一、统一资讯字段

每条候选资讯至少保存：

- 原始标题；
- 中文标题；
- 原始摘要或可核对的内容片段；
- 来源名称；
- 原文链接；
- 原文发布时间；
- 系统采集时间；
- 分类；
- 规范化链接；
- 所属事件 ID；
- 来源核验状态；
- 评分及评分依据；
- 中文摘要；
- 推荐理由。

字段缺失时保留为空并明确标记，不能让模型凭空补齐日期、版本号、价格、参数或引用。

二、规范链接与重复检测

先清理 URL 中不影响正文内容的跟踪参数，识别同一页面的不同链接形式。

重复检测不能只比较标题是否完全相同，请综合判断：

- 规范化后的原文链接；
- 标题语义相似度；
- 公司、模型、产品等核心实体；
- 事件发生时间；
- 版本号和发布动作；
- 内容是否指向同一份官方公告。

确认属于同一事件的内容应合并到同一个事件组，但必须保留每个来源及其原文链接。不要直接删除全部重复记录，要让用户可以查看该事件有哪些信源。

三、来源核验

为每个事件设置明确的核验状态：

1. “官方来源”：找到了厂商官网、官方博客、官方文档、论文主页或项目仓库等原始来源；
2. “交叉验证”：没有找到官方原文，但至少有两个相互独立、内容一致的可靠来源；
3. “单一来源”：只有一个二手来源，或无法找到可核对的原始出处；
4. “信息冲突”：不同来源对发布时间、版本名称、价格、参数或其他重要事实描述不一致。

“单一来源”和“信息冲突”的内容不能使用已经确认的语气。摘要中要明确写出“据该来源称”“目前仅有单一来源”或“不同来源说法不一致”等提示。

遇到冲突时保留各来源的原始说法，不要擅自选择一个数字，也不要把不同说法平均、拼接成新的结论。

四、精选与评分规则

请把“精选”改成一套可解释的规则，不要只让模型给出一个没有依据的总分。

可以根据现有项目调整权重，但至少考虑：

- 与 AI 主题的相关程度；
- 信息的新颖度；
- 对开发者或普通用户的实际影响；
- 来源可靠性；
- 是否属于重复报道；
- 是否存在证据冲突。

页面需要显示简洁的评分依据，让用户知道一条内容为什么进入精选。来源不可靠或存在明显冲突的内容原则上不进入今日精选，但可以保留在“全部动态”中。

五、构造四类测试数据

请增加一组明确标注为“DEMO/测试数据”的测试夹具，覆盖以下情况：

1. 同一条官方公告的英文原文、中文转载和另一篇媒体报道；
2. 两篇标题差异较大，但实际指向同一产品更新的报道；
3. 一条找不到原始出处的社交平台传言；
4. 两篇对同一个重要数字描述不一致的文章。

测试数据不能冒充当天真实新闻，也不要使用真实公司尚未发布的产品、价格或参数。

请为每组数据写出预期结果，包括：

- 应该被归为几个事件；
- 哪些记录应该合并；
- 最终核验状态；
- 是否进入今日精选；
- 页面应该显示什么风险提示。

六、页面展示

请在现有资讯卡片或事件详情中补充：

- 核验状态标签；
- 当前事件包含的信源数量；
- 官方来源或原始出处；
- “查看全部信源”入口；
- 评分依据；
- 单一来源提示；
- 信息冲突提示和各来源说法。

界面保持现有设计风格，不要因为增加这些信息导致卡片过度拥挤。风险状态不能只靠颜色区分，还要有文字标签。

七、测试和验收

完成后请：

1. 运行新增加的去重、事件聚类、来源核验和评分测试；
2. 用四组测试夹具实际执行一次完整流程；
3. 如果当前信源和网络可用，再对真实采集数据运行一次，但不要为了展示效果伪造结果；
4. 在浏览器中检查今日精选、全部动态、事件信源和冲突提示；
5. 确认刷新页面后，事件分组和核验结果仍然保存在数据库中；
6. 确认重复运行不会再次创建相同事件。

最后输出一份实测报告，必须包含：

- 输入的候选资讯数量；
- 合并后的事件数量；
- 合并掉的重复记录数量；
- 官方来源、交叉验证、单一来源和信息冲突各有多少条；
- 哪些内容没有进入今日精选，以及具体原因；
- 一个去重成功的案例；
- 一个证据不足或信息冲突的案例；
- 修改了哪些文件；
- 自动测试和浏览器检查结果；
- 仍未验证或受网络环境限制的部分。

不要只总结“功能已经完成”。请保留真实运行数据和关键处理日志，方便我截图记录测试过程。

初始对话界面：

case3 实测结果：
它成功地对现有的最初可用版本进行了升级优化，并对采集到的数据信息进行过滤和补充。

六、Case 4：让它每天自己跑，还要允许失败

跑通一次，不代表 Agent 能长期稳定运行。

第四轮，我让 Seed Evolving 加入了每日定时任务：按 Asia/Shanghai 时区执行，同时保留“立即刷新”入口。同一天重复运行，也不能反复写入同一批新闻。

当然，这点考验不算结束，它还得应付几种常见故障：RSS 无法访问、模型接口超时、结构化输出解析失败，以及任务中途退出。

我的提示词如下：

现在进入 Case 4。请继续完善现有的“AI 朋友圈”，加入每日自动运行、失败处理和中断恢复，不要重做已有功能。

具体要求：

1. 默认按照 Asia/Shanghai 时区每天 08:30 执行一次完整情报任务，并允许通过配置修改时间；
2. 保留“立即刷新”按钮，同时提供命令行手动运行入口；
3. 自动任务、手动刷新和命令行必须共用同一套执行流程；
4. 增加任务锁和幂等机制。同一天重复运行、重复点击刷新或自动与手动任务同时触发时，不能产生重复资讯和重复日报；
5. 保存每次任务的开始时间、结束时间、当前阶段、运行状态、新增数、更新数、跳过数和错误摘要；
6. 单个 RSS 失效时有限重试，仍失败则跳过该来源，继续处理其他来源；
7. Doubao-Seed-Evolving 接口超时或返回无效 JSON 时有限重试，仍失败则将内容标记为“待处理”，不能编造摘要；
8. 整轮任务失败时保留上一次成功的数据和日报；
9. 任务中途退出后，程序再次启动时应识别中断任务。可以安全恢复就继续，否则依靠幂等机制重新执行；
10. 页面显示当前状态、最近运行时间、最近成功时间、下次执行时间和失败来源数量。

项目目前以本地使用为主。请说明程序需要保持运行才能触发内部定时任务，并在 README 中补充使用 Windows 任务计划程序调用每日命令的方式，但不要自动修改系统设置。

请测试以下场景：

- 一个 RSS 来源超时；
- 模型接口超时或返回无效 JSON；
- 同一天连续运行两次；
- 自动任务与手动刷新同时触发；
- 任务运行中途退出；
- 任务失败后检查上一次成功日报是否仍然存在。

完成后实际运行并验收，输出本轮新增数、更新数、跳过数、失败来源数、重复运行结果、故障测试结果、修改文件和仍未验证的部分。保留任务日志和错误页面，方便我截图。

初始对话界面：

case4 实测结果：
成功加入了每日自动运行、失败处理和中断恢复，而且整体回复和改动脉络清晰。

七、最后让模型自己做一次升级&验收

功能完成后，我没有直接开始截图，而是让 Seed Evolving 最终再升级一下样式，之后对整体review。

我的提示词设计如下：

对当前网站页面样式、UI、效果展示进行升级优化：
升级优化标准：
1.图标：统一使用 Lucide 图标，界面全程禁止使用表情符号。
2.设计标准：对标 Awwwards 顶级网站水准，达到 Awwwards、FWA、CSS Design Awards 每日最佳网站同等设计品质。
3.创意自由度：将浏览器视作交互式艺术画布，跳出传统布局框架，追求先锋视觉风格、实验性排版、流畅物理动效、极具冲击力的文字版式。
4.沉浸式体验：融合代码、高级渲染逻辑，打造统一完整的精品页面，做出突破常规 UI 认知、令人惊艳的数字交互体验。

初始对话界面：

最终效果：

明亮模式

暗黑模式

升级完了，接下来我们让Seed Evolving回头review整个项目。

提示词设计如下：

对项目进行验收，验收内容主要包括：
- 启动命令能否在一个干净环境中执行；
- 搜索、筛选、收藏和主题切换是否正常；
- 手动刷新是否真的触发采集任务；
- 去重、来源状态和日期分组是否符合规则；
- 缺少模型密钥时是否给出明确提示；
- 定时任务失败后是否保留上一次成功数据；
- README、`.env.example` 和配置说明是否齐全；
- 页面在桌面端和手机宽度下是否可用。

初始对话界面：

这一步正好能看出模型能不能处理长程任务。做到后半段，上下文里已经塞满需求、代码、报错和多轮修改。

它得重新对照最初目标，逐项检查并修复，而不是只盯着最后一句指令。做到这一点，任务才算真正的收尾。

八、效果到底怎么样？

观察项	实测结果
从开始到首版可运行	首版编码、采集和浏览器验证约用了 57 分 43 秒。Case 1 的方案分析时间未单独计入。
总工具调用轮次	Zcode 未提供汇总数据。整个项目从规划到验收都在同一个对话中完成。
首轮候选资讯	首版实际抓取 179 条真实数据，当时接入的 19 个信源全部健康。
去重后保留事件	最终验收时，202 条报道被整理为 186 个事件，共合并 16 条重复或多来源报道。
官方来源数量	正文没有单独统计“官方来源”条目数。项目最终配置了 20 个信源，首版运行时有 19 个信源正常。
单一来源或冲突内容	没有记录总数。页面已经实现官方来源、交叉验证、单一来源和信息冲突四种状态，并实际显示了单一来源与多来源聚合案例。
完成过程中人工纠正次数	0 次推倒重做式纠正；在首版基础上追加了 Case 3、Case 4、UI 升级和最终验收等分阶段指令。
定时任务和失败恢复	核心测试通过。模拟异常后，任务会标记为失败，旧数据 MD5 保持不变，最近成功时间继续保留。边界是程序内定时任务需要服务持续运行；Windows 任务计划程序已经写入 README，但还没有经过连续多天的真实运行验证。
桌面端与移动端检查	通过。桌面端以 1440px 检查，移动端使用 iPhone 15、393px 宽度模拟；搜索框、标签和卡片布局正常。控制台没有功能性 JS 错误，仅有一个不影响使用的 favicon.ico 404。

这次 Seed Evolving 在同一个对话里完成了需求梳理、首版开发、规则调整、定时任务和验收。做到后半程，它仍会回头检查最初的要求，包括内容去重、来源状态和失败保护，没有被最后几条指令带偏。

实测结论： 好的地方在于，Doubao-Seed-Evolving全程只开了1个对话完成了本次项目初版本的搭建，而且效果相比上一次测试有较为明显的进步，问题在于长程任务时可能会遇到重新连接的情况，这个可能和网络连接稳定性有关，我会长期使用，进一步打磨“AI朋友圈”，作为自己的AI情报站。

总结

这次我让 Doubao-Seed-Evolving 做了一个每天更新的“AI 朋友圈”。并提交到了GitHub，大家可以查看项目链接：https://github.com/yueliusu/ai-news

从最初拆解参考产品，到把前后端跑起来，再到处理重复数据、核对来源、生成日报、设置定时任务，中间比我预想的麻烦一些。页面能出来只是第一步，后面的数据问题和运行细节，才是真正占时间的地方。

它到底好不好用，还得看接下来每天跑出来的结果。对我来说，这次测试有意思的地方也在这里：模型面对的已经不是“帮我写个页面”这种一次性交付，而是一个需要持续运行的小系统。需求会改，外部数据会出错，任务也可能中途停掉，最后还得有人回来检查、补上缺的部分。

如果它能稳定地在每天早上跑完，我打开网页时，看到的应该不会是一整面新闻，而是一份已经筛过一遍的 AI 动态。

至于能不能因此少刷半小时手机，跑几天就知道了。

创作者：Code_流苏（CSDN）（一个喜欢古诗词和编程的 Coder）