Tibo@thsottiaux · 5月16日43

We are busy bringing ChatGPT to Codex so that we can bring Codex to ChatGPT. One day this will make sense.

译我们正忙于将ChatGPT引入Codex，以便未来能将Codex引入ChatGPT。终有一日这会变得顺理成章。

Peter Steinberger 🦞@steipete · 5月16日27

Been using @sveltejs for a few projects lately, it's quite a nice alternative to React, fewer gotchas and complexity and Codex handles it really well. https://svelte.dev/

译最近在几个项目中使用了 @sveltejs，它是 React 的一个很好的替代方案，陷阱和复杂性更少，而且 Codex 处理得非常好。https://svelte.dev/

🚨 AI News | TestingCatalog@testingcatalog · 5月16日59

Zed ❤️ ChatGPT Open-source IDE Zed now supports ChatGPT subscription in the Zed Agent.

译Zed ❤️ ChatGPT 开源IDE Zed现已在Zed Agent中支持ChatGPT订阅服务。

Peter Steinberger 🦞@steipete · 5月16日75

🩹 clawpatch 0.1.0 is live: Clawpatch maps codebases into semantic feature slices, reviews them for bugs and quality issues, and records explicit fix attempts with validation. You'll be surprised how much this will find. npm install -g clawpatch https://clawpatch.ai

译🩹 clawpatch 0.1.0 已上线： Clawpatch 将代码库映射成语义功能切片，审查其中的错误和质量问题，并记录经过验证的明确修复尝试。 您会发现它能发现的问题之多令人惊讶。 npm install -g clawpatch https://clawpatch.ai

Yuchen Jin@Yuchenj_UW · 5月16日60

Anthropic got xAI’s GPUs, and then they immediately started running the Codex playbook. Competition is good for developers.

译Anthropic获得了xAI的GPU资源， 随后他们立即启动了Codex竞争策略。 竞争对开发者有益。

Epoch AI@EpochAIResearch · 5月16日64

Claude is typically better at software engineering and worse at math than frontier competitors. Aggregating benchmarks to create our domain-specific ECI, we find the Claude family has an average SWE-ECI 2.7 points higher than their general ECI, and a Math-ECI 1.8 points lower.

译Claude通常在软件工程方面优于前沿竞争对手，数学方面则稍逊。 根据我们汇总基准测试创建的领域特定ECI指标，Claude家族的软件工程ECI平均比通用ECI高2.7分，数学ECI则低1.8分。

Yuchen Jin@Yuchenj_UW · 5月16日14

Real men only use: - Github - X - Claude Code/Codex

译真男人只用： - Github - X - Claude Code/Codex

elvis@omarsar0 · 5月16日56

// Is Grep All You Need? // Pay attention to this on, AI devs. (bookmark it) They find that grep-style text search, when wrapped in the right agent harness, matches or beats embedding-based retrieval on coding-agent tasks. Are vector databases even needed where this is all going? It might be that what coding agents needed was not better embeddings. It was better harness design around primitive tools. If you operate a coding-agent stack that depends on a vector DB, it might be time to re-evaluate. My personal experience on this has been that agentic search, if done right, is more than good enough for a lot of use cases. But you also have to understand how to properly index and structure information for the agents to take advantage. At scale, vector databases do shine so take that into account as well. In most cases, a hybrid approach often works best but that's something we haven't figured out really well as of yet. Paper: https://arxiv.org/abs/2605.15184 Learn to build effective AI agents in our academy: https://academy.dair.ai/

译一项研究发现，将grep风格的文本搜索置于合适的智能体框架中，在代码智能体任务上的表现可匹配甚至超越基于嵌入向量的检索方法。这引发了对向量数据库必要性的质疑，核心观点指出代码智能体可能并非需要更好的嵌入模型，而是需要对基础工具进行更优的框架设计。作者建议依赖向量数据库的代码智能体栈应重新评估方案。虽然向量数据库在大规模场景中仍有优势，但智能体搜索若设计得当，已能满足多数用例。目前，结合两者的混合方法通常最优，但尚未被充分掌握。

歸藏(guizang.ai)@op7418 · 5月15日65

最近很多 Claude Code 的保姆级教程很火。 现在 Anthropic 官方出了一个 Claude Code 的保姆级教程，总共 9 节课，叫 Claude Code 101。 这玩意不比互联网上所有的 Claude Code 入门教程牛皮？ 装个沉浸式翻译插件看一看，你就是 Claude Code 的专家了，冲 九节课的内容分别是： Claude Code 是什么？ 如何安装？ 底层工作方式？ 教你写第一个高质量 Claude Code 的提示词。 什么是 Claude.md？ Explore 模式、Plan 模式和 Code 模式。 MCP 是什么？ 如何管理上下文？ 怎么用 Hooks？

译Anthropic官方推出Claude Code 101教程，共9节课系统讲解Claude Code的定义、安装、工作方式、提示词编写、三种模式、MCP协议、上下文管理及Hooks使用等核心内容，为学习者提供权威学习路径。建议配合翻译插件加速掌握。

Berryxia.AI@berryxia · 5月15日45

Qwen 3.6 Plus & OpenCode 免费开整啊！！！

🚨 AI News | TestingCatalog@testingcatalog · 5月15日34

OpenAI is working on a dedicated setting for Codex to allow users to enable "Locked use." > Let Codex use your Mac while it's locked No more need to carry a half-open laptop around?

译OpenAI正在为Codex开发专用设置，允许用户启用“锁定使用”。 > 让Codex在Mac锁定时继续使用 无需再随身携带半开状态的笔记本电脑？

凡人小北@frxiaobei · 5月15日69

我的 ipad 又香了

Peter Steinberger 🦞@steipete · 5月15日62

built a new feature into discrawl (store media), codex said it's done, then I used my codex review skill... https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

译为discrawl（存储媒体）构建了一个新功能， codex说它已完成， 然后我使用了我的codex审查技能... https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

Peter Steinberger 🦞@steipete · 5月15日79

This is a game changer. With codex autoreview and crabbox I can now go from issue to fix almost fully automated. (yes it does burn lots of tokens)

译这改变了游戏规则。通过codex自动审查和crabbox，我现在几乎可以全自动化地从问题定位到修复。（是的，这会消耗大量token） [引用 @steipete]：编写了一个循环运行codex/review的技能，直到不再出现错误为止。 注意事项：它不会为你修复系统架构，所以你仍然需要以BRAIN作为主模型。https://github.com/steipete/agent-scripts/blob/main/skills/codex-review/SKILL.md

Peter Steinberger 🦞@steipete · 5月15日50

CodexBar 0.26.0 is live ⚡ Kiro, Antigravity, OpenRouter, Kimi 🧭 calmer menus + keyboard nav 📊 better Codex/Claude limits and cost scoping 📦 named macOS assets, CLI + Homebrew fixes https://github.com/steipete/CodexBar/releases/tag/v0.26.0

译CodexBar 0.26.0 已上线 ⚡ Kiro、Antigravity、OpenRouter、Kimi 🧭 更简洁的菜单 + 键盘导航 📊 改进的 Codex/Claude 限制与成本范围 📦 命名的 macOS 资源、CLI + Homebrew 修复 https://github.com/steipete/CodexBar/releases/tag/v0.26.0

宝玉@dotey · 5月15日58

Bitcoin 玩家 cprkrn 在发帖说自己靠 Claude 找回了 11 年前丢掉的 5 个 BTC，按现价大约 40 万美元。 事情要追溯到十一年前。他当时嗑嗨了，改了钱包密码，转头就忘。这 5 个 BTC 不是 HD 钱包靠助记词派生出来的那种地址，而是早期钱包里混入的导入私钥，必须靠加密钱包文件加密码才能开。密码丢了，钥匙就锁死了。 他这些年一直没放弃。手里攒了几个候选密码、几个旧钱包文件，跑了 btcrecover(一个开源的比特币钱包恢复工具)，始终破不开。 几周前，他在大学时代的旧笔记本里翻出一串助记词，输进去派生出的地址刚好对上电脑里某个加密钱包文件——目标锁定了，但文件还是打不开。 走投无路，他把整个大学时代的电脑数据一股脑丢给 Claude。Claude 翻出两样东西：一个 2019 年 12 月的更早的钱包备份(这版本可能在密码被改之前)，以及 btcrecover 在拼接 shared key 和候选密码时的一个 bug。Bug 修掉，重新跑一遍，私钥解开，5 个 BTC 顺利转出。 Tom's Hardware 的标题是“尝试了 3.5 万亿次密码”，画面感很强，但 Claude 实际干的事要朴素得多：在一堆十年前的乱七八糟文件里翻出那个被忽略的旧备份，再看懂开源工具里的一处逻辑错误。翻遗物加调 bug，这正是 LLM 现在做得相对靠谱的活。 对照一下，2024 年研究人员靠传统手段暴力破解一个 20 字符密码、撬开价值 160 万美元的比特币钱包，花了大半年。至于那位把装着 8000 BTC 的硬盘扔进威尔士垃圾场、2025 年被法院判决不许再去翻的英国兄弟，就没这份运气了。

译一名比特币玩家通过Claude成功找回11年前因密码遗忘而锁定的5个BTC（现价约40万美元）。关键并非暴力破解，而是Claude从其大学时代的混乱数据中，定位到一个可能早于密码更改的2019年钱包备份，并发现了开源恢复工具btcrecover中的一个逻辑错误。修复该错误后，钱包被成功解锁。相比之下，传统暴力破解方法耗时漫长，凸显了LLM在处理复杂历史数据与代码逻辑问题上的实用价值。

Elon Musk@elonmusk · 5月15日62

Go in with expectations that Grok Build is still beta, but improving almost every day

译Grok Build早期测试版已向SuperGrok Heavy用户开放，初期开发者反馈极为积极。用户认为它感觉比其他编码智能体领先十倍，能原生处理完整智能体工作流、并行运行多个智能体、进行实时代码重构，并拥有支持vim模式和鼠标的精致终端界面。该工具速度快，可清晰管理大上下文，让用户体验类似与自主编码伙伴协作，而非仅获取建议。若测试版保持此发展势头，Grok Build有望成为高级用户的强大工具。

ChatGPT@ChatGPTapp · 5月15日69

Touch grass and leave your laptop—Codex is now on your phone. Now in preview on the ChatGPT mobile app.

译放下电脑接触自然——Codex现已登陆手机。 现已在ChatGPT移动应用开启预览。

歸藏(guizang.ai)@op7418 · 5月15日62

GitHub 发布了 GitHub Copilot 桌面端的技术预览版。 看起来跟 Codex 长得有点像，在 GitHub 相关功能上露出的也比较多。 现在需要申请 waitlist

AYi@AYi_AInotes · 5月15日77

Damn，xAI今天发布的Grok Build， 可能是今年到目前为止最重要的AI产品， 我看很多人还在吐槽它没有漂亮的网页界面，吐槽它贵得离谱， 但就是没人看懂这是代理时代真正到来的第一个明确信号， 铁铁们，这可不是又一个帮你补代码的助手之类的产品， 它能让你指挥一整支AI工程军团的指挥中心， 没有做花里胡哨的GUI， 反而选择了最老派的纯终端界面， 很多人觉得这是偷懒， 我觉得现在这个其实才是最聪明的战略选择， 因为CLI天生支持脚本化， 支持版本控制， 能和所有现有开发工具链无缝对接， GUI反而会成为代理执行的最大瓶颈， 其中最核心的突破是并行子代理机制， 以前的AI编码工具是一个人帮你干活，你得一步步教它， 现在是一个主代理统筹全局， 同时派出研究，写代码，审逻辑，做设计的多个子代理并行推进， 这简直就是结构化的效率革命啊， 所以我觉得那个99美元每月的高价订阅也不是为了赚钱， 相当于给你一个精准的高质量数据过滤器， xAI不需要海量玩票用户的低质反馈， 它要的是重度开发者在真实项目里产生的深度训练信号， 用高价把噪声全部筛掉，留下的每一个用户都是帮它打磨产品的免费工程师， 很多人以为这样AI会让终端彻底消失， 实际上AI正在给这个诞生了半个多世纪的老工具注入全新的灵魂， 未来最值钱的技能可能不再是自己敲代码， 而是如何指挥一群AI代理高效协作完成复杂项目， 初级开发者的工作会被大量替代， 但高级开发者会变成真正的代理军团指挥官， xAI没有等模型在编码上做到完美就把产品扔了出来， 因为它知道真实世界的使用才是最好的训练数据， 边打边练，以战养战， 这才是xAI最可怕的地方， 四年后当所有人都在用AI代理构建产品的时候， 今天所有吐槽它贵，吐槽它难用的人， 都会明白这步棋的真正分量，让们拭目以待咯 #xAI #Grok #AIAgent

译xAI推出Grok Build早期beta版，这是一个面向SuperGrok Heavy订阅者的代理CLI工具。其核心突破在于并行子代理机制，主代理可指挥多个子代理协同执行编码、研究等任务，实现结构化效率革命。战略上选择CLI界面，以支持脚本化、版本控制及与开发现有工具链集成。高价订阅旨在筛选重度开发者，获取真实项目中的高质量训练数据，加速产品迭代。此举标志着AI代理时代正式开启，未来开发者角色将向指挥AI代理军团协作转变。

向阳乔木@vista8 · 5月15日73

如何在ChatGPT 客户端用Codex？ 很多人发新闻，就不发教程！其实配置稍微有点麻烦。 1. 更新Codex 本地客户端。 左侧会出现“设置 Codex 移动版”的入口。 注意！！！ 必须用官方订阅账号，API模式看不到这个入口。 2. 点击设置入口。 进去要求扫码，一定用苹果或安卓源生相机扫码。 （ChatGPT没找到扫码按钮，微信好像不行） 3. 登录ChatGPT账号（哪怕你App已登录账号） 4. 授权后搞定。 后续可改是否让电脑保持唤醒状态。 客户端下载地址见评论

译在ChatGPT客户端中使用Codex需先更新本地客户端，左侧会出现“设置 Codex 移动版”入口，但必须使用官方订阅账号，API模式无法显示。点击入口后，需用苹果或安卓原生相机扫码，ChatGPT应用内无扫码功能且微信不适用。接着登录ChatGPT账号，即使App已登录也需重新验证。授权后即可完成配置，后续可调整电脑保持唤醒状态的设置。客户端下载地址见评论。

歸藏(guizang.ai)@op7418 · 5月15日24

嘉琛的 bridge 有些设计和能力真的很顶

译主推文称赞Bridge的设计与能力。创始人引用观点，强调应追求让少数用户“爱上”产品，而非让大量用户仅“有点喜欢”。他认为“优秀是卓越的阻碍”，过于“优秀”的创始人或产品常因退路多而难以坚持完成“最后一公里”。这与“Do things that don't scale”理念一致。因此，Bridge决定采用邀请码机制，旨在与早期用户建立深度联系，共同探索产品的独特价值，营造良好早期氛围。

宝玉@dotey · 5月15日70

http://x.com/i/article/2054823397448712192 # 为什么资深开发者讲不清自己的专业能力 作者：Tuhin Nair 原文：Why senior developers fail to communicate their expertise 你对下面这句话有什么感觉？ > “AI 智能体 (AI agents) 是软件开发的未来。我们再也不需要那些拖慢业务进度的开发人员了。” 如果你是一位资深开发者，并且认同这句话，那我可能要对你的专业水平打个问号了（我会解释原因的，我并不是在故意找茬）。 但如果你不是资深开发者，却认同这句话，我觉得你大概率是对的。 咦？这到底是怎么回事？ 广告文案 (Copywriting) 的本质，其实就是让信息精准匹配它的受众。 所以，在我这个文案工作者看来，这里发生的事情是：同一句话，在两类不同的受众听来，有着截然不同的含义。 如果你是一位资深开发者，并且你已经玩过那些让人大开眼界的 AI 智能体、大模型以及各种花哨的 AI 技能，但你的直觉依然告诉你：“大家都在宣扬程序员要失业了，这事儿听起来总觉得哪里不对劲”。那么在这篇文章里，我将尝试把你这种说不清道不明的直觉，用清晰的文字表达出来（这正是一个优秀文案该干的活）。 但是等一下！现在也有很多经验丰富的知名开发者在宣告“程序员已死”。 这又是怎么回事？到底谁的直觉是对的？是什么导致了这种分歧？ 当我加入一个团队时，通常会遇到两类资深开发者。 第一类会说这样的话： > “我发现了一个新工具，简直太酷了……”“某某公司（一家和我们业务完全不搭边的公司）就是这么干的，所以……”“快看 HackerNews 上的这篇帖子，上面说这是最佳实践，我们也许应该……” 说实话，我不太喜欢这类资深开发者。他们往往有点自我保护欲，在行业里混了很久，可能人缘还不错。但我们就是不在一个频道上。 接着是第二类资深开发者： > “我们真的需要那个功能吗？”“如果我们不做这个，会发生什么？”“我们能不能先凑合一下？也许等它变得更重要的时候再回过头来弄？” 啊，宝贝，这才是我的“梦中情怪”资深开发者。他们是回避者、精简者、废物利用者。他们想尽一切办法去避免写代码。 为什么？因为他们在专业的软件开发生涯中，毕生都在狩猎一只可怕的怪物：复杂性 (Complexity)。 各种特殊情况、一堆的 if 条件判断、新建的数据库表、全新的组件。这些全都是让人头疼的大麻烦**（因为它们极大增加了系统维护和理解的难度）**。资深开发者希望这些东西越少越好，他们会花大量时间去反复确认，是不是真的非写这段代码不可。 因为给系统做加法，就意味着增加了复杂性的风险。 是的，是的，我承认这么说有些过于绝对了。当然有很多资深开发者擅长攻克未解难题，并提出富有创意的新架构。 但归根结底，如果你要对一个正在平稳运行的系统负责，你就会对复杂性感到恐惧。 那么，这到底是为什么呢？复杂性到底有什么坏处？又为什么其他人都无法理解这种恐惧呢？ 我们打算用两个“循环圈”来简化并解释一家公司的运作方式。 这是第一个循环圈；市场营销人员、销售人员、产品经理以及 CEO，他们都生活在这个圈里： 第一个循环：业务团队通过快速尝试、市场反馈和学习，持续降低不确定性。 这个循环的核心目标是尝试与学习。企业想要把产品推向市场，然后获取反馈，看看他们搞出来的东西到底有没有价值。 对于身处这个循环里的人来说，他们要面对的怪物是：不确定性 (Uncertainty)。 不确定性是残酷的，因为没有任何策略能保证百分之百奏效。当不确定性与时间交织在一起时（比如营销和销售的薪水、创始人的工资账单，或者产品经理急需的数据），你会感觉：在死线到来之前，尽可能快地把东西推向市场，似乎是降低不确定性的唯一途径。你推向市场的东西越多，得到的反馈就越多，你（潜在地）消除的不确定性也就越多。 这个循环——也是所有公司起步时的必经之路——追求的是纯粹的、原始的速度。 但是，当一家公司开始拥有客户时，会发生什么呢？ 啊哈，现在，我们的第二个循环圈登场了。人们开始为服务付费了。 第二个循环：付费客户依赖现有服务，资深开发者通过控制复杂性来维持长期稳定。 很多资深开发者就身处这个循环圈中。这个循环的核心目标是：延续并保障服务的稳定。 保持系统运转，保持代码易读，保持问题可调试，保持故障可修复，保持架构可传授给新人，最重要的是，保持稳定。 资深开发者之所以操心稳定性，是因为他们肩负着让公司能够持续为客户提供服务的重任。 而什么会威胁到这一切？ 复杂性。 复杂性会让系统变得难以理解、难以调试、难以修复、难以交接，并最终导致系统变得极不稳定。 复杂性上升 = 稳定性下降 = 资深开发者失职 = 糟糕透顶，客户付款中断，所有人都愁眉苦脸。 所以，如果说第一个循环的目标是“消除不确定性”，那么第二个循环的目标就是“管理复杂性”。 但这为什么会导致沟通上的失败呢？ 因为一旦你有了客户，这两个循环圈就会同时运转。一家公司既需要探索新的可能性，又必须同时服务好现有的客户。 有客户之后，公司必须同时探索新可能，也必须守住现有客户。 好了，现在你可能已经猜到我对文章标题那个问题的答案了。 根据你把时间主要花在哪一个循环圈里，你对问题的认知框架是完全不同的（这也就是为什么我认为开发者在对待 AI 的观点上会产生分歧；有些人更多地在第一个循环里工作，而另一些人则在第二个循环里）。 同一个需求，两种解读：业务看到更快验证，开发者看到更多代码路径和维护成本。 在第一个循环圈里的人，他们的故事是这样的： 业务端的故事：他们要的不是代码本身，而是更快知道答案。 但在第二个循环圈里的资深开发者，他们的故事却是这样的： 开发者的故事：真正的专业价值，是用更少复杂性换来更快确定性。 这两种故事根本搭不上调。 资深开发者接到的“新增功能”需求越多，他们就越想回怼：“呃，不行……这太复杂了……维护成本太高……代码没法读了……后续开发速度会变慢……长期来看会拖累生产力……”。 但是，这些牢骚对于业务端“急需消除不确定性”的诉求来说，毫无帮助。 文案的诊断结果：你不能用你自己的烦恼，去搪塞别人的问题。 文案开出的处方：你必须把你的解决方案，包装成同样能解决他们问题的方案。 资深开发者之所以沟通失败，是因为他们总是在用“复杂性管理”的逻辑来表达自己的苦衷，而他们本该用“消除不确定性”的逻辑来推销自己的解决方案。 只要资深开发者能意识到公司其他部门真正渴望的是消除不确定性，他们就能利用自己的专业能力来提供帮助了。 那么，资深开发者最拿手的本领是什么？是不情愿去开发没必要的东西；是能够敏锐地发现复用现有代码的机会。 需要收集问卷数据？ 用 Google 表单就行了，宝贝。 需要开发一个新功能来做测试？ 你们有没有试过在现有的 UI 界面上加个假按钮，看看有没有人点？（也就是所谓的“画饼测试”或验证性测试） 需要一套新的数据分析服务？ 我们需要看数据来做出的最关键决策是什么？我们能不能只针对这一个决策，先做一个图表、看一个指标？ 你想费劲给我烤个完整的生日蛋糕？ 算了吧，直接在我的三明治上插根蜡烛就行。 这就是资深开发者学到的生存之道：他们学会了如何利用现有的软件资源，巧妙地给别人想要的东西。 但是，你该如何沟通这一点，而不至于每次都要给别人写篇小作文呢？ 文案们最喜欢把一堆复杂的信息浓缩成一句简短有力的话。所以，这里有一句每个资深开发者都必须背诵的魔法口诀：“我们能不能试个更快的办法？” 用“更快 (quicker)”这个词，是承认并迎合了业务端真正的渴望（速度）；“办法 (something)”暗示了还有别的方式可以达成目标；而“试 (try)”则暗示了这个方案可能并不完美，但很可能已经足够好了。 这句话完美地切中了公司其他部门的核心需求——用速度来消除不确定性，同时也让资深开发者能够尽情施展他们的专业特长：精简功能、复用代码，如果老天保佑的话，完全避免开发。 就是这样。这就是我对文章标题的回答：当所有人都在为“不确定性”焦头烂额时，资深开发者却总是在把“复杂性”挂在嘴边。 但是！大大的转折来了！ 现在的 AI 似乎让这一切都变得毫无意义了，不是吗？为什么还要精简？为什么还要复用？为什么还要避免开发？AI 可以在极短的时间内写出海量的代码。 唉，话虽如此，但有一件事 AI 至今还做不到，而这也正是资深开发者依然在坚持做的事。 承担责任 (Take responsibility)——背锅。

译资深开发者与业务团队存在根本认知差异。业务团队生活在“消除不确定性”的循环中，追求快速试错验证，核心是速度。而资深开发者身处“管理复杂性”的循环，核心职责是保障付费服务的长期稳定，因此对增加系统复杂性的行为极为警惕。沟通失败在于，开发者用“控制复杂性”的理由拒绝需求，却未回应业务端“消除不确定性”的迫切诉求。解决方案是，开发者应将其精简需求、复用代码等专业能力，包装成能帮助业务“更快获得答案”的方案，例如使用“我们能不能试个更快的办法？”这样的话术。尽管AI能快速生成代码，但资深开发者不可替代的价值在于为系统长期稳定“承担责任”。

Eric@ericmitchellai · 5月15日64

An all-time crossover episode Go, do

译一个历史性的跨界事件 去吧，行动吧 [引用 @OpenAI]：你们一直要求这个... 现在预览中：ChatGPT移动应用中的Codex。 开始新工作、审查输出、指导执行并批准下一步，全部通过ChatGPT移动应用。Codex将继续在您的笔记本电脑、Mac mini或devbox上运行。

meng shao@shao__meng · 5月15日66

Codex 进入 ChatGPT mobile App，这回终于能开心的移动办公，随时随地指挥 Codex 工作了（Windows 端还未推出） https://openai.com/index/work-with-codex-from-anywhere/ 新版 ChatGPT mobile App 做了一个完整的 Codex 移动工作面： · 接入用户任意一台运行 Codex 的机器（笔记本、Mac mini、远程开发环境）； · 实时同步所有线程、审批、插件、项目上下文； · 实时回传截图、终端输出、diff、测试结果、审批请求； · 文件、凭证、权限、本地配置始终留在原机器上，不上云。 技术架构：安全中继层 Codex 通过一个安全中继层让可信机器跨设备可达，而不直接暴露到公网；同时把活跃会话状态在所有登录 ChatGPT 的设备间保持同步。 OpenAI 在产品形态上选择了"云端中继 + 本地执行"的混合模型——既保留本地开发环境的安全边界与凭证隔离，又通过云中继获得跨设备的实时同步体验。这是企业级 AI 编程工具一个相对成熟的架构取舍。 OpenAI 演示的四个使用场景 1. 排队买咖啡：启动 bug 调查，Codex 复现、跑测试，需要授权时手机批准 2. 通勤途中：收到 Codex 的方案分叉决策请求，手机上选择路径，任务继续推进 3. 会议间隙：让 Codex 跨 Slack/邮件/文档汇总客户问题，准备 brief 4. 散步、午餐：灵感即时投递到新线程或现有任务，回到工位前已有初步进展

译OpenAI 在 ChatGPT 移动应用中推出 Codex 预览功能，用户可远程连接运行 Codex 的本地机器（如笔记本或 Mac mini）。通过安全中继层架构，系统能实时同步工作线程、审批请求与项目上下文，并回传截图、终端输出等结果，而所有文件与凭证均保留在本地，不上传云端。用户可在移动中启动任务、审阅输出或决策分叉，实现“云端中继+本地执行”的混合办公模式。目前该功能暂未支持 Windows 端。

ginobefun@hongming731 · 5月15日52

#BestBlogs 早报 2026-05-15 欢迎阅读BestBlogs 的今日早报，推荐阅读 Anthropic 关于 Claude Code 在大型代码库里的官方实践指南、OpenAI 关于 GPT-Realtime-2 的实现细节和开发演示视频，以及少楠关于大模型时代效率溢出之后的思考。

译本期早报重点推荐了三项内容。Anthropic发布了Claude Code在大型代码库中的官方实践指南。OpenAI则公开了GPT-Realtime-2的实现细节并提供了开发演示视频。此外，少楠探讨了在大模型时代，当效率大幅提升（效率溢出）之后所带来的深层思考。

Berryxia.AI@berryxia · 5月15日74

牛逼！Yetone 佬。

译开发者Yetone将一篇关于桌面应用开发“最佳实践”的文章转化为一个名为“native-feel-skill”的Agent Skill。该Skill旨在帮助开发者利用Coding Agent，轻松地重构或开发跨平台桌面应用，并使其获得极其接近Native原生应用的性能体验。项目代码已开源在GitHub上。

meng shao@shao__meng · 5月15日67

xAI 发布 Grok Build CLI (beta) 面向编码、应用构建与工作流自动化的 Agentic CLI。现在仅向 SuperGrok Heavy 订阅用户开放，xAI 明确表示发布目的是借用户反馈迭代模型与产品本身。 产品地址：http://x.ai/cli 一行 curl 安装 产品定位与关键能力 · Fast & flicker-free CLI — 强调终端渲染性能，针对长会话与并行任务做了优化。 · Plan（计划视图） — 提供可视化的多步计划面板，便于在执行前审阅和调整复杂任务。 · Subagents（子智能体） — 支持并行派生研究、构建、审查角色，最多可同时跑 8 个智能体。 · Skills（技能） — 可装载的工作流偏好与领域知识，让 Agent 适配团队规范。 · Plugins / Marketplaces — 团队间共享能力的市场机制，意在形成生态。 · Q&A 主动澄清 — Agent 会在动手前主动追问细节，而非直接生成。 底层模型为 grok-code-fast-1，公开数据为 SWE-Bench Verified 70.8%，上下文窗口 256K。

译xAI 面向 SuperGrok Heavy 订阅用户推出了 Grok Build CLI 测试版，这是一个用于编码、应用构建与工作流自动化的智能体命令行工具。其发布旨在通过用户反馈迭代产品。该工具核心特性包括优化的终端渲染性能、用于审阅复杂任务的可视化计划视图、支持并行执行最多8个角色的子智能体系统、可装载团队规范与知识的技能模块，以及支持团队共享的插件市场。其底层模型 grok-code-fast-1 在 SWE-Bench Verified 基准测试中成绩为70.8%，上下文窗口为256K。

Replit ⠕@Replit · 5月15日48

Mother's Day may be done, but the moms who build sure aren't. Single mom of five, Rebecca Braden, spent years navigating custody court with nothing to support her during the ever-daunting process. So she built the app she wished she'd had. Case Clarity is an AI-supported companion that helps people in legal situations organize documentation, communication, and timelines all in one place. It doesn't replace attorneys, but it makes the information they rely on clearer and more usable. Built on Replit, from lived experience.

译单亲妈妈Rebecca Braden基于自身在监护权诉讼中的艰难经历，开发了AI应用Case Clarity。该应用不替代律师，而是作为辅助工具，帮助身处法律程序中的人员集中管理文档、沟通记录和时间线，使律师依赖的信息更清晰可用。该应用基于Replit平台开发，源于真实生活经验。

ginobefun@hongming731 · 5月15日60

http://x.com/i/article/2055063165621374976 # BestBlogs 早报 05.15 · Claude Code 最佳实践 / GPT-Realtime-2 · AI 工具到 AI 体系的跃迁 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-15 BestBlogs 新手注册和老用户领取 Pro 会员福利活动进行中，欢迎参与并定制自己的早报。 https://www.bestblogs.dev/pro EP57 · BestBlogs 每日早报 · 2026 年 5 月 15 日 今天这期早报的主线是：从工具到体系。Claude Code 官方公布了大型代码库最佳实践，Harness 的配置比模型分数更决定实际表现，新兴职能「Agent Manager」正在大型组织中落地。OpenAI 通过 Build Hour 深入解析 GPT-Realtime-2 的语音 Agent 架构，对话框正在跃升为自主「语音→行动」工作流。这期还有一个值得关注的真实困境：当 AI 把开发周期从月压到小时后，效率溢出带来的反而是协作方式的重构难题。 ## 导语 AI 编程工具进入大规模落地阶段后，一个关键认知正在浮现：模型能力只是起点，围绕模型搭建的整套工程体系才是决定上限的变量。 Anthropic 这次发布的大型代码库最佳实践指南，直接点破了一个常见误区——团队往往把精力集中在比较不同模型的 benchmark 分数，却忽视了 CLAUDE.md 配置、Hooks、Skills、MCP 等「Harness」层面的工程投入才是实际体验差距的真正来源。这不是一个理论观察，而是来自真实部署在百万行级 monorepo、数十个微服务 repo 上的经验总结。 语音交互领域同样如此。OpenAI 的 GPT-Realtime-2 带来了 GPT-5 级推理和 128k 上下文，但更值得关注的是它背后的架构演进：语音 Agent 已经从「聊天机器人」跨越到了「语音→行动」自主工作流，Sierra 实测延迟降低 30%–200%，这种量级的提升意味着企业语音服务的基础设施需要重新评估。会议场景、客服中心、实时翻译——这些场景的成本结构和体验边界都将随之改变。 flomo 联合创始人少楠的案例则提供了一个反直觉的视角：16 人团队 70%–80% 的代码由 AI 贡献，开发周期从「按月」压缩到「按小时」之后，真正的瓶颈不是工程效率，而是协作方式的重构。产品经理因为能直接验证想法反而提交的需求变少了，优秀的人变得更优秀，能力鸿沟反而在拉大。当效率不再是瓶颈，考验的是另一套能力：判断什么值得做，以及如何在没有传统约束的情况下保持组织协作的凝聚力。 三篇精讲从不同维度指向同一个问题：AI 带来的效率红利，最终会被组织结构和协作惯性消耗掉多少？ 今天速览还有明略科技吴明辉聊 AI 如何颠覆 SaaS、OpenAI 前 CTO Murati 对「永远在场」AI 的探索、阿里云 Skill Factory 的工程实践、OpenAI 13.1 万 GPU 网络的反直觉设计，以及 Codex 登陆 ChatGPT 移动端的最新动态。 ## 精讲一：Claude Code 在大型代码库中的运作方式：最佳实践与入门指南 | Claude Anthropic 官方这篇指南针对的是真实企业场景：百万行级 monorepo、跨越十余年的 legacy 系统、分布在数十个 repo 的微服务群。这类代码库的挑战不是规模本身，而是规模带来的上下文爆炸——如何让 Claude Code 在茫茫代码中准确定位、精准修改，而不是在 context window 里原地踏步。 Harness 和模型同等重要 指南最核心的观点可以用一句话概括：「影响 Claude Code 实际表现的，Harness 配置和模型能力同等重要。」这个论点打破了一种常见预设——很多团队在选型时把大量时间花在比较不同模型的 benchmark 分数上，实际上，两个使用相同模型但 Harness 配置差异显著的团队，体验可能判若云泥。 这里的 Harness 由五个扩展点构成，指南给出了清晰的优先级顺序： - CLAUDE.md 文件 — 每次会话自动加载的上下文文件，根目录放全局约定，子目录放局部规范。这是整套体系的基础，所有其他层都依赖它的质量。内容越聚焦、越准确，Claude 的定位速度越快。 - Hooks — 在 Claude 执行前后注入自定义逻辑，比如格式检查、lint 验证、自动提交、安全审查。它让 Claude 的行为与团队工程规范对齐，而不是每次依赖 prompt 提醒。 - Skills — 可复用的任务模板，把常见工作流封装成结构化指令。类似「为新增 API 端点生成测试用例」这类重复任务，Skills 比每次重写 prompt 更稳定。 - Plugins — 扩展 Claude Code 的底层能力边界，比如接入自定义的代码分析工具或内部知识库。 - MCP Servers — 连接外部工具和数据源，让 Claude 能访问数据库、调用 API、读取实时数据。这是 Claude Code 与企业既有工具链整合的关键接口。 指南特别强调这五个扩展点的顺序很重要：每一层都建立在前一层的基础上。在 CLAUDE.md 还不完善的情况下就去精心配置 MCP，效果会大打折扣。 LSP 与子智能体：两个容易被忽视的加速器 除了五大扩展点，指南还着重强调了两项附加能力： LSP（Language Server Protocol）集成实现符号级导航。传统的 grep 搜索在大型代码库中精度有限——它找到的是文本匹配，不是语义匹配。LSP 能让 Claude 精确跳转到函数定义、查找所有引用、理解类型层次，显著提升在陌生代码区域的探索效率。在 C、C++、Java 这类类型系统复杂的语言中，LSP 集成的收益尤为显著。 **子智能体（Subagents）**解耦探索与编辑。核心思想是：一个子智能体负责探索代码结构、收集上下文，另一个负责实际修改。这种分工避免了单个 Agent 在探索过程中把 context window 消耗殆尽——等到真正要写代码时，已经没有足够空间容纳准确完整的修改了。子智能体完成任务后只把最终结果返回给父 Agent，中间过程的 token 消耗不会传递。 为什么 RAG 在大型代码库中失效 指南对 RAG（检索增强生成）在代码场景局限性的分析值得特别关注。很多团队在引入 AI 编程工具时会考虑「把整个代码库向量化」的方案，Anthropic 明确指出了这条路在大型团队中的天花板。 问题核心是索引的时效性。向量索引需要预先构建，当工程团队在高速迭代时，索引的更新速度根本跟不上代码变更速度。Claude 检索到的可能是两周前已被重命名的函数、上个 sprint 已经删除的模块，而且检索结果本身不会告知你这个信息是否已经过期。在一个有几千名工程师并行提交的 monorepo 里，这个问题会被急剧放大。 Agentic 搜索（即 Claude 直接在 live 代码库中 grep、读文件、跟引用）规避了这个问题——没有索引需要维护，每个开发者的实例都在最新代码上工作。代价是需要足够的起始上下文，也就是说 CLAUDE.md 的质量直接决定 Claude 能否快速定位到正确的代码区域。指南建议：如果 Claude 需要在十亿行代码库里寻找一个模糊的模式，你会在工作开始之前就碰到 context window 限制。精确的起点比广泛的搜索更有价值。 「Agent Manager」这一新兴职能 在大型组织的落地案例中，指南观察到一个新角色正在涌现：Agent Manager。这个职能介于传统技术 Lead 和 AI 工程师之间，具体职责包括：维护 CLAUDE.md 的规范质量、审查和迭代 Hooks 配置、评估 Skills 的覆盖率和准确性、协调不同团队的 MCP 接入标准，以及管理多个 AI Agent 之间的协作边界。 这个职能的出现反映了一个现实：AI 工具的「基础设施」工作需要有人专门负责，否则很容易变成「每个人都在各自配置，没有人在系统性优化」的局面。指南特别提醒，每 3–6 个月应随模型迭代主动更新 Harness 配置——旧有的「规则」可能会约束新模型本已具备的能力，形成不必要的限制。随着 Claude 的能力持续演进，过度保守的 Hooks 和过时的 CLAUDE.md 有时候反而是性能瓶颈。 这篇指南对任何在团队中推广 Claude Code 的工程师或技术 Lead 都有直接参考价值。完整内容见 Claude Code 大型代码库最佳实践。 ## 精讲二：Build Hour 深解 GPT-Realtime-2：语音 Agent 如何从聊天迈向「语音→行动」 OpenAI 的这次 Build Hour 围绕 GPT-Realtime-2 展开，但内容远不止一个新模型发布——它实际上是在描绘语音 AI 应用架构的下一代形态。从「用语音问 AI 一个问题，AI 用语音回答」，到「用语音指挥 AI 执行一系列操作，AI 实时改变应用状态」，这是两个完全不同量级的产品体验 三款音频模型协同工作 OpenAI 这次推出的不是单一模型，而是面向不同场景的三款模型组合，每款都有明确的定位： - Real-time Translate：支持 70+ 语言输入、13 种语言输出，主打低延迟流式翻译。适合实时多语言会议、跨语言客服等场景，不需要最强的推理能力，但对延迟极度敏感。 - Real-time Whisper：延迟可调，最低可达 200ms，支持 80 种输入语言。这是对语音识别精度和速度的双重优化，适合需要快速响应但对下游推理要求不高的场景。 - GPT-Realtime-2：旗舰推理模型，带来 GPT-5 级推理能力，具备高质量工具调用性能，是真正实现「语音→行动」的核心模型。在 Big Bench Audio 上比前代提高了 15.2%。 这三款模型的组合设计思路值得关注：OpenAI 没有试图用一个模型覆盖所有场景，而是根据延迟需求、语言支持广度和推理深度做了明确分层，让开发者根据具体场景选择合适的「档位」。 三项关键技术提升 GPT-Realtime-2 相比前代有几项对开发者直接有用的改进： 首先是 128k 上下文窗口，是上一代的 4 倍。这意味着近一小时的完整对话可以保留在上下文中，不需要截断，长会话中的指令遵循也更稳定。对于需要记住复杂用户偏好、维护多轮任务状态的场景，这是实质性的提升而不是数字上的增量。 其次是前导语（Preambles）机制。当用户提问后，模型需要调用工具或进行多步推理时，可以先输出「让我查一下……」或「好的，我来看看……」这类过渡语，填补思考间隔。这个设计让语音对话的节奏更接近真实人际对话，避免了用户提问后遭遇令人不安的长时间沉默。 第三是逐轮 VAD 控制。VAD（Voice Activity Detection，语音活动检测）负责判断用户是否说完话、何时该模型开始回应。新版本允许开发者在特定对话轮次禁用 VAD，防止模型在输出关键内容（比如法律声明、合同条款、医疗建议）时被意外打断。这对企业合规场景来说是刚需。 Sierra 的企业实测数据 Build Hour 邀请了企业 AI 公司 Sierra 的工程师 Ken Murphy 和 Soham 分享实战经验。他们在企业客服场景下将 GPT-Realtime-2 与传统级联语音系统进行了系统对比。传统方案是「语音识别→文本处理→语音合成」三段式架构，每段都引入延迟，且各段的误差会叠加。 实测延迟降低幅度在 30% 到 200% 之间。区间跨度大的原因是不同业务场景的原始延迟基线差异很大，但即便是最保守的 30% 改善，对用户感知体验也已经是质的提升——语音交互对延迟的敏感度远超文本交互，因为人类对话中的节奏期望是内化的。 Sierra 同时强调了一个务实的观点：模型能力再强，生产环境中的稳健性仍然依赖「Agent Harness」——处理背景噪音、口音、中途打断、连接抖动等真实世界干扰的工程层。这与精讲一关于 Claude Code Harness 的核心论点形成了有趣的呼应：无论是编程助手还是语音助手，「Harness 和模型同等重要」这一判断都成立。 语音 Agent 的下一步 从这次 Build Hour 的演示来看，OpenAI 展示的电商场景（语音管理购物清单，按预算过滤商品，实时更新 UI 状态）和产品分析仪表盘（语音指令诊断移动端 bug，Agent 自主筛选复杂数据集）已经超出了「对话助手」的范畴，进入了真正的自主工作流领域。 用户说「帮我把购物车里超过 500 元的东西移出去」，Agent 不是返回一份建议清单，而是直接操作。这是「语音→文本→建议→用户确认→操作」到「语音→操作」的路径压缩。对于产品设计者来说，这意味着 UI 交互范式需要重新思考：哪些操作应该完全自主执行，哪些需要保留确认环节。 完整技术解析见 GPT-Realtime-2 Build Hour。 ## 精讲三：AI 让生产效率不再是瓶颈，然后呢？｜AI 跃迁者调研 02-flomo 少楠 如果说前两篇精讲是在讲「如何把 AI 工具用好」，少楠的这篇访谈则在追问一个更难回答的问题：当 AI 工具真的把效率拉满之后，真正的障碍是什么？ 少楠是 flomo 浮墨笔记和幕布的联合创始人，做了 11 年产品。这次访谈他分享了一个 16 人团队在 AI 让效率暴涨之后遇到的真实困境，以及 flomo 两个从「代码上下文里长出来」的新功能背后的设计过程。 转折点：命令行比 IDE 更适合产品经理 少楠从 GPT-3.5 时代就开始使用 AI，但长期卡在两个瓶颈：API 成本太高无法集成进产品，Cursor 的 IDE 界面对不写代码的产品经理来说过于复杂——「不小心关掉右边聊天窗口就找不到了，干脆放弃。」 真正的转折来自 Claude Code 的命令行界面。「没有复杂的 IDE，直接给口头指令。」他用它写了一个浏览器插件，能跑，额度从 20 美元充到了 200 美元。同期 DeepSeek V3 把 API 价格打下来，产品内终于也敢大规模用了。从今年开始，他们团队的 AI 渗透率才真正大幅提升：16 人团队，70%–80% 的代码由 AI 贡献，开发周期从「按月」缩短到「按小时」。 这个细节值得注意：对于不写代码的产品经理来说，「简洁的命令行界面」比「功能丰富的 IDE」更低的认知门槛，反而成了 AI 编程工具的入口优势。工具的易用性不是对所有人都意味着相同的东西。 一个反直觉的悖论：产品经理反而更少提需求了 少楠对所有产品经理提了一个新要求：提需求之前，必须先拿到代码库权限，在自己的分支上用代码把需求跑通，在真实数据库里拿到结果，再写 PRD 交给工程师上线。 这带来了一个意外效果。工程师效率提升了——把任务交出去，能开一堆 Agent 并行处理。但产品经理效率反而下降了——「你证伪自己想法的效率变高了，但最终交付产出的数量变低了。以前工程师烦死产品经理了，觉得需求太多；现在是产品经理不好意思提需求了。」 他举了一个典型案例：有用户说 flomo 应该做画板功能，可以拖拽连线。以前少楠直接 Pass，觉得需求太重不敢想。现在他吃晚饭前把想法丢给 AI，吃完饭回来一上手用，发现这是个伪需求——用户需要的是「看到笔记之间有联系」的感觉，而不是自己手动连线这个操作本身。以前只能靠逻辑推演，现在是亲自做出来之后发现不靠谱。验证速度提升了，最终交出去的需求质量也提升了——只是数量少了很多。 工程师那侧也在变化。Web 端做完一个功能，移动端工程师直接去代码库级别参考实现，不需要重新写 PRD，数据埋点有专门的 Skill 技能指令自动化完成。开发周期从「按周」计算变成了「按小时」计算。 AI 没有带来能力平权 少楠给自己团队打了 5 分（满分 10 分），理由直接：「速度上去了，但用户价值的挖掘没有同步提升。」他心目中的满分状态是从「上下游关系」变成「Peer 搭档关系」，像特战小组——四个人的小组能调动远程火炮，有非常清晰的职能分工，同时互相补位，而不是冗长的瀑布流。 更值得警惕的是他的一个核心判断：​「只有原来优秀的人，变得更优秀了。AI 没有带来能力平权，反而把鸿沟拉得更大。」 最会用 AI 的人往往最累，因为能力边界扩张后，优秀的人会自发承担更多。而不擅长使用 AI 的人，和擅长使用 AI 的人之间的效率差距不是在收窄，而是在急剧拉大。 协作方式的重构是最大的难点，不是工具本身。具体问题包括：谁来做 Code Review？怎么 debug 一段 AI 生成的代码？产品经理和工程师的协同边界到底变成什么样？职能边界在溶解——有的产品经理开始兼顾交互设计，有的设计师想直接 vibe coding 出效果，这些探索性的实验会抵消一部分执行效率。少楠自己也在和 vibe coding 的诱惑搏斗：「你的能力变强之后，天然地会想做更多的东西，跟抽烟一样，抽了一口就想抽第二口，两三个小时就没了。」 从代码上下文里「长出来」的功能 flomo 最近上线的两个 AI 功能很有意思——它们都不是从传统 PRD 流程来的，而是少楠在 Claude Code 里写着写着「碰出来的」： 认知地图：少楠想把 flomo 笔记的高维向量（1000 多维）压缩到二维平面看聚类效果。在和 AI 基于代码上下文讨论「这些小点点还能做什么」时，AI 提到了等高线。他一试，发现刚好契合脑子里「个人知识库是一张地图」的想象——等高线对应认知密度的起伏，还能以月为单位播放时间轴，看到自己哪个月在攀登哪个「认知山峰」。「想了很多年的一个东西，就这样上线了。」 AI 记忆：系统把用户所有 flomo 笔记按偏好、事实、事件三大类压缩提炼，生成一份「记忆文档」。把这份文档丢给 Claude 或 GPT，回答质量和个性化程度完全不同——因为 AI 知道你最近在关注什么、你的历史判断、你的角色。这是 flomo 最重要的大更新：长期主动记录积累的私有数据被彻底盘活了。目前只对 Max 会员开放，因为把用户所有笔记压缩两遍的算力成本「是非常惊人的」。 这两个功能的共同点是：它们不是从「用户访谈→需求文档→设计稿→开发」的传统流程来的，而是从「产品经理直接用 AI 工具探索代码实现」的过程中意外发现的。这本身就是少楠所说的「工作流变化」最具体的体现。 完整访谈见 flomo 少楠：AI 跃迁者调研 02。 ## 速览 当 AI「杀死」SaaS：多 Agent 网络与软件业转型 晚点聊 LateTalk 第 164 期邀请了明略科技创始人吴明辉，深度探讨 AI Agent 如何颠覆 SaaS 商业模式。核心论点是「闭源软件价值消失，从 Token 和模型上赚钱」。明略正在开源发布多 Agent 协同网络「章鱼」，通过集体学习机制实现指数级增长。吴明辉提出了「龙虾哲学」——用工程化的义务约束来代替无法约束大模型的道德框架。有 5 年前 AI 尝试失败经验的他，这次对 AI 转型的判断更为审慎和结构化。这期时长超过两小时，想深入了解 AI 对企业软件架构影响的同学值得完整听完。 OpenAI 前 CTO 带来的「永远在场」AI 原型 腾讯科技这篇论文解读深入分析了 Thinking Machines 发布的 Interaction Model。文章从传播学的三条件出发（共在性 Copresence、共时性 Contemporality、并发性 Simultaneity），诊断了当前 AI 交互系统的根本缺陷：AI 只在你主动输入时才「存在」，在你不说话时你的世界对它不存在。Thinking Machines 的方案是通过 200ms 微轮次心跳和统一多模态架构打破这一局限，实现真正「在场」的下一代交互。这篇文章与精讲二关于 GPT-Realtime-2 的内容形成有益互补，两篇放在一起读能更完整地理解「真正的实时 AI」意味着什么。 Skill Factory：三天搭一条技能生产流水线 阿里云开发者这篇实践分享介绍了基于测试驱动开发（TDD）理念构建的 Skill Factory。系统通过多路并行生成（同时调用 3 种不同策略的 Creator，相当于「买三张不同号码的彩票」）、自动化测试回归和生态适配，实现了标准化的技能生产流水线。多路并行的逻辑是：只要其中一路生成了高质量 Skill，整个任务就算成功，这极大提高了首次生成成功率。文章对正在规模化部署 AI Skill 生态的团队有直接参考价值，配合精讲一的 Harness 概念来读效果更好。 OpenAI 13.1 万 GPU 训练网络的反直觉设计 这篇 Towards Data Science 文章深入解析了 OpenAI 发布的 MRC（Multipath Reliable Connection）协议。这套协议颠覆了 30 年的网络惯例：禁用所有路由协议、主动接受丢包、将每次传输随机分散到数百条路径上。结果是在 13.1 万块 GPU 上实现了可预测的尾部延迟，以支持同步训练。文章最值得关注的发现是：MRC 实际上「消灭」了数据中心网络的整个第三层控制平面，没有 OSPF，没有 BGP，没有 IS-IS，交换机维护零动态转发状态。这在任何已公开的生产 AI 训练网络中都是前所未有的。对大规模分布式系统和网络架构感兴趣的工程师必读。 用 Evals 与五段式 Rubric 打造可靠 AI Agent 这个 AI Engineer 工作坊视频由 Arize AI 的 Laurie Voss 主讲，系统介绍了如何从「感觉对」走向「可测量」。核心框架是三层评估体系：代码 Evals（确定性检查，快速且便宜）、LLM-as-a-Judge（用更强模型评估语义质量，适合代码无法捕捉的质量维度）、人工评估（生成黄金数据集，是自动化评估器的「校准基准」）。五段式 Rubric 设计和 Meta-Evaluation（评估你的评估器本身是否靠谱）是两个关键实操技巧。想让 Agent 从实验阶段走向生产的团队必看。 只加两行代码，为什么要两天？ 腾讯云开发者这篇文章深入剖析业务系统复杂性的根本来源：功能间隐秘增加的耦合和不可避免的代码腐化。文章指出，随着系统功能增多，实现每个新功能不会越来越容易，而是越来越难——这与理想中「可复用性会降低边际成本」的预期完全相反。实际的 functionalities-cost 曲线是指数级上升的，不是线性的。文章对于理解 AI 辅助开发在复杂遗留系统中的真实效率边界很有帮助，和精讲三少楠案例中「协作方式的重构才是最大难点」的观点形成互补。 Codex 正式登陆 ChatGPT 移动应用 OpenAI 官方宣布，AI 编程智能体 Codex 现已在 ChatGPT 移动应用中开启预览。开发者可以通过手机启动新任务、审查输出结果、引导执行流程并批准后续步骤，而 Codex 会继续在笔记本或开发机上运行。这意味着开发者可以随时随地通过口袋设备管理正在进行中的编程任务，项目上下文和文件访问权限保持不变。这是一个典型的「分离关注点」的产品设计——执行仍在算力充足的设备上，监控和审批可以在移动端完成。 ## 扩展阅读 OpenAI Codex 负责人 Tibo Sio：Codex 如何进化为通用 Agent OpenAI Forum 的演讲视频，Codex 负责人 Tibo Sio 介绍 Codex 从云端开发者工具转型为本地运行的通用知识工作助手的路径：随着 GPT-5 的发布，Codex 将关注点从简单代码补全转向「长时任务」，即需要数小时乃至数天自主工作的复杂项目。视频中预告了面向长时任务的 Slash Goal 模式和安全护航的 Auto Review Agent。对关注 OpenAI Agent 产品演进方向的人值得看。配合速览中 Codex 登陆移动端的动态一起理解效果更好。 解锁连续批处理中的异步性 Hugging Face Blog 的 LLM 推理系列第二篇，讲解如何通过 CUDA 流和事件将 CPU 批次准备与 GPU 计算解耦，实现真正的并行执行，实测获得 22% 的推理加速。技术深度较高，适合需要优化 LLM 推理服务成本、尤其是在 H200 等高端 GPU 上跑生产推理的工程师。是对第一篇连续批处理文章的延伸，建议按顺序阅读。 GitHub Issues 导航性能现代化改造 GitHub 工程团队如何通过客户端缓存、预热（Preheating）和 Service Worker，将 Issues 页面导航延迟从「网络受限」变为「接近即时」。文章特别有价值的是方法论层面：先做流量分布测量（发现 57.6% 是 hard navigation），再针对主导路径优化，而不是只优化已经较快的 React soft navigation。HPC 百分位指标的改善数据具体详实。适合做前端性能优化或关注产品感知速度提升的工程师参考。 在 Zoox 加速 LLM 驱动的开发者生产力 Zoox AI 负责人分享通过构建企业 AI 平台 Cortex 系统化提升开发者效率的路径，涵盖安全 LLM 访问、RAG、智能体 API 和采纳率管理。从「新员工入职查文档靠猜」到「AI 无处不在，缺 AI 才感觉奇怪」的转变过程，有不少关于 AI 采纳率培育的实操细节。适合正在规划企业 AI 基础设施、需要参考大型工程团队实战案例的管理者和架构师。 ## 今日阅读路径 时间有限时，建议优先按以下顺序阅读： 第一优先：Claude Code 大型代码库最佳实践 如果你的团队正在推广或评估 Claude Code，这篇 Anthropic 官方指南有直接的实操价值。理解「Harness 和模型同等重要」这一核心论点，能避免在工具选型时只看 benchmark 分数而忽视工程配置的误区。五大扩展点的优先级顺序、LSP 集成的时机、子智能体的使用场景——这些都是容易踩坑的决策点。预计阅读时间 25–35 分钟。 第二优先：flomo 少楠：AI 跃迁者调研 02 这篇访谈提供的不是技术方案，而是一个真实团队在 AI 效率提升后遇到的组织挑战的第一手记录。「AI 没有带来能力平权，反而把鸿沟拉大」和「协作方式的重构是最大难点，不是工具」这两个判断，对任何在团队中推动 AI 落地的人都有很高参考价值。尤其推荐和 flomo 同量级的中小团队创始人和产品经理阅读。预计阅读时间 30–40 分钟。 第三优先：GPT-Realtime-2 Build Hour 如果你的产品涉及语音交互或实时通信，这个 Build Hour 值得完整看完。三款音频模型的定位差异、128k 上下文的实际意义、前导语机制和逐轮 VAD 控制的产品含义、Sierra 的企业实测数据——这些细节在正式文档中很难找到这么集中的呈现。预计视频时长 45–60 分钟，可以 1.5 倍速观看不影响理解。 BestBlogs 每日早报 · EP57 · 2026 年 5 月 15 日 · bestblogs.dev

译Anthropic发布Claude Code大型代码库实践指南，强调Harness配置（如CLAUDE.md、Hooks）与模型能力同等重要，是决定实际体验的关键，并指出RAG在高速迭代代码库中存在时效性局限。同时，OpenAI通过Build Hour解析GPT-Realtime-2，展示语音Agent正从聊天机器人演进为“语音→行动”的自主工作流。此外，当AI将开发周期从月压缩到小时，效率提升正引发协作方式与组织结构的重构难题。

Berryxia.AI@berryxia · 5月15日70

兄弟们，这个好啊！ Codex 移动手机版已经上线，可以直接在商店下载使用… iOS 已经用上了～ 安卓大家可以Google Play 看看有没有

Berryxia.AI@berryxia · 5月15日63

xAI 今天正式放出了 Grok Build 的早期 Beta。 这是一个 agentic CLI，专门用来写代码、搭建应用、自动化工作流。 它支持并行子代理、计划视图、团队共享市场，还能无缝接 MCP skills、插件、hooks 和 headless 模式。 目前只对 尊贵的SuperGrok Heavy 订阅者开放。 xAI 明确表示，会根据早期用户的真实反馈持续迭代模型和产品。 试用地址：https://x.ai/cli 当大多数 AI 编码工具还在做聊天式网页界面时，xAI 选择先把 CLI 做深、做实，让真正每天都在造东西的人能直接在终端里驱动整个 agent 团队。 这波操作把“agent 真正落地”这件事，从 demo 拉到了日常工作流。 如果你是重度开发者或 builder，值得去看看。 你觉得下一代 AI 编码工具，更重要的是聊天界面，还是这种深度 agentic CLI？

译xAI正式发布Grok Build的早期Beta版本，这是一个专为编码、构建应用和自动化工作流设计的agentic命令行界面。它支持并行子代理、计划视图及团队共享市场，并能集成MCP skills等扩展功能。目前仅面向SuperGrok Heavy订阅者开放。xAI选择深耕CLI，旨在让开发者直接在终端驱动agent团队，推动agent技术从演示融入实际工作流。

OpenCode@opencode · 5月15日77

OpenCode x Qwen 3.6 Plus - free, again Last time y’all treated our capacity like an all-you-can-eat buffet. We found more GPUs. Round 2.

译OpenCode x Qwen 3.6 Plus - 再次免费 上次各位把我们的容量当成了自助餐。 我们找到了更多GPU。第二轮。

小互@xiaohu · 5月15日67

Codex 手机版上线 但是并不是大家之前认为的独立App 而是内置在ChatGPT里面 在客户端选择codex，设置后，你就可以直接在 ChatGPT 手机 App 里远程控制。 你不在电脑前，也能查看 AI 正在写什么代码、跑什么任务、卡在哪一步，甚至直接批准它继续执行。 手机里可以： • 查看任务线程 • 看 diff 和测试结果 • 给 Agent 回复新指令 • 批准危险操作 • 切换模型 • 新建任务继续跑

译Codex手机版已正式推出，但并非独立的应用程序，而是直接集成在ChatGPT手机App内部。用户只需在客户端选择并设置Codex，即可通过手机远程控制AI编程任务。核心功能是让用户即使不在电脑前，也能实时监控AI的代码编写、任务执行进度与卡顿点，并可直接批准其继续运行。具体操作包括查看任务线程、检查代码差异与测试结果、向Agent发送新指令、批准危险操作、切换模型以及创建并运行新任务。

ginobefun@hongming731 · 5月15日53

Codex 现已集成到 ChatGPT 移动应用中。

Greg Brockman@gdb · 5月15日74

You can now use Codex, wherever you have it running, from the ChatGPT app. Huge step forward for universal usage of agents.

译现在，无论Codex在哪里运行，你都可以从ChatGPT应用中使用它。 对于代理的通用使用来说，这是一大步前进。

Sam Altman@sama · 5月15日66

Codex in the ChatGPT mobile app!

译ChatGPT手机应用中推出Codex功能！

Sam Altman@sama · 5月15日74

also all this:

译OpenAI宣布Codex推出两项新功能，旨在提升围绕代码的自动化与定制体验。一是“Hooks”，允许用户通过脚本在任务关键节点自定义Codex的工作流程，例如运行验证器、扫描提示中的敏感信息、记录对话至内部系统，或根据代码库和目录创建记忆与定制行为。二是“编程访问令牌”，为Business和Enterprise团队提供范围限定的凭证，可从ChatGPT工作区设置生成，适用于CI/CD管道、发布工作流和内部自动化任务。该令牌支持设置过期时间或即时撤销，并能将使用情况关联回对应工作区。

宝玉@dotey · 5月15日66

OpenAI 把 Codex 搬进了 ChatGPT 手机 App，今天在 iOS 和安卓上同步开启 preview，所有 ChatGPT 用户都能用，包括免费版和最低价的 Go 套餐。 手机端不是让你在手机上写代码。真正干活的 Codex 还是跑在你的笔记本、Mac mini 或者 devbox 上，手机只是一个远程窗口：地铁上能看 Codex 跑到哪一步、审一眼它改的 diff 和跑的测试结果、批准下一步操作，或者临时换个方向走。文件、凭证、权限都留在原来那台机器上，不上传到手机。 OpenAI 的解释是底层走了一层 secure relay 中继,让跑着 Codex 的机器能跨设备保持可达,又不直接暴露在公网上。你在哪台设备登录 ChatGPT，会话状态和上下文就跟到哪里。 为什么现在做。OpenAI 自己公布的数字是 Codex 每周活跃用户已经过 400 万。当 agent 越来越多地跑长任务，几十分钟甚至几小时的那种，人坐在电脑前盯着就很傻，你需要随手能看一眼、能拍板的能力。 一个明显限制：手机端目前只能连 macOS 上的 Codex，Windows 支持据说”很快”。 另一层意思是，OpenAI 没给 Codex 单独做手机 App，而是塞进 ChatGPT 主 App。这跟他们之前透露过的”超级 App”路线一致，把 ChatGPT、Codex、Atlas 浏览器整合成一个入口。桌面端是独立的 Codex App，手机端直接合并进 ChatGPT。 参照系是 Anthropic。Claude Code 从去年秋天起就支持手机远程查看和介入正在跑的任务，后面的 Cowork 配套移动端走的也是类似 dispatch 思路。Codex 这次把覆盖范围扩到了 devbox 和远程企业环境（支持 remote SSH 接入），算是追平加扩张。

译OpenAI在ChatGPT的iOS和安卓App中推出Codex预览功能，所有用户均可使用。该功能并非让手机直接运行代码，而是作为一个远程操作窗口，允许用户在外出时查看任务进度、审核代码差异与测试结果，并进行决策。实际计算任务仍在用户的笔记本电脑、Mac mini或devbox上执行，文件与凭证不会传输至手机。此举旨在满足Codex每周超400万活跃用户处理长任务时的远程监控需求。目前手机端仅支持连接macOS设备，Windows版本即将推出。该集成符合OpenAI将多项服务合并至单一入口的“超级App”战略。

Peter Steinberger 🦞@steipete · 5月15日55

We've been working really hard on performance, reliability, security, and stability. Invented whole new automation flows with crabbox, automated video QA and are spending insane amounts of CPU cycles on CI. It's a good release.

译OpenClaw 团队近期专注于提升性能、可靠性、安全性和稳定性，通过引入 crabbox 等全新自动化流程以及投入大量 CPU 资源于 CI 环节，实现了显著改进。新版本默认将 OpenAI 配置设为 Codex 登录，增强了运行时回退与停滞流恢复机制，确保 Telegram 轮询在停滞情况下仍可维持。此外，安装包更精简、启动路径更快速，整体运行更高效、稳定且不易卡顿。