即刻App年轻人的同好社区
下载
这有点逆天了，codex 自己做了一个在 claude code 使用codex的插件。
突然发现在 claude code 里面已经可以直接调用 codex 了。之前其实一直也交叉在用这两个 coding agent，因为 claude code 确实强在代码编写，但是 codex（gpt 模型）主要强在代码 review 以及幻觉率和设计要更强一点。之前社区内的用法都是，同时在一个项目下面开启两个命令行窗口，一个是 cc，另一个是 codex，一边做完切换了到另一个命令行窗口，继续 codex 评审改动，查找 bug 以及修复。
不知道是奥特曼听到了社区的呼声还是自己能屈能伸，直接转头就做了一个claude code 的插件，方便用户直接在 cc 中调用 codex。这实在有点逆天。我今天就直接安装了这个插件，然后直接/codex:setup 检测一下是否可以用就可以开始了。
如果你仔细看看，codex 的 cc 插件，其实就支持了两个功能，一个是 code review，一个是 code review 后的 bug fix，它叫做 rescue。code review 本身分为两种， codex:review 就是一般功能完成后我们说的 code review，看看代码改动有什么错误，有什么没有考虑到的，有没有不符合最佳实践的等等，而另外一个 codex:adversarial-review, 那 review 的强度就上来了。
它都不是一般的 code review 了，它不仅 review 的方面更全、更深，甚至它还会挑战你改动代码的思路、方向可能全都错了。基本上就是从原理、本质上质疑你的改动。
不管是什么 review，做完后都需要修改，那就是一步到位的 codex:rescue, 妥妥的一个审阅 + 修复工作流，挺好用的。
突然发现在 claude code 里面已经可以直接调用 codex 了。之前其实一直也交叉在用这两个 coding agent，因为 claude code 确实强在代码编写，但是 codex（gpt 模型）主要强在代码 review 以及幻觉率和设计要更强一点。之前社区内的用法都是，同时在一个项目下面开启两个命令行窗口，一个是 cc，另一个是 codex，一边做完切换了到另一个命令行窗口，继续 codex 评审改动，查找 bug 以及修复。
不知道是奥特曼听到了社区的呼声还是自己能屈能伸，直接转头就做了一个claude code 的插件，方便用户直接在 cc 中调用 codex。这实在有点逆天。我今天就直接安装了这个插件，然后直接/codex:setup 检测一下是否可以用就可以开始了。
如果你仔细看看，codex 的 cc 插件，其实就支持了两个功能，一个是 code review，一个是 code review 后的 bug fix，它叫做 rescue。code review 本身分为两种， codex:review 就是一般功能完成后我们说的 code review，看看代码改动有什么错误，有什么没有考虑到的，有没有不符合最佳实践的等等，而另外一个 codex:adversarial-review, 那 review 的强度就上来了。
它都不是一般的 code review 了，它不仅 review 的方面更全、更深，甚至它还会挑战你改动代码的思路、方向可能全都错了。基本上就是从原理、本质上质疑你的改动。
不管是什么 review，做完后都需要修改，那就是一步到位的 codex:rescue, 妥妥的一个审阅 + 修复工作流，挺好用的。
0 00
后面的模型可能会越来越偏科，也可能会越来越有品味
月之暗面的创始人杨植麟最近有一个技术演讲，确实挺技术的，后半段的模型优化我基本没有理解。但是听完我第一个感受就是，模型后面要开始分化。
模型开始有着自己的偏好，有着自己的品味了。其实现在不同的模型已经开始有了，比如我们知道 Gemini 模型在 UI 前端工作就做的特别好。
但是听完了整个演讲，对于做应用开发的我还是有着不少的收获，毕竟是最前沿的思路。第一张图是，为什么 transformer 架构比 LSTM 要好？有两个维度的比较，一个是随着模型的参数越来越多（模型越来越大），为了让模型的性能更好，那么就必须要让 Loss 越小，从第一张图的第一个图表来看，LSTM 后续的 loss 一直下不去，曲线甚至要走平，不像 transformer 的曲线是平稳的下降，这就意味着 LSTM 需要更多的算力才行，不划算。
而第一张图的第二个图表表示的是，长上下文的支持。当上下文到了100个 token 的时候，LSTM 明显 loss 就下不去了。换个说法，如果超过100个 token 的长上下文，那么模型的性能就开始变差，导致幻觉了。
所以杨植麟觉得未来模型的发展方向是，往 token efficiency 和 long context 两个方向发展，token efficiency 越高，算力越省。长上下文越长，如果能保持每个 token 的 loss 也越低，那么意味了就能支持更长的上下文，能做更多的工作。（第二张图）
而第三张图有一句话很深刻，就是 agentic 推理本质上就是一个搜索。本来模型就是压缩的知识（之前用过模糊的图片来比喻），同时模型学习了内在的文本规律，所以可以让它以鲁迅的口吻来讲解化学概念。这个过程实际上就是搜索到鲁迅的文风，搜到化学概念，然后结合去生成。所以本质就是一种搜索，当然也可以在整个模型里面搜索，但是效率就低了，所以为了 token efficiency，那么搜索的方向就很重要。
对于长上下文，这个越来越重要的，现在记忆也成为了长上下文的一部分了，模型拥有的记忆越多，它就越能遵循你的指令做事，越懂你，不会刚做完某件事，转眼就忘记了，你又要重新跟它叨一遍。
而最后一张图，则关于品味，每个模型都不一样，就像是 Gemini 做的前端好看，minimax 做的差强人意，这也是一种品味，一种选择。如果你了解模型的原理，很难说这到底是不是一个刻意训练后的结果。
月之暗面的创始人杨植麟最近有一个技术演讲，确实挺技术的，后半段的模型优化我基本没有理解。但是听完我第一个感受就是，模型后面要开始分化。
模型开始有着自己的偏好，有着自己的品味了。其实现在不同的模型已经开始有了，比如我们知道 Gemini 模型在 UI 前端工作就做的特别好。
但是听完了整个演讲，对于做应用开发的我还是有着不少的收获，毕竟是最前沿的思路。第一张图是，为什么 transformer 架构比 LSTM 要好？有两个维度的比较，一个是随着模型的参数越来越多（模型越来越大），为了让模型的性能更好，那么就必须要让 Loss 越小，从第一张图的第一个图表来看，LSTM 后续的 loss 一直下不去，曲线甚至要走平，不像 transformer 的曲线是平稳的下降，这就意味着 LSTM 需要更多的算力才行，不划算。
而第一张图的第二个图表表示的是，长上下文的支持。当上下文到了100个 token 的时候，LSTM 明显 loss 就下不去了。换个说法，如果超过100个 token 的长上下文，那么模型的性能就开始变差，导致幻觉了。
所以杨植麟觉得未来模型的发展方向是，往 token efficiency 和 long context 两个方向发展，token efficiency 越高，算力越省。长上下文越长，如果能保持每个 token 的 loss 也越低，那么意味了就能支持更长的上下文，能做更多的工作。（第二张图）
而第三张图有一句话很深刻，就是 agentic 推理本质上就是一个搜索。本来模型就是压缩的知识（之前用过模糊的图片来比喻），同时模型学习了内在的文本规律，所以可以让它以鲁迅的口吻来讲解化学概念。这个过程实际上就是搜索到鲁迅的文风，搜到化学概念，然后结合去生成。所以本质就是一种搜索，当然也可以在整个模型里面搜索，但是效率就低了，所以为了 token efficiency，那么搜索的方向就很重要。
对于长上下文，这个越来越重要的，现在记忆也成为了长上下文的一部分了，模型拥有的记忆越多，它就越能遵循你的指令做事，越懂你，不会刚做完某件事，转眼就忘记了，你又要重新跟它叨一遍。
而最后一张图，则关于品味，每个模型都不一样，就像是 Gemini 做的前端好看，minimax 做的差强人意，这也是一种品味，一种选择。如果你了解模型的原理，很难说这到底是不是一个刻意训练后的结果。
1 11
微信还是接入了开源龙虾，入口之争不可失。
在微信宣布接入开源龙虾 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