本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 github.com GitHub - Jinghao67/conductor: Context conductor for clean master sessions, dirty... Context conductor for clean master sessions, dirty explainer sidecars, and interactive AI branches 作为一个既需要发论文（科研导向）又需要做项目（工程导向）的学生，我在使用ai的过程中，经常遇到下面几个问题： 1）主session污染问题：在一个session内和ai聊久了，主 session 很快会被需求讨论、实现细节、失败尝试、长篇解释、review 记录全部污染，最后自己也不知道哪个 session 是干什么的。在科研上，有了idea后需要做不同的实验去验证和实现，实验过程中涉及到配环境、调参等很容易让ai陷入局部最优而进行过度尝试污染上下文的问题。在工程上，很多工程也会涉及到这些问题，subagent由于其不可显示导致人为不可控且需要用户自己设计而过于繁琐。 2）无论是工程还是科研都来源于一个并不具体的想法，可以说：在完成整个项目的过程中，没有人对这个项目完全了解，这就需要有一个session能拿到所有session的context，来解答用户所有的问题，无论是什么问题，这个session就是用来污染的，且永远不会并入主session污染其他session。 3）过程文档至关重要，但是一个被污染的session总结出的过程文档往往是带有各种无意义信息，比如偏向用户让他给解释的概念、反复陈述各种试错的失败信息，显然这对于未来需要这份过程文档的人是噪音，所以如何维护一个无污染的过程文档至关重要。 针对上述问题，我写了conductor，它的思路是把当前主对话变成一个永远干净的master session（用于自己需要理清项目逻辑、写过程文档等），只保留全局目标、关键决策、分支地图和批准后的子session的摘要；具体使用而言：使用时会先把当前对话设为干净的master session，如果需求不清楚，可以结合grill-me or grill-me-docs追问，等讨论清楚后，conductor会先做依赖分析，判断哪些任务可以并行，哪些必须串行等待。 接着，它不会乱开session，而是先生成branch card，每张card写清这个分支要做什么，为什么开，允许带入哪些context，预期产物是什么，完成标准和return condition，只有用户确认后，才会开真正的branch session。最开始会有四个session。1）主session。2）专门用于问问题随便污染的session。3）讨论分多少branch，并行or串行的session。4）第一个branch session 进入branch session后，这个session只拿到自己的branch brief和已批准的master session的context，不会继承任何session的杂乱历史，用户可以在branch里继续交互实现任何东西，这解决了subagent不能交互的问题，这下每个子任务用户都可以及时纠偏，这些细节都会留在branch里，主session依然干净。 当branch觉得任务完成后，不会自动合并，它会先建议完成，用户确认完成后，会生成总结，把这个session中过度的污染去掉但是把经验和正确的流程总结压缩，然后master session会询问用户是否合并，因为某些子任务必须合并进入主线，要么主线不完整，比如，在科研中，配环境复现paper的branch可以不合并，但是自己的重要实验必须要合并，不然主session会缺乏细节了解。 如果使用Treills，conductor还会把master、branch、依赖关系、状态和产物路径持久化成parent/child tasks、branchmap和metadata，方便回看、回退和继续推进。 整个流程的目标是：主session保持干净和主导，分支负责探索完成，专门留有一个有所有session context的session来让用户随意问问题讨论、污染。 6 个帖子 - 4 位参与者 阅读完整话题
Firefox 浏览器日前在开发分支中正式合并了对 Vulkan Video 的初步支持，为这一主流开源浏览器引入了新的 GPU 视频硬件解码路径，被视为 Mozilla 在加速视频播放体验方面的一项重要进展。 长期以来，Linux 平台上的 Firefox 主要依赖 Video Acceleration API（VA-API）进行硬件解码，但 VA-API 并未在所有图形驱动上得到广泛、一致的支持，这不仅给 NVIDIA 用户带来额外适配成本，也使许多基于 Arm 的嵌入式设备在视频加速方面被边缘化。 在此背景下，社区此前不得不通过诸如 NVIDIA-VAAPI-Driver 之类的方案，将 NVIDIA 的 NVDEC 接口通过一层适配暴露为 VA-API，以便在 Firefox 中启用 GPU 加速播放，这类间接方案在稳定性和维护成本方面都存在一定局限。 随着 Khronos 推动的 Vulkan Video 规范逐步成熟并获得更多驱动实现支持，它开始以更跨平台的方式进入 Linux 图形生态，为浏览器等应用提供了一条绕过 VA-API 限制的新路径。 今年 3 月，针对 Firefox 缺乏 Vulkan Video 支持的问题，社区在 Mozilla Bugzilla 上提交了相关缺陷报告，并在随后的数月里推动实现落地。 近期，随着相关补丁在 Firefox 代码库中完成合并，这一 Bug 报告已正式标记为关闭，意味着 Vulkan Video 解码支持已进入主干代码并具备进入正式版本的条件。 按 Mozilla 目前的发布节奏，计划于 7 月发布的 Firefox 153 将成为首个默认提供 Vulkan Video 解码能力的版本。来自 NVIDIA 的工程师 Tymur Boiko 和 Red Hat 的 Martin Stransky 是该功能合入过程中的主要贡献者，他们在 Firefox Git 仓库中持续推进 Vulkan Video 相关代码，最终在本周完成关键合并。 按规划，Firefox 153.0 预计将于 7 月 21 日正式发布，如无最后时刻的重大问题，这一版本将面向用户开放 Vulkan Video 硬件解码支持。 对于 Linux 用户而言，Vulkan Video 的加入意味着 Firefox 在硬件加速视频播放方面将更具通用性和可移植性，有望减少依赖特定 API 或第三方适配层带来的兼容性不确定性。 尤其是在小型 Arm 设备和嵌入式平台上，随着 Vulkan Video 的进一步普及，Firefox 将有机会在更多类型的 GPU 驱动上实现高效的视频解码，为流媒体播放、网页多媒体内容等场景提供更流畅的体验。 查看评论
佬们，我来L站也有一段时间了，然后知道一些基本的信息，但是发现L站所有分支就是一座巨大的冰山，L站是只是表面的冰层，实际下，水面下还有巨大的一坨根本不理解啊。有没有系统性的说明，比如，我了解到的： L站：资讯发布、获取、分享平台 LD士多:求购商品，发布商品的平台（用LDC购买） credit：LDC获取，消费记录平台 好像还有很多平台，我目前有些都没接触到。 另外，想问下佬们，这个credit站点，LDC获取的规则是啥啊？我发现想买一个plus号啥的，都挺贵的，最起码要500.我来这么久，经常互动发帖，也才300多 5 个帖子 - 5 位参与者 阅读完整话题
随着1flowbase正式发版，我忽然意识到自己已经不能够的像以前那样开发好什么直接往main分支上面去丢了，因为这个开源项目已经开始面向一些朋友跑，他们可能也会进行代码克隆或者跑本地代码，我需要对分支指责进行有意识划分主要做了分支： 1.dev分支：个人开发分支，我基本上有什么新功能我就会直接丢上去，甚至ai没完成一个功能都会主动推送线上，所以这个分支处于薛定谔状态，可用，不可用。 2.beta分支：用来开发体检优化分支，简单来说就是dev分支在开发时候，在beta的工作空间里面做项目测试回归优化，体检之类，简单来说就是，一般不做功能性开发，偶尔也会加一个，看需求 3.main分支，仓库主分支，一般不进行开发，就是开放给外部clone，一般来说只接受beta合并，这样体检优化过没啥问题，才放进来，基本上做日抛 4.latest分支，最后镜像打包，github上面action，检测到版本变化，就会打包发布为docker镜像。 一般来说顺序：dev ->beta ->main ->latest 当然有时候beta体检之后要合并回dev分支看看跑有没有什么问题，然后才重新走上面顺序。 当然啦有人会说这也太麻烦了，特别每次都要合并main和latest分支。我让gpt写了一个脚本，能够将当前分支直接合并到main和laster里面就可以了。 这里面重点是，main分支和latest分支不要再接受其他乱七八糟分支了，单一来源和原则，这样就不需要手动合并了。 当然有佬说，要是pr到main分支怎么办，将main分支合并到dev或者beta上面做一个体检，然后再跑这个顺序 对脚本感兴趣或者项目感兴趣可以看看： 开源推广-1flowbase正式发布-组合发布专属大模型-个人和企业也能做模型上游供应商 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 历时两个月… 不贴脚本了，仓库地址放出来要审核，一些更新我也是弄到这个帖子下面的了 1 个帖子 - 1 位参与者 阅读完整话题
我在~/.codex下的AGENTS.md 写明了不允许在main和test分支上修改代码 他还是在test上写了代码 这有什么办法限制只能在test上写吗 难道只能每个工作目录都重复一遍 1 个帖子 - 1 位参与者 阅读完整话题
居然不是diff当前分支的改动，是当前分支和 main 的改动，找了一圈还没地方修改 就发了一个 hi，就有上万的改动 1 个帖子 - 1 位参与者 阅读完整话题
一款名为 Vim Classic 的新编辑器分支近日发布了首个稳定版本 8.3.0，开发团队强调该项目的全部代码均未借助大语言模型（LLM）生成。Vim Classic 8.3.0 基于较早的 Vim 8.2.0148 版本开发，团队刻意避开了更新的 Vim9 Script 引擎，以减少长期维护负担并保持代码库的简洁性。不过，这一取舍也意味着，部分依赖新特性的现代 Vim 插件将无法在 Vim Classic 中正常使用。 项目维护者表示，他们的出发点是“清理这一版本的 Vim，为其准备一个发行版本，并想象一个没有 Vim9 Script 的 Vim 8.3 会是什么样子”。在他们看来，相比上游 Vim 项目，Vim Classic 缺乏足够的资源和内部知识储备，因此必须通过简化技术栈来控制维护成本。团队在说明中也坦言，这种路径选择的代价之一，就是与部分现有插件生态的兼容性出现缺口。 尽管是一个理念上“回到经典”的分支，Vim Classic 仍保留了原版 Vim 的“慈善软件”（charityware）模式，承诺继续支持已故 Vim 作者 Bram Moolenaar 生前所坚持的慈善事业——为乌干达有需要的儿童提供帮助。为确保此次发布的安全性，开发者特别强调，他们针对上游 Vim 的安全补丁进行了重点审查，将其中修复安全漏洞的改动有选择地合并进来，同时也提醒早期采用者，系统中仍可能潜藏尚未暴露的缺陷。 这一分支的诞生与当前业界围绕生成式 AI 的争议密切相关。Vim Classic 项目由 Drew DeVault 发起，他在 2026 年 3 月 25 日发表的一篇博文中，公开表达了对生成式 AI 的强烈反感，认为这类技术在现实中集中财富与权力、助长宣传机器甚至极端主义倾向，同时在代码和文本层面大量制造“slop”（低质量内容）。由于 Vim 与 NeoVim 均已接受基于 LLM 辅助生成的代码贡献，DeVault 称自己已无法在“问心无愧”的前提下继续使用这些编辑器，因此选择分叉并维护一条不接纳 AI 代码的路线。 在上游项目中，Vim 于去年 12 月出台了正式的 LLM 相关政策，允许贡献者提交由 AI 生成或辅助生成的代码，但要求必须明确标注，并确保这些代码在风格上与历史代码库保持一致。与此相对，Vim/NeoVim 用户群体中也有相当一部分正在主动拥抱 AI 工具，通过各种插件在本地或云端引入代码补全与“智能助手”等功能。例如，有的插件主打离线优先的本地编码辅助，有的支持在多家外部 LLM 服务之间切换查询，还有插件专门用于在本地运行补全模型，甚至协同多智能体完成任务规划。 在这种分化的背景下，Vim Classic 的出现，为强烈反对生成式 AI 的开发者提供了一个价值立场更为鲜明的替代选项。对这部分用户而言，选择 Vim Classic 不仅是技术路线的抉择，也是一种围绕软件开发伦理、知识生产方式以及开源社区治理模式的态度表达。不过，由于该项目在功能与插件兼容性方面做出了明显取舍，其未来能否吸引足够多的维护者和用户，仍有待时间检验。 访问： https://sr.ht/~sircmpwn/vim-classic/ tar.gz vim-classic-v8.3.0.tar.gz .tar.gz.sig vim-classic-v8.3.0.tar.gz.sig 查看评论
有没有佬友会一个项目多分支并行cc开发 , 目前想到的方法是：开多个IDEA对应不同分支，每个IDEA的终端使用cc（不知道可不可行）？ 然后现在目前用哈雷佬的cursor++，不知道有没有骚操作对应不同分支同时用。 4 个帖子 - 4 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI 生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI 生成、润色内容已使用截图方式发出。 CodexTools：Codex++ 的 Go + React 重构分支 CodexTools 是一个面向 Codex App 的独立桌面管理器，也是 Codex++ 方向上的 重构分支 。 这个项目把原来偏脚本式、工具式的增强流程，重新整理成了一个独立的 Go + React 桌面项目，用来集中处理 Codex 安装配置、启动、连接模式、界面增强、脚本、诊断和修复流程。 它不修改 Codex App 原始安装文件，而是通过外部管理器启动 Codex，并使用 Chromium DevTools Protocol 向渲染进程注入增强脚本。 项目地址： https://github.com/hereww/codextools 项目介绍页： https://hereww.github.io/codextools/ 下载页： https://hereww.github.io/codextools/downloads.html 原始项目： https://github.com/BigPizzaV3/CodexPlusPlus 重构来源： https://github.com/hereww/CodexPlusPlus 说明：本项目为 Codex++ 的重构分支，当前以独立仓库形式维护，重点是管理器体验、桌面安装包、配置修复、连接模式和脚本能力的整理与重构。 这次重构主要解决什么 原来的增强能力已经能用，但随着功能变多，普通用户第一次配置时会遇到几个问题： 不清楚 Codex、Codex++、中转配置、Provider 配置之间的关系。 不知道应该从哪里启动、哪里修复、哪里导入配置。 出问题时很难判断是 Codex 路径、配置文件、插件入口、供应商还是本地代理的问题。 不同系统的安装包、启动入口和修复流程需要统一整理。 脚本、界面增强、会话管理等能力需要有一个稳定的管理入口。 CodexTools 的目标就是把这些东西收拢到一个桌面管理器里，让非技术用户也能按流程操作。 当前功能 首页仪表盘 首页会集中展示本地环境是否就绪，并提供主要启动入口、连接状态、界面增强状态、入口修复和关键状态检查。 新手安装引导 新手流程会按顺序完成： 系统识别 Codex 安装检查 CCSwitch 配置导入 连接模式选择 启动 Codex++ 连接服务管理 支持集中管理： 官方登录模式 官方混合 API 模式 兼容 API / 中转 API Provider 列表 CCSwitch 导入 中转连通性测试 Chat 协议转换 界面增强 当前增强能力包括： 会话删除 Markdown 导出 项目移动 Timeline 插件入口解锁 特殊插件强制安装 菜单入口增强 脚本注入能力 脚本中心 内置脚本管理能力： 脚本市场安装 本地脚本启用 / 禁用 脚本更新 脚本卸载 修复与诊断 集成常用修复入口： Codex 应用路径修复 快捷方式修复 Provider 同步 插件配置恢复 历史对话 Provider 归属修复 运行日志 诊断报告生成 下载 下载页： https://hereww.github.io/codextools/downloads.html 当前提供 macOS 和 Windows 桌面包： macOS Apple Silicon 安装包 macOS Intel 安装包 macOS 便携 zip Windows x64 安装包 Windows ARM64 安装包 Windows 便携 zip 如果 macOS 因未签名阻止启动，可以执行： xattr -cr "/Applications/Codex++ 管理工具.app" xattr -cr "/Applications/Codex++.app" 项目来源与鸣谢 CodexTools 是基于早期 Codex++ 工作继续拆分出的独立 Go 重构和管理器界面项目。 感谢原 Codex++ 项目提供的基础能力、工作流思路和面向用户的工具方向。 原始项目： https://github.com/BigPizzaV3/CodexPlusPlus 重构来源： https://github.com/hereww/CodexPlusPlus 当前重构分支项目： https://github.com/hereww/codextools 交流 电报群： https://t.me/wanai8 3 个帖子 - 3 位参与者 阅读完整话题
可以使用原版dev分支 5 个帖子 - 3 位参与者 阅读完整话题
目前我直接做的分支go的重构。主要重点是把我自己的想法放进去实现。但是有个问题就是对项目发布后应该怎么做？有什么注意事项，如何让别人下载，如何找伙伴一起维护？我不求任何捐助和赞助，主要是我给学生用，作为小白的一群人能够立马使用上手。人生第一次发布这种开源项目，希望各位佬给点建议。 5 个帖子 - 3 位参与者 阅读完整话题
codex --version codex-cli 0.133.0 如题, 我已经配置了git-branch, 效果图上是有分支的 但实际上没有 分支 7 个帖子 - 3 位参与者 阅读完整话题
V2Board及其所有分支漏洞，影响全部版本，该漏洞可修改一切已注册用户账号密码 复现方式： API端点： api/v1/passport/auth/forget Payload： JSON { "email":"任意一个已注册用户", "password": "密码", "email_code": false } 即可重置对应账户密码 最小改动修复方式： app/Http/Requests/Passport/AuthForget.php 找到’email_code’ => ‘required’ 改成’email_code’ => ‘required|string|digits:6’ 2 个帖子 - 2 位参与者 阅读完整话题
因为grok2api主分支迟迟不更新，发现已经有大佬fork并支持了最新的4.3模型了。 项目分支是： GitHub - cloudriver8/grok2api at feat/console-x-ai-routing · GitHub 我是直接让codex将老版本直接改成分支的，具体干了啥我也不知道。 我的都是free号，当前对外可见模型 这些是 /v1/models 当前返回的 9 个模型，全部实测可用： 模型 类型 结果 耗时 grok-4.20-0309-non-reasoning chat 可用 2.53s grok-4.20-fast chat 可用 0.96s grok-4.3 chat 可用 2.62s grok-4 chat 可用 2.61s grok-4.20 chat 可用 1.39s grok-4.20-reasoning chat 可用 3.02s grok-4.20-non-reasoning chat 可用 0.66s grok-4.20-multi-agent chat 可用 3.50s grok-imagine-image-lite image 可用 15.96s 当前不可见/不可测模型 项目注册表里还有这些模型，但当前账号池只有 basic active 25647，没有 super/heavy 账号池，所以 /v1/models 不暴露它们，本次没有按可用模型测试： grok-4.20-0309 grok-4.20-0309-reasoning grok-4.20-0309-non-reasoning-super grok-4.20-0309-super grok-4.20-0309-reasoning-super grok-4.20-0309-non-reasoning-heavy grok-4.20-0309-heavy grok-4.20-0309-reasoning-heavy grok-4.20-multi-agent-0309 grok-4.20-auto grok-4.20-expert grok-4.20-heavy grok-4.3-beta grok-imagine-image grok-imagine-image-pro grok-imagine-image-edit grok-imagine-video 修复点：grok-4.20 原本会被自动注入上游不支持的 reasoningEffort=high，导致 400。我已在 app/control/model/registry.py 去掉该默认参数，重建并部署后复测通过。 在当前可用的 9 个模型里，优先级可以这样看： 1. grok-4.20-multi-agent 通常最强，适合复杂推理、检索、多步骤分析、需要更稳答案的任务。 2. grok-4.20-reasoning 推理型模型，适合代码分析、数学、规划、长链路判断。比普通 grok-4.20 更适合需要“想清楚”的任务。 3. grok-4.3 / grok-4 / grok-4.20 通用能力强，适合日常问答、写作、代码、总结。grok-4.3 理论上更新，优先试它。 4. grok-4.20-fast / grok-4.20-non-reasoning / grok-4.20-0309-non-reasoning 更偏速度和普通对话，不适合复杂推理。 5. grok-imagine-image-lite 图片生成模型，不和文本模型直接比较。 我的建议：默认用 grok-4.20-multi-agent；如果它慢或不稳定，用 grok-4.20-reasoning；日常快速任务用 grok-4.3 或 grok-4.20-fast。 | 模型 | MCP 搜索表现 | |---|---| | grok-4.3 | 最均衡，约 55s，返回 27 个 sources，答案长度适中 | | grok-4.20-reasoning | 可用，约 58s，返回 23 个 sources，但更慢一点 | | grok-4.20-multi-agent | 可用，约 55s，返回 19 个 sources，但 token 消耗极高，日志里一次到 213945 tokens，不适合作为 MCP 默认搜索模型 | | grok-4.20 | 不稳定，出现过 60s 上游超时 | | grok-4.20-fast | 当前默认，但不适合 MCP 搜索；容易无有效搜索来源或 fallback | | non-reasoning 系列 | 更适合普通快速回答，不适合作为搜索汇总模型 | 13 个帖子 - 9 位参与者 阅读完整话题
名称 网址 TextVerified https://www.textverified.com/app/credits/card 5sim （短信激活） https://5sim.net/zh 68 SMS https://www.68sms.com/login Hero SMS https://hero-sms.com/ SMS Bower https://smsbower.app/ SMS-Man （接收短信） https://sms-man.com/ SMS Verification Number https://sms-verification-number.com/en/login/ 999 SMS https://www.sms-999.com/app/store SMS BUS https://sms-bus.com/ Autofications https://autofications.com/ Pvaverify https://app.pvaverify.com/dashboard
Rewrite Bun in Rust #30412 https://github.com/oven-sh/bun/pull/30412
前几天作者还在说是实验性的东西，用 ai 写着玩，结果现在已经合到 main 分支了
Rewrite Bun in Rust #30412 https://github.com/oven-sh/bun/pull/30412
IT之家 5 月 16 日消息，科技媒体 9to5Mac 昨日（5 月 15 日）发布博文， 报道称 xAI 起诉苹果公司与 OpenAI 的反垄断诉讼案出现新进展。 美国法院同意把苹果软件工程高级副总裁克雷格 · 费德里吉（Craig Federighi）列为“文件保管人”（Document Custodian） ，但驳回了将苹果首席执行官蒂姆 · 库克（Tim Cook）纳入“文件保管人”的动议。 IT之家注：“文件保管人”是诉讼取证中的特定角色，指被法院指定后，需要配合保全、检索并提交自己持有相关文件的人。其价值不在职位高低，而在是否可能掌握其他材料未覆盖的独特证据。 与普通公司员工不同，被列为文件保管人后，其邮件、消息、工作文档等都可能进入检索范围，主要影响证据披露范围。 这起诉讼源于埃隆 · 马斯克（Elon Musk）于 2025 年对苹果公司、OpenAI 的指控，认为苹果公司把 ChatGPT 整合进 Siri 的合作，影响了 App Store 排名，并可能压制其他大语言模型应用的发展。 不过苹果公司方面一直否认这些说法，尤其反对 xAI 把这项合作描述为“排他协议”。按 Apple 的说法，这笔合作并不涉及排他性安排。 美国法院认为，作为软件工程负责人，他很可能参与了 Apple 把 OpenAI 整合进 Apple Intelligence 的核心决策，因此相关文件可能直接涉及案中争议，要求其于 2026 年 6 月 17 日前提交相关文件。 与此同时，法院也划了边界。xAI 想加入另一名未具名 Apple 员工，以获取与 iPhone 销量有关的信息，但法官拒绝了这一请求，理由是智能手机行业的大范围竞争文件超出了本案范围。 法院还否决了 xAI 索要 Apple 内部 AI 使用政策的要求，认为这类员工层面的 AI 使用规则，与反垄断主张之间关系不清楚。 不过，xAI 并非没有收获。法院部分支持其调取 Apple 与 Google 合作文件的请求，但缩小了范围，只要求提交涉及 Apple 产品中 AI 供应商“潜在排他条款”的相关材料。
前几天作者还在说是实验性的东西，用 ai 写着玩，结果现在已经合到 main 分支了