Twitter AI 编程动态 - 2026-05-10¶
1. 大家在讨论什么¶
1.1 Codex 正在扩展到 ChatGPT 移动端和 Chrome 🡕¶
最明确的方向性信号并不是新模型发布，而是新增了一组使用入口。多条帖子传播了同一套 Codex 移动端 UI，另一条帖子展示了 Codex 作为 ChatGPT 应用中的一级入口出现，还有一个独立讨论串贴出了 Codex 在 Chrome Web Store 的公开页面。与 5 月 9 日相比，讨论已经从对浏览器控制的泛泛兴趣，转向了移动端和浏览器 UI 的具体证据。
@testingcatalog 认为 认为，OpenAI 正在走向更深层的 Codex 与 ChatGPT 整合；他发出的第二张图片也是整个讨论串里最有力的证据：一个“设置 Codex 移动端”的弹窗，承诺可通过手机访问线程和项目，并在桌面任务完成后接收通知。这条帖子的重要性在于，它把模糊猜测变成了具体的工作流入口。
@ziwenxu_ 发帖 展示了一张 ChatGPT 应用截图，其中 Codex 与 Projects 和 Images 并列出现在导航中。这让移动端叙事不再只是预告图，而有了更具体的依据；与此同时，这个讨论串也补充了有价值的不确定性：@JustinGorya 回复 认为，这可能仍是现有的 Codex 云端流程，而不是一次全新发布；ziwenxu 则表示自己是在 Pro 方案中看到的，并猜测这可能取决于 GitHub repo。
@TimHaldorsson 链接到 提到了官方的 Codex Chrome 扩展程序列表。其公开描述称，Codex 可以在已登录的网站、仪表盘、表单以及多标签页测试流程中工作，并会在执行敏感操作、访问历史记录和传输文件前先征求同意。@bonsaixbt 提供了 也点出了这件事对用户的重要性：如果手机可以负责监控、通知和审批，而电脑继续工作，这个智能体就不再被绑在一台笔记本电脑会话上。
讨论洞察： 看多的回复大多默认跨设备控制只是时间问题。@gao035 提问 提问这是否意味着用户可以在手机上编程、由桌面端承担重活；而 ziwenxu 讨论串中最强的怀疑意见则认为，这个入口可能是较早的云端功能，而非全新的发布。
与前一日对比： 5 月 9 日已经有 Codex 浏览器控制相关讨论，但 5 月 10 日补上了公开的移动端 UI 截图和可查证的 Chrome 入口。
1.2 终端智能体正被打包成技能、MCP 技术栈和新手工作流 🡕¶
围绕 Claude Code 和 Copilot CLI 的讨论，焦点放在外围操作层，而不是原始生成质量。最有价值的帖子包括生态地图、打包好的浏览器扩展，以及关于面向智能体的 CLI 应如何诊断并从故障中恢复的明确设计模式。
@cyrilXBT 发帖 发布了一张名为“Claude 资源圣经”的图片，梳理了 Claude Code、Claude Cowork、Claude Design 和 MCP skills 的 52 项资源。这张图的意义在于，它把产品视为由文档、技能、多路复用器和框架组成的一整套栈，而不是一个孤立的编程助手。
@doodlestein 认为 表示，面向 AI 的 CLI 工具需要真正的 doctor mode；他引用的讨论串对这一模式的定义非常具体：结构化诊断、安全的自动修复、变更前备份，以及逐字节回滚。这比泛泛的提示词建议更具信号意义，因为它描述的是智能体工作流的一套具体恢复契约。
@tom_doerr 分享了 提到了 适用于 Claude Code 的 Playwright Skill，其 README 称，它可以即时编写并执行自定义 Playwright 自动化脚本，且默认使用可见浏览器。他还 分享了 Drawbridge 提到了另一个项目，其 README 介绍了一款 Chrome 扩展，可将浏览器评论和矩形标注转换成 Claude Code 或 Cursor 的任务。与此同时，@github 推广了 分享了一个 Copilot CLI 初学者系列，讲解安装、登录、文件夹权限、提示词编写，以及向云端智能体发送 /delegate。
@Axel_bitblaze69 描述道 分享了一个由 Perplexity、Playwright、Firecrawl、Glif 和 Chrome MCP 组成的“五 MCP 全自动化栈”。其中最有启发性的回复并不是吹捧，而是治理层面的提醒：@JamesClawn 回复 指出，搜索、抓取、浏览器控制和媒体生成需要分开授权，因为一个 MCP 白名单对于如此大的能力范围来说过于粗放。
讨论洞察： 反对意见针对的是操作者安全，而不是这些工具是否有效。随着 doctor mode、浏览器技能和权限边界成为重点，讨论已经从提示词技巧转向系统卫生。
与前一日对比： 5 月 9 日的重点是把 Claude Code 视为带有记忆和例程的个人操作系统；到 5 月 10 日，重心已经转向分发层：打包技能、精选 MCP 技术栈，以及官方新手引导。
1.3 用户正通过封装层、本地引擎和快速切换订阅来绕过限制 🡒¶
市场行为依然呈现多平台并用。人们仍在比较 Claude、Codex、Copilot 和 Cursor，但更有意思的帖子来自封装层、本地运行时，以及把模型厂商当作可互换组件的直接订阅调整。
@0xSero 表示 表示，KittyLitter 意味着他不再需要随身带笔记本电脑：这款应用支持 Codex、Claude Code、OpenCode、Pi，以及即将支持的 Droid；截图显示，一部手机正在驱动一个连接到家中机器的智能体会话。@mercury__agent 宣布 表示，Mercury v1.1.7 现在可以在一个工作流中接入 GitHub Copilot 和 OpenAI Codex；与此同时，@davideciffa 表示 表示，Lucebox 现在可以在本地基于 Qwen3.6-27B 运行 Codex、Hermes 和 OpenClaw，并支持 OpenAI 兼容的工具调用。这些都是编排层动作，而不是站队某一家供应商。
@ashen_one 写道 表示，他把每月 $200 的 Claude Code 订阅降级，转而购买了 $200 的 Codex 方案，因为一个 /goal 在大约两小时内把他的 iOS 应用本地化成了 23 种语言。后续讨论与这番成果同样重要：当 @shipwithjay 提问 提到 QA 风险时，ashen_one 表示 回应说，初步结果看起来不错，但阿拉伯语仍需更完整的测试。
在成本方面，@TheGeorgePu 将其表述为 把 Copilot、Cursor 和 Claude 视为一种新的持续性税负；@MrPunyapal 发帖 晒出了一张 GitHub Copilot 限流页面，显示还需等待 2 小时 32 分钟；@vatsal_sanghvi 表示自己即将在 $200 方案下触及 Codex 的每周上限；@alishohadaee 认为 则认为，按用量计费正把人们推向本地 AI 自主。@drop_grl 补充道 还补上了一个竞争层面的变化：Codex 可以从其他智能体导入设置、聊天会话、技能和插件。
讨论洞察： 即便是较轻量的讨论串，也呈现出碎片化而非共识。@zavxai 提问 询问大家每天用哪款 AI 编程工具，回复分散在 Claude、Cursor、Copilot、Gemini 和“不用 AI”之间；还有一条回复说，这个列表已经过时，因为漏掉了 Codex。
与前一日对比： 5 月 9 日已经出现订阅套利；到 5 月 10 日，这种行为通过移动端封装、设置导入、本地运行时和硬性限额截图，变得更具操作性。
2. 什么让人感到沮丧¶
硬性上限和持续性的 AI 租金 -- 高¶
成本挫败感既表现为预算抱怨，也表现为工作流中断。@TheGeorgePu 称之为 把 Copilot、Cursor 和 Claude 视为一种新的持续性税负；@MrPunyapal 展示了 晒出了一张 GitHub Copilot 限流页面，显示还需等待 2 小时 32 分钟；@vatsal_sanghvi 表示自己即便在 $200 档位，也快碰到 Codex 的每周上限。@alishohadaee 解读为 则把 Copilot 的按用量计费视为一个证明：补贴式 token 从来都不是稳态。
之所以定为“高”，是因为用户不只是在说这些工具贵；他们还在说，上限已经开始左右工具选择和工作安排。当前的应对方式包括同时维持多个订阅、在某家厂商约束较多时切换供应商，或寻找本地替代方案。值得投入建设：高。
CLI 和扩展栈仍需要更好的自诊断与权限管理 -- 高¶
@doodlestein 制作了 把抱怨说得很明确：面向智能体的 CLI 需要 doctor mode，能够诊断损坏状态、安全修复，并在修复出错时撤销更改。@Axel_bitblaze69 随后展示了问题的另一面：它把搜索、抓取、浏览器控制和媒体生成打包进同一个 MCP 技术栈，促使 @JamesClawn 指出，对于这么大的权限范围，一个白名单太粗糙了。
今天的应对方式，是在基础智能体之上继续叠加工具。Playwright Skill 为 Claude 提供自定义浏览器自动化；Drawbridge 则提供一条独立的浏览器到任务桥接，因为这种视觉上下文仍不是原生能力。之所以严重，是因为每新增一个插件或 MCP，固然能解决一个问题，却也会带来新的配置和权限故障模式。值得投入建设：高。
设备与上下文迁移依然别扭 -- 中¶
最强的移动端和迁移相关帖子，本质上都在抱怨工作流的不连续。@testingcatalog 和 @bonsaixbt 都把基于手机的 Codex 控制视为明显缺失的一层；@0xSero 称赞 KittyLitter，因为它意味着不再需要笔记本电脑、GPT 应用或 Discord；@drop_grl 则表示 Codex 现在可以从其他智能体导入设置、聊天记录、技能和插件。
这一挫败感处于中到高，因为工作流的各个组件虽已存在，但在手机、浏览器、终端和不同厂商之间，仍缺乏连贯感。当前的应对方式，是依赖封装层、非官方迁移路径，或为同一类智能体工作同时使用多个重叠入口。值得投入建设：中到高。
3. 人们希望存在什么¶
真正面向智能体 CLI 的 doctor mode¶
@doodlestein 明确表示，当前 CLI 工具应提供 doctor mode：识别常见故障状态、在修改前备份、安全修复，并支持撤销。这不是理想化愿景，而是实际需求：随着越来越多人把 MCP、浏览器插件和本地状态接入自己的智能体栈，一个可信赖的统一恢复入口会越来越有价值。部分答案已经以自定义技能和更好的聊天界面形式出现，但现有证据仍显示，人们依赖的主要还是临时性补丁，而不是内置标准。机会：直接。
用手机优先控制长时间运行的编程任务¶
那些泄露或浮现出来的 Codex 移动端痕迹之所以引人注目，是因为它们对应的是非常具体的愿望。@testingcatalog 展示了一个弹窗，承诺可通过手机访问线程和项目，并接收完成通知；@bonsaixbt 明确写出了通过口袋里的设备进行监控和审批；@0xSero 则已经在使用 KittyLitter，以避免携带笔记本电脑。这是一个已有部分解决方案的实际需求，但公开证据仍然分散在小范围上线、截图和第三方封装层之间。机会：直接。
能在高价方案触顶后继续工作的后备路径¶
人们追求的不是抽象意义上的省钱，而是不在方案上限触发时让工作流停摆。@MrPunyapal 表示，GitHub Copilot 在达到会话上限后会把他挡在门外；@vatsal_sanghvi 表示，即便是 $200 的 Codex 档位，也可能碰到每周上限；@alishohadaee 则把按用量计费解读为推动本地算力的力量。这个需求既实际又紧迫：用户希望能优雅地回退到更便宜、本地或免费的选项，同时不丢失自己已经熟悉的智能体工作流。机会：直接。
对迁移友好的多供应商智能体配置¶
最能说明可移植性的信号，不是基准测试，而是一项迁移功能。@drop_grl 表示，Codex 可以从其他智能体导入设置、聊天会话、技能和插件；@mercury__agent 和 @davideciffa 则展示了已经位于单个供应商之上的封装层。这是实际需求，因为用户显然正在公开切换、同时使用多个平台并比较工具。部分解决方案已经存在，但默认工作流仍然过于绑定特定厂商。机会：竞争性。
4. 正在使用的工具和方法¶
| 工具 | 类别 | 情绪 | 优势 | 局限 |
|---|---|---|---|---|
| OpenAI Codex / ChatGPT mobile | 编程智能体与移动端入口 | (+/-) | 自主运行能力强，为线程/项目提供明确的手机入口，并在应用本地化上有可见成果 | 移动端上线范围仍不明确，部分证据指向较早的云端流程，重度用户仍报告每周限额 |
| Codex Chrome extension | 浏览器智能体 | (+/-) | 可在已登录网站、标签组、仪表盘、表单和测试流程中工作；执行敏感操作前会征求同意 | 仅限 Chrome，且较广的浏览器/数据访问扩大了信任面 |
| Claude Code | 终端智能体 | (+) | 拥有丰富的技能、MCP、资源地图和浏览器扩展生态 | 用户正积极将其与 Codex 比较，并要求更好的诊断与恢复能力 |
| GitHub Copilot CLI | 终端智能体 | (+/-) | 新手引导友好、支持仓库感知聊天、/delegate，并且工作流原生适配终端 |
会话上限会打断工作，并把用户推向其他智能体 |
| Playwright Skill for Claude Code | Claude 技能 | (+) | 按需生成并执行 Playwright 自动化，默认使用可见浏览器，并已被打包成插件 | 需要单独配置和浏览器依赖 |
| Drawbridge | 浏览器到代码桥 | (+) | 将浏览器中的可视化评论转换成结构化的 Claude Code 或 Cursor 任务，并支持不同处理模式 | 需要 Chrome 扩展权限、本地文件权限，以及额外的一层工作流 |
| KittyLitter | 移动端封装层 | (+) | 用一个手机入口统一接入 Codex、Claude Code、OpenCode、Pi 和本地模型 | 公开讨论中关于远程连接细节的信息仍然较少 |
| Mercury Agent | 编排器 | (+) | 一个工作流即可接通 Copilot 和 Codex 生态 | 当前证据主要来自发布帖，缺乏更深入的用户报告 |
| Lucebox | 本地推理引擎 | (+) | 为 Codex、Hermes 和 OpenClaw 提供本地运行时，并支持 OpenAI 兼容工具调用 | 公开证据目前仅限于单条偏发布性质的演示说法 |
| MCP stack (Perplexity, Playwright, Firecrawl, Chrome, Glif) | 扩展层 | (+/-) | 增加实时搜索、抓取、浏览器控制、页面检查和媒体生成能力 | 权限边界与能力重叠问题仍未解决 |
从表格往下看，最主要的模式是组合。人们正在把主智能体与移动端封装层、编排层、浏览器技能或 MCP 套件搭配使用，而不是只押注单一入口。@0xSero、@mercury__agent 和 @davideciffa 都描述了在保留工作流的同时更换底层供应商的不同方式。
常见的应对方式也很清楚：当某个方案限制更多时切换订阅；为基础智能体看不到的任务补上浏览器工具；当用量上限开始带来痛感时，转向本地或 OpenAI 兼容运行时。如今的竞争压力不仅来自模型质量，也来自入口与周边能力：Codex 依靠移动端、浏览器和迁移功能获得动能；Claude Code 通过技能和 MCP 生态保持强势；Copilot CLI 则借助新手教育扩大覆盖面，同时仍因限额问题遭到抱怨。
5. 人们正在构建什么¶
| 项目 | 构建者 | 功能 | 解决的问题 | 技术栈 | 阶段 | 链接 |
|---|---|---|---|---|---|---|
| KittyLitter | @0xSero | 面向 Codex、Claude Code、OpenCode、Pi 和本地模型智能体的移动应用 | 让人们无需携带笔记本电脑，也能在手机上延续智能体工作流 | 移动应用、家用机器远程访问、多智能体封装层 | Beta | 帖子 |
| Playwright Skill for Claude Code | lackeyjb | 能编写并运行自定义 Playwright 自动化的 Claude 技能与插件 | 按需为 Claude 提供可复用的浏览器测试和自动化能力 | JavaScript、Node.js、Playwright、Claude skill/plugin | 已发布 | 仓库, 帖子 |
| Drawbridge | breschio | 把浏览器标注转成 Claude Code 或 Cursor 任务的 Chrome 扩展 | 为 UI 编辑增加视觉上下文和具备依赖感知的任务处理 | JavaScript、Chrome 扩展、Markdown/JSON 任务桥接 | 已发布 | 仓库, 帖子 |
| Mercury Agent v1.1.7 | @mercury__agent | 在 Mercury 中连接 Copilot 和 Codex | 在多个付费生态之间维持同一套工作流 | Mercury、GitHub Copilot、OpenAI Codex | 已发布 | 帖子 |
| Lucebox | @davideciffa | 在 Qwen3.6-27B 上运行 Codex、Hermes 和 OpenClaw 的本地推测式推理引擎 | 把多智能体工具调用工作流带到本地运行时 | Qwen3.6-27B、推测式推理、OpenAI 兼容工具调用 | Alpha | 帖子 |
最清晰的构建者模式，是在基础模型之上搭基础设施。KittyLitter、Mercury 和 Lucebox 都把用户工作流从单一供应商中抽离出来：一个把入口搬到手机，一个统一多个付费生态，一个把整个执行层推向本地。这一点很重要，因为围绕限额和切换的相关帖子已经说明了这种胶水层为何有价值。
第二种模式是浏览器到代码的反馈闭环。适用于 Claude Code 的 Playwright Skill 的 README 称，Claude 可以按需编写并执行自定义 Playwright 自动化；Drawbridge 则把评论和浏览器中的自由矩形标注转成面向 Claude Code 或 Cursor 的结构化任务。两者体现的是同一个动作：为智能体接入更丰富的前端上下文，而不是让它仅凭文本去猜。
ashen_one 的本地化讨论串也可视为一种构建模式，尽管它不是一个全新的独立产品。重点不在应用本身，而在于一个 /goal 被用来推进一项真实的 iOS 待办工作，把应用扩展到 23 种语言；而后续讨论也立刻转向 QA 和布局损坏，而不是争论智能体能不能干成这件事。这传递出的成熟度信号，与玩具式演示不同。
6. 新动态与值得关注的变化¶
迁移体验正成为竞争功能¶
@drop_grl 表示 表示，OpenAI 现在正把 Codex 宣传为可从其他智能体导入设置、聊天会话、技能和插件。这一点很重要，因为它把“切换”本身变成了产品的一部分。同一天，@mercury__agent 发布了一个可在同一工作流中连接 Copilot 和 Codex 的版本，指向的是同一个方向：厂商和编排器现在都在竞争，谁能让用户以最少的重配置完成迁移。
Doctor mode 正在变成智能体原生的产品要求¶
@doodlestein 要的并不是一个模糊的故障排查命令。他描述的是一种可以检测故障状态、先做备份、安全修复并回滚变更的 doctor mode，这正是自主编程智能体可以依赖的契约。在一个充满 MCP 套件、浏览器插件和跨设备入口的信息流里，这项要求看起来很及时，而不是停留在理论层面。
7. 机会在哪里¶
** +++］ 具备安全审批闭环的跨设备编码控制** —— 反复出现的 Codex 移动端截图、Chrome 扩展列表以及 KittyLitter 的移动封装都指向同一个缺口：人们希望长时间运行的编码任务在离开笔记本电脑时也能继续推进，但仍然需要通知、审批和范围受限的控制。证据来自 ［@testingcatalog、@ziwenxu_、@bonsaixbt、@TimHaldorsson 和 @0xSero 使其成为近期最强的机会。
** +++］ 感知限制的编排与本地回退机制** —— Mercury、Lucebox、KittyLitter、反复征税话题线程，以及对 Copilot/Codex 配额上限的抱怨，都在描述同一个缺失层：当某个提供方变得过于昂贵、过于缓慢或暂时触及上限时，工作流仍能继续运行。证据来自 ［@mercury__agent、@davideciffa、@TheGeorgePu、@MrPunyapal、@vatsal_sanghvi 和 @alishohadaee 让这种痛点变得具体可感。
** ++］ 代理诊断与感知权限的恢复界面** —— doctor 模式相关讨论和对 MCP 权限的反对意见都表明，更强大的代理栈需要更好的故障处理和更严格的作用域控制。证据来自 ［@doodlestein、@Axel_bitblaze69 和 @JamesClawn 表明，结合安全修复、审计轨迹和更细粒度权限的产品仍有空间。
** ++］ 浏览器到代码的反馈与测试闭环** —— Drawbridge、Playwright Skill 和 Codex for Chrome 展示出一种反复出现的工作流模式：价值不仅在于代码生成，更在于把可视状态和实时浏览器上下文回连给代理。证据来自 ［@tom_doerr、@tom_doerr 和 @TimHaldorsson 表明，这不只是一次性的演示类别。
8. 核心结论¶
- ** 最大的产品信号来自入口扩展，而不是新模型。** Codex 移动端截图和公开的 Chrome 扩展页面，比任何基准测试或提示词讨论都更重要，因为它们展示了智能体工作流下一步的发展方向。（testingcatalog, TimHaldorsson）
- ** AI 编程讨论正从提示词转向操作系统。** 最有分量的 Claude Code 和 Copilot CLI 帖子，讨论的是技能、精选栈、新手引导和恢复模式，而不是原始文本生成质量。（cyrilXBT, doodlestein, github）
- ** 用户已经开始围绕供应商限制自建方案，而不是等待供应商来修。** 移动端封装层、编排层和本地运行时，与持续性税负抱怨和硬性上限截图在同一天同时出现。（0xSero, mercury__agent, MrPunyapal）
- ** 切换订阅正成为一种常见的优化路径。** ashen_one 的讨论串显示，一名用户因为一个
/goal处理了真实的本地化待办事项，便从 Claude Code 转向 Codex；而 drop_grl 的帖子则显示，连迁移工具本身都已成为产品竞争的一部分。（ashen_one, drop_grl） - ** 最有实质性的构建活动集中在胶水层。** Playwright Skill、Drawbridge、KittyLitter、Mercury 和 Lucebox 都位于基础模型之上或周边，让工作流变得更易用、更可迁移或更可观测。（tom_doerr, tom_doerr, davideciffa）