7 Ways How We Use AI Is Changing

我们使用AI的方式正在改变。

一开始，我们是提示词工程师，然后是上下文工程师，接着是框架工程师，再然后是循环工程师。

虽然我们很容易把这些都看作是一个又一个可笑的流行词在更迭，但现实是，我们都在这个旅程中一起摸索，试图找到使用一种全新科技的最佳方式，这种科技既在改变我们现有工作的方式，也在开拓新的工作可能。

今天我们要讨论的是，我们使用AI的方式正在改变的7个方面。

《AI每日简报》是一个关于AI领域最重要新闻和讨论的每日播客和视频节目。

好了朋友们，在我们深入之前先快速说几件事。

今天的节目是关于一系列我认为代表我们日常与AI互动方式转变的模式。

从ChatGPT诞生之初至今，我们与AI的互动模式从来都不是一成不变的，这一点始终成立。

在最初，人们发现新的方式来给AI下提示词，结果有好有坏，然后通过成百上千的文章、帖子、YouTube视频、播客和课程传播开来。

但随着时间的推移，互动模式的转变变得更加重要和实质化。

大概在过去一周左右的时间里，我看到了一些公告，它们确实强化了这些互动模式中的一些相当大的转变。

虽然我不认为我们使用AI的方式会真正地一成不变，但我确实认为这些转变中——我将在本期节目中介绍的——有些是相当根本且可能会持续下去的。

因此，当然，如果一个人想高效利用时间，这可能就更值得关注了。

所以首先是一种互动模式，这与其说是我们改变与AI互动的方式，不如说是产品设计决策正在改变我们与AI互动的选项。

很明显，现在有一种趋势是追求简化和集成，以及为最终用户减少而非增加认知决策的用户体验。

坐在我这个位子上，有一点很有趣，那就是早期的AI似乎常常违背硅谷的传统逻辑——即如果你不提供极其简单清晰的体验，用户就不会来。

事实上，恰恰相反，许多早期采用者，不仅来自科技圈，也来自更广泛的知识工作者圈，他们不但没有抗拒复杂性，而是全身心投入其中。

对我来说一个很好的例子是，今年早些时候，有9000人——其中大多数人甚至不是工程师，也根本不太懂技术——报名参加了我的免费Claw Camp项目，这个项目基本上是让他们费尽心思去琢磨如何构建自己的agent。

然而，看起来，也许尽管在AI领域愿意做那种苦差事的人比例确实比过去其他科技领域要高，但仍然有很多人想要那种简单。

当然，“简单”是新的Meta Muse产品的关键词之一，即使是那些完全有能力应对复杂性的高级用户也对这个产品的这一点赞不绝口。

How IAI的Claire Vo在多个场合讨论过她认为Muse的设计考虑得多么周到，特别是关于它向用户隐藏了什么、又没有隐藏什么。

Node.js的创造者Ryan Dahl，他当然也完全有能力处理复杂性，同样称赞Muse成功做到了简单。

技术专家Tom Goodwin写道，Muse的美妙之处在于他们成功地以一种非常易上手的方式推出了它。

不用告诉我你怎么工作的，就告诉我怎么做事情就行了。

David Herman写道，我认为Muse将会赢得休闲AI竞赛。

我给我快70岁的爸爸看了，他一下就明白了。

他很惊讶，我可以让它为我创建一份完整的合同，修改内容，然后通过短信把它用电子邮件发给客户。

Claude、OpenAI都很棒，但到目前为止，我觉得只有不到1%的人真正理解这些模型是什么。

Meta让这一切变得超级简单。

很显然这是有意为之。

Meta的首席AI官Alexander Wang写道，团队在构建Muse时的一大重点是让它开箱即用。

为了简化产品、让使用变得轻松，他们投入了大量心血在每一个小细节上。

当然，让这成为趋势而不仅是Meta团队设计决策的原因是，这种简化正在到处出现。

这周我们收到的最大的产品更新之一是Anthropic宣布，Claude Cowork和Chat不再是两个分开的东西。

Claude正在快速演变，变得不再碎片化、不再让用户在一开始就需要做很多决定，而是变成一种统一的体验。

而且，核心理念还是简单和简化。

顺便说一句，正如Claude Code的创造者Kat Wu所指出的，这种简单不仅体现在消除Cowork和Chat的差异上，还体现在整合Claude Design，让你常用的核心Claude也具备制作幻灯片、设计、文档等所有能力，不用切换到专门的界面。

Anthropic团队也指出，这是基于用户的直接反馈。

Anthropic Labs的负责人、Instagram的前联合创始人Mike Krieger写道，我们最常听到的声音是人们不确定该从哪个产品开始。

这种摩擦阻碍了人们从这些模型的能力中获得最佳体验。

不过，正如我在本周早些时候的节目中提到的，我个人对这种做法并不完全认同，因为我喜欢拥有更具体的控制权，但看来我和大多数人的想法真的很不一样。

Christian Selig转发了这一宣布并说：“我们能否也把Codex做成这样，拜托？”

这两种模式就像两个家长在吵架。

Sean和Matthew总结道，人们不想同时处理两三个文本代理、两三个聊天代理或两三个桌面终端。

你希望有一个简单统一的界面，并让代理们协调完成任务。

你只需要提出请求然后收到结果。

平台应该负责协调和委派代理，为任务路由模型，处理事情是在本地、云端还是虚拟机上，并主动和被动地应对任务。

Instinct、Muse和GrokBot确实引起了共鸣，而且在我看来，我们显然正在进入另一个范式转变的时刻。

如果第一个变化是我们使用AI的界面变得简化，那么第二个变化本身就是一种简化，它关乎我们如何控制AI。

这就是单一线程的趋势。

单一线程的意思是，你不再需要切换上下文窗口来解释新的需求或提示，而是使用一个连续运行的长时间线程，它继承之前的对话上下文，并以此管理整个体验。

以前，这受限于上下文窗口的大小。

到某个时候，AI会“累”，也就是说它的上下文窗口会被填满，然后它就会开始出错、犯错或丢失指令等等。

在去年年底和今年年初，我做的很多早期课程和讲座都是关于如何编写良好的交接文档，以在不同线程之间传递上下文。

不过，这种状况今年开始转变，特别是当Codex团队专注于压缩上下文，以此改变人们仅通过一个统一线程使用Codex的方式时。

早在四月份，Codex的Nick Baumann写道，很多编码代理设计都基于一个假设，即超过上下文窗口并进行压缩会逐渐导致更差的结果。

当你放下这个假设，所开辟的产品方向将会非常令人兴奋。

他是在回应开发者Anthony Kroger，后者曾写道：“我使用Codex时从不担心上下文窗口。”

它能压缩好几次，但不知何故，模型依然记得细节。

在大约一周后发布的文章中，Codex团队的Nick在他的一篇名为《我的Codex线程是活的》文章中阐述了他的想法。

他在里面写道，我现在最有用的Codex线程是我过去三周一直在用的那个。

它每小时检查我的Slack、Gmail，以及我写的或正在看的PR。

它每小时把噪音变成我能采取行动的清晰信号。

我的Codex使用方式已经从启动很多短期对话，转变为围绕重复出现的工作流保持更少数量的线程存活。

我仍然经常开新线程，但有些工作不应该每次我问问题就重置。

他最后写道，总之，我已经变得只专注单一线程了。

Nick继续说，我最近说过，Codex团队做的压缩改进正在为编码代理开辟新的产品方向。

很多代理产品设计假设长线程最终会退化。

如果这是真的，产品应该推动用户创建新线程并写上下文摘要。

Codex团队一直在做很多压缩相关的工作，而这项工作削弱了这个假设。

当一个线程能在很多次对话后仍然有用，我就希望同一个线程继续处理这个重复出现的任务。

简单说，有了良好的上下文压缩，线程的价值会随时间增加。

现在，Nick在四月份写了这个，而我整年确实发现自己的行为越来越多地转向那个模式。

例如，我在AI Daily Brief网站上做的所有事情，目前都是通过一个单一的Claude Code线程管理的。

当我偶尔进去做改动或更新时，我不是从头开始那个线程。

我只是接着上次停下的地方继续。

我用Claude从节目里生成视频片段的社交流程，是另一个线程。

我甚至发现这种行为开始影响我在Claude其他部分（不只是Claude Code）里的交互方式。

例如，在过去的几个月里，在项目内部，我发现对于我常做的事情，比如更新或写新的广告文案，我不会每次需要做那个任务时都开新线程或新对话，而只是接着上次做类似任务的地方继续。

结果发现，我并不是唯一一个开始以这种方式改变行为的人。

事实上，到现在，从这周开始，这正式成为了Claude项目的工作方式。

周四，Claude账户发帖说，项目现在从Claude Code里的一个对话开始运行。

你描述需要做什么，Claude会指导并行线程，在关上笔记本电脑后这些线程继续工作。

换句话说，并不是没有多个线程，而是这些多个线程由Claude管理，你要做的是通过一个线程与Claude交互。

这和我刚才描述的模式非常相似。

顺便说一句，在这个功能到Claude之前的一周，它也已经到了Cursor。

事实上，当Cursor推出他们的项目版本时，这个逻辑内置其中。

在他们的公告中，他们写道，你不需要为每个任务创建一个聊天，而是通过一个单一持久线程与一个协调器代理一起工作。

这种转变的影响相当大。

Claude Code的创建者Boris Cherny写道，项目不仅改变了我与Claude互动的方式，也改变了我编码的方式。

我停止了管理会话。

我只是想到什么就发什么，Claude 会把它们拆分成不同的线程，项目也会记住我是怎么工作的。

而且我觉得，这跟我们用AI工作的方式上一个非常相关的转变有关。

也就是说，聊天机器人正逐渐变成代理舰队的管理者。

如果你看看我刚才举的那几个例子，变化在于我们跟一个协调型AI交互的地方变了，但那个协调型AI仍然在调度很多不同的子代理来完成工作的不同部分。

我在这儿觉得有意思的是，我想在一段时间里，我们很多人大概都以为聊天机器人界面本身是个中间界面，一个当时方便又熟悉的东西，但也许会让位给其他东西。

有意思的是，当你把单线程和聊天机器人作为代理舰队管理者两者结合起来，发生的事情是，模型和基础设施公司悄悄改变了聊天机器人的本质，而不是从聊天机器人上移开，但也没把界面这块地毯从我们脚下抽走。

我们仍然能获得那种跟聊天机器人互动时同样舒适的体验。

实际上，甚至还更简化了，因为我们可以从单个线程里做这件事。

但那个聊天机器人做的事情，跟一年前相比，已经非常非常不同了。

Claude Project 之所以这么有意思，是因为它处理代理团队真的很在行。

你跟一个主协调代理对话，它就会调度出各种专家。

基本上，它会创建一个组织来解决你的问题，根据你的偏好，混合使用贵的和便宜的代理。

顺便说一句，这对我们其他的软件服务也有影响，它们可能会越来越像我们主协调代理的上下文数据库。

我所有的 iMessage 和邮件现在都通过一个单一的代理界面来跑。

我仍然发短信，但我从手机上删掉了所有邮件客户端，也取消了每个邮件订阅或应用。

Gmail 对我来说基本上就是数据库了。

Google 的其他服务也越来越多是这样。

也就是说，我再也不想手动写邮件、建文档、做幻灯片、安排日历或者管理文件了。

我就想表达意图，然后让底层那些记录系统正确地更新好。

我觉得现在你会看到应用消失得很快。

很多应用最好也只是变成数据库，最糟的话就完全过时了。

代理会成为你个人和职业生活的默认界面。

而且即使这事儿没完全发生，或者比像 Signal 那样有远见的人想的时间要长得多，但很肯定的是，你正在交互的那些聊天机器人，做的已经跟以前不一样了。

市面上每个 AI 编程工具做的第一件事都一样：就开始写代码。

Blitzy 却反着来。

在写一行代码之前，Blitzy 会花好几天时间反向工程你整个代码库。

成千上万的代理会吸收数百万行代码，映射出每一个依赖、每一个没有文档记录的约束、每一个在过去十年里做出的架构决策。

结果就是一个动态的知识图谱，它能像一位在这行里待了三十年、经验丰富的工程师那样理解你的软件。

其他工具只用 grep 搜索和 markdown 文件来猜测上下文。

Blitzy 从来不会乱猜。

它先建立真正的理解，然后自主完成超过 80% 的整个软件史诗任务。

经过验证、端到端测试、达到生产级别的 Pull Request。

这就是为什么世界 500 强的工程团队会把最关键的代码库交给 Blitzy。

去 blitzy.com 亲自看看吧。

网址是 B-L-I-T-Z-Y 点 com。

最优秀的团队不是靠一个人扛着所有人前进。

他们清楚自己的优势，也了解彼此的短板，并且会利用这两点。

这就是 Robots and Pencils 刻意打造的团队。

那里没有人为了凑人头数而磨洋工。

大家为了解决难题而来，并且因为周围人都在同步进步而留下来。

在一个很多公司只想着快速招人的市场里，这值得一看。

每期节目，我都会聊到 OpenAI、Anthropic、SpaceX AI、Google 和 Meta 之间的竞争。

如果你听了一段时间，可能已经有自己的偏好了。

也许你觉得 OpenAI 和 Anthropic 能保持领先，或者 Meta 的开源策略能赢。

不管你怎么看，每个 AI 实验室都创造了不同的投资机会。

顺便说一句，我们在这个节目里聊过很多次的一个简单但深刻的变化是，你跟那个聊天机器人的交互方式会越来越多地通过语音。

我今年发布的每一个免费学习项目，一开始都恳请大家要么用原生的 ChatGPT 语音控制，要么安装类似 WhisperFlow 的东西，纯粹是为了语音带来的高效和更广阔的上下文。

而且，这正逐渐成为智能体产品的基本门槛。

这周，GrokBot 也加入进来了，它有了自己的原生语音集成。

xAI 的 Danny Graziosi 写道，用语音模式快速向你的首席参谋下达一连串任务，同时它协调你的机器人团队，感觉就像魔法一样。

同一团队的 Parker Conrad 写道，GrokBot 已经在向更无缝的交互模式迈出了一大步。

我看好语音能把它推得更远。

Gaurav Bison 指出，这不只是语音本身，而是语音正在与更强大的底层能力相结合。

他写道，今年我试过很多智能体产品的语音功能，在智能体真正能做事之前，它一直感觉像个噱头。

语音加上真正干实事，这才是组合拳。

就连那些早就拥抱语音的公司和项目，现在也变得更加重视了。

OpenAI 刚刚发布了一个新的 Codex 广告，他们团队的两名开发人员在锻炼的时候，跟 Codex 中由新模型 GPT Live 1 驱动的语音智能体对话。

他们一边锻炼一边干这个。

Google 也在做同样的事，这周发布了 Gemini 3.8 Live 和 3.8 Live Extended Thinking，他们写道，在智能和并行推理方面的重大升级，让你用语音协作和执行复杂任务变得更直观了。

上周，和Codex在那支健身广告里宣传的一样，我们有了Devin Voice，这让使用Devin的开发者也能通过语音调用新的GPT Live模型来写代码了。

Allie K. Miller总结得很到位，她说：每次我看到新的语音优先界面，心里就有个小声音在欢呼。

语音就是现在和未来的交互界面。

今年，除了单线程任务和更强大的、能管理自己任务队列的智能体协调器，以及语音指令之外，我们给AI下达指令的性质也发生了变化。

总结一下这个重大转变：我们不再只是给AI“提示”，而是越来越多地给它们设定目标。

这本质上给了AI更多自由裁量权和自主性，让它们自己去琢磨怎么完成工作，并且能反复循环直到任务做完。

这个变化始于一些基础功能的引入，比如Claude Code和Codex里的“/goal”命令。

这是对这种交互模式的规范化，让人们可以指定目标，而不仅仅是扔一条提示。

后来这扩展到了整个“循环工程”的概念，我们整个夏天都在聊这个，大概一个月前还专门做过一次网络研讨会。

循环的概念真正火起来，是因为OpenAI的创作者Peter Steinberger写道：你不应该再给编码智能体写提示了，你应该设计循环来提示你的智能体。

循环的概念很简单：除了定义目标之外，你还为这个目标定义成功标准，让智能体能自己对照衡量，这样它就能在一个持续循环中运行，直到根据你给的量化标准达成目标。

这个变化之所以值得在节目里提，是因为虽然“循环”和“循环工程”听起来完全是我们早期用户圈子里喜欢的那种热门词，其他人听到可能只想翻白眼，但实际上，这是一个相当关键的思维转变，关乎如何最大化我们与AI的互动效果——这也是我们花这么多时间聊它的原因。

我们与AI交互方式的第六个变化，我想可以叫“多模型并用”，也就是在个人技术栈里同时使用多个不同的模型。

这不只是组织层面的事情，即使是在单个用户的工作范围里也是如此。

我到现在还没找到最合适的词来描述这种多模型并用，我的很多Patreon订阅者也喜欢指出这一点。

不过，一方面，很多高级AI用户一直把模型选择当成一种获取优势的方式——也就是说，不局限于你订阅付费的那个单一模型，而是找到最适合特定任务的模型——但现在不同了，任务的复杂度、难度、深度和持续时间，加上最先进模型的成本，以及这些模型在标准套餐中补贴方式的变化，都意味着这不再只是早期用户的尝鲜行为，而是变成了成本和效率的现实要求。

另一个促成因素是，随着时间的推移，那些稍微落后于技术前沿但更便宜的模型，已经能完成几个月前才属于前沿水平的事情。

这在Fable 5.1发布的时候特别明显。

当时X上和各个AI社区里，大家都在分享各种技巧，怎么最大化利用这个模型又不花太多钱。

而且，这种情况正在从事后找技巧，逐渐演变成实际的使用系统规范。

这种交互模式的转变，和“聊天机器人作为智能体舰队管理者”的想法密切相关。

很多人注意到，至少在目前，像Fable 5.1这样的模型，默认做法不只是用最先进的模型做协调员，连所有子智能体也用它。

我们很多人都遇到过这种情况：交给Fable一个我们认为很常规的任务，结果回头一看，当前的用量上限被用掉了很大一部分——原来它为了做点研究，启动了5到10个子智能体，而这些子智能体全都用了最先进的Fable模型，可手头的任务完全不需要这么高的配置。

简单说，搞清楚哪些任务需要哪种模型、什么能力，以及如何在管理AI时规范化这一点，将越来越重要。

顺便说一句，这个趋势如果不小心处理，可能会和那个追求简洁的趋势相冲突。

因为所有模型和工具厂商都在试图让普通用户体验更简单，这往往意味着隐藏甚至取消那些精细的控制选项——比如决定哪个任务用哪个模型。

理论上，厂商们会尝试在底层构建自动化系统来帮你搞定这些细节——比如意识到研究任务的子智能体不需要用最前沿的模型。

但我并不确定他们总能做对。

所以我觉得，这方面用户还是需要保留一定的自主权。

最后一个交互模式的变化，我最近聊了很多，所以不打算深入展开，就是“共享智能体”这个概念。

2026年会被看作智能体真正成为现实的一年，在那之前大家已经兴奋了好多年。

但在今年头三分之二的时间里，几乎所有智能体行为都还局限在个人层面。

也就是我们每个人各自组建自己的OpenAI团队，改变自己做事的方式，但不一定会改变我们团队整体的工作方式。

这个趋势正在开始转变。

今年夏天有个例子，Claude推出了Claude Tag，取代了之前在Slack里用的老系统。

以前每个人可以调用自己的Claude实例，现在换成了一套基于团队的系统，每个频道都有自己的Slack，能够跨整个频道的上下文工作，不再绑定到某一个人身上。

这个思路其实很清楚。

我们的工作有一部分确实是个人完成的，但很大一部分是团队完成的，所以我们需要的可能不只是存在于个人小世界里的智能体，而是存在于团队交汇点上的智能体。

现在你开始看到很多朝着这个方向的努力了。

Mio XYZ这周上线了，号称是“整个团队共享的第一个AI员工”。

他们在公告里写道，从7月开始内测以来，Mio为团队节省了数千小时，完成了数万个任务。

你不需要另一个智能体，你需要一个能和团队共享的智能体。

我几乎每天都能看到六七个类似趋势的例子，不过多人AI的具体含义还处在探索阶段。

本月初，Ethan Mollick写道：多人AI——即组织中多人一起使用AI来达成目标——仍然是当前使用AI时最大的非技术难题之一。

目前的方法还非常原始，基本上就是把AI当成群聊里的一个人。

这很局限。

Aria Bhuktani写道，我们至今没有一个统一的心智模型来理解在多人智能体系统中，到底谁是主体。

是你，用户吗？

智能体作为你的代理，继承你的上下文、权限和授权？

还是智能体本身？

智能体有自己的身份、关系、记忆和权限。

Aria接着说，这就像是智能体文明与人类文明以智能体速度运转之间的区别。

实际上，答案很可能是两者皆有，但适用于不同的系统和场景。

多人AI将成为2027年最大的设计问题之一。

光是这个短语，跟我聊的人每个人理解都不一样。

它指的是共享记忆、上下文、组织架构，还是完全不同的东西？

有意思的是，Rishi随后解释了为什么每个角度单独看都很有道理。

他写道，从记忆角度看：五个智能体做一个项目，对发生的事情有五个不同版本，彼此不沟通。

一团糟。

解决办法就是用一份共享记忆取代五份私有副本，这就是全部关键所在。

但接下来还有上下文这个维度。

Rishi 接着说，几乎每个我聊过的人，都给自己搭建了一个小小的上下文层，给自己的 agent 用。

对他们自己来说是管用的。

但放到整个团队里，那就行不通了。

个人上下文感觉已经解决了，但组织级别的上下文还完全是个空白。

然后当然还有组织变革这个维度。

Rishi 总结说，多人 AI 最难的部分可能根本不是技术问题。

让整个团队都采用同一种工作方式，这更像是组织设计，而不是工程问题。

没人愿意承认这一点。

但很明显，这方面会有大量的工作要做。

我们还没就多人 AI 的架构模式达成共识，就已经决定要让 AI 进入多人模式了。

然后当然他会继续解释这一切，试图让我们得到一个稍微更连贯的答案。

会有大量的产品体验和优秀的产品思路，出现在多人 AI 或者共享 agent 这个领域。

而且很快就会来。

所以，如果你想把这个问题往后推一推，让行业和规范再定型一些，我完全可以理解。

话虽这么说，但我确实觉得，对于想要深入尝试的团队来说，抢先一步肯定能获得一些先机。

以上就是我们使用 AI 的方式正在改变的七个方面。

希望这能给你一些值得探索的有趣新方向，以及一些思考你和 AI 关系的新角度。

那么，今天的 AI Daily Brief 就到这里。

一如既往感谢你的收听或收看，下次见，Peace。