昨天早上起来一看,发现 ChatGPT 发布了他们新的医疗健康功能,很多朋友说这不就是蚂蚁阿福吗? 难得,终于有一次是 OpenAI 跟随国内AI了。 我试了一下蚂蚁阿福,从能力上来看,Open AI比蚂蚁阿福差了不少,Open AI 的健康功能支持将你的检测结果和一些健康应用的数据同步过去,然后它会基于专门打造的健康模型,对你的体检结果及健康数据进行分析。 这些功能蚂蚁阿福都是有的,而且不止支持健康应用的数据同步,还支持连接各种专业的血压仪等医疗器械。 蚂蚁阿福比较强大的是:它的智能问答能力支持多种提问方式,包括语音、文字和拍照,甚至可以通过拍皮肤去识别皮肤病,拍药盒以获得药物疗效和一些禁忌的指导,以及拍摄体检报告来提供医疗资料等。 这些功能都非常易用,在体验层面非常符合中国国情。毕竟我们有很多老人和偏远地区用户,对他们来说,打字是挺费劲的。 另外,他们还支持与一些国内非常有名的医生 AI 分身进行对话。还支持:在线问诊和医院就医指导以及挂号服务。通过这些功能,他们把整个健康链路都打通了。线下就医还能直接语音唤起医保码进行支付,体验好太多了。 12 月 15 号发布新版蚂蚁阿福之后月活翻倍达到了 3000 万,单日提问量超过了 1000 万,说明很多人确实非常需要一个一站式有优秀体验的的 AI 健康中心。
昨晚 CES 2026 老黄照例发表演讲,总结一下发布内容 主要是升级的 Rubin 芯片架构和 Alpamayo 机器人和自动驾驶 VLA 模型 ------ Rubin 架构平台特性: 100% 液冷: 使用 45°C 的温水冷却,无需冷水机组,节省大量能源; 机密计算: 所有数据在传输、静态和计算过程中均加密; 性能飞跃: 在训练 10 万亿参数模型时,Rubin 的吞吐量大幅提升,且生成 Token 的成本仅为 Blackwell 的十分之一; Rubin 架构主要有下面几个部分组成: Vera CPU: 专为功率受限环境设计,性能功耗比是前代的 2 倍,采用空间多线程技术。 Rubin GPU:浮点运算性能是 Blackwell 的 5 倍,但晶体管数量仅增加 1.6 倍。引入了 NVFP4 Tensor Core,一种能够动态调整精度的处理单元。 NVLink 6 Switch: 交换机芯片带宽达到 3.6 倍全球互联网总流量,确保每个 GPU 都能同时与所有其他 GPU 通信。 ConnectX-9 网卡: 与 Vera CPU 协同设计,提供 1.6 Tb/s 的带宽。 BlueField-4 DPU:负责安全性及虚拟化,它还引入了革命性的 KV Cache 存储功能,解决了长上下文对话中 GPU 显存不足的问题,为每个 GPU 额外提供 16TB 的快速访问内存。 Spectrum-X Ethernet Switch(新一代): 采用硅光子技术和共封装光学器件,拥有 512 个通道。 ------ 开源 Alpamayo 模型家族: Alpamayo 1 VLA 模型:100亿参数的“链式思考”视觉-语言-行动模型,能把问题分解为步骤、在多方案中推理并选择更安全的路径,并用自然语言说明行动与轨迹。 开放数据集:包含超过 1700 小时的驾驶数据,这些数据涵盖了各种地理区域和路况,囊括了罕见且复杂的真实世界场景。  AlpaSim:一个用于验证自动驾驶系统的开源仿真框架。
看到马伯庸分享他写日记的方式,非常有意思! 而且跟之前分享过的 Karpathy 的记录方式也很像。 这种方式可以跟AI很好地结合,我 26 年想实践一下了。 先介绍一下他俩是怎么记录的: 他为了降低摩擦,会只记录事实(就是流水账),而不记录观点,不写感悟,不去润色,也不在乎遣词造句。 Karpathy 当时的日记也是一样采用 Append-only 模式,想到什么就往文档顶部丢,不打标签,不分类,不设层级,日记当剪切板用。 只记事实,就失去了“表演给别人看”或“自我感动”的空间,整个输入的摩擦力就大幅降低了。 而且它还可以通过语音输入,每次记完什么事,只要打开语音输入说一句话就解决了,非常方便。 而且他们还有一个特点,就是只用一个文件去记录: Andrej Karpathy 是在备忘录里,只有一个文档 马伯庸也是,就是只有一个 Word 文档 这样的话对他们来说不用整理,需要的时候直接 Command + F 查找关键字就行。 而且这种流水账的内容比较少,即使记一年也可能只有几万字,随便怎么样都能检索到对应的信息。 马伯庸主要是用这种方式来解决自己中年记忆力衰退的问题。Andrej Karpathy 将其视为大脑 RAM 的释放工具:通过手记,大脑就可以放下这些信息,从而专注于做其他需要专注的事情。 我发现他们这种记录方式跟 AI 协作也非常友好: 这种东西是非常好的 AI 原生语料。 因为它拥有高密度的语义,包括:人名、书名、事件、命令、代码,这些都是非常容易提取的结构化信息。 另外,这种方式对上下文非常友好。 因为它体积小,一年可能最多也就几万字,完美地适配了现在大语言模型的上下文。而且由于它是纯文本,AI 可以非常高效且便捷地进行查询和整理。 这种低摩擦、高信息密度,且纯文本的记录方式,无意中非常适合现在的 AI。 通过这种方式,可以快速构建起属于你自己的类似 ChatGPT 的 AI 记忆。 而且纯文本又不至于让你被绑定到某一个产品上。
TRAE 月活破160万!借着数据聊 AI 编程生态 Trae 发布了他们的年度开发者报告。 也可以看作 AI Coding 的一次生态调研,仔细看了一下,找到了一些有意思的数据。 TRAE 现在总用户数已经 600 万了,月活 160 万,作为一个相对专业的编程工具,已经相当不错,可能国内第一了。 周活跃用户在 TRAE 几乎是工作日全勤的,粘性相当高。 这几年他们的迭代还是挺快的,从刚开始的 Agent 1.0 然后是 SOLO Beta 最后是 SOLO 的正式版,基本上每一个版本我都有测试,进度真的是肉眼可见地,好用了很多。 之前经常存在的网络延迟问题,以及很多人反映过的内存占用问题,现在都已经得到了大幅改善。 根据他们官方报告的数据:补全延迟降低了 60%,内存占用降低了 43%。 在大家的使用场景上,相关数据的分布如下: 1. 代码生成:占了 30% 左右 2. 修复 Bug:占了 40% 左右 这两个种类基本上是大家最常用的任务,也是 AI 模型做得比较好的任务。 至于大家用的比较少的几个场景,仓库管理、环境管理、代码优化,这几个功能确实是大家目前不太信任的。 在编程语言方面,我们可以看看大家对于 AI 现在能解决的编程语言的排序。排名最靠前的是 Vue,之后依次是:Python、JS(JavaScript)、HTML、Java、TypeScript,可能还是主要集中在前端的网页上。 TRAE 对于各种 AI 编程生态工具的支持也相当不错,目前支持了超过 1.1 万个 MCP。 大家用的最多的 AI 编程模式是 Builder 模式占 80%,之后是 SOLO Coder 占了 40%,超过 80% 的人是多种智能体混用的,说明这几个模式的长处和短板大家都比较了解了。 随着国内模型的编程能力越来越强,同时在搭配上 TRAE 丰富且高效的基建,感觉 2026 年在编程领域还是会有非常大的进步的。