1. 从一份日报说起AI 圈的信息密度正在失控每天早上打开订阅列表我都有种被信息洪流拍在沙滩上的感觉。2026 年 9 月 18 日这一天尤其典型——Claude 生态又更新了工具链Agent 框架冒出来三四个新面孔LLM 知识库方案从学术圈一路卷到工程落地Coding 相关的热词里甚至混进了“笔试”“代码质量下降”这种带着焦虑感的讨论。做一份 AI 日报表面上是信息聚合实际上是在做一件更难的事从噪声里捞出信号再把信号翻译成能用的东西。这份日报的核心价值不在于“今天发生了什么”而在于“今天发生的事对你手上的项目意味着什么”。我做了三年多的 AI 领域内容跟踪踩过最大的坑就是早期只会罗列新闻标题读者看完等于没看。后来我调整了思路把日报当成一个决策辅助工具来设计每条信息都要回答三个问题——它属于哪个技术栈层级、它解决了什么具体痛点、它和我正在做的事有没有交集。这套方法论支撑了我从纯手工整理到半自动化流水线的整个演进过程。这篇文章我会把这份日报背后的完整工作流拆开讲。包括信息源的筛选逻辑、Agent 辅助抓取和摘要的实现细节、LLM 知识库的搭建方式、Claude Code 这类工具在流程里的实际定位以及我踩过的那些坑。适合正在做技术内容运营、想搭建个人知识管理系统、或者单纯想搞清楚 AI 工具链怎么组合使用的朋友。不需要你是算法工程师但需要对命令行和基础配置有点耐心。2. 日报的整体设计思路为什么不做“大而全”2.1 信息源分层三层过滤模型最开始我做日报的时候恨不得把全网 AI 新闻都塞进去结果就是每天产出上万字自己都不想看第二遍。后来我总结出一个三层过滤模型一直用到现在。第一层是核心源大概 8 到 12 个包括官方博客、GitHub Trending、几个高质量的技术社区。这些源的特点是信噪比高但更新频率不稳定。第二层是补充源主要是社交媒体上的技术讨论和热词榜单用来捕捉“圈子里正在聊什么”但需要人工判断价值。第三层是触发源比如某个关键词突然在多个渠道同时出现这时候才去深挖。这个分层的关键在于不同层级的源用不同的处理策略。核心源全量抓取补充源只抓热度和关键词触发源按需检索。这样既不会漏掉重要信息也不会被垃圾内容淹没。提示信息源的数量不是越多越好。我实测下来核心源超过 15 个之后边际收益急剧下降反而增加了筛选成本。2.2 为什么选择 Agent 辅助而不是纯脚本很多人第一反应是写个爬虫加正则匹配就完事了。我早期也这么干过但很快发现两个问题。第一AI 领域的新概念层出不穷正则规则永远追不上新词的出现速度。第二很多信息的价值判断需要语义理解比如“某个框架发布了新版本”和“某个框架修复了一个不影响使用的 bug”脚本没法区分重要性。所以我转向了Agent 辅助的工作流。具体来说用一个轻量的 Agent 负责三件事抓取原始内容、做初步的语义分类、生成结构化摘要。这里的关键设计是Agent 只做它擅长的事——语义理解和信息提取不做最终的价值判断。价值判断还是留给人来做因为日报的“品味”是核心竞争力这个没法外包给模型。2.3 日报的四个固定板块设计经过多次迭代我把日报固定成四个板块每个板块有明确的定位和产出标准。板块定位内容来源产出标准工具链动态追踪可直接使用的工具更新官方博客、GitHub Release必须包含版本号和变更要点技术概念解析解释新出现的术语和框架热词榜单、社区讨论必须给出类比和适用场景实操技巧分享可复现的操作方法个人实践、社区问答必须包含完整步骤和避坑点行业观察分析趋势和影响多源交叉验证必须区分事实和观点这个表格看起来简单但它解决了一个大问题每类信息的处理方式不同混在一起就会互相干扰。工具链动态需要精确概念解析需要通俗实操技巧需要详细行业观察需要克制。分开处理之后每个板块的质量都上了一个台阶。3. 核心工具链拆解从抓取到成稿的完整链路3.1 抓取层RSS 加 API 加人工触发抓取层我用的是一套组合方案没有追求全自动化因为完全自动化的代价是质量不可控。RSS 负责核心源的更新监控。我用的是一个自建的 RSS 聚合服务把十几个源统一到一个接口每 30 分钟轮询一次。这里有个细节轮询频率不要设太高很多源有反爬机制频率过高会被限流。30 分钟是我实测下来比较稳的间隔。API 负责补充源的数据获取。热词榜单类的服务通常有开放接口直接调用比爬页面稳定得多。这里要注意的是接口的返回格式可能随时变化所以我在代码里加了字段校验一旦发现结构不对就报警而不是静默失败。人工触发是最后一道保险。有些重要信息不在任何订阅源里比如某个朋友在群里分享的链接或者某个会议上的口头发布。这部分我留了一个快速录入的入口手动粘贴内容后走同样的处理流程。# 简化的抓取调度逻辑 import schedule import time def fetch_core_sources(): 核心源全量抓取每30分钟一次 for source in CORE_SOURCES: try: content fetch_rss(source) validate_and_store(content, source) except Exception as e: alert(f核心源抓取失败: {source}, 错误: {e}) def fetch_supplementary(): 补充源只抓热度和关键词每小时一次 hot_words fetch_hot_words() filtered filter_by_keywords(hot_words, KEYWORD_LIST) store_hot_words(filtered) schedule.every(30).minutes.do(fetch_core_sources) schedule.every(60).minutes.do(fetch_supplementary) while True: schedule.run_pending() time.sleep(60)这段代码的核心逻辑是分级调度。核心源频率高、全量抓补充源频率低、只抓关键词。这样既保证了重要信息不遗漏又控制了资源消耗。3.2 处理层Agent 做语义分类和摘要抓取到的原始内容是一堆混杂的文本直接扔给读者肯定不行。处理层的任务是把这些内容变成结构化的条目。我用的 Agent 配置大概是这样的给它一个明确的分类体系就是前面说的四个板块让它对每条内容做分类然后生成一段 100 到 200 字的摘要。这里的关键是提示词的设计。我试过很多版本最后稳定下来的提示词有几个要点。第一明确告诉 Agent不要做价值判断只做信息提取。比如不要说“这个更新很重要”而是说“这个更新修改了 X 功能影响 Y 场景”。第二要求 Agent保留原始链接和关键数据方便后续核实。第三要求输出格式固定方便程序解析。注意Agent 生成的摘要一定要人工过一遍。我遇到过好几次 Agent 把“修复了一个拼写错误”总结成“重要更新”的情况这种错误如果直接发出去会很尴尬。3.3 成稿层模板加人工润色成稿层我用的是一套 Markdown 模板每个板块有固定的结构。Agent 处理完的内容填入模板后我再做一轮人工润色。润色的重点不是改文字而是调整信息的排列顺序和详略。比如同一天有三条工具更新哪条放前面、哪条展开讲、哪条一笔带过这个判断需要人来定。这里分享一个技巧给每条内容打一个“行动价值”分。分数高的展开写分数低的只留一句话。行动价值的判断标准是读者看完之后能不能立刻做点什么。能立刻上手的排前面纯资讯类的排后面。4. 关键技术点深挖LLM 知识库与 Claude Code 的实战定位4.1 LLM 知识库让日报有“记忆”日报做久了会遇到一个问题同样的概念反复出现每次都要重新解释。比如 Agent 这个词从 2024 年火到现在每次有新读者进来都要从头讲一遍。这时候就需要一个知识库来沉淀这些基础概念。我搭的 LLM 知识库方案比较轻量核心思路是用向量检索加结构化标签。每个概念存一条记录包含定义、类比、适用场景、相关链接。当日报里出现某个概念时自动关联知识库里的条目生成一个“延伸阅读”的链接。具体实现上我用的是一个本地向量库加一个简单的检索接口。概念的定义用 LLM 生成初稿人工审核后入库。这里的关键是标签体系的设计。我用的标签包括技术层级框架/工具/概念、成熟度实验/稳定/主流、关联领域Coding/Agent/知识管理。这样检索的时候可以按多个维度过滤。# 知识库条目结构示例 knowledge_entry { term: Agent, definition: 能够自主感知环境并采取行动以达成目标的系统, analogy: 像一个能自己看地图、自己决定路线的司机而不是只会按固定路线开的公交, scenarios: [自动化工作流, 多步骤任务处理, 需要动态决策的场景], maturity: 主流, domain: [Agent, 自动化], related_links: [...] }这个知识库的价值在于降低日报的重复解释成本。新概念第一次出现时详细讲后续出现时只给链接读者想深入了解就点进去看。4.2 Claude Code 在流程里的实际角色Claude Code 这类工具在我的工作流里主要承担两个角色。第一个是代码片段的生成和验证。日报里经常需要贴一些配置示例或脚本片段我会用 Claude Code 先生成初稿然后自己跑一遍确认能跑通。第二个是批量文本处理。比如把十几条原始信息统一格式化成结构化数据这种重复性工作交给它效率很高。安装和配置方面我是在 Ubuntu 环境下用的整体流程比较直接。需要注意的是工作目录的权限设置如果目录权限不对会出现读写失败的情况。另外如果你在 Windows 上用可能会遇到虚拟化平台相关的提示这个按照官方文档开启对应功能就行。提示Claude Code 生成的代码一定要自己跑一遍。我遇到过生成的脚本在特定 Python 版本下报错的情况原因是用了新版本的语法特性。4.3 Agent 框架选型的几个考量现在 Agent 框架很多选哪个是个问题。我的判断标准有三个上手成本、可观测性、社区活跃度。上手成本指的是从零到跑通第一个 demo 需要多长时间。有些框架概念很多文档又写得晦涩光理解概念就要花好几天。可观测性指的是出问题的时候能不能快速定位。Agent 的执行链路通常比较长如果中间某一步出错没有日志的话很难排查。社区活跃度指的是遇到问题能不能找到人问以及框架本身是不是在持续更新。我目前主要用的是轻量级的方案因为日报这个场景不需要太复杂的 Agent 能力。杀鸡不用牛刀选一个能快速迭代、容易调试的框架就够了。如果你要做更复杂的多 Agent 协作那可能需要考虑更重的框架但那是另一个话题了。5. 实操过程全记录从零搭建一份日报的完整步骤5.1 环境准备与依赖安装先说环境。我用的是 Ubuntu 22.04Python 3.11。这个组合比较稳大部分工具链都支持。如果你用 macOS 或者 Windows大部分步骤是一样的个别命令需要调整。依赖安装分三块。第一块是抓取相关的主要是 requests 和 feedparser。第二块是处理相关的包括向量库客户端和 LLM 的 SDK。第三块是调度相关的我用的是 schedule 这个轻量库够用了。# 创建虚拟环境 python3 -m venv ai-daily-env source ai-daily-env/bin/activate # 安装核心依赖 pip install requests feedparser schedule pip install openai anthropic # 根据你用的模型服务选择 pip install chromadb # 向量库用于知识库这里有个坑要注意不同 LLM 服务商的 SDK 可能有依赖冲突。我建议一个项目里只用一家或者用虚拟环境隔离。我早期同时装了两家的 SDK结果版本冲突排查了半天。5.2 信息源配置与抓取脚本编写信息源配置我放在一个 YAML 文件里方便修改。每个源包含名称、URL、类型、抓取频率这几个字段。# sources.yaml core_sources: - name: 官方博客A url: https://example.com/feed type: rss interval: 30 - name: 代码托管平台趋势 url: https://example.com/api/trending type: api interval: 60 supplementary_sources: - name: 热词榜单 url: https://example.com/api/hotwords type: api interval: 60抓取脚本的核心逻辑前面已经给过了这里补充一个去重机制。同一个内容可能从多个源抓到或者同一个源重复推送。我的做法是用内容的哈希值做去重存一个最近 7 天的哈希集合抓到时先查重。import hashlib def get_content_hash(content): 生成内容哈希用于去重 return hashlib.md5(content.encode(utf-8)).hexdigest() def is_duplicate(content_hash, seen_hashes): 检查是否重复seen_hashes 是最近7天的哈希集合 return content_hash in seen_hashes去重这个环节看起来简单但不做的话日报里会出现大量重复内容读者体验很差。我早期就吃过这个亏同一篇官方博客因为 RSS 和 API 都抓到了在日报里出现了两次。5.3 Agent 处理流程的配置细节Agent 处理这块提示词是核心。我用的提示词模板大概长这样你是一个技术内容处理助手。请对以下内容进行处理 1. 判断它属于哪个板块工具链动态 / 技术概念解析 / 实操技巧 / 行业观察 2. 生成一段 100-200 字的摘要要求 - 保留关键数据和版本号 - 不做价值判断只陈述事实 - 如果涉及操作保留关键步骤 3. 提取 3-5 个关键词 4. 输出格式为 JSON 原始内容 {content}这个提示词的关键在于约束足够明确。我试过比较宽松的提示词结果 Agent 经常自由发挥生成的内容格式不统一后续处理很麻烦。加上明确的格式要求和字数限制之后输出稳定多了。处理流程还有一个细节批量处理而不是逐条处理。逐条调用 API 的话网络延迟会累积处理 50 条内容可能要十几分钟。批量处理可以把多条内容打包成一个请求效率高很多。但要注意单次请求的内容长度限制太长了会被截断。5.4 成稿与发布环节的自动化成稿环节我用的是模板加数据填充的方式。模板是 Markdown 格式每个板块有固定的结构。数据填充就是把 Agent 处理好的内容按板块塞进去。def generate_daily_report(processed_items, date): 生成日报 Markdown report f# AI 日报 {date}\n\n for section in [工具链动态, 技术概念解析, 实操技巧, 行业观察]: items [i for i in processed_items if i[section] section] if not items: continue report f## {section}\n\n for item in sorted(items, keylambda x: x[action_value], reverseTrue): report f### {item[title]}\n\n report f{item[summary]}\n\n report f[原文链接]({item[link]})\n\n return report发布环节我保留了人工审核这一步。自动化可以做到 90%但最后 10% 必须人工过。主要检查三件事有没有事实错误、有没有敏感内容、排版有没有问题。这三件事任何一件出问题都会影响日报的可信度。6. 常见问题与排查技巧实录6.1 抓取失败的各种姿势抓取失败是最常见的问题原因五花八门。我整理了一个排查表按出现频率排序。问题现象可能原因排查方法解决方案返回 403被反爬拦截检查请求头加 User-Agent降低频率返回空内容页面结构变化对比历史返回更新解析规则超时网络问题或源站慢测试直接访问增加超时时间加重试编码乱码字符集不匹配检查响应头指定编码格式内容重复多源抓取同一内容检查哈希去重完善去重逻辑这里重点说两个。403 错误通常是因为请求头太“裸”了加上正常的 User-Agent 和 Referer 一般能解决。如果还不行就降低抓取频率有些源对频率很敏感。编码乱码是个经典问题特别是中文内容有时候响应头声明的编码和实际编码不一致需要手动指定。注意不要用太激进的抓取策略。我见过有人为了“实时”把轮询间隔设成 1 分钟结果 IP 被封了得不偿失。6.2 Agent 输出不稳定的处理Agent 输出不稳定是另一个高频问题。表现包括格式不对、内容跑偏、摘要太长或太短。我的处理经验是从提示词和输入两个方向排查。提示词方面检查约束是否明确。比如“生成摘要”这个指令太模糊要改成“生成 100 到 200 字的摘要保留版本号和关键数据”。输入方面检查原始内容是否太长或太乱。太长的内容可以先截断或分段太乱的内容可以先做一轮清洗。还有一个技巧是给 Agent 几个示例。在提示词里放一两个输入输出的例子Agent 的输出会稳定很多。这个叫 few-shot prompting实测效果很明显。6.3 知识库检索不准的优化知识库检索不准通常有两个原因向量模型不适合中文或者标签体系设计不合理。向量模型方面如果用的是默认的英文模型中文检索效果会很差。需要换成支持中文的模型或者用多语言模型。标签体系方面如果标签太细检索时匹配不上如果标签太粗检索结果太泛。我的经验是标签控制在 3 到 5 个维度每个维度 5 到 10 个值这样既有区分度又不会太碎。另外定期清理知识库也很重要。有些概念过时了或者定义需要更新不及时清理会影响检索质量。我一般每个月过一遍把过时的标记出来需要更新的重新生成定义。6.4 日报质量波动的应对日报质量波动是内容运营的常见问题。有时候信息多日报很充实有时候信息少日报很水。我的应对策略是建立内容储备池。平时看到好的内容即使当天不用也存进储备池。信息少的时候从储备池里捞保证日报的基本质量。储备池的内容要有保质期太旧的内容就不适合再用了。我一般设 7 天超过 7 天的自动清理。还有一个策略是调整板块权重。信息少的时候可以多写一点概念解析或实操技巧这些内容不太依赖当天的新闻。信息多的时候重点放在工具链动态和行业观察上。7. 一些踩坑之后的个人体会做日报这件事技术实现只是一部分更重要的是对信息的判断力。我早期太依赖自动化觉得把流程跑通就万事大吉了结果产出的日报自己都不想看。后来才明白自动化解决的是效率问题解决不了品味问题。哪些信息值得展开、哪些一笔带过、哪些干脆不放这些判断需要人来定。另一个体会是不要追求大而全。AI 领域每天的新信息太多了想全部覆盖是不可能的。与其做一份什么都有的日报不如做一份有明确取舍的日报。我的取舍标准是只放对读者有行动价值的内容。看完能立刻做点什么的放看完只是“哦知道了”的不放。最后分享一个小技巧给日报加一个“一句话总结”。每天日报的开头放一句话概括当天最重要的信息。这句话看起来简单但写起来很考验判断力。写多了之后你会发现自己对信息的敏感度明显提升。这个习惯我坚持了半年多受益很大。至于后续的扩展方向我目前在尝试的是把日报和知识库打通。日报里出现的新概念自动关联知识库知识库的更新也反过来影响日报的内容选择。这个闭环还在打磨中等跑顺了再单独写一篇分享。