即刻App年轻人的同好社区
下载
微信还是接入了开源龙虾，入口之争不可失。
在微信宣布接入开源龙虾 openclaw 之前，最好用的入口是飞书。
虽然微信自己出来了一个 Qclaw，原生龙虾，但是口碑不好，一点都不能打。
但是入口怎么能放弃？字节已经是做空恒科的代表了，腾讯能忍受自己的入口继续被蚕食吗？
答案是不能，那打不过就先加入。
五分钟就让龙虾自己加入了微信。
1. 先要更新微信到最新版，很多人忘记这个。
2. 让龙虾自己安装微信渠道，直接把命令发给飞书龙虾就可以，
npx -y @tencent-weixin/openclaw-weixin- cli@Latest install
很多人说都要去服务器端自己安装，没必要，相信龙虾的能力。
可以让它把微信二维码给你截图出来扫，微信一扫就可以了。
如果扫码截图搞不定，关注私我，还有一招，小白都能稳稳拿下。
3. 让龙虾自己重启 gateway，直接发它。openclaw restart然后等着就行，微信端可以看到「微信 ClawBot」
AI 时代，怎么不学点大模型原理知识？ 关注私我一起 AI
在微信宣布接入开源龙虾 openclaw 之前，最好用的入口是飞书。
虽然微信自己出来了一个 Qclaw，原生龙虾，但是口碑不好，一点都不能打。
但是入口怎么能放弃？字节已经是做空恒科的代表了，腾讯能忍受自己的入口继续被蚕食吗？
答案是不能，那打不过就先加入。
五分钟就让龙虾自己加入了微信。
1. 先要更新微信到最新版，很多人忘记这个。
2. 让龙虾自己安装微信渠道，直接把命令发给飞书龙虾就可以，
npx -y @tencent-weixin/openclaw-weixin- cli@Latest install
很多人说都要去服务器端自己安装，没必要，相信龙虾的能力。
可以让它把微信二维码给你截图出来扫，微信一扫就可以了。
如果扫码截图搞不定，关注私我，还有一招，小白都能稳稳拿下。
3. 让龙虾自己重启 gateway，直接发它。openclaw restart然后等着就行，微信端可以看到「微信 ClawBot」
AI 时代，怎么不学点大模型原理知识？ 关注私我一起 AI
1 01
阿里的龙虾，悟空来了。
阿里昨天终于发布了一个全新版本的悟空。这不是大家玩游戏的那个黑悟空，而是一个类似龙虾的智能体平台。他们提出了一个概念叫做 OPT（One Person Team），也就是说你可以在这个悟空平台上直接一键创建一个团队。它里面打包了很多有行业经验的 skill，可以让你快速创建一个智能体，并配上这些 skill，理论上可以帮你完成很多事情。
我比较关注其中两点：
1. 节约 token 的方式。我们都养过龙虾，龙虾使用的 token 量非常大，基本上随便问几个问题，可能就要投入几十万的 token。
2. 安全性。毕竟这是针对 B 端的产品，企业对安全的容忍度非常低。
在节约 token 这件事情上，他们做了两件事：
- 第一是重写了所谓的文件系统。因为我们知道，消耗 token 很多的地方主要是在读大量文档和文本内容，特别是在做文档修改，这也是企业中常见的场景。
这基本上是企业中不可或缺的使用场景，或者说，是最核心的用户场景也不为过。比如修改文档、制作PPT，这些都需要反复操作。当你让AI去修改内容时，它通常需要反复读取大量文本，这会导致成本迅速上升。
因此，他们重写了整个文件系统，称为AI-Native文件系统。它能精确地更新文档中的某行或某几行，而无需读取整个文档。
另外，他们将所有底层工具都包装成了CLI。这不同于传统方式：传统上，AI可能需要通过浏览器工具（如打开Chrome网页），通过截图查看内容，再通过模拟人类操作（如点击页面按钮）来与页面交互并看到更新。这种传统的工具调用方式非常消耗Token，因为处理图片本身就需要大量Token，而且需要反复操作按钮、定位元素、生成新页面并再次截图，这些过程都造成了Token的浪费。
因此，他们选择重写所有接口，将其包装成CLI。从这点看，我也认为CLI 是比MCP Server更好的选择。因为MCP Server本质上是另一种API微服务，启动它需要成本，为了高可用还需要部署多个节点，这些实际上都是浪费。
但如果是CLI，它实际上就是运行在命令行工具里的一个用户程序，可以随调随用，就像Shell命令或Bash 命令一样。同时，AI或者说大模型，对于这类Bash 命令的使用是非常熟练的。所以，你也会看到现在包括OpenAI在内的产品，都推出了像CLI 这样的一些工具，而不是提供API或者甚至是Agent的方式。
因此，我觉得在企业开发的后续，对于工具箱的调用，大部分可能都会转向CLI 这类方式。他做了这两点，就基本上能够把最消耗Token、最浪费Token的地方给抹平了，从而达到节约Token的目的。
另外，第二点企业比较关心的肯定是安全。他也做了一些跟传统软件类似的安全性保障，但其中有一点可能是AI时代独有的。那就是对于Skill的管理。我们都知道，现在开源社区有很多Skill，里面可能容易包含一些恶意代码或恶意脚本。一旦使用了它的Skill，它运行时可能就会爬取你本地电脑的文件，或修改你的权限等。
这实际上类似于传统软件中的木马或病毒。他做的事情是：首先，他提供了很多行业相关的Skill，但所有的Skill都经过其安全扫描，以此来保证安全性。当然，所有的AI都会运行在其独有的沙盒环境里，这个沙盒环境本身可能也是受限的。这点上，就和我们传统开发SaaS或其他软件差不多，都是跑在Docker或Docker容器里面。
总体而言，我觉得从他发布的这个产品来看，是能看到AI发展的一个趋势的。
阿里昨天终于发布了一个全新版本的悟空。这不是大家玩游戏的那个黑悟空，而是一个类似龙虾的智能体平台。他们提出了一个概念叫做 OPT（One Person Team），也就是说你可以在这个悟空平台上直接一键创建一个团队。它里面打包了很多有行业经验的 skill，可以让你快速创建一个智能体，并配上这些 skill，理论上可以帮你完成很多事情。
我比较关注其中两点：
1. 节约 token 的方式。我们都养过龙虾，龙虾使用的 token 量非常大，基本上随便问几个问题，可能就要投入几十万的 token。
2. 安全性。毕竟这是针对 B 端的产品，企业对安全的容忍度非常低。
在节约 token 这件事情上，他们做了两件事：
- 第一是重写了所谓的文件系统。因为我们知道，消耗 token 很多的地方主要是在读大量文档和文本内容，特别是在做文档修改，这也是企业中常见的场景。
这基本上是企业中不可或缺的使用场景，或者说，是最核心的用户场景也不为过。比如修改文档、制作PPT，这些都需要反复操作。当你让AI去修改内容时，它通常需要反复读取大量文本，这会导致成本迅速上升。
因此，他们重写了整个文件系统，称为AI-Native文件系统。它能精确地更新文档中的某行或某几行，而无需读取整个文档。
另外，他们将所有底层工具都包装成了CLI。这不同于传统方式：传统上，AI可能需要通过浏览器工具（如打开Chrome网页），通过截图查看内容，再通过模拟人类操作（如点击页面按钮）来与页面交互并看到更新。这种传统的工具调用方式非常消耗Token，因为处理图片本身就需要大量Token，而且需要反复操作按钮、定位元素、生成新页面并再次截图，这些过程都造成了Token的浪费。
因此，他们选择重写所有接口，将其包装成CLI。从这点看，我也认为CLI 是比MCP Server更好的选择。因为MCP Server本质上是另一种API微服务，启动它需要成本，为了高可用还需要部署多个节点，这些实际上都是浪费。
但如果是CLI，它实际上就是运行在命令行工具里的一个用户程序，可以随调随用，就像Shell命令或Bash 命令一样。同时，AI或者说大模型，对于这类Bash 命令的使用是非常熟练的。所以，你也会看到现在包括OpenAI在内的产品，都推出了像CLI 这样的一些工具，而不是提供API或者甚至是Agent的方式。
因此，我觉得在企业开发的后续，对于工具箱的调用，大部分可能都会转向CLI 这类方式。他做了这两点，就基本上能够把最消耗Token、最浪费Token的地方给抹平了，从而达到节约Token的目的。
另外，第二点企业比较关心的肯定是安全。他也做了一些跟传统软件类似的安全性保障，但其中有一点可能是AI时代独有的。那就是对于Skill的管理。我们都知道，现在开源社区有很多Skill，里面可能容易包含一些恶意代码或恶意脚本。一旦使用了它的Skill，它运行时可能就会爬取你本地电脑的文件，或修改你的权限等。
这实际上类似于传统软件中的木马或病毒。他做的事情是：首先，他提供了很多行业相关的Skill，但所有的Skill都经过其安全扫描，以此来保证安全性。当然，所有的AI都会运行在其独有的沙盒环境里，这个沙盒环境本身可能也是受限的。这点上，就和我们传统开发SaaS或其他软件差不多，都是跑在Docker或Docker容器里面。
总体而言，我觉得从他发布的这个产品来看，是能看到AI发展的一个趋势的。
1 00
Prompt 其实是跟大模型交互的唯一通道。
最近在系统学习大模型的一些基本原理，以及如何更有效地构建和落地一些 agent，真正帮助企业转型。最近学习到一个最主要的点，虽然之前也在做，但突然有种顿悟的感觉，就是我们所谓的 prompt，实际上是与大模型交互的唯一途径。
所以，不管是在做应用还是在做 agent，其实我们都是在借助工程化的手段，通过各种方式为大模型构建一个最合适的 prompt，借此来获得最佳的结果。这基本上就是我们做 agent 的所有工作。
比如说，我们写的系统提示词，需要贴合要解决问题的业务场景，去构建这个提示词。同时，提示词不能太长，所以需要能够动态地加入一些提示词，这就需要用到像 RAG 这样的技术。RAG 能根据语义搜索，匹配到与用户问题最相关的提示词，并动态添加进去。
我们也一直在构建各种工具给大模型使用，让它能更好地获取更多、更准确的信息。比如之前我们做的 MCP server，但现在大家都发现，这种方式可能还没开始工作，MCP server 的提示词就已经把模型的上下文占满了，这可能并不是最佳的方式。
所以，你才会看到为什么 Anthropic 又推出了 Skill。Skill 是一种渐进式加载内容的方式。每次加载时，只加载技能的一些简短描述（即其元数据），然后判断哪些技能与当前问题相关，再动态加载对应技能的全部内容。这其实是另一种形式的 RAG，本质上也是为了构建更好的提示词。
因为 MCP Server 会占用太多上下文，所以基本上被弃用了。而 Skill 解决了这个问题。同时，在 Skill 里也可以直接调用 MCP Server。
所以，回过头来看，当我们要真正构建一个 Agent 时，其实还是脱离不开原先做产品的那套思路：
1. 首先，明确你需要这个 Agent 解决什么样的问题。
2. 然后，准备好解决这些问题所需的数据。
3. 接着，分析用户会如何提问，以及这些问题应该匹配到哪些数据。
这样，你就能很好地去构建你的知识库和技能包。
那么，基本上现在所有的 Agent 都是通用 Agent。所谓的“垂直 Agent”已经不存在了。或者说，所谓的垂直 Agent，实际上等于“通用 Agent”加上“垂直的技能包”和“垂直的知识库”。
所以，最终的目的还是要把这些东西合并成一个最恰当的提示词，给到大模型去处理。
最近在系统学习大模型的一些基本原理，以及如何更有效地构建和落地一些 agent，真正帮助企业转型。最近学习到一个最主要的点，虽然之前也在做，但突然有种顿悟的感觉，就是我们所谓的 prompt，实际上是与大模型交互的唯一途径。
所以，不管是在做应用还是在做 agent，其实我们都是在借助工程化的手段，通过各种方式为大模型构建一个最合适的 prompt，借此来获得最佳的结果。这基本上就是我们做 agent 的所有工作。
比如说，我们写的系统提示词，需要贴合要解决问题的业务场景，去构建这个提示词。同时，提示词不能太长，所以需要能够动态地加入一些提示词，这就需要用到像 RAG 这样的技术。RAG 能根据语义搜索，匹配到与用户问题最相关的提示词，并动态添加进去。
我们也一直在构建各种工具给大模型使用，让它能更好地获取更多、更准确的信息。比如之前我们做的 MCP server，但现在大家都发现，这种方式可能还没开始工作，MCP server 的提示词就已经把模型的上下文占满了，这可能并不是最佳的方式。
所以，你才会看到为什么 Anthropic 又推出了 Skill。Skill 是一种渐进式加载内容的方式。每次加载时，只加载技能的一些简短描述（即其元数据），然后判断哪些技能与当前问题相关，再动态加载对应技能的全部内容。这其实是另一种形式的 RAG，本质上也是为了构建更好的提示词。
因为 MCP Server 会占用太多上下文，所以基本上被弃用了。而 Skill 解决了这个问题。同时，在 Skill 里也可以直接调用 MCP Server。
所以，回过头来看，当我们要真正构建一个 Agent 时，其实还是脱离不开原先做产品的那套思路：
1. 首先，明确你需要这个 Agent 解决什么样的问题。
2. 然后，准备好解决这些问题所需的数据。
3. 接着，分析用户会如何提问，以及这些问题应该匹配到哪些数据。
这样，你就能很好地去构建你的知识库和技能包。
那么，基本上现在所有的 Agent 都是通用 Agent。所谓的“垂直 Agent”已经不存在了。或者说，所谓的垂直 Agent，实际上等于“通用 Agent”加上“垂直的技能包”和“垂直的知识库”。
所以，最终的目的还是要把这些东西合并成一个最恰当的提示词，给到大模型去处理。
0 00
如果龙虾早出来十年，移动互联会不会都没有那么大的发展？
现在养龙虾的热度依然很高，虽然相比以前稍微平缓了一些。大部分人已经开始养龙虾，养的人多了，大家也慢慢发现它确实是一个现象级的产品。它能够从你以前使用 ChatGPT 作为 consultant，变成一个能够帮你干活的数字助手。
不过，它能做的事情还是有一定局限性，甚至还有一些门槛。举个例子，比如你给它配置了网络搜索接口，不管是 Brave 接口还是其他接口，很多时候都需要付费、需要额度，甚至不能很好地搜索到高质量的文章（因为很多网站设置有很强的反爬机制），这些都是门槛。如果龙虾拿不到高质量数据，其实效果就会大打折扣。
有意思的是，还有一些个人或公司也开始捣鼓手机上的相关产品。我有点想不明白，理论上我的感受是，如果龙虾早在移动互联网之前的二十年或十几年就出现，那么移动互联网可能都不会有这么大的阵势了。原因很简单，比如现在他们做了一个手机上的龙虾，但后端逻辑其实和电脑上的龙虾类似，你可以做一个远程云端主机，它像一个 PC 电脑一样，可以在上面做各种操作。
你可以操作上面的应用、浏览器以及其他工具。这相当于现在做一个手机上的龙虾，其背后的逻辑是类似的。它本质上是为你提供一个远程的云端手机，上面安装了你自己的应用，比如小红书、微信、头条、抖音等，这些基本上都有。然后你需要给它账号去登录。
但我的问题是：在手机上操作和在电脑上操作，对于龙虾来说有什么区别？因为龙虾真正需要的只是数据。它获取数据之后，就能帮你规划、思考并完成任务，例如整理文章。它根本不需要去操作手机上的那些移动应用来获取数据。
如果按照这个逻辑来推，那是不是车载系统上也需要一只龙虾？它也需要访问同样的数据，比如车载系统上可能也有小红书、抖音。其实，这两者在龙虾眼里，它看到的不是界面，只是数据而已。
所以在这点上，我始终没想明白这样做的目的到底是什么。对于龙虾来说，操作浏览器，操作cli或者操作API是最简单的方式。除非有些公司只做了移动应用，或者根本没有网页端版本，也没有提供API。
这样才有可能会去操作手机以获取这些龙虾需要的数据源。然而，这一个gap很快就会被抹平掉，因为你不接入生态，你就没有生态，你就活不下去了。
现在养龙虾的热度依然很高，虽然相比以前稍微平缓了一些。大部分人已经开始养龙虾，养的人多了，大家也慢慢发现它确实是一个现象级的产品。它能够从你以前使用 ChatGPT 作为 consultant，变成一个能够帮你干活的数字助手。
不过，它能做的事情还是有一定局限性，甚至还有一些门槛。举个例子，比如你给它配置了网络搜索接口，不管是 Brave 接口还是其他接口，很多时候都需要付费、需要额度，甚至不能很好地搜索到高质量的文章（因为很多网站设置有很强的反爬机制），这些都是门槛。如果龙虾拿不到高质量数据，其实效果就会大打折扣。
有意思的是，还有一些个人或公司也开始捣鼓手机上的相关产品。我有点想不明白，理论上我的感受是，如果龙虾早在移动互联网之前的二十年或十几年就出现，那么移动互联网可能都不会有这么大的阵势了。原因很简单，比如现在他们做了一个手机上的龙虾，但后端逻辑其实和电脑上的龙虾类似，你可以做一个远程云端主机，它像一个 PC 电脑一样，可以在上面做各种操作。
你可以操作上面的应用、浏览器以及其他工具。这相当于现在做一个手机上的龙虾，其背后的逻辑是类似的。它本质上是为你提供一个远程的云端手机，上面安装了你自己的应用，比如小红书、微信、头条、抖音等，这些基本上都有。然后你需要给它账号去登录。
但我的问题是：在手机上操作和在电脑上操作，对于龙虾来说有什么区别？因为龙虾真正需要的只是数据。它获取数据之后，就能帮你规划、思考并完成任务，例如整理文章。它根本不需要去操作手机上的那些移动应用来获取数据。
如果按照这个逻辑来推，那是不是车载系统上也需要一只龙虾？它也需要访问同样的数据，比如车载系统上可能也有小红书、抖音。其实，这两者在龙虾眼里，它看到的不是界面，只是数据而已。
所以在这点上，我始终没想明白这样做的目的到底是什么。对于龙虾来说，操作浏览器，操作cli或者操作API是最简单的方式。除非有些公司只做了移动应用，或者根本没有网页端版本，也没有提供API。
这样才有可能会去操作手机以获取这些龙虾需要的数据源。然而，这一个gap很快就会被抹平掉，因为你不接入生态，你就没有生态，你就活不下去了。
1 00
养龙虾呀养龙虾，全民养龙虾。
现在基本上全民都在养龙虾。最早龙虾刚出来的时候，其实已经注意到了，但一开始以为它和其他AI产品一样是昙花一现，没想到等了一阵后，发现越来越火爆。特别是到了春节，热度一直不减。
我关注的博主们也都开始参与，先是在文章里聊龙虾，后来亲自上阵，在视频里开直播，讲怎么养龙虾，以及龙虾带给他们的感受。最后大家看新闻也发现，安装龙虾基本上还要收费。500 元安装一只龙虾。
最近，各大云厂商如阿里、字节、腾讯也都发布了自己的龙虾，并在自己的云服务器上运行。用户可以直接购买云服务器、模型调用，一键配置。这里多说一句，我发现腾讯还是很注重产品体验，在配置龙虾、接入飞书和QQ时，体验是最好的。
这两天，国家和各个省市，包括深圳、无锡等城市都开始发声，表示要支持养龙虾业务，给予金钱和算力上的支持，感觉一下子就到达了顶峰。
所以说回来，基本上已经是全民在养龙虾了。对于养龙虾这件事，我自己也养了大概三周多的样子，而且养了3只。前面两三只是一开始配置的，有一些技能没搞对，更多是因为前面的龙虾都配置在国内的服务器上。后面索性上了一个腾讯云，买了一个海外服务器，因为相对来说会方便点。毕竟龙虾是舶来货，它原先配置了很多技能，理论上它需要能够调用比如像GitHub或Google的一些能力，所以就换成了海外服务器来重新养殖龙虾。
我体验下来，有几点原因让它成为全民都在争相尝试的AI产品（我把它定位成一个AI产品，因为这样才能破圈，不再只是技术人员可以玩的玩具或产品）：
1. 我觉得最重要的一点是，它对接到了我们的IM渠道，比如飞书、企业微信、QQ。这个举动一下子改变了使用AI产品的交互方式。它不太像以前使用ChatGPT那样，需要打开电脑、打开网页、登录上去、问一个问题、得到一段文本回复。你现在是用平时经常使用的、跟别人聊天的工具来交互。
就可以通过你日常使用的聊天工具，与你背后的这个Agent（龙虾）进行沟通，让它帮你做事。所以，整个交互方式的改变，我认为一下子就把使用AI产品的门槛急剧降低了。
它甚至降低了什么门槛呢？比如说，如果你懂点技术原理，你会知道这个龙虾背后实际上就是一个Coding Agent，类似Claude Code或Codex，你配置它，它是可以写代码的。它甚至把之前流行的 Vibe Coding门槛，直接降到了你可以通过语音聊天就直接进行 Vibe Coding的程度。所以，仅仅是交互方式的改变这一件事，就直接把整个门槛降得非常低。
这是最重要的一点，因为乔布斯以前也说过，任何交互方式的改变都是一场革命。所以这是第一点。小白用户也可以直接上手用。
第二点，在使用龙虾的过程中，我觉得它实际上是一个非常主动的助手。你可以吩咐它一些任务，它不会忘记，当它真正开始执行或完成任务时，它会主动来提醒你。这种感觉是很不一样的。再加上我们前面说的，它套上了你日常聊天工具的界面之后，有时候甚至会让你有点恍惚，觉得背后可能是一个真人。
> 它就像一个真正的人在背后默默地帮你做事，所以那种做事的主动性会让你感觉非常棒。
**第三点**是，它其实非常能够自我进化。这里我直接拿它的创始人皮特自己的一个例子：他刚开发完这个龙虾时，没有给它接入语音功能。有一次，他就用自己日常的聊天工具直接给这只龙虾发了一段语音。
这只龙虾接到后，发现是一段语音，而它没有解析语音的接口。于是，它自己搜索网络，对接了一个免费的ASR接口，把这段语音的内容解析了出来，完成工作后再返回给皮特。
这一下就让皮特觉得，这只龙虾能够自己学习和进化，并把新技能沉淀下来。他第一次感受到了一个AGI时刻。
所以，基本上我觉得这三点（当然还有其他的）是最重要的。但还有另外一点我认为也足够重要，那就是：当你用得越来越多，因为经常跟它聊天，它会慢慢学习你的喜好、记住你的习惯，变得越来越懂你。
这点让很多人也有点“破防”了——为什么你这么懂我？我随便说一句话，你就能按照我原先的喜好、我的工作方式、我的要求，一句话就给我做出来。这种感觉是非常不一样的，就相当于人人都有一个这样的助手了。
所以，基本上每个人都能拥有一个最懂自己的数字助理，它能做非常多的事情。我认为，这就是为什么“龙虾”的热度居高不下，并且全民都想去“养龙虾”的最主要原因。
现在基本上全民都在养龙虾。最早龙虾刚出来的时候，其实已经注意到了，但一开始以为它和其他AI产品一样是昙花一现，没想到等了一阵后，发现越来越火爆。特别是到了春节，热度一直不减。
我关注的博主们也都开始参与，先是在文章里聊龙虾，后来亲自上阵，在视频里开直播，讲怎么养龙虾，以及龙虾带给他们的感受。最后大家看新闻也发现，安装龙虾基本上还要收费。500 元安装一只龙虾。
最近，各大云厂商如阿里、字节、腾讯也都发布了自己的龙虾，并在自己的云服务器上运行。用户可以直接购买云服务器、模型调用，一键配置。这里多说一句，我发现腾讯还是很注重产品体验，在配置龙虾、接入飞书和QQ时，体验是最好的。
这两天，国家和各个省市，包括深圳、无锡等城市都开始发声，表示要支持养龙虾业务，给予金钱和算力上的支持，感觉一下子就到达了顶峰。
所以说回来，基本上已经是全民在养龙虾了。对于养龙虾这件事，我自己也养了大概三周多的样子，而且养了3只。前面两三只是一开始配置的，有一些技能没搞对，更多是因为前面的龙虾都配置在国内的服务器上。后面索性上了一个腾讯云，买了一个海外服务器，因为相对来说会方便点。毕竟龙虾是舶来货，它原先配置了很多技能，理论上它需要能够调用比如像GitHub或Google的一些能力，所以就换成了海外服务器来重新养殖龙虾。
我体验下来，有几点原因让它成为全民都在争相尝试的AI产品（我把它定位成一个AI产品，因为这样才能破圈，不再只是技术人员可以玩的玩具或产品）：
1. 我觉得最重要的一点是，它对接到了我们的IM渠道，比如飞书、企业微信、QQ。这个举动一下子改变了使用AI产品的交互方式。它不太像以前使用ChatGPT那样，需要打开电脑、打开网页、登录上去、问一个问题、得到一段文本回复。你现在是用平时经常使用的、跟别人聊天的工具来交互。
就可以通过你日常使用的聊天工具，与你背后的这个Agent（龙虾）进行沟通，让它帮你做事。所以，整个交互方式的改变，我认为一下子就把使用AI产品的门槛急剧降低了。
它甚至降低了什么门槛呢？比如说，如果你懂点技术原理，你会知道这个龙虾背后实际上就是一个Coding Agent，类似Claude Code或Codex，你配置它，它是可以写代码的。它甚至把之前流行的 Vibe Coding门槛，直接降到了你可以通过语音聊天就直接进行 Vibe Coding的程度。所以，仅仅是交互方式的改变这一件事，就直接把整个门槛降得非常低。
这是最重要的一点，因为乔布斯以前也说过，任何交互方式的改变都是一场革命。所以这是第一点。小白用户也可以直接上手用。
第二点，在使用龙虾的过程中，我觉得它实际上是一个非常主动的助手。你可以吩咐它一些任务，它不会忘记，当它真正开始执行或完成任务时，它会主动来提醒你。这种感觉是很不一样的。再加上我们前面说的，它套上了你日常聊天工具的界面之后，有时候甚至会让你有点恍惚，觉得背后可能是一个真人。
> 它就像一个真正的人在背后默默地帮你做事，所以那种做事的主动性会让你感觉非常棒。
**第三点**是，它其实非常能够自我进化。这里我直接拿它的创始人皮特自己的一个例子：他刚开发完这个龙虾时，没有给它接入语音功能。有一次，他就用自己日常的聊天工具直接给这只龙虾发了一段语音。
这只龙虾接到后，发现是一段语音，而它没有解析语音的接口。于是，它自己搜索网络，对接了一个免费的ASR接口，把这段语音的内容解析了出来，完成工作后再返回给皮特。
这一下就让皮特觉得，这只龙虾能够自己学习和进化，并把新技能沉淀下来。他第一次感受到了一个AGI时刻。
所以，基本上我觉得这三点（当然还有其他的）是最重要的。但还有另外一点我认为也足够重要，那就是：当你用得越来越多，因为经常跟它聊天，它会慢慢学习你的喜好、记住你的习惯，变得越来越懂你。
这点让很多人也有点“破防”了——为什么你这么懂我？我随便说一句话，你就能按照我原先的喜好、我的工作方式、我的要求，一句话就给我做出来。这种感觉是非常不一样的，就相当于人人都有一个这样的助手了。
所以，基本上每个人都能拥有一个最懂自己的数字助理，它能做非常多的事情。我认为，这就是为什么“龙虾”的热度居高不下，并且全民都想去“养龙虾”的最主要原因。
1 00
大模型时代下，人应该要凸显什么价值？
最近一直在思考一个问题，因为看到越来越多的大模型发布，能力都很强。模型的 AGI 肯定在肉眼可见的未来会到来。最近龙虾很火，龙虾我们留到下一期再说。模型的能力越来越大、越来越强，那么人的价值到底在哪里？神现在哪里？这其实是现在很多人都在思考的问题：人怎么样能跟这些强大的模型一起工作或者共存？
我思考了很久，也看了很多 KOL 的观点。大家都比较着重于这个方面：
- 提出问题的能力远远比解决问题的能力更重要。因为模型太强大了，它有很多知识，学习知识的速度又很快。训练几个月就能掌握最新的知识，甚至不用重新训练，直接搜索到最新的信息。凭借强大的能力，它能很容易理解并用这些新知识帮助你解决问题。在解决问题方面，人类基本上比不过模型。
- 提出问题的能力不仅比解决问题的能力更强，实际上比验证问题还要更加重要。
也就是说，模型基本上会帮助我们完成从“人发现问题”到“人提出问题”之后的环节。所以说，整个环路应该是这样：当人发现了一些问题，然后提出正确的问题，模型就会自动去帮你解决问题。同时，模型也会根据你的要求来验证问题是否解决，就像我们现在用的 Coding Agent 一样。你想让它做什么，这是你提出的一个目标，但你怎么让它去验证这个目标到底完成了没有呢？因为你也怕它出现幻觉，然后假装做完了。所以你要给它提出一些验收的标准，也就是测试标准。
所以，基本上是这样设计的。因此，**提出问题的能力仍然是最重要的能力**。其次，就是人跟现实世界交互的能力。短期内，机器人是不太可能普及的，对吧？现在是文本模型突破了人类智力的一个奇点，但对于机器人来讲，它的商业化以及落地要更久。等到真正出现物理世界上的奇点突破时，那估计要好多年以后。虽然说现在看到有像春晚的宇树机器人跳舞表演，每年感觉都是以好几倍的速度在迭代，但实际上，一方面这些机器人非常贵，另一方面，最关键的是，这些机器人经过的是专门、垂直的训练。你想让它作为一个通用的机器人，像当年的 GPT 一样出现，那么在这点上，其实都还不太看得到。
另外一点我想到的是，从早期的职业生涯来讲，我们一直在讨论人到底是要做垂直的专业人才，还是做个通才？也就是你到底是看重深度还是广度。现在呢，这个情况可能会发生一些变化。因为在之前，我们基本上都是做深度的工作，对吧？每个人都想往专家的方向走，但他是某个领域的专家，比如前端有前端的专家，后端有后端的专家，还有数据库的专家等等。但是现在，可能因为 AI 模型的强大，情况会发生一些变化。
我自己的观点是，我们应该更多地尝试一些广度的东西。也就是说，你要知道那些东西的存在。因为如果你不知道，其实很难去借助 AI 的能力。你相当于是要去触发它思考。如果你不知道这些东西，会花你很长的时间。而且当你知道有很多广度的事情时，你会更容易问出问题——不一定是能提出很好、很正确的问题，但你一定能够很容易地去问出一些问题来。当然，深度也不是不必要。
因为要把一些领域内的事情做好，在目前来看，深度的结果还是很有必要的。但是现在有所谓的“技能”出现，就是大家可以把一些做事的工作流、行业知识，包装成一个个的技能包。也就是说，现在有点像只要提供这个技能包，那么所有的AI 模型都是一样的。那么，深度的方式可能会以另外一种方式来展现：除非是你经常能发现一些行业上的积累和经验，然后做成自己的一个工具包或技能包。
但是，对于我们来讲，技能的培养，或者说你知道这是一个有效的技能，其实要花费很长的时间。然而，技能的传播是很快的，基本上就是一个复制粘贴，所有人就都有了。
所以在这种情况下，我觉得深度的方式更多是说，你可能会把一些很复杂的工作流拆成很多小的步骤，然后在你脑海里面，你能够知道这是一个最好的方式，把它们串起来，完成工作的一种思路。那么，你很有可能就是在操纵多个AI Agent 来做这样的事情。这是多 agent 能力的运用。
最近一直在思考一个问题，因为看到越来越多的大模型发布，能力都很强。模型的 AGI 肯定在肉眼可见的未来会到来。最近龙虾很火，龙虾我们留到下一期再说。模型的能力越来越大、越来越强，那么人的价值到底在哪里？神现在哪里？这其实是现在很多人都在思考的问题：人怎么样能跟这些强大的模型一起工作或者共存？
我思考了很久，也看了很多 KOL 的观点。大家都比较着重于这个方面：
- 提出问题的能力远远比解决问题的能力更重要。因为模型太强大了，它有很多知识，学习知识的速度又很快。训练几个月就能掌握最新的知识，甚至不用重新训练，直接搜索到最新的信息。凭借强大的能力，它能很容易理解并用这些新知识帮助你解决问题。在解决问题方面，人类基本上比不过模型。
- 提出问题的能力不仅比解决问题的能力更强，实际上比验证问题还要更加重要。
也就是说，模型基本上会帮助我们完成从“人发现问题”到“人提出问题”之后的环节。所以说，整个环路应该是这样：当人发现了一些问题，然后提出正确的问题，模型就会自动去帮你解决问题。同时，模型也会根据你的要求来验证问题是否解决，就像我们现在用的 Coding Agent 一样。你想让它做什么，这是你提出的一个目标，但你怎么让它去验证这个目标到底完成了没有呢？因为你也怕它出现幻觉，然后假装做完了。所以你要给它提出一些验收的标准，也就是测试标准。
所以，基本上是这样设计的。因此，**提出问题的能力仍然是最重要的能力**。其次，就是人跟现实世界交互的能力。短期内，机器人是不太可能普及的，对吧？现在是文本模型突破了人类智力的一个奇点，但对于机器人来讲，它的商业化以及落地要更久。等到真正出现物理世界上的奇点突破时，那估计要好多年以后。虽然说现在看到有像春晚的宇树机器人跳舞表演，每年感觉都是以好几倍的速度在迭代，但实际上，一方面这些机器人非常贵，另一方面，最关键的是，这些机器人经过的是专门、垂直的训练。你想让它作为一个通用的机器人，像当年的 GPT 一样出现，那么在这点上，其实都还不太看得到。
另外一点我想到的是，从早期的职业生涯来讲，我们一直在讨论人到底是要做垂直的专业人才，还是做个通才？也就是你到底是看重深度还是广度。现在呢，这个情况可能会发生一些变化。因为在之前，我们基本上都是做深度的工作，对吧？每个人都想往专家的方向走，但他是某个领域的专家，比如前端有前端的专家，后端有后端的专家，还有数据库的专家等等。但是现在，可能因为 AI 模型的强大，情况会发生一些变化。
我自己的观点是，我们应该更多地尝试一些广度的东西。也就是说，你要知道那些东西的存在。因为如果你不知道，其实很难去借助 AI 的能力。你相当于是要去触发它思考。如果你不知道这些东西，会花你很长的时间。而且当你知道有很多广度的事情时，你会更容易问出问题——不一定是能提出很好、很正确的问题，但你一定能够很容易地去问出一些问题来。当然，深度也不是不必要。
因为要把一些领域内的事情做好，在目前来看，深度的结果还是很有必要的。但是现在有所谓的“技能”出现，就是大家可以把一些做事的工作流、行业知识，包装成一个个的技能包。也就是说，现在有点像只要提供这个技能包，那么所有的AI 模型都是一样的。那么，深度的方式可能会以另外一种方式来展现：除非是你经常能发现一些行业上的积累和经验，然后做成自己的一个工具包或技能包。
但是，对于我们来讲，技能的培养，或者说你知道这是一个有效的技能，其实要花费很长的时间。然而，技能的传播是很快的，基本上就是一个复制粘贴，所有人就都有了。
所以在这种情况下，我觉得深度的方式更多是说，你可能会把一些很复杂的工作流拆成很多小的步骤，然后在你脑海里面，你能够知道这是一个最好的方式，把它们串起来，完成工作的一种思路。那么，你很有可能就是在操纵多个AI Agent 来做这样的事情。这是多 agent 能力的运用。
0 10
Anthropic Agent Teams功能体验与价值分析
过去两天我体验了一下Anthropic，发现它提供了一个实验性功能叫做Agent Teams。这个功能其实很有想法。在早期的时候，Claude Code 只提供了 Sub-Agent，对吧？Sub-Agent 实际上可以并行开启几个，目的是在并行时代最大化并行来提高效率。
不过，Sub-Agent 之间是不能通讯的。而 Anthropic 真正提出的是以团队为概念，团队内的每个成员实际上可以相互沟通。这就很不一样了，因为在我们的很多工作当中，一个团队不能只和老板沟通，还必须和同事沟通。
所以，Agent Team 解决的问题虽然和之前一样，都是通过并行提升效率，但它在添加了 Agent 之间可以相互讨论和做决定之后，带来了另外一个维度的提升。也就是说，它做的事情更加稳定和准确，质量相对更高了。
这是我在体验了两天 Agent Team 功能后，看到的一个明显价值。
当然，从Agent Team能做什么出发，我们作为程序员，那就是开发代码、开发功能。我也是这么去尝试的。
在开启这个实验性功能后，我配置了MiniMax的M 2.5，也尝试使用了字节的豆包 SeedCode来测试不同的模型。我同样给了它一个应用去开发。
我发现它带来了另一个感受：当你创建了一个团队，并赋予每个成员不同的角色（即他们的职责）之后，它真的能够长时间运行，直到任务完成为止。
其背后的实现原理，实际上还是通过Team Leader来创建一个共享的 Task List。这很像以前我们单兵作战时，也会有一个计划、一个功能清单。然后拆分任务后分给下面的人。Team Leader同时还负责协调。但是，像前端与后端的集成，就让他们自己去沟通完成。
因为他们之间会自己通讯，通过这样的方式，你会发现，对于长时间运行来完成功能这件事情本身，似乎已经被解决了。
只要你的token足够多，那么它就可以持续运行一天、两天或三天。这就像为什么Anthropic在发布Opus 4.6的时候提到，他们让整个团队去开发一个十万行的C编译器。他们干了两周，但花费也很高，大约两万美金。
然后，我在测试一个本地应用的时候，我让他从头开始开发一个英语学习的本地Electron应用。我和他聊的需求基本方式上没变：我要做什么样的功能，他来问我细节，然后我们讨论，最终讨论出一个计划。
有了这个计划，确定了要做的功能列表之后，就可以启动整个Agent团队。这个团队的Team Leader会自动地给你拆分和分工：前端做什么？后端做什么？QA做什么？我这个团队里还有产品经理。
我发现一个特别有意思的事情：在整个开发过程中，前期只需要产品经理，但进入开发阶段后，产品经理就一直在等待任务，可能最闲的就是他了。而前端、后端和QA则特别忙。但在真实的场景当中，我们并不是这样的，因为Team Leader也可以写代码，产品经理也可以帮忙测试。
所以，它里面也提供了一种模式：如果你发现 Team Leader 在写代码，那么你可以让他不写代码。因为他一旦写代码了，他就很难去分配任务了。然后，你也可以让他做成一个委托模式（delegation）。这样的话，他可以专注于协调各个成员。
但是这样看下来，就会变成 PM 和那个 Team Leader 在大多数时间是空闲的。空闲的时候他只能发呆，实际上他是在等待，但也是在消耗一些 token。
所以在真实的场景下，我觉得更好的方式是：不管是谁，PM 也可以去做验证，对吧？你可以去验收产品，那相当于可以减少一个 QA。然后 Team Leader 也可以去写部分的代码。实际上，这才是真实的一个研发团队。
但是，Agent Team 不仅仅只能做这个，对吧？你可以组建一个小组去做一些 research。比如说，你想去研究一个主题，那么你可以设置不同的角色，他们可以相互去辩论，因为他们 Agent 之间可以相互通讯了。
当然，你也可以做并行的一些工作，因为它本身最大的价值就体现在它可以并行执行。你可以让它并行去 review 一些 code。我看到了一个例子：在我们的后端开发中，我们基本上是微服务架构。在微服务架构中，你有很多微服务，当你改一个功能时，可能需要改动好几个微服务。那么你也可以让它并行去处理这些改动。
每个微服务有它对应的一个 Agent。当你开发一个功能时，它们可以自行调整好各自的接口，这样效率就更高了。
因此，可以看到它能够产生的价值主要体现在：
- 并行处理
- 相互沟通，从而提升质量
- 能够稳定地长时间运行
这就是它带来的最大价值。
过去两天我体验了一下Anthropic，发现它提供了一个实验性功能叫做Agent Teams。这个功能其实很有想法。在早期的时候，Claude Code 只提供了 Sub-Agent，对吧？Sub-Agent 实际上可以并行开启几个，目的是在并行时代最大化并行来提高效率。
不过，Sub-Agent 之间是不能通讯的。而 Anthropic 真正提出的是以团队为概念，团队内的每个成员实际上可以相互沟通。这就很不一样了，因为在我们的很多工作当中，一个团队不能只和老板沟通，还必须和同事沟通。
所以，Agent Team 解决的问题虽然和之前一样，都是通过并行提升效率，但它在添加了 Agent 之间可以相互讨论和做决定之后，带来了另外一个维度的提升。也就是说，它做的事情更加稳定和准确，质量相对更高了。
这是我在体验了两天 Agent Team 功能后，看到的一个明显价值。
当然，从Agent Team能做什么出发，我们作为程序员，那就是开发代码、开发功能。我也是这么去尝试的。
在开启这个实验性功能后，我配置了MiniMax的M 2.5，也尝试使用了字节的豆包 SeedCode来测试不同的模型。我同样给了它一个应用去开发。
我发现它带来了另一个感受：当你创建了一个团队，并赋予每个成员不同的角色（即他们的职责）之后，它真的能够长时间运行，直到任务完成为止。
其背后的实现原理，实际上还是通过Team Leader来创建一个共享的 Task List。这很像以前我们单兵作战时，也会有一个计划、一个功能清单。然后拆分任务后分给下面的人。Team Leader同时还负责协调。但是，像前端与后端的集成，就让他们自己去沟通完成。
因为他们之间会自己通讯，通过这样的方式，你会发现，对于长时间运行来完成功能这件事情本身，似乎已经被解决了。
只要你的token足够多，那么它就可以持续运行一天、两天或三天。这就像为什么Anthropic在发布Opus 4.6的时候提到，他们让整个团队去开发一个十万行的C编译器。他们干了两周，但花费也很高，大约两万美金。
然后，我在测试一个本地应用的时候，我让他从头开始开发一个英语学习的本地Electron应用。我和他聊的需求基本方式上没变：我要做什么样的功能，他来问我细节，然后我们讨论，最终讨论出一个计划。
有了这个计划，确定了要做的功能列表之后，就可以启动整个Agent团队。这个团队的Team Leader会自动地给你拆分和分工：前端做什么？后端做什么？QA做什么？我这个团队里还有产品经理。
我发现一个特别有意思的事情：在整个开发过程中，前期只需要产品经理，但进入开发阶段后，产品经理就一直在等待任务，可能最闲的就是他了。而前端、后端和QA则特别忙。但在真实的场景当中，我们并不是这样的，因为Team Leader也可以写代码，产品经理也可以帮忙测试。
所以，它里面也提供了一种模式：如果你发现 Team Leader 在写代码，那么你可以让他不写代码。因为他一旦写代码了，他就很难去分配任务了。然后，你也可以让他做成一个委托模式（delegation）。这样的话，他可以专注于协调各个成员。
但是这样看下来，就会变成 PM 和那个 Team Leader 在大多数时间是空闲的。空闲的时候他只能发呆，实际上他是在等待，但也是在消耗一些 token。
所以在真实的场景下，我觉得更好的方式是：不管是谁，PM 也可以去做验证，对吧？你可以去验收产品，那相当于可以减少一个 QA。然后 Team Leader 也可以去写部分的代码。实际上，这才是真实的一个研发团队。
但是，Agent Team 不仅仅只能做这个，对吧？你可以组建一个小组去做一些 research。比如说，你想去研究一个主题，那么你可以设置不同的角色，他们可以相互去辩论，因为他们 Agent 之间可以相互通讯了。
当然，你也可以做并行的一些工作，因为它本身最大的价值就体现在它可以并行执行。你可以让它并行去 review 一些 code。我看到了一个例子：在我们的后端开发中，我们基本上是微服务架构。在微服务架构中，你有很多微服务，当你改一个功能时，可能需要改动好几个微服务。那么你也可以让它并行去处理这些改动。
每个微服务有它对应的一个 Agent。当你开发一个功能时，它们可以自行调整好各自的接口，这样效率就更高了。
因此，可以看到它能够产生的价值主要体现在：
- 并行处理
- 相互沟通，从而提升质量
- 能够稳定地长时间运行
这就是它带来的最大价值。
1 00
人工智能软件开发的第三时代开启了。
Michael，Cursor 的一号位最近发布了一篇博客，讲的是人工智能软件开发的第三时代已经来临了。他在这篇博客里精确定义了AI智能软件开发的三个时代，分别是什么？因为我在最早Claude Sonnet 3.5变得非常可用的时候，就开始用了Cursor，所以基本上我也完整经历过了这三个时代。现在是第三个时代刚刚开启。
他定义的第一个时代叫做Tab补全。这个有点像你原先是手写代码，后来换了一个IDE，比如说像Jetbrain。它能够根据你的上下文很快地补全一些代码。以前的IDE不帮你写代码，只是补全一些函数名，或者是括号等内容。但在Cursor的第一时代，Tab补全实际上可以帮你写一些基本的函数和不太复杂的类。通过这种方式，你会发现它变得非常可用，极大提升了效率。但重点在于，开发的主导权还是在开发者手里，AI只是辅助你写代码。
即使是这样，它还是极大地提升了开发效率。之前我在用Cursor的时候，感觉开发效率的提升可能都超过了 100%。
接着，就进入了第二个时代。第二个时代，他们叫做“同步的Agent”，也就是说，还是以人为主导。但是，它会慢慢地让你少写很多代码。或者说，基本上从这个时代开始，我就开始不怎么写代码了。
我转变成了去定义一个局部的函数。我告诉它我这个函数的目的应该是什么，或者我这个类的目的应该是什么，以及它的限制条件和验收标准是什么。我会先想好这些。
在做一个很大的功能之前，我肯定会先把它拆分成可能5到10个不同小任务，然后每个任务逐一去完成。那么对于同步的Agent来讲，它实际上很好地帮助了我：我已经拆分好任务了，对于这些小的任务，我只要定义好它的目标以及验收标准，那么它实际上就很容易地帮我完整实现这个功能。
在这个过程中，我完全不需要去写代码，甚至不用去敲Tab键。在这个第二个时代，基本上就开始让人觉得，我根本不需要写代码。
所以，这也就促进了很多资深工程师，每一天可以提交几十个或上百个 commit。因为他只需要去定义好这些子问题和子任务，那么 AI 会帮他完整地实现。因为子任务的范围相对比较小，也比较集中，甚至有些不需要跨模块、跨文件去修改。在这种情况下，它完成的准确度还是很高的。
所以，基本上很多时候，如果你用现在比较强大的模型，比如说 OpenAI 的 GPT-5 或 Claude 4.5 来写的话，那么它的准确度是极高的，基本上就是一次过。它写的单元测试和集成测试也是一次过。所以你就很放心了，每天你可能就是一直在跟它强调、给它布置不同的子任务，它最后都给你生成好。最后，你可能只需要去做 review，然后做一个最后的集成工作，再来验收一下，可能就结束了。
但是在这个过程中，人还是要参与的。所以这就是为什么说，使用同步的 Agent，还是让你进入到一个无限的 prompt 和 response 的循环里面，你不断在循环，一直到这个任务结束。
然后，接着这两个阶段，实际上对于Tab 的阶段来讲，对于Tab 的阶段来讲，它实际上大概跨越了两年。但是对于A的阶段来讲，很有可能就一年都不到，然后马上就开启了第三个阶段。
第三个阶段就是现在大家都在做的，就是说它从构建功能或者构建子功能，到现在它能够去构建一个完整的系统。所以之前在 Claude Opus 4.6 发布的时候，它直接提出来的一点就是，它可以让这个模型无间断地工作两周，然后能写出一个10万行的C的编译器。那么这个就变成它已经从构建一些子功能，到开始构建整个系统了。
这对人的要求来讲也是最高的，也就是说，你要怎么样能够完整地定义好和拆分好这些任务，然后它才能够去逐步地按照你的一个清单去做。这有点像之前我在分享的，就是说实际上你也可以用那个Ralph Loop，就是你可以定义好一个feature list，然后它能够一步一步按照你原先定义的方式去做。这样的话，你可以把整个工作都交给它，交给云端，你不用去管，一直到他可能干了两天两夜以后，然后你才能拿到第一个结果，然后你再去真正地去验收和测试。
所以，这个对人的要求会非常非常高，同时呢，它对于整个基础设施的要求也会很高。
因为你需要有云端的服务器，甚至有云端的浏览器。然后，当你发现有错误的时候，你怎么能够让它重新再跑？这些都是需要考虑的。
但是，对于Michael 来讲，他认为已经开启了第三时代。那么从今年开始，从现在开始往后的一年，绝大多数的工作可能都会通过这种Cloud Agent来直接实现。
在这个过程中，这种Cloud Agent有三个特性：
1. Agent肯定是写百分之百的代码了，人不需要在中间打断它、跟它交互。因为你只有看到结果，也就是它定义的“工件”（artifact）出来以后，你才能够有跟它对话的机会。
2. 人的价值应该体现在哪里？人的价值应该体现在第二步，就是你要花很多的时间先去拆解问题，然后你要去最后Review它的输出，甚至你要提供反馈。也就是说，哪怕它变成了完全自动化在云端跑，你还是需要进入一个可能间隔时间更长一点的循环（loop）。比如，它出来一个输出、一个工件，然后你需要去Review。Review完，你给它一些反馈，然后它再重新启动它的工作。它还是会进入这样一个循环当中的。
但人的第二个工作，就是你能拆解问题。你要去想怎么更好地拆分任务，然后能够同时开启多个Agent，以并行化的方式去做。所以，人的价值应该体现在这两点上面。但不管怎样，这肯定就是一个新的软件开发流程了，你只能去拥抱它。
Michael，Cursor 的一号位最近发布了一篇博客，讲的是人工智能软件开发的第三时代已经来临了。他在这篇博客里精确定义了AI智能软件开发的三个时代，分别是什么？因为我在最早Claude Sonnet 3.5变得非常可用的时候，就开始用了Cursor，所以基本上我也完整经历过了这三个时代。现在是第三个时代刚刚开启。
他定义的第一个时代叫做Tab补全。这个有点像你原先是手写代码，后来换了一个IDE，比如说像Jetbrain。它能够根据你的上下文很快地补全一些代码。以前的IDE不帮你写代码，只是补全一些函数名，或者是括号等内容。但在Cursor的第一时代，Tab补全实际上可以帮你写一些基本的函数和不太复杂的类。通过这种方式，你会发现它变得非常可用，极大提升了效率。但重点在于，开发的主导权还是在开发者手里，AI只是辅助你写代码。
即使是这样，它还是极大地提升了开发效率。之前我在用Cursor的时候，感觉开发效率的提升可能都超过了 100%。
接着，就进入了第二个时代。第二个时代，他们叫做“同步的Agent”，也就是说，还是以人为主导。但是，它会慢慢地让你少写很多代码。或者说，基本上从这个时代开始，我就开始不怎么写代码了。
我转变成了去定义一个局部的函数。我告诉它我这个函数的目的应该是什么，或者我这个类的目的应该是什么，以及它的限制条件和验收标准是什么。我会先想好这些。
在做一个很大的功能之前，我肯定会先把它拆分成可能5到10个不同小任务，然后每个任务逐一去完成。那么对于同步的Agent来讲，它实际上很好地帮助了我：我已经拆分好任务了，对于这些小的任务，我只要定义好它的目标以及验收标准，那么它实际上就很容易地帮我完整实现这个功能。
在这个过程中，我完全不需要去写代码，甚至不用去敲Tab键。在这个第二个时代，基本上就开始让人觉得，我根本不需要写代码。
所以，这也就促进了很多资深工程师，每一天可以提交几十个或上百个 commit。因为他只需要去定义好这些子问题和子任务，那么 AI 会帮他完整地实现。因为子任务的范围相对比较小，也比较集中，甚至有些不需要跨模块、跨文件去修改。在这种情况下，它完成的准确度还是很高的。
所以，基本上很多时候，如果你用现在比较强大的模型，比如说 OpenAI 的 GPT-5 或 Claude 4.5 来写的话，那么它的准确度是极高的，基本上就是一次过。它写的单元测试和集成测试也是一次过。所以你就很放心了，每天你可能就是一直在跟它强调、给它布置不同的子任务，它最后都给你生成好。最后，你可能只需要去做 review，然后做一个最后的集成工作，再来验收一下，可能就结束了。
但是在这个过程中，人还是要参与的。所以这就是为什么说，使用同步的 Agent，还是让你进入到一个无限的 prompt 和 response 的循环里面，你不断在循环，一直到这个任务结束。
然后，接着这两个阶段，实际上对于Tab 的阶段来讲，对于Tab 的阶段来讲，它实际上大概跨越了两年。但是对于A的阶段来讲，很有可能就一年都不到，然后马上就开启了第三个阶段。
第三个阶段就是现在大家都在做的，就是说它从构建功能或者构建子功能，到现在它能够去构建一个完整的系统。所以之前在 Claude Opus 4.6 发布的时候，它直接提出来的一点就是，它可以让这个模型无间断地工作两周，然后能写出一个10万行的C的编译器。那么这个就变成它已经从构建一些子功能，到开始构建整个系统了。
这对人的要求来讲也是最高的，也就是说，你要怎么样能够完整地定义好和拆分好这些任务，然后它才能够去逐步地按照你的一个清单去做。这有点像之前我在分享的，就是说实际上你也可以用那个Ralph Loop，就是你可以定义好一个feature list，然后它能够一步一步按照你原先定义的方式去做。这样的话，你可以把整个工作都交给它，交给云端，你不用去管，一直到他可能干了两天两夜以后，然后你才能拿到第一个结果，然后你再去真正地去验收和测试。
所以，这个对人的要求会非常非常高，同时呢，它对于整个基础设施的要求也会很高。
因为你需要有云端的服务器，甚至有云端的浏览器。然后，当你发现有错误的时候，你怎么能够让它重新再跑？这些都是需要考虑的。
但是，对于Michael 来讲，他认为已经开启了第三时代。那么从今年开始，从现在开始往后的一年，绝大多数的工作可能都会通过这种Cloud Agent来直接实现。
在这个过程中，这种Cloud Agent有三个特性：
1. Agent肯定是写百分之百的代码了，人不需要在中间打断它、跟它交互。因为你只有看到结果，也就是它定义的“工件”（artifact）出来以后，你才能够有跟它对话的机会。
2. 人的价值应该体现在哪里？人的价值应该体现在第二步，就是你要花很多的时间先去拆解问题，然后你要去最后Review它的输出，甚至你要提供反馈。也就是说，哪怕它变成了完全自动化在云端跑，你还是需要进入一个可能间隔时间更长一点的循环（loop）。比如，它出来一个输出、一个工件，然后你需要去Review。Review完，你给它一些反馈，然后它再重新启动它的工作。它还是会进入这样一个循环当中的。
但人的第二个工作，就是你能拆解问题。你要去想怎么更好地拆分任务，然后能够同时开启多个Agent，以并行化的方式去做。所以，人的价值应该体现在这两点上面。但不管怎样，这肯定就是一个新的软件开发流程了，你只能去拥抱它。
2 00
几个Claude Code的使用技巧。
虽然一直在使用 Claude Code 开发软件，随着使用得越来越多，也看到大家分享的技巧越来越多。今天看到一些分享，突然发现其实有些技巧还蛮有用的，但平时自己在开发或者实现功能时，反而用得比较少。这里有几个技巧实际上相对来说蛮有用，可以在日常开发中尽量使用，提高开发效率。
第一个技巧：双击 ESC 键
- 当我们让 Claude Code 执行某个任务时，和它对话时可能会说错话、给错指令，或者对它的回答不满意。它会以流式方式告诉你正在做什么。如果发现它好像走错了，很多时候我们只会单击一次 ESC 键，这只是暂停当前工作，不能让它“时光倒流”。
- 如果双击 ESC 键，它实际上会回到这次对话之前的上一次对话状态，这样你就可以重新组织语言，让它按照你的方式开发新的功能。
- 需要注意的是，如果它已经修改了一些代码文件，需要通过 git 的方式回退（reset），恢复文件的初始状态。
因为双击 ESC 键，它仅仅只是回退到对话历史记录的上一次，这样就不会把取消的那一次对话，直接送到 Claude Code 的上下文当中。这是第一个技巧。
第二个技巧，大家用的相对会比较少。就是有些时候我们在使用时，需要去执行一些终端的命令。那么，你就可以通过感叹号，然后执行一个命令的方式，直接在当前的 Claude Code 窗口运行这个命令，不用像之前一样，需要重新打开一个终端的窗口，然后在那边运行命令。那边如果有了一些错误，你可能还要再复制回来。这样的话，就很容易让你在运行完命令后，直接分析这次测试失败的原因是什么，然后可以让他来修复代码。
第三个技巧是节约 token 的技巧。我们平时都知道，当你在使用 Claude Code 开发一个功能的时候，你可以通过 `context` 命令去查看当前送给模型的上下文包含了什么内容，然后你可以去调优。但是我们知道，当我们让 Claude Code 在做一些事情的时候，有很多时候有些文件是不需要被搜索和读到上下文当中的。比如说，你生成的一些文件，构建出来的一些文件，比如 `build` 里面的文件，`dist` 里面的文件，甚至你安装的一些依赖包。
甚至是对于一些包含敏感信息的文件，比如包含环境变量的文件，或者像日志文件这类实际上不需要让 Claude Code 去搜索或读取到上下文中来回答用户问题的文件，你可以通过添加一个 `.claudeignore` 文件来配置。它非常像 `.gitignore` 文件，你可以在里面配置你需要忽略的目录或文件。配置在这个文件里的内容，无论是目录还是文件，都不会被 Claude Code 加载到它的上下文当中。
最后一个技巧是，Claude Code 的指令有点像管道，可以通过链式调用的方式组合起来。举个简单的例子：当我们在开发一个新功能时，可以先用 `/plan` 命令说“我要添加一个购物车的功能”，等它生成计划后，再用它创建一个分支。接着在这个新分支上，按照原定计划逐步实现功能，然后进行测试。测试时，可以通过 `!npm test` 的方式来运行测试。最后，可以通过 `/review` 命令进行代码审查。审查通过后，再通过 `/commit` 命令提交代码。
最后，可以通过 `/commit` 命令来提交代码，然后通过 `git push` 将其推送到远程仓库。从这个流程可以看出，它实际上是把 Cloud Code 的一些预先定义的命令、开发新功能的工作流、进行代码审查的命令，以及你自己要执行的自定义命令，全部整合在了一次用户提示中，而不是拆分成多个步骤。如果你能善用这些技巧，将能显著提升你在某些方面的软件开发效率。
虽然一直在使用 Claude Code 开发软件，随着使用得越来越多，也看到大家分享的技巧越来越多。今天看到一些分享，突然发现其实有些技巧还蛮有用的，但平时自己在开发或者实现功能时，反而用得比较少。这里有几个技巧实际上相对来说蛮有用，可以在日常开发中尽量使用，提高开发效率。
第一个技巧：双击 ESC 键
- 当我们让 Claude Code 执行某个任务时，和它对话时可能会说错话、给错指令，或者对它的回答不满意。它会以流式方式告诉你正在做什么。如果发现它好像走错了，很多时候我们只会单击一次 ESC 键，这只是暂停当前工作，不能让它“时光倒流”。
- 如果双击 ESC 键，它实际上会回到这次对话之前的上一次对话状态，这样你就可以重新组织语言，让它按照你的方式开发新的功能。
- 需要注意的是，如果它已经修改了一些代码文件，需要通过 git 的方式回退（reset），恢复文件的初始状态。
因为双击 ESC 键，它仅仅只是回退到对话历史记录的上一次，这样就不会把取消的那一次对话，直接送到 Claude Code 的上下文当中。这是第一个技巧。
第二个技巧，大家用的相对会比较少。就是有些时候我们在使用时，需要去执行一些终端的命令。那么，你就可以通过感叹号，然后执行一个命令的方式，直接在当前的 Claude Code 窗口运行这个命令，不用像之前一样，需要重新打开一个终端的窗口，然后在那边运行命令。那边如果有了一些错误，你可能还要再复制回来。这样的话，就很容易让你在运行完命令后，直接分析这次测试失败的原因是什么，然后可以让他来修复代码。
第三个技巧是节约 token 的技巧。我们平时都知道，当你在使用 Claude Code 开发一个功能的时候，你可以通过 `context` 命令去查看当前送给模型的上下文包含了什么内容，然后你可以去调优。但是我们知道，当我们让 Claude Code 在做一些事情的时候，有很多时候有些文件是不需要被搜索和读到上下文当中的。比如说，你生成的一些文件，构建出来的一些文件，比如 `build` 里面的文件，`dist` 里面的文件，甚至你安装的一些依赖包。
甚至是对于一些包含敏感信息的文件，比如包含环境变量的文件，或者像日志文件这类实际上不需要让 Claude Code 去搜索或读取到上下文中来回答用户问题的文件，你可以通过添加一个 `.claudeignore` 文件来配置。它非常像 `.gitignore` 文件，你可以在里面配置你需要忽略的目录或文件。配置在这个文件里的内容，无论是目录还是文件，都不会被 Claude Code 加载到它的上下文当中。
最后一个技巧是，Claude Code 的指令有点像管道，可以通过链式调用的方式组合起来。举个简单的例子：当我们在开发一个新功能时，可以先用 `/plan` 命令说“我要添加一个购物车的功能”，等它生成计划后，再用它创建一个分支。接着在这个新分支上，按照原定计划逐步实现功能，然后进行测试。测试时，可以通过 `!npm test` 的方式来运行测试。最后，可以通过 `/review` 命令进行代码审查。审查通过后，再通过 `/commit` 命令提交代码。
最后，可以通过 `/commit` 命令来提交代码，然后通过 `git push` 将其推送到远程仓库。从这个流程可以看出，它实际上是把 Cloud Code 的一些预先定义的命令、开发新功能的工作流、进行代码审查的命令，以及你自己要执行的自定义命令，全部整合在了一次用户提示中，而不是拆分成多个步骤。如果你能善用这些技巧，将能显著提升你在某些方面的软件开发效率。
23 010
Claude Code作者Boris访谈中说到，自从 opus 4.5 以来，他再也没写过一行代码了。
今天主要聊一下最近关于Claude Code作者Boris的一次访谈。看完他的采访视频后，我觉得有一些信息非常有启发性。
首先，Boris提到自从他开发出Claude Code之后，从Oppo 4.5版本开始，Claude Code的90%甚至接近100%的代码，都是由Claude Code自己生成的。也就是说，它已经达到了自我生成的阶段。由于 Claude Code已经完全用Claude Code来生成，这也导致所有代码都被反复重写过无数次。现在你看到的任何一个版本，都已经不是六个月前的任何一行代码了，所以迭代速度非常快。
这也解释了为什么以前我升级Claude Code时，可能很久才需要更新一次版本，但现在只要两三天不更新，等你再更新时，已经迭代了十几二十个小版本，速度非常快。
另外一个有启发的点是，关于什么是AGI，Boris以及Anthropic团队对AGI的理解也很值得关注。
AGI的实现路径，应该是先教会模型学习编程，然后再教会它使用工具，最后再教它使用电脑。这样子的话，就能够真正实现AGI，但同时又能够保证它的安全性。因为对于编程来讲，你是可以去限制它的，它是比较容易去限制的，就像是现在我们把程序放在一个完全独立的沙盒里面跑一样。你是很容易地限制它的网络、限制它的数据流通等方面，或者是限制它的一些权限的。所以这是Anthropic认为实现AGI最正确的一条路径，所以他们一直押注在编程上面。
关于使用工具，是很神奇的一点。他提到，之前在刚刚发布Claude Code、模型刚学会使用工具的时候，他就尝试了用集成的Bash工具。一旦集成了Bash工具，这是一个最纯粹的、最原始也最强大的一个模型了。因为Bash基本上能做任何事情，而且它长期以来已经积累了非常多的数据，准确度非常高。它能够写文件、读文件，能够执行各种Bash的命令来安装各种包，然后能够运行程序。所以模型加上Bash，就已经是一个非常强大的Agent了。
所以，当时在刚刚发布完工具以后，他有一天就集成了Bash工具，让模型来使用这个Bash工具。这时，他就随便问了一个问题，比如“我正在听什么音乐？”，他发现模型竟然能够写出一段脚本，然后去操纵他的Mac，查到他正在播放的是什么音乐。所以他认为，那是他第一个瞬间感觉到“这就是AGI”的时刻，一个“Aha moment”。
第三点启发是，我们经常说需要在`claudecode.md`文件里写上一些需要让模型关注的事情。但他自己的文件里，全部就两行，主要是针对PR的。他把大部分工程上的要求，可能都写到了一个整个团队的`claudecode.md`文件里。但对他个人的`claudecode.md`文件，实际上就两行：
1. 提交了PR就能够自动合并。
2. 提交了PR以后，它能够直接发布到内部的一些通讯工具，方便那边的同事快速审批，这样他就不用一直等待或者被卡住。
另外一点，我觉得这对于所有人来说可能都是比较愿意听到的：哪怕他是Claude Code 的创建者，哪怕他用的是最强大的模型Claude Opus，但他发现他还是需要不断地学习。
因为有时候他发现在做事时，由于思维惯性，还是会习惯性地用传统的软件开发方式去处理。他的思维有时还停留在六个月前。他在这篇访谈中反复提到“6个月”这个时间点，例如模型大概每6个月就会发生一次巨大的变化。所以，很多工作你做了，实际上6个月后可能会失效。这也有可能是他们内部模型发生巨大变化的一个迭代周期（目前是6个月，这是我猜测的）。
上次也讲到，未来可能没有“软件工程师”这种特定角色了，因为每个人都是一个“建造者”（builder），都能够创建任何产品和软件。
那么，对于技术人来说，最重要的技能是什么？
1. **保持初心**：要拥有“初学者心态”（beginner’s mindset），保持好奇，持续学习。
2. **保持谦逊**：因为模型会成长发展到远远超出你的地步，你在它面前可能会感到非常沮丧。这时就需要保持谦逊。接受自己不懂。
3. **从错误中学习**：我隐约觉得，他们现在内部开发过程中，都不是让系统完全自动化运行，而是在不断迭代。你发现错误，就能返回来重新修改。以这样的方式去构建软件，才是正确的。
另外，他们最后还提到，因为现在大家比较经常使用“计划模式”（Plan Mode）。用户每次让模型去构建的软件描述都太简单了，只有一两句话。但整个软件其实包含很多细节，包括用户流程、数据存储以及一些特殊需求。这些细节都隐藏在需求里，所以他们才开发出这个“计划模式”，希望用户在使用模型开发软件之前，能够先构思好方案。
但他自己也提出，这个模式未来可能不再需要了。在后续的模型迭代中，模型自己可能就能处理得很好，用户就不需要在模型和计划模式之间来回沟通了。我对这点还蛮期待的，但不太确定：如果很多细节都由模型按照其最佳实践自行实现，会不会丧失掉一些个性化的需求？
最后他也提到，自Claude Code 发布以来，基本上Anthropic（的功能）让每个人的效率提升了150%。结合我之前看到的，昆仑万维（国内一家公司）对其所有研发人员的要求是，无论从CTO到初级程序员，使用这类工具的效率提升目标都要达到50%，这是一个全员提升，非常吓人的一个数字。
他提到，自从有了 Claude Code 以来，他基本上已经把所有开发工具都卸载掉了，只保留了 Claude Code 这个终端工具。他自己也没有再亲手写过一行代码。
未来的开发就应该是这样。
今天主要聊一下最近关于Claude Code作者Boris的一次访谈。看完他的采访视频后，我觉得有一些信息非常有启发性。
首先，Boris提到自从他开发出Claude Code之后，从Oppo 4.5版本开始，Claude Code的90%甚至接近100%的代码，都是由Claude Code自己生成的。也就是说，它已经达到了自我生成的阶段。由于 Claude Code已经完全用Claude Code来生成，这也导致所有代码都被反复重写过无数次。现在你看到的任何一个版本，都已经不是六个月前的任何一行代码了，所以迭代速度非常快。
这也解释了为什么以前我升级Claude Code时，可能很久才需要更新一次版本，但现在只要两三天不更新，等你再更新时，已经迭代了十几二十个小版本，速度非常快。
另外一个有启发的点是，关于什么是AGI，Boris以及Anthropic团队对AGI的理解也很值得关注。
AGI的实现路径，应该是先教会模型学习编程，然后再教会它使用工具，最后再教它使用电脑。这样子的话，就能够真正实现AGI，但同时又能够保证它的安全性。因为对于编程来讲，你是可以去限制它的，它是比较容易去限制的，就像是现在我们把程序放在一个完全独立的沙盒里面跑一样。你是很容易地限制它的网络、限制它的数据流通等方面，或者是限制它的一些权限的。所以这是Anthropic认为实现AGI最正确的一条路径，所以他们一直押注在编程上面。
关于使用工具，是很神奇的一点。他提到，之前在刚刚发布Claude Code、模型刚学会使用工具的时候，他就尝试了用集成的Bash工具。一旦集成了Bash工具，这是一个最纯粹的、最原始也最强大的一个模型了。因为Bash基本上能做任何事情，而且它长期以来已经积累了非常多的数据，准确度非常高。它能够写文件、读文件，能够执行各种Bash的命令来安装各种包，然后能够运行程序。所以模型加上Bash，就已经是一个非常强大的Agent了。
所以，当时在刚刚发布完工具以后，他有一天就集成了Bash工具，让模型来使用这个Bash工具。这时，他就随便问了一个问题，比如“我正在听什么音乐？”，他发现模型竟然能够写出一段脚本，然后去操纵他的Mac，查到他正在播放的是什么音乐。所以他认为，那是他第一个瞬间感觉到“这就是AGI”的时刻，一个“Aha moment”。
第三点启发是，我们经常说需要在`claudecode.md`文件里写上一些需要让模型关注的事情。但他自己的文件里，全部就两行，主要是针对PR的。他把大部分工程上的要求，可能都写到了一个整个团队的`claudecode.md`文件里。但对他个人的`claudecode.md`文件，实际上就两行：
1. 提交了PR就能够自动合并。
2. 提交了PR以后，它能够直接发布到内部的一些通讯工具，方便那边的同事快速审批，这样他就不用一直等待或者被卡住。
另外一点，我觉得这对于所有人来说可能都是比较愿意听到的：哪怕他是Claude Code 的创建者，哪怕他用的是最强大的模型Claude Opus，但他发现他还是需要不断地学习。
因为有时候他发现在做事时，由于思维惯性，还是会习惯性地用传统的软件开发方式去处理。他的思维有时还停留在六个月前。他在这篇访谈中反复提到“6个月”这个时间点，例如模型大概每6个月就会发生一次巨大的变化。所以，很多工作你做了，实际上6个月后可能会失效。这也有可能是他们内部模型发生巨大变化的一个迭代周期（目前是6个月，这是我猜测的）。
上次也讲到，未来可能没有“软件工程师”这种特定角色了，因为每个人都是一个“建造者”（builder），都能够创建任何产品和软件。
那么，对于技术人来说，最重要的技能是什么？
1. **保持初心**：要拥有“初学者心态”（beginner’s mindset），保持好奇，持续学习。
2. **保持谦逊**：因为模型会成长发展到远远超出你的地步，你在它面前可能会感到非常沮丧。这时就需要保持谦逊。接受自己不懂。
3. **从错误中学习**：我隐约觉得，他们现在内部开发过程中，都不是让系统完全自动化运行，而是在不断迭代。你发现错误，就能返回来重新修改。以这样的方式去构建软件，才是正确的。
另外，他们最后还提到，因为现在大家比较经常使用“计划模式”（Plan Mode）。用户每次让模型去构建的软件描述都太简单了，只有一两句话。但整个软件其实包含很多细节，包括用户流程、数据存储以及一些特殊需求。这些细节都隐藏在需求里，所以他们才开发出这个“计划模式”，希望用户在使用模型开发软件之前，能够先构思好方案。
但他自己也提出，这个模式未来可能不再需要了。在后续的模型迭代中，模型自己可能就能处理得很好，用户就不需要在模型和计划模式之间来回沟通了。我对这点还蛮期待的，但不太确定：如果很多细节都由模型按照其最佳实践自行实现，会不会丧失掉一些个性化的需求？
最后他也提到，自Claude Code 发布以来，基本上Anthropic（的功能）让每个人的效率提升了150%。结合我之前看到的，昆仑万维（国内一家公司）对其所有研发人员的要求是，无论从CTO到初级程序员，使用这类工具的效率提升目标都要达到50%，这是一个全员提升，非常吓人的一个数字。
他提到，自从有了 Claude Code 以来，他基本上已经把所有开发工具都卸载掉了，只保留了 Claude Code 这个终端工具。他自己也没有再亲手写过一行代码。
未来的开发就应该是这样。
16 16