新规到底改了什么

苹果开发者官网的 4.3(b) 条款原文写道：对于约会、手电筒、音效、壁纸、简易计时器、占卜算命等”已在 App Store 站稳脚跟”的品类，除非能提供”有意义的不同或更优体验”，否则不再接受新的提交；并且”若这些应用未被更新、改善，或无法吸引用户，我们未来可能会将其从 App Store 移除”。与此前仅拒绝新申请不同，新规的剑锋首次指向已上架的存量应用。

另一类被点名的是饮酒游戏、《爱经》指导手册、模拟放屁与打嗝等”低质量、平庸、低投入”应用，苹果警告：反复提交此类应用的开发者，可能失去整个 Apple Developer Program 账号权限。

为什么现在动手

有媒体估算，截至 2026 年第二季度 App Store 在架应用已突破 580 万款，其中近 17%（超 98 万款）连续 18 个月未更新、日活不足 500 人。这类”数字苔藓”虽不致命，却持续挤占服务器资源、稀释搜索权重。苹果同步在 iOS 27 发布窗口（2026 年 9 月 14 日）推出个性化推荐与运营工具，清理低质应用正是为了让用心打磨产品的开发者获得更多曝光。

对中国开发者意味着什么

中国独立开发者是受影响最直观的群体之一。壁纸、简易计时器、音效工具向来是个人开发者的”练手品类”，新规下这类应用不仅难以上新，存量版本若长期不维护也可能被下架。值得关注的是，苹果在回溯清退之外，也通过现有机制主动提醒开发者版本老旧、下载低迷，给优化留出窗口——这意味着”维护即生存”将成为中小开发者的硬性课题。

横向对比，谷歌 Play 与国内安卓商店近年也在做类似治理，但苹果此次把”低俗恶搞”单独列出并上升到账号层级处罚，力度更狠。对依赖批量铺量、换皮上架的作坊式团队，这无异于一次生态出清。

哪些应用会被下架？

分两类看：一是约会、手电筒、壁纸、音效、简易计时器、占卜算命等低差异化品类，若长期不更新、不优化且缺乏用户吸引力，面临应用本身下架；二是饮酒游戏、放屁打嗝类低俗应用，反复提交可能连开发者账号一起被取消。

开发者账号会被取消吗？

仅当反复提交低俗低质应用才会触发账号级处罚；普通存量应用”变 stale”的后果是下架单款应用，而非注销账号。苹果强调，屡次违规者才会被移出开发者计划。

现有应用如何自保？

核心是持续维护与差异化：在 2026 年内完成实质性版本更新、提升留存与崩溃率指标、避免与既有应用高度雷同。对壁纸、计时器等红牌品类，加入本地 AI 或沉浸交互等独特能力，是避开”准入熔断”的现实路径。

一张表看清两类后果

结语

App Store 的这次”大扫除”，本质上是平台在应用数量见顶后，把竞争从”谁上架更多”转向”谁做得更好”。对认真做产品的中国开发者，这是曝光机会；对换皮铺量的团队，则是清退信号。规则的天平，正在向质量一侧倾斜。

本文基于苹果开发者官网 App Store Review Guidelines 4.3(b) 条款及 Mac Observer、DoNews 等公开报道整理分析。

争议焦点：代码被指「逐字一致」

Minitap 联合创始人兼首席执行官尼古拉·德汉舒韦克表示，谷歌用于 Artemis 的相关内容，来自 Minitap 开源的 mobile-use 项目。mobile-use 是一项允许 AI 通过自然语言控制真实 Android 设备的开源项目。

Minitap 称，谷歌在 Artemis 中采用了其为 Android 设备连接、Hopper 智能体指令以及 WhatsApp 消息任务编写的具体实现，两边代码「甚至逐字一致」。更引人注意的是，Artemis 软件包中原本列有 Minitap 作者皮埃尔-路易·法夫罗、让-皮埃尔·洛与尼古拉·德汉舒韦克姓名的文件，在 8 月通过强制推送被替换。

事件受到质疑后，谷歌在代码中补上了来源说明：「本项目包含由 Minitap 公司开发的源代码。」

许可证层面：开源不等于可随意取用

报道指出，开源并不意味着可以不受限制地直接取用代码，使用者仍必须遵守相应许可证的条款。这部分代码采用 Apache 2.0 许可证，派生项目必须保留版权声明，并注明对代码所作的修改。

与此同时，Minitap 一直要求更新 AndroidWorld 排行榜上已经过时的基准测试成绩，但迟迟没有得到处理；而谷歌的 Artemis 却位列第二，且成绩刚在 8 月更新。值得注意的是，AndroidWorld 基准测试本身由谷歌维护，这进一步放大了外界对排名公允性的疑问。

背景：从开源到闭源的分野

Minitap 在编写上述开源代码后，转而使用闭源代码支撑其现有产品。尼古拉·德汉舒韦克表示，今天的 Minitap 已经是「完全不同的存在」，并认为谷歌在相关技术进展上已经「落后了 7 个月」。

行业启示

这起纠纷为依赖开源项目的企业敲响警钟：即便代码以宽松许可证发布，署名与修改声明等合规义务依然不可回避。对于在产品中集成第三方开源组件的公司而言，建立许可证审查与溯源机制，正从「最佳实践」变为「必选项」。对普通开发者来说，在贡献或使用开源代码时保留完整的版权与修改记录，既是法律要求，也是在争议发生时自我保护的关键证据。

新价格方案一览

本次调价覆盖 deepseek-v4-flash 与 deepseek-v4-flash-vision-exp 两款模型，两者执行相同价格标准。空闲时段与高峰时段价格如下：

高峰时段为空闲时段价格的两倍，时段划分维持此前规则：周一至周五 9:00–12:00、14:00–18:00。

降幅拆解：缓存命中成本下降最显著

与调价前相比，输入缓存命中价格从空闲 0.05 元、高峰 0.10 元降至 0.02 元和 0.04 元，降幅为 60%；输入缓存未命中从 1.5 元、3.0 元降至 1 元和 2 元，降幅约 33.33%；输出价格从 4.5 元、9 元降至 4 元和 8 元，降幅约 11.11%。

对于批处理、多轮对话、Agent 循环调用等上下文反复出现的场景，缓存命中价格下降带来的成本优势最为直接。一次性问答场景的成本下降则相对有限。

价格调整的时间背景

这是 DeepSeek 在 2026 年 8 月上线峰谷分时定价后，首次对 Flash 系列整体降价。此前有报道称，DeepSeek 今年前 7 个月营收约 4.75 亿元，算力投入约 110 亿元，该数据未经官方确认。

与此同时，国内大模型市场的价格竞争仍在持续。智谱 AI 此前已为 GLM-5.3-Flash 推出夜间免费策略，行业整体仍在单位 Token 边际价格上继续下探。

开发者影响

Flash 系列本就面向高并发、低延迟的推理场景。此次降价后，重复调用成本进一步降低，对于需要频繁调用 API 的自动化工作流、客服机器人、代码助手等应用，成本结构会有所优化。不过，开发者仍需结合实际调用模式评估降价带来的真实收益，尤其注意高峰时段的溢价规则。

该参考数据约每 15 天更新一次，开发者可据此为应用合理定义需要兼容的 API 版本。从官方数据看，目前各版本分布如下：

– HarmonyOS 7.0.0（API 26.0.0）：5.27%- HarmonyOS 6.1.1（API 24）：86.82%- HarmonyOS 6.1.0（API 23）：5.50%- HarmonyOS 6.0.2（API 22）：1.58%- HarmonyOS 6.0.1（API 21）：0.41%- HarmonyOS 6.0.0（API 20）：0.04%- HarmonyOS 5.1.1（API 19）：0.10%- HarmonyOS 5.1.0（API 18）：0.07%- HarmonyOS 5.0.0（API 17）：0.21%- HarmonyOS 5.0.0（API 12 至 16）：占比均为 0%

6.1 系列仍是绝对主力

数据显示，HarmonyOS 6.1.1（API 24）的设备量占比高达 86.82%，而 6.1.0（API 23）已降至 5.50%。6.1.0 及以上版本的合计占比达到 97.59%，这意味着 6.1 以下（不含 6.1）版本的占比已不足 3%，约为 2.41%。

与此同时，5.0.0 已有多个版本实现占比归零，对应的 API 版本包括 12、13、14、15、16。5.1.1（API 19）作为 5.X 时代版本号最高的版本，占比也仅有 0.10%。

终端规模持续扩大

据 IT之家此前报道，华为常务董事、终端业务集团董事长余承东在发布会现场宣布，鸿蒙 HarmonyOS 6 与 HarmonyOS 7 的终端数量已突破 8500 万。随着 7.0.0 版本占比的稳步爬升，鸿蒙新版本的存量基础正在逐步夯实，为开发者适配新特性提供了清晰的时间表依据。

科技媒体 Windows Central 于 9 月 7 日发布博文指出，微软 Project Zenith 所采用的工具与系统设置并非设备独占，普通用户也可手动调整 Windows 11，并自行安装 Visual Studio Code 等开发工具。这意味着该项目更像是一套”开箱即用”的预置方案，而非限定在特定硬件上的封闭能力。

项目定位与起源

IT之家曾于 9 月 4 日报道，微软发布 Project Zenith 项目，面向 Windows 11 开发者提供开箱即用的开发环境。该项目主要目标是减少用户首次配置电脑所需的步骤，会预装一批开发工具，并默认启用适配开发流程的系统设置，让开发者开机即可进入工作流。

硬件门槛

在硬件运行门槛上，Project Zenith 要求设备至少具备 64GB 统一内存，内存带宽至少达到 250GB/s。不过，微软官方尚未公布对处理器、存储容量以及价格等参数的进一步要求。

非设备独占，可手动复现

Windows Central 指出，Project Zenith 的预装应用与系统设置并不属于专属能力。用户只要购买一台满足相近配置的 Windows PC，就能自行参照该项目修改 Windows 11 的相关设置，并安装 Visual Studio Code 等开发工具，从而搭出一套相似的软件环境。

在定位上，该媒体认为 Project Zenith 并非通过独立的系统版本来限制功能访问，其主要价值在于降低初始设置成本——借助出厂预置，减少用户在多台设备间重复的手动配置操作。

小结

Project Zenith 的本质，是把”买来就能写代码”的体验做成一套可复制的预置规范：64GB 统一内存与 250GB/s 带宽划出了体验基线，而工具和设置本身向所有相近配置的用户开放。对开发者而言，这套思路降低了新机首配的摩擦；对普通用户而言，它也不是遥不可及的专属功能。

由新管理层推动

报道指出，这一努力主要由新任首席执行官约翰·特努斯（John Ternus）与现任服务业务高级副总裁埃迪·库伊（Eddy Cue）推动。值得注意的是，资深高管菲尔·席勒（Phil Schiller）上周刚从负责 App Store 相关事务的岗位离任——自 2020 年转任苹果 Fellow 后，他的一部分职责便是掌管 App Store。报道称，席勒并不认同相关方向，担心此举会进一步激怒开发者与政府监管机构，最终选择不参与。

可能的调整方向

古尔曼并未给出具体方案，但列举了苹果可能采取的多条路径。其一，取消人工应用审核流程，尽管在智能体编程时代这套机制成本高且效果有限，但进一步自动化恐怕难以获得开发者好感。其二，上调目前每年 99 美元的开发者会员费。考虑到不少独立开发者每月已在 Codex、Claude 等编程工具上花费 200 美元，苹果或认为有提价空间。其三，对大型开发者按流量收取订阅费，以分担基础设施成本。

截至发稿，苹果尚未公布任何明确计划。相关调整最终如何落地，仍有待观察。

开发者现在能做什么

在发送给开发者的邮件中，苹果写道：「我们通知您，要求 macOS 13 或更高版本的 Mac App Store 通用应用，现在可以移除对 Intel 芯片 Mac 电脑的支持。移除后，您可以简化开发流程，并优化下载体积与本机占用。要去掉 Intel 支持，只需把应用的构建设置改为仅 arm64，然后重新构建并提交到 Mac App Store 即可。」

换言之，开发者只需在构建配置中保留 arm64 一种架构，就能向 App Store 提交纯 Apple Silicon 版本。苹果强调，这样做既能减少维护成本，也能让安装包更小、在设备上的占用更轻。

Intel Mac 用户的去留

过去，开发者被要求必须提供 Intel 兼容版本，以保证老款 Mac 也能运行。新规则下，这一要求被取消。对于仍在使用 Intel Mac 的用户，苹果给出的安排是：他们可以继续使用与其机器兼容的「最后一版」应用——也就是说，已安装的应用不会失效，只是此后新版本可能不再向前兼容。

苹果彻底告别 Intel 的时间表

此次松绑，是苹果结束 Intel 时代的最新一步。按计划，下一版重大系统 macOS 27「Golden Gate」将彻底终止对 Intel 芯片 Mac 的支持。与此同时，苹果此前还宣布，把 Intel 应用翻译到 Apple Silicon 上运行的 Rosetta 2 软件，将在 macOS 27 之后停用，仅部分游戏享有例外。

苹果自 2020 年推出 M1 芯片开启 Apple Silicon 转型，到如今允许应用直接放弃 Intel 架构，标志这场历时数年的迁移进入收官阶段。对开发者而言，维护一套架构的成本下降；对消费者而言，老款 Intel Mac 的「退役倒计时」也随之变得明确。

苹果于 8 月 13 日向美国加州北区联邦法院提交了一份法庭命令要求的提案，主张对美国的 App 在应用内放置外链、跳转到网页完成购买时收取佣金。这场围绕「应用商店外链该不该抽成」的拉锯，再次回到法官案头，也把 Epic Games 与苹果的多年诉讼重新推到聚光灯下。

费率怎么算：标准应用 15%，小开发者 5%

按照苹果的提案，佣金按 app 类型分级：

• 标准应用：15%。原本内购为 30% 的应用，改走网页购买后费率减半。
• 新闻伙伴计划、视频伙伴计划、小程序伙伴计划成员，以及订阅续费：10%。
• 符合小开发者计划的 app：5%。该计划门槛为年营收低于 100 万美元。

举个具体的例子：如果一位 Spotify 用户在 App 内点开链接跳到 Spotify 官网并订阅了会员，Spotify 需要向苹果支付 15% 的费用。苹果称这一费率基于专家分析得出，并且低于 Google 在 Epic 诉 Google 案中对外部链接收取的费率。

来龙去脉：从 Epic 诉讼到藐视法庭

这场纠纷的起点是 2021 年 Epic Games 与苹果的反垄断诉讼。法院当时命令苹果修改「反引导」（anti-steering）规则，允许开发者在 App 内链接到 App Store 之外的购买渠道。苹果一度推出 12% 至 27% 的费率（叠加第三方支付处理费后几乎与原费率相当），几乎没有开发者采用。

Epic Games 指控苹果违反法院命令，主审法官 Yvonne Gonzalez Rogers 认同这一说法，并于 2025 年 4 月判定苹果「藐视法庭」，禁止其对链接收取任何费用。自那以后，只要 App 把用户导向网页完成购买，苹果便收不到钱。苹果提起上诉，上诉法院维持了藐视裁决，但同时认为苹果有权因自身知识产权获得合理补偿，于是把确定费率的事发回地区法院。

下一步：最高法院十月开庭

在上诉法院确认藐视认定后，苹果把官司打到了美国最高法院，大法官们同意在 10 月开始的庭期审理此案。苹果曾多次请求推迟费率计算，理由是若最高法院推翻上诉法院的藐视裁决，地区法院「禁止收费」的判决也将失效；但地区法院、上诉法院和最高法院均未同意暂停。

接下来，地区法院将评估苹果的费率提案，并听取 Epic Games 的回应，最终确定苹果必须执行的具体费率。苹果强调，零佣金无法体现其为开发者提供的平台价值；Epic Games 则一贯主张外链应当「商业上可用」，而非被高额费率架空。

无论结果如何，这一费率的影响都可能超出美国本土。苹果曾向最高法院表示，全球各地的监管者都在观望此案走向——它既关乎开发者的分成空间，也将成为各国应用商店规则的一个重要参照。

来源：MacRumors（作者 Juli Clover，2026 年 8 月 13 日）

科技媒体 How-To Geek 在 8 月 10 日刊出的分析文章指出，Linux 社区的紧张情绪始于 AI 生成的贡献大量涌入一套本就没为此设计的评审流程。

生成一分钟，评审两小时

问题的核心其实很朴素：用 AI 工具生成一份补丁或一份漏洞报告，成本几乎为零；而认真评审这些提交，仍然需要真人投入大量时间和精力。

这让一个原本就超载的系统进一步恶化。在内存管理这类繁忙的子系统里，早在 AI 工具普及之前就已经有大量补丁排不上评审队列。

内核的私有安全邮件列表把矛盾推到了临界点。这个渠道过去很安静，每周处理少量经过深思熟虑的报告；如今每天会收到五到十份。由于列表是私有的，提交者无从得知同样的问题是否已经有人报过，于是相同的议题被反复提交。负责相关领域的维护者可能花上几个小时逐条筛查，最后发现这些漏洞要么根本不存在，要么几个月前就已经修复。

Linux 之父 Linus Torvalds 对 AI 生成代码持保留态度已有一段时间。他不认为这类代码适合用于生产环境，并指出在不理解底层代码与系统架构的前提下盲目采信 AI 的输出，出问题几乎是必然的。

表面能编译，不代表它是对的

社区内部对如何处置 AI 代码远未达成一致，一部分开源项目已经明令禁止 AI 生成代码，而另一部分开发者则希望 AI 辅助开发继续发展，认为这类工具确实能帮人更快穿过复杂的工作。

批评者的理由并不在于「AI 永远写不好代码」，而在于当下的可信度：一份补丁可能表面看起来完全正常，编译不报任何错误，却因为某些只有在后期才会显现的原因而完全跑偏。AI 没有对一份代码库历史的直觉，也不清楚某些架构决策当初为什么那样做，于是它带进来的问题往往多于它修掉的问题。

更现实的成本落在时间账上。软件开发的实质并不是写代码，而是在交付前理解和审查代码。当 AI 让缺乏经验的开发者也能轻易生成大段补丁，仍然得有人把这些代码逐行读完并作出判断。维护者要花几个小时去揣摩 AI 为什么做出某个决定，或者反过来追着提交者提问——而提交者往往答不上来。这些时间是从真正推动项目前进的工作里直接扣掉的。

目前出现的应对手段大多是临时性的，比如给拉取请求设置数量上限、强制要求标注 AI 参与情况。这类措施有一定效果，但由于生态本身是开放且去中心化的，很难让所有人对任何一项对外规则达成共识。

讽刺之处：最适合跑本地 AI 的系统，用户却装不起来

维护者其实在两条战线上同时作战，而两者都源于这套系统的构建方式。

一边是维护者疲于应付涌入仓库的机器生成内容；另一边是普通桌面用户想在本地跑一个模型，却要在互相竞争的桌面环境里挑选，还要面对 Snap 与 Flatpak 这类彼此冲突的打包格式，以及未必兼容的图形服务器。把一个本地 AI 模型在 Linux 上跑起来，需要真实的技术功底，门槛高到连长期使用 Linux 的作者本人都表示暂时不想碰。

而按架构来说，Linux 本应是运行本地 AI 最合适的平台：它能提供直连硬件的 GPU 算力访问，没有 Windows 及其 WSL2 兼容层带来的虚拟化开销与内存预留。缺少一个能统一界面标准和硬件适配规则的中心权威，生态的碎片化就停不下来，一个干净、易用的本地 AI 前端也就始终建不起来。

于是形成了一个尴尬的局面：维护者忙着筑墙抵挡机器生成的提交，普通用户则被挡在本地 AI 的门外。Linux 在本地 AI 上能提供的能力，与它实际交付的体验之间，这条缝隙短期内不太可能收窄。

来源：How-To Geek（作者 Jorge A. Aguilar）