夜雨聆风有一件事挺扎心的。
我之前发普通 AI 日报，阅读量经常在 20、30 左右徘徊。不是说没人看，是真的只有少数人看。
但我发了一篇实操复盘：《我是怎么把一个旅行规划 skill 做扎实的》，阅读到了 210。
这个数字放在大号那里当然不算什么，但对「希卡实验室」这种小实验账号来说，已经足够说明问题了：大家不是不关心 AI，而是不太想再看一篇“今天又发生了什么”。
因为今天发生的事太多了。
OpenAI 有新动作，Anthropic 有新模型，Google 发论文，某个 Agent 框架更新了，某个开源项目突然爆了，某个产品改了定价，某个开发者又做了一个看起来很酷的小工具。
每天都很热闹。
但热闹看完之后，经常只剩下一种感觉：我知道了，然后呢？
所以我最近在反思一件事：如果「希卡实验室」还只是一个泛 AI 日报号，那它大概率会被信息流淹没。因为日报这件事，本质上已经不缺人做了。
真正有价值的，可能不是“帮大家看 AI 新闻”，而是把 AI 变化变成可复用的工具、流程和一线实验记录。
于是我干了一件有点自找麻烦的事：我把 AI 日报做成了一条自动化管线。
内部项目名叫 OpenClaw AI News Hub，直译一下就是 AI 资讯内容中枢。听起来像产品名，但它对我来说更像一个工作台：每天把分散的信息抓回来，整理成结构化材料，再生成日报、深度稿，最后推到不同渠道。
一开始我以为，AI 日报这件事很简单。
找新闻，摘要，排版，发布。
后来我发现，不是。
AI 日报真正麻烦的地方，不是“写一篇文章”，而是每天都要面对同一堆问题：信息从哪里来？重复内容怎么去掉？哪些是真正重要的？哪些只是热闹？同一件事在不同来源里怎么合并？生成内容时怎么减少幻觉？发布失败怎么办？人工改过的正文会不会被自动任务覆盖？
这些问题不解决，日报就会变成一种很脆弱的手工活。
你今天状态好，就整理得细一点；明天事情多，就随便凑一版；后天工具报错，可能直接断更。
这不叫内容系统。
这叫靠意志力续命。
而我对自己的意志力，一向不太信任。
所以我决定把「每天写一篇 AI 日报」改造成「每天跑一条内容生产管线」。
这条管线的目标，不是让 AI 替我写完一切。
恰恰相反。
我真正想要的是：让我能复盘、能恢复、能控制。让 AI 做它擅长的重复劳动，让人保留判断、审核和修改的空间。
换句话说，不是让 AI 替我写，而是让 AI 帮我把“写之前的混乱”变得可控。
01 日报不是文章，而是一个系统
以前我对日报的理解很朴素：每天把重要新闻整理一下，配一点自己的判断，发出去。
这个理解不能说错，但只适合小规模、低频、靠人肉维护的阶段。
一旦你想持续做，问题就来了。
第一，信息源会越来越多。
Twitter List、RSS、TopHub，各有各的价值。Twitter 更像一线信号，RSS 更像正式发布，TopHub 更像热度观察。单看一个源，容易偏；全都看，又容易爆炸。
第二，同一件事会重复出现。
一个模型发布，可能官方博客有一篇，开发者转发一轮，媒体写一轮，中文社区再讨论一轮。如果不做归并，你会以为今天发生了十件事，实际上可能只有两件。
第三，摘要不等于理解。
AI 很擅长把一段内容压缩成几句话，但它不天然知道这件事为什么重要。它可能把噪音写得像大事，也可能把真正值得跟进的信号一笔带过。
第四，发布不是最后一步。
RSS、微信公众号、Web、Obsidian Vault，每个渠道的格式、节奏、用途都不一样。你不能指望一份 Markdown 同时适配所有地方。
所以我开始把日报当成一个系统，而不是一篇文章。
这个系统的目标不是“每天自动写一篇看起来像人的文章”。
说实话，这个目标挺危险的。因为它很容易滑向批量制造平庸内容。
我更在意的是：信息进来之后，每一步发生了什么，我能不能看见；中间某一步错了，我能不能重跑；AI 生成了内容，我能不能审核；我人工改过的正文，会不会被下一次自动任务一把覆盖。
自动化最怕的不是不够自动。
自动化最怕的是看起来很顺，实际上一出错就只能祈祷。
02 我把它拆成了 6 个阶段
OpenClaw AI News Hub 这条管线，目前被拆成 6 个阶段：
Collect → Normalize → Cluster → Structure+Score → Digest → Publish。
翻译成人话，大概是：
先把东西捞回来，再洗干净，再把相似的放一起，再判断重要性，再生成内容，最后发到不同地方。
听起来很正常。
但真正做的时候，每一步都能踩坑。
第一阶段：Collect，先把信息捞回来
Collect 是采集阶段。
它负责从 Twitter List、RSS、TopHub 这些来源里，把原始信息抓回来。
这里有一个很重要的点：我不想让采集阶段就“变聪明”。
它的任务不是判断谁重要，也不是决定哪条该写。它只负责尽量完整、稳定地把原始材料保存下来。
为什么？
因为只要原始材料还在，后面就能重跑。
今天的结构化策略不满意，可以明天换；今天的摘要提示词写得一般，可以重新生成；今天错过了某个判断，也能回头补。
但如果采集阶段就把很多东西过滤掉了，后面再聪明也没用。
所以在这条管线里，采集阶段的结果会进入共享归档目录，保存为 raw-items 之类的结构化文件。
它不追求漂亮，只追求可追溯。
这是我做这条管线后的第一个认知变化：内容生产的第一步，不是写作，是留痕。
第二阶段：Normalize，把乱七八糟的信息洗成统一格式
不同来源的数据格式很烦。
Twitter 有自己的字段，RSS 有自己的字段，TopHub 又是另一套结构。标题、链接、发布时间、来源、正文摘要，每个地方都不一样。
如果后面每一步都要适配这些差异，代码和提示词都会越来越乱。
所以 Normalize 阶段要做的事，就是把不同来源的信息变成统一格式。
这一步听起来像纯技术活，但它对内容质量影响很大。
比如同一条信息，如果链接、来源、发布时间没有处理好，后面就很难去重；如果原始文本和摘要混在一起，模型生成时就容易把“别人评论”当成“事实”。
我以前手工做日报时，经常靠眼睛判断：这两条好像是同一件事，那我合并一下。
但这件事不能每天靠眼睛做。
眼睛会累，脑子会飘，咖啡也不总是有用。
Normalize 的价值，就是把“凭感觉整理”变成“有格式约束的整理”。
它不性感，但很关键。
第三阶段：Cluster，把同一件事聚在一起
Cluster 是聚类阶段。
它要解决的问题是：今天的信息里，哪些其实是在说同一件事？
比如某个 AI 产品发布新功能，官方发了一条，开发者试用后发了一条，媒体又写了一条。它们不是三件事，而是一件事的不同侧面。
如果不聚类，日报就会变成信息堆叠：一条接一条，看起来很丰富，读者却很累。
聚类之后，内容才开始有“事件”的形状。
这也是为什么 OpenClaw 里不只保存 normalized-items，还会生成 events。
item 是一条信息。
event 是一件事。
日报真正要写的，不是一条条 item，而是一组组 event。
这个区别很小，但对内容体验影响很大。
读者不需要知道“今天有 50 条信息”。
读者真正想知道的是：今天有哪些值得关注的变化？这些变化之间有什么关系？哪些值得我后续投入时间？
第四阶段：Structure+Score，让内容有层次，也有优先级
聚类之后，还需要结构化和打分。
Structure+Score 这个阶段做两件事：一是把事件整理成可写作的结构，二是给它一个相对优先级。
我不想把日报做成“所有新闻平等排队”。
因为现实不是这样的。
有些信息只是热闹，有些信息会影响工具选择，有些信息值得做成单独深度稿，有些信息适合放进 Obsidian 作为长期观察素材。
所以结构化阶段会把事件拆成更适合后续使用的形态，比如事实摘要、关键信号、可能影响、适合发布的渠道等。
打分也不是为了制造一个绝对正确的排行榜。
我没那么自信。
它更像一个提醒机制：哪些应该放到日报前面，哪些可以进入深度稿候选，哪些只适合归档。
这一步还有一个特别重要的原则：保护事实句。
尤其是深度稿能力里，我希望它是 citation-first，也就是先有引用、先有来源，再组织表达。对于事实句，要尽量减少模型自由发挥的空间。
AI 写作最容易翻车的地方，不是它不会写，而是它太会写了。
它能把不确定的东西写得很确定，把没发生的逻辑补得很顺，把一句“可能”扩写成一段“趋势”。
读起来很舒服，但很危险。
所以我宁愿让它慢一点、笨一点，也要让事实链条更清楚。
第五阶段：Digest，生成日报和深度稿
到了 Digest 阶段，才是真正意义上的“生成内容”。
但这时的生成，已经不是让模型面对一堆网页然后自由发挥。
它拿到的是前面几步处理过的材料：rawItems、normalized、events、structured 等等。
这听起来有点像工程文档。
但对我来说，它其实是一份“工作契约”。
每天的日报不是凭空出现的，而是从哪批数据、经过哪些阶段、产出了哪些文件，都能追踪。
除了日报，这条管线还支持深度稿。
深度稿不是每天都发，也不应该每天都发。它更适合基于历史归档，生成 2500–3500 字的回顾文章。
比如某个 Agent 框架连续几周都有更新，或者某类 AI 原生应用持续出现新的形态，就可以从归档里拉出材料，做一次更完整的复盘。
但深度稿必须审核。
这一点我会写进流程里，而不是靠自觉。
日报可以更自动一点，深度稿必须更谨慎一点。
因为越是长文，越容易在逻辑链条里夹带模型自己的想象。
第六阶段：Publish，把同一份内容渲染到不同渠道
最后是 Publish。
以前我以为发布就是复制粘贴。
后来发现，发布也是一个系统问题。
Telegram 适合快速推送，微信公众号适合完整阅读，Web 适合作为公开存档，Obsidian Vault 适合我自己长期复盘。
同一份内容，放到不同渠道，目的不一样。
所以 Publish 阶段不只是“发出去”，而是多渠道渲染。
它要考虑格式，要记录 publication jobs，要处理失败重试，还要避免重复发布。
比如一次发布失败后，系统应该知道这次 job 到底是失败了，还是已经成功但回调没拿到。否则重试就可能变成重复发布。
这类问题非常不浪漫。
但它决定了自动化能不能真的跑起来。
很多自动化项目一开始很爽，最后死在边角问题上：发布失败没人知道，重跑覆盖了人工修改，某个阶段出错只能从头再来。
为了避免这种情况，我给每个阶段都设计了独立 CLI 入口，共享归档目录，支持从任意阶段断点续跑。
也就是说，如果 Structure+Score 出问题，不需要重新 Collect；如果 Digest 不满意，可以基于已有 structured-items 重来；如果 Publish 失败，也应该只处理发布任务，而不是把前面的内容全部洗掉。
这条管线对我最大的安慰，不是它自动，而是它可恢复。
03 几个我后来才意识到的关键设计
做这条管线时，有几个设计是我越做越觉得重要的。
第一个是：不用数据库，先用文件系统。
OpenClaw 目前不引入数据库。所有持久化都放在 .data 下面，用 JSON 和 Markdown 保存，包括 raw-items、normalized-items、events、structured-items、daily-digest、publication jobs。
这不是因为数据库不好，而是因为在这个阶段，文件系统更透明。
我可以直接打开看，可以 Git 同步，可以对比变化，也可以把它接进 Obsidian。
对于一个还在快速试验的内容管线来说，透明比高级更重要。
数据库以后当然可能会需要，但不是一开始就需要。
过早引入复杂基础设施，很容易把一个内容实验变成后端工程项目。
我已经踩过类似的坑：本来想做内容，最后三天都在调环境。
那种感觉很熟悉，也很绝望。
第二个是：自动任务不能覆盖人工正文。
这是一个很小但很要命的原则。
Runbook 里我给自动任务设了边界：自动任务只新增 note，或者更新受控 sidecar 字段，不覆盖人工正文。
为什么？
因为内容不是只有生成，还有编辑。
我可能会在 Obsidian 里改一段判断，补一个案例，删掉一句不准确的话。如果自动任务下一次运行时直接覆盖正文，那就等于把人的判断当成临时缓存。
这不行。
AI 可以生成初稿，可以补材料，可以做结构化，但人工正文必须被保护。
否则人就会越来越不敢改，最后变成“反正改了也会被覆盖”。
一个让人不敢介入的自动化系统，迟早会变成黑箱。
而我想要的是相反：它应该让我更愿意介入，因为每次介入都不会白费。
第三个是：Skill 要有边界，不是什么都封装。
因为「希卡实验室」接下来会更多关注 Agent、Skill 与工作流，所以我也在思考：这条 AI 日报管线里，哪些部分适合封装成 skill？
我的判断是：采集归一化、结构化生成、日报生成、深度稿生成、多渠道渲染，都适合。
但实际发布接口、审核流 UI、Web 存档策略，暂时不建议封装。
原因很简单：前者是相对稳定的能力，后者牵涉权限、人工判断、平台变化和长期策略。
Skill 不是把所有东西都塞进去。
Skill 的价值是把边界清楚、可复用、可组合的能力沉淀下来。
边界不清的地方，强行封装只会制造更大的麻烦。
04 最大的变化：我开始能复盘了
这条管线最让我有感的地方，不是它能自动生成日报。
而是它让我开始能复盘。
以前手工做日报，做完就过去了。
今天看了哪些源？哪些被忽略了？为什么选这几条？哪条后来证明重要？哪条其实只是噪音？很难系统回答。
现在不一样。
因为每个阶段都有归档，我可以回头看：原始信息是什么，归一化后变成什么，聚类怎么做，结构化怎么判断，最后日报写成了什么。
这意味着日报不再只是“当天内容”，而会慢慢变成一个可查询、可复盘、可再利用的知识库。
这对「希卡实验室」很重要。
因为我不想只追热点。
热点当然要看，但更重要的是从热点里沉淀模式：什么样的 AI 原生应用开始出现？Agent 的真实边界在哪里？Skill 怎么从一个 prompt 变成可用工具？工作流在哪些地方真的能省时间，哪些地方只是看起来很美？
这些问题，不是靠一篇日报能回答的。
它需要持续记录，也需要可回溯的材料。
所以 OpenClaw AI News Hub 对我来说，不只是一个日报工具。
它更像是「希卡实验室」未来内容生产的底座。
05 所以，AI 日报到底应该是什么？
做完这一轮，我对 AI 日报的理解变了。
它不应该只是“今天 AI 圈发生了什么”。
因为这件事太容易被替代了。
搜索引擎可以告诉你，资讯网站可以告诉你，社群可以告诉你，各种 bot 也可以告诉你。
真正值得做的 AI 日报，应该回答另一个问题：这些变化，对我们做 AI 原生应用、做 Agent、做 Skill、做工作流，有什么启发？
它应该是一个观察入口，而不是信息终点。
它应该连接短期新闻和长期实验。
它应该既能快速告诉我今天有什么，也能在一个月后帮我回看：哪些趋势是真的，哪些只是噪音，哪些东西值得做成工具。
这也是为什么我会把日报做成一条管线。
因为一篇文章只能发布一次。
但一条管线可以每天运行、持续积累、不断调整。
对我来说，AI 工具最理想的状态，不是替我热闹，而是帮我沉淀。
不是替我判断，而是让我更容易判断。
不是替我写完一切，而是让我把想法变成能持续运行的流程。
结尾：希卡实验室接下来想做什么
过去，「希卡实验室」更像一个泛 AI 观察账号。
看到新东西，记录一下；发现好工具，分享一下；遇到有意思的方向，写一写。
这当然还有价值。
但从阅读数据看，大家更愿意看的，是我亲自下场之后的东西：怎么做，哪里卡住，怎么改，什么能复用，什么只是看起来很美。
所以接下来，我想把「希卡实验室」升级成一个更明确的账号：
AI 原生应用、Agent、Skill 与工作流的一线实验记录。
品牌主张也会更清楚：把 AI 想法做成可用工具。
这篇文章讲的 OpenClaw AI News Hub，就是这个方向里的一个实验。
它不完美，也不会一开始就很优雅。
但它至少让我从“每天追着新闻跑”，变成“搭一条可以持续处理新闻的管线”。
如果以后你在「希卡实验室」看到的内容，不再只是“今天 AI 又发生了什么”，而是更多“我把某个想法做成了一个可用工具”，那大概就是这次改版真正开始生效了。
也欢迎你监督我。
毕竟自动化管线能不能跑起来，最后不看名字多酷，也不看架构图多完整。
就看它能不能在第二天、第三天、第十天，还继续稳定地产出有用的东西。
最后也想问你三个问题：
你现在看 AI 日报时，最希望它帮你解决的是“快速知道发生了什么”，还是“判断哪些值得跟进”？
如果把 AI 日报做成工具，你觉得最重要的能力是采集、去重、打分、深度回顾，还是多渠道发布？
你有没有一个每天都在手工重复做、但一直没自动化的内容/工作流程？欢迎留言，我可以挑一个继续做实验复盘。
