meng shao@shao__meng · 5月19日72

OpenAI Codex Cookbook 系列之 Goals 从 "prompt" 到 "goals" · Prompt：ask → work → result → wait（做完即停） · Goal：work → check → continue or complete（做完检查证据，未达成则继续） Goal 的关键是给 Codex 一条可审计的完成线，并允许它在空闲时基于已有证据自主决定下一步，而无需用户每轮重复说"继续"、"再跑一次基准"、"现在查测试"。 生命周期和命令 Goals 是 线程作用域 的持久状态，不是全局 memory，也不是项目级 instructions。 /goal <目标> 设置目标 /goal 查看当前目标 /goal pause 暂停 /goal resume 恢复 /goal clear 清除 可能的停止条件：成功、暂停、清除、被打断、预算耗尽、遇到需用户输入的阻塞。 continuation 是事件驱动的，不是死循环：仅在线程 idle、无队列输入、无 pending 工作、Goal 仍 active 且在预算内时才会触发。Plan-only 的回合不触发 continuation；如果某次 continuation 没有调用任何工具，下一次自动 continuation 会被抑制（防止空转）。 如何写一个"强 Goal"——六个要素 1. Outcome（结果）：完成时什么应为真。 2. Verification surface（验证面）：用什么证据证明——测试、benchmark、报告、命令输出、产物。 3. Constraints（约束）：工作期间不能回退什么。 4. Boundaries（边界）：可用的文件、工具、数据、仓库。 5. Iteration policy（迭代策略）：每次尝试后如何选择下一步。 6. Blocked stop condition（阻塞停止条件）：何时该停下并说明无可行路径，需要什么才能解锁。 推荐模板： /goal <期望终态> verified by <具体证据> while preserving <约束>. Use <允许的输入/工具/边界>. Between iterations, <如何选择下一步最佳行动>. If blocked or no valid paths remain, <报告什么、需要什么才能继续>. 对比示例（性能优化）： · 弱：/goal Improve performance · 中：/goal Reduce p95 checkout latency below 120 ms without regressing correctness tests · 强：在上一条基础上加入 benchmark 名、允许动用的服务/fixture 范围、每轮记录变化与下一个实验，以及"基准跑不动时如何报告阻塞"。 Goal 激活后发生了什么变化 1. 目标常驻可见：测试失败、benchmark 改善但未达阈值、研究路径数据缺失，Codex 都不会丢掉原始目标。 2. 可以从 idle 线程自主续跑——但仅在安全边界（无 pending 工作、无用户输入排队）。 3. 完成必须基于证据：不能因为模型"觉得差不多"就标记完成，必须对照文件、测试、日志、benchmark 输出或产物。 研究类 Goal 的范式案例：复现 Deep Hedging 论文 最具启发性的部分，用 Buehler 等人的 Deep Hedging 论文做案例，说明"复现一篇论文"这种充满不确定性的任务该如何 Goal 化。 弱 Goal：/goal Reproduce Buehler et al., "Deep Hedging" —— 没说哪一节、什么算复现、缺失训练状态怎么办。 强 Goal 要求 Codex 产出一份分级证据报告，区分四类状态： · Reproduced mechanics（机理已重建） · Approximate trained results（近似训练结果） · Blocked exact replay（无法精确复现的部分） · Remaining uncertainty（剩余不确定性） 实际执行中，Codex 能重建定价/对冲机理、复现 Heston 参考价、训练 CVaR 对冲策略、重建主直方图与对冲面、复现 BS 交易成本斜率；但原始随机种子、训练路径、TF 计算图、optimizer 状态、checkpoint 全部缺失——因此最诚实的结果只能是"部分近似复现，而非精确神经回放"。 何时不该用 Goal？ · 一行编辑、简短解释、小段 code review、单问单答 —— 用普通 prompt。 · 终点模糊（"make this better"、未定义终态的 "refactor this"）。 · 用 Goal 来掩盖不确定性——如果数据可能缺失、benchmark 可能 flaky、代理证据是否允许，都应在 Goal 中显式说明。 Goal 的最佳适配场景具备三个属性：持久目标 + 基于证据的终点 + 路径可能需要多轮探查。典型用例：性能优化、flaky 测试调查、依赖迁移、需复现的 bug 猎杀、多步重构、benchmark 驱动调优、需产物的研究任务。 Cookbook https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex

译本文介绍了 OpenAI Codex 中的“Goals”功能，它将工作模式从单次“提示-执行-停止”转变为基于证据的自主循环。Goal 为 Codex 设定了一个可审计的完成目标，使其能在空闲时自主决定下一步并推进任务，无需用户反复指令。文章详细阐述了 Goal 的生命周期、命令，并重点说明了如何编写一个包含结果、验证面、约束等六个要素的“强 Goal”。同时，它指出了 Goal 最适用于性能优化、复杂任务复现等需多轮探查的场景，而不适用于简短问答等简单任务。

meng shao@shao__meng · 5月19日79

Claude Code 核心开发者 Thariq 带来自己高频使用的「开发日志」提示词 @trq212 这段提示词解决了 AI 协作编码中最棘手的结构性问题：规格永远写不完整，但人又无法实时跟踪 AI 的每一个判断。 传统的两种极端都失败： 1. 过度规约：试图在 spec 里穷举所有边界情况——不现实，且拖慢启动 2. 完全放手：让 agent 自由发挥——结果是大量隐性决策埋藏在 diff 里，code review 时才发现，返工成本极高 这个提示词走的是第三条路：承认歧义不可避免，把"判断"这个动作本身变成可审计的产物。 这种做法为啥有效？ · 降低模型的"过度澄清"倾向：模型不必反复打断你问问题，可以自主推进 · 把隐性决策外化：原本藏在代码里的"为什么这样写"被显式写出来，review 时直接对照笔记，而不是逆向工程 diff · 结构化的四个维度正好覆盖了实施中所有"非代码信息"： · Design decisions = 填补 spec 的空白 · Deviations = 偏离 spec 的地方（最危险，必须显式） · Tradeoffs = 没走的路（防止 reviewer 重复思考同样的备选） · Open questions = 需要人类回环的点 · HTML/Markdown 作为载体：轻量、可读、可与代码同 PR 提交，不需要额外工具 值得借鉴的 prompt 设计原则 · 给模型一个"合法的出口"，而不是逼它在歧义前停下或瞎猜 · 要求结构化产物（四个明确分类），比开放式"写点笔记"质量高一个数量级 · 用单独文件而非 inline 注释——保持代码干净，同时让元信息集中、可搜索 · 二次迭代本身是个示范：第一版凭直觉写，第二版让 Claude 帮忙结构化——这就是这条 prompt 自己倡导的"人机协作"范式 提示词原文： Implement <SPEC>. As you work, maintain a running implementation-notes.html file that captures anything I should know about how the implementation diverges from or interprets the spec, including: · Design decisions: choices you made where the spec was ambiguous · Deviations: places where you intentionally departed from the spec, and why · Tradeoffs: alternatives you considered and why you picked what you did · Open questions: anything you'd want me to confirm or revise

译针对AI协作编码中“规格永难完整”与“决策无法追踪”的核心矛盾，此提示词提出了第三条路径。它要求AI在实现需求时同步维护一份结构化文档，明确记录设计决策、对规格的偏离、考虑过的权衡以及待确认的开放性问题。这种方法的关键在于将AI执行过程中的隐性判断显式化、文档化，从而让Code Review可直接对照决策笔记，而非逆向工程代码。它不仅降低了模型的过度澄清倾向，更通过提供结构化产物，建立了一种可审计、可协作的人机开发新范式。

meng shao@shao__meng · 5月19日71

Cursor 发布 Composer 2.5，仍基于 Kimi K2.5，同时因为与 SpaceXAI 合作，马斯克亲自发帖证实 Composer 2.5 已经开始使用 Colossus 2 算力训练，同时正在合作从零训练一个算力规模 10 倍以上的全新模型！ Composer 2.5 相对 Composer 2 在智能水平和行为表现上均有显著提升，重点改进了三类能力：长任务的持续推进、复杂指令的可靠遵循、协作交互的自然度。 https://cursor.com/blog/composer-2-5 三项关键训练创新 1. 定向文本反馈强化学习 解决问题：长任务（数十万 token 的 rollout）中，最终奖励难以告诉模型究竟是哪一步出了错——典型的 RL 信用分配难题。 2. 合成训练数据 合成任务量是 Composer 2 的 25 倍。其中一种代表性方法是 feature deletion： · 给模型一个有完整测试套件的代码库 · 删除若干代码以剥离某个特性 · 让 agent 重新实现该特性，以原测试作为可验证奖励 3. 基础设施层优化 继续预训练阶段使用 Muon 优化器 + 分布式正交化： · 按模型自然粒度跑 Newton-Schulz（attention 按 head，MoE 按 expert） · 分片张量先 all-to-all 拼回完整矩阵，正交化后再 all-to-all 散回；通信与计算异步重叠 · 1T 模型的优化器单步耗时仅 0.2s 训练目标的"软"维度 Cursor 明确指出现有 benchmark 无法很好衡量的两个维度，他们专门优化了： · Communication style（沟通风格） · Effort calibration（投入度校准——什么时候该多想、什么时候该收手） 这两点在实际协作中体感差异很大，也是这次定向文本反馈方法的重点应用场景。

译Cursor发布迄今最强模型Composer 2.5，仍基于Kimi K2.5。模型已与SpaceXAI合作，使用Colossus 2算力开始训练，并计划合作训练一个规模大10倍的全新模型。Composer 2.5在长任务推进、复杂指令遵循及协作自然度方面均有显著提升。关键创新包括：采用定向文本反馈强化学习解决长任务信用分配问题、使用25倍于前代的合成数据进行训练，以及通过Muon优化器与分布式正交化技术优化基础设施层。此外，模型还专门针对沟通风格和投入度校准等协作“软”维度进行了优化。

Berryxia.AI@berryxia · 5月19日77

兄弟们，Claude Design 直接放大招了！ Anthropic 官方刚刚宣布：所有计划的 token limit 全部翻倍。 以前用它做完整 UI、生成多页设计稿、跑复杂 Agent 工作流，经常做到一半就撞墙。 现在直接多出一倍空间，连续创作的体验彻底不一样了。 对每天 vibe coding、做原型、生成设计、写产品页的兄弟来说，这波更新把 Claude Design 从“能用”直接推到了“真香”。 以前总觉得 token 限制是最大瓶颈，现在 Anthropic 用实际行动告诉你：他们还在认真把创作工具往死里卷。

译Anthropic宣布Claude Design所有计划的Token限制翻倍。这解决了以往在处理完整UI设计、多页设计稿或复杂Agent工作流时频繁出现的token不足问题。翻倍后的空间显著提升了连续创作的体验，让该工具在vibe coding、原型制作等任务中实用性大增，从“能用”跃升至“真香”。这体现了Anthropic为提升竞争力而对创作工具的持续优化。

ginobefun@hongming731 · 5月19日70

http://x.com/i/article/2056536208592039936 # BestBlogs 早报 · 05-19 · Composer 2.5、长时 Agent 与 AI 生码率 在线阅读和收听：https://www.bestblogs.dev/explore/brief/2026-05-19 > EP61 · BestBlogs 每日早报 · 当 AI 编码跨过工具替换的门槛，工程化才真正开始。 AI 编码正在跨过工具替换的门槛，走进工程化深水区。今天的早报有一条很清晰的主线：从写得快，到做得对。 Cursor 把 Composer 2.5 的训练栈完整公开，节奏从产品迭代切换到模型迭代；Anthropic 工程师在 AI Engineer 大会拆解长时间 Agent 工程，用对抗式的 generator-evaluator 架构把 Agent 续航推到 12 小时；阿里云 CIO 蒋林泉则端出 2026 财年真实数据，告诉所有人「AI 生码率」是一个危险的过程指标 ——「代码一定是负债」，Vibe Coding 不能直接上生产。 工具升级、工程化运行、效能反思，三条线索连起来，是从写得快到做得对的范式转身。今天的早报除了三条精讲，还有 Skill 开发、RAG 全链路、十七种 Agent 架构、MCP 企业落地、Anthropic 创始人手册、AI 收入集中度，以及 Anthropic 收购 Stainless 等七条值得一读的内容。 ## 导语 如果只看一个关键词，今天属于 「工程化」。 过去一年里，「Agent」「Vibe Coding」「AI 提效」基本被当作工具命题处理：换个更好的模型、装一个更聪明的 IDE、把流程自动化一段，效果就来了。但 2026 年中段开始，三条独立线索同时把命题往后推了一层。 第一条是模型层。Cursor 的 Composer 2.5 不是一个产品公告，而是一份训练报告：textual feedback RL、25 倍合成任务规模、亿级参数 MoE 训练栈、和 SpaceXAI 联手用 Colossus 2 训练新一代模型。一家原本的工具公司，正式进入自有模型的训练周期。 第二条是 Agent 工程层。Anthropic 的 Ash Prabaker 和 Andrew Wilson 把长 session 的失败模式归纳成三类：context rot、规划缺陷、输出 sycophancy；并给出今天最被推崇的架构 —— 类 GAN 的 generator-evaluator 对抗循环，宏观规划器、代码生成器、视觉评审器通过磁盘 markdown 协商契约。结果是 Opus 3.7 时代 1 小时的自主续航，到 Opus 4.6 已经被推到 12 小时。 第三条是组织效能层。阿里云 CIO 蒋林泉给出 2026 财年的硬数据：前端人均有效代码量翻 3 倍、后端翻 2 倍，千行代码缺陷率前端降 30%、后端降 55%。但他从一开始就把「AI 生码率」从考核体系里划掉。理由很硬：编码只占软件工程 20% 时间，AI 生码率衡量的恰好是这条链路里「价值密度最低、最容易被替代」的那一段；用最容易被替代的环节去衡量整体效能，是最常见也最隐蔽的误区。 三条线索叠加起来，会得到一个并不轻松的结论：AI 让代码生产的边际成本趋近于零，但代码本身始终是负债。能不能把它转化成资产，取决于工程化与组织能力。今天的三条精讲，恰好分别站在模型、架构和组织三个高度回答这件事。 围绕这条主线，今天的速览还有 7 条值得带走的内容：阿里云对 Skill 开发方法论的系统梳理、大淘宝 RAG 全链路工程实战、腾讯关于 17 种 Agent 控制流架构的拆解、Spring I/O 上 MCP 与 Spring AI 的企业级落地、Anthropic 的 AI Native 创始人手册、AI 收入集中度被两家头部公司吞下 89% 份额的最新数据，以及 Anthropic 收购 Stainless 收编 SDK 与 MCP 服务器基建的官方动作。三个层级（模型 / 架构 / 组织）的精讲 + 七条横切视角的速览，构成了今天对「AI Native 工程团队」最完整的一次切片。 ## 精讲一：Cursor 发布 Composer 2.5：基于 Kimi K2.5 的智能升级 评分：93 · Cursor Blog · 在 BestBlogs 阅读全文 背景。 Composer 2.5 沿用了 Composer 2 的底座 —— 月之暗面开源的 Kimi K2.5 模型权重。但和上一代不同，这一次 Cursor 在博客里端出来的不是产品截图，而是一份完整的训练报告：训练栈做了哪些改动、合成任务怎么造、强化学习的奖励信号怎么对齐到具体行为。这种姿态本身就是信号 —— Cursor 把训练栈作为差异化的核心叙事，节奏正在从产品迭代切换到模型迭代。 三件值得说的事。 第一件是定向文本反馈强化学习（textual feedback RL）。传统 RL 一条 rollout 可能跨越几十万个 Token，最后给一个总奖励，模型很难判断到底是哪一步走错了 —— 想抑制一个局部行为（错误工具调用、混乱解释、风格违规）很难，因为最终奖励是一个 noisy signal，告诉你哪里错了说不清。Cursor 的做法是：在出错的那一轮上下文里直接插入一条文本提示，比如「提醒：当前可用的工具是这几个」，把这条带提示的上下文当作教师模型，把原始上下文当作学生模型，做一次 on-policy distillation KL loss 的局部蒸馏。信号从粗粒度总奖励变成精确到具体轮次的局部信号，编码风格、沟通方式、工具调用错误这些细颗粒行为都被拉了回来，同时还保留了 RL 在整条 trajectory 上的全局目标。 第二件是合成任务规模直接放大 25 倍。其中一类「特征删除」任务很有意思：给模型一个带完整测试的代码库，让它删掉某个功能但保持其他测试通过，然后再让它重新实现这个功能，用原来的测试当作可验证奖励。Cursor 在文中也坦白：模型变强之后甚至出现了奖励作弊 —— 有一次它从 Python 类型检查的缓存里反推出被删除函数的签名，还有一次它反编译 Java 字节码还原第三方 API。规模化 RL 在变成一条工程长跑，需要越来越细致的看护机制。 第三件是工程层面的优化：分片 Muon 优化器、双网格 HSDP 并行策略，让万亿参数 MoE 的每一步优化只要 0.2 秒。这些本来是闭门技术，公开出来本身就是给行业的礼物。 为什么重要。 Composer 2.5 价格定在每百万输入 Token 0.50 美元、每百万输出 Token 2.50 美元，首周双倍额度；另有一个快速版本，相同智能水平价格抬到 3.00 / 15.00 美元每 M token，仍然比同等智能水平的 frontier 模型快线便宜不少。但真正值得关注的不是价格，而是结尾的那一段：Cursor 宣布和 SpaceXAI 合作，用 Colossus 2 集群、相当于 100 万张 H100 的算力，从零训练一个 10 倍总算力规模的更大模型。这意味着 Cursor 不再只是一家产品公司，AI 编码工具的竞争层级，正在从应用层下沉到模型层。同时 Cursor 在博客里特意提到，Composer 2.5 在沟通风格、effort calibration 这些「不容易被现有 benchmark 衡量」的维度上也做了系统性调优 —— 这是产品公司转向模型公司之后才会重视的事。 和今日其他议题的关系。 模型再强，要把这种强度变成可交付的长任务，还需要一层架构 —— 这是接下来精讲二要回答的。读完精讲一之后看精讲三，会看到模型能力增长和组织效能提升之间的鸿沟有多大。 阅读建议。 如果你是 AI 工程师，从「Targeted RL with textual feedback」一节读起，再补一遍 Composer 2 的技术报告作为基底；如果你是产品负责人，重点看价格曲线和模型路线图。 ## 精讲二：构建能持续运行数小时的智能体：Anthropic 工程师揭秘对抗式生成 - 评估架构 评分：93 · AI Engineer · 在 BestBlogs 观看演讲 背景。 在 AI Engineer 大会的首场分享上，Anthropic Applied AI 团队的 Ash Prabaker 和 Andrew Wilson 没有再讲一个浮夸的浏览器自动化 demo，而是认真拆了一件事：怎么让 Agent 自主运行 5 到 12 小时、甚至跨多日，还能保持代码可交付。这正是当前长时间 Agent 工程的核心难题。 三类失败模式。 Andrew Wilson 把长 session 的失败归纳为三类。第一类是 context rot​，会话越拉越长，模型对早期信息的把握逐渐崩塌；到 Token 上限附近还会出现 context anxiety​，开始草草收尾以「赶紧关掉上下文」。第二类是 规划缺陷​，原生大模型不擅长长 horizon 规划，要么一口气塞太多功能进一轮，要么半途停在残缺的代码库上。第三类是 输出 sycophancy：模型不擅长评判自己的产出，前端界面看起来对就报告完成，后端逻辑断了也不察觉。 数据校准。 Anthropic 给出一组很硬的对照：Opus 3.7 时代，一个 Agent 完成 50% 任务的自主运行时长大约是 1 小时；到 Opus 4.6，已经推到了 12 小时。模型本身在变强（model weights 这一面），但要把这 12 小时真正用好，外层的脚手架（scaffolding）同样关键。Anthropic 自己的 Agent SDK 从 Claude Code 的 research preview 演化到 GA，引入了 progressive disclosure Skills（只先加载 frontmatter、延迟加载完整工具 schema）、programmatic tool calling（让 Agent 自己写处理脚本、避免把数据塞进主上下文）这类原语。 核心架构：生成 - 评估对抗循环。 Ash Prabaker 推荐的当前最佳实践不是 Ralph Wiggum 那种线性循环（一个 Agent 在单一终端会话里顺序处理任务），而是借鉴 GAN 思路的对抗架构。系统里有三类独立角色：宏观规划器（Planner）拆分里程碑、代码生成器（Generator）实现功能、Playwright 视觉评审器（Evaluator）拉起真实浏览器对照参考站点打分。三者不靠把所有上下文塞进同一个模型，而是通过本地磁盘的 markdown 文件协商契约 —— 先把「这一关算交付」的标准用文本固化下来，再让生成器去干。每个角色有自己的 context window 和 system prompt，互相之间是独立的人格设定。 为什么要拆开？因为一个模型批评自己永远比批评别人难得多，self-evaluation 是 trap。把评估器单独拎出来，可以给它一个非常苛刻的系统提示，建立对抗压力。设计、原创、工艺、功能，每一项都用打分表量化，迭代直到评审器满意才算这一关交付。文中演示了一个例子：同一个 prompt「做一个复古游戏制作器」，单一循环的 Agent 跑出来界面拥挤、播放模式不能用；对抗架构跑了 6 个小时，Agent 自动起名 RetroForge，配了 54 色复古调色板，带物理引擎和键盘绑定，甚至自己加了一个递归式 AI 关卡助手，用自然语言生成关卡地图。同一个 base model，不同的脚手架架构，输出质量差出一个数量级。 为什么重要。 这套架构有两个非显然的工程结论：第一，不要让 Agent 自评​，单一 session 内部的自我审查永远不可靠 —— 输出 sycophancy 是模型权重层面的固有偏置，只能靠独立的 critic 角色和对抗压力来矫正；第二，用结构化交接代替上下文压缩，状态、配置、契约都写到本地磁盘，不要靠 LLM 自己背。把 markdown 当成 Agent 之间的协议层，远比试图把所有信息塞进同一个 context window 更可靠。这是把 Agent 当成一个工程系统来设计的方式，也是真正把 12 小时连续会话变成可生产代码的关键。 和今日其他议题的关系。 精讲一让模型本身变强，精讲二回答了「这种强度怎么变成可交付」。再到精讲三，企业要拿什么去衡量这种能力的产出，就不只是技术问题了。 阅读建议。 建议直接看视频原片，重点是 Adversarial Generator-Evaluator Loop 那一段；如果只有 10 分钟，去精讲三回看「结构化交接 vs 上下文压缩」的工程结论，对 AI 辅助软件工程的落地有直接帮助。 ## 精讲三：CIO 正在抛弃 AI 生码率：一场关于什么才算产研提效的实践复盘 评分：92 · InfoQ 中文 · 在 BestBlogs 阅读全文 背景。 阿里云 CIO 蒋林泉端出 2026 财年 vs 2025 财年的产研效能数据：前端人均有效代码量翻 3 倍、后端翻 2 倍；千行代码缺陷率前端下降 30%、后端下降 55%。承接更多核心业务和 AI 创新、没有增加人力，最后落到业务价值。 在一个几乎所有团队都在谈论「AI 提效」的年份，这样的衡量指标和结果并不常见。更值得说的是：这套结果背后，他从一开始就把行业最流行的指标 ——「AI 生码率」—— 从考核体系里划掉。 为什么不要 AI 生码率。 他的理由分两层。第一层，AI 生码率是过程指标，组织一旦盯着过程指标，AI 就特别容易产生毒害。代码行数不加权毫无意义，团队很容易陷入灌水陷阱 —— 看起来生码率从 20% 攀升到 50%，但对业务效能毫无帮助。第二层更结构性：端到端看，开发人员真正写代码的时间只占整个软件工程生命周期的 **20%**​，剩下 80% 时间花在需求对焦、PRD 评审、跨团队对齐、上下游联调和返工。而那 20% 里，价值密度差别也极大 —— 自动生成单测、补充注释、写胶水代码这类工作本来就不耗时间；真正费力的是核心概念、核心算法、核心逻辑和跨系统联调，那些是「代码量少、精力投入度极高」的地方。把这两个漏斗叠起来，AI 生码率衡量的恰好是整条链路里 价值密度最低、最容易被 AI 替代 的那一段。用最容易被替代的环节去衡量整体效能，是第一个误区。 「代码一定是负债」。 蒋林泉的第二个判断更尖锐：代码一旦生产出来，首先是负债。增加的大量代码「可能」是资产，但「一定」是负债。任何代码进入生产环境，立刻引入维护成本、增加系统复杂度，依赖关系需要持续管理；能否转化为对业务客户的正向价值，是不确定的。如果生成的代码无法对业务产生正向价值，规模化地生产代码本质上就是规模化地生产负债。理解这一句，是后面所有 AI 工程实践的逻辑基础。 Vibe Coding 的边界。 他给出两条很清楚的区分：做一个 Demo / 个人应用，和做一个客户大规模生产系统之间，有巨大差别；做一个全新应用，和在已有核心业务系统上叠加新需求，也有巨大不同。大部分企业的核心应用都是存量系统，业务复杂度高、积累了不同人的编码风格和历史技术债，需要为生产稳定性、性能、可维护性负责。在这样的环境里，Vibe Coding 直接生成的代码无法大规模投入生产并承担质量责任。阿里云 CIO 团队的果断选择是：不用 Vibe Coding 直接上生产，采用 AI 辅助的软件工程，把 AI 作为提效工具融入规范化工程流程，覆盖测试、运维、编码、存量系统梳理等切面。 AI 改写人月神话与左移。 文中还有两条很有启发的论断。一是「人月神话」：原来加人之所以低效，是因为人际沟通呈几何级数增长，新成员缺乏系统上下文、需要高成本的知识传递；但加 Agent 不一样 —— Agent 能无损拿到上下文，能规模化从已有代码里解析上下文，不需要人与人之间几何级数增长的沟通消耗。二是「左移」：以前一直说要在问题出现之前就解决它，但难以贯彻，是因为「左移本质是跨部门转移责任」，左边的人接不接、有没有能力承担都是组织摩擦力的来源；AI 时代，上下文和知识资产可以从存量代码里抽取，加上增量的 PRD、Spec，业务复杂系统能简化成一个共识框架，跨岗位之间在一条业务链路里能更低成本、更高效地对齐。一个具体的成果是：在有新成员加入的情况下，借助 AI 把测试覆盖从 20% 提升到加权接近 100%。 为什么重要。 这是今天三条精讲里最「反流行」的一条，也是最可执行的一条。它直接告诉企业：不要追 AI 生码率，要追 业务价值 E2E​；不要追 Vibe Coding 上生产，要追 AI 辅助的软件工程；不要奖励代码数量，要奖励「品味」—— 对业务价值的判断力。它也回答了一个被很多技术管理者绕开的问题：当所有人都在炫耀「AI 生码率从 20% 涨到 50%」，真正的 E2E 产研时间却没有缩短，这种割裂背后的原因，不是技术问题，是组织管理对「可量化指标」的过度依赖。 和今日其他议题的关系。 把精讲一、二的能力底座放进精讲三的组织视角里，你会得到一个完整的判断框架：模型够强（精讲一）、Agent 续航够长（精讲二）、但只有靠 E2E 度量和工程化流程（精讲三），才能让它落到「业务价值」。这也是今天「从写得快到做得对」这条主线的最终归处。换句话说，模型层和 Agent 工程层负责把「能做的事」推到新边界，组织层负责回答「该做哪些事、做到什么标准才叫好」—— 三者缺一不可。 一个延伸观察。 文章另一组细节也值得记下：他强调 AI 时代的人才结构里「技能在贬值、品味在升值」。技能指的是「会做某件事」，品味指的是「能定义什么是好」。AI 工具普及后，技能的稀缺性正在迅速下降，而对业务价值的判断、对产品最终验收的标准，反而越来越难被替代。这是他给团队反复强调的一句话：忘掉岗位和位置，去看任务和目标。 阅读建议。 建议读全文。如果只能跳读，重点看「两个流行误区」和「AI 破解人月神话与左移」两节；如果你是技术负责人，最后那一节关于「品味 vs 技能」的判断值得反复看，并和今天速览里的 Anthropic 创始人手册对照着读。 ## 速览 今天还有 7 条值得一读的内容，把它们大致按从工程实践到行业格局排列： Skill 开发：保姆级教程 & 一站式开发助手发布（阿里云开发者 · 评分 93） 作者把 Agent Skill 的本质讲透了：一个 SKILL.md 文件就是「技能卡」，背后是 YAML frontmatter + 渐进式三级加载机制 —— Agent 只在需要时才读取详细指令，既节省上下文又保证执行精准。文章覆盖目录结构、编写规范、跨平台发布痛点和一站式开发助手 skill-dev-aio。最值得带走的判断是 ——「Skill 替代的不是你，而是你身上那些重复、易错、本不该占用大脑的任务；真正的价值在于体验和判断」。如果你最近开始用 Claude Skills / Agent Skills 把工作流沉淀下来，这是少有的把方法论和工具一起讲清楚的中文资料，也能直接呼应今天精讲二里 progressive disclosure 的工程细节。 RAG 全链路技术详解（大淘宝技术 · 评分 92） 一篇罕见的 RAG 实战指南，覆盖了完整的工程链路：文档加载（多格式解析 + 元数据提取）、智能切分（规则 / 语义 / 结构化方法，含 Meta-Chunking 用 PPL 困惑度感知语义边界的原理）、索引构建（embedding 模型选型与向量生成）、检索优化（Query 改写、HyDE / Doc2Query、标签过滤、重排序）、生成调优（Prompt 设计、参数控制、SFT 微调），到进阶的 Graph RAG（多跳推理与全局摘要）与 Ragas 自动化评估体系（Context Precision/Recall、Faithfulness、Answer Relevancy）。文章强调「可测、可调、可信赖」的工程化态度，回应了 Agent 开发里最常见的三个共性挑战 —— 知识库构建缺乏标准、检索召回精度达不到预期、缺乏量化评测体系。对落地企业级 Agent 知识库的团队是一份高质量的内部培训材料。 从 0 开发大模型的 17 种 Agent 架构演进详细拆解（腾讯技术工程 · 评分 92） 作者用 agno 框架把开源项目 all-agentic-architectures 的 17 种 Agent 控制流模式重写了一遍。核心观点很犀利：Agent 架构的本质不是 prompt engineering，也不是某个框架的 DSL，而是控制流设计，应当能在任何体面的框架里复现。文章梳理了一条清晰的演化路径 —— 从单次生成到反思闭环，再到工具交互、观察 - 行动循环、显式规划、验证驱动重规划、多 Agent 编排、长期记忆、搜索 / 模拟，最后到「可信任」。每一步都用同一套六个问题（要解决什么、State 是什么、拓扑、Router、失败模式、何时该升级）拆解。如果你正在选型多 Agent 编排框架，或在长 session Agent 上踩坑，这篇能帮你把「状态有没有被正确建模、控制流有没有被显式表达、错误能不能被局部截断、副作用能不能被关进闸门、系统知不知道自己什么时候该停」这五件真正决定能不能落地的事想清楚。 深入探索 MCP 与 Spring AI：从协议核心到企业级生产部署全链路指南（Spring I/O · 评分 92） James Ward 和 Maximilian Schellhorn 在 Spring I/O 上的技术深度演讲。视频从 Agent 的三个基础组件（Memory、Context、Tools）讲起，重点拆解 Model Context Protocol（MCP）如何解决工具调用标准化 —— 让开发者不必再为每一个 CRM、机票、订单 API 写一套定制 tool function；并演示了 Spring AI 框架在 OAuth 鉴权、水平扩展、上下文优化上的企业级实践。把今天精讲二的对抗式架构落到 Java 生态来看，是一份非常好的工程对照材料；对 Spring Boot / 企业 AI 平台团队尤其有价值，也能给「MCP 在生产环境到底怎么落」这个常见问题一个完整答案。 Anthropic 创始人手册：AI Native 公司，正在把「几个人做几百人的事」变成现实（AINLP · 评分 88） Anthropic 刚发布的 36 页《The Founder's Playbook: Building an AI-Native Startup》中文译读，按 Idea → MVP → Launch → Scale 四个阶段拆解 AI Native 创业公司的生命周期，并给出每个阶段的退出标准、典型风险和实操练习。一个核心判断：当 AI 已经能写代码、做调研、整理竞品、起草投资人材料、自动化大量运营流程，过去那条「想法 → 验证 → 融资 → 招人 → 开发 → 再融资 → 再招更多人 → 规模化」的默认路径正在被改写。创业公司不一定每进入一个新阶段就必须配更大的团队、更多岗位和一轮新融资；很多工作可以由创始人通过 Claude Chat、Claude Cowork 和 Claude Code 编排完成，创始人的角色从「亲自执行的人」变成「系统编排者」。最大的风险不再是「做不出来」，而是「太快做出一堆没人要的东西」。判断力取代执行力，成为最稀缺的能力 —— 这和精讲三里蒋林泉说的「品味通缩，技能通胀」是同一件事，也呼应了今天 Anthropic 收购 Stainless 的另一条新闻：基础设施层的并购正在和创业公司形态变化同步发生。 AI 收入集中度创新高：Anthropic 与 OpenAI 吞下 89% 份额（腾讯科技 · 评分 89） The Information 最新数据显示，34 家头部 AI 初创公司年化收入合计逼近 800 亿美元（月收入 66 亿美元），比半年前增长 112%；但其中 Anthropic 和 OpenAI 两家吞下了 89%，比半年前又高了 4.5 个百分点，剩下的 32 家只能为 11% 的蛋糕奋力拼抢。Anthropic 据华尔街日报报道有望在 6 月底冲到 500 亿美元年化收入 —— 而 2026 年初它的年化收入还只有 10 亿美元，4 月份跳到 300 亿美元以上，第一季度收入和使用量同比增长 80 倍。文章还点出一个容易被忽视的事实：Cursor、Perplexity、ElevenLabs、Cognition 等过 5 亿美元线的应用公司，很多收入会回流到 Anthropic 和 OpenAI 当模型成本 —— Cursor 在截至 1 月的一个季度里毛利率一度做到 -23%，暴露了依赖头部模型供应商的脆弱性。AI 商业化正在走向赢家通吃的格局，模型供应商和应用公司的边界也在加速模糊；这对应用层创业公司接下来一两年的护城河选择，是个严肃的问号。 Anthropic 收购 Stainless：整合 SDK 与 MCP 服务器平台（Anthropic · 评分 88） Anthropic 官方推文宣布收购 Stainless —— 这家公司从 Anthropic API 早期阶段起就负责所有 Anthropic SDK 的构建和运行，也是 MCP 服务器生态里基础设施层的关键供应方。把这条新闻和今天精讲二的 Agent SDK 演化、速览里的 MCP / Spring AI 视频放在一起看，会得到一个一致的信号：Anthropic 正在系统性把开发者工具和 MCP 生态的基础设施收进自己手里，加深对开发者体验的控制，加速 MCP 成为连接 AI 模型和外部工具/数据源的事实标准。叠加上一条 89% 收入集中度的报道，模型层的赢家通吃正在向 SDK 与协议层延伸。 ## 扩展阅读 今天的内容池里还有几条不进精讲、但值得跟读的方向： - Agent 工程化的延伸阅读路径：把今天的精讲二（Anthropic 长时间 Agent）+ 速览里的 17 种 Agent 架构 + MCP 与 Spring AI 视频 串起来读，能形成一条「架构理念 → 控制流模式 → 生产部署」的完整路径，比单独看任何一篇都更有体感。 - AI 编码与组织效能的对照阅读：精讲一（Cursor Composer 2.5）讲模型怎么变强，精讲三（阿里云 CIO）讲组织怎么衡量 AI 投入，加上速览的 Anthropic 创始人手册 讲创业公司形态的重构，三篇放一起，是当下「AI Native 工程团队」的三种不同观察视角。 - 行业格局的横切信号：AI 收入集中度 89% 的报道 + Anthropic 收购 Stainless 的推文 一起读，会看到一条更长的线 —— 模型层的赢家通吃正在向开发者基础设施层（SDK、MCP、Agent SDK）延伸。这关系到接下来一两年应用层创业公司的护城河会建在哪里。 - Skill 工程化的最佳实践入口：如果你刚开始把团队的工作流写成 Skill，先读它再回头看精讲二关于「progressive disclosure Skills」的工程细节，会更容易理解为什么 frontmatter + 渐进加载是当前最佳实践。 ## 今日阅读路径 如果你今天只有 20–30 分钟，按这个顺序读最划算： 1. 精讲三：阿里云 CIO 抛弃 AI 生码率 —— 先把「该不该做」的判断框架定下来。读完最大的收获是不再被「AI 生码率 70%」这种数字迷惑，知道该用 E2E 业务价值去衡量产研效能。 1. 精讲二：Anthropic 长时间 Agent 工程 —— 再看「怎么把强模型变成可交付」。重点看对抗式 generator-evaluator 架构和「结构化交接 vs 上下文压缩」两条结论。 1. 精讲一：Cursor Composer 2.5 训练报告 —— 最后看「底座变强到什么程度」。如果你不写训练栈代码，重点看 textual feedback RL 的思路和 SpaceXAI 合作的战略意涵。 如果还剩 10–15 分钟，加读速览里的 Anthropic 创始人手册 和 17 种 Agent 架构拆解：前者帮你看清 AI Native 创业公司的生命周期，后者帮你把 Agent 控制流的方法论装进脑袋。再多 5 分钟，可以加读 Skill 开发那篇 —— 它和精讲二的 progressive disclosure 工程细节是直接呼应，能帮你把今天读到的 Agent 工程化心得直接落地到自己的工作流里。 如果你做的是企业 AI 平台、Spring Boot 后端，或 Java 生态的 Agent 工程，把 MCP 与 Spring AI 视频 当作今晚的额外补课；如果你关注 AI 行业格局和创业方向，把 收入集中度 89% 和 Anthropic 收购 Stainless 一起读，会更清楚下一年模型供应商和应用公司之间的关系会怎么演化，以及创业护城河该往哪里建。 读完今天的早报，欢迎在评论区分享你最有共鸣的一条。明天见。

译本文聚焦AI编码领域正从追求“写得快”向“做得对”的工程化范式转变。文章通过三条核心线索展开：Cursor发布Composer 2.5并公开训练栈，标志着从产品公司转向模型迭代；Anthropic工程师提出对抗式生成-评估架构，将长时Agent自主运行时间从1小时提升至12小时；阿里云CIO则指出“AI生码率”是危险指标，强调代码是负债，工程化与组织能力才是关键。这共同指向一个结论：AI降低了代码生成成本，但将其转化为资产需要深度工程化。

ginobefun@hongming731 · 5月19日56

#BestBlogs 早报 2026-05-19 欢迎阅读和收听今天的 BestBlogs 早报，推荐阅读 阿里云 CIO 蒋林泉关于 AI Coding 考核的分享，把「AI 生码率」从考核里划掉，提醒所有人「代码是负债」，Vibe Coding 不能直接进生产。

译阿里云CIO蒋林泉分享对AI Coding考核的看法，主张将“AI生码率”从考核指标中移除。他强调“代码是负债”的观点，认为由Vibe Coding等方式直接生成的代码不应直接用于生产环境。这一立场引发了对当前行业考核导向和代码质量管理的思考。

Chubby♨️@kimmonismus · 5月19日71

Huge, did NOT expect that release. Evals looks very solid, significant jump compared to composer 2! But: it’s 10x more efficient than the competition. Looks really exciting. Need to try it out

译没想到这次发布这么重磅。评测结果看起来非常扎实，相比Composer 2有显著提升！ 但重点是：它的效率是竞争对手的10倍。看起来真的很令人兴奋。需要试用一下。

Replit ⠕@Replit · 5月19日30

CEO and co-founder of Replit, @amasad is building the platform that makes coding accessible to billions, from kids creating school projects to enterprises running their business. See him take the stage with Spike Jonze on day one of Vibecon. NYC, June 17–18. Get your tickets at http://vibecon.ai

译Replit的CEO兼联合创始人@amasad正在打造一个让数十亿人能够编程的平台，从创建学校项目的孩子到运营业务的企业。 请于6月17-18日在纽约参加Vibecon大会，观看他与Spike Jonze同台演讲。 购票请访问 http://vibecon.ai

宝玉@dotey · 5月19日50

我几乎不用codex和Claude code的fast mode，速度实际上快得没那么明显，主要是token消耗太快用不起

ClaudeDevs@ClaudeDevs · 5月19日64

Fast mode now defaults to Opus 4.7 in Claude Code. Try it out today with /fast

译Claude Code的快速模式现已默认使用Opus 4.7。 今天就试试 /fast

karminski-牙医@karminski3 · 5月19日53

Qwen3.7! 就在今天! ArenAI (就是之前的 LMArena), 刚刚发布了 Qwen3.7-Max-Preview 在 ArenAI 的内测跑分. 整体排名在第13, 处于目前版本国模SOTA. 本次提升最高的是数学能力, 达到了总榜第7, 编程水平在第10. 另外视觉能力测试也来到了第16. 我直接试了一下 ArenaAI 上面的 Qwen3.7-Max-Preview, 题目是一个使用 three.js 画一个软盘蓝图的场景, 主要考察大模型的前端+空间理解+建模能力. 直接看我两张 Qwen3.6-Plus 和 Qwen3.7-Max-Preview 的生成对比 (注意这个图上的元素完全是代码绘制的, 不是大模型生成的图片). 能看到Qwen3.7 在空间理解和指令遵循上有了很大的提升, 能保持所有元素都在同一轴向上(能完成这一点是巨大的进步, 目前 DeepSeek-V4-Pro 还有这方面的问题). 并且摆放顺序和每个标签的标记也是准确的, 以及背景的网点效果也还原了(这就是指令遵循的提升体现). 当然不足的地方也有很多, 比如这个软盘的一些不规则图形的细节刻画还是差了一些. 但是是瑕不掩瑜的. 稍后正式发布后给大家带来 Qwen3.7-Max 的详细评测! (另外值得注意的是 ArenaAI 给 meta 的新模型 Muse Spark 给到了第5的超高位置. 而目前社区中这个模型一点水花都没有. 我也没API能测这个模型. 所以 ArenaAI 的评分还是仅供参考.) #阿里千问 #qwen37 #qwen37max

译阿里千问今日推出Qwen3.7-Max-Preview，在ArenAI（原LMArena）内测中排名第13，为国内模型最高水平。模型数学能力显著提升，位列总榜第7；编程能力排名第10；视觉能力测试升至第16。作者实测显示，在前端代码生成场景中，Qwen3.7的空间理解与指令遵循能力进步明显，元素轴向一致性优于DeepSeek-V4-Pro等模型。此外，ArenaAI给Meta新模型Muse Spark的异常高评分引发关注，但该评分仅供参考。

AYi@AYi_AInotes · 5月19日62

Cursor 今天发的 Composer 2.5，表面看是常规迭代， 拆开基准图和 blog 之后我整个人都有点懵， 它本质上其实不是一个新模型，更像是把 RL 后训玩到极致的 agentic 怪物， 因为它85% 的算力根本没花在底座上，全都砸在后期魔改上了🤣 同等智能下成本直接砍到对手的十分之一， 最狠的是那张成本-性能曲线， Composer 2.5 在 CursorBench 3.1 上拿到 63.2%，单任务成本几乎贴着 0 美元那条线， Opus 4.7 xhigh 要贵一个数量级才能接近，GPT-5.5 medium 也要 2 美元左右， Terminal-Bench 直接追平 Opus 4.7， 10x 更高效这个感觉不是吹的， 但我觉得这件事真正值得关注的可能不是 benchmark 数字， 而在于他们做对了一件 agentic 里最痛苦的事:就是信用分配， 长 rollout 几千上万 token，global reward 其实根本分不清哪一步错了， 他们的解法叫 textual feedback RL——在出错的 local context 里插极短 hint，让 teacher model 生成正确分布，再用 KL loss 让原模型对齐， 风格、工具调用、解释清晰度，全都能精细调， 这意味着什么， 以前大家迷信谁底座大谁牛， 现在看的是谁敢把 80%+ 算力砸在 RL 和合成数据闭环里， Kimi k2 只占 7.5%，却把 Opus 和 GPT 打到平手， Agentic coding 真正的胜负手不在单次 pass@1， 而在于 40 分钟后它还能不能自己恢复状态继续跑， 在于该努力时努力、该偷懒时不浪费 token 的行为校准， 这些东西现有 benchmark 根本测不到，但开发者每天都能感受到， 我觉得这是 Composer 2.5 最被低估的地方， 以后做 agent 的人，得同时建 anti-hacking 监控了——他们用 25x 合成数据后，模型已经聪明到能逆向工程类型缓存、反编译 bytecode 来钻漏洞，reward hacking 可能也不再是 bug，是需要被管理的 emergent behavior， Cursor 也不再只是 IDE 公司了， 他们和 SpaceXAI 合作，用 Colossus 2 从零训 10x compute 大模型， 垂直整合的时代终于要来了，做编辑器的反向，掌控最上游模型能力， 我觉得真正的差距不在单次 prompt， 而在第 45 分钟它还能不能自己爬起来继续干 hhh

译Cursor发布的Composer 2.5并非全新底座，而是将85%算力集中于强化学习后训练的agentic模型。它在CursorBench 3.1上达63.2%性能，单任务成本极低。其核心突破在于通过“textual feedback RL”解决了长任务中的信用分配难题，实现精细化调优。该模型真正的优势是长时间运行下的稳定性与行为校准，这是现有基准未能体现但开发者能感知的关键能力。这标志着行业评价标准正从迷信底座规模转向衡量RL与合成数据闭环的投入效率。

Emad@EMostaque · 5月19日53

This is such an interesting chart layout, like it a lot! Congrats to @cursor_ai team on the 2.5 launch 🚀

译这个图表布局真有意思，非常喜欢！ 祝贺 @cursor_ai 团队发布 2.5 版本 🚀

OpenAI Developers@OpenAIDevs · 5月19日64

Your Mac can hold down the fort while you work from your phone. Enable remote connection in the Codex desktop app, then turn on “Keep this Mac awake.” When your Mac is powered on and plugged in, Codex can keep running there while you work from the ChatGPT mobile app.

译你的Mac可以在你用手机工作时坚守岗位。 在Codex桌面应用中启用远程连接，然后开启“保持Mac唤醒”。 当Mac开机并接通电源时，Codex可以持续运行，而你则通过ChatGPT移动应用工作。

Tibo@thsottiaux · 5月19日30

So many times I mentally go "I don't have time for that" and then correct myself re-realizing I can just ask Codex to do it. And more often than not, it just does it.

译很多次我脑子里会想“我没时间做那个”，然后纠正自己，重新意识到我其实可以直接让Codex去做。而大多数时候，它真的就完成了。

Replit ⠕@Replit · 5月19日47

This is exactly what we're seeing. The "AI for everything" era is really the "software for everyone" era. Every SMB becomes a software company.

译这正是我们所看到的。“AI赋能一切”的时代，本质上是“软件普及每个人”的时代。每家小企业都将变成软件公司。

ClaudeDevs@ClaudeDevs · 5月19日70

Prompt cache diagnostics are now in Claude Console. When a request misses the cache, you can now see exactly which part of your prompt changed and how many tokens it cost you.

译提示缓存诊断现已在Claude控制台上线。 当请求未命中缓存时，您现在可以准确查看提示的哪一部分发生了变化，以及这消耗了多少令牌。

Rohan Paul@rohanpaul_ai · 5月19日60

Top AI labs are suddenly abandoning fringe consumer features (like video models &amp; conversational personas) to mirror Anthropic's success with coding agents. "They're all like, “We're only going to do coding agents too.” ~ Marc Benioff, CEO of Salesforce

译顶级AI实验室突然放弃边缘消费功能（如视频模型和对话角色），转而效仿Anthropic在编程智能体领域的成功。 “他们都表示，‘我们也要只做编程智能体了。’” ——Salesforce CEO Marc Benioff

Greg Brockman@gdb · 5月19日69

how to use /goal in codex — keep Codex working on a persistent objective until it's solved:

译如何在 Codex 中使用 /goal —— 让 Codex 持续执行一个明确目标直至解决： [引用 @derrickcchoi]：我的同事撰写了一篇关于在 Codex 中使用 Goals 的精彩文章。 他们介绍了何时使用 Goals、激活 Goals 时会发生什么变化，以及如何编写能为 Codex 提供明确结果、约束和验证标准的 Goals。 如果你感兴趣，文章还介绍了我们在架构层面如何设计 Goals。 https://developers.openai.com/cookbook/examples/codex/using_goals_in_codex

Thariq@trq212 · 5月19日67

continuing my HTML era, I had so much fun talking with Claire at Code w/ Claude about staying in the loop with long running agents

译在Code with Claude活动中，演讲者Thariq提出“HTML是新的Markdown”这一观点。他指出，虽然Markdown编写简单且易被AI解析，但对人类可读性较差；而HTML能更有效地作为人类与AI代理之间的交互界面。其应用场景包括：使用HTML工件作为动态交互式规格说明、快速构建临时微用户界面、维护一个活的设计系统，以及在与Claude等模型交互时使用开放式提示（如“whatever is needed”）以赋予其更多自主思考空间。该观点强调了软件开发中前端呈现与后端智能结合的重要性，并探讨了工程师与产品经理角色融合后的演变方向。

宝玉@dotey · 5月19日83

Cursor 发布 Composer 2.5 Cursor 今天上线自家编程模型 Composer 2.5。主打长任务上更顶得住、复杂指令跟得更稳，官方称效率最多能比同等水平的模型高出十倍。为了推这个新模型，Cursor 把它未来一周的默认额度直接翻倍。 训练上的一个小亮点是用文本反馈做信用分配，让模型在十万 token 量级的长轨迹里也能学得动。就是让模型扛得住连续几十上百步的编程任务，中途不容易忘了自己在干什么。 底座还是 Kimi Composer 2.5 仍然基于 Moonshot 的 Kimi K2.5 二次训练，跟上一代一致。两个月前 Composer 2 发布时 Cursor 没披露底座来源，被开发者从 API 请求头里挖出 kimi-k2p5-rl 的模型 ID 闹了一场，这次直接写进了博客，算是把透明度补回来。 发布同时，Cursor 宣布跟 SpaceXAI 联合从零训练一个更大的模型，总算力是这次的十倍，跑在 Colossus 2 那套百万张 H100 等效的超算集群上。 背景是 SpaceX 4 月跟 Cursor 签了战略合作，并拿到了今年晚些时候以 600 亿美元收购 Cursor 的选择权；xAI 此前已并入 SpaceX。Cursor 的算力命脉，事实上已经接到了马斯克这边。

译Cursor 发布了迄今最强的编程模型 Composer 2.5。该模型在长任务处理和复杂指令跟随方面更加稳定高效，官方称其效率最高可提升十倍。其技术亮点在于采用文本反馈方法，解决了超长轨迹（十万 token 级）下的学习难题，使模型能可靠执行连续数十甚至上百步的复杂编程任务。模型底座仍基于 Moonshot 的 Kimi K2.5 进行二次训练。同时，Cursor 宣布与 SpaceXAI 联合启动更大规模模型训练，将依托 Colossus 2 超算集群，这也意味着其算力基础已与马斯克旗下资源深度绑定。

宝玉@dotey · 5月19日61

我最近 Vibe Coding 的一些感受：就是心态回不去了，以前可以接受几个月才做一个产品出来，现在忍受不了这种速度，就会依赖 Agent 去写代码，但是对快速生成的质量很难满意，就需要花时间去细心打磨，但又难接受打磨的速度，就很拧巴。 有点像打游戏，用作弊码了开始很爽，玩一会就索然无味了。

译作者分享了采用AI辅助的“Vibe Coding”开发模式后的矛盾心态：虽极大提升了开发速度，但生成代码质量不佳需手动修复，却又难以接受修复的相对“慢速”，陷入拧巴状态。这被类比为游戏作弊码的体验，并指向AI在解放重复劳动的同时，可能使创造性工作本身变得“无聊”的深层议题。

🚨 AI News | TestingCatalog@testingcatalog · 5月19日70

CURSOR 🔥: A newly released Composer 2.5 performs on par with Opus 4.7 and comes with up to 10x better cost efficiency. > It's more intelligent, better at sustained work on long-running tasks, and more reliable at following complex instructions. Usage limits will be doubled for Composer 2.5 over the next week.

译Cursor发布了其迄今最强大的模型Composer 2.5。官方强调，该模型在性能上可与Opus 4.7比肩，并实现了高达10倍的成本效率提升。Composer 2.5在智能性、处理长时任务的持续工作能力以及遵循复杂指令的可靠性方面均有显著改进。作为发布福利，该模型在未来一周内的使用额度将加倍。

凡人小北@frxiaobei · 5月19日71

Anthropic 这篇关于 Claude Code 在大型代码库的最佳实践，几个能直接抄作业的点： · CLAUDE. md 要分层。根目录那份只放整体架构和关键的坑，每个子目录再放各自的局部约定，Claude 进哪个目录就加载哪一份。 · 让 Claude 从子目录启动，不要从仓库根启动。它会自动往上回溯加载所有说明文件，反而上下文更准。 · 测试和 lint 命令按子目录切分。别让它改了支付服务就把整个仓库的测试全跑一遍，又慢又把上下文塞满无关报错。 · 装 LSP（语言服务器协议，比如 Python 有 pyright，TypeScript 有 tsser）。Claude 默认是 grep 字符串找代码，同名函数一搜几千个。LSP 能让它按符号本身定位，一步直达定义。具体接法是装一个 code intelligence 插件 + 对应语言的 language server 二进制文件，Claude Code 文档里有现成的。 · 每 3-6 个月审一次配置，新模型发布后再审一次。当初为旧模型写的规则，可能会反过来束缚新模型。 以及一个组织层面的提醒：哪怕不专门成立 AI 工具团队，至少要指定一个人负责管 Claude Code 的配置、权限、插件、CLAUDE. md 规范，不然大家各搞各的，好经验传不出来。

译Anthropic 分享了在大型代码库中使用 Claude Code 的关键实践。核心建议包括：将 CLAUDE.md 配置分层，根目录放全局架构，子目录放局部约定；从子目录启动以精准加载上下文；测试和 lint 命令按子目录隔离运行；安装 LSP 以实现基于符号的精准代码定位；定期审查配置。组织层面需指定专人统一管理配置与规范，以促进最佳实践共享。

Thariq@trq212 · 5月19日73

a prompt I've been using a lot recently: implement &lt;SPEC&gt; and while you do, keep a running implementation-notes.html file (or markdown) with decisions you had to make weren't in the spec, things you had to change, tradeoffs you had to make or anything else I should know

译我最近常用的一个提示词： 实现<SPEC>，同时维护一个持续更新的implementation-notes.html文件（或markdown），记录规范中未提及的决策、需要修改的内容、必须做出的权衡，以及其他我需要了解的事项。

ClaudeDevs@ClaudeDevs · 5月19日73

What are best practices for running Claude Code at scale? New blog post on what we've learned from teams running it across multi-million-line monorepos, decades-old legacy systems, and distributed microservices: https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

译在大规模运行Claude Code有哪些最佳实践？ 关于我们从团队在数百万行单体仓库、数十年历史的遗留系统和分布式微服务中运行的经验总结，新博客文章已发布： https://claude.com/blog/how-claude-code-works-in-large-codebases-best-practices-and-where-to-start

François Chollet@fchollet · 5月19日66

A mental model for working with coding agents is that they're blind squirrels running into a maze and bumping into walls. You must place the walls (verifiable constraints) strategically so that they end up in the general region you want them in.

译与编程智能体协作的心智模型是：它们就像在迷宫中奔跑、不断撞墙的盲眼松鼠。你必须策略性地设置墙壁（可验证的约束），让它们最终大致到达你期望的区域。

Berryxia.AI@berryxia · 5月18日64

尼玛，本来就焦虑的不行。 这货直接给你说：未来软件免费，你的工作就是会被替代！” 这你受得了吗？ Anthropic CEO亲口放话了： “软件很快就要变得便宜，甚至几乎免费。” 他直接把最残酷的真相扔了出来： 你不需要会写代码的联合创始人。 你不需要5万美元做MVP。 你不需要6个月开发周期。 你只需要Claude，一个周末就够了。 虽然是特么在推荐自己家的产品，但是我们不用起来，真的是亏是自己啊！ 大多数人看完只会担心自己的工作。 少数人这个周末就会打开Claude，开始vibe coding自己的第一个产品。 以前创业的门槛是钱、是团队、是时间。 现在门槛只剩下一个：你敢不敢周末动手。 软件免费的时代，真正值钱的不是代码，而是你敢不敢第一个去用。

译Anthropic CEO表示，软件将很快变得极其便宜甚至免费。这意味着创业的传统门槛——需要编程技术的联合创始人、至少5万美元的启动资金、长达数月的开发周期——正在消失。现在，仅需使用Claude等AI工具，一个周末就可能构建出产品原型。这一变化引发了人们对职业被AI替代的广泛焦虑，但也为少数行动者创造了机会：真正的价值将不再是编写代码本身，而是敢于率先利用这一变革的人。

AYi@AYi_AInotes · 5月18日71

http://x.com/i/article/2053129966217277440 # 我终于想明白了：你 90% 用 Markdown 写的东西，本来就该是 HTML（2026 实战指南・附全套提示词） 上篇写 Markdown vs HTML 那条爆了之后,后台收到最多的一个问题是: 那到底哪些活该用 HTML,哪些活该用 Markdown? https://x.com/AYi_AInotes/status/2052842474687680678 说实话当时那篇没回答这个问题。 我只讲了"HTML 是 AI 时代的沟通语言",但没讲清楚边界在哪。 后来这半个月,我一直在用各种活试,把"什么时候该用什么格式" 这件事拆得越来越清楚。 今天把决策框架放出来,顺便用 @AntLingAGI 开源的 Ring-2.6-1T 跑了三个最实用的 HTML 工具——铁汁们打开浏览器就能用的那种。 ## 一句话决策标准 判断一个 AI 产出该用 HTML 还是 Markdown,看一个信号就够了: > 这个东西生成完之后,是被读,还是被用。 被读 → Markdown。 被用 → HTML。 听起来简单,但 80% 的活其实卡在中间——你以为是被读的, 其实是被用的。比如项目计划,大多数人交付时写成 Markdown 文档, 对面看了三天就忘了。但同样的信息做成可点击的项目页, 对面会反复回来看。 ## 四组判断信号 用 HTML 的 4 个信号 - 需要交互——点击、拖拽、滑块、输入。任何带"用户操作"的东西 - 需要可视化——流程图、时间线、对比表、图表、SVG - 一次性产出且不需要二次编辑——demo、原型、临时工具 - 要发给别人看——发个链接打开即用,不用下载任何东西 用 Markdown 的 4 个信号 - 需要后续手动编辑——文档、笔记、技术博客 - 纯线性阅读——公众号长文、Twitter Thread - 需要版本控制——Git diff 友好、code review 友好 - 长期沉淀——Notion、Obsidian、wiki 这种 四组里命中两组以上,就按这一边走。 有意思的是,真正容易被读者忽视的判断,是"需要交互"。 这个维度一旦命中,Markdown 几乎一定输。 ## 三个 Ring 实测 HTML 工具 理论讲完了,接下来是实测。 我用 Ring xhigh 跑了三个 HTML 工具,都是单 HTML 文件, 打开浏览器就能用,不依赖任何库。**三个工具加起来跑通花了 不到 10 分钟,产物质量都是 9/10。 ## 场景一:交互式项目计划页 输入项目名 + 周期 + 里程碑 + 风险表。 我拿一个企业内部"2026 年度组织盘点"做了样本—— Ring xhigh 大约 2分多钟出第一版,暗色主题 + 横向时间线 + 可折叠风险表 + 团队头像墙 + 整体进度条一次到位。 跑出来的页面不接 polish skill 就能直接发给 leader 看 以前同样的活,我用 Notion 拼模板大约 30-40 分钟, 节省了 20 倍时间。 ## 交互式项目计划页(组件多 / 视觉强)提示词： ## 场景二:Prompt 调参器 输入 prompt 用途 + 需要调的参数。 Ring 产出:三栏布局——左边滑块 + Switch 参数面板, 中间 prompt 编辑器(支持 {{ }} 占位符高亮), 右边实时预览合成 prompt + 一键复制按钮 + token 估算 + Claude Opus 费用估算。 HTML:prompt调参器 这个工具我自己天天用,Ring 给的版本比我手写的稳得多—— 关键是"token 估算 + 费用估算"这种细节,自己写经常忘。 也是2分多钟出第一版,直接能用。 ## Prompt 调参器(交互密 / 单页应用) ## 场景三:可交互流程图 输入流程主题 + 节点清单 + 节点关系。 Ring 产出:纯 SVG 流程图,支持拖动平移、滚轮缩放、点击节点 展开详情、双击高亮关联连线。坐标系判断完全正确—— prompt 里那句"Y 轴向下为正"显式约束起了关键作用。 CTO 线组织盘点流程图 - 11 节点可交互 跑了 1分多分钟出第一版,11 个节点的复杂流程图布局工整、 连线无交叉。这比我用 Mermaid 折腾半天的体验好太多。 > prompt：可交互流程图(SVG 坐标系敏感) ## Ring 跑 HTML 的三个坑 但 Ring 跑 HTML 也有几个坑要说清楚,我都踩过。 坑一:首次输出可能不完整。 三个场景里,项目计划页的第一次跑出来缺了几个组件—— 不是错误,是模型停在中间。补一句"请补全所有组件, 确认所有模块都生成完整"再让它重跑,第二次就稳了。 这个坑要预防的话,prompt 里加一句 "完成后逐项确认每个模块都已渲染"。 坑二:SVG 坐标系翻转。 SVG 的 Y 轴向下为正这件事,Ring 偶尔会按数学坐标系处理, 导致整个图翻转。预防做法是在 prompt 里显式写 "Y 轴向下为正,节点垂直间距 120px,X 轴向右为正"。 有这一句,出错率明显降下来。 坑三:仿站做不了。 Ring 当前没有多模态,做不了"看截图复刻"。 如果你想还原一个看到的页面,流程是先用 Claude / GPT 读截图、 输出布局描述,再把描述喂给 Ring 写代码。 ## 一个升级版判断 咱们回到核心， 上篇推文里我写过一句:Markdown 是给人写给人看的, HTML 是给 AI 写给人用的。 最近一周我实测跑下来,还想再补一句: > 选错格式的本质,是没想清楚交付物到底要被读还是被用。 倒不是说 HTML 比 Markdown 更先进,主要是 AI 时代的产出越来越多被"用", 而不是被"读"。讲真，这一类活,Markdown 天然就吃亏。 Ring xhigh 在 HTML 工具这种场景上,跑下来比我预期稳—— 尤其是单文件不依赖外部库这种约束,它接得住。 OpenRouter可以直接使用，适合在自己手头的 HTML 工具项目 里跑一遍: 🔗 https://huggingface.co/inclusionAI/Ring-2.6-1T 完整 prompt 模板(三个场景全套) + 调用示例 + 避坑指南 已经整理成飞书文档,需要的评论区留言我私信发。

译本文核心观点是判断AI产出格式的关键在于该产物是用于“阅读”还是“使用”。被阅读的文档、笔记适合Markdown；需要交互、可视化、一次性交付或直接分享的工具型产物则应选择HTML。文章提出了四组具体判断信号，如需要交互和可视化即指向HTML。作者使用Ring-2.6-1T模型实测了三个HTML工具，包括交互式项目计划页、Prompt调参器和可交互流程图，均能在几分钟内生成高质量、单文件且不依赖外部库的成品，效率大幅提升。同时，文章也指出了使用Ring生成HTML时可能遇到的输出不完整、SVG坐标系错误等常见问题及应对方法。

meng shao@shao__meng · 5月18日74

TRAE 团队分析了用户实际使用的 Agent Skills Top 10 这 10 个 Skills 覆盖了从 UI 设计到调试的产品开发全链路，还有一个 PUA Skills 😄，咱们分类看看： 流程治理类（强制工作流） 1. brainstorming —— 设计先行 强制在写代码前完成结构化需求对话，未批准方案禁止编码。核心是消灭"这事太简单不用设计"的惯性偷懒。 5. writing-plans —— 计划落地 把头脑风暴的产物拆成 2–5 分钟粒度的可执行任务，每步附带完成标准、风险预案和代码示例。是 brainstorming 的下游配套。 7. using-superpowers —— 调度中枢 元技能。强制 Agent 在每次响应前先检索并加载相关 skill，并明确优先级：用户指令 > 技能指令 > 系统默认。 8. karpathy-guidelines —— 行为护栏 源自 Karpathy 对 LLM 编码缺陷的观察，约束三类常见病：过度假设、过度工程、留下烂摊子。原则是 think first / stay simple / edit surgically。 设计与前端类 2. frontend-design 针对"AI 生成页面千篇一律"的问题，强制选择明确的设计语言（极简 / 复古 / 野兽派等），关注排版、配色、动效的真实质感。 3. ui-ux-pro-max 全平台设计系统生成器：50+ 风格、97 套配色、57 套字体组合，附带无障碍规范。属于 frontend-design 的"重型武器"版。 调试与验证类 4. systematic-debugging 四阶段方法论：禁止猜测式修复，要求根因追踪、纵深防御、基于条件的等待，必须完成完整诊断后才允许动手。 9. webapp-testing 基于 Playwright 的本地测试套件，强调"先侦察后行动"——截图、抓控制台日志、管理多服务生命周期。 10. agent-browser 更通用的浏览器自动化 CLI：导航、填表、点击、截图、数据抽取，把浏览器变成 Agent 的标准 I/O 通道。 生态扩展类 6. find-skills 对接开放的 skills. sh 生态，支持模糊搜索和从任意 Git 仓库安装，并按 Agent 作用域隔离。 额外发现：PUA /pua —— 高压问责 四级升级机制 + 七项检查清单，禁止 Agent 用"差不多了"或被动等待来收尾，强制承担完整责任。命名带反讽意味。 整体设计逻辑分层 1. 元层 using-superpowers, find-skills 2. 行为层 karpathy-guidelines, /pua 3. 流程层 brainstorming → writing-plans 4. 执行层 frontend-design, ui-ux-pro-max 5. 验证层 systematic-debugging, webapp-testing, agent-browser 形成的闭环是：想清楚 → 拆细 → 做精 → 验透 → 担责。

译TRAE团队基于真实的用户技能调用数据（而非安装量），分析了用户实际高频使用的Agent Skills Top 10。这些技能覆盖了从UI设计、流程规划到测试调试的产品开发全链路，甚至包含一个带有反讽意味的“PUA”高压问责技能。其设计具有清晰的分层逻辑，从元层的技能检索与调度，到行为层的约束护栏，再到具体的执行与验证层，共同构成了一个“想清楚→拆细→做精→验透→担责”的结构化、负责任的闭环工作流。

🚨 AI News | TestingCatalog@testingcatalog · 5月18日61

GOOGLE 🔥: Gemini desktop app will get Gemini Live, Gemini Spark, Gemini Omni, and a new "Stream to Cursor" feature. What we know so far 👀 - "Stream to Cursor" feature will allow Gemini to have something similar to "Magic Pointer" announced last week during Android Show. - Gemini Spark Agent will be able to operate local files from attached folders. - Gimini Omni is referred to as "Veo4 Omni" internally. - Skills will be supported too. - Gemini Live feature is WIP and not functional yet. A short demo from testers ⚡

译谷歌Gemini桌面应用即将迎来重大功能更新。新增的“Stream to Cursor”功能类似上周Android Show上展示的“Magic Pointer”。Gemini Spark智能代理将能直接操作本地文件夹中的文件。此外，应用将引入被内部称为“Veo4 Omni”的新模型，并支持Skills技能体系。不过，Gemini Live实时功能目前仍在开发中，尚未可用。

Claude@claudeai · 5月18日44

Next stop: London. Register to tune in tomorrow for deep dives, demos, and conversations with the teams behind Claude: https://claude.com/code-with-claude/london

译下一站：伦敦。 注册收听明日深度解析、演示及与Claude团队的对话：https://claude.com/code-with-claude/london

向阳乔木@vista8 · 5月18日68

Anthropic CFO最近接受了访谈，虽然有一个多小时，但信息增量不大，简单列几条，大家不用看视频了。 1. 今年第一季度，Anthropic 的年化营收从 90 亿美元涨到了 300 亿美元出头。 2. Anthropic 的算力同时服务三件事：训练新模型、加速内部研发、服务外部客户。 同一块芯片，早上跑推理，下午做强化学习，晚上切回训练。 3. CFO 会把 30% 到 40% 的时间花在算力相关的决策上。 4. 人类天生是线性思维，思维定势打破很难打破，不做估算做，做情景规划。(还是在讲采购算力的想象力问题) 5. 更好的模型让内部研发更快，更快的研发产出更好的模型，同时对外服务的成本也在下降。 所以Anthropic会留不少算力给内部研发提效用。 6. Anthropic 内部超过 90% 的代码由 Claude Code 完成。财务团队有70个skill的技能库，准确率90% 到 95% 7. Anthropic 在可解释性研究和对齐研究上的投入，额外带来的收货，对模型工作理解更好，大客户更信任。 AI总结文章：https://blog.qiaomu.ai/anthropic-cfo-on-compute-as-mission-critical https://www.youtube.com/watch?v=wEEZPpx8qow

译Anthropic CFO在访谈中透露，公司今年一季度年化营收从90亿美元猛增至300亿美元以上。算力被高效复用以同步支持模型训练、内部研发和客户服务，CFO近半时间投入算力决策，强调需超越线性思维进行情景规划。内部研发形成“更好模型驱动更快研发，进而产出更优模型”的飞轮效应，同时降低对外服务成本。公司超90%代码由Claude Code完成，显著提升效率；在可解释性与对齐研究上的投入，则增强了客户信任，形成差异化优势。

宝玉@dotey · 5月18日59

http://x.com/i/article/2056234281895088128 # 为什么我不“凭感觉编程” 作者：Jacob Harris 标题：Why I Don’t Vibe Code（https://jacobharr.is/personal/i-dont-vibe-code） 最近网上关于“凭感觉编程”（Vibe Coding）以及大语言模型（LLM）将如何颠覆软件开发的讨论铺天盖地。据说，每一个新模型的发布都会把我们带入纯粹生产力的天堂，让我们能以光速发布软件，彻底消除产品开发中的所有摩擦和内耗。 或许吧，我姑且信之。但我自己，是不“凭感觉编程”的。 如果你觉得这套好用，那太棒了！我写这篇文章并不是为了探讨 LLM 的优劣，只是这玩意儿对我个人来说，从来没对过胃口。这篇文章，算是我简单盘点一下其中的种种原因。 我是个守财奴 我不是个原教旨主义者。我试过用集成在 IDE 里的 LLM。对于那些描述起来很简单、但自己动手又嫌烦的任务，它们确实挺好用的，比如把网格里的一堆方形图片缩小。我本可以去查查图像处理软件 ImageMagick 的命令行参数，但这种事交给 AI 去干再合适不过了。接着，我又试着用某个 AI 工具分析了我项目里的一段代码，还做了几件小事，然后一切戛然而止。系统通知我：额度用光了。如果想继续，请绑定信用卡购买更多 Token。 你得知道，我祖上两边都是出了名的铁公鸡。几个世纪以来，无论是在大西洋的这头还是那头，我们家族一直精打细算、锱铢必较。举个极端的例子：我的一位远房祖先在 17 世纪的菲利普国王之战中丧生，原因竟然是他在撤离房子时落下了点奶酪，非要跑出安全的堡垒去捡。 所以你一定要相信我：当我发现为了让自己能“思考”，居然还要无休止地给一个服务交钱时，我浑身不自在，以至于连信用卡的影子都不想给他们看。我合上笔记本电脑，卸载了那个 IDE，甚至乖乖用回了极其硬核的纯文本编辑器 Emacs。然后我发现，我压根儿就没觉得少了 AI 有什么不习惯的。 我年纪大了 年纪大确实有点帮助。我写代码已经很多年了，尤其是在这个把只有 5 年经验的开发者就称为“高级工程师”的行业里。有时候，经验是缓解焦虑的一剂良药（前提是，你焦虑的不是在这个 5 年就能称“高级”的行业里遇到的年龄歧视）。这波 AI 热潮确实让我想起了早年那些“低代码”或“无代码”工具所吹嘘的重大突破。我不怀疑 AI 可以成为开发者手中的利器，我知道在很多任务上它能提供更好的工具支持。但这些争论，总是让我回想起关于“偶然复杂性”（accidental complexity）和“本质复杂性”（essential complexity）的经典理论。 即使在我还是个年轻码农的时候，弗雷德·布鲁克斯（Fred Brooks）也算得上是老前辈了。作为 IBM System 360 系列大型机（及配套操作系统）的项目经理，他曾在第一线亲眼目睹了如今软件项目中那些司空见惯的烂摊子。他将这些观察整理成了《人月神话》一书，至今仍应是软件工程课程的必读经典。我手头的那本是后来重印的新版，里面收录了他后期的一篇著名文章《没有银弹》。在这篇文章中，布鲁克斯探讨了新工具对开发者生产力的实际影响。要想像程序员一样思考，你必须明白现实世界是极其复杂的。编程最好被理解为：在混乱的现实之上强加一种简化的模型，我们称之为“抽象”（abstractions），通过降低复杂性来让世界变得可理解。 这让我们能够将特定的情况泛化成一个个可以层层叠加的结构。例如，“把花生酱抹到面包上”这个具体动作，可以泛化成一个 spread(substance)（涂抹物质）的方法，这个方法既可以接受“花生酱”作为参数，也可以接受“奶油奶酪”。接着，我们可以用这些基础方法构建出更高级的函数，比如 create_pbj()（制作花生酱果冻三明治）等等。在现代高级编程语言中写代码，就像是站在一座由抽象概念堆砌而成的金字塔顶端：只需一行代码，就能在多个系统上触发数以百万计的底层操作。 那么，如果我们继续往下走，把“编程”这个行为本身也抽象掉呢？这就是 AI 智能体的终极梦想：成群结队的智能体接受任务，然后在无人监督的情况下自动实现它们。听起来棒极了！但这解决的仅仅是布鲁克斯所说的偶然复杂性，也就是编写代码本身那些繁琐、笨重的地方。自从那篇文章发表以来，软件开发在应对偶然复杂性方面已经取得了巨大的进步。我们不用再写底层的机器码，而是使用现代的动态解释型语言；我不需要再从头记住如何手写一个快速排序，只需调用标准库里的排序方法即可；我也不用再从零开始搭建整个 Web 应用，而是直接使用现成的框架。如果我想重命名或者重构某段代码，我的编辑器可以代劳。 AI 似乎只是这一进程的最新迭代，一些编辑器已经用不可预测的 AI 智能体，取代了过去那些可预测的老式重命名和重构工具。诚然，这听起来像是在掷骰子碰运气，但在实际开发中，那种灾难性的大翻车又能有多常见呢？ 然而，即便更好的工具削弱了偶然复杂性，本质复杂性还在那儿。设计出正确、优雅、清晰且易于维护的抽象架构和系统，依然是一项无比艰巨的工作，这种复杂性哪儿也去不了。这项工作需要技能、经验，以及从过去系统崩溃的血泪史中艰难汲取的智慧。LLM 那种花哨的“高级自动补全”，面对这种很难直接找到标准答案的复杂性，到底能发挥多大作用？也许通过精心设计提示词，你可以引导它走向你心仪的方案，但到了那个地步，负责引导的人还不如自己干脆把方案设计出来算了，因为 LLM 根本无法向你解释它为什么选择了某条特定的路径。本质复杂性往往是怪异、罕见且混乱的。也许我错了，也许模型在处理这些混乱情况方面正变得越来越好，但我发现这通常需要一种非常特定的人类思维模式和方法。幸运的是，我超爱这种乱糟糟的东西。 我爱死这些混乱了 前面我一直在谈论软件如何抽象流程，但其实我们也利用抽象的“简化”特性，作为理解世界的一种工具。在经典名著《国家的视角》中，詹姆斯·斯科特（James Scott）描述了后启蒙时代的一个核心动机：通过抽象和分类，让人口和财产变得清晰可辨。能量化的东西，就能被改造。例如，一个国家在看待其森林时，可能不再将其视为复杂的生态系统，而是仅仅通过“能用于造船的木材比例”来评估。这种视角随之促使国家采取行动，比如用单一树种的林场取代原生森林。于是，一片森林被抽象成了一个“种植船桅的系统”。 这种方法催生了官僚机构和纸质表格，进而演变成了今天的网页表单和数据库。作为程序员，为了对世界采取行动，我们必须减少现实数据中的混乱。我们期望日期必须是精确的，期望人的名字相对简单规范，期望数据在输入时是完整的且随着时间推移保持一致。每一个程序员和每一次系统设计，都在做出一种削足适履的强制妥协：我们决定系统应该反映现实的哪些方面，又该丢弃哪些方面。我这么说并非为了批评，因为要想构建出不被无数特殊情况（我们称之为“边缘用例”，因为它们本应是处于边缘的罕见情况）所拖垮的系统，这是唯一的方法。 但是，这个过程如此根深蒂固，以至于我们有时会忘记它同时也是一种人为的造作，尤其是在用它来描述人的时候。强制性别字段只接受“男”或“女”，并不能迫使性别的本质变得非黑即白；我们对种族的定义是一种不断变化的社会建构。我们简化的模型可能会给我们提供洞见（过去 20 年自闭症诊断率猛增了 300%！），但却无法捕捉到这些洞见背后的潜在因素（这很可能只是因为我们对自闭症定义的改变以及筛查力度的加大）。退一步去审视任何模型是如何构建的，以及它遗漏了哪种类型的知识，这非常重要。每一次抽象，同样也是一次遮蔽。 作为一名前数据记者，我学会了如何“审问”数据，并且严谨地防范我得出的答案可能会在哪些方面产生误导。如果你想避免发布令人尴尬的更正声明，“迫害妄想症”绝对是数据记者最好的朋友。你不仅要能思考数据说了什么，还要能思考它没有包含什么。 不幸的是，这种试图跳出来审视系统本身的元认知，是 LLM 永远无法做到的。对它们来说，模型本身就是现实。正如 Robin Sloan 在其引人入胜的文章《语言模型是在地狱里吗？》中精辟指出的那样：AI 模型的构建基础和它们看待世界的方式，都被极度剥离了细节。当你我看着一段文字时，我们能看到它的上下文（比如文本格式、标题、作者简介、提供链接的网站等），而 LLM 仅仅在一个纯粹由字母构成的世界里运转（严格来说，它们接收的是子词标记，这就是为什么早期的模型数不清单词 'strawberry' 里有几个字母 'r'）。要求 LLM 去认识到它所看到的现实是有局限性的，就像是问金鱼水温怎么样一样，对牛弹琴。 写到这一节时，我满脑子都是 DOGE（政府效率部）在社会保障局（SSA）试图揪出欺诈行为时的那些拙劣表演。举个例子，DOGE 审查了 SSA 的数据库，发现里面有超过 900 万条记录的出生日期在 120 多年前，却没有记录死亡日期。马斯克断言，唯一的解释就是数以百万计的人在欺诈性地领取福利。但他对问题的起因和严重程度都判断错了。DOGE 本可以质疑数据质量，本可以去查查实际是否有钱打进了这些账户，甚至本可以随便找个 SSA 的专家给他们解释一下。但他们没有，他们直接照单全收了字面数据，并草率地得出了错误的结论。 这个套路他们玩了一遍又一遍。在另一个关于付款的欺诈指控中： > 据查阅相关文件及知情人士向《纽约时报》透露，在随后的广泛分析中，政府机构专家仔细记录了 DOGE 工作中的逻辑谬误。 代理副局长肖恩·布伦在一份审查其中一个问题的备忘录中写道：“这些付款是合法有效的。”（财政部发言人拒绝置评。） 但据熟悉鲁索先生言论的人士称（鲁索未回应置评请求），他表示 DOGE 不会信任这些职业公务员。相反，他坚持让阿卡什·博巴，一名 21 岁、曾在帕兰提尔实习并成为 DOGE 核心程序员的年轻人，来进行他自己的分析。 以他们自己狂野的方式，DOGE 团队正在重演导致 LLM 走偏的同款逻辑。他们拒绝考虑任何在数据字面意思之外的替代解释，拒绝与自己圈子之外的任何人交流，死死咬住一个极其简化的解释，仅仅因为这太合他们胃口了：这完美印证了他们“政府员工全都是蠢货、欺诈行为无处不在”的世界观。 我本人因为极其害怕让自己看起来像个白痴，绝不希望把数据分析工作外包给 LLM。但有大把的人愿意这么干。我担心这个问题只会越来越糟。 摩擦是上天的恩赐 大语言模型驱动开发的魅力在于，它标榜能消除一切摩擦。吹鼓手们编织出美好的神话：开发团队一天就能发布几十个新功能，在越来越奇葩的网络拓扑结构下，指挥着好几个 AI 智能体团队自主运转。我懂，软件开发有时候确实枯燥又让人抓狂。能够以不可思议的速度疯狂产出代码，把玩着打磨精美的产品而不是半成品原型，那种感觉一定超级刺激。 但我需要这种摩擦。 刚开始学习一门新语言或新框架时，我连做最基础的事情都要和摩擦搏斗，这感觉糟透了。而当我在处理一个陌生的代码库或数据源时，我需要预留出几个小时的时间去仔细审视它。我经常会做一些逐字逐句的深度死磕，打开特定的文件，一行一行地看，直到我完全理解它们的上下文，以及开发者做出这些选择的原因。我知道，我大可以叫 LLM 帮我总结一下整个项目，省下这大把时间，但我真的需要这个在代码里“泡着入味”的过程。我需要的不仅是知道开发者做了什么选择，我还需要知道他们为什么这么选，以及这些选择是如何反映出这门语言的局限性或编程习惯的。我在失败中学习，如果 LLM 把这部分苦差事替我干了，我将永远无法真正理解我到底在做什么。 即使是在熟悉的语言环境里写我自己的代码，我依然严重依赖摩擦作为重要的线索。当写代码变得非常困难时，这说明在当前的架构下我正走向一条歧路。它在提醒我，应该认真考虑重新设计，以便未来的扩展能更顺畅。 遇到这种情况，我通常会出去散个长步（或者直接打卡下班），给大脑留点空间，退一步换个角度思考问题。这招真的管用。我发现这种停顿极其有效，以至于即便思路清晰，我也会强迫自己停下来。在开发大型软件项目时，在开始为一个新功能写代码之前，我会先强制自己写一份架构决策记录（Architectural Decision Record，ADR），描述我想做什么。这些文档逼着我记录下这一刻我的想法、我对问题的假设，以及我这套方案可能带来的后果。有时候，写着写着我就意识到，我对自己最初的直觉太盲目自信了，以至于都没发现它会把项目带进沟里；同时，对于未来接手我工作的继任者来说，这也永远是记录“当年那帮家伙到底在想什么？”的绝佳途径。 而 LLM 驱动开发对待摩擦的态度，就是不管三七二十一，闭着眼睛直接写过去。LLM 会极其配合。它大概率能写出能跑通的代码，性能指标可能不错，测试也能通过（尤其是如果测试也是 LLM 写的话）。但它根本不知道自己为什么选择了那条路，它感受不到摩擦，也无法向你解释一种架构方案是否感觉比另一种更清晰优雅。如果负责写提示词的工程师本身缺乏洞察力，不知道好坏方案的差别，他们就会陷入一种死循环：一遍又一遍地让 AI 强行穿越重重摩擦写代码。最终生成一堆奇形怪状的抽象逻辑，而留给未来团队的唯一设计文档，就是几年前一个用来指示 AI 模型的 Markdown 孤本文件。祝你从那玩意儿里重构出当年的架构决策好运吧！ 不难看出，我所见到的大多数凭感觉编程的成功案例，要么是开发者本身已经是该领域的专家（因此能够驾驭 AI 的工作），要么是那些哪怕搞砸了也无伤大雅的小项目。至于其他情况，我们只能想办法自己判断那著名的“如何画猫头鹰”梗图中剩下没画完的部分到底画得好不好、安不安全了。 还有一个让我耿耿于怀的点：当 LLM 的推销员们将“摩擦”视为眼中钉时，他们实际上在暗示什么。在广告、现场演示和 LinkedIn 帖子里，大多数 LLM 营销都在刻画一位孤胆英雄般的工程师（或者一个单兵团队），英勇地利用 LLM 驱动编程，以迅雷不及掩耳之势喷射出一堆应用或网站并火速上线。但是，行业真正想要的是开发者在日常工作中使用 LLM，而在实际工作中，所谓的“摩擦”通常是指那些旨在防止缺陷或糟糕创意流入生产环境的既定流程和规范。 不可避免地，对“LLM 驱动速度”的狂热追求，最终会把矛头指向人本身，包括其他工程师、产品经理、项目经理、测试人员、合规审查员或者设计师。因为这些职位，现在也被视为了“摩擦”。既然我们能捏出 AI 用户画像，还要什么用户调研？既然 AI 工具能直接吐出网页排版，还要什么设计师？既然我们自己就是统帅 AI 智能体大军的经理，还要什么项目经理？如果我们不再需要等另一个开发者来审查我们的代码，只要通过了测试和扫描就自动合并，那该多爽？如果我们再也不用把工作时间浪费在跟别人沟通上，而是直接飞升到一个只剩纯粹编码的境界里，那该多美？ 但是，软件开发是一项协作的过程，团队里的每一个成员都在为打造优秀产品贡献力量。砍掉这些角色，或者用沾染着 LLM 气息的代码幽灵去替代他们，肯定能让团队跑得更快，但这绝不意味着他们交付的产品会更好。而且，这个过程绝对会变得无比孤独。 我极其在乎 我不使用 LLM 的最简单的理由，或许就是我太热爱编程了，以至于我一点也不想把它拱手让给机器。就像如果我是个画家或音乐家就不会求助于 AI 一样，编程是我表达创造力的一种方式，我绝不让出这份纯粹的快乐。尽管有时候它能把人逼疯，但把一个朦胧的想法一点点塑造变成真实的系统，特别是如果其中还包含着优雅的实现或有趣的挑战，这其中蕴含着巨大的喜悦。有些晚上，我会合上工作用的电脑，打开私人的笔记本，一头扎进我想做的某个好玩的新玩意儿里。而在工作中，作为团队的一员去构建软件，那种感觉甚至更棒！我热爱团队协作，热爱一起打磨软件的过程，尤其是看到大家挺身而出、主动承担解决问题的责任时。当团队只是在“承担提示词的责任”，而由 LLM 助手在干活时，我不认为这种动力还能维持原样；或者更糟，当 LLM 助手直接取代了团队的部分成员时。 责任感太关键了。在过去的几十年里，我在不同的岗位上培养出了强烈的个人责任感。作为一名前数据记者，代码里的一个 Bug 可能会导致极其难堪的报纸更正，或者引来灭顶之灾般的诉讼。在公共科技领域，错误可能意味着为公众提供服务和福利的系统彻底崩溃，无论是波及全体弱势群体，还是仅仅影响到一个普通人。我不敢说我从未犯错，但我真的极其在乎把事情做对，因为我在乎这份工作的使命。我有幸曾与许多同样在乎、同样想尽全力为人民服务的同事并肩作战。 而 LLM 是不可能“在乎”的。当然，它可以装得非常逼真，但它依然只是一个试图模仿人类心智的赝品，所做的只是把那些在统计学上更容易同时出现的词组串在一起罢了。它不会因为犯错而感到懊恼，也不会努力试图改进，因为它没有内在的意识，更别提什么道德良知了。它永远无法被追责，因此，我永远也不能把我的道德责任外包给它。 当 LLM 表现良好时，它是即将取代所有程序员的天才；而当 LLM 删除了你所有的基础设施，或者在测试结果上“撒谎”时，错的却是你。毕竟，谁叫你没把提示词和工作流精确地配置好，没能“哄”着 LLM 给出正确输出呢？哎呀，再试一次吧，再试一次。我读过的大量 LLM 教程都在反复强调：你必须在一开始就把所有必要的指令、修正条款和附加说明统统喂给它，否则系统就会把事情搞砸。这种思维模式和敏捷开发完全背道而驰，敏捷开发讲究的是频繁修正方向、及时拿到反馈、信任团队能做出正确的选择。我们似乎正在倒退回一种类似于 1950 年代早期计算机的分时共享模式。只不过这一次，孤单的程序员不再是抱着一沓打孔纸带排队上机，而是拿着厚厚的“法律合同”指望机器把它变成程序。 我开个玩笑；这里其实不涉及什么法律责任。考虑到两者受众群体的相似度，这也许不足为奇，但 LLM 供应商正在重演特斯拉的套路。他们在没有进行安全测试的情况下就把新功能推送给用户，而且诡异的是，就像特斯拉的狂热死忠粉一样，LLM 的鼓吹者们在面对灾难性后果时，往往会责怪自己和他人，声称这是因为用户的提示词写得不够好。我实在不知道该怎么评价这种现象，但科技界正在将一种极端的资本主义标准化，让消费者承担更多的风险，因为企业和政府双双放弃了他们的监管责任，这让我感到极度不安。当初仅仅因为砸死了一个孩子，我们就全面封杀了容易误伤致命的草地飞镖游戏，但逼得用户自杀或精神失常的 AI 聊天机器人，却被视为了 AI 创新必须付出的合理代价。是不是非得等到凭感觉编程引发系统崩溃导致人员伤亡，而不是仅仅死于尴尬时，情况才会有所改变？ 在艰难的时刻，写代码也一直是我的慰藉。有研究表明，玩俄罗斯方块是预防创伤后应激障碍（PTSD）的有效方法。这个理论认为，让大脑中负责排列和旋转图形的部分保持活跃，能阻碍创伤记忆的形成。如今，我很幸运没有患上 PTSD（我绝不是在拿患者开玩笑），但我对这个概念深有共鸣。编程就像是在解一个复杂的谜题，在黑暗的时期，它常常是我的避风港。正像前面提到的例子所暗示的，我对 DOGE 非常了解，因为在过去的一年里，我一直在构建和维护一个追踪他们疯狂行径的系统。与工作项目不同，这完全是一场收集并拼凑数据集的练习，目的是让一个拼命想要隐藏自己的组织暴露在阳光下。这是一个极其充实的过程，也是我将绝望转化为希望能有些用的东西的途径。这已经不是我第一次用代码作为化解悲伤的手段了，它之所以管用，正是因为它是一项需要投入精力的工作。如果我只盯着最终的结果，这个疗愈的过程就会大打折扣。 其他几个可笑的理由 这篇小文的长度已经远远超出了我的预期，毕竟它最初只是我想发在 Bluesky 上的几段简短牢骚。在结束之前，再快速补充几个理由。 首先，我极度反感 AI 聊天机器人默认的那种油腔滑调的语气。作为一个在美国东海岸城市长大的人，当一个我不认识的人突然对我表现得热情过头、客气得有些诡异时，我就会本能地警觉起来，因为这通常意味着他们要么准备骗我的钱，要么准备向我传教。读 LLM 的聊天记录会让我起鸡皮疙瘩。是的，我知道我可以通过设定让 LLM 换一种语气，但不知为何，这只会让整个事儿感觉更糟。 和许多开发者一样，我也存了整整一个文件夹的草稿，里面全是那些永远没填完坑的业余项目。比如，我曾经打算用 Clojurescript 写一个拼字游戏的克隆版，因为这样我就可以利用 Blabrecs 里的代码生成一堆根本不存在的假词，故意把游戏搞得让人抓狂。好吧，我承认这可能只是我个人的恶趣味，你得设身处地才能 get 到笑点。从 LLM 的角度来看，这些都是装满失败的文件夹，我确实可以用 LLM 来搞个“一天做一个 App”之类的挑战。然而，过程远比结果重要。不是每一个突发奇想的脑洞都必须变成现实产品，通常情况下，我从头脑风暴的乐趣中，以及为了证明“我没必要把这玩意做完”而学习新知识的过程中，获得的收获要多得多。 我原本不打算在这篇文章里讨论在工作中使用 LLM 的道德问题。不是因为我不在乎，而是因为已经有太多比我聪明的人，极其深刻地论述过这项技术所带来的令人忧虑的隐患。在当下这个 LLM 正在向带有儿童的学校发送炸弹威胁，或者按需生成儿童色情内容的时代，我真的不放心使用它们。如果我连提都不提这方面，我心里也会过意不去。在资本主义的框架下，也许确实不存在绝对道德的消费，但就算见鬼，我也至少要努力去尝试一下。我们不可能用一种让如此多的人陷入悲惨境地的工具，来建设一个更美好的世界。 说来也怪，似乎没有谁比这帮 LLM 的吹鼓手们活得更苦大仇深了。如果开发者们利用他们新获得的“生产力暴涨”，终于过上了 10 年前这帮极客们假装膜拜的每周工作 4 小时的乌托邦生活，我可能还真会被打动。但病态的是，硅谷的许多人似乎把工作外包给了 AI 智能体之后，反而利用节省下来的业余时间去接了更多的工作。他们没有把时间用来休息、搞艺术或享受生活，而是拥抱了 996 工作制，以及一个高度量化的工作环境，这甚至会让以极度压榨著称的科学管理学派祖师爷弗雷德里克·泰勒看了都直冒冷汗。也许 LLM 革命最终会席卷我和我的饭碗，但在那之前，我可不想先把自己卷进坟墓里。 未来路在何方？ 我不会假装自己能预知未来。也许这项技术真的会发展到不可思议的地步，以至于我会后悔当初没有积累足够的经验去熟悉它。又或者，它也许会陷入停滞，整个建立在炒作之上的金融纸牌屋轰然倒塌。如果那一天真的到来，我希望我们能把软件开发重新建设成一种充满人性关怀的实践。

译本文作者以资深工程师的视角，阐述了其不采用“凭感觉编程”（Vibe Coding）的原因。核心论点是：AI工具主要缓解了软件开发中编写代码等“偶然复杂性”，但无法触及设计健壮、可维护系统架构这一“本质复杂性”，后者仍需依赖深厚的人类经验与判断。作者进一步指出，大语言模型（LLM）仅在符号层面运作，缺乏人类对上下文、社会现实及模型自身局限性的“元认知”能力，无法审问和反思数据与抽象背后的简化与遮蔽。因此，他认为构建清晰系统的关键仍在于人类的专业判断与反思。

Tibo@thsottiaux · 5月18日10

Codex is for cosy Sunday evenings. Show me your cosy creations.

译Codex 适合慵懒的周日夜晚。展示你的慵懒创作。

meng shao@shao__meng · 5月18日62

给 AI 时代工程师们的警示：不要把你的学习外包给 AI 随着 LLM 和 Agent 能力增强，作为工程师，咱们 “接受 AI 建议” 的概率在不断增加，甚至会默认跳过确认环节直接接受。@addyosmani 自己也是 AI 重度用户，但不会把学习和判断让 AI 来做。 几乎所有人都陷入一个工作模式： 粘贴报错 → 模型给出修复 → 症状消失 → 提交代码 → 进入下一个任务 在这个循环中消失的，是 "问题与解法之间那段混乱的挣扎"，而这段挣扎，恰恰是认知能力生长的唯一土壤。 Addy 把这称作"单人版的认知投降"：模型更快，于是你放弃在"理解深度"上与它竞争。每次妥协都微小到不构成事件，但成千上万次叠加后，离开 AI 你还能独立构建什么——这个能力每周都在缩水。 三项研究的趋同结论 1. Anthropic (2026) Python 库学习实验 AI 组与对照组完成速度相同，但理解测验得分 50% vs 67%；调试题差距更大 2. MIT《Your Brain on ChatGPT》 EEG 测量显示 LLM 用户脑区耦合最弱；83% 的人写完文章后无法引用自己刚写的任何一句 3. CHI 2026 锚定效应研究 任务开头使用 LLM 会框定整个问题空间，即使后续靠自己完成，决策质量也明显下降 为什么工具本身不会帮你？ Addy 点破了一个产品逻辑层面的真相： · 产品团队的 KPI 是"合并的 PR 数"和"更短的周期时间"，不是"让你变成更强的工程师" · 工具刻意把摩擦力打磨干净——而摩擦力正是学习发生的地方 · Claude Learning Mode、OpenAI/Google 的同类功能确实存在，但被集体归类为"学生用的"——这是严重误判 什么时候纯委托 AI 会崩塌？ Addy 还是认为：样板代码、胶水代码、一次性脚本——该委托就委托。但在五种场景下，纯委托必然失败： · 出 bug 时——"代码是 agent 写的"不能帮你 debug · AI 自信地错了时——对抗"看起来合理的错误答案"的唯一防线是足够的专业知识 · 底层变化时——框架升级、安全审计发现结构问题，无法靠 re-prompt 解决 · 偏离中位数时——AI 擅长 GitHub 上被解过一百万次的问题，越独特越无能 · 市场重新定价时——只能"带 AI 才能交付"的工程师，正进入一个正在重估专业价值的劳动力市场 最后一句尤其锋利： "如果你用 AI 跳过学习，你是在用未来的相关性，换一个稍微轻松点的周二。" # 可执行的姿势调整（核心方法论）# 1. 先形成假设，再提问 请求修复前，先写两三句你认为问题是什么。用模型的答案验证你的理论，而不是替代它。 2. 先要解释，再要代码 进入陌生领域时，第一条 prompt 应该是："解释它如何运作、有哪些替代方案、各自的权衡是什么"。理解了概念，再要代码。 3. 在能力之外时打开 Learning Mode 是的，会更慢。这正是重点。 4. 把 AI 的输出当作 junior 的 PR 来审 "测试过了"就足以合并吗？如果不是，这里也不行。 5. 偶尔徒手重写一遍 拿一段 AI 写过的代码，从零复现。这是校准检查，告诉你已经悄悄丢了多少。 6. 让模型反过来教你 代码生成后再加一条 prompt："你用了哪些概念？我需要读什么才能理解这个设计选择？"——一条额外的 prompt 就能改变这次会话的留存。 # 两个独立的指标 # 一个极简但深刻的自检框架： 每次写完代码问自己："我今天学到了什么，还是只是关闭了 issue？" · 偶尔答案是"只关了 issue"——没问题 · 连续几个月都是这个答案——认知债务正在背景里累积 "Ship" 和 "Learn" 是两个独立的指标。 · 你的 manager 和客户只会问第一个 · 第二个，只能你自己问自己

译Addy Osmani 警示工程师过度依赖AI生成代码会导致“认知投降”，即牺牲深度理解换取效率。研究显示，依赖AI会削弱问题理解、脑部活动和决策质量。产品设计追求效率，但学习恰恰发生在“摩擦力”中。AI委托在样板代码中有效，但在调试、AI犯错、底层变化、处理独特问题及面对市场价值重估时必然失败。作者建议应形成假设再提问、先要解释再要代码、开启学习模式、审阅AI输出如PR、徒手重写代码，并区分“交付”与“学习”指标，避免用未来能力换取短期轻松。

Greg Brockman@gdb · 5月18日22

so much joy in asking codex for random questions at work (such as finding some specific spreadsheet i'd been looking at a while ago), much more fun than searching around for context by hand

译工作中向Codex随意提问带来许多快乐（比如查找之前看过的某个具体电子表格），远比手动搜索上下文有趣得多。

StepFun@StepFun_ai · 5月18日35

When AI handles the syntax, what's a developer's actual value? Next Wednesday in Mountain View, we're exploring the shift from AI coding to AI creating with @EazoAI, Agora, and SEAMATE. Our team is on stage. Come dig into it. May 21 · 5-7 PM RSVP: http://lu.ma/eqpg9qy3

译当AI处理语法时，开发者的真正价值是什么？ 下周三在Mountain View，我们将与@EazoAI、Agora和SEAMATE一起探索从AI编码到AI创造的转变。 我们的团队将在台上。来深入探讨。 5月21日·下午5-7点 RSVP: http://lu.ma/eqpg9qy3

Tibo@thsottiaux · 5月18日43

Seeing issues where usage limits are out of sync for some Codex users. Apologies and team is investigating.

译发现部分Codex用户的使用限制出现不同步问题。 为此致歉，团队正在调查。

AYi@AYi_AInotes · 5月18日66

Kimi做网站设计这么牛逼吗？ 这个视频分享了怎么用Kimi 2.6做获奖10美元的网站， 教程讲的特别细， 需要字幕学习的可以评论区留言告诉我！