上篇「我说轮子多造」提到的 Whistle 项目今天跑通了闭环，写一个实录。
日报这类产品理应定制化——每个人的隐性信息需求不同，而信息源膨胀、噪声加剧的当下，无关信息会侵占大量「内存」，盯盘也很费体力脑力。我相信未来日报的形态会是人人一个的高度定制 agent，更远的未来，人人都会有自己的定制 agent，日报则会作为一个小小的模块/skill。
这就是 Whistle 的目的。
它不做公共资讯产品，也不替代成熟的新闻聚合工具，更像一条私人信息管道：我选信息源、设过滤标准，agent 帮我读取、筛选、总结、排版，产出一份每天能快速扫完的互联网日报。
普通日报回答「今天大家应该知道什么」，Whistle 回答「今天有什么值得我知道」。
为什么要做#
我原来获取信息的方式很散。
X、GitHub、Hacker News、Product Hunt、各类 newsletter、朋友转发、论坛、模型发布页、博客和论文摘要——这些来源没有统一入口，每个都有自己的噪声：X 上情绪和重复转发多，GitHub trending 热闹但不一定有价值，新闻站为更新频率塞边角料，newsletter 又带作者的推荐偏好，互联网上没有绝对没有噪声的信息。
我真正需要的不是更多信息，而是更少但更贴近我的信息。
我不想每天打开十几个站点，也不想靠平台算法决定我看到什么。我想要一套相对固定的流程：
可信来源
→ 自动抓取
→ 按我的标准过滤
→ 合并重复信息
→ 提炼要点
→ 生成稳定格式
→ 定时发布和推送这件事过去也能做，但写爬虫、接 API、处理失败、设计模板、做部署、接邮件推送、维护定时任务——这些杂活对个人工具来说太容易让人放弃。
agent 把成本明显压下来了。我不需要一上来就把模块设计完整，可以先把闭环跑起来：信息源少一点、格式粗糙一点都行，只要每天能自动产出一份我愿意看的日报，这个项目就有价值。
第一版闭环#
Whistle 第一版没追求复杂，目标只有一个：每天早上自动生成一份互联网日报，方便我阅读。
基本链路是：
配置每日关注的信息源
→ Vercel Cron 定时触发 GitHub Actions
→ headless Codex 读取和整理信息
→ 生成结构化日报内容
→ 输出 HTML
→ 用浏览器能力顺带导出 PDF
→ 部署到一个 Next 静态站
→ 推送邮件提醒HTML 是主要产物。日报本质是给人读的，HTML 比纯 Markdown 更适合做信息层级、链接跳转、重点标注和版面控制。PDF 不重要，只是构建过程已经有浏览器环境，顺手导出作为归档版本。
Next 静态站也不是重点，只是一个方便的展示壳。Whistle 的核心是每天能不能稳定产出一份可读的日报，而不是前端框架。
第一版只守几个基本要求：
能自动跑
能看
能回溯
能改这四件事成立，就先别急着做复杂功能。
Agent 在里面做什么#
Whistle 里 agent 不是简单的「摘要器」。
把一堆网页丢给模型让它总结几段话，那确实太粗。日报真正麻烦的地方在于要做一系列判断：
这条信息是不是新信息？
它和昨天的内容有没有重复？
它是发布、传闻、融资、观点，还是教程？
它对我是否有意义？
它应该放在哪个栏目？
它需要一句话摘要，还是需要展开解释？
原始链接是否值得保留？
标题有没有夸大？这些判断很难用固定规则写死，但很适合交给 agent 做第一轮处理。
理想的分工是：
程序负责稳定性
Agent 负责判断和表达
人负责标准和验收程序保证任务按时启动、文件按格式生成、链接可访问、部署不出错；agent 负责提炼要点、合并重复、判断价值、写成自然语言；人则负责定义什么是「值得看」，并在日报跑偏时调整规则。
边界很重要。全交给 agent，系统不可控；全写硬规则，又失去灵活性。Whistle 把 agent 放进一条受约束的流水线，让它在固定位置发挥判断力。
日报应该长什么样#
做这个项目后，我对日报形态的判断更明确了：日报不应该只是信息列表。
一个好的个人日报至少要有三层。
第一层是快速扫读。让我在一分钟内知道今天有没有值得关注的大事，只需要标题、来源、重要性和一句话摘要。
第二层是主题归类。同一天的信息常常不是孤立的——某个模型发布、某家公司融资、某个开源项目爆火、某篇论文被讨论，背后可能指向同一个趋势。只按时间排序，很容易看不到这些关系。
第三层是可追溯链接。日报不能只给结论。每条内容都保留原始来源，方便我感兴趣时点进去看，否则就成了二手转述，而不是信息入口。
我希望 Whistle 的输出不是：
今天有十条新闻。而是更接近：
今天值得看的是三类变化。
每类变化下面有若干条来源。
每条来源都有一句话判断和原始链接。也不想把它做成纯聊天机器人。聊天适合临时问答，日报更适合稳定格式，每天同样的结构反而有利于形成阅读习惯。
第一版踩到的问题#
跑通闭环后，问题也明显。
第一是信息源质量。日报的上限取决于输入，源头不好，再漂亮的摘要和排版也没意义。agent 能过滤噪声，但凭空知不到没喂给它的信息。Whistle 后续最重要的工作不是做更多样式，而是持续维护信息源列表。
第二是重复信息。同一个发布会、同一个模型、同一个项目可能在多个来源里反复出现。不去重，日报会显得很满，但信息密度低。不能只做字符串去重，因为不同来源会用不同标题讲同一件事，更合适的方式是按事件合并而不是按链接合并。
第三是重要性判断。什么叫重要？因人而异：融资对投资人重要，对开发者一般；新模型参数对研究者重要，对普通用户不重要；某个工具更新对我有用，对别人可能只是小版本变动。Whistle 不该追求客观重要性，而该追求个人相关性——记住我的偏好，而不是假装在编辑大众媒体。
第四是格式稳定性。Agent 擅长写内容，但不一定每次都严格遵守结构。日报要自动发布，不能今天五个栏目、明天三个、后天又换一套标题体系。这里需要模板、schema 或后处理程序把产物约束住。
第五是成本。每天让 agent 读大量网页、做长上下文总结、再生成 HTML，成本会慢慢成问题。个人项目可以先不计较，但要长期跑，还是要考虑缓存、增量更新、分层摘要和失败重试。
为什么用 Agent#
日报很难完全写成规则。
一条新闻值不值得放、标题要不要改、几条来源是不是在说同一件事，这些判断都带模糊性。硬写规则也能做，但很快会变成一堆 if else，越补越累。
完全人工也不现实。每天打开来源、筛选、去重、整理、排版，做两天还行，长期就成负担。
agent 适合先把粗活做掉。它不需要替我做最后判断，只要先给出一版可读的日报：链接基本对、重复少一点、摘要别太离谱、栏目大致稳定，剩下的我再根据结果调整规则和信息源。
Whistle 不是让 agent 自由发挥的项目，而是把它放进一条固定流水线，该判断的地方判断，该输出的地方输出。流程尽量确定，模糊的部分交给模型。
这比纯脚本顺手。
后续想做什么#
第一是信息源配置。把信息源拆成更清楚的层级——AI 模型发布、开源项目、公司博客、论文、产品更新、行业观点——不同类型用不同的抓取和筛选规则，总之信息源还得由人来把控。
第二是事件合并。日报不该围绕链接组织，而该围绕事件组织。同一事件可以有多个来源，主来源负责事实，补充来源负责观点或细节。
第三是偏好规则。我要把偏好写得更明确：哪些主题优先、哪些来源降权、哪些类型直接忽略。否则 agent 只能按通用意义判断重要性，产物会越来越像普通资讯站。
第四是质量检查。自动生成后最好有一层检查：链接是否可访问、是否出现空栏目、是否有明显重复、是否缺少来源、是否出现过度肯定的表述。这些不一定都要由模型做，很多用脚本就够。
第五是更好的归档和搜索。日报当天看完就丢掉，价值会少一半。它应该能积累成自己的信息库，以后想回看某个模型、某家公司、某个项目的发展路径，可以直接在归档里搜到。
小结#
Whistle 目前还很早期，只是先把从信息源到日报产物的链路跑通了。
它不算新闻产品，更像私人信息过滤器：每天早上替我把来源扫一遍，压下重复和噪声，留下几条真正值得点开的东西。
后面要做的不是把它变复杂，而是让它更稳定、更贴近我的阅读习惯。信息源慢慢调，规则慢慢补，归档慢慢沉淀。只要它每天能少消耗我一点注意力，这个小轮子就算有用了。