创作者Code_流苏CSDN一个喜欢古诗词和编程的 Coder目录一、为什么要做一个“AI 朋友圈”二、测试环境和方法三、Case 1只给目标看它怎么拆任务四、Case 2把第一版真正跑起来五、Case 3最难的其实不是搜索而是敢不敢删六、Case 4让它每天自己跑还要允许失败七、最后让模型自己做一次升级验收八、效果到底怎么样总结哈喽大家好我是流苏。最近 AI 圈的更新快得有点让人跟不上。早上刚刷到一个新模型下午可能就多了个 AgentGitHub 里刚收藏完几个项目时间线又被另一条技术路线刷满。消息一条接一条但真正值得花时间看的常常夹在转发、标题党和重复报道中间。我以前看 AI 资讯基本靠刷公众号、逛技术社区和翻社交平台。看到有用的就先丢进收藏夹结果收藏夹越堆越满真正回头读的没几篇。所以这次测试 Doubao-Seed-Evolving 时我想做一个自己会长期打开的东西一个每天自动更新的 AI 情报 Agent。它会帮我搜集 AI 动态合并重复新闻核对来源再整理成一条像“朋友圈”一样的信息流。打开网页刷几分钟今天 AI 圈发生了什么大概就能有个数。一、为什么要做一个“AI 朋友圈”我不缺 AI 新闻缺的是筛选。同一条模型发布消息可能被十几个账号换着标题转发一张未经证实的截图几小时后也可能变成“重磅更新”。如果只是做个 RSS 阅读器抓回来的内容越多我反而看得越累。我希望这个 Agent 做好四件事每天从官方博客、RSS 和公开网页中收集AI 动态判断多篇内容是否在说同一件事合并重复信息保留原始来源标记证据不足或相互冲突的消息生成方便浏览的中文简报并按日期保存。这类任务正适合测试 Seed Evolving。它不只要写代码还要检索、判断和核验信息。持续升级后的版本在代码生成、检索准确性和幻觉控制上到底有没有进步实际跑一遍就知道了。这不只是写个页面。模型要先吃透需求再把前后端、数据存储、定时任务、模型调用和异常恢复串起来。任何一环掉链子最后都只是个好看的 Demo所以就比较考验模型的长程任务能力以及全链路问题处理的能力。OK话不多说我们先看一下本次测试的测试环境和方法二、测试环境和方法项目测试信息主要模型Doubao-Seed-Evolving火山Agent plan开发方式Zcode项目类型AI 情报聚合网站 每日任务数据来源官方博客、RSS/Atom 和允许访问的公开页面模型调用通过环境变量配置火山方舟模型接口数据存储由模型根据环境自己选择建议 SQLite定时规则每天固定时间运行也支持手动刷新和第一期一样我没有提前写好技术方案让模型照着执行。在刚开始只给了目标、参考链接和几条边界让它先检查环境、自己拟定计划。为了方便观察我把测试分成四轮每轮都留下一个可以截图记录的阶段成果。三、Case 1只给目标看它怎么拆任务第一轮我没有让 Seed Evolving 立刻写代码而是先分析参考网站和公开 Skill再设计自己的实现方案。我使用的提示词如下我要做一个名为“AI 朋友圈”的个人非商业项目。它每天自动收集 AI 圈动态完成清洗、去重、来源核验、分类和中文摘要再用类似朋友圈的信息流展示。 参考 Skillhttps://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