从 46 条内容中筛选出 10 条重要资讯。


  1. DuckDB v2.0 预览版发布,引入服务器模式与新 SQL 解析器 ⭐️ 9.0/10
  2. 黄仁勋宣布 NVIDIA 与 SB Energy 合作,在俄亥俄州为 OpenAI 建设大型 AI 工厂,目标 2030 年达 16 吉瓦算力。 ⭐️ 8.6/10
  3. 调查人员使用 AirTag 追踪批量图书运输,发现其终点是亚马逊 AI 训练中心 ⭐️ 8.3/10
  4. Cursor 发布 Origin,一个专为并行 AI 智能体工作流设计的 AI 原生代码托管平台。 ⭐️ 8.3/10
  5. AI Agent 协作平台 Cumora 现已开源 ⭐️ 8.3/10
  6. Rust 编译器获得原生 GPU 卸载支持,实现安全、可移植的内核 ⭐️ 8.0/10
  7. AI 生成的 GitHub Copilot 建议在 Snowflake 的 Jira 自动化中引入代码注入漏洞 ⭐️ 8.0/10
  8. Hacker News 社区热议对 AI 生成内容的普遍疲劳 ⭐️ 8.0/10
  9. Thibault Sottiaux 宣布推出 Codex,一个近乎 100% 可靠的开源 AI 开发者工具。 ⭐️ 8.0/10
  10. Guillermo Rauch 分享链接,可能宣布新进展。 ⭐️ 7.0/10

DuckDB v2.0 预览版发布,引入服务器模式与新 SQL 解析器 ⭐️ 9.0/10

DuckDB 团队宣布了计划于 2026 年秋季发布的主要版本 v2.0 的预览。其核心新特性包括支持以服务器模式运行、触发器、新的 VARIANT 数据类型、异步 I/O、新的 SQL 解析器以及新的存储格式。 此次重大发布极大地扩展了 DuckDB 超越其传统嵌入式进程内模型的能力,可能使其更直接地与客户端-服务器分析型数据库竞争。新特性,特别是服务器模式和触发器,可能为生产环境和数据流水线解锁新的用例,从而扩大其对企业数据团队的吸引力。 该版本的代号为 ‘Variegata’,代表了数据库的一次重大演进。虽然预览版重点介绍了主要新增功能,但完整的变更范围以及任何潜在的向后兼容性考虑将在最终版本发布时详细说明。

hackernews · ibotty · 8月17日 13:46 · 社区讨论

核验: 多源印证

背景: DuckDB 是一个开源的进程内分析型数据库管理系统(OLAP)。与需要独立服务器进程的传统数据库不同,DuckDB 作为嵌入式数据库在主机应用程序内运行,类似于 SQLite,但其针对大型数据集的复杂分析查询进行了优化。由于其简单性、高性能和丰富的 SQL 支持,它在数据工程领域用于本地开发、ETL 流程和交互式分析方面获得了广泛欢迎。

参考链接

社区讨论: 社区对 v2.0 表达了强烈的期待,特别是对新的 ‘Quack’ 服务器功能。用户赞扬 DuckDB 在多个公司中表现出的性能和多功能性。讨论还包括关于 AI 对快速开发节奏影响的疑问、与 ClickHouse 等竞争对手相比增量物化视图功能的缺失,以及呼吁支持数据库研究资助。

标签: #databases, #data-engineering, #open-source, #analytics, #release


黄仁勋宣布 NVIDIA 与 SB Energy 合作,在俄亥俄州为 OpenAI 建设大型 AI 工厂,目标 2030 年达 16 吉瓦算力。 ⭐️ 8.6/10

NVIDIA 首席执行官黄仁勋宣布与 SB Energy 合作,锁定俄亥俄州 PORTS-Pike 科技园区的土地、电力和外壳容量,用于建设一个专用的 AI 工厂,OpenAI 将作为主要租户。初始部署预计提供 4.25 吉瓦的 AI 工厂容量,OpenAI 已承诺到 2030 年部署约 12 吉瓦的 NVIDIA 算力,并可扩展至 16 吉瓦。 此次合作是对下一代 AI 所需物理基础设施的一次大规模长期投资,直接连接了算力供应方(NVIDIA)、能源与数据中心基础设施方(SB Energy)以及领先的 AI 消费者(OpenAI)。这标志着为确保和扩展“智能基础设施”而采取的战略举措,可能决定未来 AI 发展的速度和规模,并创造数千亿美元的经济机会。 该项目涉及为 NVIDIA 的 AI 工厂专门锁定“LPS 容量”(可能指大规模电力采购协议)。预计每一代系统将包含约 150 万块 NVIDIA GPU,每代系统对应的收入机会在 1500 亿至 2000 亿美元之间,总机会估计约为 6000 亿美元。

aihot · X:Jensen Huang (@JensenHuang) · 8月17日 12:40 · 中文阅读

核验: 多源印证

背景: “AI 工厂”是一种专门的计算基础设施,旨在管理从数据摄取到训练和推理的整个 AI 生命周期,其核心产品是智能。SB Energy 是一家专注于开发关键基础设施的美国数据中心和电力平台,由软银集团和 Ares Management 支持。俄亥俄州的 PORTS 园区是一个主要的工业和物流中心,适合建设大规模、高耗电的计算设施。

参考链接

社区讨论: 社区情绪复杂,一些人庆祝该项目是对美国基础设施和技术领导力的重大推动。然而,一个显著的反驳观点担忧,将 GPU 生产重点放在大型数据中心上可能会加剧消费级硬件的短缺和高价,有用户恳请 NVIDIA 也为普通消费者生产更多 GPU。

标签: #AI Infrastructure, #NVIDIA, #OpenAI, #High-Performance Computing, #Industry Partnership


调查人员使用 AirTag 追踪批量图书运输,发现其终点是亚马逊 AI 训练中心 ⭐️ 8.3/10

2026 年 7 月,调查媒体 404 Media 与一位书商合作,在一批约 1000 本珍本图书的订单中,将一枚 Apple AirTag 放入其中一本书内进行追踪。这批货物最终被运送到拉斯维加斯亚马逊 LAS8 设施的 VGT3 区域,在线员工讨论证实该区域用于对大量图书进行破坏性扫描,以获取 AI 训练数据。 这项调查为亚马逊等大型科技公司如何为其 AI 模型获取训练数据提供了具体的物理证据,使相关猜测变成了有据可查的商业行为。这引发了关于版权、数据获取透明度以及 AI 时代实体文化资产命运的严重伦理和法律问题。 该设施的入口处有一个恐龙拿着书的标志,报道称其寓意非常直白。追踪方法依赖于基于蓝牙的“查找”网络,而非 GPS,来精确定位。这批图书是通过珍本和二手书交易平台 Biblio 订购的。

rss · Simon Willison · 8月17日 15:21 · 2 个来源

核验: 多源印证

背景: 一段时间以来,一直有书商收到大量匿名图书订单的传闻,这些订单被怀疑来自寻求扫描图书以获取训练数据的 AI 公司。Apple AirTag 是一种小型追踪设备,利用蓝牙信号和苹果的“查找”网络来定位物品。Biblio.com 是一个专门交易二手书、珍本书和绝版书的在线市场,连接着全球的卖家和买家。

参考链接

标签: #AI Ethics, #Training Data, #Investigative Journalism, #Amazon, #AI Industry


Cursor 发布 Origin,一个专为并行 AI 智能体工作流设计的 AI 原生代码托管平台。 ⭐️ 8.3/10

Cursor 已正式上线其代码托管平台 Origin,现已向所有付费计划用户开放早期测试版。Origin 专为 AI 智能体从头设计,具备高吞吐性能,例如每秒 22.6 次提交,并内置了 AI 驱动的自动合并冲突解决功能。 此次发布意义重大,因为它解决了 AI 驱动开发中的一个关键瓶颈:像 GitHub 这样的传统 Git 平台并未针对多个 AI 智能体同时工作的并行、高频工作流进行优化。Origin 在 Cursor 生态系统内的纵向整合,有望将代码从生成、审查到合并的整个 AI 编码流程一体化。 Origin 的技术基础来自 Cursor 在 2025 年底收购的 Graphite 团队,该团队擅长用于并行代码变更的“堆叠式 PR 管理”。其初始发布策略侧重于代码审查层和 GitHub 同步功能,以降低用户迁移门槛,完整的托管功能迁移将逐步进行。

twitter · 宝玉 · 8月17日 18:01 · 3 个来源

核验: 多源印证

背景: 并行 AI 智能体编码涉及多个 AI 编码智能体同时处理不同任务,这可能会压垮为顺序性人类工作流设计的传统版本控制系统。堆叠式拉取请求(PR)是一种代码审查方法,将多个有依赖关系的变更在一个堆栈中管理,允许并行审查和合并,这与 AI 智能体的输出模式非常契合。高吞吐 Git 托管是一个新兴的关注领域,旨在应对来自自动化、并发开发活动增加所带来的负载。

参考链接

标签: #AI Agents, #Developer Tools, #Code Hosting, #Cursor, #Workflow Automation


AI Agent 协作平台 Cumora 现已开源 ⭐️ 8.3/10

开发者 ‘yetone’ 开源了 Cumora,这是一个类似 Slack 的平台,其中具备独立人设和记忆的 AI Agent 可以在聊天频道中与人类协作。该项目已在 GitHub 上开源,同时支持云端托管服务(Cumora Cloud)和本地部署模式(BYOA)。 此次开源使得先进的多智能体协作技术更易获取,有望加速将实用的 AI 团队成员集成到日常工作流程中的开发进程。它解决了智能体协调中的关键挑战,例如防止冲突回复,这对于可靠的人机协作至关重要。 该平台设计了一套协调机制,防止智能体基于过时信息行动,并采用一个轻量级模型的’分诊层’来决定何时调用大语言模型,以优化 Token 使用。本地部署需要 PostgreSQL 和 Redis,其云服务目前处于邀请制内测阶段。

twitter · yetone · 8月17日 12:30 · 2 个来源

核验: 多源印证

背景: Cumora 利用了 Model Context Protocol (MCP) 和 OpenAI Responses API 等技术。MCP 是一个连接 AI 应用与外部数据和工具的开源标准。OpenAI Responses API 则是用于构建智能体应用的状态化接口。BYOA(自带智能体)模式允许用户使用自己的 API 订阅(如 Claude Code)在本地运行智能体,减少了供应商锁定。

参考链接

社区讨论: 社区反应凸显了对其相对较小代码库(’不到 14 万行代码’)的惊讶,对 AI 仍在处理 ASCII 艺术图上存在困难的调侃,以及对项目潜力的普遍兴奋。这种参与度表明了对多智能体系统实际实现的浓厚兴趣。

标签: #AI Agents, #Open Source, #Developer Tools, #MCP, #Product Release


Rust 编译器获得原生 GPU 卸载支持,实现安全、可移植的内核 ⭐️ 8.0/10

一篇发表在 arXiv 上的研究论文介绍了一个将 Rust 代码卸载到 GPU 的框架,该框架已直接集成到上游 Rust 编译器(rustc)中。该框架利用 LLVM 的卸载基础设施为 NVIDIA 和 AMD GPU 生成原生代码,旨在为 Rust 中的 GPU 编程提供一个安全、可移植且快速的接口。 这项工作意义重大,因为它将内存安全保证带入了 GPU 编程领域,通过消除对特定供应商语言或不安全指针操作的需求,有望简化 AI/ML、高性能计算和系统性能应用的开发。它可能降低 Rust 开发者利用 GPU 加速的门槛,而无需被锁定在单一的硬件生态系统中。 该框架基于 LLVM 的可移植目标卸载接口构建,目前支持 NVIDIA 和 AMD GPU,并计划扩展到 Intel 和 Apple 目标平台。它承诺在 CPU 和 GPU 内存之间自动进行数据传输,未来还将提供更高级、可能不安全的接口以实现更精细的控制。

hackernews · linggen · 8月17日 17:54 · 社区讨论

核验: 多源印证

背景: GPU 卸载是指将计算任务从中央处理器(CPU)转移到图形处理器(GPU)以加速性能的过程,常用于 AI 和科学计算。传统上,在 Rust 等语言中进行 GPU 编程需要使用外部绑定到特定供应商的框架(如 CUDA),或者为 Vulkan 等编写 SPIR-V 等中间语言的着色器。新框架旨在利用 Rust 现有的中级中间表示(MIR)和 LLVM 后端,将这一功能直接集成到 Rust 编译器中。

参考链接

社区讨论: 社区讨论显示出兴奋与技术审视并存。一些开发者,特别是那些从事自定义 LLM 推理引擎工作的,对无需维护复杂的 GPU 绑定代码感到非常兴奋。另一些人则质疑其通过 LLVM 而非直接从 Rust 的 MIR 定位 GPU 指令集的架构选择,并将该方法与现有的供应商中立解决方案(如 Vulkan/SPIR-V)进行比较。社区也对项目的实际可用性和目标受众感兴趣,询问代码是否已发布以及是否主要面向高性能计算领域。

标签: #Rust, #GPU Programming, #Systems Performance, #AI/ML Infrastructure, #Compiler Research


AI 生成的 GitHub Copilot 建议在 Snowflake 的 Jira 自动化中引入代码注入漏洞 ⭐️ 8.0/10

Wiz 的安全分析显示,Snowflake 一个 Jira 自动化工作流中由 GitHub Copilot 生成的代码建议包含一个 YAML 模板注入缺陷。该漏洞通过一个拉取请求引入,可能允许攻击者在 Snowflake 的 CI/CD 管道中执行任意代码。 这一事件突显了一个关键的新风险向量:AI 辅助编码工具可能无意中将安全漏洞大规模引入企业系统。它强调了在 CI/CD 管道中进行严格代码审查和安全扫描的日益增长的需求,因为 AI 降低了代码生成的门槛,但并未降低安全代码验证的门槛。 该漏洞源于 GitHub Actions 工作流 YAML 文件中一个run块内的 shell 命令对用户输入的处理不当。分析指出,有缺陷的代码是现代化已弃用的 Jira 操作工作的一部分,且包含 Copilot 建议更改的初始拉取请求中只有一个提交由该 AI 工具共同撰写。

hackernews · galnagli · 8月17日 14:18 · 社区讨论

核验: 多源印证

背景: GitHub Copilot 是一个基于 AI 的代码补全工具,可根据上下文建议代码片段。Jira 自动化允许团队在 Jira 问题跟踪系统内自动化重复性任务和流程。代码注入漏洞发生在应用程序将不受信任的数据解释为代码时,允许攻击者执行任意命令,这在控制软件部署的 CI/CD 管道中尤其危险。

参考链接

社区讨论: 讨论强调,核心问题不仅仅是“AI 生成了不安全的代码”,而在于 AI 降低了代码生成成本,但代码审查成本仍然很高的不平衡。评论者指出 YAML 的复杂性是一个促成因素,就相关拉取请求的具体细节进行了辩论,并强调了在 CI 中使用静态分析工具来捕获此类漏洞的必要性。

标签: #AI Security, #CI/CD, #GitHub Copilot, #Vulnerability, #Automation


Hacker News 社区热议对 AI 生成内容的普遍疲劳 ⭐️ 8.0/10

Hacker News 上的一场讨论(获得 524 分、316 条评论)凸显了人们对 AI 生成内容日益增长的疲劳感和负面影响,尤其是在技术文档和代码领域。社区指出了诸如冗长、缺乏细微差别和智力上的懒惰等关键问题。 这种情绪反映了一个关键的转折点,即 AI 生成材料被认为质量低下且泛滥,正在损害专业环境中的沟通、信任和代码可读性。这表明需要更审慎地应用 AI 工具,并可能预示着科技行业将重新评估人类洞察力与自动化产出之间的价值。 具体的抱怨包括代码中 AI 生成的注释冗长且充满术语,以及拉取请求中的文档内容庞杂且无帮助。讨论中一个值得注意的建议是,分享用于生成内容的提示词比分享 AI 的输出本身更有价值。

hackernews · mooreds · 8月17日 19:47 · 社区讨论

核验: 多源印证

背景: Hacker News 是一个专注于计算机科学和创业的知名社交新闻网站,以其社区驱动的讨论而闻名。AI 生成内容疲劳指的是,由于 AI 工具轻易产生大量通用、低价值的内容,导致受众日益感到厌倦,这些内容通常缺乏深度、原创性和人类的细微差别。

参考链接

社区讨论: 社区情绪 overwhelmingly 是负面的,评论者对技术工作中低质量 AI 内容的泛滥感到沮丧。关键观点包括:认为 AI 生成的回复因智力上的懒惰而令人反感;哀叹代码可读性下降;以及建议分享原始提示词比分享生成的文本更诚实、更有用。

标签: #AI Ethics, #Developer Tools, #Content Generation, #Community Discussion, #Workflow Automation


Thibault Sottiaux 宣布推出 Codex,一个近乎 100% 可靠的开源 AI 开发者工具。 ⭐️ 8.0/10

Thibault Sottiaux 宣布了一款名为 Codex 的新 AI 开发者工具,该工具被描述为近乎 100% 可靠、开源且偶尔需要重置。该公告还指出,Codex 未来将与一个名为 Astra 的平台集成。 这一公告意义重大,因为它为竞争激烈的 AI 编程助手领域引入了一个高度可靠的开源替代方案,有可能降低开发者的门槛并促进社区驱动的创新。与 Astra 的集成计划表明,该项目正朝着构建一个更全面的 AI 驱动开发或自动化生态系统迈进。 该工具宣称的“近乎 100% 可靠性”是一个关键卖点,但其在复杂现实场景中的性能仍有待验证。提及“偶尔需要重置”表明该系统可能仍需要人工干预,或者具有特定的运行状态。

follow_builders · Thibault Sottiaux · 8月17日 00:36

核验: 多源印证

背景: AI 编程助手,如 OpenAI 的 Codex CLI,是通过生成、解释或调试代码来协助开发者的工具。此处的“Astra”一词含义模糊;它可能指 Google DeepMind 的 Project Astra(一个通用 AI 助手的研究原型),也可能指其他专注于分析或创意自动化的同名平台。该公告似乎是为一个名为 Codex 的新的、独立的工具发布的,与 OpenAI 的产品没有直接关系。

参考链接

标签: #AI Developer Tools, #Open Source, #AI Agents, #Automation, #Product Launch


Guillermo Rauch 分享链接,可能宣布新进展。 ⭐️ 7.0/10

Vercel 创始人 Guillermo Rauch 在社交媒体上分享了一个链接,内容很可能与 AI 或开发者工具相关的公告或讨论。现有信息中未提供链接材料的具体内容。 作为开发者生态中的重要人物,Rauch 的公告通常预示着可能影响 Web 开发、AI 集成和开发者工作流程的新工具或趋势。该帖子的高参与度表明了社区的浓厚兴趣,以及其对开发者工具发展方向可能产生的影响。 该新闻条目仅是一个包含链接的社交媒体帖子,没有对其内容进行直接描述。其高评分和标签表明社区推断其与 AI 开发者工具、产品发布或工作流自动化相关,但这仅是基于上下文的推测,而非明确的细节。

follow_builders · Guillermo Rauch · 8月17日 02:36

核验: 已核对原文

背景: Guillermo Rauch 是 Vercel 公司的 CEO 和创始人,该公司以其 Next.js 框架和面向 Web 开发的前端云平台而闻名。Vercel 一直积极将 AI 能力集成到其开发者平台中,而 Rauch 是现代 Web 开发社区的关键影响者。

标签: #AI Developer Tools, #Product Announcement, #Workflow Automation, #Open Source



更多追踪内容

以下内容已于今日成功抓取,但未进入上方主列表。

其他追踪推文

Twitter/X · @dotey · 8月17日 17:32 UTC · 喜欢 105 · 转发 14 · 回复 22 · 浏览 19200

yetone 开源了一个新项目 Cumora:把 AI Agent 变成你的聊天群里的正式成员。

Cumora 的界面长得像 Slack,但名单上的同事看起来都是 AI。有名字、有人设、有记忆,能发私聊、能建群、能认领任务,甚至能收发真实邮件。你不 @ 它们,它们也可能主动跳出来说一句“我注意到上周那个问题还没解决”。

从截图看,默认团队里有 Atlas(研究员)、Bram(工程师)、Iris、Nova、Saga 这些角色,人类和 Agent 在同一个频道里讨论问题,界面上几乎分不清谁是人谁是 AI。左侧栏里既有人和 Agent 的一对一私聊,也有多人群聊,还有看板和日历。

技术上有两种运行方式。一种是 Cumora Cloud,Agent 跑在云端托管的 Kubernetes Pod 里,用 OpenAI 的 Responses API 驱动。另一种叫 BYOA(Bring Your Own Agent),你在自己的电脑上跑一行 npx cumora agent computer,Agent 的"大脑"就变成你本地的 Claude Code 或 Codex CLI,用你自己的订阅,密钥不经过 Cumora 的服务器。

多 Agent 协作最怕的就是撞车,几个 Agent 同时抢着回答同一个问题,或者基于过时的上下文给出矛盾的回复。Cumora 设计了一套协调机制来处理这个问题:如果一个 Agent 的回复基于过时的信息,系统会把它拦下来,让它看完新消息再决定要不要发;任务认领是原子操作,不会出现两个 Agent 同时做一件事;还有一个小脑分诊层,先用轻量模型判断该不该唤醒大模型,避免每条消息都烧 Token。

目前 Cumora 处于邀请制内测阶段,可以在 https://t.co/y0gEUiFlBT 用 Google 或 GitHub 账号申请。项目完整开源在 GitHub(yetone/cumora https://t.co/vUDDFuvOJu),支持本地部署,装好 Postgres 和 Redis 就能跑起来。桌面端支持 macOS、Windows 和 Linux,移动端 iOS 也在计划中。

Twitter/X · @dotey · 8月17日 16:42 UTC · 喜欢 42 · 转发 6 · 回复 4 · 浏览 7653

这个问题其实还挺典型的,软件工程越来越重要这个观点我很赞同

在以往的传统软件工程中,我们在写代码之前会先明确需求 -> 架构设计 -> 接口设计 -> 模块实现 ... 这样的流程

当下的 AI 虽然非常非常聪明了,但它无法知道它应该知道但你没告诉它的事(看起来像废话吗?其实不是)。比如这个项目的预期维护周期,是一个临时小工具,还是一个会持续迭代几年的大项目?项目需求是否会持续迭代,随着迭代可能的架构相对变化和不变的地方都有哪些?

这些问题,如果你不告诉 AI 的话,它一般会以最小可实现代码来实现,以免过度设计

我现在 Vibe Coding 的感觉是,有些东西是不能完全交给 AI 的(至少是和 AI 共同结对编程来明确),比如 整体架构、表结构、数据结构、接口设计 这些

当然我也有直接 /goal 的时候,这种情况还挺多,就是在一次性小项目或者一个原型项目的时候,我希望能尽快出来看看效果,而不是长期维护

如果这个小项目后续要变成长期维护项目了,我会新开一个项目,不留历史包袱,直接重写一个架构良好的新项目出来

“何时重构” 这个问题甚至有时候是一种感觉,一种品味。就像以前软件工程里说的 bad smell 一样,AI 时代我们每个人都要锻炼这种敏锐度。但无论如何,我认为应该记住一点:重构,在任何时候都是软件生命周期中必不可少的一环

Twitter/X · @dotey · 8月17日 01:33 UTC · 喜欢 22 · 转发 0 · 回复 41 · 浏览 17332

其实不用担心代码命名的问题,agent 并不是简单通过猜关键字去找代码的,它会阅读代码片段,根据上下文去找。

举个例子来说,它发现程序崩溃了,它会先根据错误日志去定位到崩溃的位置,然后先阅读这部分的代码,以此为起点,再去找相关的代码,直到上下文足够定位问题,再去生成修复的代码。

其他 Follow Builders 资讯

中文标题Nikunj Kothari:今年你从头到尾读过的最喜欢的论文是什么?另外...

Follow Builders · X 动态 · Nikunj Kothari · 8月17日 04:48 UTC · 喜欢 3 · 转发 1 · 回复 2

A social media user asks for recommendations on favorite technical papers and sci-fi reads from the past year.

中文摘要一位社交媒体用户征求过去一年中最喜欢的论文和科幻读物的推荐。

中文标题Aaron Levie:关于 AI 智能体价值及其机会所在的绝佳思考方式

Follow Builders · X 动态 · Aaron Levie · 8月17日 04:34 UTC · 喜欢 88 · 转发 5 · 回复 17

Aaron Levie proposes that the core value of AI agents lies in applying tireless intelligence to tasks that were previously impractical, not due to lack of desire or value, but due to sheer scale or complexity.

中文摘要Aaron Levie 提出,AI 智能体的核心价值在于将不知疲倦的智能应用于那些以前因规模或复杂性而不切实际的任务上。

中文标题Peter Yang:我想用这个功能,但又担心它会耗尽我所有的 Token。它的 Token 效率高吗?

Follow Builders · X 动态 · Peter Yang · 8月17日 04:21 UTC · 喜欢 39 · 转发 0 · 回复 20

A user expresses concern about token consumption efficiency when considering using an unspecified AI feature.

中文摘要一位用户对考虑使用某个未指明的 AI 功能时,表达了对其 Token 消耗效率的担忧。

中文标题Peter Yang:如何设置这个东西使其在所有应用中都有效,而不仅仅是 Codex?

Follow Builders · X 动态 · Peter Yang · 8月17日 02:46 UTC · 喜欢 28 · 转发 0 · 回复 19

A user asks a vague question about configuring an unspecified tool to work across applications beyond a specific one (potentially Codex).

中文摘要用户提出了一个关于如何配置一个未指明的工具以在特定应用(可能是 Codex)之外的所有应用程序中工作的模糊问题。

中文标题Peter Steinberger:想知道这个我没启用、加载缓慢的菜单栏新图标是什么

Follow Builders · X 动态 · Peter Steinberger · 8月17日 00:55 UTC · 喜欢 147 · 转发 4 · 回复 33

A user complains about an unexplained, slow-loading menu bar icon in Chrome, suggesting it might be time for a 'Chrome Lite'.

中文摘要用户抱怨 Chrome 中出现一个未启用且加载缓慢的菜单栏图标,暗示可能是时候需要一个'Chrome Lite'了。

中文标题Thibault Sottiaux: GPT-5.6 Sol 1M in Codex。这功能以前只适用于 API 密钥,但我们刚刚切换了开关...

Follow Builders · X 动态 · Thibault Sottiaux · 8月17日 00:13 UTC · 喜欢 3686 · 转发 171 · 回复 445

OpenAI has enabled the 1 million token context window for Codex within ChatGPT accounts, a feature previously limited to API users.

中文摘要OpenAI 已为 ChatGPT 账户内的 Codex 启用了 100 万 token 的上下文窗口,该功能此前仅限于 API 用户。