ginobefun@hongming731 · 4月28日69

http://x.com/i/article/2048918501637943296 # BestBlogs 每日早报 EP41 · Symphony 编排 / gpt-realtime-1.5 / AI 原生工程团队 · 04.28 OpenAI 这一周把控制平面摆到了台面上。一边是 Symphony 让 Linear 看板直接驱动 Codex Agent、gpt-realtime-1.5 把语音指挥软件推向产品级、吴恩达顺势抛出 AI 原生工程团队的运营模型；另一边，微软 Russinovich 与 Hanselman 在 ACM 上发表同行评审论文，警告 Agentic Coding 工具正在系统性掏空初级开发者的人才管线。当 harness 决定团队上限，工程师究竟该把判断力沉淀在哪里，今天的精讲值得逐字读完。 ## 导语 如果说过去几个月行业还在争论"该用多大的模型"还是"该搭多复杂的工作流"，今天这一期把另一个问题推到了中央：控制平面到底归谁、靠什么沉淀 。OpenAI 用三件事给出了回答——Symphony 把 Linear 看板变成 Coding Agent 的状态机，gpt-realtime-1.5 让语音直接驱动应用状态，吴恩达则把 AI 原生工程团队的新运营模型说得很直白：编码智能体把构建速度推上新台阶之后，2 到 10 人的同地小团队靠面对面沟通就能跑出最高效率，通才取代专才，瓶颈反而冒到了产品、市场和法务。 但同一波浪潮的反面也已经被点名。微软 Azure CTO Mark Russinovich 和 VP Scott Hanselman 在 Communications of the ACM 上的同行评审论文里直接写道：AI 给资深工程师巨大的产能加成，却给初级开发者套上"AI drag"——招聘市场已经看见了 22 到 25 岁岗位下滑 13%、入门级开发者招聘较 2022 年下降 67% 的现实。腾讯技术工程团队、量子位访谈楼天城、腾讯科技的 Skill 蒸馏长文，则从三个方向回答了同一个问题：当工作流可以被工业化，工程师该把"判断力"沉到哪一层、留下什么。 如果你今天只有十分钟，把精讲一、二、三按顺序读完就够；如果还想做一份能讲给团队听的纪要，把速览里 Russinovich、知识沉淀、Skill 蒸馏三条放进去，整套"控制层 + 知识沉淀 + 人才管线"就清楚了。 ## 精讲一 · OpenAI 发布 gpt-realtime-1.5：用嘴指挥软件正在变成产品级体验 OpenAI Developers 官方账号今天发出了 gpt-realtime-1.5。公告把它定位得很清楚：这是专为「语音控制的交互式应用」而生 的新模型，重点不是再上一层语音生成的拟真度，而是让用户能用语音更自然地操控应用状态——配套放出的演示视频里，端到端的应用交互完全靠语音驱动完成。 为什么这件事值得放在第一位？过去两年，"语音 AI"在 demo 阶段非常热闹，但真正落到生产应用里，开发者会反复撞到同一堵墙：模型可以听懂、可以说，但它和应用状态之间总有一层断层——要么靠开发者自己拼接 STT、LLM、TTS 三段式流水线，要么用 realtime API 把延迟压下来但拿不到稳定的"对状态做修改"的能力。gpt-realtime-1.5 的设计目标就是把这层断层补齐：让"用嘴指挥软件"从演示视频走进产品级体验。 它和今天另外两条精讲也是一组的。Symphony 是把控制平面交给 Agent ，gpt-realtime-1.5 则是把控制平面递给用户的嗓子 ——同一周 OpenAI 在两个相反方向上各开了一刀，但指向的是同一个判断：交互层、编排层、控制层，都要被重写一遍。吴恩达说 AI 原生小团队会被产品瓶颈卡住 ，gpt-realtime-1.5 之类的模型恰恰是减小这种瓶颈的关键——当语音交互足够稳，工程师就不必再为"再做一遍语音前端"分心。 阅读建议：如果你正在 OpenAI 平台上做语音应用、或者团队里有 voice-first 产品的尝试，今天就把这条公告点开、把 demo 视频顺手过一遍，再决定要不要把现有 realtime 流水线迁过来。它是本周最值得马上跟进的模型升级，原文：OpenAI 发布 gpt-realtime-1.5：为语音控制交互应用而生。 ## 精讲二 · OpenAI 开源 Symphony：把 Linear 变成 Coding Agent 的控制平面 如果说 gpt-realtime-1.5 是"用户怎么指挥软件"的答卷，Symphony 就是"工程师怎么指挥 Agent"的答卷。今天 OpenAI 在 blog 上把 Symphony 开源出来，附上一份 SPEC.md，并直接放话：内部部分团队上线三周内 PR 落地数量增长了 5 倍。 故事的起点很扎实。OpenAI 内部团队半年前做过一个反共识的决定——一个内部生产力工具的代码仓库不允许人手写一行代码 ，每一行都必须由 Codex 生成，团队为此把工程流程重新设计了一遍，先解决了 harness engineering 的问题。但很快撞上下一个瓶颈：上下文切换 。每个工程师同时开三到五个 Codex session 还能 hold 住，再多就开始忘记哪个 session 在干什么、跳来跳去 nudge agent、调试 stall 的长任务。Agent 是快了，但人变成了系统瓶颈——他们造了一支极强的"junior 团队"，然后亲手把 senior 工程师的时间全花在微观管理上。 Symphony 是这个矛盾的解法。它的核心做法是取消"以 session 为中心"的范式 ，改成以工单为中心：每一张 Linear 上 open 的 issue 会被映射到一个独立的 Agent 工作区，Symphony 持续盯着任务板，确保每张 active 工单始终有一个 Agent 在 loop 里跑；Agent 崩了 Symphony 自动重启，新工单进来 Symphony 自动认领，看板状态就是状态机。一张工单能产出多个 PR、能横跨多个 repo，也能是纯调研类任务最后只输出一份报告。 更关键的两层影响。第一层是工程师角色变了 ——不再坐在终端前监督每一个会话，而是花更多时间在工单的拆解、计划评审、PR review 上；甚至产品经理、设计师都能直接派活，因为接活的不再是某个具体工程师，而是 Linear 看板。第二层是最后一公里被自动化 ：Symphony 会盯 CI、需要时自动 rebase、自己解 conflict、retry flaky check，把以前最磨人的"PR 落地"那段流程接管过去。OpenAI 承认这有 meta 感——团队就是用 Symphony 来构建 Symphony 的。 它和今天另外两条精讲串起来也很顺。吴恩达说工程师需要承担更多产品、设计、市场角色，正是因为 Symphony 这类工具把"实现层"压扁了，多出来的精力得有去处；Russinovich 与 Hanselman 警告初级开发者管线被掏空，恰恰也是 Symphony 这种范式带来的副作用——junior 工程师过去靠"接住一个 session、跟着 senior 把 PR 拍到底"成长，现在 Linear 看板直接对接 Agent，他们的成长台阶反而被抽掉。 阅读建议：如果你在带工程团队、或者团队里已经在常态化使用 Codex / Claude Code，今天把这篇精读完，再去对照自己的工作流。重点不是抄 Symphony，而是把它的逻辑映射回你自己的 issue tracker——它本质是一份 SPEC.md，原文：OpenAI 开源 Codex 编排规范 Symphony：把 Linear 变成 Coding Agent 控制平面。 ## 精讲三 · 吴恩达：AI 原生软件工程团队的新运营模型 吴恩达今天抛出的判断和 Symphony 是同一段乐曲的不同声部。Coding Agent 把构建速度推上新台阶之后，他观察到的现象是：工程师不得不同时承担产品、设计、市场的角色 ——以往按职能切分的协作链条变得太慢，新瓶颈跟不上来；2 到 10 人的同地办公（co-located）小团队靠面对面沟通跑出最高效率，远超大型分布式组织。 他点出的新瓶颈很值得记下来：产品管理瓶颈 ——工程师必须懂一些产品判断，产品经理也得懂一些工程；市场营销瓶颈 ——增长跟不上产能；法律合规瓶颈 ——审查节奏跟不上发布节奏；设计瓶颈 ——视觉和体验跟不上功能堆砌。吴恩达的结论很硬：在这种环境下，愿意学跨职能技能的通才会取代专才 ，2 到 10 人的小团队完全可能跑出过去几十人才能做到的事。这不是一个人单打独斗的时代，而是"小型同地全栈团队"的时代。 它和今天的另一条主旋律——精讲二 Symphony 看板、速览里腾讯技术工程团队的"Harness 不是目的、知识才是护城河"——共振非常清楚：编排工具会把工程师从微管理 Agent 里释放出来，多出来的时间必须沉淀到产品判断、用户判断、组织判断这些更靠近商业目标的层级 ，否则就会像 Russinovich 警告的那样，把人的判断力用在不创造增量的事情上。吴恩达把这一切定义成"学习与创造的黄金时代"——技能的复利第一次跨越了职能边界。 阅读建议：这条特别适合两类人逐字读。第一类是正在带 5 到 15 人小团队的 tech lead 或创始人，把"通才优先"和"产品 / 市场瓶颈"作为下一阶段招聘和组织设计的提示。第二类是入行不久、还在纠结要不要"专一深耕"的工程师——吴恩达直接告诉你方向：跨职能学习的复利会更高。原文很短但密度很大：吴恩达：AI 原生软件工程团队的新运营模型。 ## 速览 下面这 7 条是今天值得花 5 到 10 分钟逐条读完的高分内容，覆盖人才管线、知识沉淀、Skill 蒸馏边界、小米物理 AI、Harness 哲学、淘天工程实践和 EAPO 强化学习六条主线。 微软 Russinovich 与 Hanselman 警告：AI 正掏空初级开发者人才管线 微软 Azure CTO Mark Russinovich 和 VP Scott Hanselman 在 Communications of the ACM 上发表了一篇同行评审的 opinion piece，直接说 Agentic Coding 工具正在让软件工程行业陷入结构性危机。核心矛盾 ：AI 给 senior 工程师巨大的产能加成，却给入门期（early-in-career, EiC）开发者套上他们叫"AI drag"的负担——junior 还没养成对 AI 输出做"steer / verify / integrate"的判断力，被 AI 工具拖慢而不是放大。结果是激励结构发生位移：公司在招 senior 的同时把 junior 工作自动化，下一代 senior 的人才管线在悄悄塌陷。文中数据非常扎眼：哈佛研究显示 GPT-4 之后 22 到 25 岁、AI 暴露岗位（含软件开发）的就业率掉了约 13%；另一份独立研究显示入门级开发者招聘较 2022 年下降 67%；MIT 早期 2025 年的实验还发现把写作外包给 ChatGPT 的成年人脑活动下降、回忆变差，研究者称之为"cognitive debt"（认知债）。两人开的药方是借鉴医学培训的"先生制"（preceptor program）——一年期资深工程师带教，把判断力和系统品味这种隐性资本传下去。配着精讲二 Symphony 一起读最有杀伤力：Symphony 把"实现"工业化，但谁来培养下一代能审 Symphony 输出的人，这是行业必须现在就回答的问题。原文：微软 Russinovich 与 Hanselman 警告：AI 正掏空初级开发者人才管线。 Harness 不是目的，知识才是护城河 —— 腾讯 AI 工程团队的知识沉淀实践 腾讯技术工程团队这篇长文，几乎是把"Harness Engineering"这个 2026 年最热的话题从工具层面拽回到知识层面。作者 stevenpxiao 给出的核心判断是：构建 Harness 工作流不是最终目的，私域和团队知识的沉淀才是真正的技术护城河 。模型会迭代、工具链会更新、工作流会重构，但"领域模型 / 架构决策 / 最佳实践 / 已知陷阱 / 业务流程"这些知识不会因为模型换代而失效。文章把 Harness 拆成三支柱：上下文工程 （长短期记忆、知识检索注入、渐进式披露、上下文防火墙）、架构约束 （Agent 编排模式、状态机、降级策略、安全边界）、持续治理 （质量门禁、知识生命周期、自动衰减）。最值得抄进笔记本的是它给的"五层知识存储 × 五种类型 × 三级成熟度"模型——把团队知识按粒度分层，从快速验证一次的 hint，到经过多项目验证的 proven knowledge，再到生产级架构决策；新人进项目时，能直接"站在前人肩上"。这一篇和精讲二 Symphony、精讲三吴恩达的运营模型是同一组：当工作流被工业化，沉淀什么、怎么沉淀就是真正的差异化 。原文：Harness 不是目的，知识才是护城河 —— 一个 AI 工程交付团队的知识沉淀实践。 严肃聊聊，Skill 到底能蒸馏我们的几分之几？ 腾讯科技这一篇是这周最值得"反向思考"的长文。三月底 GitHub Trending 上一周内出现了五六个"蒸馏 Skill"项目：把离职同事的飞书、钉钉、Slack、微信记录喂给 Claude 自动生成 skill 文件的"同事 skill"一周拿了 9500 星；把前任蒸馏成 Skill 的 exskill 支持微信、QQ、社媒截图，甚至构建出五层性格结构；"老板 skills"用三个模块复刻老板审方案、汇报坏消息、说话风格；最浮夸的"女娲 skill"用 6 个并行 Agent 从 40 多个信息源提取公众人物心智模型，已经内置 Paul Graham、芒格、费曼等 13 个人。同一周 CMU 发表了 SKILLFOUNDRY 论文，扫一遍 GitHub 仓库、API 文档、Notebook 和论文，跑一次 pipeline 就挖出 286 个 skill、跨 27 个领域、71.1% 是现有库里没有的；在基因组细胞类型标注任务上，加了 skill 后覆盖率从 81.1% 提升到 99.2%、准确率从 68.5% 提升到 82.9%。但 GitHub 上同时也出现了 anti-distill——它能生成一份"看起来完整、核心知识却被掏空"的 skill 文件，把具体编码规则改写成"缓存使用遵循团队规范"这种正确的废话。文章的核心提问也是今天的主旋律之一：Skill 能蒸馏的是显性规则与知识路由，但隐性的直觉与效用判断蒸馏不掉。它和精讲三吴恩达的"通才优先"、Russinovich 的"junior 培养危机"是一组。原文：严肃聊聊，Skill 到底能蒸馏我们的几分之几？｜Hao 好聊趋势。 小米的野望：CFO Alain Lam 详解 AI 与全球化战略 挪威主权财富基金 CEO Nicolai Tangen 主持的《好公司相伴》播客这一期请到了小米集团 CFO Alain Lam。他梳理了小米十六年从手机起家、构建"人车家全生态"的扩张逻辑：MIUI 起步、用一年造出小米 1、布局智能家居、2021 年决定造车、不到三年推出第一款 SU7，集中十倍资源只做一款车 ——30 分钟卖出 5 万辆，福特 CEO 试驾六个月之后说"开了就甩不掉"。AI 在小米的落地非常全面：编程、销售预测、压铸检测、自研开源大模型；人形机器人 2019 年开始布局，目前先用于小米自家工厂提升效率，灵巧手已经做到接近真人手的尺寸和自由度。Alain 给出的关键判断是：物理世界数据稀缺，小米遍布全球十亿台联网设备的硬件生态恰恰是训练物理 AI 的关键资产 ——这一点和今天精讲一 gpt-realtime-1.5 把语音作为新交互层、和速览里楼天城世界模型 2.0 的"传感器直接驱动动作"形成了一条"物理 AI"的隐性主线。雷军则是亲自试驾 150 款车、考取赛车执照的产品狂人，"中国速度"不是口号，而是成熟供应链 + 前沿创新 + 超长投入耐心三件事的复合产物。原文：小米的野望：小米 CFO 详解 AI 与全球化战略。 量子位专访楼天城：AI 是匹脱缰野马，Harness 是这个时代最关键的能力 小马智行 CTO 楼天城在量子位的这场长访谈，把"Harness（驯马）"作为这个时代最关键能力之一的判断说得非常硬。他的逻辑链是这样的：今天的 AI 越来越像脱缰野马，开始学会调用工具、调用 Skill、自我演进，主动性和能量大幅提升，未来甚至连人类都可能成为被「调用」的一环 。当 AI 司机的安全性全面超越人类，再让人类工程师手把手教 AI 开车，无异于让业余棋手辅导 AlphaGo——人类驾驶数据的价值在逐步归零，研发主导权会逐步交给 AI。在这种背景下，小马智行发布了 PonyWorld 世界模型 2.0：人类不再是闭环中心，AI 正式成为总教练 ，自我诊断成为系统进化的核心引擎。技术路线上，他们选择跳过"语言"这个中间商，让传感器数据直接映射为驾驶动作——VLA（视觉-语言-动作）路线把 4D 物理时空降维成文字反而丢失了大量上下文。这一篇和精讲二 Symphony、精讲三吴恩达的"通才团队"是同一族判断：Harness 不只是 Coding Agent 的关键词，它正在变成所有"人类 + AI 主导研发"领域的共同范式 。原文：量子位专访楼天城：AI 是匹脱缰野马，Harness 是这个时代最关键的能力。 淘天营销中后台生码工作流最佳实践 大淘宝技术这一篇是把 AI 生码从"本地分散"收敛到"云端托管一体化"的真实工程复盘。背景很真实：财年初团队同时跑两条路径——简单需求走云端 Alex 平台一站式生码，复杂需求降级到本地 Cursor / CodeAgent CLI，结果是评估判断成本上升、AI 提效只覆盖到几个节点、需求交付全链路仍然靠人力串联。本地模式踩到的具体坑值得每个 AI Coding 平台借鉴：环境配置难统一 （Node 版本、网络代理差异巨大，同一套 MCP 在不同同学环境频繁出问题）、生态用工 AK 管理困难 （明文存储个人设备，分发、轮换、回收无统一管控）、执行易中断 （电脑息屏、网络断开就要手动续跑）。团队最终选择全部收敛到云端 AoneSuper 沙箱，并配套 git submodule + turborepo 的跨仓库工作区、可编排的场景化工作流。最有启发的是它把场景按确定性切两层：迁移和重构 （高确定性）用架构说明文档 + 领域 Skill 固化规则；日常迭代 （低确定性）引入"功能树"实现精准查表式知识供给，并用 D2C / API 还原优化、知识自动沉淀形成提效飞轮。一句方法论值得抄：给恰好够用的精确知识、确定性逻辑交工程、知识建正向循环 。配着腾讯"知识沉淀"那一条一起读，对"工作流如何服务于知识"会有非常具象的理解。原文：淘天营销中后台生码工作流最佳实践。 搜对≠答对：EAPO 用"证据奖励"让大模型不再靠猜 阿里通义实验室的这篇 EAPO 论文已被 ACL 2026 录用。问题切口很真实——AI 搜索把全网资料塞进几百万 token 的上下文，大模型却经常"答错或者蒙对"：举的例子是问周杰伦 2005 到 2010 年间演唱并获金曲奖提名的歌曲数，理想是 12 首，但模型要么答 15（把没演唱的《淘汰》也算进去），要么答 12 但引用的证据其实是错的。研究团队通过"树状证据采样"做预实验，把高质量证据直接喂给模型时准确率从 45% 飙到 63%；证据找得稀烂时，再优化推理几乎没用——找到对的证据，就几乎找到了对的答案 。EAPO 的方法论分三层：第一层强制模型走"分析问题 → 提取原文证据 → 执行推理 → 给出答案"的 4 步工作流，让中间证据环节透明可监督；第二层引入群组相对证据奖励，模型对同一问题生成多组证据组合，奖励模型挑出引用最精准、最具决定性的那组；第三层让奖励模型与策略模型协同进化，高置信度且答案正确的优质证据链反哺奖励模型微调，形成自适应闭环。结果是30B 模型在长文本推理基准上反超 120B 的 GPT-OSS 和 Claude-Sonnet-4 。这一篇和今天精讲一 gpt-realtime-1.5、速览楼天城的"AI 自我诊断"是同一类思路——监督信号要从最终答案下沉到中间过程。原文：搜对≠答对：EAPO 用"证据奖励"让大模型不再靠猜。 ## 扩展阅读 下面这 6 条是今天值得抽时间扫读的补充材料，每条说明它补充了什么、谁该读。 - 记忆，是 Agent 基建｜对话 Calvin@Vida ：OpenAI 4 月 21 日给 Codex 上线了记忆功能 Chronicle，第二天清华 00 后 Calvin 团队就把开源版 OpenChronicle 推上 GitHub 并冲到 X today's news trending 第一。文章核心观点是"记忆已经从产品功能变成 Agent 基建"——OpenChronicle 走本地优先 + 模型无关路线，AX Tree 优先解析、保存格式不绑定 Claude / Codex / OpenCode 任何一家。配着精讲二 Symphony 一起看，对"Agent 时代谁拥有记忆"会有更立体的判断。AI 工程师必读。 - Anthropic、OpenAI、谷歌和微软都认为智能代理控制层是产品，但在定价上存在分歧 ：InfoQ 中文这篇梳理了 16 天里三家厂商在 Agent 控制层（Harness）上的不同押注——Anthropic 在自己的基础设施上加单独计费的运行时（每会话每小时 8 美分）、OpenAI 把 harness 开源进 Agents SDK 只对模型和工具调用收费、Google 和 Microsoft 则打包成跨会话内存 / 代码执行 / 工具的消费层。文章对 Martin Fowler 给的"控制工程"定义做了完整梳理：围绕 AI 模型但不包括模型在内的一切——模型调用、上下文、工具编排、沙箱、持久化、权限、错误恢复、可观测性。给所有正在做 Agent 平台采购或自建的团队看：控制层是新市场，但商业模式还在分裂 。 - MCP in the Java World: Bringing Architectural Strategy to LLM Integrations ：InfoQ 这篇介绍了 MCP Java SDK 把 LLM 集成从随手调工具升级成有纪律的架构模式——协议级别的契约、anti-corruption layer、面向企业系统的治理。host 提供模型执行环境，client 中介请求，server 用清晰边界暴露 tools 和 resources，Tools 是动作、Resources 是结构化上下文数据。给 Java 系企业架构师和 Spring 团队的必读对照——把"AI 集成"做成长期可维护资产，不是又一段一次性脚本。 - GitHub Copilot is moving to usage-based billing ：GitHub 官宣，2026 年 6 月 1 日起所有 Copilot 套餐切到 usage-based 计费，premium request 单位换成"GitHub AI Credits"，按 token 消耗（含 input / output / cached）计算，付费套餐可加购。5 月初会先放出 preview bill，让用户和管理员看到 6 月切换前的预估账单。所有用 Copilot 的团队都该现在就把现有用量打出来 ，避免 6 月切换后被账单吓到。 - The Future Is Shrouded in an AI Fog ：Harvard Business Review 这篇 Toby E. Stuart 的策略文章给了个关键判断：AI 让未来的不确定性扩张，所有"长周期投入"——人才培养、企业战略、估值——都被打上了厚重的雾。建议从"重大单押"切到"分阶段承诺 + 期权式投入"。配着 Russinovich 的"junior 危机"一起读，会对"为什么 HR 现在最难做规划"有更深感受。 - 喝点 VC｜a16z 联合创始人：真正危险的不是投错项目，而是错过下一个 Google ：20VC 这场 Marc Andreessen 的访谈把风投核心心法摆得很直白——"成本上的错误"亏的是 1000 万美元，"机会成本上的错误"亏的是错过 1000 亿美元 ；判断创业者的关键特质是勇气加雄心，要能正面迎击问题、硬闯过去；最好的 AI 是面向消费者所有人都能拿到的版本，使用价值最有可能极端去中心化；早期阶段没有替代品，头两年就像烤蛋糕，最初配方写错后面再多资源也补不回来。给所有创业者和早期投资人看，也是今天最适合作为收尾的"判断密度高"的对话。 ## 今日阅读路径 如果你今天只能读三篇，按下面顺序： 1. 先读 OpenAI 开源 Codex 编排规范 Symphony：把 Linear 变成 Coding Agent 控制平面 ——这是今天信息密度最高的一篇，直接告诉你"Coding Agent 时代的工程组织长什么样"。读完它你就理解了今天的另外两条精讲为什么会同时出现。 1. 再读 吴恩达：AI 原生软件工程团队的新运营模型 ——把 Symphony 的工具论延展到组织论：通才取代专才、2 到 10 人同地小团队跑出最高效率、新瓶颈在产品和市场。这是今天最适合给团队转发的判断。 1. 最后读 微软 Russinovich 与 Hanselman 警告：AI 正掏空初级开发者人才管线 ——把上面两篇的"乐观面"反过来读一遍。当 Symphony 把实现工业化、吴恩达鼓吹通才小团队，下一代 senior 从哪里来？这是 2026 年所有工程组织都必须现在就回答的问题。 如果还有时间，把速览里的 Harness 知识沉淀 和 Skill 蒸馏 串起来读——前者告诉你"沉淀什么"，后者告诉你"哪些东西蒸馏不了"。 完整每日早报（含分群推荐、原文链接和深度阅读）请访问 BestBlogs：https://www.bestblogs.dev/。

译OpenAI近期发布Symphony与gpt-realtime-1.5，分别从工程师工作流与用户交互层面重塑软件控制平面。Symphony实现工单驱动的自动化编码，而gpt-realtime-1.5旨在提供产品级语音控制体验。吴恩达据此提出，AI原生工程团队应由小型通才团队构成，效率瓶颈将转移至产品与市场等领域。同时，微软专家警告此类工具可能导致初级开发者人才萎缩，引发行业对工程师核心判断力应沉淀于何处的深度思考。

Sam Altman@sama · 4月28日32

codex with the $20 plan is a really good deal

译每月20美元计划的Codex真是非常划算

Berryxia.AI@berryxia · 4月28日65

🚀 Claude Code 终于可以和浏览器并排实时控制了！ YC 大佬推出 GStack Browser + /open-gstack-browser skill，调试体验直接起飞！ 1. 在 Claude Code 中输入 Install GStack 快速安装 2. 输入 /open-gstack-browser 即可打开浏览器窗口 3. 实现 Claude Code 和浏览器完全 side-by-side 操作 4. 完美解决 Agent 调试时“看不见浏览器在干什么”的痛点 Claude Code 重度用户和 AI Agent 开发者必装神器！ 项目地址： https://github.com/garrytan/gstack

Berryxia.AI@berryxia · 4月28日69

小米 MiMo-V2.5 现已正式开源！ 采用 MIT License，支持商业部署、持续训练和微调 — 无需额外授权。 两个模型均支持 100 万 token 上下文窗口： • MiMo-V2.5-Pro：专为复杂 Agent 和编码任务打造，在开源模型中 GDPVal-AA 和 ClawEval 基准排名第一 • MiMo-V2.5：原生多模态模型，具备强大 Agent 能力 小米称：模型的价值不仅仅由排行榜决定——而是由它解决的问题来衡量。

译小米正式开源MiMo-V2.5系列模型，采用MIT许可证，允许商业部署、持续训练和微调。两个模型均支持100万token上下文窗口：MiMo-V2.5-Pro专为复杂Agent和编码任务设计，在开源模型的GDPVal-AA和ClawEval基准测试中排名第一；MiMo-V2.5是原生多模态模型，具备强大的Agent能力。小米强调，模型的价值不应仅由排行榜衡量，而应取决于其解决实际问题的能力。

宝玉@dotey · 4月28日69

转译：西方忘了怎么造东西，现在也快忘了怎么写代码 作者：Denis Stetskov 2023 年，在巴黎航展上，雷神公司的总裁站在台上，讲起他们为了重启“毒刺”导弹（Stinger）生产线，到底费了多大劲。 他们把一批 70 多岁的老工程师请了回来，让这些老人教年轻员工怎么造一枚导弹。图纸还是卡特总统时代画在纸上的老图纸。测试设备已经在仓库里躺了很多年。导弹的鼻锥还得靠手工安装，方法和 40 年前一模一样。 五角大楼已经 20 年没买过新的“毒刺”了。然后，俄罗斯入侵乌克兰，局势一下变了：所有人突然都需要这种导弹。 可生产线早就关了。电子元件已经过时。导引头组件也停产了。2022 年 5 月下的订单，要到 2026 年才能交付。 整整 4 年。 不是因为没钱，而是因为真正知道怎么造它的人，十年前就退休了，而且没人接上。 我在乌克兰带工程团队。我的团队见到的是这个问题的另一面。不是工厂车间，而是战场上接收武器的那一端。 当雷神还在努力根据 40 年前的蓝图重启生产时，美国已经在向乌克兰运送成千上万枚“毒刺”。RTX 首席执行官 Greg Hayes 说，10 个月的战争，消耗掉了相当于 13 年产量的“毒刺”。 这种模式，我太熟悉了。它现在正在我的行业里重演。 一百万发炮弹，没人造得出来 2023 年 3 月，欧盟承诺在 12 个月内向乌克兰提供 100 万发炮弹。 当时，欧洲一整年的炮弹产能只有 23 万发。而乌克兰每天就要消耗 5000 到 7000 发。 任何人拿个计算器算一下，都知道这事根本不可能。 到了最后期限，欧洲只交付了大约一半。马克龙后来称，最初那个承诺太鲁莽。由 9 个国家、11 家媒体联合发起的一项调查发现，欧洲真实的生产能力大概只有欧盟官方说法的三分之一。 那 100 万发炮弹的目标，直到 2024 年 12 月才真正完成，比原计划晚了 9 个月。 问题不是某一个环节卡住了。是每一个环节都卡住了。 法国在 2007 年就停止了国内发射药生产，整整 17 年没有继续做。欧洲唯一一家主要 TNT 生产商在波兰。德国自己的弹药储备只够用两天。丹麦一家 Nammo 工厂在 2020 年关闭，后来不得不从零开始重启。 整个欧洲国防工业，长期以来都被优化成一种模式：生产少量、昂贵、定制化的产品。没人为大规模生产做准备。也没人为危机做准备。 美国也好不到哪里去。 155 毫米炮弹壳主要靠宾夕法尼亚州斯克兰顿的一家工厂；爆炸物填装则依赖爱荷华州的一处设施；美国从 1986 年起就没有本土 TNT 生产了。 后来砸进去几十亿美元，产量依然没达到目标的一半。 要么合并，要么死 这不是偶然。 1993 年，五角大楼告诉国防企业的 CEO 们：要么合并，要么死。 于是，51 家主要国防承包商最终缩成了 5 家。战术导弹供应商从 13 家变成 3 家。造船厂从 8 家变成 2 家。国防工业劳动力从 320 万人降到 110 万人，砍掉了 65%。 弹药供应链到处都是单点故障（single point of failure，指一个环节出问题就会拖垮整个系统）。 155 毫米炮弹壳只有一家制造商，位于加州科切拉，而那里就在圣安德烈亚斯断层上。发射药装药也只有加拿大的一处设施能做。 整个系统被优化到成本最低，却几乎没有任何应急余量。 纸面上看，很高效。 现实里，只差一个坏日子，就会崩。 知识一旦死去，就很难复活 再看 Fogbank。 Fogbank 是一种用于核弹头的机密材料。它在 1975 年到 1989 年间生产，后来生产设施被关闭。 多年后，美国政府为了一个核弹头寿命延长项目，需要重新制造 Fogbank。结果他们发现，自己已经不会做了。 美国政府问责局（GAO）的一份报告指出，几乎所有掌握生产经验的人，要么退休了，要么去世了，要么离开了相关机构。留下来的记录也很少。 经历了 6900 万美元的成本超支，以及数年的失败尝试后，他们终于做出了可用的 Fogbank。 然后，又发现新批次太“纯”了。 原来的生产工艺里，曾经有一种无意中产生的杂质，而这种杂质对材料功能至关重要。可没人知道这件事。 负责复现的工程师不知道。几十年前做出原始材料的工人也不知道。 洛斯阿拉莫斯把它称为原始工艺中的“无意识依赖”（unknowing dependency）：这个环节很关键，但当年没人意识到它关键。 一个核武器项目，竟然失去了制造自己发明出来的材料的能力。 更可怕的是，知识并不只是随着人离开而流失。它从一开始就没有被任何人真正完整理解过。 (更正：原文最初版本曾写道，当年制造 Fogbank 的工人知道这种杂质的存在。事实并非如此。他们也不知道。这个依赖关系是无意形成的，这反而让“知识流失”的论点更强，而不是更弱。感谢评论区的 John F. 指出这一点。) 同一套剧本 我读到 Fogbank 的故事时，立刻认出了这个模式。 我说的不是核材料本身，而是那个熟悉的剧本： 花几十年建立起一种能力。 找到一个更便宜的替代方案。 让人才梯队慢慢萎缩。 享受节省下来的成本。 然后，当危机突然要求你拿回那种能力时，看着一切崩塌。 在国防工业里，那个替代方案叫“和平红利”（peace dividend，指冷战结束后减少军费、把资源转向民用经济的收益）。 在软件行业里，它叫 AI。 我之前写过“人才管道崩塌”的问题。招聘数据、初级工程师到资深工程师之间的断层，都已经有很多证据。还有“理解力危机”：人们会让 AI 写代码，却越来越不理解代码本身。 但我之前一直没有找到一个足够贴切的历史类比。 现在我找到了。 而这个类比告诉我们的东西，是招聘数据看不出来的：重建一种能力，到底需要多久。 重建能力永远需要很多年 国防工业里，每一次大规模恢复产能，哪怕是相对简单的系统，也要 3 到 5 年。复杂系统则要 5 到 10 年。 “毒刺”：从下单到交付，至少 30 个月。 “标枪”（Javelin）：花了 4 年半，产量还没翻倍。 155 毫米炮弹：投入 50 亿美元，4 年过去仍没达到目标。 法国直到 2024 年才重启发射药生产，而距离它关闭国内生产线，已经过去了 17 年。 钱从来不是最大的限制。 知识才是。 兰德公司（RAND）发现，潜艇设计中有 10% 的技术技能，需要 10 年在岗经验才能培养出来，有时还得建立在博士学位之后。国防工业里的技术工种，学徒期通常要 2 到 4 年；要达到能当主管的水平，则需要 5 到 8 年。 现在，把这套时间线放到软件行业里。 一个初级开发者，需要 3 到 5 年，才能成长为合格的中级工程师。 需要 5 到 8 年，才能成为资深工程师。 需要 10 年甚至更久，才能成为首席工程师或架构师。 这条时间线，不能靠砸钱压缩。 也不能靠 AI 压缩。 METR 做过一项随机对照试验（randomized controlled trial，医学和社会科学中常用的一种严谨实验方法）：经验丰富的开发者使用 AI 编程工具后，在真实开源任务上反而慢了 19%。 开始前，他们预测 AI 会让自己快 24%。结果现实和预期之间，相差了 43 个百分点。 研究人员后来想做后续实验时，相当一部分开发者拒绝参加——如果实验要求他们在没有 AI 的情况下工作，他们就不愿意。他们已经无法想象回到不用 AI 的状态。 账单总会来的 软件行业现在正进入同一种“优化”的第三年。 Salesforce 说，2025 年不会再招聘更多软件工程师。LeadDev 的一项调查发现，54% 的工程负责人认为，从长期看，AI 编程助手会减少初级工程师招聘。计算研究协会（CRA）对大学计算机院系的调查显示，62% 的院系报告今年入学人数下降。 我在代码审查里已经看到了这个问题。 现在，审查才是瓶颈。 AI 生成代码很快。 人类审查代码很慢。 于是行业的答案也很可预测：让 AI 去审查 AI 写的代码。 我不会这么做。 我改造了我们的拉取请求模板（pull request template，开发者提交代码变更时填写的说明模板）。现在，每个 PR 都必须说明：改了什么，为什么改，这属于哪类变更，以及修改前后的截图。 也就是说，我们要给审查者提供结构化上下文，不能让审查者靠猜。 我还在每个项目里安排专门的审查人员。更多双眼睛，就有更多机会发现模型漏掉的问题。 但这些仍然解决不了更深层的麻烦。 现在真正需要的能力已经变了。 光有技术能力不够。你还需要能主动负责、能清楚沟通取舍、能反驳机器给出的糟糕建议——哪怕那台机器说话听起来无比自信。 这些其实是领导力。 我们上一轮招聘就能说明这种人有多稀缺：2253 名候选人，2069 人被淘汰，最终录用 4 人。转化率只有 0.18%。 既有技术能力，又有判断力、能看出 AI 什么时候错了的人，在市场上几乎已经不存在了。 我们会记录一切。 Site Books、SDD、RVS 报告、带完整测试覆盖的样板模块……这些今天都有用，因为读这些文档的人，本身具备足够的工程能力，知道该怎么行动。 可如果以后读文档的人不具备这种能力，会怎样？ 坦白说，我不知道。 也许 5 年后的 AI 足够强，这些问题就不重要了。也许问题仍然可控。我没法预测 2031 年模型会强到什么程度。 但危机不会提前给你发日历邀请。 没人预料到 2022 年欧洲会爆发全面陆地战争。国防工业有 30 年时间做准备，但它没有。 就连 Fogbank 当年也有记录。只是记录不够。更糟的是，原来的工人甚至没有完全理解自己的工艺。 5 到 10 年后，我们会需要资深工程师。 我们会需要那种真正理解系统全貌的人；需要能在凌晨两点调试分布式故障的人；需要携带着那些代码库里根本不存在的组织知识的人。 可这些工程师现在还不存在，因为我们没有在培养他们。 本该现在学习成长的初级工程师，要么根本没有被雇用，要么正在形成一项由美国国防部资助的劳动力研究称为“AI 中介能力”（AI-mediated competence）的东西。 他们会提示 AI。 但他们说不出 AI 错在哪里。 这就是代码行业的 Fogbank。 当初级工程师跳过调试，跳过那些塑造能力的犯错过程，他们就无法建立隐性知识（tacit expertise，指难以写成文档、只能通过实践积累的经验性能力）。 等我这一代工程师退休时，这些知识不会转移给 AI。 它只会消失。 西方已经犯过一次这样的错误。账单在乌克兰到期了。 我知道这听起来像什么。我也知道，我之前已经写过人才管道的问题。 但国防工业这个例子，不是为了重复同一个论点。它是为了展示：如果行业现在对 AI 的期待落空，会发生什么。 “毒刺”、“标枪”、Fogbank、那一百万发没人造得出来的炮弹——这就是把赌注押在“优化”上，结果赌错之后要付出的代价。 而我们现在，正在软件工程上押下同样的赌注。 也许 AI 会变得足够强，这场赌局最后会赢。 也许不会。 当年的国防工业，也以为和平会永远持续下去。 来源：https://techtrenches.dev/p/the-west-forgot-how-to-make-things

译作者以国防工业为镜，揭示西方因长期“优化”导致关键能力流失的深层危机。雷神公司重启“毒刺”导弹生产线需召回70多岁老工程师，依赖卡特时代的图纸，新订单交付需4年。欧盟承诺的百万发炮弹交付严重延期，暴露出整个国防工业供应链存在大量单点故障，且缺乏大规模生产与应急能力。这种模式源于冷战后的“和平红利”政策，导致企业合并、劳动力锐减。类似地，核材料Fogbank的制造工艺也曾因人员流失而几乎失传。作者指出，软件行业正重蹈覆辙：过度依赖AI编程工具可能导致初级工程师培养断层和“理解力危机”。重建能力需要数年甚至数十年，核心限制并非资金，而是知识与经验传承的断裂。当前市场已极度缺乏兼具技术能力与独立判断力的人才。

Fuli Luo@_LuoFuli · 4月28日76

Just dropped two open-source models: MiMo-V2.5-Pro (Code Agent, 1T total) and MiMo-V2.5 (Multimodal Agent, 310B total). Oh and one more thing — we're giving devs & creators 100T tokens on us. Go build something cool 🛠️ 🎁 100T Free Token Grant for Builders http://100t.xiaomimimo.com

译小米宣布开源两个大模型：专攻复杂智能体和编码任务的MiMo-V2.5-Pro，以及原生全模态模型MiMo-V2.5。两者均支持100万token的上下文长度，并采用允许商业部署和微调的MIT许可证。同时，小米为开发者和创作者提供了100万亿token的免费额度，鼓励基于此构建应用。模型的价值不仅在于其在GDPVal-AA和ClawEval等基准测试中的排名，更在于其解决实际问题的能力。

宝玉@dotey · 4月28日74

GitHub Copilot 从 6 月 1 日起改按用量计费。订阅价格没变，但"用多少付多少"的规则会让重度用户的账单变得不太确定。 过去一年，Copilot 从一个编辑器里的补全助手，变成了能跑多步骤、跨整个代码仓库的 Agent 编程平台。一个简单的聊天提问和一次跑几个小时的自动编程任务，以前消耗的“高级请求次数”可能一样多，GitHub 一直在背后默默吸收那些飙升的推理成本。现在扛不住了。 新规则的核心：取消“高级请求次数”，换成 AI 积分（AI Credits）。积分按 Token 消耗计算，包括输入、输出和缓存的 Token，费率跟各模型的 API 定价挂钩。 各档订阅价不变，每月自动到账与订阅价等额的积分：Pro 是 10 美元对应 10 美元积分，Pro+ 是 39 美元对 39 美元，Business 19 美元/人，Enterprise 39 美元/人。代码补全和“下一步编辑建议”这类基础功能不消耗积分，跟以前一样包含在订阅里。 有两个细节值得注意。第一，以前高级请求用完了还能降级到便宜模型继续干活，以后这条退路没了，积分花完就是花完，除非买更多或者管理员开了预算。第二，Copilot 的代码审查功能除了消耗 AI 积分，还会额外消耗 GitHub Actions 的运行时长。 企业用户有三个月的过渡缓冲：6 月到 8 月，Business 用户每月拿到 30 美元积分（比订阅价多 11 美元），Enterprise 拿到 70 美元（多 31 美元）。企业还能把团队成员的积分打通成资源池，用不完的不浪费。 5 月初 GitHub 会上线预览账单功能，让你在正式切换前看看自己按新规则大概要花多少钱。年付用户暂时不受影响，到期后才会转到新体系。 对轻度用户来说，这次变化几乎无感。但如果你已经习惯了让 Copilot Agent 跑长任务，6 月之后最好盯一下账单。

译GitHub Copilot 将于6月1日起改用基于AI积分的用量计费模型，以支持更多Agent和高级工作流。各档订阅价格不变，每月赠送等额积分，代码补全等基础功能不消耗积分。新规则按Token消耗计费，积分用尽后无降级选项，代码审查会额外消耗Actions时长。企业用户有三个月过渡期及积分池福利。5月初将上线账单预览功能，年付和轻度用户受影响小，但重度用户需关注成本变化。

宝玉@dotey · 4月28日67

《Cursor 3 反馈整理：用户真正想要的不仅是“更炫的 IDE”，还想它是一个可靠的 AI 开发工作台》 整理自 Eric Zakariasson 征集 Cursor 3 反馈的帖子及 431 条回复。整体看下来，最有价值的意见可以归成几类：用户喜欢 Cursor 3 的 Agent 方向，但现在最强烈的诉求是“把 Agent、IDE、Git、浏览器、终端、模型选择和团队协作变成一条稳定的工作流”，而不是在多个模式之间来回切换。 第一类，也是最核心的一类：Agent Window 很有潜力，但不能牺牲 IDE 的基本能力。 很多人不是反对新界面，而是希望新 Agent 体验里也保留完整开发者习惯：LSP、调试、任务运行、扩展、快捷键、文件搜索、代码跳转、格式化、终端命令、diff 接受/拒绝等。现在的问题是，用户一旦进入 Agent Window，就经常需要为了一个小操作切回旧 IDE。真正理想的形态，是 Agent 负责推进工作，人类随时能无缝接管、检查、微调、运行、调试。 第二类：多 Agent 和多仓库协作，是 Cursor 3 最值得押注的方向。 不少用户提到想要类似看板、任务树、节点图的 Agent 进度视图，可以看到每个 agent / subagent 在做什么、卡在哪里、是否需要人介入。还有人希望有角色化 Agent 团队：一个做规划，一个实现，一个 review，一个跑 QA。对复杂项目来说，Cursor 的机会不是“一个聊天框写代码”，而是“多个隔离 worktree 中的 Agent 并行推进任务，再由用户统一调度和验收”。 第三类：Worktree、Workspace、Branch 和 Git 工作流需要产品级打磨。 反馈里反复出现 branch 切换、创建新分支、PR 检测、commit 当前 chat 改动、选择性 staging、multi-repo git diff、submodule 支持、CI 状态、PR comment、CodeRabbit 式 review、merge 后同步 main 等需求。开发者并不想每次都让 Agent 用自然语言帮自己做 Git 操作，他们想要一个低摩擦、可控、可审计的 Git 控制台。尤其是 Agent 多任务并行后，worktree 的命名、状态、来源、diff 和 PR 关系会变得极其关键。 第四类：信息架构和导航是当前体验的高频痛点。 很多人提到找不到 chat、项目太多、sidebar 混乱、当前焦点不清楚、面板切换麻烦、chat 自动滚到底、active agent 不明显、workspace 不能直接 pin、chat 重命名太麻烦。一个很有价值的建议是“Smart Rename”：让 Cursor 根据线程内容自动给 chat 命名。还有用户希望能 pin 某条消息、从某条消息 fork session、跨项目引用旧 session、把旧 chat 拖进新 chat 当上下文。这里的本质需求是：当 Agent 工作变多，Cursor 需要从“聊天记录列表”升级成“任务记忆系统”。 第五类：键盘优先和可自定义快捷键，是重度用户的底线。 高赞反馈明确说：整个产品必须可以不用鼠标操作。用户想快速在 chat、文件、文件树、终端、浏览器、diff、agent 之间切换，也想自定义 keybindings，继承旧 Cursor / VS Code 里的肌肉记忆。现在很多阻力不是功能没有，而是到达路径太深。对开发者工具来说，快捷键不是小优化，而是生产力体验的一部分。 第六类：稳定性和性能问题正在影响信任。 不少反馈集中在启动慢、Windows/WSL/SSH 问题、内存暴涨、CPU 飙升、OOM、多个 agent 后卡死、大代码库索引拖慢、文件树空白、chat reload 后消失、markdown 内容丢失、LSP 失效、Vue/Svelte 支持问题、终端状态不同步、Cloud/Local 不一致等。这里的信号很明确：Cursor 3 的野心很大，但如果基础稳定性不够，用户会暂时退回 Codex、Claude Code、T3 Code 或旧 Cursor。 第七类：模型和成本透明度，是用户越来越敏感的地方。 大量用户要求更高额度、更便宜的 Composer、支持本地模型、BYOK、OpenRouter、Codex 订阅、第三方模型订阅，或者至少在模型选择器里直接显示价格/质量/速度指标。用户不是只想要更多模型，而是想知道“这个任务用哪个模型最划算”。一个很好的方向是：Cursor 主动建议“这个任务可以用便宜模型”“这个任务值得开强模型”“上下文快满了，建议切新 agent 或自动生成 handoff”。 第八类：扩展、MCP 和外部工具集成，是 Cursor 维持护城河的关键。 很多人希望新 Agent 界面能支持旧 IDE 的扩展，尤其是 Git、CodeRabbit、debug、任务运行、格式化、语言插件等。MCP 方面，用户想要更稳定的连接、更好的 auth/state 管理、按 chat 启用不同 MCP、发现并推荐合适 MCP。还有人提到 GitHub、Vercel、Slack、Telegram、Linear、Asana、数据库、邮箱、部署、review、自动化通知等集成。Cursor 的机会是成为“开发自动化中枢”，而不是只做 AI 编辑器。 第九类：移动端和远程控制需求非常明确。 很多人要 iOS / mobile app，不只是为了“在手机上写代码”，而是为了随时查看 Agent 进度、回复 Agent 问题、批准命令、继续对话、看 preview、远程触发任务。Agent 越 autonomous，移动端就越有价值，因为用户需要的是“远程监管一个正在工作的开发助理”。 第十类：前端和设计工作流还可以更强。 不少反馈提到浏览器 preview、terminal、files 希望能同时打开；需要移动视图、缩放、DOM 元素选择、浏览器 profile 隔离；Design Mode 里希望能直接改文案、spacing、h1、选择多个元素、在父子元素间切换。更进阶的反馈是：希望接入 Figma tokens / design system，保证 Figma → Cursor → code → Figma 的一致性，不要让设计 token 在 AI 修改中漂移。 一句话总结： Cursor 3 的用户已经不满足于“AI 帮我改代码”。他们真正想要的是一个稳定、可控、键盘友好、支持多 Agent 并行、能理解多仓库和完整工程上下文的 AI 开发操作系统。 最值得优先做的是把这四件事打磨到极致： 1. Agent 和 IDE 无缝融合； 2. Worktree / Git / PR 工作流产品化； 3. 大项目下稳定、快、不丢上下文； 4. 模型成本、能力和任务分配变得透明可控。 如果 Cursor 3 能把这些做好，它就不只是“带 AI 的编辑器”，而会变成开发者管理 AI 工程团队的主界面。

译用户对Cursor 3的反馈显示，核心诉求已超越“AI辅助编码”，转向构建一个可靠、可控的AI开发工作流。主要需求包括：Agent功能需与IDE无缝融合，保留完整的开发工具链；支持多Agent协作与可视化进度管理；深度集成并产品化Git、Worktree和PR工作流；解决信息架构与导航痛点，升级为任务记忆系统；确保键盘优先操作与高度自定义；提升基础稳定性和性能以建立信任；增加模型选择与成本透明度；加强扩展、MCP及外部工具集成，成为开发自动化中枢；提供移动端以远程监管Agent；以及强化前端与设计工作流的集成能力。用户期望Cursor 3能演变为管理AI工程团队的稳定主界面。

OpenAI Developers@OpenAIDevs · 4月28日66

📣 What if every open issue had a Codex agent? That’s the idea behind Symphony, an open-source agent orchestrator for Codex that turns task trackers into always-on systems for agentic work, letting humans focus on review and direction.

译📣 如果每个未解决的问题都有一个 Codex 智能体呢？ 这就是 Symphony 背后的理念——一个为 Codex 设计的开源智能体编排器，它将任务追踪器转变为持续运行的系统，用于智能体工作，让人类专注于审查和方向指导。

Xiaomi MiMo@XiaomiMiMo · 4月28日71

Xiaomi MiMo-V2.5 is now officially open-sourced！ MIT License, supporting commercial deployment, continued training, and fine-tuning - no additional authorization required. Two models, both supporting a 1M-token context window : • MiMo-V2.5-Pro: built for complex agent and coding tasks, ranking No.1 among open-source models on GDPVal-AA and ClawEval • MiMo-V2.5: a native omni-modal model with strong agent capabilities A model's value isn't measured by rankings alone — it's measured by the problems it solves. Let's build with MiMo now! 🤗 Weights: https://huggingface.co/collections/XiaomiMiMo/mimo-v25 📄 Blog: https://mimo.xiaomi.com/index#blog

译小米正式开源MiMo-V2.5系列模型，采用MIT许可，支持商业部署、继续训练与微调。该系列包含两个支持100万令牌上下文窗口的模型：MiMo-V2.5-Pro专为复杂智能体和编码任务设计，在GDPVal-AA和ClawEval基准测试中位列开源模型第一；MiMo-V2.5则是具备强大智能体能力的原生全模态模型。官方强调，模型的价值不仅在于排名，更在于其解决实际问题的能力，并已公开模型权重与技术博客。

凡人小北@frxiaobei · 4月28日35

OpenClaw 4.1x 后对于 GPT 的支持上了一个大台阶，之前只说不干的毛病基本没了。 但是我修改了点 soul 文件里的内容后，他现在讲话总“卧槽”是怎么回事儿。 像极了刚走向社会的二愣子。

译OpenClaw 4.1x版本在GPT支持方面实现重大改进，基本解决了以往只说不干的缺陷。但用户修改soul文件内容后，AI在对话中频繁使用“卧槽”等口语化词汇，导致言语风格变得粗俗和不成熟。这种行为被比喻为刚走向社会的二愣子，反映出AI在个性化调整后可能出现意料之外的言行表现。

Z.ai@Zai_org · 4月27日41

The "triple usage" period for GLM-5.1 and GLM-5-Turbo is now extended to June 30. Availability: Anytime except 2-6 AM ET.

译GLM-5.1和GLM-5-Turbo的"三倍用量"使用期现已延长至6月30日。 可用时间：除东部时间凌晨2点至6点外，全天可用。

Greg Brockman@gdb · 4月27日40

gpt-5.5 great for hard tasks like writing GPU kernels

译gpt-5.5 非常适合编写 GPU 内核等高难度任务

meng shao@shao__meng · 4月27日63

用 Gemma 4 + Pi Agent 在本地跑一个 Coding Agent @patloeber 搭建了一个 100% 本地 Coding Agent： LM Studio（模型服务） + Gemma 4 26B A4B（Q4_K_M 量化）+ Pi（终端 Agent） # 模型选型：为什么是 Gemma 4 26B A4B Gemma 4 相比前代有三个关键升级，使其首次真正适合做 Agent： · 原生 function calling · 支持 system prompt · 具备 thinking mode 26B A4B：MoE 架构，总参数 26B，每 token 只激活 4B。质量接近大模型，速度接近小模型。 尽管激活只有 4B，但 26B 全量必须加载到显存（路由需要），所以显存占用仍按 26B Dense 模型估算。 不同显存量化建议： · Q4_K_M：18 GB，平衡推荐 · Q6_K：24 GB，更高质量 · Q8_0：28 GB，接近原版 # 上下文与显存的权衡（实战要点） 256K 上下文是上限，不是必须。Context 越大，额外 VRAM 占用越多，不同场景上下文推荐： · 单文件小改：16K · 标准编码：64K · 多文件重构：128K · 全仓库：256K 作者建议：显存允许就上 128K。Agent 会快速堆积上下文（文件内容、工具输出、对话历史），中途爆 context 非常糟心。 OOM 排错顺序：先降 context size，再调 GPU offload。 # Pi：极简主义的 Agent 框架 Pi（作者 Mario Zechner / badlogic）的设计哲学很值得关注——反堆砌： · 核心只给模型 4 个工具：read、write、edit、bash · 系统提示极短，token 高效 · 一切扩展能力通过 skills、extensions 注入 这对本地模型尤其重要：本地模型上下文窗口和理解能力都不如 GPT-5 / Claude，臃肿的 system prompt 会直接吃掉它的"工作内存"。Pi 把上下文预算尽可能留给真正的任务。 会话管理命令（缓解上下文压力）： /compact —— 压缩历史 /new —— 全新会话 /tree —— 浏览历史快照 /fork —— 从某节点分叉，不丢主线 # 安装与连接（关键配置） npm install -g @ mariozechner/pi-coding-agent ~/.pi/agent/models.json 让 Pi 指向本地 LM Studio： { "providers": { "lmstudio": { "baseUrl": "http://localhost:1234/v1", "api": "openai-completions", "apiKey": "lm-studio", "models": [ { "id": "google/gemma-4-26b-a4b", "input": ["text", "image"] } ] } } } # 能力扩展：Skills vs Extensions · 形态：Markdown 指令包 vs. TypeScript 模块 · 能做：注入领域知识/流程 vs. 自定义工具、命令、UI、权限、子 Agent · 触发：/skill:name 或自动发现 vs. 启动加载 值得装的几个： · liteparse：本地解析 PDF/DOCX/PPTX。Gemma 只能读图，所以文档要先被它转格式 · pi-skills：作者维护的官方合集 · frontend-slides、grill-me 等 # 安全警告（容易被忽略的部分） Pi 默认 YOLO 模式，bash 命令不询问直接执行。 本地模型出现幻觉的概率高于云端旗舰模型，"幻觉一条 rm -rf 命令"的风险是真实存在的。 作者给的三层防护选项： · permission-gate 扩展：危险命令前弹确认（轻量） · cco：把命令丢容器里跑（中等） · sandbox 扩展：完整沙箱（重） 至少装第一个。 # 原文在这 https://patloeber.com/gemma-4-pi-agent/

译开发者@patloeber分享了一套完全本地的Coding Agent方案，核心是Pi Agent框架与Gemma 4 26B A4B模型。Gemma 4因原生支持function calling和thinking mode，首次真正适合作为Agent；其MoE架构在质量与速度间取得平衡。Pi框架设计极简，仅提供read、write等四个核心工具以节省宝贵的上下文窗口。文中强调了上下文长度与显存的权衡，并给出安全警告：本地模型可能产生危险命令幻觉，建议至少安装permission-gate等扩展进行防护。

karminski-牙医@karminski3 · 4月27日50

给大家同步一下DeepSeek-V4 的测试进度，目前前面几项大家熟悉的测试都已经跑完了，还缺少大家期待的GPT-5.5-Pro (我去攒点银子), xiaomi-mimo, hunyuan-3-preview 的测试，这几个正在跑了。 然后这次我还增加了【大模型工程能力测试】，说下测试核心设计思路： 首先工程项目我选择了酒馆（SillyTavern-1.17.0），然后写的需求文档是让被测试大模型给酒馆增加一个支持实时解释器的数值系统。大家都知道酒馆其实搭配各种插件其实是可以实现数值系统的，比如RPG数值系统。 但是，大模型是没办法凭空创造数值逻辑的，所以本次的需求就是让大模型通过tool_call可以创建新的数值系统，比如属性，状态，天赋等等，并且定义数值与现有数值系统的逻辑，即，它可以注入一段js代码，与已有的js代码交互，形成新的逻辑。 比如现在只有hp，数值100/100, 然后AI可以通过调用我们的数值系统，创建一个新的状态，叫做中毒，中毒状态持续10个tik, 然后每个tik会减少10点生命值。这一切全是我们的数值系统在AI创建这个js代码逻辑后自动执行的，不需要AI再接管。 这样一来是可以大大拓展可玩性，二来是大模型不会因为玩家【求求你了我快寄了给我加1000HP】轻松实现作弊。 然后，我还需要魔改terminal coding cli (本次使用的是kimi cli), 即，大模型需要使用魔改后的kimi-cli 来fork一份酒馆源代码来实现我们这个新需求，而这个魔改的kimi-cli 可以监督大模型的实现过程，统计大模型的token使用，使用工具的情况和能力，最终再运行我们专门为这个需求定制的黑盒测试，实现真正的【工程级别分析】。酒馆源代码足足有20万行，纯js也有13万行，作为测试项目工程量足够大了。 除此之外，我还魔改了酒馆源代码模板（就是AI要fork那一份），增加了酒馆cli模式，这个模式可以让被测试大模型实现harness闭环，即模型修改完代码了，可以进入cli模式自己玩酒馆测试一下，看看对不对，从而反复迭代自己的代码，还顺便考验了大模型的 Agent能力。 总之，还请大家稍安勿躁，我会尽快放出测试视频。【跪谢大家】 #deepseekv4

译作者同步了DeepSeek-V4的测试进度，并重点介绍了一项新设计的“大模型工程能力测试”。该测试以约20万行代码的SillyTavern项目为基础，要求大模型通过tool_call创建新的数值系统（如属性、状态），并能注入JS代码与现有系统交互。测试使用魔改的kimi-cli来监督实现过程、统计token与工具使用情况，并运行定制黑盒测试。此外，通过为酒馆增加CLI模式，测试还评估了大模型的Agent能力，使其能自行测试并迭代代码。目前测试仍在进行中。

歸藏(guizang.ai)@op7418 · 4月27日35

最近正在重构 CodePilot，把 AI 能做的事情变得简单点，AI 不能做的东西变得详细点。

小互@xiaohu · 4月27日44

这个提示词牛P啊 ↓

译这个提示词牛逼啊

meng shao@shao__meng · 4月27日54

真正的「个人 Agent」应该是什么样？ 是 OpenClaw，还是 Codex 或 Claude Code，至少目前，他们都还不是！ # @petergyang 个人 Agent 七条标准 能力层（Capability） 1. 跨工具完成实事 —— 邮件、日历、Workspace、任意 API/MCP 2. 主动性与可靠性 —— 定时任务、触发器、自动跟进，并且失败要可见 认知层（Cognition） 3. 长期记忆 —— 让它越用越"懂你" 接入层（Access） 4. Web 和移动端原生可用，无需 /slash 命令或手动配置 5. 在文字、语音、视频、实时通话之间无缝切换 6. 能从第三方 IM 触达，像一个真人联系人 人格层（Personality） 7. 有个性，让人愿意聊 # 对三个产品的判定 Claude Code 问题在哪：接入层 + 人格层 关键问题：移动端要先 /remote-control 才能对话；cron 失败不通知；整体仍是"代码 IDE"的语境 Codex 问题在哪：接入层 关键问题：潜力大，但缺移动端 = 个人 Agent 的入口缺失 OpenClaw 问题在哪：能力层 关键问题：接入和人格最接近，GPT 5.5 比 5.4 更有性格，但不够可靠——重度用户得反过来找 Codex/Claude Code 修它

译作者提出了个人Agent应满足的七条标准：能力层需能跨工具处理任务并具备主动性与可靠性；认知层需拥有长期记忆；接入层需在Web与移动端原生可用、支持多模态无缝切换且能从第三方IM触达；人格层需具备个性。依据此标准，当前OpenClaw、Claude Code和Codex均未完全达标。Claude Code在接入便捷性和人格化上不足；Codex主要缺乏移动端入口；OpenClaw则在能力层的可靠性上有明显缺陷，导致重度用户仍需借助其他工具来修正其错误。

阿绎 AYi@AYi_AInotes · 4月27日57

说个扎心的真相，90%的AI工程师，其实什么都没做出来 Cluely的CEO Roy Lee在NYU做活动，当场掏500美元现金，问在场所有学AI的学生和工程师，谁在LinkedIn上真正上线过一个公开的项目，结果全场几乎没人举手。 太真实了，现在的AI圈就是这样，人人都能跟你聊大模型，聊Agent，聊世界模型，刷过几百篇论文，调过几十个demo，但你问他有没有上线过一个能让别人用的东西，大部分人都沉默了。 我们总以为AI时代拼的是谁懂的多，谁的技术深，其实根本不是。 LLM能帮你写80%的代码，能帮你解决大部分技术问题，但剩下那20%的脏活累活，部署，边缘case，用户体验，成本控制，才是真正能区分你和别人的地方。 所以别再当那个只会看教程的工程师了，去做去实践，去解决实际问题，，离线小模型App，自我迭代的代码Agent，个人生活OS，哪个都行。 不用等你学完所有东西，不用等完美，这个周末开干，下周就公开上线。哪怕做的很烂，哪怕只有几个人用，也比你藏在电脑里的一百个demo强一万倍。 在AI时代，知识已经变成了最不值钱的东西，到处都是教程，到处都是论文，真正稀缺的，是把知识变成公开可验证的产品的执行力。 别当那个坐在NYU教室里，连500美元都拿不到的人，动起来兄弟们

译Cluely的CEO Roy Lee在NYU活动中，以500美元现金询问在场AI学生和工程师是否上线过公开项目，几乎无人举手。这揭示了AI圈的普遍现象：工程师们热衷讨论大模型、Agent等理论，却缺乏将知识转化为公开产品的执行力。LLM虽能解决大部分技术问题，但部署、用户体验和成本控制等实际工作才是关键。知识在AI时代已泛滥，真正稀缺的是执行力。呼吁工程师立即实践，做出哪怕不完美的公开产品。

Orange AI@oran_ge · 4月27日14

昨天开放麦遇到刘小排 @bourneliu66 他说他烦死 AI 大 V 了 我说哥你也是 AI 大 V 他还喷了 labnana 是 vibe coding 出来的 我一笑而过，格局打开 还要帮他的 BuilderPulse 项目做宣传

译刘小排（@bourneliu66）在开放麦中表达对AI大V的厌倦，但被指出自己也是AI大V。他批评labnana项目基于vibe coding开发。作者以幽默态度回应，强调格局开放，并承诺帮助推广刘小排的BuilderPulse项目，凸显AI社区内自我反思与项目互助的互动。

Peter Steinberger 🦞@steipete · 4月27日40

Excited that GitHub shows real numbers here again. We been closing over 10k issues and close to 5k PRs this week thanks to clawsweeper and clownfish. Overall since December: 27k issues / 30k PRs closed.

译很高兴看到GitHub再次在此展示真实数据。本周我们借助clawsweeper和clownfish已关闭超过1万个问题及近5千个PR。 自12月以来总计：关闭2.7万个问题 / 3万个PR。

Greg Brockman@gdb · 4月27日30

codex empowers anyone to build

译开发者借助Codex大幅缩短游戏开发周期。朋友原计划耗时数周完成一款融合Guitar Hero、Dota和RPG机制的回合制游戏原型，但在Codex辅助下，团队快速清理了Godot代码库，并通过图像生成技术将草图转化为UI，短时间内构建出可玩性高的MVP版本，实际测试达两小时。这一经历促使开发者决定正式推进项目，体现了AI工具对创作流程的革新。

Yuchen Jin@Yuchenj_UW · 4月27日39

GPT-5.5 in Codex is really good. Frontier coding models are converging fast, and soon the differences will be less about raw model capability and more about harness, UX, reliability, price, and rate limits. Anthropic: release Mythos! What are you waiting for?

译Codex 中的 GPT-5.5 真的很棒。 前沿编程模型正在快速趋同，很快差异将不再主要体现在原始模型能力上，而更多在于工具链、用户体验、可靠性、价格和速率限制。 Anthropic：赶紧发布 Mythos！还在等什么？

Tibo@thsottiaux · 4月27日34

Looking at the traffic dashboard for Codex just now, it would be scary if we didn't have a lot more compute coming online in the coming weeks. All according to plan fortunately.

译刚才查看Codex的流量仪表板，如果未来几周我们没有更多计算资源上线，情况会很可怕。幸好一切都在按计划进行。

向阳乔木@vista8 · 4月26日85

http://x.com/i/article/2048407268547522560 # OpenAI GPT-5.5官方介绍 [AI翻译重写] OpenAI 在 4 月 23 日发布了 GPT-5.5，4 月 24 日 API 正式开放。 每次大模型发布，都会有一堆跑分截图刷屏，然后大家看完就散了。 但这次读完OpenAI的博客原文，有几个地方值得认真拆开来说。 > https://openai.com/index/introducing-gpt-5-5/ ## 它到底想解决什么 先说一个很多人都有过的体验。 用 AI 做复杂任务，你得像个项目经理一样全程盯着它。 稍微多几个步骤，它就开始跑偏，或者干脆停下来问你"接下来怎么办"。 你花在"管理 AI"上的精力，有时候比自己动手还多。 GPT-5.5 想解决的，就是这个问题。 OpenAI 的原话是：给它一个乱糟糟的、多步骤的任务，它会自己规划、调用工具、检查结果、处理模糊情况，然后一直做下去，直到完成。 这个方向比跑分数字更值得关注。 跑分可以调参刷出来，但"能不能真的把一件复杂的事做完"，才是实际工作里最重要的能力。 OpenAI 把这类能力叫做 Agentic，中文可以理解为"自主行动能力"，也就是模型能像一个真正的执行者一样，自己规划步骤、调用外部工具、处理中途遇到的障碍，而不是每一步都等人指令。 ## 跑分数据，先看这几个关键的 这张表对比了 GPT-5.5、GPT-5.4、GPT-5.5 Pro、GPT-5.4 Pro、Claude Opus 4.7 和 Gemini 3.1 Pro 六个模型。 几个重点数字： Terminal-Bench 2.0（测试复杂命令行工作流，需要规划、迭代和工具协调）：GPT-5.5 拿到 82.7%，GPT-5.4 是 75.1%，Claude Opus 4.7 是 69.4%。提升幅度不小。 GDPval（测试 AI 在 44 种职业里完成知识工作的能力）：GPT-5.5 是 84.9%，GPT-5.4 是 83.0%，Gemini 3.1 Pro 只有 67.3%。 OSWorld-Verified（测试模型能不能独立操作真实电脑界面，比如点击、输入、切换软件）：GPT-5.5 是 78.7%，GPT-5.4 是 75.0%，Claude Opus 4.7 是 78.0%，基本持平。 FrontierMath Tier 4（顶级数学难题，人类专家解起来也很吃力）：GPT-5.5 是 35.4%，GPT-5.4 是 27.1%，Claude Opus 4.7 是 22.9%，Gemini 3.1 Pro 只有 16.7%。这个提升幅度相当明显。 BrowseComp（测试模型在网上深度搜索和研究的能力）：GPT-5.5 Pro 拿到 90.1%，是所有模型里最高的。 ## 代码能力：不只是"写代码更快" 这两张图有个很有意思的地方：GPT-5.5 的点在右上角（得分更高），但横轴的位置（token 消耗）并没有比 GPT-5.4 多，甚至更少。 更聪明，同时更省。 这在大模型里不常见，通常能力越强，消耗越大。 Expert-SWE 是 OpenAI 内部的评测基准，专门测那种"长周期编程任务"，每道题的人类预计完成时间中位数是 20 小时。GPT-5.5 在这个测试上同样超过了 GPT-5.4。 > 视频地址：https://openai.com/index/introducing-gpt-5-5/?video=1185606271 演示里，有一个是从一张截图出发，让模型用 WebGL 和 Vite（两个前端开发工具）实现一个阿尔忒弥斯二号任务的 3D 轨道可视化 app，用的是 NASA 真实数据，还要支持交互操作和真实的轨道力学。 这种任务以前需要一个有经验的前端工程师花好几天。 两个真实测试者的反馈值得引用： Dan Shipper（Every 创始人）发布 app 后遇到了一个棘手 bug，调了好几天，最后让公司最好的工程师重写了部分系统才解决。 他拿 GPT-5.5 做了个回溯测试：把 bug 出现时的代码状态给模型，让它判断该怎么修。 GPT-5.4 做不到，GPT-5.5 给出了和那位工程师基本一致的方案。 他说 GPT-5.5 是"第一个让我感受到真正概念清晰度的编程模型"。 Pietro Schirano（MagicPath CEO）让 GPT-5.5 把一个有几百处前端改动和重构的分支，合并进一个同样有大量变更的主分支。 这种合并在工程上是噩梦级别的，人工做可能要花一整天。 模型大概用了 20 分钟，一次搞定。他说"感觉像是在和一个更高智能合作，甚至有一种尊重感"。 还有一个 NVIDIA 工程师说： > "失去 GPT-5.5 的使用权，感觉像是被截肢了。" Cursor 的联合创始人 Michael Truell 也给出了具体描述：GPT-5.5 比 GPT-5.4 更持久，在复杂的长任务里不会轻易停下来，这对他们用户最依赖的那类工作影响最大。 ## 知识工作：从"回答问题"到"帮你干活" GDPval 这个测试很有意思，它不是考数学或者写代码，而是测模型在 44 种真实职业里完成知识工作的能力，比如财务分析、法律文件、市场研究。 GPT-5.5 以 84.9% 的胜率领先，Gemini 3.1 Pro 只有 67.3%，差距相当大。 OSWorld-Verified 测的是模型能不能真正"用电脑"，不是在对话框里聊天，而是看屏幕、点击、输入、在不同软件之间切换。 GPT-5.5 达到 78.7%，接近 Claude Opus 4.7 的 78.0%。 Tau2-bench Telecom 测的是复杂客服工作流，GPT-5.5 达到 98.0%，GPT-5.4 是 92.8%。 而且这个测试是在没有针对性调整提示词的情况下跑的，其他模型的数据是调整过提示词之后的结果，所以这个对比对 GPT-5.5 来说其实更有说服力。 OpenAI 内部的真实使用数据： - 超过 85% 的 OpenAI 员工每周在用 Codex，覆盖工程、财务、市场、数据科学等几乎所有部门。 - Finance 团队用它审查了 24,771 份 K-1 税务表格（K-1 是美国的一种合伙人税务申报表），共 71,637 页，比去年提前了两周完成，而且流程里排除了个人隐私信息。 - Comms 团队用它分析了六个月的演讲邀请数据，建立了一套评分和风险框架，低风险请求自动处理，高风险的还是走人工审核。 - Go-to-Market 团队有人用它自动生成每周业务报告，每周省了 5 到 10 小时。 ## 科研能力：这个方向有点超出预期 GeneBench 是一个专门测多阶段科学数据分析的基准，聚焦遗传学和定量生物学。 这类任务的特点是：数据可能有错误或歧义，模型要自己判断，还要正确使用现代统计方法，而且很多题目对应的是科学专家需要花好几天的项目。 GPT-5.5 在这里的提升幅度比其他测试更明显：从 GPT-5.4 的 19.0% 跳到了 25.0%，Pro 版更是到了 33.2%。 BixBench 是围绕真实生物信息学和数据分析设计的基准（生物信息学，Bioinformatics，是用计算机方法分析生物数据的学科，比如基因序列分析）。 GPT-5.5 达到 80.5%，GPT-5.4 是 74.0%，是目前有公开成绩的模型里最高的。 数学证明的案例值得单独说。 一个内部版本的 GPT-5.5 配合自定义工具，帮助发现了一个关于拉姆齐数的新证明。 拉姆齐数（Ramsey numbers）是组合数学里的核心研究对象。 组合数学研究离散对象怎么组合在一起，比如图、网络、集合、模式。 拉姆齐数问的是：一个网络要多大，才能保证某种有序结构必然出现？这类结果极少，技术难度很高。 这个证明后来在 Lean 里得到了验证。 Lean 是一个数学形式化验证工具，可以用计算机严格检验数学证明是否成立。 也就是说，不是模型"说"它发现了证明，是真的经过了独立验证的数学结论。 两个研究者的真实使用案例： 免疫学教授 Derya Unutmaz 用 GPT-5.5 Pro 分析了一个有 62 个样本、近 28,000 个基因的基因表达数据集，生成了详细研究报告，还挖出了关键问题和洞察。 他说这些工作，他的团队做可能要几个月。 数学助理教授 Bartosz Naskręcki 用 GPT-5.5 在 Codex 里，从一个提示词出发，11 分钟内构建了一个代数几何 app，可以可视化两个二次曲面的交线，并把结果转换成 Weierstrass 模型（一种椭圆曲线的标准形式，在数论研究里很常用）。 他后来还扩展了 app，加入了更稳定的奇点可视化和精确系数输出，可以直接用于后续研究。 他说，这类自定义数学可视化工具以前需要专门的软件才能实现，现在一个提示词就能搞定。 ## 推理效率：模型帮助优化了运行自己的基础设施 这部分是原文里最容易被忽略、但技术上最有意思的地方。 GPT-5.5 是一个更大、更强的模型，按常理应该更慢、更贵。 但 OpenAI 说它的单 token 延迟和 GPT-5.4 持平，也就是响应速度没有变慢。 怎么做到的？ GPT-5.5 是专门为 NVIDIA GB200 和 GB300 NVL72 系统设计和训练的。 这是英伟达最新一代的 AI 推理硬件，专门为大规模语言模型推理优化。 但硬件只是一部分。他们还对推理系统做了大量软件层面的优化，其中最有意思的一个： 以前，每个请求在 GPU 上会被切成固定数量的块来处理，这样大请求和小请求可以在同一块 GPU 上运行。 但固定分块对所有流量形状都不是最优的。 Codex 分析了几周的生产流量数据，写出了自定义的启发式算法，动态决定怎么分块和负载均衡。 这个优化让 token 生成速度提升了 20% 以上。 也就是说，模型帮助优化了运行自己的基础设施。 这个递归关系有点微妙，但非常真实。 Artificial Analysis 的智能指数是由外部机构跑的 10 个评测的加权平均，包括编程、科学、推理等多个维度。 GPT-5.5 在这张图上的位置：智能指数最高，同时 token 成本处于中等水平，也就是 OpenAI 说的"顶级智能，一半的成本"。 ## 网络安全：能力越强，管控越严 这次发布在网络安全方向有专门的篇幅，值得单独说。 OpenAI 把 GPT-5.5 的生物化学和网络安全能力都评定为 High（高风险），但还没到 Critical（临界）级别。 这是他们内部 Preparedness Framework（准备框架，用来评估模型潜在风险等级的体系）里的分级。 CyberGym 测的是模型在网络安全任务上的能力：GPT-5.5 是 81.8%，GPT-5.4 是 79.0%，Claude Opus 4.7 是 73.1%。 CTF（Capture the Flag） 是网络安全领域的一种竞赛形式，参赛者需要找到系统漏洞、获取隐藏的"Flag"字符串。 这个内部测试用的是更难的 CTF 题目，GPT-5.5 达到 88.1%，GPT-5.4 是 83.7%。 OpenAI 的应对策略分三层： 第一层，加强管控。 针对高风险网络安全请求部署更严格的分类器，他们自己也承认"一开始可能会误伤一些正常用户"，会持续调整。 第二层，开放可信访问。 推出 Trusted Access for Cyber 计划，从 Codex 开始，通过身份验证的用户可以获得更少限制的网络安全能力访问权限，用于合法的防御性工作。 负责保护关键基础设施的组织可以申请访问 GPT-5.4-Cyber（专门的网络安全版本），但需要满足严格的安全要求。 申请地址是 chatgpt.com/cyber。 第三层，和政府合作。 探索如何用 AI 支持负责保护关键基础设施的政府机构，包括数字系统、电网、供水系统等。 ## 长上下文能力：这个提升幅度很惊人 MRCR（Multi-Round Conversation Retrieval） 测的是模型在超长对话里找到正确信息的能力。 8 根针，意思是在对话里藏了 8 条关键信息，看模型能不能全找到。 在 512K 到 1M token 的超长上下文里，GPT-5.5 达到 74.0%，GPT-5.4 只有 36.6%，Claude Opus 4.7 是 32.2%。 翻倍的提升。 这意味着 GPT-5.5 在处理超长文档、超长对话时，信息检索能力远超前代。 Graphwalks 测的是在超长图结构数据里做推理（比如找路径、找父节点）。 在 1M token 的场景下，GPT-5.5 的 BFS（广度优先搜索）得分是 45.4%，GPT-5.4 只有 9.4%。 ## 抽象推理：ARC-AGI-2 的数字很有意思 ARC-AGI 是一个专门测试抽象推理和模式识别的基准，被认为是衡量"类人推理能力"的重要指标。 ARC-AGI-1（相对简单版本）：GPT-5.5 是 95.0%，Gemini 3.1 Pro 是 98.0%，GPT-5.5 略低。 ARC-AGI-2（更难版本）：GPT-5.5 是 85.0%，GPT-5.4 是 73.3%，Claude Opus 4.7 是 75.8%，Gemini 3.1 Pro 是 77.1%。GPT-5.5 在这里反而领先了。 ## 定价和可用性，说清楚 ChatGPT 里： - GPT-5.5 Thinking：Plus、Pro、Business、Enterprise 用户可用 - GPT-5.5 Pro（更难问题，更高精度）：Pro、Business、Enterprise 用户可用 Codex 里： - GPT-5.5：Plus、Pro、Business、Enterprise、Edu、Go 计划可用 - 上下文窗口：400K token - Fast 模式：速度快 1.5 倍，价格是 2.5 倍 API（开发者接口）： OpenAI 特别说明：虽然 GPT-5.5 比 GPT-5.4 贵，但因为完成同样任务用的 token 更少，实际总成本对大多数用户来说不会增加太多，在 Codex 里甚至可能更省。 ## 最后说一个更大的背景 这次发布有一句话值得反复读： > "过去一年，AI 在软件工程领域的渗透速度极快。GPT-5.5 想做的，是把这种渗透扩展到科学研究和更广泛的知识工作。" 软件工程是第一个被大规模改变的领域，因为代码是结构化的，对错容易验证，反馈循环很快。 科学研究更难，因为数据有噪声，结论需要专业判断，验证周期很长。 但从 GeneBench、BixBench、数学证明这些案例来看，模型正在从"回答科学问题"变成"参与科学过程"。 这两件事之间的距离，比看起来要大得多。 能不能真的做到，还需要时间验证。但方向已经很清楚了。

译OpenAI发布GPT-5.5，核心目标是增强模型自主规划与执行多步骤复杂任务的能力，减少人工干预。在多项基准测试中表现突出：在Terminal-Bench 2.0、FrontierMath Tier 4等复杂任务上超越GPT-5.4及Claude Opus等竞品；在GDPval知识工作与OSWorld-Verified真实电脑操作测试中也保持领先。其代码能力更优且效率更高，科研能力显著提升，甚至辅助发现了拉姆齐数的新证明。尽管模型更大更强，其响应速度与GPT-5.4持平。

meng shao@shao__meng · 4月26日77

[论文分享] 深入阅读 Claude Code 泄露源代码，结合 Anthropic 官方文档和社区分析，重建出一个生产级 Coding Agent 的完整架构图谱，并以独立开源系统 OpenClaw 作为对照组！ 论文地址：https://arxiv.org/pdf/2604.14228 # 最核心的一个数字：1.6% vs 98.4% 社区估算：Claude Code 整个代码库里，只有约 1.6% 是"AI 决策逻辑"（提示词、模型调用、循环），其余 98.4% 是确定性的运行环境（permission、context、tool routing、recovery）。 这个悬殊比例意味着： · 模型几乎拥有完全自主决策权（reason 在哪做、调什么工具） · 但模型从不直接接触文件系统、shell、网络 · 工程复杂度不是为了约束模型，而是为了让模型在一个安全富饶的环境里自由发挥 这和 LangGraph（用状态图约束控制流）、Devin（显式 planner）走的是相反路线：最小脚手架 + 最大化操作型 harness。 # 团队做设计权衡时的五种人类价值驱动整套架构 · 人类决策权：用户最终拥有控制权；通过原则等级（Anthropic→operators→users）形式化 · 安全/隐私：即使用户不专心，系统也要保护代码、数据与基础设施 · 可靠执行：既要单轮正确，也要跨上下文窗口、跨会话、跨子 agent 保持一致 · 能力放大：让用户做以前根本不会尝试的事（Anthropic 内部数据：~27% 任务是"没有这工具就不会做"的） · 情境适配：系统适应用户项目、习惯、技能，关系随时间演进 第六个是评估视角而非设计价值：长期人类能力保留——这是论文最重要的批判性观察，后面会展开。 # 十三条设计原则与架构骨架 · Deny-first with human escalation（默认拒绝、不识别就升级给人） · Graduated trust spectrum（信任是渐进光谱） · Defense in depth（多重独立安全层） · Externalized programmable policy（策略外部化，可配置） · Context as scarce resource（上下文是稀缺资源） · Append-only durable state（追加式持久化） · Minimal scaffolding, maximal harness（最小脚手架 + 最大 harness） · Values over rules（重价值判断，轻硬规则） · Composable multi-mechanism extensibility（可组合的多机制扩展） · Reversibility-weighted risk（按可逆性加权评估风险） · Transparent file-based config/memory（透明文件而非黑盒数据库） · Isolated subagent boundaries（子 agent 隔离） · Graceful recovery and resilience（优雅恢复） 整体架构可以读作两层视图： · 七组件视图（高层）：用户 → 接口 → Agent Loop → 权限系统 → 工具 → 状态/持久化 → 执行环境 · 五层视图（细化）：Surface 层（CLI/SDK/IDE）→ Core 层（loop + compaction）→ Safety/Action 层（权限、hooks、tools、sandbox、subagent）→ State 层（context 装配、session、CLAUDE.md）→ Backend 层（shell、MCP、远程执行） # Agent 主循环：一个朴素的 while-true queryLoop() 是一个 async generator，每一轮固定走 9 步：设置解析 → 状态初始化 → 上下文装配 → 五个 pre-model shaper → 模型调用 → tool_use 派发 → 权限网关 → 工具执行 → 停止判定。 不再做的事：没有显式 planner，没有状态图，没有 tree search。这是 ReAct 的最简实现。 工具执行用 StreamingToolExecutor：模型一边流式输出 tool_use，一边并行执行只读工具，写操作串行。结果按收到顺序回填，保证模型看到的工具结果顺序与它发起请求时的顺序一致。 恢复机制有五种（输出 token 升级、reactive compact、prompt-too-long 处理、流式回退、fallback model），全部是"先静默自救、不行才告诉人"。 # 安全的"七层防御" 任何工具调用都要穿过这七层，任何一层都可以否决： 1. Tool 预过滤（被全局拒绝的工具甚至不会出现在模型视野里） 2. Deny-first 规则（deny 永远压制 allow，即使 allow 更具体） 3. Permission Mode 约束（plan/default/acceptEdits/auto/dontAsk/bypassPermissions/bubble 共七模式） 4. Auto-mode ML 分类器（yoloClassifier.ts，独立 LLM 调用判定安全性） 5. Shell sandbox（独立于权限系统的文件系统/网络隔离） 6. Resume 不恢复 session 级权限（强制重新授权） 7. Hook 拦截（PreToolUse 可阻断/重写/异步审批） 最关键的设计哲学：Anthropic 自己的研究发现用户对权限提示的批准率高达 93%——这意味着交互式确认在行为上不可靠。所以架构选择是"不靠人盯着"，而是用 sandbox + 分类器把需要人决策的次数压低 84%。 # 上下文管理：五层渐进式压缩 模型的上下文窗口是整套系统的瓶颈资源。每次模型调用前依次跑 5 个 shaper： · Budget reduction（始终生效）：单条 tool 结果超尺寸就替换为引用 · Snip：删掉旧历史段 · Microcompact：缓存友好的细粒度压缩，等 API 返回后再用真实 cache_deleted_input_tokens · Context collapse：read-time projection——存储不动，模型看到的是投影视图（这是论文里很精彩的设计） · Auto-compact：兜底的全模型生成式摘要 为什么要 5 层而不是 1 层：每层成本不同，先做便宜的轻压缩，不行才升级。这是 lazy-degradation 思想。代价是用户难以预测系统行为，因为有些层（特别是 context collapse）对用户不可见。 CLAUDE.md 的四级层次（managed→user→project→local）是文件型记忆——刻意拒绝向量数据库，理由是"用户必须能读、能改、能 git commit"。代价是检索粒度只能到文件级（用 LLM 扫文件头选最多 5 个），不如向量检索精细。 重要洞察：CLAUDE.md 是以"用户消息"形式注入而非 system prompt，因此对模型的约束是概率性的。真正的强制力来自 deny-first 的权限规则。这是一个刻意的"指引层（概率） vs 执行层（确定）"分离。 # 扩展机制：四个、不是一个 论文回答了一个常见困惑——为什么 Claude Code 既有 MCP，又有 plugins、skills、hooks？ 答案是这四者承担的上下文成本不同： · MCP servers：外部服务集成，上下文开销高 · Plugins：多组件打包分发，上下文开销中 · Skills：领域指令 + 元工具，上下文开销低 · Hooks：生命周期拦截，上下文开销默认零 梯度上下文成本意味着便宜的扩展（hooks）可以大量铺开，昂贵的（MCP）保留给真正需要新工具的场景。代价是开发者要学 4 套 API。 Hook 系统极其细致：源码定义了 27 种事件，其中 5 种参与权限决策，22 种用于生命周期/编排。 # 子 Agent：隔离而非共享 通过 AgentTool（Task 是它的 legacy alias）派遣。子 agent 有三种隔离模式： · Worktree：临时 git worktree，文件系统隔离 · Remote（仅内部）：远端 Claude Code 运行 · In-process（默认）：共享 FS，隔离上下文 关键约束：子 agent 只把最终摘要文本回传给父级，完整 transcript 走 sidechain 存独立 .jsonl 文件——既保留可审计性，又不污染父上下文。 代价：每次调用基本都得自包含 prompt（除 fork-subagent 外）。Anthropic 自己披露 agent teams 模式 token 开销约为普通 session 的 7×，这才是为什么"摘要回传"如此关键。 多 agent 协调用文件锁而不是 message broker——零依赖、可调试，但牺牲吞吐。 # 持久化：append-only JSONL Session 存为几乎只追加的 JSONL（极少数清理重写除外）。三条独立持久化通道： 1. Session transcript（项目级，每 session 一文件） 2. 全局 prompt history（仅用户输入，supports Up 与 Ctrl+R） 3. 子 agent sidechain（独立 .jsonl + .meta.json） --resume 重放 transcript 重建会话，但刻意不恢复 session 级权限——这是把"信任"作为会话隔离的安全不变量：用户每次都重新授权，避免旧上下文中的授权决策被带进新的语境。 compact_boundary 标记里嵌入 headUuid/anchorUuid/tailUuid，让 loader 在读取时打补丁拼接消息链——既压缩了上下文，又保留了完整历史的可重建性。 # 与 OpenClaw 的对照：同样的问题，不同的答案 维度：Claude Code vs. OpenClaw · 系统形态：临时 CLI 进程 vs. 持久化网关 daemon · 信任模型：每动作 deny-first 评估 + 7 模式 vs. 网关边界鉴权（DM 配对、白名单、可选沙箱） · Agent runtime：queryLoop() 是系统中心 vs. Pi-agent 嵌入网关 RPC，per-session 队列 · 扩展架构：4 机制按上下文成本梯度 vs. manifest-first 插件，12 种能力，集中注册表 · 内存：CLAUDE.md 4 级 + 5 层压缩 vs. 工作区引导文件 + dreaming 长期记忆推举 · 多 agent：父-子任务委派 vs. 路由（多 agent 服务不同渠道） + 委派两层分离 最有意思的发现是两者可组合：OpenClaw 可以通过 ACP 把 Claude Code 当作外部 coding harness 托管。这暗示 agent 设计空间不是平面分类，而是层级式的——网关层和任务层可以叠在一起。 核心洞察："Claude Code 把信任边界放在模型与执行环境之间；OpenClaw 把它放在网关周界。" # 五大价值张力（最有思想深度的章节） · Authority × Safety：93% 批准率证明人类督查不可靠，安全要靠分类器/sandbox 补 · Safety × Capability：>50 子命令的 bash 会跳过 per-subcommand 检查（解析慢导致 UI 卡顿）——defense-in-depth 的层共享性能瓶颈 · Adaptability × Safety：多个 CVE 利用"信任对话框出现前"的 hook/MCP 初始化窗口攻击 · Capability × Adaptability：主动式提示让任务完成率 +12-18%，但高频时用户偏好骤降 · Capability × Reliability：上下文有界 + 子 agent 隔离 → 局部好决策 ≠ 全局好结果 # 第六视角：长期人类能力保留 论文不把它列为价值，而作为评估透镜，外部经验证据汇总： · Becker et al. 2025（16 名经验丰富开发者 RCT）：AI 工具使开发者慢 19%，但他们自我感觉快了 20% · Shen & Tamkin 2026：AI 辅助组理解力测试低 17% · He et al. 2025（Cursor 在 807 个仓库的因果分析）：代码复杂度 +40.7%，初期速度增益三个月内消散 · Liu et al. 2026：30.4 万 AI 提交审计，约 1/4 引入的问题持续到最新版本，安全问题留存率更高 · Kosmyna et al. 2025（54 人 EEG 研究）：LLM 用户神经连接性减弱，且移除 AI 后仍持续 · Rak 2025：2023→2024 入门级技术岗招聘下降 25% 论文的判断是：Claude Code 显著放大短期能力，但提供的支持长期人类成长、深度理解、代码库连贯性的机制非常有限。 论文结尾把"未来系统应当把可持续性差距作为一等公民设计问题"作为最重要的开放挑战。 # 六个开放方向（未来 agent 系统） 1. 可观察性—评估鸿沟：78% 的 AI 失败是隐性的，89% 团队有可观察性但只 52% 做离线评估。需要 generator-evaluator 分离的脚手架。 2. 跨会话持久性：CLAUDE.md（静态）和 transcript（单会话）之间的"中间层"是空白 3. Harness 边界演化：where/when/what/with whom 四个轴向的扩展（特别是物理 VLA 行动会改变 reversibility-weighted risk 的代价不对称） 4. Horizon scaling：从单会话到多周期科学研究的可靠性 5. 治理与监管：EU AI Act（2026 年 8 月全面适用）、GPAI Code of Practice 对日志、透明度、人类监督提出外部约束 6. 长期人类能力作为一等设计目标：测量层与设计层都是空白 # 值得记住的几个判断 "模型推理在哪里、harness 执行在哪里——是整个 agent 系统设计的根问题。" "95% 单步准确率下，100 步任务成功率只有 0.6%。"——这是为什么每一步都要验证。 "前沿模型在编码任务上的能力正在收敛，operational harness 的质量正在成为主要差异化因素。" "agent 的设计选择不是平面的分类，而是层级化的——任务级 harness 可以被网关级控制平面托管。" "工程复杂度不是为了限制模型决策，而是为了让模型能更好地决策。" # 对工程实践的启示 对正在构建 agent 系统的我们： · 投入确定性基础设施（context 管理、安全分层、恢复机制）比给越来越强的模型套 planning 脚手架更有回报 · deny-first + 多层独立检查比单一沙箱在生产环境更鲁棒，但要警惕共享性能瓶颈导致的同时降级 · 上下文压缩做成多层渐进式比一次性截断或单步摘要更可靠，但用户需要可观察性 · append-only 持久化 + 不跨会话恢复权限是把审计性和安全不变量同时拿到的便宜做法 · 扩展机制按上下文成本分层：让"贵的"扩展（MCP）只用在真正需要新工具的场景，"便宜的"（hooks）可以铺开 · 子 agent 用摘要回传，不要共享 transcript——否则 token 开销线性爆炸（Claude Code 数据：7×） · 把用户长期能力保留写进设计目标，而不是只在事后用 metric 衡量

译论文通过分析 Claude Code 泄露源码，揭示其生产级 Coding Agent 架构的核心是“最小 AI 决策+最大确定性环境”设计。仅约 1.6% 代码为 AI 逻辑，其余 98.4% 用于构建安全、可靠的操作框架。架构围绕人类决策权、安全等五种价值驱动，采用七层独立防御体系保障工具调用安全，并通过五层渐进压缩策略高效管理上下文窗口。其扩展机制按上下文成本分级，子 Agent 采用隔离设计，整体强调透明性与用户可控性，与依赖状态图或显式规划的主流路径形成鲜明对比。

阿绎 AYi@AYi_AInotes · 4月26日56

翻墙出来一定要多看优质的信息源，不要只是出来看片！多逛英推区宝藏，看不懂听不懂阿绎给你翻译拆解系列03： 这个创造了Claude Code的男人Boris Cherny大神，完整公开了自己的工作流， 看完之后我发现，核心就三件事，但每一件都跟大多数人的直觉相反： 第一，永远选最贵最聪明的模型 听着像烧钱，实际上反过来，聪明模型一次想清楚，笨模型来回试错烧掉的token远超差价。 他的原话："计划做得好，代码自然好。" 第二，整个团队维护一个纯文本知识库 不是Notion，不是花哨的文档系统，就是一个txt文件。Claude每犯一次错，记一笔，每周更新好几次，这个文件就是团队的长期记忆，Claude不会在同一个地方摔倒两次。 第三，永远让Claude看到自己代码的运行结果 能跑代码，能看浏览器渲染， 他的比喻很准："你让一个画家蒙着眼睛画画， 画完不让他看，然后怪他画得丑？" 他的清晨流程：醒来，手机上启动三个任务，该干嘛干嘛，晚点回来检查。 规划模式起步 → 敲定计划 → 自动接受修改 → 完成 多个Claude实例，一个周密计划，一个共享知识库，没了。 很多人 Claude 被封号用不了，这里分享我自用的 AI 大模型聚合平台 ZenMux，汇聚全球最顶的大模型，包括 ChatGPT 5.5，GPT-image-2 等最近的都是当天发布当天上线，国内直连，比中转站安全稳定，总之用着很香，再也没有封号烦恼，性价比拉满🤙

译Boris Cherny公开其构建Claude Code的核心工作流，强调三个反直觉原则：1）始终选用最昂贵、最聪明的AI模型，因其一次性规划能力反而更节省token；2）团队维护一个纯文本知识库作为“长期记忆”，记录错误以避免重犯；3）始终让Claude能看到自己代码的运行结果，确保有效迭代。其流程依赖于周密规划、共享知识库和多个Claude实例的协同。针对Claude使用问题，推荐使用聚合平台ZenMux，该平台汇聚多款顶级模型并提供稳定服务。

Emad@EMostaque · 4月26日38

I don’t think there will be any coding models 3-4 years from now.

译我认为3-4年后将不再有任何编程模型存在。 [引用 @DavidOndrej1]：完全不同意。 收购Cursor是Elon的天才之举。 如果xAI在12-18个月内拥有最好的编程模型，我也不会感到惊讶。

Peter Steinberger 🦞@steipete · 4月26日48

Summarize 📝0.14.0 is out. GPT-5.5 Fast mode via `--fast`, Reddit thread extraction in the browser extension, local PDF `--extract`, and fixes for auto model config + Meta site compatibility. https://github.com/steipete/summarize/releases/tag/v0.14.0

译总结 📝0.14.0 版本已发布。 通过 `--fast` 启用 GPT-5.5 快速模式，浏览器扩展支持 Reddit 帖子提取，本地 PDF `--extract` 功能，以及自动模型配置修复 + Meta 网站兼容性修复。https://github.com/steipete/summarize/releases/tag/v0.14.0

Yuchen Jin@Yuchenj_UW · 4月26日33

GPT-5.5 still isn’t very good at making pretty frontends, which is understandable. People who are IQmaxxing usually aren’t looksmaxxing.

译GPT-5.5 在制作漂亮的前端方面仍然不太擅长，这是可以理解的。 通常专注于智商最大化的人不会专注于外貌最大化。

Peter Steinberger 🦞@steipete · 4月26日46

CodexBar 🎚️ 0.23 is out: Mistral support, Claude Designs/Daily Routines usage, Cursor Extra usage, GPT-5.5 pricing, cleaner widgets/menus, and a bunch of reliability fixes. https://github.com/steipete/CodexBar/releases/tag/v0.23

译CodexBar 🎚️ 0.23 已发布： 新增 Mistral 支持、Claude Designs/Daily Routines 使用情况、Cursor Extra 使用情况、GPT-5.5 定价、更简洁的小部件/菜单，以及一系列可靠性修复。https://github.com/steipete/CodexBar/releases/tag/v0.23

宝玉@dotey · 4月26日49

写 PRD（产品需求文档，Product Requirements Document）要写一版给 Agent 的吗？ 我觉得是没必要： 1. 如果人能看懂，模型更应该能看懂 2. 如果产品经理写的 PR 都可以直接给 Agent 用了，大部分场景程序员都不太需要了 3. 其实大部分场景已经不需要 PRD 了，可能几句话直接让 Agent 实现更快更好

译作者认为没有必要为AI Agent单独撰写产品需求文档。其核心观点是，如果人类能看懂的PRD，AI模型理应也能理解。若产品经理撰写的PRD已能直接供Agent使用，程序员在多数场景下将不再必需。更进一步，作者指出在许多场景中，冗长的PRD本身已非必要，直接通过简洁的指令让Agent实现功能可能更快、更好。这一讨论源于业界关于是否需要为Agent开辟PRD专门章节的实践探索。

SemiAnalysis@SemiAnalysis_ · 4月26日53

https://newsletter.semianalysis.com/p/the-coding-assistant-breakdown-more

译https://newsletter.semianalysis.com/p/the-coding-assistant-breakdown-more [引用 @sama]：我们在前端方面仍稍显逊色，但我们现在在智商上碾压了

Berryxia.AI@berryxia · 4月26日57

这个价格才是DeppSeek 应有的嘛！ 2.5折！ 不过就这几天截止5.5 日！

译Deepseek V4 官方推出2.5折优惠活动，截止日期为5月5日，旨在鼓励用户积极使用该模型。官方同时提供了配置 Claude code 的指南，强调需注意模型选择（如 deepseek-v4-pro 和 deepseek-v4-flash）和思考级别设置（例如将 EFFORT_LEVEL 设为 max），以优化集成和使用体验。

Sam Altman@sama · 4月26日34

how can they write code so fast?!

译他们怎么写代码这么快？！ [引用 @henrycunh]：codex app 正逐渐成为我用过的最好软件 发展速度快得离谱

TestingCatalog News 🗞@testingcatalog · 4月26日37

ANTHROPIC 🔥: Anthropic is working on Bugcrawl, a new Claude Code feature that would scan repositories for bugs using 10 parallel agents. It is very possible that this feature would target Teams and Enterprise plans, as with the Security and Code Review features. Whose stock will tank next? 👀

译ANTHROPIC 🔥: Anthropic 正在开发 Bugcrawl，这是一项新的 Claude Code 功能，将使用 10 个并行代理扫描代码库中的错误。 该功能很可能针对 Teams 和企业版计划，就像安全和代码审查功能一样。 接下来谁的股票会暴跌？👀

Tibo@thsottiaux · 4月26日42

It’s the little things that matter, what are some small papercuts you have noticed in Codex? We’ll fix as many as possible in the next week.

译细节决定成败，你注意到Codex中有哪些小问题？我们将在下周尽可能多地修复它们。

Tibo@thsottiaux · 4月26日27

You can just codex things

译你可以直接codex化事物

阿绎 AYi@AYi_AInotes · 4月26日67

说个暴论，这可能是今年对AI辅助开发影响最大的一次更新， TS大神@mattpocockuk Pocock刚刚给他的代码架构改进技能，加了一份只有37行的官方术语表， 要求所有AI输出必须严格使用里面的词汇，不能用component service API boundary这些烂大街的词， 一开始以为这就是多此一举，看完才反应过来，这才是解决AI乱改代码的终极方案， 以前AI给你的架构建议永远是正确的废话，它会告诉你要解耦要模块化，但不知道什么是深模块什么是浅模块， 现在有了这套统一语言，它终于能准确说出这个模块是透传的没有价值，那个接口太浅应该合并， 最狠的是那个删除测试，想象删掉这个模块，如果复杂度消失了，它就不该存在， 如果复杂度分散到了所有调用方，它才真正创造了价值， 不像是给人看的词汇表，更像是给AI定的思考规则，它把架构改进从凭感觉的艺术，变成了可重复可验证的工程。 https://github.com/mattpocock/skills/blob/main/improve-codebase-architecture/LANGUAGE.md

译TS大神Matt Pocock为其代码架构改进技能制定了一份仅37行的官方术语表，强制AI在输出建议时使用统一、精确的词汇，摒弃模糊术语。此举旨在解决AI随意修改代码的问题，使其能准确识别模块深浅与价值。通过“删除测试”等方法，将架构改进从主观艺术转变为可重复、可验证的工程实践。

Greg Brockman@gdb · 4月25日31

what are you building with codex?

译你在用 Codex 构建什么？ [引用 @PaulSolt]：本周末你打算用 GPT 5.5 和 Codex 制作什么应用？