《AI 日报 · 2026-09-22》是我给自己定下的一个长期小项目每天雷打不动产出一份面向开发者与技术从业者的AI信息日报。这个名字里的日期既是归档标记也是交付标准——它逼着你把当天出现的AI大模型、AI agent、AI编程、AI应用开发、本地部署AI等散落信息收敛成几条能直接指导行动的判断。适合谁看适合每天被海量信息淹没、又不想因为漏掉一条关键新闻就多走弯路的人。也适合正在琢磨“怎么用AI工作流提高效率”的你。先把话说在前面这个项目不复杂但坑很多下面把我踩过的和补过的路都摊开讲。1. 日报的整体设计与思路拆解1.1 为什么非要做一份属于自己的AI日报每天翻社区、刷新闻、看群里讨论信息量大到让人失去判断力。我一开始以为“收藏了就等于知道了”结果一个月后回头一看收藏夹里有几百条内容真正能说出所以然的没几条。于是我开始倒逼自己每天选一批AI相关内容写成日报要求每一条都写清楚“这条消息为什么重要我的态度是什么”。日报的价值不在“搬运”而在“筛选”。AI大模型每隔一段时间就有新版本、新论文、新框架AI agent已经从一个概念演变成能实际跑任务的工具链AI编程插件从能补全代码进化到能改bug、写测试。这些变化都有各自的时间窗口。你晚一两天知道可能只是少聊一句你晚一两周知道可能就会在技术选型上做出错误的决定。做日报就是给自己安装一个“强制关注机制”。这个项目本身也很有意思你是在用AI工作流来监控AI动态。收集依靠RSS源和仓库热榜初筛交给AI agent摘要让大模型来写最后人工审核。整个流程跑顺之后你会发现“信息管理”这件事本身就是最好的AI应用开发练习。1.2 栏目结构按“可执行”而不是“技术层级”来划分我第一版日报划分得很学术按“计算机视觉”“自然语言处理”“多模态”来分栏结果没人看连我自己都经常跳过。后来我想通了日报不该像论文目录它应该像一份个人工作的“优先级队列”。目前我的固定栏目长这样栏目名收录内容判断标准模型与底座新发布的大模型、推理引擎、支持本地部署AI的框架值不值得花一个晚上跑个demo验证开发与应用AI应用、AI agent、应用开发框架和API更新能不能接进我当下的项目模块编程与工具AI编程插件、提示词技巧、AI辅助测试工具能不能让我今天写代码更快、更少返工教程与工作流部署教程、面向AI应用开发的完整工作流能不能直接照抄、有没有提供实测数据待求证消息热度高但是来源单一的新闻只进列表不写判断等核实这个结构比纯技术分类好用得多原因很简单栏目本质上是“今天我需要消费什么”而不是“学术上应该怎么命名”。比如一条“某大模型本地部署配置指南”会被放到底座栏而同一条新闻如果用语言模型API发布就会被放到开发与应用栏。同样的新闻落在哪个栏目取决于你能拿它干什么这是日报和资讯聚合站最大的区别。1.3 收稿门槛宁可少写三条也不碰标题党日报的版面是有限的但AI每天产出的新内容远超过你能消化的量。这时候最关键的决策不是“选哪些”而是“拒掉哪些”。我定了几条硬标准必须有可点击、可回溯的原文链接。没有链接的一律不收。消息必须能对应到具体版本号、项目名、API名称或事件时间不接受“某头部机构正在研究”这类模糊措辞。与大语言模型、开发框架或AI工具链无关的内容不进技术日报哪怕它在热搜榜第一。已经连续报道过三天以上没有新进展的消息自动降级。这套标准非常有帮助。它逼我每天在初筛阶段砍掉80%的候选条目让剩下的20%有足够空间写清楚。很多人做日报喜欢凑条数一天塞二十条每条只有标题链接名曰“速报”实际上看的人一个都记不住。日报像钱包容量有限里面应该放高价值的卡片而不是杂乱收据。2. 从信息源到成品工具选型与流水线设计2.1 信息源RSS、仓库热榜和垂直社区做日报最怕的不是条目少而是信息源单一。单一来源的必然结果是有严重的视角偏差只刷GitHub的人会以为全世界都在造轮子只刷自媒体的人会以为大模型发布了20个版本其实未必。我现在稳定使用几类信息源按重要程度排序可靠RSS源主流AI论文站点、大厂AI技术博客、核心框架官方博客。这类源更新速度中等但准确度最高适合做定盘星。开源仓库热榜GitHub Trending、PaperHub这类站点按每日、每周变化能第一时间反映出开发者真正在玩什么对AI编程和AI应用开发尤其敏感。垂直社区比如各类AI技术讨论区、知识社区里的专业频道。这里能看到真实问题比如“谁谁部署时踩了坑”“这个AI agent为什么不能连续调用工具”。自己维护的线索池平时遇到有意思的链接先丢进一个临时列表等到做日报时再逐条确认。这个池子长期积累下来比任何现成热榜都懂你。采集层很朴素的就一样需求稳定。你不需要一个花哨的爬虫系统你需要的是每天同一时间能把新内容抓下来就算某个网站挂了也不能让整条流水线停工。2.2 AI agent 负责跑腿大模型负责动脑选型阶段不少人和我一样纠结一个问题日报里的摘要到底让AI agent自动生成还是自己手动写我的经验是这是两件事得拆开看。AI agent适合做规则明确、重复性高的动作抓取页面、解析发布时间、过滤重复标题、提取关键词、把“标题不符合格式”的内容丢进回收站。这些事不需要创意需要准确、稳定的执行让agent来做人类几乎不需要干预。大模型适合做语义任务生成摘要、判断栏目归属、提炼“这件事和我有什么关系”。但大模型有一个无法根除的问题——它会在训练数据中读到过类似的文章然后凭记忆而不是凭你给的原文生成内容这就产生了所谓的“AI幻觉”。所以我把两者串成一个环agent负责把原始材料交给大模型大模型输出带“可信度标记”的摘要初稿再由agent把初稿和原文链接打包送进人工审核列表。大模型不直接发布任何东西它只是“起草人”不是“责任编辑”。2.3 本地部署AI与云端API混合调度日报每天都产出大量文本如果全部调云端API成本高且速度不稳定。尤其是初筛阶段要对几十条新闻做快速打标大约用大模型应该尽量便宜。我这里用了一个混合调度策略场景用什么原因海量条目初筛本地部署AI小模型隐私好、批量跑几乎零边际成本、可以短超时反复试正式摘要生成云端API大模型理解能力强、摘要更符合自然习惯、能处理长上下文标题去重与规则清洗无模型纯脚本模型不适合做精确匹配正则和集合运算更可靠本地部署AI并不是大家想的“免费午餐”它对显存和内存有硬门槛。我早期用一台老显卡跑7B参数模型速度勉强能在夜间处理完一天积累的条目但如果当天消息特别多就会拖到凌晨。后来设了“budget”概念初筛任务最多跑30分钟跑不完就排队等API高峰期过了再补。实操中有一个很管用的原则本地部署的模型能力不够就让它的任务简单点。不要试图让它输出现场非常完美摘要只需要输出“这是哪类新闻、哪些关键词值得提取、可信度打分”这样的任务它能胜任。2.4 工作流每天都在跑简单才能长期坚持我见过不少人搭建日报系统做得比生产环境还复杂分布式采集、消息队列、向量数据库、用户前台齐活。但实际情况是日报是一个“个人流程”它最重要的指标是可持续性不是架构的复杂性。如果某一天你因为出差、开会、网络故障少跑了一步整个流程就中断了你得花双倍时间补救这不可持续。我的工作流骨架已经压到最短定时任务拉取所有信息源原始内容。脚本去重、剔除禁止词和广告链接按栏目粗分。本地模型初筛云端模型生成摘要。摘要进入人工复核队列在里面打勾、改错、补链接。确认无误后生成Markdown文件作为当天版本的日报。整个流程没有图形界面全靠命令行脚本加待办清单。你问我为什么不做成网站因为对我来说“发布到网站”不会增加信息价值只会增加维护成本。个人日报的第一消费者是自己先满足自己再考虑是否分享给别人。3. 实操过程一份日报是怎么跑出来的3.1 采集层的Python脚本单源失败不影响发版我用的采集工具比较朴素Python标准库加feedparser和httpx主逻辑是遍历信息源把标题、链接、摘要、发布时间存成统一结构。这一步的关键诉求是“坏一个源不能坏整份日报”所以所有网络请求都套了异常捕获和超时控制。下面是采集层的核心片段和实际跑的样子差别不大只是源列表更多import feedparser import httpx sources [ {name: arxiv_cs_ai, url: https://rss.arxiv.org/rss/cs.AI, section: 模型与底座}, {name: github_trending, url: https://github.com/trending?sincedaily, section: 编程与工具}, ] timeout httpx.Timeout(connect10.0, read15.0) def fetch_source(source): # 每个源单独抓取异常只记录不中断 result [] try: httpx.get(source[url], timeouttimeout) # 预留真实下载页面的逻辑 feed feedparser.parse(source[url]) for entry in feed.entries[:25]: result.append({ title: entry.title, link: entry.link, summary: entry.get(summary, )[:300], source: source[name], section: source[section], }) except Exception as exc: log_error(source[name], exc) return result def collect_all(pool): items [] for src in pool: items.extend(fetch_source(src)) return items为什么要强制设置超时因为有些源响应速度很慢平时3秒内能返回某天可能突然重试30秒都拿不到如果整个流程跟着卡死日报就完蛋。设置连接超时10秒、读取超时15秒之后一个源失败大约半分钟就会跳过其他源继续跑。另外注意feedparser是解析RSS的常用方式如果你接入的站点没有RSS可以退而求其次直接抓取HTML中的和meta标签但稳定性差很多建议优先选RSS。/p h33.2 提示词模板设计顺带把AI幻觉按下去/h3 p摘要生成阶段我用一个非常固定的提示词模板和平时聊天式的请求完全不一样。任何AI产品想要稳定输出都不能指望模型自己发挥。我的模板有三个层次角色设定、任务拆分、输出纪律。最关键的是最后一条它专门对付AI幻觉。/p precode classlanguage-text你是一名AI日报的文字编辑。给你一条候选新闻的标题、摘要和原文链接。 请你 1. 用150字以内写一条中文摘要聚焦“这件事是什么”和“为什么值得关注”。 2. 判断这条新闻属于我规定的栏目只能从以下中选 模型与底座 / 开发与应用 / 编程与工具 / 教程与工作流 3. 判断这条新闻的可信度 - 可信原文有明确机构、发布渠道、发布时间 - 存疑标题与内容不一致或只有单一来源 - 待求证你无法判断但感觉可疑 4. 如果你无法从原文链接中看到足够的信息直接输出“信息不足”不要编造内容。 5. 禁止使用“值得注意”“引发热议”“重大突破”这类空话。 输出格式必须是JSON不要添加额外解释。 /code/pre p这套提示词运行了很长时间最宝贵的不是摘要质量而是“信息不足”这个选项。很多AI幻觉是从人提问开始的问题本身没有设定边界模型就会自觉补全。你明确告诉它“看不到信息就直说别编”幻觉发生概率会大幅下降。当然完全消除是不可能的这也就是为什么下一步人工审核绝对不能被省。/p h33.3 人工验证、清洗与发布/h3 p从初稿到可发布的日报中间隔着一道人工关卡。这个过程我没有自动化也不推荐自动化原因是现在的模型判断力还达不到“能对代价负责”的程度。你可能觉得只是自己看的一条日报没有法律风险但试想一下你写了一条不存在的模型版本号然后你自己根据这条信息做了技术决策这本质上是被自己的日报坑了。/p p我的人工审核只做三件事/p p第一反查原文标题。把标题复制到搜索里看看是否真实存在真实页面如果搜不到直接弃稿。/p p第二验证链接域名和发布时间。很多AI agent会把存量旧闻重新包装成今日新闻这是最隐蔽的失误。你只要检查一下链接里是否有明确日期就能拦住一半。/p p第三给摘要里的数字做一致性检查。模型容易在数字上犯糊涂比如把“8B参数”写成“80B”把“第四轮评测”写成“首轮评测”这类错误往往摘要读起来很顺但数字完全错了。/p p做完这三件事我才会把条目写进日报。如果某条新闻特别重要但原文时间无法确认我会把它放进“待求证消息”栏目并在文末标注“发布前未经源站确认”宁可丢脸不能造谣。/p h33.4 当天归档模板示例AI日报 2026-09-22/h3 p当你把流程跑顺“每天出一期”就变成了简单的“归档”。下面是我某一天也就是项目名字里的2026-09-22实际生成的日报结构具体新闻内容不展开了重点看结构怎么承接到前面的工作流/p ul li今日关注3条 ul li选3条对技术方向有影响力的消息每条附一句“为什么重要”。/li /ul /li li开发与应用3-5条 ul li包括AI agent框架、应用开发案例、API更新。/li /ul /li li编程与工具3条 ul li记录AI编程插件、提示词技巧、测试工具不分排名只列改动。/li /ul /li li教程与工作流2条 ul li包括本地部署AI配置心得、端到端工作流拆解。/li /ul /li li待求证消息不超过2条 ul li单列表格注明线索来源不给结论。/li /ul /li /ul p这套模板最大的好处是它既是“产出”也是“存档”。一个月之后回头看每一期就是当时技术社区的一次快照。你去翻那些天的日报能清楚感受到AI agent的讨论热度从概念走向落地AI编程工具从“能写片段”到“能自动修bug”本地部署AI从“极客玩具”变成“企业数据合规方案”这是一条非常清晰的脉络。/p h24. 常见问题与排查技巧实录/h2 h34.1 AI摘要“AI味”太重怎么处理/h3 p只要让大模型写摘要就会遇到一种典型的“AI味”好像说了很多又好像什么都没说。“值得注意的是”“引起了广泛关注”“具有巨大的潜力”这类虚词几乎成了模型的口头禅。我之前一度以为是模型不够聪明换了很多提示词之后才发现问题的关键是模型默认会追求“周全”的表达——它不敢把话说死于是只好用空词填充。/p p解决办法是强制禁用词列表。我在提示词里加了一行/p precode classlanguage-text禁止使用以下词汇重要、值得关注、强调、显著、突破、潜力、赋能、助力如果摘要里出现这些词请重写。 /code/pre p这个思路很简单效果也非常明显。你把自己最反感的空话列出来让模型避开它就会被逼着去描述具体事实和数字。比如同样是介绍AI编程插件更新禁用虚词后的摘要会变成“支持在提交代码前自动生成变更描述需要Python 3.10当前版本仍处于beta阶段”这比“重大更新引领AI编程新潮流”有用得多。/p h34.2 文章摘要抓不全链接失效怎么办/h3 p日报的素材来源大部分是RSS摘要很多网站只给前一两百字。如果你只基于那一点点内容做摘要很可能误判整篇文章的主题。我为此加了“原文二次抓取”当摘要长度不足的时候用httpx把原文HTML抓下来再抽取正文中最前面的若干段作为摘要参考。/p p这个流程里最常见的问题是链接失效。有些新闻发布几小时后就被网站下架了或者反爬策略把我们的请求挂掉。我的处理方法是在采集层直接记录失败状态不要等日报生成时才去重试。如果某条内容只有单一来源且已失效我会直接从候选里移除。日报本来就该宁缺毋滥不要为了凑期数而把死链接贴进去。/p p另外一个实操技巧是给所有外部请求统一加浏览器User-Agent很多技术网站看到默认httpx请求会直接拒绝。这个问题容易排查只要连续多天发现某个RSS源一直零数据先看看是不是被反爬拦截绝大多数是它而不是源本身没更新。/p h34.3 本地部署AI太耗显存成本失控怎么办/h3 p本地部署AI模型听起来省钱实际跑起来未必。7B参数模型在纯CPU上跑一个条目初筛可能要半分钟如果每天积累100条新闻光初筛就是将近一个小时。GPU支持当然舒服但显卡显存也有约束大点的模型放不下小点的模型效果又不行。/p p我的经验是“给任务分级再决定模型大小”。初筛任务很简单只需要“新闻类型判断关键词抽取”这类任务用最小的可用模型就能完成设定显存占用低、速度更快。正式摘要就交给云端API模型的理解能力更强摘要更容易读。还有一点某类新闻有固定历史模板比如“框架新版本发布”这种其实都不用模型直接写规则让它匹配版本号就行。用规则和正则去跑比花钱让大模型跑还准确。说得极端一点如果一项任务已经能用规则描述清楚就不要让模型来处理这是控制成本和幻觉的统一答案。/p h34.4 日报漏了关键消息怎么办/h3 p日报做完之后最让人崩溃的不是内容写错而是第二天发现你漏掉了一条重大消息。我一开始遇到这种情况会很焦虑总觉得是自己收集不全。同时解决这件事可以从流程上强制规避。/p p首先要接受一个事实人力和算力有上限任何日报都无法保证覆盖所有信息。但可以压低遗漏概率。方法是在信息源里加入“交叉确认”机制同一个事件如果出现在两个不同来源它就会在去重时保留两条记录同时发出“多源交叉提示”这样你不会孤独只看到一个角度你会看到多个角度的重叠无法漏掉。第三个办法是季度复盘每月回头读一遍当月日报把那些“当时错过、后来才发现重要”的线索重新标记好。这样持续下来你的信息源配置会越来越贴近真实关注圈漏报概率会指数级下降。/p h34.5 把日报沉淀到个人知识库/h3 p一份日报如果看完就算过两周就变成了一团模糊的记忆很难查证。我后来给日报加了归档层用的是最简单的SQLite数据库表结构不复杂条目id、日期、栏目、标题、链接、原始正文摘要、最终发布摘要、人工审核标记。/p precode classlanguage-sqlCREATE TABLE daily_news ( id INTEGER PRIMARY KEY AUTOINCREMENT, report_date TEXT NOT NULL, section TEXT NOT NULL, title TEXT NOT NULL, link TEXT NOT NULL, raw_summary TEXT, final_summary TEXT, status TEXT CHECK(status IN (draft,published,corrected)) ); /code/pre p不要因为“数据库”三个字就觉得门槛高这个表结构已经足够支撑一个中等体量的个人知识库。你可以随时按照日期查询某一天的事项可以按栏目查询“这个月哪些AI编程工具更新了”可以按状态查错。做这个反而不难只需要在日报发布时往数据库写一条记录配合一个定时备份即可。/p p这件事的后效是什么它让日报从“当天的消耗品”变成“持续生长的资料库”。半年后再看那段时期的日报你会发现自己在AI agent、AI编程、本地部署这些话题上的判断哪些是过早下结论哪些是幸运地准确——这就是长期记录最值钱的部分。/p h34.6 日报生成这件事后续还能怎么扩展/h3 p当前面所有流程稳定之后我可以告诉你后续值得做的一件事把日报的输出引回你的项目里。比如在同一张SQLite表中给每条新闻增加“与我当前项目的相关度”字段每天发布前用提示词让模型判断这条消息是会改变我的技术选型、能优化某个已有模块、还是纯粹只是“知道就行”。经过一个月的积累你就可以从数据里看出到底哪些类型的AI动态真的影响到了你的决策。这就是从“看日报”升级成“用日报”。/p p更进一步你可以让AI agent每天早晨把当日日报压缩成一封邮件或一条消息推送到手机上。但前提是你还是需要保留“人工审核”这道防线。自动收集、自动摘要这些都可靠但“判断什么值得看”的最终审批权我建议无论如何都保留在自己手里。这一条经验比任何工具选型都重要。/p