7月11日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.

今天直播的视频双语版

当你用 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 写的代码量太大了，看不过来怎么办？

真佩服 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是一样的思路还是啥

很多人搞不清楚 ChatGPT、Codex、Work 什么差别，以及额度是独立的还是共享的，根据官方文档整理了一个简单的 Q & A。 Q：Chat、Work、Codex，一句话说清区别？ Chat 回答问题，Work 帮你干活，Codex 帮你写代码。 Chat 就是你熟悉的 ChatGPT，你问它答，快进快出。 Work 是一个能跨应用收集信息、然后交付完整成品的智能体（Agent），交付物是文档、表格、幻灯片、网页应用这些拿到手就能用的东西。 Codex 也是智能体，但它主要操作的是代码仓库，能读你的项目文件、改代码、跑测试、提交 PR。 打个比方： Chat 是你问"番茄炒蛋怎么做"，它告诉你步骤。 Work 是你说"帮我准备一桌晚餐"，它自己去冰箱找食材、炒菜、摆盘。 Codex 是你说"这个菜谱 App 有 bug"，它打开代码自己修。 【来源：https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex】 Q：Work 到底能做什么？跟直接在 Chat 里说“帮我写个报告”有什么不同？ 在 Chat 里你说“帮我写个报告”，它给你一段文字，你自己复制粘贴到 Word 里排版。 Work 完全不同。你先把日常工具接进去，Slack、Gmail、Google Drive、SharePoint、Teams、日历、CRM、项目管理工具都行，OpenAI 叫它 plugins。接好之后告诉它你要什么结果，它会自己去这些应用里拉数据、整合信息、生成一份可以直接交付的成品。你在提示词里用 @ 加应用名就能指定它去哪儿找数据。 举个例子，Zapier 的企业营销负责人用 Work 搭了一个系统，每月审查数千条线索，追踪 CRM 和邮件中的客户触点，找出跟进断裂的地方，生成管理层周报。Virgin Atlantic 的数字产品负责人用它做竞品对标分析，让 ChatGPT 调研各家航空公司的服务水平，生成可供团队审查的数据集，把原本需要数周的分析缩短到几小时。 另一个区别是 Work 能长时间跟进。一个复杂项目，它可以跟好几个小时，自己拆步骤、自己推进。中间有拿不准的会来问你，你也可以随时调整方向、审批关键动作。 【来源：https://openai.com/index/chatgpt-for-your-most-ambitious-work/】 Q：Work 能定时跑任务？ 能。这个功能叫 Scheduled Tasks（定时任务），可以设成一次性、定时重复、事件触发或持续监控。 比如你设一个任务：每天早上检查 Slack 和邮件里的新消息，整理成简报发给你。或者：每当有新的客户反馈进来，自动归类主题、整理成产品改进建议。这些都能在后台跑。它还能用桌面端的内置浏览器上网查信息，甚至通过 Computer Use 功能操作你电脑上的其他应用。 定时任务面向 Plus、Pro、Business 和 Enterprise 用户开放，各档计划的并发任务数量上限不同。任务不能每小时跑超过一次，长时间无人理会的任务可能会自动暂停。 【来源：https://openai.com/index/chatgpt-for-your-most-ambitious-work/ https://help.openai.com/en/articles/6825453-chatgpt-release-notes】 Q：那 Codex 跟 Work 的区别到底在哪？ 这两其实是同一套底层 Agent（Codex）和 UI，但是应用在不同的场景，配合不同的插件。读的东西不同，交付的东西也不同。 Work 读的是你的业务上下文，邮件、文档、聊天记录、日历，交付的是商务成品，幻灯片、电子表格、文档、网站。Codex 读的是你的代码仓库，交付的是代码变更，diff、测试结果、PR。 【来源：https://openai.com/index/chatgpt-for-your-most-ambitious-work/】 Q：Codex 每周有 500 万人用，为什么还要再出一个 Work？ OpenAI 在博文里提到，虽然 Codex 最初是为开发者设计的编程智能体，但已经有超过 100 万人在用它做软件开发以外的工作。Work 的推出，某种程度上是把这些非编程用途正式化了，给了它一个专门的界面和工作流，用 plugins 连接业务应用，输出文档和幻灯片而不是代码。 OpenAI 自己内部也在大量使用：销售团队用 Work 把一次客户探索对话在 24 小时内变成了定制 POC（概念验证），以前这个流程需要几周。财务团队用 Work 把月末结账和预测流程从几天压缩到几小时。 我觉得 Codex 这么做呢，目的是为了吸引办公人群，原本这些人看到 Codex 的名字会以为是写代码用的，但是改名呢又会影响原本的 Codex 用户，结果就搞成这样一套产品两个名字。 简单来说就是一套产品，两个名字，两种主要场景，同时吸引不同用户群。 【来源：https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex https://www.developersdigest.tech/blog/chatgpt-work-codex-desktop-app】 Q：我在哪儿能用这三个模式？ Chat 最简单，网页、手机、桌面端都有，所有平台通用。 Work 在网页和手机上已经开始上线（Pro、Enterprise、Edu 优先，Plus 和 Business 未来几天陆续开放）。桌面端也有，而且桌面端更强，能用本地文件，还有内置浏览器上网抓取信息。 Codex 只在桌面端能选。手机上不能直接用 Codex 模式，但可以通过 ChatGPT App 里的 Remote 标签远程查看桌面上正在跑的 Codex 任务。 一个要注意的点：网页/手机端的 Work 对话和桌面端的 Work 对话目前不互通，云端是云端，本地是本地。Chat 对话则可以跨网页和桌面端同步。 原来独立的 Codex App 已经合并进了新版 ChatGPT 桌面端。一个 App 里切换 Chat、Work、Codex 就行。开发者可以把 Codex 设为默认打开视图，App 图标也能换成 Codex 的 logo。原来的 ChatGPT 桌面端会更名为 ChatGPT Classic。 【来源：https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex https://openai.com/index/chatgpt-for-your-most-ambitious-work/】 Q：Chat 聊天和 Work/Codex 的额度是共享的吗？ 不共享。Chat 对话有自己独立的消息限额，图片生成和语音也各有各自的独立限额和重置周期。 Work 和 Codex 用的是另一个池子，OpenAI 叫它"智能体用量"（agentic usage）。帮助中心原文说：Codex、ChatGPT Work、ChatGPT for Excel 和 Workspace Agents 的用量从同一个智能体额度池中扣减。 所以你在 Chat 里聊天聊得再多，不会影响 Work 和 Codex 的额度。但 Work 和 Codex 之间会互相挤占。白天用 Work 跑了一堆复杂任务，晚上想用 Codex 写代码，可能会发现额度已经不多了。 【来源：https://help.openai.com/en/articles/11369540-using-codex-with-your-chatgpt-plan https://developers.openai.com/codex/pricing】 Q：要花多少钱？ Work 不是独立付费产品。它跟 Codex 共用同一个额度池，包含在你现有的 ChatGPT 订阅里。所有计划都能用，从免费到企业版，区别在于额度多少。 Free（免费）：能试用 Work 和 Codex，额度非常有限，试试味道可以。美国地区有广告。 Go（$8/月）：额度比免费多约 10 倍，桌面端可有限地用 GPT-5.6 Terra 跑 Work 和 Codex。没有 Deep Research 和 Agent Mode。有广告。 Plus（$20/月）：第一个去掉广告、功能完整的档位。包含 Deep Research（每月 10 次）、Codex、Agent Mode。三年没涨价，性价比最高。 Pro（$100 或 $200/月）：$100 档额度是 Plus 的 5 倍，$200 档是 20 倍。面向重度用户。 Business（$20/月/人起，年付；月付 $25）：至少 2 人，多了 SSO 和合规控制，数据默认不用于训练。 Enterprise（定制报价）：150 人起。 额度计费从今年 4 月开始改成按 Token 消耗计算。用更强的模型或开 Fast 模式，消耗更多。Plus 和 Pro 用户额度用完后可以购买额外 credits 继续使用。 【来源：https://chatgpt.com/pricing/ https://developers.openai.com/codex/pricing】 Q：GPT-5.6 的 Sol、Terra、Luna 是什么？我该用哪个？ 这是 GPT-5.6 的三个子型号。 Sol 最强，适合复杂推理和高难度编程，也最贵（API 价格 $5/$30 每百万 Token 输入/输出）。 Terra 居中，日常工作默认选它（$2.50/$15）。 Luna 最快最便宜，对速度敏感或任务简单时用（$1/$6）。 Free 和 Go 用户只能用 Terra。 Plus 及以上可以三个都选，还能调节 effort 级别。 ultra effort 在 Work 中仅限 Pro 和 Enterprise 用户，在 Codex 中 Plus 及以上可用。 【来源：https://www.developersdigest.tech/blog/chatgpt-work-codex-desktop-app https://chatgpt.com/pricing/】 Q：Work 上线后，原来的 ChatGPT 还在吗？ 在。Chat 模式就是原来的 ChatGPT，一切照旧。桌面端点"Quick chat"按钮就能开新对话，手机端在顶部下拉菜单选"Chat"。你可以完全无视 Work 和 Codex，继续像以前一样用。 【来源：https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex】 > 引用 @OpenAI: Introducing ChatGPT Work, a new agent in ChatGPT powered by Codex and GPT-5.6. > > It can take action across your apps and files, stay with a project for hours if needed, and turn a goal into finished work. > > It’s a whole new way to get work done.

Q：ChatGPT Work 桌面端和 Claude Cowork 桌面端有什么区别？ 两者现在都是桌面端智能体，都能操作本地文件，都能用 Computer Use 控制你的电脑，都支持定时任务。但实际用起来，路径和体验差别不小。 1. 执行架构不同。 Cowork 在你的电脑上运行一个隔离的 Linux 虚拟机作为沙箱，所有文件操作都在这个本地沙箱里完成，生成的文件（.docx、.xlsx、.pptx、.pdf）直接保存到你指定的文件夹。 ChatGPT Work 的桌面端继承了 Codex 的沙箱和权限控制体系，用操作系统原生隔离机制（macOS 上是 Seatbelt，Windows 上是 Windows Sandbox），同时还有一个内置浏览器，不需要额外装扩展就能上网查资料、操作网页工具。 2. 操作电脑的方式不同。 ChatGPT Work 桌面端的 Computer Use 可以在后台操作你的其他应用，点击、打字、移动文件，你会看到屏幕上出现一个"不是你在动"的第二个光标。 Cowork 也有 Computer Use（目前仍是研究预览阶段），通过 Claude in Chrome 扩展操作浏览器，通过桌面端直接操作应用。 3. 应用连接方式不同。 ChatGPT Work 用统一的 plugins 目录，60 多个连接器对接 Slack、Teams、Google Drive、SharePoint、Salesforce 等。你在提示词里用 @ 指定应用名就能拉数据。 Cowork 用 MCP（Model Context Protocol，模型上下文协议）连接器，对接 Slack、Notion、HubSpot、Jira、Linear 等，还有 11 个官方行业插件（销售、法务、营销、财务等），也支持自建插件。 4. 产品结构相似但不同。 ChatGPT 桌面端现在是三合一：Chat、Work、Codex 在同一个 App 里通过模式切换器选择。 Claude 桌面端最近也改版了，从原来的三个标签（Chat、Cowork、Code）合并成了两个标签：Home 和 Code。 Home 里 Chat 和 Cowork 共享同一个首页，对话、Cowork 任务、项目和文件都在同一个侧边栏里，你在消息框左下角切换 Chat 和 Cowork 模式。 Code 标签是 Claude Code 的桌面界面，专门用于软件开发。 结构上，两家现在很像：都是把日常对话、知识工作、编程三种模式塞进了同一个桌面 App。 5. 跨设备能力不同。 Claude Cowork 从 7 月 7 日开始向网页和手机端扩展（Beta，Max 用户优先，其他付费计划陆续开放）。 Cowork 任务现在可以远程跑在 Anthropic 的服务器上，关掉电脑也能继续执行，你可以在手机上查看进度、回复 Claude 的问题、或在另一台设备上接着干。定时任务也能在后台跑了。但有一个限制：如果任务需要读写本地文件、用浏览器、或用 Computer Use，你的桌面端 App 必须保持打开状态，远程会话通过桌面端去够这些本地资源。 ChatGPT 这边，Chat 对话可以在网页和桌面端之间同步。但 Work 对话目前不互通：网页/手机端创建的 Work 对话留在云端，不会出现在桌面端的 Work 里；桌面端的 Work 线程和本地文件也留在那台电脑上。Codex 桌面端任务不会出现在网页端，但可以通过手机 App 的 Remote 标签远程查看。 Claude Cowork 的跨设备同步走得更前面一步，同一个会话可以在桌面、网页、手机端之间流转。ChatGPT Work 目前云端和桌面端是割裂的，这是 OpenAI 明确说了"at launch"的限制，后续大概率会补上。 【来源：https://openai.com/index/chatgpt-for-your-most-ambitious-work/ https://www.eigent.ai/blog/chatgpt-work-vs-claude-cowork-which-agentic-workspace-fits-your-team https://www.leadwithai.co/article/chatgpt-work-is-here-openais-answer-to-claude-cowork https://support.claude.com/en/articles/15520349-use-claude-cowork-on-web-desktop-and-mobile https://claude.com/resources/tutorials/navigating-the-claude-desktop-app】