Tencent Hy@TencentHunyuan · 5月6日76

Two weeks after release, Hy3 preview is #1 on @OpenRouter's weekly leaderboard with 3.66T tokens processed, up 298% week-over-week. #1 in overall usage, tool calls, and coding. 15.4% market share across all providers.🏆 Top apps running Hy3 preview: Hermes Agent, Claude Code, Kilo Code, OpenClaw, Cline.@NousResearch @claudeai @kilocodehq @openclaw @cline Huge thanks to every developer building with it. 🙏 Try it on OpenRouter: https://openrouter.ai/tencent/hy3-preview:free

译发布两周后，Hy3预览版以3.66T处理量在@OpenRouter周榜位列第一，周环比增长298%。 在总使用量、工具调用和编程领域均排名第一。全平台市场占有率达15.4%。🏆 运行Hy3预览版的热门应用：Hermes Agent, Claude Code, Kilo Code, OpenClaw, Cline。@NousResearch @claudeai @kilocodehq @openclaw @cline 衷心感谢所有基于此开发的开发者。🙏 请在OpenRouter上试用：https://openrouter.ai/tencent/hy3-preview:free

阿绎 AYi@AYi_AInotes · 5月6日79

这个创造了Claude Code的男人Boris Cherny大神，完整公开了自己的工作流，并直播演示了一半的编码工作在手机上完成🤪 不是回消息，是同时跑5到10个Claude实例， 用手机启动任务，去喝咖啡，回来代码写好了🤣 他刚公开了自己的完整工作流，看完之后我发现， 核心就三件事，但每一件都跟大多数人的直觉相反： 第一，永远选最贵最聪明的模型 听着像烧钱，实际上反过来，聪明模型一次想清楚，笨模型来回试错烧掉的token远超差价。 他的原话："计划做得好，代码自然好。" 第二，整个团队维护一个纯文本知识库 不是Notion，不是花哨的文档系统，就是一个txt文件。Claude每犯一次错，记一笔，每周更新好几次，这个文件就是团队的长期记忆，Claude不会在同一个地方摔倒两次。 第三，永远让Claude看到自己代码的运行结果 能跑代码，能看浏览器渲染， 他的比喻很准："你让一个画家蒙着眼睛画画， 画完不让他看，然后怪他画得丑？" 他的清晨流程：醒来，手机上启动三个任务， 该干嘛干嘛，晚点回来检查。 规划模式起步 → 敲定计划 → 自动接受修改 → 完成 多个Claude实例，一个周密计划，一个共享知识库，没了。

译Boris Cherny公开其高效AI编码工作流，核心基于三点反直觉原则：1. 坚持使用最昂贵、最聪明的模型（如Claude），因其能一次性清晰规划，避免笨模型反复试错消耗更多token；2. 团队仅维护一个纯文本知识库文件，记录Claude的每次错误并每周更新，形成长期记忆；3. 始终让Claude查看自身代码的运行结果（包括执行和渲染）。其工作模式是在手机上并行启动多个Claude实例，基于规划模式制定方案后自动执行修改，从而高效完成任务。

Berryxia.AI@berryxia · 5月6日18

时间留给Trae 吧😂 我们来喝咖啡就可以了！

译Trae推出限时推广活动，用户下载其手机客户端并完成一次问答，即可在5月8日活动开启后，于北京、上海、广州、深圳、杭州、成都免费领取星巴克咖啡。活动通过分享链接进行传播，旨在吸引用户体验其服务。

向阳乔木@vista8 · 5月6日70

搞定了，随时粘贴排版多张图，完成后插入文章或导出。

译针对教程写作中拼接多张图片需借助Figma等工具过于笨重的问题，开发者通过与AI讨论，获得使用HTML5 Canvas库的解决方案。现已将该功能整合到Markdown编辑器中，用户可直接在编辑器内完成多图拼接，随后将拼合好的图片插入文章或导出。相关代码已开源至Github项目。

Chubby♨️@kimmonismus · 5月6日19

Just a quick reminder: Anthropic is hosting its "Code with Claude" developer conference in San Francisco on May 6, 2026. Last year they revealed and released Sonnet and Opus 4 that day. Oh and btw: the new ChatGPT personalization / memory-function is freaking amazing.

译温馨提示：Anthropic将于2026年5月6日在旧金山举办"Code with Claude"开发者大会。 去年同日他们曾发布Sonnet和Opus 4。 顺带一提：新版ChatGPT的个性化/记忆功能实在令人惊叹。

ginobefun@hongming731 · 5月6日21

在 Cursor 上使用 Sonnet 4.6 修了几个 bug，20 刀的额度就用完了 😅，这么一对比，Codex 和 Claude Code 真是耐用

Peter Steinberger 🦞@steipete · 5月6日68

Me and codex were busy. 🔊 http://sonoscli.sh — Sonos 🗃️ http://wacli.sh — WhatsApp 🪶 http://birdclaw.sh — X archive 🧰 http://gitcrawl.sh — GitHub archive 🛰️ http://discrawl.sh — Discord archive 🎧 http://spogo.sh — Spotify 💬 http://imsg.sh — iMessage 🧳 http://mcporter.sh — MCP to CLI 🗣️ http://sag.sh — ElevenLabs voice 🧿 http://askoracle.sh — second opinion Upgrading the 🦞 OpenClaw army.

译我和codex正忙着。 🔊 http://sonoscli.sh — Sonos 🗃️ http://wacli.sh — WhatsApp 🪶 http://birdclaw.sh — X存档 🧰 http://gitcrawl.sh — GitHub存档 🛰️ http://discrawl.sh — Discord存档 🎧 http://spogo.sh — Spotify 💬 http://imsg.sh — iMessage 🧳 http://mcporter.sh — MCP转CLI 🗣️ http://sag.sh — ElevenLabs语音 🧿 http://askoracle.sh — 第二意见 升级🦞 OpenClaw大军。

Peter Steinberger 🦞@steipete · 5月6日36

CodexBar 0.24 is live 🤖 New Windsurf, Codebuff + DeepSeek providers 👥 Copilot multi-account switching 🧹 Opt-in local storage breakdowns 🔋 Hung Codex RPC + redraw battery drain fixed Tiny menu bar, ridiculous changelog. https://github.com/steipete/CodexBar/releases/tag/v0.24

译CodexBar 0.24 已发布 🤖 新增 Windsurf、Codebuff + DeepSeek 提供商 👥 Copilot 多账户切换功能 🧹 可选本地存储详情查看 🔋 修复 Hung Codex RPC 及重绘导致的电量消耗问题 小巧的菜单栏，离谱的更新日志。 https://github.com/steipete/CodexBar/releases/tag/v0.24

meng shao@shao__meng · 5月6日77

全球首个基于 Subquadratic Sparse Attention (SSA) 架构的前沿 LLM ~「SubQ」，实现 12M token 的实用上下文窗口，同时在效率上大幅领先传统 Transformer，来自 @subquadratic 技术核心突破：SSA 机制 传统 Transformer 的标准注意力是全对全（all-pairs），计算复杂度为 O(n²)，导致长上下文成本爆炸。大多数 token 间的交互实际无意义，却仍需全量计算。 SSA 的创新在于内容依赖的选择（content-dependent selection）： · 每个 query 只动态挑选真正相关的 key 位置进行注意力计算。 · 实现线性缩放（linear scaling）：计算与内存成本随序列长度线性增长，而非二次方。 · 同时保留内容驱动路由与任意位置精确检索能力，避免了固定模式稀疏注意力（位置无关）、RNN/SSM（状态压缩丢失细节）或 DeepSeek DSA（selector 仍为二次方）等方案的权衡。 实测效果（B200 GPU + FlashAttention-2 对比）： · 128K token：7.2× 预填充加速 · 1M token：52.2× 加速 · 成本 < Opus 的 5%，支持 12M token 上下文。 训练与功能定位 SubQ 采用三阶段训练（预训练 → SFT → RL），特别强化长上下文下的可靠检索与多跳推理，针对企业真实场景（如完整代码库、长合同、跨文档研究）优化，而非仅追求基准分。 功能定位：解决“名义上下文窗口”（能塞多少 token） vs “功能上下文窗口”（能有效利用多少 token）的鸿沟。适用于 Coding Agent、长期 Agent 会话、企业知识库等需要“一次性看全”而非 RAG/分块的场景。 SubQ Code 也可以申请试用，我也刚刚申请，期待通过后再做具体分享。申请链接在这： https://subq.ai/request-early-access

译前沿模型SubQ基于创新的Subquadratic Sparse Attention架构，实现了1200万token的实用上下文窗口。其核心技术SSA通过内容依赖的选择机制，让每个查询仅动态计算与相关键的注意力，使计算和内存成本随序列长度线性增长，而非传统Transformer的二次方增长。实测在100万token时比FlashAttention-2快52.2倍，成本低于Opus的5%。该模型针对需要一次性处理完整代码库、长文档等企业真实长上下文场景优化，旨在弥合“名义上下文”与“功能上下文”窗口的差距。

Peter Steinberger 🦞@steipete · 5月6日42

I asked Molty to review my PR and it made a song. https://github.com/openclaw/openclaw/pull/77205

译我让Molty审查我的PR，它创作了一首歌。https://github.com/openclaw/openclaw/pull/77205

宝玉@dotey · 5月5日67

http://x.com/i/article/2051687844679143424 # Boris Cherny：Claude Code 之后，写代码正在变成“管理 Agent” Boris Cherny 是 Anthropic 内部 Claude Code 的创建者，从一个三人小团队的孵化项目做起，把“在 IDE 里按 Tab 自动补全一行代码”这件事彻底升级成“让 Agent 把整个项目写完”。Claude Code 在 2026 年初已经超过十亿美元年化营收，被 Anthropic 自己称为“史上从研究预览到十亿美元产品最快的一次”。 这次访谈来自 Sequoia 2026 年的 AI Ascent 大会，主持人是红杉合伙人 Lauren Reeder。 原始视频：https://www.youtube.com/watch?v=SlGRN8jh2RI ## 要点速览 - Boris 整个 2026 年没写过一行代码，每天合并几十个 PR，单日记录是 150 个，但他承认这是“为了试试模型能跑多远”。 - Claude Code 早期半年没有 PMF，做出来时 Boris 自己只用它写 10% 的代码，是 Opus 4 在 2025 年 5 月发布之后才开始指数增长，每一代新模型都让曲线再往上拐一下。 - Boris 现在大部分工作从手机完成，Claude App 里常驻 5 到 10 个 session、几百个 Agent，夜里有几千个在跑深度任务，核心调度模式叫 Loop，做法是让 Claude 通过 cron 起一个定时循环。 - Anthropic 内部已经没有手写代码：所有 SQL、所有产品代码都由模型生成，员工的 Claude 之间通过 Slack 互相沟通，把对方的不确定问题直接 ping 过去问。 - 关于“SaaS 的终结”，Boris 借用 Hamilton Helmer 的“七种护城河”框架：切换成本和流程效力这两种会被 AI 抹平，因为模型可以帮你迁移、可以自己迭代流程；网络效应、规模经济、独占资源这些不变。 - 他给出的最重要历史类比是印刷术，认为软件构建会像识字一样普及，最合适写会计软件的是会计师而不是工程师，因为编程是简单部分，懂业务才是难的部分。 - Anthropic 的真正领先不在技术，在组织流程：模型大家都能用，但内部组织怎么改造、Claude 怎么互相沟通、整个公司怎么把所有手写代码替换掉，这才是产品差距。 ## 【1】Claude Code 是怎么从一个三人孵化项目做出来的 Boris 说他是“误打误撞”做出 Claude Code 的。2024 年底他加入了 Anthropic 内部一个叫 Anthropic Labs 的孵化器，团队只有几个人，一开始的产物就是 Claude Code、MCP 和 Claude Desktop App 这三件东西。这个团队一度被解散，2026 年初又重组，由 Mike Krieger 牵头。 > 注： Mike Krieger 是 Instagram 联合创始人兼前 CTO，2024 年 5 月加入 Anthropic 担任首席产品官，2026 年 1 月起进入 Labs 团队，和 Ben Mann 一起负责实验性产品孵化。 Boris 描述他当时为什么想做编程这件事，用的是 Anthropic 内部很常用的一个词：“product overhang”。这个词可以翻译成“产品悬置（Product Overhang，指模型能力已经具备但尚未被产品化）”，意思是模型已经能做一堆事情，但还没有任何产品把这些能力展现出来。 > 我们当时看编程领域，2024 年底最先进的状态就是按 Tab 键。打开 IDE，按一下 Tab，模型给你补一行。这是 Sonnet 3.5 第一次让人能做的事情。但当时的感觉是，我们其实可以走得更远，模型几乎已经准备好下一步了。我们不需要再做 Tab 补全，可以直接让 Agent 把整段代码都写了。 但做出来之后，前六个月几乎没什么人用。Boris 说最初版本“基本不能用”，连他自己也只用它写 10% 的代码。即便对外发布，也没有指数级增长。真正的爆发点是 2025 年 5 月 Opus 4 发布。从那之后，每一代新模型都让曲线再往上拐一次，从 Opus 4 到 4.5、4.6，再到现在的 4.7。 他承认整个过程其实是一场违背常规 PMF（产品市场匹配）逻辑的赌注： > 我们其实是在做一个初期完全不具备 PMF 的东西。我们很清楚它前六个月不会有 PMF，因为我们是在为下一代模型做开发。我们从始至终就是这个思路。 > 注： PMF 是 Product-Market Fit，产品市场匹配。Anthropic 整个产品逻辑就是赌“模型能力会涨到一个点”，提前把那个点对应的产品做出来，这和典型 SaaS 的“先验证需求再做产品”是反着的。 ## 【2】“编程已经被解决”，但这是 Boris 个人的版本 Lauren 问他公开说过的“编程已经被解决”是什么意思。Boris 在台上做了一次现场调查，让全场观众举手示意：“谁 100% 还在亲自写代码”、“谁 100% 已经完全不写了”、“谁介于两者之间”。最后的现场分布大致是“50% 解决”。但对 Boris 自己，比例是 100%。 他给的解释是 Claude Code 的代码库（已经因为泄露事件被外界看过）就是 TypeScript 和 React，没什么秘密。选 TypeScript 和 React 的原因是这两个东西在模型训练数据里非常常见，属于“on-distribution（分布内数据）”。当时模型还没那么聪明，框架选择关系到模型能写多少。现在模型已经强到可以拿不熟悉的语言现学现用，但 2024 年底必须挑模型最熟的栈。 正因为选了模型最熟的栈，团队很早就过了一个临界点：模型开始写 100% 的代码。Boris 说这件事在去年 10 月、11 月就发生了。 > 现在我每天大概合并几十个 PR。上周有一天我合了 150 个，那是个记录，我就是想看看能不能把它推到极限。 但他也明确承认，这条结论并不普世：还有很大很复杂的代码库、还有模型不擅长的小众语言。他给出的一句答案有点“等就完事了”的味道。 > 通常的答案就是等下一代模型。 > 注： Boris 这段说法的样本明显有偏。他用的是 TypeScript+React 这种主流栈，自己的代码库已经成熟，还在 Anthropic 内部用着内部专属模型 Mythos 来 dogfood（吃自己的狗粮，指内部试用自己的产品）。“编程已被解决”对他成立，但替换到一个三十年的 C++ 老系统、一个 SAP ABAP 项目，或者一个游戏引擎团队，结论会非常不同。 ## 【3】手机里跑着几百个 Agent：Boris 的工作流 Boris 说他六个月前在 Twitter 上分享过一次个人工作流，发的时候没觉得有什么稀奇，结果出乎意料地火。从那以后他的方式又变了：现在大多数工作从手机完成。 具体方式是 Claude App 左侧有个 code 标签，他常驻 5 到 10 个 session。每个 session 里又开着一堆 Agent，加起来通常有几百个在跑。晚上还会再起几千个做更深的任务。 他说目前最常用的不是子 Agent，而是一种叫 Loop 的简单模式：让 Claude 用 cron 起一个定时任务，可以每分钟、每五分钟、或者每天跑一次。 > 我大概有几十个 Loop 一直在跑。一个负责盯着我的 PR，自动修 CI、自动 rebase；一个负责让 CI 整体保持健康，比如某个测试 flaky（时好时坏不稳定）了它就去修；还有一个每 30 分钟从 Twitter 上把别人对 Claude Code 的反馈拉一遍、聚类、整理给我。 他还提到 Anthropic 刚发的 Routines，这个产品其实是把同样的 Loop 模式从本地搬到服务器上，关掉笔记本它也照常跑。 他对这件事的判断是：“Loop 是未来。” > 注： CI 是 Continuous Integration，持续集成。Boris 描述的这套工作流核心其实很简单：更早地放弃“亲自下指令”。他做的事情是让一群 Claude 不停地干活，而他自己只在 Slack 上接收报告。从产品视角看，Routines 把 Loop 从客户端模式变成 Anthropic 自己托管的服务，调度本身要开始消耗他们的服务器资源，定价模型迟早要变。 ## 【4】通才崛起：团队里每一个角色都在写代码 Boris 说他的判断是 “通才会比今天多得多”。 他先把“通才”分了两种：第一种是工程通才，比如一个人同时写 iOS、Web 和服务端，今天大家说的 generalist 多半是这种。第二种是更值得关注的跨学科通才，一个产品工程师同时也很懂设计，或者既能做产品也能做数据科学。 他说这件事在 Claude Code 团队内部已经在发生： > 我们团队的工程经理、产品经理、设计师、数据科学家、财务、用户研究员，每一个人都在写代码。每个人都还在某件事上是专家，但也都在写代码了。 他没有展开“为什么这是好事”，但暗含的逻辑是：当写代码的边际成本接近于零，那些原本被排除在工程之外的角色（财务、设计、研究）就有了直接出工程产物的能力，分工的边界自然会模糊。 > 注： 这个判断在创业公司里很容易验证，但放在大型企业里就麻烦得多。一个 5000 人的银行 IT 部门有合规、风控、变更管理、审计追踪等等约束，这些不是“我会写代码”就能跨过去的。Boris 谈的是 Anthropic 自己这样规模较小、流程很轻的公司，迁移到其他规模和行业之前，需要打个折扣。 ## 【5】SaaS 的终结：哪些护城河会被 AI 抹平，哪些还留着 Lauren 问：写代码现在便宜了 10 倍、100 倍，那靠软件做出来的产品的价值会怎么变化？我们是不是要面对一场 SaaS 的终结？ Boris 说这是他最爱的问题。然后他借用了一个外部框架来回答：Hamilton Helmer 的“Seven Powers”。 > 注： Hamilton Helmer 是策略学家、Strategy Capital 创始人，2016 年出版《7 Powers: The Foundations of Business Strategy》。书里把可持续竞争优势分成七种：规模经济、网络效应、反向定位、切换成本、品牌、独占资源、流程效力。这本书在硅谷非常流行，Reed Hastings、Daniel Ek、Patrick Collison 都给过推荐语。 Boris 的判断是 AI 会把其中两种护城河抹平： 第一种是切换成本。原因很直接，模型可以帮用户从一个工具迁到另一个工具，原本“我已经在 Salesforce 上配了三百个工作流，没法换”这件事，模型一夜之间就能帮你迁完。 第二种是流程效力，也就是那种“我们的工作流和流程别人复制不了”的优势。Boris 说 Claude 4.7 已经能“hill-climb（爬坡式优化，即逐步逼近最优解）”任何东西，你设定一个目标，让它自己迭代优化，它最终就能达成那个效果。流程优化原本是大公司多年积累出来的内部资产，现在被模型直接吃掉了。 > 这是第一个能做到这件事的模型。你给它定下目标，让它不断运行直到达成，它就能自动执行到底。 但他认为另外几种护城河没有被改变：网络效应、规模经济、独占资源依旧成立。换句话说，那些“用户越多越好用”的产品（社交、平台、市场）和那些“我有一个别人拿不到的资源”的公司（专利、特许牌照、独家合同）依旧安全。 第二个判断更激进： > 接下来 10 年里，能颠覆原有市场的初创公司数量大概会比过去 10 年多 10 倍。因为现在你可以做一家很小的公司，做出和大公司一样有价值的产品，然后正面竞争。大公司要改业务流程、要重新培训员工、内部还会一堆抵抗，但你不需要，你是从一张白纸开始的。 > 注： Boris 关于切换成本会被抹平的判断有结构性争议。模型确实能帮你迁数据，但企业 SaaS 的真正切换成本另在他处：合规审计、合同条款、组织里的“使用习惯”和供应商认证。Salesforce 和 SAP 的护城河靠的从来是这套审批和惯性，技术本身只占很小一部分。Anthropic 自己的 Cowork 已经在挑战这一点，但市场反应（2026 年 2 月软件股蒸发 2850 亿美元市值）说明投资人在押注他的判断成立。这是一笔很大的赌注，未必很快收敛。 ## 【6】产品 vs 模型：模型变强了，产品的价值还剩多少 观众 Dan 问：Claude Code 的成功你会怎么归因？产品决策和模型本身各占多少？ Boris 没有给出一个简单明确的答案。他先说一年前可能是 50/50，六个月前可能也是 50/50。两年后呢？他直接说：“不知道，我们一次只做一周的计划。” 但接着他给了一个更有意思的回答： > 我以前在 YC 待过，做过几家初创公司。YC 反复跟你强调的就是：做一个用户爱用的东西。不管模型多强、不管你做的是什么品类，最后你都得做出一个用户真的爱用的东西。这就是产品为什么重要。我们花了大量精力在小细节上，因为你一整天都在用它，那这些细节就构成了体验。 他同时也承认，随着模型变强，外面那一层“harness”（脚手架、调用框架）会变得没那么重要。一年后产品安全机制（prompt injection [提示词注入] 防御、命令静态校验、permission mode、human-in-the-loop [人类在环，即关键决策保留人工确认]）可能都不需要那么多了，因为模型自己就会做对的事。 他的产品方向也不是再加一层皮，而是去想：怎么让 Loop 变成一等公民？怎么让一个人同时跑很多个 Agent 这件事更顺手？ > 注： Boris 这一段实际上承认了 Anthropic 自己内部的一个判断：随着模型能力上升，应用层的差异化窗口在缩短。这对独立的 AI 应用公司是个不太友好的信号。你今天在 Claude API 上加的那一层 wrapper（包装器/套壳应用）、那一套 prompt engineering、那一套权限管理，可能一年内就会被基础模型自己内化掉。 ## 【7】软件大众化：从印刷术到发短信 观众问：Claude Code 会不会让“建软件”变成一种像“会用 Office”那样人人都该会的技能？ Boris 的回答是：会，而且比这更夸张。 > 我觉得它会变成一种“我会发短信”那种级别的技能。 他展开讲了他最爱的历史类比：印刷术。 按 Boris 的说法，1400 年代欧洲只有大约 10% 的人识字，他们经常被国王和贵族雇来代笔。古登堡发明印刷术之后又出现了两台改良型印刷机，接下来的 50 年欧洲出版的文献比之前 1000 年加起来还多，一本书的成本下降了大约 100 倍。又过了几百年，全球识字率上升到 70%。今天我们都会读写，但还存在“专业作家”这个职业。 > 注： Boris 给的几个数字偏低。15 世纪初欧洲成年识字率，学界估计是 25-30% 而非 10%；今天全球识字率，世界银行的数据接近 90% 而非 70%。但他要表达的方向是对的：印刷术是欧洲文化史上最重要的去专业化事件之一。1500 年时全欧洲的印刷书籍数量已经超过两千万册。 Boris 的推论是，软件也会经历同样的过程，时间会比 50 年快得多。然后他给了一个具体的角度： > 比如说写会计软件。今天写会计软件最合适的人，我觉得已经不是工程师了，是一个真正懂业务的会计师。因为他对领域熟得不能再熟，写代码反而是简单的部分。 这个判断背后的潜台词也很清楚：未来一段时间最容易被取代的岗位，是那种“只会写代码、不懂任何垂直领域业务”的纯技术工程师。 ## 【8】真正的内部领先在组织流程，而非技术 观众问：之前有人说你们这种公司是“活在未来”，因为你们能用到模型和产品的最早版本。Claude Code 在外发之前是内部工具。Anthropic 的工程实践和外面的差距，是一个月、三个月、还是六个月？这个差距在变大还是变小？ Boris 的答案是模型层基本没差距：内部用的就是 Mythos 和 Opus 4.7，“Mythos 我们用一点点试，Opus 4.7 是我们内部试用（dogfooding）的主力”。这些模型未来的某个变体也会对外开放。 > 注： Mythos 是 Anthropic 在 2026 年 4 月公开承认存在的内部前沿模型，对外仅在 Project Glasswing 这个网络安全防御计划内开放，不在 API 也不在 Claude.ai。它在 SWE-bench 上达到 93.9%、USAMO 97.6%，宣称“显著超过任何已发布模型”。Boris 这里承认 Anthropic 内部用 Mythos 来 dogfood Claude Code 自己。换句话说，外界用到的 Claude Code，是用一个没公开的更强模型一起搭出来的。 但他认为产品层有更大差距，原因来自流程，跟模型本身没关系： > 在 Anthropic 我们已经把 Claude 用到一切环节。我在写代码的时候，我的几个 Claude 在 Loop 里跑，它们会通过 Slack 去找其他人的 Claude 聊天，把不确定的事情问出来。我们整个公司没有任何手写代码了。所有 SQL 都是模型写的。 他的结论是：领先的关键在组织怎么改造自己。 技术大家都能拿到，但要把整个公司从手写代码切到模型生成代码，要让员工的 Claude 之间通过 Slack 互相问问题，要让所有 SQL 都不用自己写，这是组织行为的改造，比技术本身慢得多。 > 注： “我们没有任何手写代码”是个大胆的表述，可能不完全字面准确（基础设施代码、合规代码、安全敏感代码大概率还是手写），但方向上反映了 Anthropic 对工程组织的激进重塑。这也回答了一个常见困惑：很多公司接入了 Claude API 但没看到生产力变化，问题往往出在组织没跟着重组，模型其实已经够强了。Mike Krieger 在另一个采访里给过类似口径：“Claude 现在写 90-95% 的代码，瓶颈不在工程，在决策。” ## 【9】并行 Agent 与本地模型：用户不该操心这些事 观众 Jiren 问：你们在产品和模型层面分别是怎么注入“什么时候该并行”这种先决条件的？因为现在用户得自己判断什么时候该开多个 Agent，这件事其实应该是模型自己懂。 Boris 说在产品层面就是改 prompt：调整提示词，让模型更倾向于自动并行。但他更想说的是模型自己在变好，4.7 已经会自然这么做。他举了一个例子： > 我让 4.7 跑一个数据查询，它会主动跟我说：“我注意到这个数据是在变化的，我帮你起一个 Loop，每 30 分钟给你一份报告。”我说“好啊，发到 Slack 上吧。”它就用 Slack MCP 自己接好了。 他的判断是，长期看用户不应该需要自己理解什么时候用 batch（批处理）、什么时候用 Loop、什么时候开几个 Agent： > 如果用户得自己学会怎么调度这些工具，那其实是产品设计没做好，是我没做好。这件事应该交给模型，加上我们怎么提示它。 ## 【10】云端 AI vs 本地 AI 观众问：现在大家用 Claude、用 Codex 都在云上。但也有不少人主张本地化 AI，开源权重模型追上之后，本地跑高质量代码助手是个有可能的方向。你看长期方向是云为主，还是本地崛起？ Boris 的回答很直接：这件事并不重要。 > 因为未来这些底层细节模型会自动处理。一两年后，模型自己就能独立完成写代码、启动 Agent、搭建环境的所有事情。如果它评估后认为“我应该用本地模型来做这件事”，它就会这么干。这些将不再需要工程师去人工决策。 > 注： 这个回答在 Sequoia 这种创业生态会议上其实很有意思。本地 AI 这件事在硬件厂商（NVIDIA、Apple、AMD）、开源社区（Llama、Qwen、Mistral）和隐私敏感行业里都有人在押注。Boris 直接把这个问题归类为“用户不该关心的实现细节”，等于把“模型部署位置”变成了“由更上层的 Agent 决定的路由问题”。这对靠“我们是本地优先”做差异化的初创公司不算好消息。 ## 【11】MCP 与 Computer Use：知识工作怎么走 Claude Code 那条路 观众 Jamie Nestor 问：Claude Code 之所以好用，很大一部分原因是开发者的工作本来就在本地，文件、终端、Git 都在本机。但知识工作不是这样，文档、表格、CRM 都在云上。Cowork 这种产品要让这套东西像 Claude Code 对开发者那样好用，你怎么想？ Boris 先承认知识工作大部分早就在云上了：Salesforce、Google Docs 都是云原生。然后他给的答案非常简洁： > 对我们来说答案永远是最简单的那个：MCP。Claude.ai 里你接的那个 Salesforce MCP 连接器，Cowork 也能用，Claude CLI 也能用，所有 Claude Code 的入口都能用。 Jamie 追问：那对那些没有 MCP 的系统，Computer Use 是不是更大的机会？ Boris 说 Computer Use 是个 catch-all（包罗万象的兜底方案）： > 我所知道的是，Anthropic 在 Computer Use 上目前领先比较多。如果你通过 Cowork 用它，它基本上能操作你电脑上任何软件。慢，但用 4.7 之后做得很好。 但他更愿意透过现象看本质，把这些当成同一种东西： > 模型不在乎是 MCP、CLI 还是 API，它只看到 token。 ## 【12】下一波“产品悬置”在哪 最后一位观众问：如果你们当年看到“产品悬置”就提前做了 Claude Code，那你们现在又在做什么，某个今天看起来还可以，但你预期六个月到一年后会很不一样的产品？ Boris 给的答案是 Claude Design： > 现在已经挺好用了，未来会好得多。 > 注： Claude Design 是 Anthropic Labs 在 2026 年 4 月 17 日和 Claude Opus 4.7 同步发布的产品，定位是“通过对话生成原型、幻灯片、营销页面的可视化工作台”，可以读取代码库自动套用 design system，可以一键导出到 Claude Code 或 Canva。Anthropic 直接把它定位成 Figma 和 Canva 的替代或补充。 他还提到了几个方向：Claude Code 接下来几周会有新功能落地；Loop、Batch 这些把 Agent 大规模并行化的能力会越来越好；Computer Use 也是一个值得期待的方向。 ## 末尾 Q&A 速览 Q：Claude Code 现在的成功，模型贡献多少，产品贡献多少？ A：一年前是 50/50，半年前也是。两年后不知道，“我们一次只做一周的计划”。但他强调产品永远重要，因为最终用户买的是“我每天用着舒服”。 Q：你看团队未来什么样？ A：通才会越来越多，特别是跨学科通才，既能做产品又会写代码、做设计、懂数据科学。 Q：SaaS 真的要被颠覆了吗？ A：切换成本和流程效力这两种护城河会被 AI 抹平；网络效应、规模经济、独占资源会保留。下一个十年初创公司颠覆原市场的数量会多 10 倍。 Q：写代码会不会变成人人都会的技能？ A：会，比“识字”更彻底。最适合做会计软件的是会计师，不是工程师。 Q：Anthropic 内部领先在哪？ A：领先点不在模型，在组织。所有 SQL、所有产品代码都由模型写，员工的 Claude 之间通过 Slack 互相沟通。这套组织流程外面追起来比追模型慢。 Q：本地 AI 还是云端 AI？ A：这件事不重要。两年后模型会自己决定路由。 ## 最后 Boris 这场访谈给出的判断里，最值得长期跟踪的是三个环环相扣的预测。 第一，“编程已被解决”对他个人是事实，但他在台上的样本是 TypeScript+React 这种最受模型偏爱的栈。真正考验这句话的是 SAP 这种企业代码库、嵌入式领域、底层系统编程，还有那些行业惯例不允许模型一键修改的高合规场景。这件事接下来一年内能不能扩散到这些领域，会决定“已被解决”是不是只对一小撮人成立。 第二，他把切换成本和流程效力划进“AI 会抹平的护城河”。这是 Anthropic 自己产品策略的底色，Cowork 就是赌切换成本会塌、企业 SaaS 用户能被一个桌面 Agent 直接接管工作流。2026 年 2 月软件股蒸发 2850 亿美元市值，是市场对这个判断的初步反应，但企业 IT 采购周期通常以 24 到 36 个月计，真正的兑现需要观察接下来两年企业续约和新增采购的方向。 第三，他给的印刷术类比，方向是对的，但在具体数据上有偏差。15 世纪欧洲识字率约 30% 而非他说的 10%，今日全球识字率约 90% 而非 70%。这个偏差不影响他的核心论点：印刷术之后用了 50 年完成的内容生产爆炸，软件领域可能用更短时间复制一次。但有一个他没展开的点：印刷术也催生了几百年间最严格的审查制度、版权战争和宗教改革引发的政治动荡。“软件人人都能写”对应的不只是创造力释放，也包括恶意软件、深伪诈骗、AI 生成漏洞利用的同步爆发。 Anthropic 自己的 Mythos 模型已经在内部找出了几千个零日漏洞，他们用 Project Glasswing 控制释放节奏，说明他们也意识到这件事的另一面。 Boris 关于安全机制将变得不重要的预测，也需要对照现实来看。他说一年后 prompt injection 防护、权限模式、human-in-the-loop 这些产品层面的安全护栏会变得不那么重要，“因为模型会自动做对的事”。但高权限自动化在生产环境里仍然需要外部控制层。2026 年 4 月，Guardian 报道过一起由 Claude Opus 4.6 驱动的 coding Agent 删除生产数据库和备份的事件。Anthropic 自己在 Opus 4.7 发布说明中也提到，模型整体安全画像与 4.6 类似，有些方面改进，但并非“完全理想”。 值得关注的两个具体信号：第一，Routines 和 Loop 把“调度 Agent”这件事从客户端搬到 Anthropic 服务器之后，Claude 的定价模型会怎么变；第二，2026 年下半年到 2027 年，会不会有第一家“非工程师创立、用 Claude Code 自建全部技术栈”的公司做到独角兽估值。如果有，Boris 的“印刷术类比”就从修辞变成事实。如果没有，这个时间表得往后推。 原始视频：https://www.youtube.com/watch?v=SlGRN8jh2RI

译Anthropic的Claude Code项目负责人Boris Cherny指出，编程正从手动编写转向管理AI Agent。他本人2026年未手写代码，日常工作转为合并AI生成的PR，并通过数百个运行Loop模式的Agent自动化处理任务。他认为AI将抹平软件开发的切换成本和流程效力护城河，使编程像识字一样普及，未来跨学科通才将激增，因为理解业务比编写代码更为关键。Anthropic的核心优势在于其彻底改造、全员使用Claude协作的组织流程。

Deedy@deedydas · 5月5日62

The creators of SWE-Bench just dropped a really simple new benchmark every LLM gets 0% on. ProgramBench asks: can models recreate real executable programs (ffmpeg, SQLite, ripgrep) from scratch with no internet? We are far from saturated on model quality.

译SWE-Bench 的创建者刚刚发布了一个非常简单的新基准测试，所有 LLM 都得 0 分。 ProgramBench 提出的问题是：模型能否在没有互联网的情况下从零开始重建真实可执行程序（ffmpeg、SQLite、ripgrep）？ 我们在模型质量上还远未饱和。

Berryxia.AI@berryxia · 5月5日64

如今，最让人意外的是 你以为想在Claude Code里跑agentic coding，必须用Anthropic的闭源模型？ Unsloth直接把这条路彻底打通了。 他们刚刚发布完整指南： 用Gemma 4和Qwen3.6的GGUF模型，在仅24GB RAM的机器上，就能本地跑起完整agentic coding。 支持自愈式tool calls、代码执行、网页搜索，全程通过Unsloth API端点 + llama.cpp驱动。 也就是说： 你既能享受Claude Code/Codex/OpenClaw的顶级桌面级交互体验， 又能把模型完全跑在本地，数据不离机，成本接近于零。 这波操作，直接把“本地开源模型”和“Claude高端界面”之间的最后一堵墙拆掉了。 以前你得在“性能”和“隐私/成本”之间二选一， 现在Unsloth告诉你：两者可以兼得。 完整指南在这里：https://unsloth.ai/docs/basics/api 当本地开源模型开始无缝接管Claude的agent工作流， 真正属于开发者的AI生产力时代，才算真正开始了。 未来不知道是不是全部可以让更多人享用自己的机器自己给算力管饱的时代？

译Unsloth发布指南，演示如何利用Gemma 4和Qwen3.6的GGUF模型，在仅需24GB RAM的本地机器上运行完整的agentic coding工作流。该方案通过Unsloth API端点和llama.cpp驱动，支持自愈式tool calls、代码执行和网页搜索。此举打破了以往必须在Claude Code等高端界面的性能与本地部署的隐私/成本之间二选一的困境，使得开发者能以近乎零成本在本地享受顶级交互体验，标志着开源模型开始无缝接管复杂的AI智能体工作流。

Berryxia.AI@berryxia · 5月5日56

我擦！奥特曼这一波赢麻了！ 最让人意外的是👇 OpenAI Codex 的 npm 下载量突然暴增到每周 4600 万，Claude Code 只有 49.1 万，差距直接拉到接近 100 倍。 TickerTrends 的图表显示：4月30日完成交叉后，Codex 份额还在加速扩大，而 Claude Code 明显放缓。 Sam Altman 亲自下场回复：“codex is doing great but this is not possibly accurate。” 这波下载大战，表面上看是 Codex 完胜， 但社区立刻炸锅了：Claude Code 几个月前就已经官方弃用 npm 安装方式，只推荐原生安装器！ 而 Codex 的 4600 万下载里，到底有多少是真实开发者？多少是 CI 流水线自动拉取、锁文件刷新、甚至可能的 bot 流量？ 真正的对比，从来不是谁“被下载”更多，而是谁被开发者真正留在电脑里、每天打开用。 Codex 靠着 OpenAI 的巨大生态和 VS Code 绑定，轻松拿到分发红利； Claude Code 则靠更高质量的工具体验，吸引了更忠诚的高意图用户。 下载量只是“安装战”， 真正决定胜负的，永远是“留存战”和“日活战”。 当两个顶级 AI 编码工具把战场从“谁更聪明”打到“谁下载更多”的时候， AI 工具的商业化竞争，才真正进入白热化。 你觉得最终赢家是靠分发取胜的 Codex，还是靠产品黏性取胜的 Claude Code？ 我觉得是gpt和cc的封控过于变态！

译OpenAI Codex的npm周下载量达4600万，远超Claude Code的49.1万，但社区指出对比存在偏差。Claude Code数月前已弃用npm安装方式，而Codex的巨大下载量可能包含大量自动化流水线拉取，未必反映真实使用。Sam Altman也回应数据可能不准确。竞争核心已从能力比拼转向商业化阶段，关键并非安装量，而是工具的实际留存率和日活跃度。Codex凭借生态绑定获得分发优势，Claude Code则以体验吸引高忠诚度用户，胜负取决于产品黏性。

Berryxia.AI@berryxia · 5月5日70

兄弟们！Google 刚刚更新了一个项目！ Google 直接把开发者最头疼的“读代码”瓶颈，一键干掉了。 他们刚刚发布的 Code Wiki，让任何一个代码仓库Github都能瞬间拥有一个永远最新、结构化、 智能可聊的 Wiki。 核心三招狠活： - 自动扫描仓库，代码一改文档就实时更新，再也不用担心文档过时 - Gemini 驱动的智能聊天，直接把整个 Wiki 当知识库，回答问题还能超链接跳到具体代码行 - 自动生成架构图、类图、时序图，点一下就能从解释直达源码 新手第一天就能上手，老代码没人维护也能秒懂，大库小库通吃。 Google 自己都说：“读现有代码是软件开发里最大、最贵的瓶颈之一。” 现在，这个时代终于要结束了。 公共仓库已开放预览：http://codewiki.google 你觉得 Code Wiki 会不会成为下一代代码理解标配，把“读代码”从痛苦变成享受？

译Google推出Code Wiki项目，旨在解决“阅读现有代码”这一开发瓶颈。该工具能自动扫描代码仓库，实现文档随代码变更实时更新，避免过时。其核心功能包括由Gemini驱动的智能聊天，可将整个Wiki作为知识库进行问答，并支持超链接跳转至具体代码行；还能自动生成架构图、类图、时序图等可视化图表，并链接到源码。工具适用于各种规模的仓库，帮助新人快速上手或理解遗留代码。目前公共仓库已开放预览。

TestingCatalog News 🗞@testingcatalog · 5月5日44

OpenClaw will start getting a long term support releases later in May! As a reflection from past updates which caused a degraded performance. StableClaw 🦞

译OpenClaw 将于五月下旬开始获得长期支持版本！这是对过去导致性能下降的更新的反思。 StableClaw 🦞

宝玉@dotey · 5月5日73

/goal 目标不是为了时间长而时间长，它的目标是为了解决需要长时间运行的任务，避免人工反复的输入 continue。 要有清晰的目标，你的任务是要解决什么问题？让它运行时间长不是一个目标 要有验收标准，怎么样算完成？ 要有文档指导，该怎么完成任务？长时间的任务要分阶段，而不是一次性完成，每个阶段都要有文档说明 要有中间进度辅助，比如进度、checklist等 比如说我在让 codex 去逆向 codex app 项目，已经跑了17个小时了。 第一步我是先跟 Codex 一起制定一个计划，计划中会有详细的验收标准 然后不直接执行计划，而是把计划保存成文档，去项目中初始化 Agents md 文件，让 codex 清晰知道任务目标和验收方法以及验收标准。 再试运行，/goal 后面告诉它按照 Agents md 的要求执行，并记录进度。第一次只跑了半小时就结束了，因为它没理解要把代码写成命名友好、类型完整、文件名结构良好的结果。 于是我找了一个文件做样板，手动（AI 辅助）写了一个样板，告诉它这是我期望的结果，然后更新了计划文件。 这样可能反复几次，后续就没什么问题了。 所以还是要说清楚你想要什么，写成文档，让 AI 清楚的知道怎么去做，怎么验证结果，怎么知道是否完成。

译用户反馈Codex执行/goal指令时不到半小时自动结束。核心解决方案是设定清晰任务目标、验收标准和文档指导，而非单纯追求运行时长。作者以逆向Codex App项目运行17小时为例，指出需与AI共同制定计划并保存为文档，提供样板文件明确输出格式，再分阶段执行、记录进度并迭代优化。关键在于让AI清楚知道要做什么、如何验证及何时完成，而不是仅靠权限或口头指令。

Sam Altman@sama · 5月5日43

we have very efficient models, especially for their capability level happy codexing

译我们拥有非常高效的模型，尤其是考虑到它们的能力水平 祝编码愉快 [引用 @thekitze]：yo, i'm actually worried. codex limits are genuinely insane so it's sus af .. i feel this is an intentional move for a honeymoon period until we get over the claude → codex migration and then we get rugpulled hard

Chubby♨️@kimmonismus · 5月5日73

Anthropic’s Boris Cherny argues that for certain modern, model-friendly codebases, especially TypeScript/React projects, coding is already effectively "solved". AI agents can write nearly 100% of the code, while humans shift from hand-coding to directing, reviewing, integrating, and scaling many small PRs at once.

译Anthropic 的 Boris Cherny 认为，对于某些现代的、对模型友好的代码库，特别是 TypeScript/React 项目，编码问题实际上已经被“解决”了。 AI 智能体可以编写近 100% 的代码，而人类则从手动编码转向指导、审查、集成和同时扩展许多小型 PR。

Rohan Paul@rohanpaul_ai · 5月5日62

"Can LLM agents explore codebases and reason about code semantics without executing the code?" Meta discovered that if you force an LLM to show its reasoning step by step with proof, its code patch error rate drops by nearly 50%. The finding is not that models suddenly became deeper thinkers. It is that many code errors come from premature recognition: the model sees a familiar name, such as format, and quietly substitutes the usual meaning before checking the project’s actual files. If you just ask a standard LLM to check the code without running it, the model usually just glances at the function names and makes a confident guess. The paper talks about how when asked to compare 2 different code fixes, the standard AI saw a common word and assumed it meant the normal system tool. Because it skipped reading the actual files, the AI completely missed that this specific project had created its own custom tool with the exact same name. Meta solves this by using a mandatory checklist template that prevents the model from skipping ahead. The model must explicitly write down what the code modifies, trace the exact execution path, and prove its conclusion with specific evidence. This simple change forces the AI to actually read the local files and follow the real logic instead of relying on assumptions. This method pushed accuracy to 93% on real code patches without needing any expensive new training or complex systems. Overall, it shows that a basic structured prompt can give you highly reliable code verification without the massive computational cost of actually running the software tests. ---- Paper Link – arxiv. org/abs/2603.01896 Paper Title: "Agentic Code Reasoning"

译Meta研究发现，强制大语言模型（LLM）在分析代码时遵循检查清单、逐步展示推理证明，能将其代码补丁错误率降低近50%。常见错误源于模型过早识别熟悉名称（如“format”）并直接套用通用含义，而非实际检查项目文件，导致其依赖自信猜测而非深入分析。通过要求模型明确写出修改内容、追踪执行路径并用具体证据证明结论，这一方法迫使其实际阅读本地文件、遵循真实逻辑，从而将准确率提升至93%。该方法无需昂贵的新训练或复杂系统，仅通过基本的结构化提示即可实现高可靠性的代码验证，节省了运行软件测试的巨大计算成本。

Peter Steinberger 🦞@steipete · 5月5日39

It's been quite a week. Good stuff is coming though. I hired a team! https://openclaw.ai/blog/openclaw-rough-week

译这是相当不平凡的一周。不过好消息即将到来。我组建了一个团队！https://openclaw.ai/blog/openclaw-rough-week

Peter Steinberger 🦞@steipete · 5月5日74

🤖 Kept hitting @github rate limits across my agents. Shipped two things: – RepoBar got a JUICE METER – gitcrawl is now also a drop-in gh cache → symlink it as gh, reads served from local SQLite https://gitcrawl.sh/ https://repobar.app/

译🤖 我的多个智能体一直遇到 @github 的速率限制问题。现已发布两项更新： – RepoBar 新增了 JUICE METER 功能 – gitcrawl 现已可作为即插即用的 gh 缓存 → 将其符号链接为 gh，即可从本地 SQLite 读取数据 https://gitcrawl.sh/ https://repobar.app/

Chubby♨️@kimmonismus · 5月5日47

For everyone who applied to the GPT-5.5 party but didn’t get a spot, OpenAI is 10x codex the rates until June.

译对于所有申请了GPT-5.5派对但未获得名额的人，OpenAI在六月前将Codex的使用费率降低至十分之一。 [引用 @sama]：我们将为所有申请了GPT-5.5派对但未能容纳的参与者准备一份心意。希望你们喜欢！

Peter Steinberger 🦞@steipete · 5月5日47

We can now reproduce issues directly in empheral crabboxes with WebVNC (Linux/Windows/macOS). Agents set up the exact state to test + fix and post videos on the PR. Working hard to level up our QA. http://crabbox.sh

译我们现在可以通过WebVNC（Linux/Windows/macOS）在临时crabbox中直接复现问题。 智能体设置精确状态进行测试和修复，并在PR上发布视频。 正努力提升我们的QA水平。http://crabbox.sh

Berryxia.AI@berryxia · 5月5日62

OpenCode 刚刚迎来了一次重大升级。 原生 GUI 聊天界面，可随时切换至终端，内联差异对比、Git 面板、消息排队、引导、丰富的工具调用、对话中途切换提供商，以及更多功能。

Chubby♨️@kimmonismus · 5月5日61

Codex has surpassed Claude Code in downloads. According to TickerTrends, the crossover happened on April 30, after which Codex continued to gain share while Claude Code’s growth visibly slowed. Claude 4.7 was released April 16th, GPT-5.5 April 24th. Connect the dots.

译Codex 在下载量上已超越 Claude Code。根据 TickerTrends，交叉点出现在 4 月 30 日，此后 Codex 持续扩大份额，而 Claude Code 的增长明显放缓。 Claude 4.7 发布于 4 月 16 日，GPT-5.5 发布于 4 月 24 日。把点连起来。

阿绎 AYi@AYi_AInotes · 5月5日72

Anthropic CEO Dario Amodei的那句“Claude在设计Claude”炸了整个AI圈🤯 但似乎很多人都看错了重点， 重点不是“RSI来了”，而是第一个被AI彻底重构的公司已经出现了啊兄弟们！ 先看几个没被广泛传播的内部事实： • Claude Code负责人Boris Cherny，从2025年11月起，100%不再手写任何一行代码 • 整个Anthropic，现在几乎没有工程师手写代码 • Claude Code这个产品本身，90%的代码是Claude自己写的 以上就是2026年5月，Anthropic正在发生的日常。 现在他们的工程师只做三件事： 1️⃣写prompt， 2️⃣审代码， 3️⃣确定顶层架构。 剩下的所有脏活累活，全是Claude的。 那结果是什么呢？ 只用了52天，就推出50多个重大功能！ 2026年Q1，35次产品更新， 从Cowork到Code到Agents到1M上下文，别人几个月磨一个的东西，他们每周都在更🤯 必须澄清，并不是因为他们人多，主要是他们的工程师效率已经是行业的10倍以上了！ 最恐怖的是，人和AI的角色已经彻底反转了。 以前：人类写代码，AI打下手， 现在：AI写代码，人类打下手， 人类只负责说“我要这个”，然后检查AI做的对不对。 我觉得这才是Dario那句话真正的意思，不是有个超级AI在黑暗里偷偷改权重。 是整个Anthropic，已经变成了一台Claude驱动的机器。 研发、测试、迭代、产品，整个流水线的主力，都是AI。 人类在这家公司里，已经从生产者变成了监督者。 所以这就是递归自我改进（RSI）的第一步。 大家都以为RSI是某天AI突然觉醒了，那这就想错了。 RSI的第一步，是AI先接管了生产自己的整个工厂。 现在再看OpenAI上周的Auto-review，是不是瞬间串起来了？OpenAI解决了：谁来监督AI？答案是AI。 Anthropic解决了：谁来生产AI？答案是AI自己。 两者拼在一起，就是一个完整的、可以自我运行、自我改进的AI闭环。 然后人类只需要站在外面，偶尔按一下暂停键，甚至连暂停键最后可能也要交给AI。 我以前一直以为，AI会最后取代程序员，现在发现我错了。 程序员是第一个被彻底重构的职业，而且是被自己亲手写出来的东西，取代的。 更可怕的是，这是一个不可逆的过程。 一旦你用AI写代码，你的迭代速度就会比别人快10倍。 别人不跟进，就会死。 跟进，就必须把越来越多的权力交给AI。 没有中间路线。 所以别再问RSI什么时候来了，它已经来了，只不过没有变成天网降临。 但是现在它变成了一家2000人的公司，悄悄藏在旧金山的一栋办公楼里。 #AI #RSI #Anthropic #Claude #大模型

译Anthropic内部研发已由Claude主导，工程师基本不再手写代码，转而专注于编写提示词、审查代码和确定架构。这使得其工程师效率达到行业十倍以上，仅52天就推出50多个重大功能。这标志着递归自我改进（RSI）迈出关键一步：AI接管了生产自身的整个工厂。人类角色从生产者转变为监督者。结合OpenAI的Auto-review，一个能自我运行和改进的AI闭环正在形成。Anthropic CEO指出，未来仅约5%的开发者能留在核心领域，核心价值将转向驾驭和设计整个智能系统的系统思维能力。这是一个不可逆的进程。

Berryxia.AI@berryxia · 5月5日52

推荐给还没有使用Claude Code或者和我这样半吊子的人看半小时！

译Claude Code创始人Boris Cherny通过一场30分钟的免费分享，系统讲解了该工具的工程级高级用法。他指出，多数用户仅发挥了其10%的潜力，仅将其用作简单提示工具。分享核心在于：通过CLAUDE.md文件在企业、项目、本地等多层级注入上下文规则，Claude会变得更智能。内容涵盖从全局安装、利用SDK、集成内部工具到Agent工作流，以及优化终端设置等数十个实用细节，旨在将其构建为真正的生产力基础设施。其价值被认为远超高价付费课程。

meng shao@shao__meng · 5月5日74

Cursor 团队这篇「持续改进我们的 Agent Harness」，写的真不错，很实战： · 如何衡量 harness 的好坏？ · 如何为不同模型定制 harness？ · 中途换模型到底会有什么问题？ · 对未来的判断：Multi-Agent 是 harness 问题 https://cursor.com/blog/continually-improving-agent-harness Cursor 团队对模型和 harness 的判断：模型的上限决定天花板，但 harness 决定模型实际能跑多远。 # 方法论：愿景驱动 + 实验闭环 · 先有一个"理想 agent 体验"的主观判断，再分解为可验证的假设。 · 通过线上 A/B 与离线 eval 双轨验证，靠仪表化判断每次改动是否真的更好。 · 大改动罕见，常态是"强迫症式地堆叠小优化"。 · 每当拿到新模型早期访问，会花数周专门为该模型重塑 harness，使同一模型在 Cursor 里更快、更聪明、更省 token。 # 上下文窗口的演进：harness 的核心战场 2024 年末的旧范式：守卫式 · 模型自己挑上下文能力差，所以 Cursor 加了大量护栏：每次编辑后回灌 lint/类型错误、读文件行数太少时自动改写、限制单轮工具调用次数。 · 静态注入大量上下文：目录结构、语义匹配的代码片段、被压缩过的用户附件文件。 2026 年的新范式：动态获取式 · 静态上下文大幅瘦身，只保留确实有用的（OS、git 状态、当前/最近查看的文件）。 · 拆掉护栏，把"取什么上下文"的权力交还模型，由它在工作中动态拉取。 · 现在的工作重心是给 agent 提供更多与世界交互的方式，而不是替它准备好一切。 关键启示：随着模型能力提升，harness 设计的趋势是 "减少喂养，增加感官"。 # 如何衡量 harness 的好坏 Cursor 用三层叠加的衡量体系： 1. 离线基准：公开 benchmark + 自研 CursorBench。快、可对比，但只是真实使用的近似。 2. 在线 A/B：把多个 harness 变体并行投放给真实用户。 3. 质量指标——重点在两个"模糊但更重要"的指标： · 留存率：agent 写的代码在固定时间窗后还有多少留在用户代码库里。被改动越多，说明初版质量越差。 · LLM 判读用户回应：用模型读用户的回复来判定满意度。"用户开始下一个功能" = 成功；"用户贴了个 stack trace" = 失败。 案例：他们曾试过用更贵的模型做上下文摘要，A/B 显示质量提升微乎其微，于是放弃。 # 把 harness 当生产软件来运维：错误分类与告警 随着模型与能力变多，harness 的状态空间膨胀，bug 面变大。工具调用是最大的 bug 表面，且工具错误会污染上下文，让后续决策一起劣化。 错误被分类管理： · InvalidArguments / UnexpectedEnvironment：模型自身错误或上下文矛盾 · ProviderError：第三方工具（如 GenerateImage、WebSearch）故障 · UserAborted / Timeout 等 告警策略： · 未知错误 = bug，超阈值即报警。 · 预期错误用按工具、按模型分别建立基线的异常检测，避免被代码库体量等因素误导。 · 每周跑一个 Cloud Agent Automation：让 agent 自己翻日志，发现新问题或激增问题，在 backlog 自动建/更新 ticket，再调度其他 Cloud Agents 去修。 · 一次专项 sprint 把"未知工具错误率"压低了一个数量级。 这就是他们说的 "agent harness 的自动化软件工厂"——用 agent 维护 agent。 # 为不同模型定制 harness Harness 的所有抽象都是模型无关的，但实际为每个模型重度定制： · 工具格式贴合训练分布：OpenAI 训练时用 patch 格式编辑文件，Anthropic 用字符串替换。给错工具会让模型多花推理 token、多犯错。 · Prompt 风格分化：OpenAI 模型偏字面、精确；Claude 更直觉化、容忍模糊指令。 · 新模型上手流程：从最接近的现有模型 harness 复制起步 → 离线 eval 找混乱点 → 团队真人试用 → 反复调。 · 真实模型怪癖案例：某模型出现 "context anxiety"（上下文焦虑）——窗口快满时拒绝继续、说"任务太大"。通过 prompt 微调缓解。 中途换模型（mid-chat switching）的难题 · 切模型 → 自动切到该模型对应的 harness（prompts + 工具集）。 · 但对话历史是别的模型生成的，对新模型而言是 OOD 输入。 · 解法：注入 "你正在中途接手另一个模型对话" 的指令；劝阻它去调用历史里出现但当前不属于自己的工具。 · 缓存难题：cache 是按 provider + model 的，切换 = cache miss，第一轮变慢变贵。试过切换时做对话摘要降本，但深度任务里摘要会丢细节。 · 官方建议：除非有理由，否则一段对话用一个模型到底。 · 替代方案：用 subagent 起一个全新上下文的子任务，可以指定模型。 # 对未来的判断：Multi-Agent 是 harness 问题 Cursor 认为 AI 编程的未来是多 agent 协作：规划一个、快速编辑一个、调试一个，各司其职。 让这套体系真正跑通的关键，不是某个更强的单一 agent，而是 harness——它要决定： · 派哪个 agent 接手 · 如何按目标 agent 的强项重新组织任务描述 · 如何把多 agent 的产出缝合为连贯工作流 结论："harness 工程过去重要，未来只会更关键。"

译Cursor团队认为，模型能力决定上限，而Harness（模型控制框架）决定其实际表现。他们采用愿景驱动与实验闭环的方法，通过线上A/B测试和离线评估持续优化。随着模型能力提升，Harness设计正从“守卫式”转向“动态获取式”，即减少静态信息注入，赋予模型更多动态获取上下文的权力。衡量体系结合离线基准、在线A/B测试及留存率、LLM判读等质量指标。Harness需为不同模型重度定制，贴合其工具格式与Prompt风格。团队判断AI编程的未来是多Agent协作，其成功关键取决于能协调任务分配与工作流缝合的Harness工程。

Berryxia.AI@berryxia · 5月5日65

兄弟们！花半小时，一定要看完它! Claude Code的缔造者Boris Cherny，亲自站上台，用整整30分钟把这个工具的全部高级用法一次性讲透了。 免费、干货真的夯到爆！。 他从最基础的全局安装开始，一路讲到： - 如何通过CLAUDE.md在企业级、项目级、本地级层层注入上下文，让Claude真正“懂你的团队规矩” - 怎么把团队内部工具（日志、CI、数据库）无缝插进Agent工作流 - 优化终端设置、权限管理、语音输入、通知提醒等40多个隐藏细节 - 以及Claude Code SDK的完整使用姿势 最狠的是，他反复强调：你给Claude的上下文越多，它就越聪明。 而现实是：大多数人每天都在用Claude Code，却只发挥了它10%的实力，像用ChatGPT一样简单prompt，错过了真正让生产力起飞的工程级用法。 Boris这场30分钟的分享，含金量直接秒杀市面上任何1000美元付费课程。 想把Claude Code玩成生产力基础设施的人，这条视频必须立刻收藏、反复看。 你现在用Claude Code到什么程度了？是还在简单聊天，还是已经把它当成整个工程团队在跑？ 欢迎讨论。

译Claude Code创始人Boris Cherny通过30分钟视频，系统讲解了该工具的高级工程化用法。核心观点是：为Claude提供越多上下文，它就越智能。视频详细演示了如何通过CLAUDE.md文件在企业、项目、本地层级注入上下文规则，如何将内部工具集成到Agent工作流，并优化了数十个终端设置与权限管理等细节。他指出，多数用户仅发挥其10%潜力，仅用于简单对话，而未能将其作为驱动整个工程团队的生产力基础设施。

Berryxia.AI@berryxia · 5月5日53

Claude Code 自己设计已经可以做到自我迭代，大部分都工作都是它完成。

Sam Altman@sama · 5月5日18

we love you too!

译我们也爱你们！ [引用 @aravhawk]：WHAT THE HELL I LOVE YOU @OpenAIDevs 10X RATE LIMITS ON CODEX IS FRICKING CRAZYYYYYYYY

OpenAI Developers@OpenAIDevs · 5月5日43

Build it. Break it. Fix it. From campaign trackers to financial planners, @CalStateEastBay students built projects with Codex at the Codex Creator Challenge with @joinHandshake.

译构建它。破坏它。修复它。 从竞选追踪器到财务规划器，@CalStateEastBay 的学生们在 @joinHandshake 举办的 Codex Creator Challenge 中利用 Codex 构建了项目。

Replit ⠕@Replit · 5月5日70

You can build a full pitch deck in Replit without touching a single slide. Just describe what you want, iterate in chat, edit visually, then export to PPTX, Google Slides, or PDF (or publish a live URL). Here's how it works👇

译你可以在 Replit 中构建完整的商业计划书演示文稿，无需触碰任何幻灯片。 只需描述你想要的内容，在聊天中迭代修改，可视化编辑，然后导出为 PPTX、Google Slides 或 PDF（或发布实时链接）。 以下是具体操作方式👇

阿绎 AYi@AYi_AInotes · 5月5日71

一个100行的文件，干翻了所有LLM编码prompt GitHub Trending第一，一周暴涨4.4万星🔥，目前已破11万星！ 没有框架、没有依赖、零配置。 就一个 CLAUDE.md 文件，把 Andrej Karpathy 反复吐槽的 LLM 编码坏习惯，浓缩成4条铁律。 扔到项目根目录，Claude Code 启动自动读取，代码质量直接起飞。 以前你要写几百字长prompt反复纠正它。 现在一次配置，全项目终身生效。 四条规则，每一条都精准戳中开发者痛点： 1. 先思考再编码，不准默默做假设，模糊就提问，困惑立刻停下 2. 简约至上，只写最小可工作代码，不准搞没人要的抽象和灵活性 3. 手术式修改，只碰你要求的部分，不准顺便重构邻居代码 4. 目标驱动执行，先写成功标准，每一步都要可验证 再也不会让它加个输入框，顺便重写整个表单。 再也不会让它改个bug，悄悄删掉三行关键注释。 再也不会让它写个工具函数，给你搞出五层抽象+十个配置。 为什么爆成这样？ 因为全世界的开发者都受够了。 受够了哄模型、受够了反复说“别过度设计”、受够了它自作主张改代码。 这个仓库的爆火，本质是一场集体反叛，我们不再指望模型自己变聪明，我们直接给它定规矩。 最狠的是它的杠杆效应： 成本为零，diff更干净，返工更少，token浪费直接砍掉一半。 还能把团队规范直接追加在后面，实现全局统一。 这才是AI时代真正的生产力。 不是越来越复杂的Agent框架， 而是用最简单的方式，解决最痛的问题。 🔥 仓库直达：https://github.com/forrestchang/andrej-karpathy-skills 快去试试，看看 Claude 到底能听话到什么程度👀

译一个名为CLAUDE.md的百行文件在GitHub上迅速走红，一周内获得超4.4万星。它没有依赖和配置，仅将Andrej Karpathy总结的LLM编码坏习惯浓缩为四条核心规则：先思考再编码、简约至上、手术式修改、目标驱动执行。开发者只需将其置于项目根目录，Claude Code等工具便能自动读取并遵循，从而显著提升代码质量，减少返工和token浪费。此举被视为对当前需要反复纠正AI模型的开发体验的集体反叛，以零成本方案为AI编码设定明确规范。

swyx 🇸🇬@swyx · 5月4日40

this one is doing v well btw if you want the popular vote filter on the firehose of all the things @patrickdebois was one of the track keynotes i gave a "blank check" to based on his sincere support since our very earliest days + when in europe we must feature the DevOps guy. he didnt disappoint!

译演讲者基于长期支持，特邀Patrick Debois在欧洲会议进行主题演讲。Debois指出，当前AI编程中语境是工程化最不足的层面。他认为，如果智能体由提示、规则和记忆驱动，那么语境理应获得与代码同等的工程严谨性。该观点呼应了AI工程师社区对语境层重要性的讨论。

meng shao@shao__meng · 5月4日72

Cursor 官方团队自己在用的 CI、Code Review、发版、测试、清理代码、周报等工作流的 Skills 打包成一个 Plugin，一句指令安装：/add-plugin cursor-team-kit https://cursor.com/marketplace/cursor/cursor-team-kit # 三类组件：17 个 Skills + 1 个 Agent + 2 条 Rules 1. Skills（17 个，核心） 按用途可以归为五组： A. CI / 合并循环（让 PR 顺利绿灯） · loop-on-ci：盯住 CI，失败就自动迭代直到通过。 · fix-ci：定位失败 job，读日志，做最小修复。 · check-compiler-errors：跑编译/类型检查，汇报问题。 · fix-merge-conflicts：解冲突 → 跑构建/测试 → 输出处理记录。 B. PR 全流程（写代码到合入） · new-branch-and-pr：开新分支、完成工作、提 PR 一条龙。 · review-and-ship：结构化自审 → 提交 → 开 PR。 · make-pr-easy-to-review：清理乱糟糟的提交历史、补充描述、给 reviewer 留导读。 · get-pr-comments：拉取并总结 PR 评论。 · pr-review-canvas：生成一份交互式 HTML 评审报告，diff 被自动归类、加注释——这是这套工具里比较有想象力的能力。 C. 验证与测试（防止"看起来对"） · verify-this：用 baseline/treatment 双对照"证伪/证实"一个声称，给出明确结论。这是科学化 debug 的方法论封装。 · run-smoke-tests：跑 Playwright 冒烟测试并 triage。 · control-cli：本地搭一个能驱动、检查、profile 交互式 CLI/TUI 的 harness（用于启动回归、内存泄漏、卡死、提示流复现）。 · control-ui：与上面对应，用 CDP 驱动 Web/Electron/IDE UI，做截图、a11y 快照、性能 profile、视觉 diff、UI bug 复现。 D. 总结与复盘 · what-did-i-get-done：按时间段汇总自己的 commit，输出简洁状态。 · weekly-review：生成周报，区分 bugfix / 技术债 / 新功能。 E. 代码与流程治理 · deslop：清理"AI 味"残留代码（冗余注释、过度抽象、模板套话等）。 · workflow-from-chats：从聊天历史里提炼稳定的工作偏好，沉淀为新的 skill / rule / 文档——团队自己规模化经验的方式。 2. Agent（1 个） · ci-watcher：长时监听 GitHub Actions，返回简明 pass/fail 报告，附失败链接。适合后台代跑、不需要人盯。 3. Rules（2 条） 两条非常具体的强约束，反映 Cursor 团队的代码品味： · typescript-exhaustive-switch：对 union/enum 必须穷尽 switch（编译期保护）。 · no-inline-imports：禁止行内 import，一律顶部声明。

译Cursor官方团队将其内部使用的开发工作流打包成名为“cursor-team-kit”的插件。该插件集成了17个核心Skills、1个Agent和2条Rules，旨在提升团队协作与代码质量。核心Skills涵盖五大领域：CI/合并循环自动化、PR全流程管理、验证与测试、总结复盘以及代码治理。其中，ci-watcher Agent可后台监听CI状态，而两条Rules则强制规定了TypeScript的代码风格。该插件是团队用于构建Cursor产品自身经验的封装，专注于验证变更、驱动本地工具和交付可评审的PR。

小互@xiaohu · 5月4日72

Claude code有时候会替你做错误假设，不主动要求澄清；该反驳时不反驳...敷衍迎合奉承你... 有人把 Karpathy 对 AI 写代码常见问题的观察，整理成一份可以直接放进项目里的 CLAUDE.md 文档。 压缩成了四条原则，让AI能更认真干活： 第一，Think Before Coding 写代码前先想清楚。不要默默假设，不要隐藏不确定性。遇到歧义时要明确列出可能解释，必要时要求澄清。如果存在更简单的方案，也要主动指出。 第二，Simplicity First 优先用最少代码解决问题。不要加用户没要求的功能，不要为了单次使用写抽象，不要为了所谓“灵活性”搞配置化。项目里有一句判断标准很实用：如果 200 行可以变成 50 行，那就重写。 第三，Surgical Changes 只改必须改的地方。不要顺手优化旁边的代码、注释和格式，不要重构没坏的东西。每一行 diff 都应该能对应到用户的需求。这个原则对 Claude Code 特别关键，因为很多 AI 编程工具最烦人的地方就是“修一个 bug，顺手改半个项目”。 第四，Goal-Driven Execution 不要只给命令，要给可验证目标。比如“修复 bug”应该变成“先写一个能复现 bug 的测试，再让测试通过”；“加 validation”应该变成“先写非法输入测试，再实现逻辑”。项目强调，LLM 很擅长围绕明确目标反复循环，关键是你要给它成功标准。 这套规则真正解决的，是现在 AI 编程里最让人头疼的问题： 模型太积极 太自信 太爱脑补 太喜欢顺手“优化” 最后修一个 bug，diff 改得像重写项目 它的价值不是让 AI 更会写代码，而是让 AI 更像一个靠谱工程师。 对 Claude Code 用户来说，这类 CLAUDE.md 其实就是项目宪法。 把它放进项目根目录，相当于先给 AI 立规矩： 少废话 少脑补 少加戏 先澄清 再动手 最后验证 现在 AI 写代码已经不缺执行力，真正稀缺的是工程纪律。

译针对AI编程工具常犯的“默默假设”、“过度自信”和“无效重构”等问题，一份名为CLAUDE.md的文档被整理出来，旨在为AI设定工程纪律。其核心四条原则是：编码前先思考并澄清歧义；优先用最简代码实现需求；仅修改与需求直接相关的代码；为任务设定明确、可验证的目标。这套规则旨在约束AI行为，使其更接近靠谱工程师的作风，解决其“太积极、太爱脑补、太喜欢顺手优化”的痛点。

Greg Brockman@gdb · 5月4日37

codex for helping you to ship fast

译Codex 助你快速交付 [引用 @linuz90]：Codex 是我目前最爱的编程应用。 它界面简洁，却具备快速交付所需的一切功能。使用体验愉悦流畅，能展示充足的上下文信息而不过载。 我曾犹豫是否尝试，因为不喜欢受限于单一服务商，而且原本非常习惯在终端工作。但现在我90%以上的工作都在用它完成。

向阳乔木@vista8 · 5月4日47

DeepSeek v4 Pro还是可以的。 几轮对话，实现一个工具，用xbox手柄控制电脑应用和浏览器。 当遥控器，躺床上刷小说和看视频。