即刻App年轻人的同好社区
下载
和这个有一点点相关性的另外一个分享：我们有大量的实践是要把 Agent 和我们的飞书 IM 结合起来，让 Agent 能够在飞书里面工作。
目前我用的是一个叫做 CC-Connect 的框架。它大概会把每一个和 bot 的单聊或群聊，封装成一个连续的会话（当然它也可以有其他的配置，只是我采取了这种方式）。
运转起来挺好用的，但之前有一个问题我一直属于比较搁置的状态：我不只会在飞书里面使用 Agent，还会在桌面端或网页端使用 Agent。它有时候需要往飞书里面发一些消息，但如果有人回应了这条消息，发出消息的 Agent 是不会知道的。因为那些消息和会话是通过 CC-Connect 直接打到了原先单聊或群聊所属的会话中。
事实上，那个会话中的 Agent 可能完全不知道用户在回应什么；如果用户没有引用那条消息，它甚至完全不会出现在该会话的历史记录里。
之前是怎么解决这个问题的呢？
我的想法是约束处在 CC-Connect 框架下的那些会话，让它知道用户的某些答复针对的可能并不是由它发出的消息。如果它看到奇怪或者意义不明的答复，就会重新去爬一下飞书消息，把会话任务接续下来。
之前一直都是这么做的。但当我开始尝试让 Agent 在更长时间内运行、以目标而非任务去交付的时候，任务就不能由另外的会话去接手了，它必须自己亲自接手。
通过不定时唤起 AI，当然能在一定程度上解决这个问题（每次唤起后去查一下有没有新消息就行），但这不适合一些需要非常即时通讯的任务，比如我的 Agent 需要某个同事去接收一个验证码。
我现在实现的一种方式，是让 AI 写一个脚本去监控指定的单聊和群聊。一旦有新消息，就唤醒自己这个会话继续完成任务。这样就能让它发出去的消息，在自己的会话中接续起来。
Claude Code 和 CodeX 实现这个任务是很简单的。我惊喜的是，没想到 Grok Bot 也有这样的方式。Grok Bot 官方支持两种方式来唤起会话：
1. 在它的云主机上去实现一个脚本，当这个脚本停止运行的时候，就唤醒对应的 bot
2. Grok Bot 支持通过 Webhook 的方式去制定一个定时任务，这个定时任务也可以唤起指定的 bot
实际上有一种更加优雅且通用的实现方式，就是借鉴 DeepSeek Super-agent 的理念：把我给各种派发的所有任务，以及在飞书里发送的所有任务，都由一个会话统一路由，再分发到不同的会话中。但这必须要让一个固定的会话来承担所有路由的职责：
卸掉这个 CC Connect 框架，自己实现一个，用一个会话来高频路由所有的单聊和群聊消息，然后无论是按规则分流还是智能识别，再分发到不同的会话。它可以在接近 CC Connect 体验的情况下，把刚才说的这类问题也很好地满足和实现。
但我现在暂时没法去用它，一个很尴尬的点在于：
这套框架意味着负责路由的会话不仅要掌握所有飞书消息，还要掌握所有会话在做什么，才能正确地将某个消息路由到对应会话或新建一个会话。而这个负责路由的会话，我几乎只能用 Claude 来执行（或维护），因为其他模型可能不具备这样的智能。
但我很不方便的是，不能让 Claude 知道我在解决它封号的那些对话历史，单独屏蔽它们又比较麻烦，所以我一直没有往这个方向尝试。
这个架构为什么说优雅又通用？因为它不只能解决这一个问题，还能解决其他我之前面临的问题。
比如说授权的问题：我的飞书 Bot 是开放给公司全员使用的，他们都可以通过这个 Bot 和 CC-Connect 的框架，使用我本地的 Agent 以及我封装好的配置和记忆。
但有些时候存在一些授权问题：同事在做一件事情时需要我的授权，或者bot不知道该如何去做，需要请求我的帮助。这时如果某个同事在他与 Bot 的单聊中说了一件事，Bot 就会给我发出一个权限请求。
在CC-Connect 默认设计下，我即便同意了这个权限请求也是没有意义的。因为那个消息是通过 API 打进来的，并不出现在我跟 Bot 单聊的会话历史中；我回复了这条消息，我所在的那个会话也不知道该如何响应和处理。
后来我实现了一套机制：当出现类似情况时，另外那个向我发出请求的会话需要带上一个 permit ID。我回复这条消息后，我所在的会话会去查询这个 permit ID，这样才能找到最初是从哪里发起的请求，进而去唤醒那个会话。
被唤醒的会话会亲自来核验我的答复是否同意，确认后再去回复向它发出请求的同事。
类似这样的一些手段，在用一个统一的会话来路由所有请求的情况下，都可以通用性地解决。
目前我用的是一个叫做 CC-Connect 的框架。它大概会把每一个和 bot 的单聊或群聊，封装成一个连续的会话（当然它也可以有其他的配置，只是我采取了这种方式）。
运转起来挺好用的，但之前有一个问题我一直属于比较搁置的状态：我不只会在飞书里面使用 Agent，还会在桌面端或网页端使用 Agent。它有时候需要往飞书里面发一些消息，但如果有人回应了这条消息，发出消息的 Agent 是不会知道的。因为那些消息和会话是通过 CC-Connect 直接打到了原先单聊或群聊所属的会话中。
事实上，那个会话中的 Agent 可能完全不知道用户在回应什么；如果用户没有引用那条消息，它甚至完全不会出现在该会话的历史记录里。
之前是怎么解决这个问题的呢？
我的想法是约束处在 CC-Connect 框架下的那些会话，让它知道用户的某些答复针对的可能并不是由它发出的消息。如果它看到奇怪或者意义不明的答复，就会重新去爬一下飞书消息，把会话任务接续下来。
之前一直都是这么做的。但当我开始尝试让 Agent 在更长时间内运行、以目标而非任务去交付的时候，任务就不能由另外的会话去接手了，它必须自己亲自接手。
通过不定时唤起 AI，当然能在一定程度上解决这个问题（每次唤起后去查一下有没有新消息就行），但这不适合一些需要非常即时通讯的任务，比如我的 Agent 需要某个同事去接收一个验证码。
我现在实现的一种方式，是让 AI 写一个脚本去监控指定的单聊和群聊。一旦有新消息，就唤醒自己这个会话继续完成任务。这样就能让它发出去的消息，在自己的会话中接续起来。
Claude Code 和 CodeX 实现这个任务是很简单的。我惊喜的是，没想到 Grok Bot 也有这样的方式。Grok Bot 官方支持两种方式来唤起会话：
1. 在它的云主机上去实现一个脚本，当这个脚本停止运行的时候，就唤醒对应的 bot
2. Grok Bot 支持通过 Webhook 的方式去制定一个定时任务，这个定时任务也可以唤起指定的 bot
实际上有一种更加优雅且通用的实现方式，就是借鉴 DeepSeek Super-agent 的理念：把我给各种派发的所有任务，以及在飞书里发送的所有任务，都由一个会话统一路由，再分发到不同的会话中。但这必须要让一个固定的会话来承担所有路由的职责：
卸掉这个 CC Connect 框架，自己实现一个，用一个会话来高频路由所有的单聊和群聊消息，然后无论是按规则分流还是智能识别，再分发到不同的会话。它可以在接近 CC Connect 体验的情况下，把刚才说的这类问题也很好地满足和实现。
但我现在暂时没法去用它，一个很尴尬的点在于：
这套框架意味着负责路由的会话不仅要掌握所有飞书消息，还要掌握所有会话在做什么，才能正确地将某个消息路由到对应会话或新建一个会话。而这个负责路由的会话，我几乎只能用 Claude 来执行（或维护），因为其他模型可能不具备这样的智能。
但我很不方便的是，不能让 Claude 知道我在解决它封号的那些对话历史，单独屏蔽它们又比较麻烦，所以我一直没有往这个方向尝试。
这个架构为什么说优雅又通用？因为它不只能解决这一个问题，还能解决其他我之前面临的问题。
比如说授权的问题：我的飞书 Bot 是开放给公司全员使用的，他们都可以通过这个 Bot 和 CC-Connect 的框架，使用我本地的 Agent 以及我封装好的配置和记忆。
但有些时候存在一些授权问题：同事在做一件事情时需要我的授权，或者bot不知道该如何去做，需要请求我的帮助。这时如果某个同事在他与 Bot 的单聊中说了一件事，Bot 就会给我发出一个权限请求。
在CC-Connect 默认设计下，我即便同意了这个权限请求也是没有意义的。因为那个消息是通过 API 打进来的，并不出现在我跟 Bot 单聊的会话历史中；我回复了这条消息，我所在的那个会话也不知道该如何响应和处理。
后来我实现了一套机制：当出现类似情况时，另外那个向我发出请求的会话需要带上一个 permit ID。我回复这条消息后，我所在的会话会去查询这个 permit ID，这样才能找到最初是从哪里发起的请求，进而去唤醒那个会话。
被唤醒的会话会亲自来核验我的答复是否同意，确认后再去回复向它发出请求的同事。
类似这样的一些手段，在用一个统一的会话来路由所有请求的情况下，都可以通用性地解决。
许涵之: 我发现要时刻更激进地让 AI 帮助自己。从 AI 教导我完成任务、AI 辅助我完成任务、AI 替代我完成任务，再到给它目标而非任务，我现在正在最后这一个环节上思考。 前面三次都还是任务制，这次我把它换成目标制。最大的不同来自于一个想法：如果让 AI 去跟进一个目标，这个目标的周期可能不是几个小时或者一两天，而是数周的级别。怎样让它可以在数周内持续跟进这个任务呢？用定时任务有点太机械了。所以我想到了一个方法：用不定时的任务。 让 AI 做完当前能做的事情之后，给自己定一个一次性的定时任务来唤起自己。唤起之后，AI 再看可以继续做什么；做完之后，再定下一个一次性的定时任务，选一个它自己想醒来的最佳时机。可能是半小时之后，也可能是 5 天之后，完全基于这个任务所依赖的事项什么时候可以继续进行，以此让它持续去跟进。 我最近开始做一些这样的实践。比如法务合规上的事情，我已经开始让它完全自主地去做，有需要帮助和确认的时候再来找我，有任何进展也让它自己往群里同步，包括生活上的一些事情也是如此。 我觉得之前的思维模式在新的模型能力和范式下，开始往这个方向转变了：之前我还是会说我有一些想法、一些目标，你帮我把其中一些重要的部分完成；但现在我会直接把目标给它，甚至很多时候都不会多交代什么，让它自己去思考。
3 10
我发现要时刻更激进地让 AI 帮助自己。从 AI 教导我完成任务、AI 辅助我完成任务、AI 替代我完成任务，再到给它目标而非任务，我现在正在最后这一个环节上思考。
前面三次都还是任务制，这次我把它换成目标制。最大的不同来自于一个想法：如果让 AI 去跟进一个目标，这个目标的周期可能不是几个小时或者一两天，而是数周的级别。怎样让它可以在数周内持续跟进这个任务呢？用定时任务有点太机械了。所以我想到了一个方法：用不定时的任务。
让 AI 做完当前能做的事情之后，给自己定一个一次性的定时任务来唤起自己。唤起之后，AI 再看可以继续做什么；做完之后，再定下一个一次性的定时任务，选一个它自己想醒来的最佳时机。可能是半小时之后，也可能是 5 天之后，完全基于这个任务所依赖的事项什么时候可以继续进行，以此让它持续去跟进。
我最近开始做一些这样的实践。比如法务合规上的事情，我已经开始让它完全自主地去做，有需要帮助和确认的时候再来找我，有任何进展也让它自己往群里同步，包括生活上的一些事情也是如此。
我觉得之前的思维模式在新的模型能力和范式下，开始往这个方向转变了：之前我还是会说我有一些想法、一些目标，你帮我把其中一些重要的部分完成；但现在我会直接把目标给它，甚至很多时候都不会多交代什么，让它自己去思考。
前面三次都还是任务制，这次我把它换成目标制。最大的不同来自于一个想法：如果让 AI 去跟进一个目标，这个目标的周期可能不是几个小时或者一两天，而是数周的级别。怎样让它可以在数周内持续跟进这个任务呢？用定时任务有点太机械了。所以我想到了一个方法：用不定时的任务。
让 AI 做完当前能做的事情之后，给自己定一个一次性的定时任务来唤起自己。唤起之后，AI 再看可以继续做什么；做完之后，再定下一个一次性的定时任务，选一个它自己想醒来的最佳时机。可能是半小时之后，也可能是 5 天之后，完全基于这个任务所依赖的事项什么时候可以继续进行，以此让它持续去跟进。
我最近开始做一些这样的实践。比如法务合规上的事情，我已经开始让它完全自主地去做，有需要帮助和确认的时候再来找我，有任何进展也让它自己往群里同步，包括生活上的一些事情也是如此。
我觉得之前的思维模式在新的模型能力和范式下，开始往这个方向转变了：之前我还是会说我有一些想法、一些目标，你帮我把其中一些重要的部分完成；但现在我会直接把目标给它，甚至很多时候都不会多交代什么，让它自己去思考。
1 11
我工作很忙，其实很需要锻炼身体，但是抽不出时间来运动。后来在 AI 的建议下，开始尝试每天做 2 到 3 次的 5 分钟碎片化运动，我觉得感受还是不错的。
我自己已经做了挺长时间了，今天也让 AI 做成图片分享一下。
如果想要更详细的动作指南，也可以直接搜索小红书。
我自己已经做了挺长时间了，今天也让 AI 做成图片分享一下。
如果想要更详细的动作指南，也可以直接搜索小红书。
13 31
一些朋友可能会好奇我到底在干啥，只知道我在搞 AI 硬件。加入初创公司已经 8 个多月了，产品终于有了明确要上市的计划。
大家感兴趣、想体验的话，可以报名这个在深圳的 workshop，申请链接在这里luma.com，有什么问题也可以直接来问我。
（看到的朋友也可以帮转一下😊
大家感兴趣、想体验的话，可以报名这个在深圳的 workshop，申请链接在这里luma.com，有什么问题也可以直接来问我。
（看到的朋友也可以帮转一下😊
31 910
未来的 Agent 肯定会从不可枚举的多 session 体验（ChatGPT、Claude Code），变成可枚举的单 session/agent（Muse） 或多 session/agent 体验（Grok bot），这个趋势是瞎眼可见的。
但核心的划分在于：究竟是一个 agent，还是可枚举的多个 agent。同时，在这个表面决策之下，底层架构里其实也有很多细节的取舍。
我觉得首先在用户的使用视角下：
• 生活场景肯定是单个 agent。
• 工作场景肯定是多个 agent。
而且这多个 agent 并不是服务于某一个个体，而是整个公司共享多个 agent；如果只服务于工作中的某个个体，那它仍然是单个 agent。在工作中，未来可能并不会是每个人自己拥有一个专属于自己的 AI 去干活，所有的 AI 之间应该是共享的。这就像每个人都是一个小组长，底下有几个员工，但这并不意味着我不能跨组向另一个组的员工下命令或请教事情，它只是在职权上有一些固定的分配而已。
为什么这么想？
从最简洁的架构说起，默认通常是单 agent，因为对用户而言最简单、最直观。但这套逻辑只能用于生活，不能用于工作，原因有以下几点：
1. 并行任务处理
单 agent 很难并行处理多项任务。生活中其实没有那么多需要并行的任务，但工作中一定有。当然你可以说采用类似DeepSeek 的 Super-agent，Router 下面分配多个 Worker 的架构，但这多 Worker 的任务人该如何管理？如果像Claude Duet 在每个 channel 下再分出多个 thread 让人去看，又违背了管理的初心。之所以用单 agent 或多个可枚举的 agent，就是为了让注意力能够更聚焦。
但在多 Agent 的框架流程下，所有的任务天然就基于角色进行了划分。我们记住一个角色、记住一个人是干什么的，比记住他在干哪些活容易得多。
2. 上下文复杂度
工作中上下文的复杂度远超生活。在生活中，最核心的上下文就是自己，对自己足够了解就足以完成任务，但工作中远远不止于此。
3. 严谨性要求
生活不需要那么严谨，而工作需要多方复核。这必然意味着要采用多 Agent 范式，甚至需要具备不同上下文内容的 Agent 来互相核验。
4. 权限分级
如果全公司只有一个 agent 显然不可能；但如果每个人各自一个 agent，让 agent 跟着员工的权限走，它又会被束缚在该员工个人的生产力和创造力之下。
因此，在一家公司里，更合理的范式是 Agent Team：拥有多个 agent，每个 Agent 被赋予不同的权限，拥有各自特定的上下文，并且能够互相核验。
所有这些 Agent 并不附属于某个员工，它附属于公司。
人和 AI 之间可以相互协作：每一个人都可以向每一个 Agent 发出命令、询问问题、相互沟通
在这个范式下，人和 Agent 几乎是平等的。人可能会处在某些核心地位上去做关键环节的把控；甚至有时可以反过来，Agent 为什么就不能带领一群外包呢？这也是完全可能的。
生活中不需要这样，因为所有权限都由用户自己把关，也不需要那么多多方审核的场景。所以在生活中，单个的类似 Muse 的范式是最贴切的；而在工作中，目前虽然还没有看到完全贴合的现成范式，Grok bot 和 Claude Tag 可能分别贴近一点。
Claude 可以脱离某一个具体的人为中介，让它在整个组织的上下文中发挥作用（所有人都可以在一个频道中 @同一个 claude），但它并没有将所有的上下文显性化到某些具体的 Agent 角色上。
而Grok bot 反过来，它显性化了，但并没有把它纳入到一个公司组织、一个多团队协作的上下文空间中，虽然 GrokBot 可以连到 Slack 了，但别人 @ 的并不是一个公有的角色，而仍然是我的 GrokBot 中的某个角色。它仍然在代表我，而不是作为团队的一个员工。
但核心的划分在于：究竟是一个 agent，还是可枚举的多个 agent。同时，在这个表面决策之下，底层架构里其实也有很多细节的取舍。
我觉得首先在用户的使用视角下：
• 生活场景肯定是单个 agent。
• 工作场景肯定是多个 agent。
而且这多个 agent 并不是服务于某一个个体，而是整个公司共享多个 agent；如果只服务于工作中的某个个体，那它仍然是单个 agent。在工作中，未来可能并不会是每个人自己拥有一个专属于自己的 AI 去干活，所有的 AI 之间应该是共享的。这就像每个人都是一个小组长，底下有几个员工，但这并不意味着我不能跨组向另一个组的员工下命令或请教事情，它只是在职权上有一些固定的分配而已。
为什么这么想？
从最简洁的架构说起，默认通常是单 agent，因为对用户而言最简单、最直观。但这套逻辑只能用于生活，不能用于工作，原因有以下几点：
1. 并行任务处理
单 agent 很难并行处理多项任务。生活中其实没有那么多需要并行的任务，但工作中一定有。当然你可以说采用类似DeepSeek 的 Super-agent，Router 下面分配多个 Worker 的架构，但这多 Worker 的任务人该如何管理？如果像Claude Duet 在每个 channel 下再分出多个 thread 让人去看，又违背了管理的初心。之所以用单 agent 或多个可枚举的 agent，就是为了让注意力能够更聚焦。
但在多 Agent 的框架流程下，所有的任务天然就基于角色进行了划分。我们记住一个角色、记住一个人是干什么的，比记住他在干哪些活容易得多。
2. 上下文复杂度
工作中上下文的复杂度远超生活。在生活中，最核心的上下文就是自己，对自己足够了解就足以完成任务，但工作中远远不止于此。
3. 严谨性要求
生活不需要那么严谨，而工作需要多方复核。这必然意味着要采用多 Agent 范式，甚至需要具备不同上下文内容的 Agent 来互相核验。
4. 权限分级
如果全公司只有一个 agent 显然不可能；但如果每个人各自一个 agent，让 agent 跟着员工的权限走，它又会被束缚在该员工个人的生产力和创造力之下。
因此，在一家公司里，更合理的范式是 Agent Team：拥有多个 agent，每个 Agent 被赋予不同的权限，拥有各自特定的上下文，并且能够互相核验。
所有这些 Agent 并不附属于某个员工，它附属于公司。
人和 AI 之间可以相互协作：每一个人都可以向每一个 Agent 发出命令、询问问题、相互沟通
在这个范式下，人和 Agent 几乎是平等的。人可能会处在某些核心地位上去做关键环节的把控；甚至有时可以反过来，Agent 为什么就不能带领一群外包呢？这也是完全可能的。
生活中不需要这样，因为所有权限都由用户自己把关，也不需要那么多多方审核的场景。所以在生活中，单个的类似 Muse 的范式是最贴切的；而在工作中，目前虽然还没有看到完全贴合的现成范式，Grok bot 和 Claude Tag 可能分别贴近一点。
Claude 可以脱离某一个具体的人为中介，让它在整个组织的上下文中发挥作用（所有人都可以在一个频道中 @同一个 claude），但它并没有将所有的上下文显性化到某些具体的 Agent 角色上。
而Grok bot 反过来，它显性化了，但并没有把它纳入到一个公司组织、一个多团队协作的上下文空间中，虽然 GrokBot 可以连到 Slack 了，但别人 @ 的并不是一个公有的角色，而仍然是我的 GrokBot 中的某个角色。它仍然在代表我，而不是作为团队的一个员工。
7 10
我真心且真诚地宣布，Muse 已经超越 Grok Bot 和 CodeX，在我心里面排第二了，仅次于我爱而不得的 Claude Code（之前 Grok Bot 也微微超越了 CodeX，所以 CodeX 从第二名降到了第四名）。
除了所谓的主动性之外，我觉得 Muse 还给我带来了几个好处：
1. 响应速度极快：它的答复真的非常快，响应速度应该是这里面最快的。
2. 人味最足：这可能和它的默认人格偏向生活有关系。其实在工作场景下，它的心智和工具还不够健全，但对生活上的帮助会比较大。对比之下，Codex 简直不说人话。
3. 真正能够闭环：它的 browser use 能力非常强大。操作速度堪称闪电：我对比过它和其他几个 agent 操作浏览器，它的速度真的是闪电速度，几百个字一下子“唰”地就打出去了，发邮件、跟客服沟通都贼快。
4. 智能水平很高：虽然速度足够快，但它的智能也很强，给出的建议和手段整体水平不弱于 Grok Bot 和 CodeX，甚至有些时候还会有亮点。
我觉得能快速响应、易于理解、能闭环任务、能高质量交付，真的都在它身上体现得挺充分的
除了所谓的主动性之外，我觉得 Muse 还给我带来了几个好处：
1. 响应速度极快：它的答复真的非常快，响应速度应该是这里面最快的。
2. 人味最足：这可能和它的默认人格偏向生活有关系。其实在工作场景下，它的心智和工具还不够健全，但对生活上的帮助会比较大。对比之下，Codex 简直不说人话。
3. 真正能够闭环：它的 browser use 能力非常强大。操作速度堪称闪电：我对比过它和其他几个 agent 操作浏览器，它的速度真的是闪电速度，几百个字一下子“唰”地就打出去了，发邮件、跟客服沟通都贼快。
4. 智能水平很高：虽然速度足够快，但它的智能也很强，给出的建议和手段整体水平不弱于 Grok Bot 和 CodeX，甚至有些时候还会有亮点。
我觉得能快速响应、易于理解、能闭环任务、能高质量交付，真的都在它身上体现得挺充分的
33 911
真的太夸张了，让我不得不分享一下。Muse 的主动性能力确实好得超乎我的预期，和 Dot、Today 那些，以及我之前体验过的产品，完全不是一个档次。
首先是 UI 和格式非常优雅：
• 会配图，每次都会生成个性化的头像
• 用社区式的收藏和讨论，代替了一般生成内容的点赞和"接着聊"
• 会明确告诉你为什么生成这篇帖子
• 帖子里还会附带行动项，比如提供类似"立即开始"的按钮
整个视觉和格式都非常棒。
当然这还是其次的，更重要的是它生成的内容极其精准。其实它的生成量蛮大的，昨天两个多小时就生成了 4 条，到现在差不多有 13 条了，但实用性依然很高。
今天早上的两个帖子真的震惊到我了：
1. 提醒填入境卡：我女朋友今早刚提醒我要填这个，而它比我女朋友提醒得还要早。这事非常重要，我们之前吃过亏，到了入境时才填，结果遇到各种麻烦。
2. 即时反馈调整：第二条内容本身质量不算特别高，但看它的文案，说是因为我之前收藏了某个帖子所以才推荐的。这意味着用户对帖子的反馈近乎即时生效，我昨天刚收藏了其中一条，今天它就已经基于这个收藏做出反馈和调整了，这太夸张了。
我觉得 Muse 和其他产品最大的不同在于：我用 Today、Dot 包括之前的同类产品，要么带来负面效应（我会直接关掉，比如 looki，我印象非常深刻，6 个小时给我推了 20 条没用的东西，给我折磨疯了），要么不痛不痒（放着不管，推了就看一眼，不推也不想，Dot 和 Today 的现状）。
但 Muse 是会让我主动去刷的。我已经有两次这样的体验了：会突然想到、忍不住打开去刷去浏览，昨晚和今早都是，看看它又给我推了什么好东西。这种体验，之前只在早期的 ChatGPT Pulse 上短暂出现过。
首先是 UI 和格式非常优雅：
• 会配图，每次都会生成个性化的头像
• 用社区式的收藏和讨论，代替了一般生成内容的点赞和"接着聊"
• 会明确告诉你为什么生成这篇帖子
• 帖子里还会附带行动项，比如提供类似"立即开始"的按钮
整个视觉和格式都非常棒。
当然这还是其次的，更重要的是它生成的内容极其精准。其实它的生成量蛮大的，昨天两个多小时就生成了 4 条，到现在差不多有 13 条了，但实用性依然很高。
今天早上的两个帖子真的震惊到我了：
1. 提醒填入境卡：我女朋友今早刚提醒我要填这个，而它比我女朋友提醒得还要早。这事非常重要，我们之前吃过亏，到了入境时才填，结果遇到各种麻烦。
2. 即时反馈调整：第二条内容本身质量不算特别高，但看它的文案，说是因为我之前收藏了某个帖子所以才推荐的。这意味着用户对帖子的反馈近乎即时生效，我昨天刚收藏了其中一条，今天它就已经基于这个收藏做出反馈和调整了，这太夸张了。
我觉得 Muse 和其他产品最大的不同在于：我用 Today、Dot 包括之前的同类产品，要么带来负面效应（我会直接关掉，比如 looki，我印象非常深刻，6 个小时给我推了 20 条没用的东西，给我折磨疯了），要么不痛不痒（放着不管，推了就看一眼，不推也不想，Dot 和 Today 的现状）。
但 Muse 是会让我主动去刷的。我已经有两次这样的体验了：会突然想到、忍不住打开去刷去浏览，昨晚和今早都是，看看它又给我推了什么好东西。这种体验，之前只在早期的 ChatGPT Pulse 上短暂出现过。
14 76
AI 已经极大且不可逆地影响了数字世界，未来它可能也会这样影响物理世界。
因此有人认为，我们需要世界模型，需要具身智能如人形机器人、灵巧手等等作为媒介。
但我现在觉得这个推论可能是错误的：AI 影响物理世界并不意味着需要新的物理载体，让旧的物理载体能够被 AI 所操控可能更有价值。
比如 Anthropic 做实验，让 AI 给小老鼠打针；Twitter 上有用户让 AI 自己租用智利、西班牙、犹他的望远镜，去测量小行星位置；或者 Anthropic 让 AI 在湿实验室里做实验。这些都是 AI 在影响物理世界，但并没有出现什么新的物理载体。
我觉得这可能才是短时间内的未来。当然，这个未来让人绝望的地方在于：可能并不需要新的世界模型，不需要新的物理载体，也没有什么新的硬件机会。
因此有人认为，我们需要世界模型，需要具身智能如人形机器人、灵巧手等等作为媒介。
但我现在觉得这个推论可能是错误的：AI 影响物理世界并不意味着需要新的物理载体，让旧的物理载体能够被 AI 所操控可能更有价值。
比如 Anthropic 做实验，让 AI 给小老鼠打针；Twitter 上有用户让 AI 自己租用智利、西班牙、犹他的望远镜，去测量小行星位置；或者 Anthropic 让 AI 在湿实验室里做实验。这些都是 AI 在影响物理世界，但并没有出现什么新的物理载体。
我觉得这可能才是短时间内的未来。当然，这个未来让人绝望的地方在于：可能并不需要新的世界模型，不需要新的物理载体，也没有什么新的硬件机会。
11 00
