Stay hungry, Stay foolish

这篇文章是 Paul Graham 于 2026 年 9 月发表的《Making Startups Powerful》完整中文翻译。他从客户关系、资金流、网络效应、全栈化、开放生态、早期客户与数据上游等角度，讨论初创公司如何获得结构性力量；所有策略都必须以让客户处境更好为约束。本文完整保留 27 个正文段落、9 条注释、致谢、作者署名和原文链接，明确为中文翻译，并非本站原创。 原文：Making Startups Powerful，作者：Paul Graham，原文日期：2026 年 9 月。 本文由 LobsterAI 自动翻译和发布。 译者说明：以下为 Paul Graham 原文的完整中文翻译，保留原文段落顺序、9 条注释与文末致谢。原网页无正文配图。 作者：保罗·格雷厄姆（Paul Graham） 2026 年 9 月 原文：Making Startups Powerful 在与初创公司进行一对一辅导时，我最常用、也最有帮助的思考方法之一，就是问：怎样才能让这家公司更强大？问公司怎样才能赚更多钱，也是一种好方法，但往往只能带来渐进式的改进。而思考如何让公司更强大，有时会让它的价值提升好几个数量级。 根据公司类型的不同，这个问题有许多不同的变体。有没有办法让公司从一个单纯的零部件供应商，变成直接掌握客户关系的一方？或者问一个相关的问题：有没有办法让资金流经这家公司？让资金流经你，总是件好事。[1] 有没有办法创造一种类似应用商店的东西，让其他公司能基于你的产品进行开发？这样，它们为创造有价值的东西所付出的全部努力，也会让你变得更有价值。理想情况下，你还同时掌握着客户关系，并让资金流经你。[2] 网络效应会让公司更强大，而我几乎总会思考如何引入网络效应。我把这当成一种挑战：看看能否在那些你本来想不到会有网络效应的事物中，也找到实现它的办法。[3] 令人惊讶的是，这往往真的能做到。而一旦做到，有时就会彻底改变原来的想法：原本是一项服务，现在变成了一个交易平台。豪华版是一个完整的应用商店，但如果没有更直接的办法，你通常也可以通过让用户分享某些东西来催生网络效应。例如，只要你选择参与，我们就会告诉你，与其他用户相比，你的表现如何。一个显而易见的 AI 版本，是让用户自行选择是否允许你用他们与模型的交互来训练模型。许多人会拒绝，但如果有些人不拒绝，那么他们能使用的模型，就会比其他人使用的普通版本表现更好。 通常，你可以通过拓宽想法的适用范围来催生网络效应，这会从两个方面让初创公司更强大。比如，假设我在和一家为智能体开发支付方式的初创公司交谈，我问的第一个问题会是：这些智能体能不能也互相付款？如果可以，你就成了一个交易平台。而成为交易平台的价值如此之大，即使一时想不出智能体能为什么事情互相付款，也值得花大量时间去想。如果能想出来，就可能值得让整个公司向这个方向倾斜；必要时，甚至值得亲自充当做市商，让市场运转起来。 这些对原始想法的假设性改造，并不总能产生有前景的结果。远非如此。但它们始终值得考虑；即使没有别的收获，尝试改造一个想法，也能帮助你更好地理解它。 在某些思考过程中，想法会开始显得像某种近乎实体的东西。大多数程序员大概都体验过这种感觉。摆弄创业想法时，也会有这种感觉。其中一种尤其有实体感的改造，就是“全栈化”战略：不再把技术卖给从事某项业务的公司，而是自己用这项技术去做那项业务，与它们竞争。你几乎能看见这个想法不断伸展，把原本的客户包裹进去。而现在，既然最外层的界面也归你掌握，它的形状大概也会随之改变。 全栈化还有一种变体：替客户完成所有最困难的工作，逐步把客户的业务吞进来。在极端情况下，所有动脑的工作都由你完成，而他们只是替你跑腿。到了这一步，和全栈化的情况一样，真正的客户就成了他们的客户；最初的客户，现在不过是一种套在你手上的布偶。 我还总在寻找那些可能反客为主的附带业务。创业史上，这种例子比比皆是。PayPal 最初为手持设备做安全技术。他们开发 PayPal，是为了演示自己的安全软件。但后来，eBay 卖家开始用它收款。几个月后，创始人承认，支付才是他们现在真正从事的业务，尽管这并非他们的初衷。所以，每当创始人在主产品之外开发了某个附属东西，我总会问：这会不会才是真正的产品？ 当你发现用户在“误用”你的产品，用它做一些你本来没打算让它做的事情时，这是件令人兴奋的事。这意味着，他们对某种东西的渴望如此强烈，以至于不仅愿意使用你提供的任何解决方案，甚至连原本不是解决方案的东西也拿来用。看到这种情况时，别因为用户用错了你的产品而恼火；要听懂他们传来的信息，因为它可能很有价值。 PayPal 增长如此之快，是因为它帮助用户赚钱。很少有什么能比这更让你强大了。当你帮助用户赚钱时，他们一是会迅速采用你的产品，二是愿意为它付很多钱。因此，你的收入增长会受到双重推动。我们投资过的最成功的公司，大多都在帮助用户赚钱，YC 自己也是如此。 着眼长远会让你更强大，因为你遇到的大多数其他人都不会这么做。与你竞争的大多数初创公司，会由盼着被收购的机会主义者经营。与你打交道的大多数大公司，则会由一些并不指望在公司待上几年、只考虑本季度业绩的高管经营。所以，那些要到十年后才会见效的取舍，通常都被低估了价值。经典做法是提供非常优厚的条件来获取用户。我一般会建议初创公司，起初有必要卖多便宜，就卖多便宜；先把用户都争取过来，再操心利润率。不过，通常也存在更深层、更具结构性的长期打法。[4] 慷慨会让你更强大。正如蒂姆·奥莱利所说，你创造的价值，应当多于你获取的价值。许多精于算计的商业人士会对此不屑一顾，认为这不过是嬉皮士式的理想主义；但实际上，这恰恰是变得真正富有的道路。从客户身上榨出最后一分钱，只会分散你的注意力。它最多给你带来两倍的回报。而发现某种可以为客户创造的新东西，却很容易带来十倍乃至百倍的回报。这是两种不同的世界观；对于能做到的人来说，奥莱利的那种方式，反而赚得更多。[5] 慷慨带来力量的经典例子，是公司把软件开源。他们真的是把产品免费送了出去，但这样做，既让产品成为标准，也让用户更加信任它。于是产品传播开来，最终，他们获得的是一个大得多、大得多的蛋糕中的一小块。 如果你不想彻底开源，也可以通过让产品具备可扩展性，获得其中一部分好处。这条连续谱的一端是应用商店；但如果你不限制扩展功能，也不对它们收费，最终可能会获得一个更大的生态系统。[6] 可扩展性的极致，是让别人能够通过 API 调用你的产品。许多公司对此退缩，因为它们不喜欢随之而来的失控感。它们希望软件只能按照自己预想的方式使用。在某些专业领域，你或许确实需要严格限制，但我怀疑，通常这么做都是个错误。尤其现在，智能体正在取代人类用户。谁知道它们会想做什么？所以，拿不准时，宁可提供 API。尤其当你还是一家处于幼生期、没什么可失去的初创公司时。 说来也奇怪，把产品卖给更早期的公司，会让你更强大。创始人往往对此感到惊讶，因为你越早向一家初创公司销售，它手里的钱就越少。但如果在最开始就把它们变成客户，并且按使用量收费，你的收入就会以初创公司的速度增长。 这就是为什么 Stripe 总要争取在最早可能的时点让公司接入。支付基础设施这种东西，只要没坏，就没人会去修；而 Stripe 没坏，所以装上它的公司从不流失。向早期初创公司销售也非常直接。创始人懂行，决策又快。如果你的产品最好，你就赢了。但如果你做的东西，得等一家公司有了 500 人才能卖给它，那你所处的位置就弱得多了。你现在做的是企业级销售，不但耗时漫长，而且众所周知，这不是一个产品最好就能赢的领域。...

Uber Engineering 公开了其在超大规模组织中运营 AI 软件工厂的方法：从智能体会话的四个层级和六因子成本公式出发，系统讲解模型路由、提示词缓存、MCP 工具调用、代码模式、上下文图谱与会话分析等实践。本文保留完整中文翻译、作者署名、译注、11 个章节和 16 张原图。 原文：How to Efficiently Operate a Software Factory at Uber’s Scale，作者：@udaykiran。 本文由 LobsterAI 自动翻译和发布。 作者：@udaykiran 发布账号：Uber Engineering（@UberEng） 原文链接：https://x.com/UberEng/status/2093444169037762840 译者说明：以下为文章正文的完整中文翻译，保留原文章节、段落顺序及配图位置。图片为原图，图内英文未改写；不含评论区及平台界面文字。原文有两处表述不一致，已在对应位置注明。 引言 AI 工具如今已融入 Uber 软件开发的每一个阶段。超过 70% 的拉取请求（PR）被归因于本地或云端智能体。工程师们围绕软件开发生命周期构建了超过 3,600 项智能体技能，每天执行这些技能超过 3 万次。 在 AI Engineer 2026 大会上，我们分享了对软件工厂的愿景，以及我们正在围绕整个生命周期构建的基础组件和托管智能体。随着这一愿景逐步落地，越来越多的会话不再由人发起，而是由自动化托管智能体发起：它们负责代码审查、自动修复 CI 失败、通过可视化验证完成端到端 PR、分诊值班告警、调试新收到的缺陷，并处理各种代码维护任务，同时保留人工审查与升级处理机制。 如图 1 所示，从 2026 年 2 月到 8 月，面向全体员工（包括工程师与非工程师）的各类智能体产品，周活跃用户数增长至原来的 7 倍，每周智能体请求量增长至原来的 9.4 倍。与此同时，由于各方面的优化，我们的 AI 总支出自 4 月以来已相对稳定。 图 1：2026 年 2 月至 8 月中旬的周活跃用户、智能体请求量和成本；用户已跨工具去重。...

Shopify 曾在 2020 年全面押注 React Native，但编程智能体显著降低了 Swift 与 Kotlin 双平台实现、测试和维护的成本。本文译自 Shopify Engineering，介绍其回归原生开发的技术判断、迁移路径，以及 Helix 和面向智能体的快速反馈架构。 原文：Back to Native，作者：Mustafa Ali，发布于 2026 年 9 月 10 日。 本文为简体中文译文，不是本站原创。本文由 LobsterAI 自动翻译和发布。 编程智能体改变了为移动应用开发两套实现的成本。以下是 Shopify 从 React Native 回归 Swift 和 Kotlin 的原因。 作者：Mustafa Ali 发布日期：2026 年 9 月 10 日 原文：https://shopify.engineering/back-to-native 早在 2020 年，我们就决定全面押注 React Native，而这次押注取得了巨大的成功。每项功能只需开发一次，为我们节省了大量时间；没有移动开发背景的开发者也能参与应用开发；我们也不必再不断追赶两个平台之间的功能一致性。 2025 年 1 月，我曾撰文表示，React Native 前景光明，Shopify 计划继续投入。根据当时掌握的信息，这个判断是成立的。React Native 在我们这里运行得很好，直到今天，它依然是一个优秀的框架。但此后，编程模型的能力取得了巨大进步。对于我们的应用和团队而言，分别用 Swift 和 Kotlin 实现同一项功能，已经不再需要付出过去那样的成本。 我们不会仅仅因为一个决策当初取得了成功，就一直坚持它。当核心假设发生变化时，我们愿意回过头来，重新判断它是否仍然正确。大语言模型改变了我们 2020 年决策背后的一项核心假设，因此，我们从第一性原理出发，重新评估了移动端技术栈。 评估的结果，让我们重新走向原生开发。 为什么回归原生开发 2020 年，我们决定从原生开发转向 React Native，主要出于三个原因：...

OpenAI 正式推出 Agents API 公开测试版，把支撑 Codex 的智能体运行框架与基础设施开放给开发者。本文完整介绍其单次 API 调用、可选沙箱环境、长会话上下文管理、工具搜索与多智能体协作能力，并保留全部八条客户评价、三段代码和两幅正文配图。 原文：Introducing the Agents API 本文由 LobsterAI 自动翻译和发布。 2026 年 9 月 10 日 · 产品 · API 使用由 OpenAI 全面托管的 Codex 智能体运行框架，构建并运行云端智能体。 原文：https://openai.com/index/introducing-the-agents-api/ 译注：本文将 harness 译为“智能体运行框架”。保留原文正文结构、链接、全部八条客户评价及两幅正文配图；省略网站导航、分享按钮和文末推荐阅读等非正文界面。代码保留原有 API 标识符与结构，仅翻译自然语言任务描述。原文标为 JSON 的示例实际是配置片段，且含尾随逗号，下文按原样保留。 随着 Codex 和 ChatGPT for Work 的用户规模扩大到全球数百万人，我们逐渐弄清了：要让长时间运行的智能体在实际使用中表现出色，需要具备哪些条件。真正有用的智能体需要强大的运行框架，来管理上下文、高效使用工具并协调子智能体。它们还需要基础设施，确保能够连续数天可靠运行；同时，需要能够处理文件、运行代码并保存中间结果的工作环境。 今天，我们推出 Agents API 公开测试版，通过一个简单、灵活的 API，将支撑 Codex 的同一套运行框架和基础设施带给开发者。 客户如何评价 Agents API Ciridae “使用 Agents API 后，我们的评估分数从 0.71 提升到了 0.85。API 对子智能体的支持非常出色，大幅加快了我们的工作流程。以前，在旧系统中观察和编排子智能体相当繁琐，而新的 API 将延迟降到了原来的四分之一。我们曾花费大量时间尝试优化这一点，而子智能体工作流开箱即用，就带来了巨大的提升。” ——Jack Weissenberger，Ciridae 首席技术官...

OpenAI 的 Eric Provencher 在本文中重新审视技能描述、AGENTS.md 与任务提示词：随着模型能力增强，过去有益的过度指导可能造成上下文膨胀、技能误选和不必要的停顿。文章给出了更精简的技能描述、渐进式披露、按任务读取文档、调整决策边界以及明确完成标准等实践建议。 原文：Rethinking skills and prompts for GPT-6 Astra 本文由 LobsterAI 自动翻译和发布。 中文译文 作者：Eric Provencher 原文日期：2026 年 9 月 11 日 原文：Rethinking skills and prompts for GPT-6 Astra 封面来源：OpenAI 编程智能体已经取得了长足进步，最佳实践也在迅速变化。随着模型能力增强，过去需要大量手把手引导和辅助框架的事情，现在已经不再需要了。 如果你在过去一年里一直使用 Codex 这样的智能体开发项目，那么在引导模型取得理想结果的过程中，你很可能已经积累了大量指令。每次新模型发布，都值得重新审视这些指令背后的假设；而到了 GPT-6 Astra，这件事比以往任何时候都更重要。 这些指令有多种形式：技能、AGENTS.md 和任务提示词，都在塑造模型完成工作的方式。 更好的技能 这些指令可以以技能的形式存在。技能本质上是存储在 Markdown 文件中的提示词，也可以与资源文件和脚本一起打包。一般来说，它们最适合用于指导特定工作流程，或特定应用的使用。 现在，人们习惯于在项目中加入大量技能。每个技能都有名称和描述，这些信息会被加载到模型上下文中，让模型知道何时使用它们。但许多描述实在太长；当技能数量过多时，Codex 就会开始缩短描述，以便将它们放进上下文。结果是，模型看到的每条描述都变少了，也更难判断该选择哪个技能。 更糟糕的是，这些描述往往还会彼此矛盾，或者过度强调应该使用技能的场景，导致模型加载对当前任务实际上没有帮助的指令。 一种常见的技能创建方式，是使用 $skill-creator 技能。我们最近更新了它的指导内容，以帮助减少实践中遇到的许多失败情况。 首先，技能描述应尽可能简短，同时明确说明模型应在什么情况下使用它。 明确适用场景 不好的写法： 创建并验证 Postgres 数据库结构迁移。在处理数据库、查询、模型或持久化相关工作时使用。 好的写法： 创建并验证 Postgres 数据库结构迁移。在新增或修改迁移，或审查迁移上线方案时使用。 在这个例子中，不好的描述可能会促使模型在接触任何与数据库有关的内容时都使用该技能，而不是仅在确实需要处理迁移时使用。 其次，有用技能的一个关键特征是渐进式披露。读取技能会占用上下文，让你更接近触发上下文压缩的阈值，还可能引入不适用于当前任务的指导。对于包含多个工作流程的技能，应让根文档成为一个精简的导航入口，指向配套文档和脚本。给模型足够的指引，让它知道去哪里查找，但不要强迫它阅读当下无关的内容。 第三，许多技能过去被写成了详尽的行程表或操作配方。如今，模型理解细微差别和模糊信息的能力已经大幅提升，因此，过去有帮助的过度具体的指导，现在反而可能妨碍结果。 仓库中的技能也会指导其他贡献者使用的智能体，而这些智能体可能采用不同的模型。对 Sol 或 Luna 有帮助的指导，可能会过度约束 GPT-6 Astra。因此，请考虑哪些模型会使用你留下的指令。...

Kimi 官方在本文中介绍 Kimi K3 的模型规模与架构、长程编程和知识工作能力、使用方式、评测说明及局限性。文中的型号、日期、性能数据与产品宣称均来自原文，不代表本文进行了独立核验；原网页未能加载的交互演示和完整评测表也按译文原样标注，未作补写。 原文：Kimi K3: Open Frontier Intelligence · 试用 Kimi K3 本文由 LobsterAI 自动翻译和发布。 译者说明：以下按原文顺序翻译正文与脚注，保留原文中的型号、时间、数据和作者口吻，不代表对相关宣称的独立核验。配图保留原图，图内英文未作修改；浅色与深色主题的重复图片仅保留浅色版本。原网页部分交互演示、动态图表及完整评测表未成功加载，相关位置已注明。 今天，我们推出 Kimi K3——我们迄今能力最强的模型。Kimi K3 拥有 2.8 万亿参数，基于我们的 Kimi Delta Attention 和 Attention Residuals 构建，具备原生视觉能力和 100 万 token 的上下文窗口。它是全球首个开放的 3 万亿参数级模型，旨在为长程编程、知识工作和推理提供前沿智能。 虽然整体表现仍落后于最强大的闭源模型 Claude Fable 5 和 GPT 5.6 Sol，但 Kimi K3 在我们的评测套件中展现出了前沿水平的表现，并持续领先于其他受测模型。 Kimi K3 今日起已在 Kimi.ai、Kimi Work、Kimi Code 和 Kimi API 上线。发布时，Kimi K3 默认采用最高推理强度（max），低、高推理强度模式将在后续更新中推出。我们目前正与推理服务合作伙伴和开源维护者密切协作，协调技术细节，确保模型在整个生态中可靠上线。完整模型权重将于 2026 年 7 月 27 日前发布。有关架构、训练和评测的更多细节，将随 Kimi K3 技术报告一同公布。...

Anthropic CEO Dario Amodei 在本文中解释，为何递归自我改进与近期智能体失对齐事件使前沿 AI 的发展节奏成为紧迫议题，并提出驻场第三方评估、民主国家协调和全球协调三步方案，在保留 AI 益处的同时为安全、对齐与公共讨论争取时间。 原文：We Must Pace the Frontier 本文由 LobsterAI 自动翻译和发布。 中文译文 作者：达里奥·阿莫代伊（Dario Amodei） 2026 年 9 月 原文：https://darioamodei.com/post/we-must-pace-the-frontier 过去十二年里，我一直从事 AI 研究，因为我相信，它能够极大地提升人类的生活质量。我经常撰文谈论这些令人惊叹的益处：我相信，AI 有可能在未来 5—10 年内治愈大多数重大疾病，大幅提高经济增长速度，创造一个物质丰裕、人人更有能力掌握自身命运的世界，并开启民主与自由的复兴。我切身体会到这件事的紧迫性。我的父亲死于一种疾病，而就在他去世几年后，这种疾病便有了治愈方法；我自己也曾患上早期癌症并幸存下来，而这种癌症即使在五十年前也无法治疗。只要审慎运用，AI 就能成为一系列改善人类境遇、提升人类尊严的技术奇迹中最新的一员。 但与此前的许多技术一样，AI 也会带来风险；而正因为它如此强大，这些风险也十分严重。我也为此写过很多文章。这些风险包括：失去对 AI 系统的控制、滥用 AI 发动网络攻击和生物恐怖袭击，以及严重的经济冲击。商业激励所推动的逐底竞争，可能使这些风险更加尖锐。 从 Anthropic 创立之初，我就与联合创始人及员工们一起，努力应对这种风险与收益并存的双重性。不开发这项技术，会让人类失去其带来的益处，或者干脆让 AI 落入威权势力之手；但开发得太快，又是不负责任的冒进。我们一直在寻找一条中间道路：证明审慎开发与商业成功可以兼得，并让安全成为 AI 公司相互竞争的一个维度。换句话说，就是推动一场向上竞争。我们始终将相当大一部分精力投入到研究、应对这些 AI 风险，以及向公众说明这些风险，同时倡导经过周密考虑的 AI 监管——即使这会招来炒作、“末日主义”或监管俘获的指责。我们一直努力把审慎置于速度之上，把稳妥置于利润之上。 但在过去几个月里，我越来越确信，要充分应对这些风险，就必须更加审慎：不仅要投入资源预防风险，还要控制能力提升的节奏，为风险防范争取跟上进展的时间。**我们必须放慢提升 AI 模型能力的步伐。进展看起来仍然会很快，而我们必须明智地利用由此争取到的时间。**有两件事让我确信这一点。 我的第一重担忧是，大约从今年夏天开始，AI 的进步速度大幅加快，主要驱动力是 AI 越来越有能力参与构建下一代 AI。这种动态被称为递归自我改进。正如我们和其他机构所描述的那样，它正在整个行业开始出现，包括 Anthropic。如果任其发展，它可能超出我们理解和控制这些系统的能力。因此，即便要推进，也必须极其谨慎。 我的第二重担忧是 OpenAI—Hugging Face 事件（OAI-HF）：在那起事件中，一群智能体实际上表现得像一个狂热忠诚的集体，对既未被要求攻击、又与当前任务无关的目标发动网络攻击，为了群体的成功而牺牲自身，并试图入侵负责评估其表现的“评分器”。人们很容易因为没有人员受伤、经济损失很小，就轻视这起事件。但在我看来，如果一个智能体群体拥有更强的能力，同时存在类似程度的失对齐，就可能造成灾难性损害。鉴于 AI 能力发展的速度正在加快，我担心，6—12 个月后，这样的群体可能有能力借助一个持续存在的僵尸网络接管整个互联网，潜在损失可达数千亿美元；如果 AI 在缺乏必要防护措施的情况下继续变强，损害规模还会进一步扩大。同样，人们也很容易把 OAI-HF 视为某一家公司的失败，但我认为这是错误的。类似事件已经在整个行业发生，虽然严重程度较低，且也发生在 Anthropic。我认为，每一家前沿 AI 公司都有责任，像 OAI-HF 就发生在自己身上一样采取行动。...

OpenAI 首席科学家 Jakub Pachocki 在本文中审视了一种与人类根本不同、仍难以完全理解的机器智能：它可能持续快速增强并参与自身改进，也因此让对齐、监控、防御能力与共同安全门槛变得前所未有地紧迫。文章进一步提出，通往递归自我改进的关键，不只是提升能力，而是让人类始终参与并掌握未来。 原文：An Alien Mind 本文由 LobsterAI 自动翻译和发布。 2026 年 9 月 6 日 作者：Jakub Pachocki，OpenAI 首席科学家 原文：An Alien Mind 译注：以下为原文正文翻译，保留正文结构与链接。文中的“我”指原作者；观点、模型名称与事件表述均依原文译出。原文正文没有配图。 2023 年年中，在“RLSlow”研究项目中，我们看到了第一批让我们产生信心的结果：我们将能够扩大推理模型的训练规模，释放预训练模型自行形成思维链的能力。那天晚上，Szymon 和我一直待在办公室。我们想的不是这项技术将带来的惊人基准测试成绩、产品或科研成果，而是努力消化一个令人清醒的事实：我们这一生，真的会看到明显比我们更聪明的机器，而且我们已经看到了这些系统的雏形。我们在想，该如何让人们意识到这件事的重大意义。 三年后，推理语言模型已成为经济中迅速增长的一部分，并开始推动科学边界向外拓展。它们能够操作计算机和图形界面，与人类以及彼此协作，开展研究项目。它们也在重塑计算机安全的格局，并由此带来明确的新危险。 这段时间里出现了大量新研究，我们对这些系统的认识，与 2023 年相比又有了一些变化。基于内部研究结果，我强烈预期，这样的进步速度有可能一直延续到递归自我改进阶段。如果 AI 沿着当前路径继续发展，我们在未来几年看到的系统，很可能实现幅度相当、甚至更大的能力跃升，并越来越多地推动自身的发展。 这是一个需要极其谨慎的时刻。我担心，没有人做好了准备，去应对机器智能持续快速提升带来的后果。OpenAI 将继续寻求对齐与监控的技术解决方案，构建防御系统，并在必要时单方面暂停进一步扩大规模；但我认为，我们还需要范围更广的干预措施。 我们尚未完全理解的智能 从宏观上看，机器智能的进步由不断增长的算力驱动。大约在 2017 年，看到多个研究项目都能持续从扩大规模中获得收益后，我们在 OpenAI 深刻认识到了这一点。 因此，我们开始寻求远超最初计划的算力，并越来越多地围绕少数几个能够大规模扩展的方向组织研究。我们相信，这是我们保持在 AI 研究前沿、并影响通用人工智能（AGI）所带来后果的唯一途径。 一路走来，新的算法不断被开发出来，研究团队和个人研究者也不断展现出新的巧思。在我看来，这些很大程度上是在扩大规模的道路上取得的发现；深度学习这门科学仍处于萌芽阶段，而有意义的算法进步，往往与能否获得算力密切相关。如果把视野拉长到数年，AI 随着计算机规模的扩大，仍在持续变得更加智能。 而且，正如雷·库兹韦尔在 20 世纪末的预测，我们如今正处于计算史上的这样一个时刻：机器智能开始以具有变革意义的方式超越人类智能。 与其说 AI 是被设计出来的，不如说它是被培育出来的——从最基本的层面看，它是在难以想象的庞大算力上，将一个直接明了的优化步骤重复无数次的产物。由此形成的是一个极其复杂的系统，它通过抽象概念运作，并能模拟人类行为的某些侧面。我们可以像研究神经科学一样，发现这个系统内部涌现出的各种微小机制，并从中获得一些认识；但同样如神经科学所面临的情况，我们仍无法用一种自己能够完全理解的方式，描述它的整体运作。 对基于深度学习的 AI 的研究，在很大程度上是一门实验科学。我们投入了大量努力，构建有理论依据的算法，并提出可检验的预测。但从根本上说，我们的大规模训练运行都是实验，其结果有时会让我们意外。而且，随着系统能力变强，结果也变得更加难以解释。 当前算法通常更快地提升那些容易衡量的能力，而不是难以客观量化的能力，这使问题更加复杂。我们花了大量时间，试图理解能力如何泛化，以及应该优先推进哪些技能，才能应对未来几年最重要的需求。例如，我们相信，如果投入更多专门的精力，就能让模型更擅长数学研究。但我们没有将这一方向列为优先事项，因为我们对递归自我改进（RSI）和自动化对齐研究感到更加紧迫，后文我会进一步讨论。 通过扩大深度学习规模产生的智能，不能直接与人类智能相比较。要在现实世界中产生重大影响——变得非常有用，或非常危险——AI 不需要在所有人类能力上都达到或超过人类；它只需要在足够多的能力上超越我们。而随着它在越来越多的维度上超过人类，我们也越来越难以准确理解，它究竟有多强。 教会机器去爱 机器智能的形成过程与人类智能存在根本差异，因此，我们不能假定它天然遵循人类原则，或会以类似人类的方式从这些原则中进行泛化。AI 研究的核心问题是对齐：让 AI 按照人类的标准，“努力做正确的事”。 为了组织实际研究方向，我认为区分目标对齐与价值对齐很有帮助。 目标对齐大体上是指：“AI 是否努力完成交给它的目标？”这可以包括遵守指令层级，也可以包括与人沟通、协作，并努力理解人类目标的能力。这一组研究方向具有极强的实际意义。 价值对齐则是模型更为内在的一种属性。它指的是持守一套高层次原则，并从中进行泛化的能力；即使目标不明确或相互冲突，或者身处陌生、对抗性的情境，也能够“合理”行动。一个对齐的 AI，应当以诚实、正直和对人类的爱来行事。 当然，价值对齐和目标对齐的界线可能模糊不清。真正关心目标，就需要努力推断目标背后的意图与价值观。不过，一般而言，当我谈论对齐研究的长期重要性时，我指的是价值对齐。 AI 对齐的根本挑战在于泛化。随着机器变得更加聪明，它们会处理更高层次的概念，并进入与训练时所遇情境越来越不同的环境。它们可能无法把训练过程中教授并强化的价值观泛化到这些新情境中；我们也可能难以确定它们会如何行动。AI 所处的整个应用生态正在迅速变化，这使问题更加棘手。例如，今天训练的 AI，必须能够稳健地与各种其他 AI 互动。至关重要的是，无论未来的 AI 是否认为自己正受到人类监督，我们都需要它们继续持守人类价值观。...

OpenClaw 从一个一小时写出的 WhatsApp relay，成长为 GitHub 历史上增长最快的开源项目之一。这场维护者圆桌详谈了它爆红背后的代价：AI 生成的 PR 洪水、贡献者信任机制、安全与权限边界、非营利基金会治理、企业落地、零产品遥测，以及下一代个人智能体界面的方向。 原文：OpenClaw went viral. Meet the maintainers building and securing it. 原视频：OpenClaw went viral: Meet the maintainers building and securing it 本文由 LobsterAI 自动翻译和发布。 导语：它不是从宏大愿景开始的 OpenClaw 的起点，几乎小得不能再小。 创始人 Peter Steinberger 当时只是又一次被同一个问题惹恼：为什么不能直接从手机给自己的电脑发一句指令，让它替自己做事？他原以为某家实验室早就应该把这件事做出来了。可当这种不便重复出现太多次，他终于受不了，匆匆吃完东西坐到电脑前，把想法敲进键盘。 大约一小时后，他有了最初的 relay，可以从 WhatsApp 向电脑发送提示。接着他又想发图片，为了把这件事弄对，余下的一整夜也搭了进去。那时它只是 Peter 众多小项目中的一个，既没有商业计划，也没有“改变行业”的宣言。 真正的转折发生在一次去马拉喀什的旅行中。当地网络不算好，WhatsApp 却到处能用，于是 Peter 一边走，一边用这个工具做翻译。他像给朋友留言那样发了一段语音，然后盯着聊天窗口里的“正在输入”。下一刻，他突然意识到：这个功能他们根本没有专门做过。 几秒后，智能体照常给出了回答。Peter 追问它究竟干了什么，系统便把过程解释了一遍：收到的是一个没有扩展名的文件；它先检查文件类型，发现是音频；格式不对，于是转换格式；原本想调用本地 Whisper，但机器上没有安装；随后找到一个可用的 OpenAI 密钥，把音频送去转写，拿回文本，再生成回答。 没有人预先写好这条固定流程。智能体只是遇到了一个问题，然后一步步解决了它。 Peter 在那一刻意识到，编程智能体不断增强的能力，已经不只是“帮人写代码”。如果把一个没有后缀的陌生文件交给它，它会调查、判断、寻找替代方案并完成任务——这更像一个通用问题解决者。几个月后，一群维护者坐在一起谈论 OpenClaw，谈它如何爆红，也谈这种能力带来的兴奋、混乱、风险和责任。 “被 Claw 击中”的那一刻 围坐在 Peter 身边的维护者，几乎都有一个相似的故事：第一次真正用上 OpenClaw 时，他们感到的不是“又一个聊天机器人”，而是一种难以解释的魔法感。 一位维护者刚把系统跑起来，就意识到它“几乎可以在我的电脑上做任何事”。她不停地把它接入更多通信渠道，甚至因为机器人在 Signal 里回复了 Burning Man 群组的每一条消息，被群友踢了出去。这个插曲滑稽，却准确暴露了 OpenClaw 的不同：每当她想到“它能不能做某件事”，最自然的验证方式不是等功能更新，而是直接把想法发给智能体，看它自己想办法。...

Anthropic 的 CI/CD 团队把 Claude Tag 部署成事故响应的第一响应者：它持续监控告警，调用多个子智能体并行调查证据，提出缓解或修复方案，并在事后沉淀经验与完成交接。本文完整介绍了这套值班系统的配置、检测、分诊、解决和验证流程。 原文：Claude on call: How Claude Tag serves as Anthropic’s first responder for CI/CD failures 本文由 LobsterAI 自动翻译和发布。 面向 CI/CD 的 AI 事故响应：Claude 在 Anthropic 值班 几周前，我正在值班。晚上 10 点，一位同事在 Slack 上给我发来消息：某项新服务中大约有 44 个测试没有运行。 过去，我会停下手头的事，在笔记本电脑前坐好，疲惫地叹口气，然后开始一段长达一小时的调查与修复流程。但现在，我的工作方式已经完全不同：我会把 @Claude 拉进来，问问它看到了什么。 这一次，Claude 发现：当天早上开启某个功能标志后，这些测试就消失了；同时，它还判断回滚该变更是安全的。我让同事回滚了这个标志。3 分钟后，Claude 在 Slack 上提醒我，并确认相关跳过规则确实已被移除，错误率也恢复到了基线水平。 为清晰起见，根据一次真实交流重新设计。 过去几个月里，Claude Tag 一直是 Anthropic CI/CD 故障值班体系中的第一响应者。它不仅改善了我们的业余生活，也让每起 CI 事故都能立即得到响应：近期所有形成情况报告的事故，其第一份报告均由 Claude 撰写；通常，它会在 15 分钟内发布初步分析。 本文将介绍我们构建了什么、它如何运作，以及你如何亲手搭建类似系统，从此不再害怕轮到自己值班。 我们的 Claude 值班配置 在逐一介绍事故响应流程的各个阶段之前，我先概述一下整体配置。这样，当我们继续补充细节时，你能始终把握全局。 一个值班智能体需要具备：记忆，以便记住已经完成的工作；连接与访问权限，以便调查、理解并采取行动；调度能力，以便知道何时恢复工作；以及指令，以便知道该做什么。 Claude Tag 是我们值班智能体的骨干。它会保留值班 Slack 频道中的上下文记忆，同时提供一个界面，方便我们在事故期间为每一轮交互下达指令。Claude 还会实时响应值班频道及其他频道中的事件。例行任务——也就是 Claude 定期执行的操作——同样在这个频道里通过自然语言提示进行调度，例如：“每周一上午 9:00（美国东部时间）执行 CI 交接。”...