我已经有一段时间不主动刷 X 的信息流了。
真正的问题不是里面没东西看。恰恰相反，是有价值的信息太多，噪音也多。
本来只想看看有什么新东西，半小时后却只记住了几个不感兴趣的热点，真正和工作、业务有关的内容一条都没留下。
所以我把“刷 X”变了一种玩法，做成了一条持续运转的信息消化环。
它每天跑四轮。我给三类来源的权重是：60% For You、25% Following、15% 主动搜索。
抓到内容以后，它不会立刻让 AI 总结，而是先检查来源是否健康、数据是否新鲜。流程异常就明确报告失败，不拿旧数据冒充“今天没有重要信息”。
然后才进入去重、相关性筛选、证据核验和语义审查。
在一轮匿名化的真实运行里，多个来源共出现 142 次，去重后剩下 80 条不同内容；23 条通过机器初筛，12 条进入语义审查，最后只有 3 条被标为“值得知道”，其中 1 条获得“正式晋升”。
142 次来源命中 → 80 条不同内容 → 23 条初筛 → 12 条语义审查 → 3 条值得知道 → 1 条正式晋升。
这个漏斗真正帮我解决的，不是“筛得有多狠”，而是把以前混在一起的两个问题拆开了：
哪些内容值得我知道？
哪些内容值得改变系统状态？
认知层是“值得知道”：每轮 0–3 条。系统必须告诉我它为什么重要、证据核验到了哪一步、哪些只是作者自述或推断，以及可以从业务、产品、研究或工作流哪个角度利用。
系统层是“正式晋升”：每轮最多 1 条。只有当它有足够证据、相对已有记忆确实有增量、能找到明确的消费者，并留下可核验回执，才会进入知识、观察、行动或内容系统。
另外两条没有消失，但也不会因为“看起来有趣”，就自动变成两个任务或两份待办。
现在一条信息可以有五种去向：丢弃、观察、学习、行动、内容。
只有拿到真实的知识写回、任务路由或内容队列回执，系统才会承认它真的进入了下一环。AI 说一句“已处理”，不算完成。
目前，四轮报告会固定进入我每天打开的 Codex App。
我后来发现，这类工具可能不应该先做成另一个需要打开的 App。因为我真正使用这些信息的地方，本来就是 Codex、Cursor 这类 AI 客户端。
所以我又做了一个本机 MCP alpha，一共 6 个工具：
• 5 个只读工具：新鲜度检查、最新摘要、日期摘要、有限搜索、证据读取
• 1 个写工具：只允许显式确认后记录真实反馈
这个 MCP 不负责采集 X，也不复制新的账本、队列或定时器。它只是一个很窄的 AI 客户端入口。
目前 Codex 已经真实识别这个本机服务；Cursor 的配置和路径已经校验，原生客户端加载还在做最终核验。
更底层的内核也不绑定任何模型。来源健康、去重、排序、上限和回执由确定性程序负责；Codex、Claude、Cursor、本地模型甚至纯规则程序，只要遵守同一协议，都可以负责中间的语义判断。
我现在觉得，这类 AI 信息工具真正缺的不是总结速度，而是四件事：
1. 先判断来源是否健康，再谈智能。
2. 允许零输出，不为了证明有用而强行制造结论。
3. 把“知道”和“改变状态”分开。有些消息知道就够了，不值得创建任务。
4. 每一步都留下回执。没有真实写回，就没有闭环。
这版目前还是本地优先的 alpha。我不急着把它做成 SaaS，下一步先找几位非作者测试三个问题：
1. 能不能快速跑出第一份摘要？
2. 不同人的个性化结果能不能持续有用？
3. 它是否真的减少了主动刷信息流的时间？
如果你也想在自己的 AI 客户端里试这种信息消化器，评论区留一句“想试”。我会根据第一批真实反馈，再决定要不要把它整理成公开工具或开源项目。
真正的问题不是里面没东西看。恰恰相反，是有价值的信息太多，噪音也多。
本来只想看看有什么新东西，半小时后却只记住了几个不感兴趣的热点，真正和工作、业务有关的内容一条都没留下。
所以我把“刷 X”变了一种玩法，做成了一条持续运转的信息消化环。
它每天跑四轮。我给三类来源的权重是：60% For You、25% Following、15% 主动搜索。
抓到内容以后，它不会立刻让 AI 总结，而是先检查来源是否健康、数据是否新鲜。流程异常就明确报告失败，不拿旧数据冒充“今天没有重要信息”。
然后才进入去重、相关性筛选、证据核验和语义审查。
在一轮匿名化的真实运行里，多个来源共出现 142 次，去重后剩下 80 条不同内容；23 条通过机器初筛，12 条进入语义审查，最后只有 3 条被标为“值得知道”，其中 1 条获得“正式晋升”。
142 次来源命中 → 80 条不同内容 → 23 条初筛 → 12 条语义审查 → 3 条值得知道 → 1 条正式晋升。
这个漏斗真正帮我解决的，不是“筛得有多狠”，而是把以前混在一起的两个问题拆开了：
哪些内容值得我知道？
哪些内容值得改变系统状态？
认知层是“值得知道”：每轮 0–3 条。系统必须告诉我它为什么重要、证据核验到了哪一步、哪些只是作者自述或推断，以及可以从业务、产品、研究或工作流哪个角度利用。
系统层是“正式晋升”：每轮最多 1 条。只有当它有足够证据、相对已有记忆确实有增量、能找到明确的消费者，并留下可核验回执，才会进入知识、观察、行动或内容系统。
另外两条没有消失，但也不会因为“看起来有趣”，就自动变成两个任务或两份待办。
现在一条信息可以有五种去向：丢弃、观察、学习、行动、内容。
只有拿到真实的知识写回、任务路由或内容队列回执，系统才会承认它真的进入了下一环。AI 说一句“已处理”，不算完成。
目前，四轮报告会固定进入我每天打开的 Codex App。
我后来发现，这类工具可能不应该先做成另一个需要打开的 App。因为我真正使用这些信息的地方，本来就是 Codex、Cursor 这类 AI 客户端。
所以我又做了一个本机 MCP alpha，一共 6 个工具：
• 5 个只读工具：新鲜度检查、最新摘要、日期摘要、有限搜索、证据读取
• 1 个写工具：只允许显式确认后记录真实反馈
这个 MCP 不负责采集 X，也不复制新的账本、队列或定时器。它只是一个很窄的 AI 客户端入口。
目前 Codex 已经真实识别这个本机服务；Cursor 的配置和路径已经校验，原生客户端加载还在做最终核验。
更底层的内核也不绑定任何模型。来源健康、去重、排序、上限和回执由确定性程序负责；Codex、Claude、Cursor、本地模型甚至纯规则程序，只要遵守同一协议，都可以负责中间的语义判断。
我现在觉得，这类 AI 信息工具真正缺的不是总结速度，而是四件事：
1. 先判断来源是否健康，再谈智能。
2. 允许零输出，不为了证明有用而强行制造结论。
3. 把“知道”和“改变状态”分开。有些消息知道就够了，不值得创建任务。
4. 每一步都留下回执。没有真实写回，就没有闭环。
这版目前还是本地优先的 alpha。我不急着把它做成 SaaS，下一步先找几位非作者测试三个问题：
1. 能不能快速跑出第一份摘要？
2. 不同人的个性化结果能不能持续有用？
3. 它是否真的减少了主动刷信息流的时间？
如果你也想在自己的 AI 客户端里试这种信息消化器，评论区留一句“想试”。我会根据第一批真实反馈，再决定要不要把它整理成公开工具或开源项目。