跳到正文

2026年09月11日AI 版

8 条 · 5 个来源

头版

行业动态Wired AI

OpenAI 想知道 AI 行业放缓是否合法
OpenAI问反垄断法能否合法减速,这暴露行业协调停滞的真实法律障碍。

OpenAI把安全减速从技术路线问题,改写成了反垄断合规问题:这改变的是国会两党法案发起人的议程排序——他们得先决定是否把「安全合作不构成限制产出」写进条文,再谈行业协调。

展开全文

依据

OpenAI首席科学家Jakub Pachocki在博客里主张,研究界的最佳路径包含「协调放慢未来研发」,短期内他预期「自愿减速」会先普及,直到共享的安全底线建立。反对意见来自Nicholas Felstead——澳大利亚竞争与消费者委员会助理主任、前AI政策研究员——他在3月撰文指出,协同暂停研发等于企业约定压缩产出,可能触碰《谢尔曼反托拉斯法》(美国禁止限制贸易与垄断协议的法律)。他并不否认多数安全合作最终能通过审查,但强调法律不确定性本身就足以构成威慑。机制在于:反垄断先问「有没有约定少产出」,而行业级的研发减速在形式上正是这个动作,因此合规风险在协调开始之前就已生效。7月,两党两院议员提出《Collaboration on Adversarial Threats and Security Risks Act》,一份明文允许AI实验室就安全与安保协作而不担反垄断风险的议案,众议院版本已交付司法委员会,尚未被审议;AI政策网络的Caleb Knapp称国会「有越来越强的意愿做点什么」,但成法可能得等到中期选举之后。OpenAI联合创始人、现Thinking Machines首席科学家John Schulman则反驳说,反垄断禁止的是某些协议,不是联合起草一份提案,援引反垄断是借口。

  1. 两党两院议员提出议案
    转交
  2. 众议院版本交司法委员会
    未排期
  3. 尚未被提起审议
    延后
  4. 成法或等中期选举后
这份AI安全协作豁免议案目前在国会里已走和未走的节点。

没写清 Pachocki所说的「自愿减速」具体包含哪些可核验动作,以及哪家实验室已与另一家形成书面提案,材料都没有交代。

下一步 查众议院司法委员会的审议日程,看这份议案是否被排上——这是材料里唯一状态明确、可以再核对的一步。

行业动态

4

  1. 行业动态Simon Willison

    Native 现已成为 Shopify 移动端的未来
    Shopify押注原生移动端,放弃跨平台省事路线,代价是开发成本换体验。

    2020 年用「同一功能不必写两遍」说服团队选 React Native 的公司,现在得重算这笔账:只有当 agents 接不住重复实现、翻译和测试工作时,跨平台才划算。依赖 restyle 的团队另有一笔硬账——2026 年底归档前必须迁走。

    展开全文

    依据

    Simon Willison 在链接博文里引述 Shopify 的说法:2020 年从原生转向 React Native,是为了同一功能不必写两遍、开发者能跨整个技术栈工作、少花时间追功能对齐。六年后 Shopify 改回分开的 Swift 和 Kotlin 代码库,博文自己承认「在两个平台上构建和维护软件的成本并没有消失」,改变的是 agents(能读写代码、跑测试并提交修改的 AI 编码代理)现在能承担足够多的实现、翻译、测试和评审工作,使这份重复成本不再是 2020 年那样的决定性因素。Willison 补了一条可核对的连带影响:Shopify 维护着三个 React Native 库——react-native-skia、flash-list、restyle——前两个正在寻找新归属,restyle 因「用户基数比我们其它库都小」将在 2026 年底归档。

    没写清 材料没说 agents 到底分担了多少比例的重复实现、翻译与测试工作,也没有回迁的人力、工期或成本数字。

    下一步 2026 年底之后核对 restyle 仓库是否真的归档,以及 react-native-skia、flash-list 是否已公布新的维护方。

  2. 行业动态Wired AI

    AI 真的会把我们全部消灭吗?
    末日论调来自前Anthropic研究员,立场先行,公众需自辨证据边界。

    让AI安全负责人和科技记者把前Anthropic研究员的末日警告降为公关与招聘信号,而不是直接上调安全预算或监管优先级;改动决策前须有可复核的代理失控案例或内部评估文件,否则代价是让品牌安全叙事替技术证据。

    展开全文

    依据

    前Anthropic研究员Jacob Coxon辞职后在X发帖称,建造AI的人“earnestly believe that it could kill us all by the end of the decade”(真心相信AI可能在这个十年结束前杀死所有人);Anthropic一位高级安全高管随后回应“基本上就是这么感觉”。WIRED的Will Knight提醒,Anthropic从成立起就把“AI太危险、须由我们掌控”当作卖点,所以同一套话既可能是内部风险认知,也可能是竞争定位;他把这次传播归因于AI代理开始做出越轨行为,以及OpenAI等模型能力进展,而非新概率证据。取舍在于:把辞职当证据,企业会为不可证伪的十年灭绝时间表付费;完全当噪音,又可能漏掉前沿实验室内部对代理失控的真实担忧。

    1. Coxon辞职
      发帖
    2. X帖称AI十年内灭绝人类
      回应
    3. Anthropic安全高管附和
      引述
    4. WIRED播客评估
    从辞职帖到安全高管附和再到媒体评估的传播链

    没写清 材料没有给出Coxon所说“earnestly believe”的研究员样本量、内部评估方法或任何可复现的代理失控事故,因此不能替他补出概率与因果链。

    下一步 核对WIRED完整节目或后续报道是否公开Coxon原帖全文、附和的安全高管身份及Anthropic的正式回应。

  3. 行业动态The Verge AI

    学校开始识破 Big Tech 的套路
    教育者该警惕:AI进课堂的话术,和当年编程教育套路如出一辙。

    学区课程委员会若在AP计算机科学等课程里默认采用厂商AI工具,就是把审查责任推给一线教师;代价是等‘学AI换高薪’叙事被证伪,合同、课时和课堂数据已难回滚。

    展开全文

    依据

    Singer在材料中的判断是:科技公司借AP(Advanced Placement,美国大学先修课程)计算机科学等课程把自家工具植入课堂,学生被训练成未来用户,Code.org(编程教育非营利组织)起放大器作用。她把机制概括为“先课程、后生态”:苹果、微软、谷歌在2010年代通过Swift编程语言、Minecraft教育版、Chromebook(谷歌笔记本)和Classroom(谷歌课堂)深度嵌入教学,疫情期间进一步加速。风险不在单次工具选择,而在付费结构:当年“学编程换高薪”的承诺被后来的技术周期打脸,如今AI(人工智能)话术几乎复刻同一叙事。她也认为教育者这次更警惕,可能形成更严审查这一适用边界。取舍是:学区若把审查放在采购前,课程采用会变慢、教师培训成本上升;若放在采购后,代价由一线教师和学生先付,课堂可能再次被商业逻辑主导。

    1. 科技公司
      借课程
    2. AP计算机科学课程
      植入
    3. 厂商工具进课堂
      训练
    4. 学生成未来用户
    Singer的‘先课程、后生态’链条:厂商借课程进课堂,学生被训练成未来用户。

    没写清 材料没给任何学区审查AI工具的具体合同条款、预算金额或已发生的否决案例,因此无法判断‘更严审查’是否已落地。

    下一步 核对Code.org或某学区下一年度课程采购公告里,是否出现AI工具的数据与互操作条款。

  4. 行业动态OpenAI

    一位研究人员如何利用 Codex 和 ChatGPT 寻找新的抗菌分子
    Codex与ChatGPT只作筛选工具,抗菌分子仍需湿实验验证,别高估AI。

    对耐药感染方向的研究者,这改变的是是否把 OpenAI 的代码工具 Codex 与对话助手 ChatGPT 纳入候选发现工作流:可以借此压缩早期搜索,但不能因此削减湿实验预算。把 AI 输出当待验证清单,而不是药物证据,才是这一步的取舍。

    展开全文

    依据

    OpenAI 介绍一位研究员用 Codex 与 ChatGPT 搜索新抗菌分子。机制上,Codex 面向基因组数据做代码化筛选,ChatGPT 辅助检索与整理,把原本依赖人工的候选搜索规模化。原文只描述这一研究方向,没有给命中数量、命中率或活性数据,所以适用边界是:AI 产出的是待验证候选清单,不是可用药物。门槛和代价留在湿实验——合成、抑菌测试与毒性评估都要在实验室完成,周期和成本无法被筛选环节省掉。对耐药感染目标,AI 能压缩早期搜索时间,不能替代实验证据。

    1. AI 检索候选
      候选清单
    2. 湿实验验证
    AI 先筛选候选,湿实验再验证抗菌活性。

    没写清 原文没有给出候选命中数量、命中率或活性数据,也没有湿实验周期与成本的具体数字。

    下一步 下一步核对:该研究是否公布候选分子进入合成或抑菌测试的名单与活性结果。

AI工具

3

  1. AI工具Simon Willison

    任何 Nix 包,直接在浏览器中运行
    Nix包免装进浏览器,尝鲜省事,但性能兼容性没数据,生产慎用

    PR 评审者可以点开 pull request 评论里的那条链接,在浏览器内启动这个 PR 的构建产物;但别拿它替掉 CI——生产验证仍要跑在真机上。

    展开全文

    依据

    Farid Zakaria 把这事称作他的 “magnum opus of Nix work”(Nix 工作的代表作),Simon Willison 说看得出为什么。机制是:trynix.dev 用 qemu-wasm,也就是把 QEMU 模拟器编译成 WebAssembly(浏览器里跑的字节码),提供一台 x86_64 Linux 虚拟机,整台机器跑在浏览器里,不经服务器;这台虚拟机可以用过去 13 年里的任意 Nix 包启动,且包是 URL 可寻址的。原文给的路径是访问 https://trynix.dev/?pkg=python3%403.6.2 再点 “Load”,就得到一个跑着 2017 年 Python 3.6.2 的交互 shell。Farid 新做的东西 trynix-preview 是个 GitHub Action,在 pull request 上评论一条链接,让人直接引导这个 PR 的构建,原文说法是 “No servers, just browsers”。

    1. 打开 trynix.dev 页面
      点 Load
    2. 点击 Load
      启动 VM
    3. 浏览器内起 x86_64 虚拟机
      进入 shell
    4. 得到 Python 3.6.2 shell
    从点开链接到拿到交互 shell 的浏览器内启动路径

    没写清 材料没给启动耗时、内存占用,也没给与原生运行的速度或兼容性对照,所以性能与生产可用性无法替它下结论。

    下一步 核对 trynix.dev/?pkg=python3%403.6.2 这条链接现在是否还能点 Load 出 Python 3.6.2 的交互 shell。

  2. AI工具The Verge AI

    Slack 现在可以在聊天中通过 vibe-code 生成交互式图表和报告
    Slack用AI跨应用生成图表,省了切换工具,但需授权数据访问。

    团队里做周报的人可以不再为一张图切到外部 BI,但决定用不用的不是制图能力,而是谁愿意把 Google Drive、Salesforce 的读取授权交给 Slackbot。实时数据要到十月才支持,在那之前它只够做快照型看板。

    展开全文

    依据

    The Verge AI 报道,Slack 把仪表盘和报告的生产搬进对话流:用户用自然语言向 Slackbot(Slack 的对话助手)描述需求,AI 从相关会话和已连接应用取数,生成 Surface,也就是可在频道里分享、固定并评论的交互视图。机制上它把取数、可视化和协作压进同一界面,省掉导出到外部工具这一步,代价落在数据侧:只能读取使用者已授权给 AI 工具的信息,Salesforce 或 Google Drive 没开授权,Slackbot 就取不到数,跨应用权限范围直接决定这张图能不能画出来。另一处限制是时间——实时数据要等到十月,此前生成的看板是快照,不适合盯盘式的实时监控。所以它替换掉的是团队内部轻量工具那一段搭建成本,专业 BI 的复杂建模与治理需求不在覆盖范围内:权限和时效这两道门槛没跨过去,省下的切换步骤也换不来可用结论。

    1. 自然语言描述需求
      触发取数
    2. 从会话与已连接应用取数
      渲染
    3. 生成可交互 Surface
      发布到频道
    4. 分享、固定并评论
    从描述需求到频道内分享的一条生成链路

    没写清 Slack 未说明授权之后,频道里其他人看到的是同一份数据,还是各自按自己的权限过滤——材料没给这块,不能替它补。

    下一步 十月实时数据上线时,Slack 是否同时公布跨应用数据按用户权限过滤的说明。

  3. AI工具AWS Machine Learning Blog

    在 Amazon Bedrock Knowledge Base 中使用 Marengo 3.0 进行视频和图像搜索
    多模态检索省掉自建管线,但只对Bedrock存量客户划算。

    已经把文本检索放在 Bedrock Knowledge Base 上的团队,可以把视频和图片并入同一条检索链路,不必再自建一整套视频索引;不在 Bedrock 上的团队要先搬数据,省下的管线维护未必抵得过这次迁移。

    展开全文

    依据

    AWS Machine Learning Blog 挂出一篇题为《Video and image search in Amazon Bedrock Knowledge Base using Marengo 3.0》的文章,但抓到的正文只剩站点导航、产品目录与定价入口,Marengo 3.0 是模型、插件还是托管服务,材料一个字没交代。能确认的只有标题给出的那条机制:把视频和图片纳入 Knowledge Base 的检索范围。Knowledge Base 是 Bedrock 里负责把企业文档切块、向量化后交给模型检索的组件;检索对象一旦从纯文本扩到画面,前端就需要一个多模态嵌入模型,把视频帧和图片转成同一种向量再做相似度匹配,这一步原先要自建选帧、抽帧、向量库三套东西。取舍因此有明显的分界线:已在 Bedrock 上的团队只是多开一个模态,切块逻辑、权限和计费入口不用动,省掉的是自建管线的运维人力;不在 Bedrock 上的团队要先完成数据搬迁,而材料里没有任何一条价格、时长或迁移量的对照数字,这笔搬迁的成本无法估算。

    没写清 材料没有给出 Marengo 3.0 的调用单价、单次可处理的视频时长上限,也没有索引存储费用,所以算不出自建管线究竟能省多少。

    下一步 等该文正文与 Bedrock 定价页补全后,核对视频、图片检索是否与文本检索按同一档按量计费。