即刻App年轻人的同好社区
下载
Siri AI好于预期，目测体验比Pixel上的gemini更简单更易普及到大众
虽然也没有很突破性的亮点，比如更彻底基于GenUI和多模态交互的Agentic OS
面向现实世界的视觉智能好像只在visionOS里讲了，在iPhone上（基于摄像头）没讲
Shortcuts相当于变成了vibe coding app和自定义Tool（基于工作流编排）生成器，不是像GenUI那样生成新GUI app，而是生成新的Tool，通过其他通用GUI（包括agent）来使用
完全没提第三方app怎么提供Tool接入Siri AI（说明还是靠之前的app intents），只此地无银三百两的强调app不用担心被AI取代、app会更多更好😂，只讲了提供Foundation Model和Core AI API给app用（这属于我一直唱衰的「把AI集成到现有软件里」的模式）
前面Craig还强调AI应该让人类生活更美好，这个倒是挺关键的，是消费者AI路线的重点，如果仅凭Anthropic这种短视路线，对AI天花板的拉低不仅会来自主动性的匮乏（只能靠有主动性的少数人/企业驱动海量agent，带来大量失业），也会来自大众的反动，美国大众现在反感AI的比例非常高（图2）
图3是可能是跳水原因…
虽然也没有很突破性的亮点，比如更彻底基于GenUI和多模态交互的Agentic OS
面向现实世界的视觉智能好像只在visionOS里讲了，在iPhone上（基于摄像头）没讲
Shortcuts相当于变成了vibe coding app和自定义Tool（基于工作流编排）生成器，不是像GenUI那样生成新GUI app，而是生成新的Tool，通过其他通用GUI（包括agent）来使用
完全没提第三方app怎么提供Tool接入Siri AI（说明还是靠之前的app intents），只此地无银三百两的强调app不用担心被AI取代、app会更多更好😂，只讲了提供Foundation Model和Core AI API给app用（这属于我一直唱衰的「把AI集成到现有软件里」的模式）
前面Craig还强调AI应该让人类生活更美好，这个倒是挺关键的，是消费者AI路线的重点，如果仅凭Anthropic这种短视路线，对AI天花板的拉低不仅会来自主动性的匮乏（只能靠有主动性的少数人/企业驱动海量agent，带来大量失业），也会来自大众的反动，美国大众现在反感AI的比例非常高（图2）
图3是可能是跳水原因…
2 00
其实生育率长期趋势的决定性因素只有一个：
女性的教育水平（广义，包含文化发展和信息传播）
斯宾格勒的《西方的没落》里有句话："Children do not happen, principally because intelligence at the peak of intensity can no longer find any reason for their existence"
图4是OurWorldInData创始人（牛津教授）写的一篇数据综述，可以印证我这个观点
女性的教育水平（广义，包含文化发展和信息传播）
斯宾格勒的《西方的没落》里有句话："Children do not happen, principally because intelligence at the peak of intensity can no longer find any reason for their existence"
图4是OurWorldInData创始人（牛津教授）写的一篇数据综述，可以印证我这个观点
3 00
作为股东，祝贺下 Cloudflare 收购了 「bun」（Web App Meta-framework + JS App Runtime）+「vercel」（Frontend PaaS）+「rspack」（Rust-based JS Toolchain）😌，向 Agentic Web Infra 或者说 Web-based Tool-use Infra 又前进一小步
9 00
我之前一直在说Anthropic当前的数据和完全依赖按量付费的路线不可持续，要小心波动
AI的To B或To D并不是已经完全跑通的灵丹妙药，其实和To C有一样的问题：
在C端，「把agent嵌入在现有软件里」的软件企业无法赚回新增的token成本，不得不「审慎克制」。如果按量付费，大多数C端个人用户也无法「赚回」在token上花的钱
需要由少数「把软件嵌入在agent里」里的通用agent企业，来支撑世界上大部分C端token花费，把coding agent/多模态agent隐藏到底层包装成不需要人类主动性也能带来大量token消耗的产品形态来扩大AI使用规模，通过新打造的分发入口和广告、电商等普通C端软件企业做不到的各种新商业模式来赚回成本
在B端，如果按量付费，大多数企业客户同样无法赚回在token上花的钱，更高的效率和更强的生产力并不能给这些企业直接带来更多自由现金流（不能直接带来业务的扩张和新业务）
它们要么裁员，用token成本替换人力成本，要么跟C端一样需要更高效的企业AI产品来节省成本，让有能力赚回token成本的少数AI企业软件公司集中消耗B端的大部分token
还有一个主要发展方向就是三木奥特曼一直在说的「持续降低token成本」、「让token成本无限趋近电力成本」
只要成本降到一定程度，量变引起质变，C端和B端的很多使用场景也会爆发，而在成本降下来之前，这些场景要么跑不起来，要么就需要上面说的「少数企业」、「少数产品」来集中消耗token
AI的To B或To D并不是已经完全跑通的灵丹妙药，其实和To C有一样的问题：
在C端，「把agent嵌入在现有软件里」的软件企业无法赚回新增的token成本，不得不「审慎克制」。如果按量付费，大多数C端个人用户也无法「赚回」在token上花的钱
需要由少数「把软件嵌入在agent里」里的通用agent企业，来支撑世界上大部分C端token花费，把coding agent/多模态agent隐藏到底层包装成不需要人类主动性也能带来大量token消耗的产品形态来扩大AI使用规模，通过新打造的分发入口和广告、电商等普通C端软件企业做不到的各种新商业模式来赚回成本
在B端，如果按量付费，大多数企业客户同样无法赚回在token上花的钱，更高的效率和更强的生产力并不能给这些企业直接带来更多自由现金流（不能直接带来业务的扩张和新业务）
它们要么裁员，用token成本替换人力成本，要么跟C端一样需要更高效的企业AI产品来节省成本，让有能力赚回token成本的少数AI企业软件公司集中消耗B端的大部分token
还有一个主要发展方向就是三木奥特曼一直在说的「持续降低token成本」、「让token成本无限趋近电力成本」
只要成本降到一定程度，量变引起质变，C端和B端的很多使用场景也会爆发，而在成本降下来之前，这些场景要么跑不起来，要么就需要上面说的「少数企业」、「少数产品」来集中消耗token
4 23
周六周日在字节上海工区旁边（漕河泾会议中心）的Apple生态大会里有WebSpatial的展台，可以现场用visionOS设备体验WebSpatial应用，周日上午可以选择参加两小时的WebSpatial工作坊活动现场用coding agent折腾空间Web应用的可能性，也可以到空间计算主会场听我讲解下
活动官网：letsvision.swiftgg.team
活动行页面：hdxu.cn
以下优惠码先到先得，看有没有能用的
99 元门票兑换码（10 张）：mFtCavyW，ByBGVkHA，gEkUz2Sm，hLcexc5Z，9Ucn52pw，vs94jc6d，4YWSAyz6，muV6peHv。hZQa7hkp，kfmdRQYk
699 元门票兑换码（3 张）：33DBTUSZ，7LAzRUWU，e4BCZnRQ
活动官网：letsvision.swiftgg.team
活动行页面：hdxu.cn
以下优惠码先到先得，看有没有能用的
99 元门票兑换码（10 张）：mFtCavyW，ByBGVkHA，gEkUz2Sm，hLcexc5Z，9Ucn52pw，vs94jc6d，4YWSAyz6，muV6peHv。hZQa7hkp，kfmdRQYk
699 元门票兑换码（3 张）：33DBTUSZ，7LAzRUWU，e4BCZnRQ
9 11
不是「PC养虾」击败了「AI手机」，而是GUI Agent的用途被搞错了
龙虾之前，手机GUI Agent在国内更受重视，是因为国内的个人电脑普及和桌面互联网软件积累当年被打断，Tool的积累都在手机上
这是迎合现状的产品思维，但AI革命不是产品思维主导而是技术主导，移动互联网上的积累再深厚，其实都可以一夕推翻
Agent虽然「类人」，但更类似专业用户而不是大众用户，根本不需要手机app来降低交互门槛（参考附图），桌面电脑/服务器上的Tool对Agent来说能力更强更全、效率更高（有unix管道、bash脚本、文件系统、HTML/JS、Open API等可以直接用代码做自动化和聚合操作的软件协议）
GUI agent不是没用，而是之前被错误的用来解决另一类Agent的问题（OpenAI和xAI似乎都走了这个弯路，前者靠Codex快追上来了，后者正在推倒重建）
之前的帖子（m.okjike.com）里提到过「服务器端 AI」和「客户端 AI」这种Agent分类方式，这里说的客户端不是指模型在客户端运行，而是指Tool在客户端运行或涉及客户端交互
从用途角度来描述这两种类型的通用Agent会更清晰：
第一类可以称作「劳动代理」：用于取代传统的人口资源，供应独立劳动力
第二类可以称作「交互代理」，用于增强人类与外部世界（包括软件数字世界）互动的能力
「劳动代理」更适合用coding agent而不是用GUI agent实现。
这种Agent用的Tool更适合基于服务器/桌面软件环境（包括CLI）而不是手机GUI软件环境。
这种Agent就算扩展到移动场景，也是通过机器人，而不是通过用户的个人移动设备。
「交互代理」需要两类Agent产品形态，第一类是最彻底的形态，可以称作「Agentic Web浏览器」，用户通过这种浏览器（User Agent）与外界软件世界互动，通过Web获取Tool和内容，所有Tool、内容乃至客户端状态都聚合在浏览器自身「内部」。
另一类产品形态是所有个人计算设备（包括手机、眼镜/目镜等）的系统全局GUI Agent，能跟用户实时紧密协作，共享同一套外部的Tool环境和客户端状态。
这两类Agent之间还有一个交叉领域：
眼镜/目镜等可穿戴个人计算设备的多模态交互输入能力、GUI Agent的视觉能力和行动能力、机器人的Physical AI能力（含多模态、视觉、行动等），是共通的，只要其中一个需求够强，相关技术就注定会发展，让其他需求也受益
龙虾之前，手机GUI Agent在国内更受重视，是因为国内的个人电脑普及和桌面互联网软件积累当年被打断，Tool的积累都在手机上
这是迎合现状的产品思维，但AI革命不是产品思维主导而是技术主导，移动互联网上的积累再深厚，其实都可以一夕推翻
Agent虽然「类人」，但更类似专业用户而不是大众用户，根本不需要手机app来降低交互门槛（参考附图），桌面电脑/服务器上的Tool对Agent来说能力更强更全、效率更高（有unix管道、bash脚本、文件系统、HTML/JS、Open API等可以直接用代码做自动化和聚合操作的软件协议）
GUI agent不是没用，而是之前被错误的用来解决另一类Agent的问题（OpenAI和xAI似乎都走了这个弯路，前者靠Codex快追上来了，后者正在推倒重建）
之前的帖子（m.okjike.com）里提到过「服务器端 AI」和「客户端 AI」这种Agent分类方式，这里说的客户端不是指模型在客户端运行，而是指Tool在客户端运行或涉及客户端交互
从用途角度来描述这两种类型的通用Agent会更清晰：
第一类可以称作「劳动代理」：用于取代传统的人口资源，供应独立劳动力
第二类可以称作「交互代理」，用于增强人类与外部世界（包括软件数字世界）互动的能力
「劳动代理」更适合用coding agent而不是用GUI agent实现。
这种Agent用的Tool更适合基于服务器/桌面软件环境（包括CLI）而不是手机GUI软件环境。
这种Agent就算扩展到移动场景，也是通过机器人，而不是通过用户的个人移动设备。
「交互代理」需要两类Agent产品形态，第一类是最彻底的形态，可以称作「Agentic Web浏览器」，用户通过这种浏览器（User Agent）与外界软件世界互动，通过Web获取Tool和内容，所有Tool、内容乃至客户端状态都聚合在浏览器自身「内部」。
另一类产品形态是所有个人计算设备（包括手机、眼镜/目镜等）的系统全局GUI Agent，能跟用户实时紧密协作，共享同一套外部的Tool环境和客户端状态。
这两类Agent之间还有一个交叉领域：
眼镜/目镜等可穿戴个人计算设备的多模态交互输入能力、GUI Agent的视觉能力和行动能力、机器人的Physical AI能力（含多模态、视觉、行动等），是共通的，只要其中一个需求够强，相关技术就注定会发展，让其他需求也受益
4 00
正确理解的前提是正确分类，其实有两类做「GAO（通用Agent优化） 」的协议：
客户端Tool接口：
- 基于Unix哲学的CLI
- 基于原生GUI框架的App Intents（苹果）、AppFunctions（安卓）、App Actions（Win）
- 基于浏览器引擎的WebMCP
- 在客户端运行的MCP Server
服务器端Tool接口：
- MCP Server和MCP App
- 用Skill封装的Open API
作为新一代入口/分发中心/超级应用的通用Agent，目前也有两类：
- 生成客户端代码，调用在客户端（包括云端沙盒化的专用客户端环境）运行的Tool，比如cowork、openclaw
- 生成服务器端API调用代码，把服务器端API作为Tool，也用云端沙盒里的CLI Tool，提供类浏览器的跨平台客户端，比如ChatGPT、Manus
已有的软件产品的思维定式和常见迷思是以为AI就是「把Agent集成到软件里」，喜欢强调「场景/context」（也就是自家软件当下的用例），要么承担不了token成本、损害现有商业模式和现金流，要么容易觉得AI没啥用、落不了地，要么把软件主屏都改成对话界面，用户每次打开App都多了一步操作要跳过这个首屏
其实AI的真正意味是「把软件集成到通用Agent里」，软件的用户不再只是人（少数power user加一堆轻度用户），通用Agent（海量power user和会写代码的pro user）才是软件最重要的新用户
一个软件不做好GAO，不对通用Agent友好，相当于桌面互联网时代既不支持Web标准兼容现代浏览器也不做SEO对Google友好
要做GAO对各种现在和未来的通用Agent都尽可能友好，就应该尽可能提供上述所有Tool接口
没客户端，就优先提供CLI，而MCP和教AI用Open API的Skill更是根本
有客户端，就先在现有客户端技术栈中支持对应协议，比如有Web就优先在HTML中声明WebMCP，同时也探索MCP App（含MCP-UI）和面向pro user的CLI用法
最后再来看MCP会不会被取代的问题：
最初只有MCP这一种Tool协议的时候，客户端软件想作为Tool也需要依靠MCP Server（运行在客户端）
现在CLI的价值被「重新发现」：
1. 身为客户端软件，却不需要额外暴露Agent专用的Tool接口，自己原有的基于unix哲学的使用方式能直接作为API协议，人怎么用CLI，Agent就怎么用
2. 虽然也需要提前安装，但不需要像客户端MCP Server那样还要提前启动、持续运行。可以按需调用
3. 天然对云端沙盒化的Agent专用客户端环境友好，因此早就被ChatGPT这样的通用Agent们广泛使用，之后随着coding agent的破圈，在普通用户的客户端环境里也被各家通用Agent广泛使用
基于GUI的客户端软件（包括Web、Mac/Win、iOS/安卓）的使用方式，则是优先面向普通人的，Agent不是普通人，这种使用方式对会写代码的Agent来说是低效的，因此需要额外暴露API
各家客户端技术栈逐渐有了原生的Tool协议（开头提到的WebMCP、App Intents这类），但这些协议除了WebMCP都不是跨平台的，会首先采纳这类协议的，是操作系统自身的第一方通用Agent，这些还在发展早期，现有的主流通用Agent都是第三方超级应用，就算愿意采纳这些协议，也可能被操作系统限制
在支持UNIX风格CLI环境的客户端平台，CLI是已被广泛采纳的跨平台Tool协议，是最佳选择。而不支持CLI的客户端平台（比如手机等移动设备）对客户端运行MCP Server也同样不友好，要指望各家客户端技术栈的原生一方Tool协议。
推演结果是：在客户端，MCP确实可以淘汰
在服务器端，如果一款产品如果没有GUI，不面向普通用户，只提供Open API，那么用Skill直接教Agent用Open API似乎也完全可以代替MCP
如果有GUI，且想要集成到上面说的第二类通用Agent，则MCP仍然是必要的选择，MCP在这种情况下有两个优势：
1. 已经从MCP Server标准扩展到了MCP App标准，支持MCP-UI，可以在通用Agent中提供GUI
2. 本来就持续运行，只要通用Agent支持「Tool Search Tool」，能自主搜索发现MCP，就不需要提前安装，可以像Web那样被按需使用。Skill 只是本地文件协议，不是Web协议/网络协议，需要提前安装到本地文件系统里
推演结果是：在服务器端，MCP要靠发展UI能力和Web能力，才能免于淘汰
客户端Tool接口：
- 基于Unix哲学的CLI
- 基于原生GUI框架的App Intents（苹果）、AppFunctions（安卓）、App Actions（Win）
- 基于浏览器引擎的WebMCP
- 在客户端运行的MCP Server
服务器端Tool接口：
- MCP Server和MCP App
- 用Skill封装的Open API
作为新一代入口/分发中心/超级应用的通用Agent，目前也有两类：
- 生成客户端代码，调用在客户端（包括云端沙盒化的专用客户端环境）运行的Tool，比如cowork、openclaw
- 生成服务器端API调用代码，把服务器端API作为Tool，也用云端沙盒里的CLI Tool，提供类浏览器的跨平台客户端，比如ChatGPT、Manus
已有的软件产品的思维定式和常见迷思是以为AI就是「把Agent集成到软件里」，喜欢强调「场景/context」（也就是自家软件当下的用例），要么承担不了token成本、损害现有商业模式和现金流，要么容易觉得AI没啥用、落不了地，要么把软件主屏都改成对话界面，用户每次打开App都多了一步操作要跳过这个首屏
其实AI的真正意味是「把软件集成到通用Agent里」，软件的用户不再只是人（少数power user加一堆轻度用户），通用Agent（海量power user和会写代码的pro user）才是软件最重要的新用户
一个软件不做好GAO，不对通用Agent友好，相当于桌面互联网时代既不支持Web标准兼容现代浏览器也不做SEO对Google友好
要做GAO对各种现在和未来的通用Agent都尽可能友好，就应该尽可能提供上述所有Tool接口
没客户端，就优先提供CLI，而MCP和教AI用Open API的Skill更是根本
有客户端，就先在现有客户端技术栈中支持对应协议，比如有Web就优先在HTML中声明WebMCP，同时也探索MCP App（含MCP-UI）和面向pro user的CLI用法
最后再来看MCP会不会被取代的问题：
最初只有MCP这一种Tool协议的时候，客户端软件想作为Tool也需要依靠MCP Server（运行在客户端）
现在CLI的价值被「重新发现」：
1. 身为客户端软件，却不需要额外暴露Agent专用的Tool接口，自己原有的基于unix哲学的使用方式能直接作为API协议，人怎么用CLI，Agent就怎么用
2. 虽然也需要提前安装，但不需要像客户端MCP Server那样还要提前启动、持续运行。可以按需调用
3. 天然对云端沙盒化的Agent专用客户端环境友好，因此早就被ChatGPT这样的通用Agent们广泛使用，之后随着coding agent的破圈，在普通用户的客户端环境里也被各家通用Agent广泛使用
基于GUI的客户端软件（包括Web、Mac/Win、iOS/安卓）的使用方式，则是优先面向普通人的，Agent不是普通人，这种使用方式对会写代码的Agent来说是低效的，因此需要额外暴露API
各家客户端技术栈逐渐有了原生的Tool协议（开头提到的WebMCP、App Intents这类），但这些协议除了WebMCP都不是跨平台的，会首先采纳这类协议的，是操作系统自身的第一方通用Agent，这些还在发展早期，现有的主流通用Agent都是第三方超级应用，就算愿意采纳这些协议，也可能被操作系统限制
在支持UNIX风格CLI环境的客户端平台，CLI是已被广泛采纳的跨平台Tool协议，是最佳选择。而不支持CLI的客户端平台（比如手机等移动设备）对客户端运行MCP Server也同样不友好，要指望各家客户端技术栈的原生一方Tool协议。
推演结果是：在客户端，MCP确实可以淘汰
在服务器端，如果一款产品如果没有GUI，不面向普通用户，只提供Open API，那么用Skill直接教Agent用Open API似乎也完全可以代替MCP
如果有GUI，且想要集成到上面说的第二类通用Agent，则MCP仍然是必要的选择，MCP在这种情况下有两个优势：
1. 已经从MCP Server标准扩展到了MCP App标准，支持MCP-UI，可以在通用Agent中提供GUI
2. 本来就持续运行，只要通用Agent支持「Tool Search Tool」，能自主搜索发现MCP，就不需要提前安装，可以像Web那样被按需使用。Skill 只是本地文件协议，不是Web协议/网络协议，需要提前安装到本地文件系统里
推演结果是：在服务器端，MCP要靠发展UI能力和Web能力，才能免于淘汰
3 00
Qwen的tech leader离职的这个原因，跟我当年离开字节架构的原因完全一样😂
从无到有做起来、开始商业化之后，大厂管理容忍不了这种内部创业式的垂直整合团队和一体化协同产品
从无到有做起来、开始商业化之后，大厂管理容忍不了这种内部创业式的垂直整合团队和一体化协同产品
9 00
低情商和高情商的区别，同样的要求，Sam就谈成了😂
跟愚蠢爱虚荣的恶霸打交道，要始终夸对方，功劳都归对方，这个前提下再把具体细节引导到自己的立场上，不能一上来就让恶霸没面子、觉得你以后可能不服从他
情商不仅是个认知问题，也是个执行问题，低情商的执行是从一开始就追求确定性，不能有世界线发散的空间，不愿在表面妥协留出模糊空间，想一劳永逸的解决，不愿意走弯路和陪对方踩自己已知的坑
高认知低执行的低情商，本质上是能理解别人的情感、认知局限和非理性行为，但自己无法做出偏离事实、是非、直接手段、直线路径的行为调整。比如我自己就是虽然能想到上面这些道理，但行动上做不到，所以产品工作不好做，做产品经理不像做软件工程师，要跟更多样的人打交道，很多人不就事论事，不纯粹。我一般也不夸人，说话没情绪价值，只会发现问题和解决问题，怎么想就怎么说
跟愚蠢爱虚荣的恶霸打交道，要始终夸对方，功劳都归对方，这个前提下再把具体细节引导到自己的立场上，不能一上来就让恶霸没面子、觉得你以后可能不服从他
情商不仅是个认知问题，也是个执行问题，低情商的执行是从一开始就追求确定性，不能有世界线发散的空间，不愿在表面妥协留出模糊空间，想一劳永逸的解决，不愿意走弯路和陪对方踩自己已知的坑
高认知低执行的低情商，本质上是能理解别人的情感、认知局限和非理性行为，但自己无法做出偏离事实、是非、直接手段、直线路径的行为调整。比如我自己就是虽然能想到上面这些道理，但行动上做不到，所以产品工作不好做，做产品经理不像做软件工程师，要跟更多样的人打交道，很多人不就事论事，不纯粹。我一般也不夸人，说话没情绪价值，只会发现问题和解决问题，怎么想就怎么说
4 01