8月23日2026 · 星期日

从 17 条抓取中筛选 12 条 · twitter × 5 账号 · 00:48 UTC 生成

今日信号 · 高度即评分 · 点击直达

colibri：以低于10GB内存流式运行744B MoE模型8.0
Anthropic 发布面向 AI 智能体的零信任指南8.0
AI不会取代工程师，但会重塑他们的工作方式7.0
OpenLogi：用 Rust 重写的罗技 Options+ 本地优先替代方案7.0
Wake：原生 macOS 应用，可搜索并恢复编码 Agent 的对话记录7.0
Pixel Snapper 修复 AI 生成的像素画：对齐网格并量化调色板7.0
OpenCore Legacy Patcher 让不受支持的旧 Mac 也能运行新版 macOS7.0
OpenAI 为付费 ChatGPT Work 和 Codex 用户推出累积重置功能7.0
Pi 的压缩机制如交接班：压缩旧上下文并重建继续7.0
用爬山法优化AI评估：一次聚焦一个维度7.0
HTML/React 被认为是 AI 生成可编辑图表的最佳格式6.0
用户通过ChatGPT Sites构建音乐应用分享专辑6.0

018.0

colibri：以低于10GB内存流式运行744B MoE模型

colibri 是一个零依赖的 C 语言库，通过按需从磁盘流式加载模型权重，开创了在消费级硬件上运行大规模混合专家（MoE）模型的新方法。它将显存、内存和硬盘视为统一的存储层次，使得 744B 的 GLM-5.2 模型能够在 CPU 上以 int4 量化运行，常驻内存低于 10GB。该项目已获得超过 25,000 个 GitHub star，并支持从 35B Qwen3.6 到 2.8T Kimi K3 的六个模型家族。这一突破使前沿规模的 MoE 模型平民化，这类模型通常需要数百 GB 的显存和昂贵的数据中心 GPU。通过实现在 32GB 内存的机器上推理，colibri 使个人开发者、研究人员和爱好者能够在本地试验万亿参数模型，减少对昂贵 API 服务的依赖。它解决了 AI 社区的一大痛点，并可能加速边缘和个人 AI 应用的创新。 colibri 将稠密层常驻在内存中（约 10GB），仅从磁盘流式加载被路由到的专家权重，因此完整模型无需一次性装入 RAM。推理速度高度依赖磁盘 I/O，快速的 NVMe SSD 是决定每秒 token 数的最大因素。该库内置网页仪表盘，可实时可视化 19,456 个专家的路由热度，并在专家被调用时闪烁。它用纯 C 编写，零依赖，支持 CPU 和 GPU 执行。

@GitHub_Daily原推文1 张图片想在自己电脑上跑大模型，一看动辄几百 GB 的权重和显存要求，基本就放弃了。 colibri 换了个思路，把显存、内存和硬盘当成一个整体来调度，权重按需从硬盘流式加载，纯 C 写的零依赖，已斩获 25000+ Star！支持的全是前沿 MoE 模型，从 35B 的 Qwen3.6 到 2.8T 的 Kimi K3 共六个家族，每个模型就一个 C 文件。 GitHub：http://github.com/JustVugg/colibri 官方演示里 744B 的 GLM-5.2 用 int4 量化在 CPU 上流式跑了起来，常驻内存不到 10 GB。自带网页仪表盘，19456 个专家的路由热度实时可视化，哪个专家被调用会闪一下，看着挺震撼的。内存不缺的机器都可以拉下来试试，亲手摸一摸千亿级模型，和租 API 是两种感觉。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

想在自己电脑上跑大模型，一看动辄几百 GB 的权重和显存要求，基本就放弃了。 colibri 换了个思路，把显存、内存和硬盘当成一个整体来调度，权重按需从硬盘流式加载，纯 C 写的零依赖，已斩获 25000+ Star！支持的全是前沿 MoE 模型，从 35B 的 Qwen3.6 到 2.8T 的 Kimi K3 共六个家族，每个模型就一个 C 文件。 GitHub：http://github.com/JustVugg/colibri 官方演示里 744B 的 GLM-5.2 用 int4 量化在 CPU 上流式跑了起来，常驻内存不到 10 GB。自带网页仪表盘，19456 个专家的路由热度实时可视化，哪个专家被调用会闪一下，看着挺震撼的。内存不缺的机器都可以拉下来试试，亲手摸一摸千亿级模型，和租 API 是两种感觉。

背景

混合专家（MoE）是一种用于许多前沿大语言模型的架构，每个 token 只激活一部分“专家”子网络，从而减少计算量，但需要庞大的总参数量。传统推理将所有权重加载到 GPU 内存中，这对于消费级硬件上数百亿参数的模型是不可行的。colibri 利用专家激活的稀疏性，仅从磁盘流式加载所需的专家权重，并利用稠密层相对较小的特点。int4 等量化技术降低权重精度以进一步减少内存占用。该项目的方法类似于早期的“卸载”方法，但针对 MoE 模型进行了优化，并用无依赖的 C 语言实现以保证可移植性。

8月22日 08:31在 X 打开#LLM #MoE #open-source #inference #memory optimization

028.0

Anthropic 发布面向 AI 智能体的零信任指南

Anthropic 发布了一份 36 页的指南《面向 AI 智能体的零信任》，提出了用于保障 AI 智能体部署安全的“最小代理权”概念。该指南概述了三阶段方法：静态最小权限角色、任务范围权限提升，以及自动过期的即时访问。该指南以 PDF 形式在 Anthropic 网站上提供。随着 AI 智能体获得更多自主权并访问工具和数据，基于静态权限的传统安全模型已不再适用。“最小代理权”框架通过确保智能体仅拥有特定任务所需的权限，填补了 AI 部署安全的关键空白，降低了滥用或利用的风险。来自主要 AI 实验室的这份指南很可能影响行业最佳实践。该指南强调“最小代理权”是 AI 智能体零信任的实用实现，超越了简单的最小权限，纳入了任务范围和时限访问。它建议保持智能体身份稳定以便进行生命周期管理，同时使用即时权限提升来授予窄范围特权。该 PDF 托管在 Anthropic 的 CDN 上，并通过 @bibryam 的推文分享。

@bibryam原推文1 张图片🔖 Anthropic’s Zero Trust for AI Agents A useful 36-page guide for anyone shipping agents. The practical idea is “least agency”: static least-privilege roles → task-scoped elevation → just-in-time access that expires automatically. https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6a1611a04085d7cd3dadc924_Claude-eBook-Zero-Trust-for-AI-Agents-05182026.pdf 原推文媒体预览

展开原推文收起原推文

@bibryam

🔖 Anthropic’s Zero Trust for AI Agents A useful 36-page guide for anyone shipping agents. The practical idea is “least agency”: static least-privilege roles → task-scoped elevation → just-in-time access that expires automatically. https://cdn.prod.website-files.com/6889473510b50328dbb70ae6/6a1611a04085d7cd3dadc924_Claude-eBook-Zero-Trust-for-AI-Agents-05182026.pdf

背景

零信任是一种安全模型，默认不信任任何用户或系统，即使在网络边界内也是如此。最小权限是零信任的核心原则，仅授予任务所需的最低权限。AI 智能体是能够代表用户执行操作的自主系统，通常需要访问各种工具和数据。Anthropic 是一家以 Claude 语言模型闻名的 AI 安全公司。

8月22日 10:48在 X 打开#AI agents #Zero Trust #security #Anthropic #AI deployment

037.0

AI不会取代工程师，但会重塑他们的工作方式

由@xicilion提出、@dotey转发的观点用洗碗机类比指出：AI工具将自动化标准编程任务，但人类工程师在处理边缘情况和日益增长的复杂性方面仍不可或缺。该观点认为，随着AI处理更多常规工作，软件行业的总产出将扩大，从而产生仍需人类专业知识填补的新“缝隙”。这一观点为对大规模失业的担忧提供了一个细致入微的反驳，表明AI将改变而非消灭工程师角色。它强调了自动化投资回报递减的经济原理，这可以指导科技公司的战略决策，并影响开发者的职业规划。该类比将洗碗机比作能替代三个洗碗工，但无法处理异形锅、烧焦的铁板和精致瓷器，最后5%的餐具仍需人工。文章认为，为这5%开发超级洗碗机的成本可能是前95%的十倍，因此使用人力更划算。文章还指出，随着工具变得更强大，行业总产出会扩大，边缘情况的绝对数量也会增加。

@dotey引用推文响马高见： > 工程师永远不会消失，但是工作方式会变化。工具化永远会进化到 roi 低于人力的边界，然后需要更多的人力来补齐最后的缝隙。类似于你开了一家餐厅，买了一台洗碗机，一下子替代了 3 个洗碗工，效率高、成本低。这就是工具化带来的 ROI（投入产出比）远高于人力的阶段。但洗碗机洗不了所有东西。异形的锅、烧焦的铁板、精致的瓷器，这些还得靠人手洗。你可以花大价钱去研发一台能洗一切的超级洗碗机，但为了搞定最后这 5% 的餐具，你可能得投入比前面 95% 多十倍的钱。这时候你算一笔账：与其砸钱造那台超级机器，不如留一个洗碗工来处理这些边角料，人力反而更划算了。工具进化到某个点之后，再往前推的成本急剧上升，ROI 跌到比直接用人还低。另一个角度，工具越强，整个行业的总产出往往也在膨胀。洗碗机让你的餐厅能接待更多客人，于是产生了更多的异形锅、更多的特殊情况，那些“缝隙”的绝对数量反而变多了。所以你可能裁了 3 个普通洗碗工，最后又请了 2 个专门处理疑难杂症的人。 AI 工具会吃掉大量标准化的编程工作，但软件行业的总规模也会因此爆发式增长，而增长带来的各种边界情况、系统集成、业务理解这些“缝隙”，短期内仍然需要人来填。展开原推文收起原推文

@dotey

响马高见： > 工程师永远不会消失，但是工作方式会变化。工具化永远会进化到 roi 低于人力的边界，然后需要更多的人力来补齐最后的缝隙。类似于你开了一家餐厅，买了一台洗碗机，一下子替代了 3 个洗碗工，效率高、成本低。这就是工具化带来的 ROI（投入产出比）远高于人力的阶段。但洗碗机洗不了所有东西。异形的锅、烧焦的铁板、精致的瓷器，这些还得靠人手洗。你可以花大价钱去研发一台能洗一切的超级洗碗机，但为了搞定最后这 5% 的餐具，你可能得投入比前面 95% 多十倍的钱。这时候你算一笔账：与其砸钱造那台超级机器，不如留一个洗碗工来处理这些边角料，人力反而更划算了。工具进化到某个点之后，再往前推的成本急剧上升，ROI 跌到比直接用人还低。另一个角度，工具越强，整个行业的总产出往往也在膨胀。洗碗机让你的餐厅能接待更多客人，于是产生了更多的异形锅、更多的特殊情况，那些“缝隙”的绝对数量反而变多了。所以你可能裁了 3 个普通洗碗工，最后又请了 2 个专门处理疑难杂症的人。 AI 工具会吃掉大量标准化的编程工作，但软件行业的总规模也会因此爆发式增长，而增长带来的各种边界情况、系统集成、业务理解这些“缝隙”，短期内仍然需要人来填。

@xicilion

工程师永远不会消失，但是工作方式会变化。工具化永远会进化到 roi 低于人力的边界，然后需要更多的人力来补齐最后的缝隙。

背景

ROI（投资回报率）衡量一项投资相对于其成本的盈利能力。在自动化中，当工具以低成本取代许多工人时，ROI很高，但当工具试图处理越来越罕见或复杂的情况时，ROI会递减。软件行业见证了AI编码助手的快速增长，它们可以生成样板代码，但在处理细微需求、集成和调试方面往往力不从心。

8月22日 15:01在 X 打开#AI #software engineering #automation #ROI #future of work

047.0

OpenLogi：用 Rust 重写的罗技 Options+ 本地优先替代方案

OpenLogi 是一个用 Rust 编写的新开源项目，旨在替代罗技的 Options+ 软件。它无需账号、不发送任何遥测数据，并在 Linux、macOS 和 Windows 上提供完整功能。该项目在 GitHub 上已获得超过 13000 颗星。这解决了罗技官方软件长期存在的隐私和可用性问题——官方软件要求注册账号并常驻后台。通过提供本地优先、跨平台的替代方案，OpenLogi 让用户能够在不牺牲隐私的情况下完全控制自己的罗技外设。它也体现了用 Rust 工具替代专有系统实用程序的增长趋势。 OpenLogi 通过 Logi Bolt、Unifying 接收器、蓝牙或 USB 与罗技 HID++ 外设通信。配置通过单个 TOML 文件完成，可以轻松在不同机器间复制。它支持按应用切换配置、DPI 切换、SmartShift 滚轮阻尼和触发力度调节，甚至还能控制罗技的补光灯和摄像头（变焦、对焦、曝光）。

@GitHub_Daily原推文1 张图片罗技的鼠标键盘都挺好用，但配套的 Options+ 软件交互真的一言难尽，开机常驻还得注册个账号才能改按键。 OpenLogi 用 Rust 重写了这套驱动，不要账号，不往外传任何数据，Linux 上功能同样齐全，已斩获 13000+ Star！按键随便改，DPI 分档切换，SmartShift 滚轮的阻尼和触发力度也能调，手势可以绑到任意一个物理按键上。 GitHub：http://github.com/AprilNEA/OpenLogi 所有配置就是一个 TOML 文本文件，换台机器直接拷过去，比在图形界面里一层层翻设置省事。按应用自动切配置也在，切到 Figma 一套键位，切回浏览器又是另一套。罗技的补光灯和摄像头也一并管了，变焦、对焦、曝光直接写进硬件，改完在 Zoom、OBS 里同步生效。桌上摆着罗技外设、又嫌 Options+ 太重的，可以换它试试，macOS、Linux、Windows 三端都有。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

罗技的鼠标键盘都挺好用，但配套的 Options+ 软件交互真的一言难尽，开机常驻还得注册个账号才能改按键。 OpenLogi 用 Rust 重写了这套驱动，不要账号，不往外传任何数据，Linux 上功能同样齐全，已斩获 13000+ Star！按键随便改，DPI 分档切换，SmartShift 滚轮的阻尼和触发力度也能调，手势可以绑到任意一个物理按键上。 GitHub：http://github.com/AprilNEA/OpenLogi 所有配置就是一个 TOML 文本文件，换台机器直接拷过去，比在图形界面里一层层翻设置省事。按应用自动切配置也在，切到 Figma 一套键位，切回浏览器又是另一套。罗技的补光灯和摄像头也一并管了，变焦、对焦、曝光直接写进硬件，改完在 Zoom、OBS 里同步生效。桌上摆着罗技外设、又嫌 Options+ 太重的，可以换它试试，macOS、Linux、Windows 三端都有。

背景

罗技 Options+ 是罗技鼠标、键盘及其他外设的官方配套软件。它允许用户自定义按键、调整 DPI 和配置设备特定功能，但需要账号并运行后台服务。HID++ 是罗技用于与其设备通信的专有协议。TOML 是一种人类可读的配置文件格式，易于解析和编辑。

8月23日 00:00在 X 打开#Rust #Open Source #Logitech #Driver #Privacy

057.0

Wake：原生 macOS 应用，可搜索并恢复编码 Agent 的对话记录

Wake 是一款新的原生 macOS 应用，可索引并搜索来自 14 种编码 Agent（包括 Claude Code、Codex、Gemini CLI 和 OpenCode）的对话记录。它提供全文和代码搜索，支持中文和代码片段匹配，并允许在终端中一键恢复会话。该应用使用 Rust 编写，要求 macOS 14 及以上版本，索引 800 MB 会话数据仅需约 5 秒。开发者经常使用多个编码 Agent，却难以找到过去的对话或解决方案。Wake 通过跨工具统一搜索解决了这一痛点，节省时间并减少上下文切换。其注重隐私的设计（只读、零网络请求）使其适用于敏感代码库。 Wake 支持 14 种工具，包括 Claude Code、Codex、Gemini CLI 和 OpenCode。它提供全文搜索，可精确匹配中文和代码片段，点击结果可直接跳转到该消息。该应用为只读，零网络请求，索引 800 MB 会话数据约需 5 秒。它使用 Rust 编写，要求 macOS 14 或更高版本。

@GitHub_Daily原推文1 张图片明明记得上周跟 Claude Code 讨论过一个方案，想再翻出来，找半天没找到那对话。 Wake 把 Mac 上所有 Agent 的历史会话收进一个原生应用，统一浏览、全文搜索、一键恢复。支持 Claude Code、Codex、Gemini CLI、OpenCode 等 14 种工具，搜索连中文和代码片段都能精确匹配，点结果直接跳到那条消息。 GitHub：http://github.com/iAmCorey/Wake 找到会话后一键在终端里恢复现场，自动回到原来的项目目录接着聊。所有工具的数据只读访问，全程零网络请求，作者机器上 800 MB 的会话记录建索引只要 5 秒。 Rust 写的原生应用，要求 macOS 14 以上。同时用好几个编码 Agent 的，装一个当会话档案馆挺合适。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

明明记得上周跟 Claude Code 讨论过一个方案，想再翻出来，找半天没找到那对话。 Wake 把 Mac 上所有 Agent 的历史会话收进一个原生应用，统一浏览、全文搜索、一键恢复。支持 Claude Code、Codex、Gemini CLI、OpenCode 等 14 种工具，搜索连中文和代码片段都能精确匹配，点结果直接跳到那条消息。 GitHub：http://github.com/iAmCorey/Wake 找到会话后一键在终端里恢复现场，自动回到原来的项目目录接着聊。所有工具的数据只读访问，全程零网络请求，作者机器上 800 MB 的会话记录建索引只要 5 秒。 Rust 写的原生应用，要求 macOS 14 以上。同时用好几个编码 Agent 的，装一个当会话档案馆挺合适。

背景

Claude Code 和 Codex 等编码 Agent 是 AI 工具，可通过生成代码、回答问题以及在终端中执行任务来辅助软件开发。它们会在本地存储对话历史，但这些历史通常分散在不同的工具和目录中。Wake 是一款 macOS 应用程序，可将这些历史记录聚合到一个可搜索的界面中，类似于 Spotlight 索引文件的方式。它使用 Rust 构建，Rust 是一种以性能和安全著称的系统编程语言，并利用原生 macOS API 提供快速、离线的体验。

8月22日 13:30在 X 打开#developer-tools #AI-agents #productivity #macOS #open-source

067.0

Pixel Snapper 修复 AI 生成的像素画：对齐网格并量化调色板

Pixel Snapper 是一款新工具，通过将每个像素对齐到一致的网格并将颜色量化到严格的调色板来修复 AI 生成的像素画。它提供网页版、桌面版和命令行版，使用 Rust 编写，并编译为 WebAssembly 以便集成。该工具可自动检测像素大小或手动指定，并支持对整个目录进行批量处理。 AI 生成的像素画经常出现像素大小不一致、网格错位以及颜色不在统一调色板内的问题，导致无法直接用于游戏开发。Pixel Snapper 解决了这一痛点，使开发者能够将 AI 生成的素材直接用于游戏引擎。这为依赖 AI 进行快速原型设计的独立开发者和小团队简化了素材流程。默认调色板为 16 色，但用户可以传入自己游戏使用的调色板。该工具能够保留抖动纹理，README 中的对比图展示了这一点。它支持自动和手动像素大小检测，并可批量处理目录。该项目在 GitHub 上开源，仓库地址为 Hugo-Dz/spritefusion-pixel-snapper。

@GitHub_Daily原推文1 张图片用 AI 生成像素风素材，放大一看就穿帮，像素忽大忽小、网格是歪的，颜色也不在一个调色板里。 Pixel Snapper 专治这个，把 AI 生成的像素画重新吸附到规整网格上，像素尺寸统一，颜色量化进严格的调色板。默认 16 色，也能传自己游戏在用的调色板，出来的图能按像素分辨率无损缩放。 GitHub：http://github.com/Hugo-Dz/spritefusion-pixel-snapper README 里的对比图连抖动纹理都留住了，处理得比预想的细。像素大小能自动检测也能手动指定，一次丢一个目录进去批量处理也行。网页版打开就能用，另有桌面版和命令行版，Rust 写的，还编译成了网页组件方便集成进自己的项目。经常用 AI 出像素素材做游戏的，出图后过一遍它，素材就能直接进引擎用了。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

用 AI 生成像素风素材，放大一看就穿帮，像素忽大忽小、网格是歪的，颜色也不在一个调色板里。 Pixel Snapper 专治这个，把 AI 生成的像素画重新吸附到规整网格上，像素尺寸统一，颜色量化进严格的调色板。默认 16 色，也能传自己游戏在用的调色板，出来的图能按像素分辨率无损缩放。 GitHub：http://github.com/Hugo-Dz/spritefusion-pixel-snapper README 里的对比图连抖动纹理都留住了，处理得比预想的细。像素大小能自动检测也能手动指定，一次丢一个目录进去批量处理也行。网页版打开就能用，另有桌面版和命令行版，Rust 写的，还编译成了网页组件方便集成进自己的项目。经常用 AI 出像素素材做游戏的，出图后过一遍它，素材就能直接进引擎用了。

背景

像素画是一种在像素级别创建图像的数字艺术形式，通常使用有限的调色板来营造复古美感。AI 图像生成器可以生成类似像素画的图像，但往往无法保持一致的像素网格或调色板，导致出现混合像素和模糊边缘。网格对齐是将每个像素对齐到固定网格的过程，而颜色量化则是将颜色数量减少到预定义集合。这些技术对于使像素画在游戏引擎中可用至关重要，因为素材必须能够干净地缩放并匹配游戏的视觉风格。

8月22日 10:00在 X 打开#AI #pixel art #game development #tool #Rust

077.0

OpenCore Legacy Patcher 让不受支持的旧 Mac 也能运行新版 macOS

OpenCore Legacy Patcher（OCLP）让 2007 年及以后的老款 Mac 也能安装并运行 macOS Big Sur 及更新版本，包括 macOS 15 Sequoia。该项目在 GitHub 上已获得超过 18000 颗星，并提供详细的文档。它支持 Wi-Fi、显卡加速和个人热点，安装后系统更新也能正常推送。该工具延长了旧款 Intel Mac 的使用寿命，减少了电子垃圾，并让用户无需购买新硬件。对于依赖旧 Mac 工作或日常使用、但又希望获得现代 macOS 功能和安全更新的用户来说，它尤其有价值。项目的高人气反映了社区对让旧硬件继续发挥作用的强烈需求。 OCLP 仅适用于 Intel Mac，不支持 PowerPC 或 Apple Silicon 机型。目前它支持从 macOS 11 Big Sur 到 macOS 15 Sequoia 的系统。该工具通过在内存中打补丁来工作，因此更改不是永久性的，可以撤销。某些功能（如 Metal 应用）在不支持 Metal 的 GPU 上可能无法使用。

@GitHub_Daily原推文1 张图片OpenCore Legacy Patcher，能让苹果已经停止支持的旧电脑装上新系统。即便是 2007 年的老机器，也都能安装和使用 macOS Big Sur 及更新版本。 Wi-Fi、显卡加速、个人热点都有适配，装完系统更新照样正常推送。 GitHub：http://github.com/dortania/OpenCore-Legacy-Patcher 项目已斩获 18000+ Star，文档写得很细。家里有旧的 Mac 电脑，想更新系统可以看下。原推文媒体预览

展开原推文收起原推文

@GitHub_Daily

OpenCore Legacy Patcher，能让苹果已经停止支持的旧电脑装上新系统。即便是 2007 年的老机器，也都能安装和使用 macOS Big Sur 及更新版本。 Wi-Fi、显卡加速、个人热点都有适配，装完系统更新照样正常推送。 GitHub：http://github.com/dortania/OpenCore-Legacy-Patcher 项目已斩获 18000+ Star，文档写得很细。家里有旧的 Mac 电脑，想更新系统可以看下。

背景

苹果会在 Mac 使用一定年限后正式停止软件支持，这意味着它们不再获得新的 macOS 版本或安全更新。OpenCore 最初是为黑苹果系统开发的引导加载程序，OCLP 利用它在不受支持的硬件上启动打过补丁的 macOS 安装程序。补丁过程涉及在内存中修改系统文件，以启用旧款 Wi-Fi、显卡和其他组件的驱动程序。这种方法由社区驱动且免费，但未得到苹果认可，可能存在一定的不稳定风险。

8月22日 04:00在 X 打开#macOS #OpenCore #legacy hardware #open source #tutorial

087.0

OpenAI 为付费 ChatGPT Work 和 Codex 用户推出累积重置功能

OpenAI 宣布为所有付费的 ChatGPT Work 和 Codex 用户推出累积重置功能。该功能承诺在公告当天太平洋时间晚上 8 点前上线。用户现在可以在自己选择的时间兑换一次完整的使用限额重置。该功能让付费用户能更灵活地管理使用限额，减少在关键工作中遇到限额而中断的困扰。对于使用 Codex 进行编程任务的开发者和团队尤其有价值，因为中断会打乱工作流程。这一举措反映了 OpenAI 在竞争激烈的市场中改善付费用户体验、留住订阅用户的努力。一次完整的累积重置会同时重置 5 小时和每周的使用窗口，且每周重置日期会移到兑换后大约七天。该功能仅面向付费的 ChatGPT Work 和 Codex 用户，不包含免费用户。推荐奖励可以赚取额外的累积重置，Plus/Pro 用户的推广活动持续到 2026 年 6 月 24 日。第三方工具如 codex-reset 和 codex-resets.com 已经出现，帮助用户追踪和兑换这些重置。

@thsottiaux引用推文The banked reset has landed, I repeat, the banked reset has landed. Have an amazing weekend.展开原推文收起原推文

@thsottiaux

The banked reset has landed, I repeat, the banked reset has landed. Have an amazing weekend.

@thsottiaux

The banked reset will be there by 8pm PST. For all paid users of ChatGPT Work and Codex. Do with this information what you may.

背景

ChatGPT Work 和 Codex 是 OpenAI 提供的付费订阅层级，为专业和编程用途提供更高的使用限额和高级功能。速率限制限制了用户在给定时间窗口（如 5 小时或一周）内可以发出的请求数量。“累积重置”允许用户存储一次重置并在以后兑换，而不是自动应用。这让用户可以灵活地在最需要的时候重置限额，例如在编程冲刺或截止日期前。

8月22日 00:50在 X 打开#OpenAI #ChatGPT #Codex #product update

097.0

Pi 的压缩机制如交接班：压缩旧上下文并重建继续

一篇新博客文章解释了 Pi 如何实现压缩：将其视为交接班，保留近期工作，将较早的决策压缩成结构化摘要，然后重建上下文。首次重建会重新计算第一个变化 token 之后的所有内容。文章地址为 earendil.com/posts/compaction-in-pi/。该方法解决了长对话 AI 的一个核心挑战：如何在不丢失关键信息的情况下管理上下文。通过将较早的上下文压缩为结构化摘要，Pi 可以保持连贯性并减少 token 消耗，这对成本和性能都很重要。交接班的类比让构建智能体系统的开发者更容易理解该机制。压缩过程保留近期工作，同时总结较早的决策，首次重建会重新计算第一个变化 token 之后的所有内容。该博客文章由 @bibryam 的推文链接，Pi 官方文档也涵盖了自动压缩和分支摘要。一个名为 @taylorsatula/pi-compaction 的 npm 包提供了另一种压缩方法，使用结构化工程交接摘要。

@bibryam原推文1 张图片How Compaction Works in Pi Pi treats compaction like a shift handoff: keep recent work, compress older decisions into a structured summary, then rebuild context. The first rebuild recomputes everything after the first changed token. https://earendil.com/posts/compaction-in-pi/ 原推文媒体预览

展开原推文收起原推文

@bibryam

How Compaction Works in Pi Pi treats compaction like a shift handoff: keep recent work, compress older decisions into a structured summary, then rebuild context. The first rebuild recomputes everything after the first changed token. https://earendil.com/posts/compaction-in-pi/

背景

Pi 是一个 AI 助手，通过压缩较早的上下文来管理长对话，以保持在 token 限制内。压缩是大语言模型应用中使用的一种技术，用于总结或压缩对话历史，使模型能够在不丢失重要信息的情况下继续。交接班是一种工作场所实践，即将离岗的员工向接岗员工介绍近期事件和待办任务；Pi 使用这个类比来描述它如何保留近期工作同时总结较早的决策。“第一个变化 token”指的是对话中新信息改变上下文的点，需要重新计算后续 token。

8月22日 12:57在 X 打开#compaction #Pi #systems design #context management #blog post

107.0

用爬山法优化AI评估：一次聚焦一个维度

该帖子介绍了一个使用爬山法改进AI评估的实用框架：选择一个单一维度（质量、成本或延迟）并迭代优化。它强调利用失败模式分类法来指导改进，并给出了一个具体示例：通过将上下文限制为每个任务仅3-5个相关工具来减少工具调用失败。作者还建议先用最好的模型上线，待用户满意度确认后再爬山到更小、更便宜的模型。这种方法帮助AI团队避免“平均值的暴政”，专注于特定、高影响的维度，而不是单一的聚合分数。它为在生产环境中改进LLM应用提供了一种系统化方法，直接解决了工具调用失败和成本降低等常见痛点。该框架对于构建和维护AI系统的从业者来说是可操作的。该方法依赖于拥有能够衡量所选维度进展的评估。作者引用了系列第3部分中的“失败模式分类法”作为确定爬山方向的指南针。一个具体示例：如果工具调用失败很常见，就将上下文中的工具数量从20个减少到每个任务3-5个，然后迭代。对于成本降低，建议从最好的模型开始，然后爬山到更小、更便宜、更快的模型，同时保持质量。

@realmadhuguru引用推文How to build great evals - part 6 Hill climbing on evals is just a fancy way of saying: pick a dimension that matters and optimize for it. This could be improving the quality of existing features based on your latest production data on high value user journeys, expanding to adjacent use cases, lowering cost or latency. The actual work boils down to better harnesses and model selection through methods like prompt eng, context eng, memory, post training, deterministic old school code etc. Your failure mode taxonomy (from part 3) is a good compass for where your product struggles and needs some love. E.g. maybe tool calling failures are your most common problem. You dig in and notice you stuff 20 tools in context, when each task really only needs 3-5. hill climbing here involves context eng to give it the right tools at the right stage and iterate until you get it to good. Or take the cost reduction goal.. I’ve written about how I advise launching your product with the best model first. Get the quality as high as you can. Once you know users love the experience, hill climb to get similar quality with a smaller, cheaper, faster model. Same methods - harness, models. The important thing is to have evals that tell you whether you are actually moving in the right direction. More tomorrow. Send this to your teammates! Drop your questions in the comments and I will answer in future posts.展开原推文收起原推文

@realmadhuguru

How to build great evals - part 6 Hill climbing on evals is just a fancy way of saying: pick a dimension that matters and optimize for it. This could be improving the quality of existing features based on your latest production data on high value user journeys, expanding to adjacent use cases, lowering cost or latency. The actual work boils down to better harnesses and model selection through methods like prompt eng, context eng, memory, post training, deterministic old school code etc. Your failure mode taxonomy (from part 3) is a good compass for where your product struggles and needs some love. E.g. maybe tool calling failures are your most common problem. You dig in and notice you stuff 20 tools in context, when each task really only needs 3-5. hill climbing here involves context eng to give it the right tools at the right stage and iterate until you get it to good. Or take the cost reduction goal.. I’ve written about how I advise launching your product with the best model first. Get the quality as high as you can. Once you know users love the experience, hill climb to get similar quality with a smaller, cheaper, faster model. Same methods - harness, models. The important thing is to have evals that tell you whether you are actually moving in the right direction. More tomorrow. Send this to your teammates! Drop your questions in the comments and I will answer in future posts.

@realmadhuguru

How to build great evals - part 5 Stop dumbing down the results from your beautiful, complex eval suite into one single score. This often happens because some senior wants a simplified number to make decisions. Happened to us in the early days of Gemini. And I see it happening with a lot of teams. This is the tyranny of the average. AI systems do not have a simple dimension of quality. Imagine a model that goes from: 85% -> 89% on simple summarization 80% -> 85% on basic factual QA 70% -> 63% on complex financial analysis A single score obscures the fact that the model got worse on your frontier use case. The immediate reaction to this is to come up with a weighted score. The problem with this is that you have created false, mathematical procession around a judgment call. So what should you do? - keep a prioritized list of your evals per the ladder we discussed in part 4 yesterday. - get people who can look at the details and don’t look for abstracted simplicity. - Understand all the critical eval results in depth, where they fail, where they shine and make a decision on whether your new AI system is better or worse for your users. Next post tomorrow! Drop your eval questions below and I will answer in future posts. Share this with your teammates. And your managers who run from complexity.

背景

爬山法是一种经典的优化算法，它迭代地对解决方案进行小幅改进，朝着局部最优方向移动。在LLM应用背景下，“评估”指的是衡量模型在特定任务上表现的评估套件。上下文工程涉及精心选择模型提示或上下文窗口中包含的信息以提高性能。失败模式分类法对系统常见的失败方式进行分类，帮助团队确定修复的优先级。

8月22日 21:37在 X 打开#AI evals #LLM optimization #prompt engineering #context engineering #machine learning

116.0

HTML/React 被认为是 AI 生成可编辑图表的最佳格式

@dotey 在推文中提出，HTML 或类似 HTML 的格式（如 React）是目前创建可自由编辑的 AI 生成图表的最佳方式。作者认为这些格式训练效果最好、生成质量最高，而且 HTML 易于编辑并能转换为其他可编辑格式。这一观点是在回应关于 AI 友好绘图工具取舍的讨论时提出的。这一观点凸显了当前 AI 绘图领域的一个实际缺口：AI 虽然能快速生成图表，但人工微调仍然困难。通过提倡将 HTML/React 作为中间表示，它指向了一种可能的工作流，能够在 AI 生成与人工可编辑性之间取得平衡。这对于寻求不牺牲手动控制的 AI 原生工具的开发者和团队具有重要意义。推文特别提到 HTML 和 React 作为示例，指出它们是图表生成中训练效果最好的格式。它还声称 HTML 可以方便地编辑并转换为其他可编辑格式。被引用的讨论提到 DrawIO 和 Excalidraw 是 AI 时代之前的工具，而 Mermaid、PlantUML 和 HTML 是 AI 友好的替代方案。原作者指出，尽管 DrawIO 存在连线错误和布局不稳定等 AI 生成问题，但它仍然是他们日常使用的工具。

@dotey引用推文现阶段画图并且能自由编辑最佳方式应该是 HTML 或者类似于 HTML（比如 React）的方式，因为这个训练的最好的画出来效果最好的。而且 HTML 可以方便的编辑，也可以转换成其他可编辑格式。展开原推文收起原推文

@dotey

现阶段画图并且能自由编辑最佳方式应该是 HTML 或者类似于 HTML（比如 React）的方式，因为这个训练的最好的画出来效果最好的。而且 HTML 可以方便的编辑，也可以转换成其他可编辑格式。

@LanLance24

借这个话题，很想了解下大家现在在「画图」这件事上的取舍。 AI 时代之前，我日常主要用 DrawIO 和 Excalidraw。AI 爆发之后，也尝试过一些对 AI 更友好的方式，比如 Mermaid、PlantUML，或者像 Thariq 提到的直接用 HTML。但用下来一直有个很明显的问题是：AI 很好生成，但人很难微调。所以现在我的日常反而还是 AI 生成 DrawIO，再手动调整。虽然 DrawIO 本身对 AI 并不算友好，生成复杂图时也经常会出现连线错乱、布局不稳定之类的问题，但至少最后还能比较自由地编辑。感觉现在一直缺一个真正做到 AI-Native，同时又对人类编辑友好的画图方案。不知道大家日常都是怎么画图的？有没有更好的工作流或工具推荐 🤔

背景

AI 生成的图表通常使用 Mermaid 或 PlantUML 等基于文本的格式，这些格式易于模型生成，但人类难以微调。DrawIO 和 Excalidraw 等传统绘图工具提供丰富的编辑功能，但对 AI 不太友好。HTML 和 React 是 Web 技术，可以将图表表示为结构化、可编辑的代码，有可能弥合 AI 生成与人工编辑之间的差距。

社区讨论

被引用的讨论反映了一个普遍的挫败感：AI 可以轻松生成图表，但人工微调仍然困难。原作者仍然使用 DrawIO 结合 AI 生成和手动调整，这表明缺乏真正 AI 原生且对人类友好的工具。推文中关于 HTML/React 的建议被提出作为一种潜在的解决方案，但在所给内容中没有提供共识或进一步的社区反馈。

8月22日 14:53在 X 打开#AI #diagramming #HTML #React #workflow

126.0

用户通过ChatGPT Sites构建音乐应用分享专辑

用户@thsottiaux通过自然语言提示，让ChatGPT在ChatGPT Sites上创建了一个音乐应用，因为@ajambrosino觉得直接向Twitter上传音乐太难了。这个名为“now-thats-what-i-call-slop”的应用完全通过自然语言提示构建，并可通过分享链接访问。这展示了像ChatGPT Sites这样的无代码AI工具如何降低创建和分享功能性Web应用的门槛，使非开发者能够解决音乐分发等实际问题。它凸显了使用对话式AI进行快速原型制作和个人项目的增长趋势，可能颠覆传统的应用开发流程。 ChatGPT Sites目前处于公开测试阶段，适用于ChatGPT Plus、Pro、Business、Enterprise和Edu计划，并有使用限制。用户可以通过描述需求、审查版本、请求修改和部署来创建网站。该应用名为“now-thats-what-i-call-slop”，暗示这是一个轻松、低成本的创作，其URL托管在openai.chatgpt.site域名上。

@thsottiaux

@ajambrosino thought it was too hard to upload music to twitter, so he just prompted a whole music app hosted on ChatGPT Sites into existence just to share his album https://now-thats-what-i-call-slop.openai.chatgpt.site

Now That's What I Call Slop! · Codex Musicnow-thats-what-i-call-slop.openai.chatgpt.site · 直连原文

背景

ChatGPT Sites是一项功能，允许用户通过自然语言描述需求来创建、预览、发布和分享交互式网站和轻量级应用。它集成在ChatGPT和Codex中，无需编程知识。这条新闻涉及用户利用该工具构建音乐应用来分享专辑，绕过了直接向Twitter上传音乐的困难。

8月22日 04:06在 X 打开#AI #ChatGPT #no-code #web apps #creative coding