7月10日2026 · 星期五

OpenAI 今天一口气发布了一整套产品更新： 1. GPT-5.6 正式向公众开放 2. ChatGPT 和 Codex 合体成了一个桌面应用 3. 一个叫 ChatGPT Work 的新功能让 AI 从聊天助手变成了能干活的 Agent。 先说 GPT-5.6。 GPT-5.6 今天正式放开，三个级别：Sol 是旗舰，主打复杂推理和长时间自主工作；Terra 是性价比款，官方说性能接近上一代旗舰 GPT-5.5 但价格只有一半；Luna 是轻量款，跑得快、便宜。API 定价方面，Sol 每百万 token 输入 5 美元、输出 30 美元，Luna 只要 1 美元和 6 美元。ChatGPT 免费用户和 Go 用户默认用 Terra，Plus 及以上可以自选模型。 Sol 还新增了两个推理档位：max 让模型花更多时间深度思考，ultra 则会调用多个子智能体(Agent)并行处理任务，有点像同时派出几个人分头干活再汇总。ultra 目前限 Pro 和 Enterprise 用户。 再说 ChatGPT 和 Codex 桌面应用合并。 OpenAI 把 ChatGPT 和 Codex 塞进了同一个桌面应用里，Chat、Work、Codex 三个模式共享同一套能力和任务历史，区别只在界面：Codex 展示代码差异和 PR（代码提交合并请求），Work 把技术细节隐藏掉，面向非开发者。用户可以在两个模式间自由切换。 Codex 现在每周活跃用户 500 万，其中超过 100 万人用它做的是开发之外的工作，比如写报告、做分析。OpenAI 发现非开发者也涌进了 Codex，与其维护两个独立产品，不如合到一起。Fidji Simo（OpenAI 应用业务 CEO）内部邮件里说：“产品分散拖慢了我们的速度。” ChatGPT Work 是这次最值得关注的新功能。它不再只是回答问题，还能跨应用执行任务：连接你的 Google Drive、Slack、邮箱等工具，自己拆解复杂项目，分步骤独立完成，需要时才问你。比如你给它一句话“把客户调研整理成营销方案”，它能自己读资料、写方案、生成不同市场的素材版本，全程带着上下文。还能设定定时任务，比如每周自动汇总 Slack 消息刷新会议议程。 Work 也会登陆网页和手机端，意味着你不需要在电脑前也能发起和跟踪任务。 另一个值得一提的是 Sites。现在 ChatGPT 对话里生成的可视化、仪表盘或小工具，点一下就能变成一个可分享的网站。做个项目进度面板发给团队、做个内部工具原型让同事试用，不用再折腾部署。 浏览器也升级了，支持登录态网站操作、多标签页和文件下载，配合新的 Chrome 扩展，ChatGPT 可以在你浏览器里直接帮你干活。这让 Computer Use（电脑操控）能力有了更实际的落地场景。 Codex 端也有几个开发者关心的更新：可以直接在应用里编辑文件、看 PR 和审查反馈、新增 Ultra 模式处理高难度编码任务。还有一个细节，Codex 加了从 Claude Code 迁移的导入功能，包括设置和偏好配置，显然是在争抢 Anthropic 的开发者用户。 今天的发布放在更大的背景下看，是 OpenAI 超级应用战略的一步。把聊天、编码、浏览、文件操作全装进一个应用里，目标是成为 AI 时代的生产力平台，直接对标 Google Workspace 和 Microsoft 365。 考虑到 OpenAI 刚向 SEC 提交了上市文件，企业用户贡献了其 40% 的收入，这次发布的商业逻辑也很清楚：用统一平台锁住企业客户，为 IPO 讲一个更大的故事。 顺带一提，GPT-5.4 将在 7 月 23 日退役。 > 引用 @OpenAI: Sol, Terra, and Luna, our GPT‑5.6 family of models, are starting to roll out now in ChatGPT, Codex, and the API.

今天直播的视频双语版

真佩服 Vercel 的挖坑速度，又开了个大坑，后面就看能不能填上了。 Native SDK 是一套用 Zig 语言构建原生桌面应用的开发框架，它想解决的问题是用声明式标记语言写 Native UI。 要我说，在 AI 时代之前，这类框架真的挺有价值的，写一遍到处能运行。 现在 AI 时代，不如同一套设计，让 AI “翻译”到不同平台，Mac 你就老老实实用 AppKit（SwiftUI 都没必要），既能保证性能和兼容性，又能避免去踩跨平台框架带来的各种坑。 当然只是我观点，仅供参考，下面是项目的介绍： 主流方案（Electron 之类）往往要把一整个浏览器打包进去，应用体积和内存占用都很夸张。Native SDK 的做法是保留声明式的写法，但把浏览器换掉，用自己的渲染引擎直接往操作系统窗口里画像素。 开发体验上，界面写在 .native 后缀的标记文件里，逻辑用 Zig 写，架构是 Model/Message/Update 的单向数据流，跟 Elm 那一套思路类似。状态变更只发生在一个 update 函数里，界面层只负责绑定和派发消息，不能直接改数据。这种约束带来一个好处：整个应用的行为是确定性的，可以录制一次操作、无头回放、逐帧对比状态指纹来做自动化测试。 框架自带了一套组件库（按钮、输入框、Tab、对话框、虚拟列表、图表等），默认就有排版和配色，拿来就能用。定制走设计 Token 体系，换一套 Token 就能换一套视觉风格。CLI 工具链也比较完整：native init 创建项目，native dev 热重载开发，native check 做静态校验（能检查标记文件里的数据绑定是否跟 Zig 的 Model 和 Msg 类型匹配），native test 跑无头 UI 测试，native build 出发布包。最终产物是几 MB 的单体二进制文件，不带解释器和运行时。 一个有意思的设计是它把 AI Agent 协作作为一等公民考虑：每个应用内置自动化服务器，Agent 可以读取无障碍快照、操控控件、断言运行时状态、截取确定性截图。CLI 还自带 Agent 技能文件，用 native skills list 可以查看。 平台支持方面，macOS 最成熟（Metal 渲染、原生菜单、托盘），Linux 和 Windows 可用但功能少一些，iOS 和 Android 处于实验阶段。WebView 作为可选项在桌面端也能混用。项目目前还在 pre-1.0 阶段，API 仍在变动，采用 Apache 2.0 开源协议。 > 引用 @ctatedev: Introducing Native SDK > > The toolkit for building native apps > > → Hot reload > → Markup + Zig > → Instant launch > → macOS, Windows and Linux > → GPU engine built from scratch > → Built-in design system and themes > → Custom components + design tokens

更接近 Flutter 的思路，跟 RN 走的是相反方向。 https://x.com/CorrectRoad/status/2075071901559669098?s=20 RN 的做法是把 JS 写的组件映射到平台原生控件（iOS 上是 UIKit，Android 上是原生 View），所以按钮、输入框这些长得跟系统控件一样。 Native SDK 不用平台原生控件，它自己有一套渲染引擎，每个像素都自己画。按钮、列表、输入框全是引擎绘制的，不是系统提供的。从这个意义上说，它的原生指的是编译成原生二进制、直接画进 OS 窗口，而不是使用原生 UI 组件。 但它又不像 Flutter 那样什么都自己来。滚动物理、右键菜单、系统对话框、托盘、文本输入（IME）这些交给操作系统处理。所以是个混合策略，渲染自己做，但交互行为里涉及系统级体验的部分还是走 OS。 跟 Zed 的 GPUI 对比，两者的核心哲学很像，都是不依赖系统控件，自己画全部界面，编译型语言，无运行时。主要差异在几个层面： 1. 语言选择不同。 GPUI 用 Rust，Native SDK 用 Zig。 2. 界面描述方式不同。 GPUI 的 UI 写在 Rust 代码里，通过实现 Render trait 来声明视图，本质上是代码即 UI。Native SDK 把视图拆到单独的 .native 标记文件里，跟逻辑代码分离，更接近 Web 前端的写法（模板 + 逻辑分离）。对 AI 代码生成来说，标记文件可能比 Rust trait 实现更容易生成和校验。 3. 状态管理模型不同。 GPUI 是 Entity 系统加响应式上下文，比较灵活但也更零散。Native SDK 是严格的 Elm 架构（Model/Msg/Update），所有状态变更只走 update 函数，确定性更强，可以做到录制回放和逐帧比对。这是一个取舍，牺牲灵活性换可预测性。 4. 定位也不太一样。 GPUI 是和 Zed 编辑器伴生的，现在虽然计划独立发布成 crate，但设计决策高度围绕编辑器场景（高帧率文本渲染、多人协作）。Native SDK 从一开始就定位通用应用框架，自带组件库和 Design Token 体系，带着开箱就能出像样 App的意图。 > 引用 @CorrectRoad: @dotey 有多原生。类似RN还是Flutter。 > > 对比zed的GPUI是一样的思路还是啥

当你用 Coding Agent 去 Vibe Coding 的时候，你的角色不是单纯的程序员了，变成了工程经理（EM，Engineering Manager）的角色，这就好比你问一个 EM：为啥要去看代码？不应该只关注功能么？ 一个不懂代码不看代码的 EM 也许可以当个合格的 EM，但绝对不是优秀的 EM。 指挥 AI Agent 干活，跟 EM 指挥一群开发工程师（SDE）很像，当过 EM 的一定心有戚戚，你得帮着去理解需求、拆解需求，去分配任务，去验收任务。 比指挥 SDE 省心的地方在于你不用照顾 AI 的情绪，也不用担心 AI 过劳，可以使劲 PUA，使劲用。 但费心的地方在于 AI 没有主动性，AI 没有完整上下文。 没有主动性体现在你得指挥着他们干活，哪怕 AI 再聪明，也不能你一句话就主动把活都给你干了。 整个团队 EM 了解的信息是最多的，下面每一个 SDE 了解的信息都是片面的，就像 Agent 不知道所有上下文只有你知道。 所以一个功能做出来，EM 如果不验收一下，不看看代码，那么即使你下面的 SDE 再聪明，也会因为信息不对称不完整，造成误解，而实现出跟你预期不一样的结果，更不要说搞出一些严重的安全性问题。 再聪明的 AI，在没有充分了解所做功能的完整上下文、使用场景的情况下，方案都是可能有偏差的。毕竟没有万能的方案，只有适合特定场景的方案。就算你在事前有充分的计划和讨论，但是一些藏在你脑子里面的隐含的难以表达的信息还有很多是无法直接传导给 AI 的。 > 引用 @yuerschool: @dotey 为啥要去看代码？不应该是只关注功能么？

AI 写的代码量太大看不过来，这里面分两种，一种是做原型，这种你就不需要看，只验证功能就好了；一种是要做生产环境就绪的版本，那么就要看代码要验证功能。https://x.com/zemul888/status/2075257259987484686?s=20 代码太多看不过来的问题其实在传统软件工程就有这种问题，核心就是集成的颗粒度。 早年瀑布模型的时候，一个版本几个月上年，每次变更一大坨，各模块独立开发，然后再集成。但模块之间集成的时候无比痛苦，因为代码变更太多了。并且集成后要很长时间才能稳定下来。 后来敏捷开发就变成“持续集成（Continuous integration）”了，简单来说就是一次一个小功能，做了一点就集成。不是围绕模块去变更，而是围绕小的功能点去变更，再配合好自动化测试，每次功能的变更后系统整体都是稳定的。由于一次变更量不大，所以也好验收代码。 Vibe Coding 也是一样的，你一次让 AI 搞个大的，不仅结果不好，还没办法验收审查，代码看不过来。 如果你换个思路，一次做个小功能点，一次修一个小bug，那么每次做完你都是可以验收可以审查的，可以随时纠正的。质量也有保障。 > 引用 @zemul888: @dotey Ai 写的代码量太大了，看不过来怎么办？