苹果让开发者“自证 Bug 还活着”：关闭工单的，不一定是问题本身
苹果的软件生态一直有一种微妙的矛盾感：一边是业内最强势、最封闭、也最讲究体验的商业系统之一；另一边，却常常让最靠近它的开发者感到一种难以言说的疲惫。最近，资深 Mac 开发者 Jeff Johnson 在博客里点名苹果的 Feedback Assistant——也就是开发者提交系统问题和产品缺陷的官方渠道——抱怨苹果会在多年没有动静后，突然要求开发者“验证”某个 Bug 在最新测试版里是否依然存在；如果开发者没有在规定时间内回应，工单就可能被关闭，默认问题已解决。
听起来像是流程管理，实际上却像一场反向举证：不是苹果证明“我们修好了”，而是开发者要证明“它还没修好”。这件事之所以引发共鸣，不是因为它有多戏剧化，而是因为几乎每个和大平台打过交道的开发者，都能从中闻到那股熟悉的味道——系统很庞大，流程很冰冷，愿意认真反馈问题的人，最后反而成了被流程消耗的人。
三年没回音，突然催你两周内确认
Jeff Johnson 提到的案例很具体。2023 年 3 月，他向苹果提交了一个隐私相关的 Bug，编号 FB12088655，内容是网络过滤扩展会泄露 TCP 连接和 IP 地址。这不是那种“偶现、难复现、像薛定谔的 Bug”的问题；他当时给了复现步骤，也提供了 Xcode 示例项目。此后整整三年，苹果没有任何实质回复。
直到几周前，苹果突然发来通知，要求他在 macOS 26.4 beta 4 上“验证”问题，并更新报告。更让人皱眉的是，苹果还表示，如果两周内没有收到验证反馈，可能会关闭这份工单，并默认问题已修复。三年沉默，换来两周倒计时，这种时间观念的错位，确实很难不让人火大。
Jeff 的不满并不难理解。很多独立开发者并没有条件像大公司 QA 团队那样全年跟进测试版系统。他提到，自己通常只在 WWDC 后安装开发者测试版，等到正式版发布后就不会一直追 beta 了。理由非常现实：设备有限，时间也有限，没人愿意全年无偿扮演苹果的外部测试员。更讽刺的是，他去询问会长期跑 macOS beta 的 Little Snitch 开发团队，对方告诉他，这个问题在 beta 4 中依旧能复现。随后，macOS 26.4 正式版发布后，Jeff 亲测也还是老样子。
这就让整件事显得格外尴尬：苹果要求开发者确认一个“疑似已修复”的问题，但从结果看，这个问题根本没有被修复。开发者跑了一圈，像被安排去追一只根本不存在的兔子。
真正的问题，不是 Bug 没修，而是人被当成工单附件
如果只是“某个 Bug 三年没修”，这其实还不算稀奇。任何复杂操作系统都有技术债，也都有优先级排序。真正让开发者寒心的，是苹果在这套流程里呈现出的态度：不是“谢谢你帮我们定位问题”，而更像“请配合完成关闭流程”。
Jeff 在文章里说，他最不满的并不是苹果没有修掉所有 Bug，而是苹果对 Bug 报告和提交者缺乏尊重。这个说法很重，但并非没有依据。你提交了完整复现步骤、示例工程、背景说明，苹果内部理应可以自行验证问题是否仍存在。可现实却像是在说：你既要当发现者，又要当重测工程师，还得在规定时间内自证问题没有自然蒸发，否则案子就算了结。
这种机制最伤人的地方在于，它会打击最有责任感的人。愿意认真写 Bug report 的开发者，往往正是最在乎平台质量、最愿意和平台长期合作的人。对他们来说，提交问题本来就是帮苹果补课。可一旦这套系统开始把“关闭工单数量”变成某种内部绩效指标，提交者就会逐渐意识到：自己不是合作伙伴，更像后台流程里一个可被催促、可被忽略、也可被自动归档的编号。
苹果当然不会承认自己在“刷关闭率”，但 Jeff 的怀疑并不离谱。科技公司内部管理一旦过度依赖数字，最容易出现的副作用就是指标替代现实。打开的 Bug 少了，并不等于系统质量更高；也可能只是因为更多问题在没有解决前，就已经被流程性地折叠掉了。办公室里的报表会因此更好看，用户手上的崩溃和异常却不会凭空消失。
苹果的软件口碑，正在被自己的流程一点点磨损
这件事放在 2026 年看，格外刺眼。因为这几年，外界对苹果软件质量的讨论明显变多了。硬件依然强势，芯片路线依然领先，生态绑定依然牢固，但一旦说到系统稳定性、功能打磨和跨版本一致性，开发者和重度用户的怨气并不小。从 Safari 到系统权限，从窗口管理到后台服务，从 iPadOS 的生产力承诺到 macOS 的细碎回归，苹果的软件团队似乎越来越像在做一艘超大邮轮的边航行边维修。
Jeff 还提到另一个案例：他此前报告的一个标签页相关 Bug，明明可以 100% 复现，却被苹果标记为“调查完成——基于当前信息无法诊断”。这句很多开发者都看得懂，翻译得直白一点就是：我们没法往下做了，但也不一定是你的问题。至于还需要什么信息？苹果并没有说清楚。开发者追加询问后，也没有后续回复。
这不是苹果一家独有的问题。Google、Microsoft、Meta 这些大公司也都曾被开发者批评过反馈系统冷漠、工单黑箱、沟通低效。区别在于，苹果长期以来卖的不只是产品，更是一种“我们更懂体验”的品牌叙事。正因为它把体验和细节放在品牌核心位置，开发者才会对这种流程失温格外敏感。你可以接受一个庞大系统不完美，但很难接受它在面对帮助修补的人时，表现得像一台毫无情绪的自动售票机。
Beta 的意义，难道只是让开发者再做一轮义务劳动？
Jeff 最尖锐的一句抱怨，是他质问测试版的意义到底是什么。他提到，自己一个月前报告了 iPadOS 26.4 beta 中导致 Safari 崩溃的 Bug，但苹果在正式版发布前也没修掉。这其实戳中了很多开发者和媒体这几年都在观察的一个问题：测试版越来越频繁，公测文化越来越普及，但它们究竟提高了多少最终版本的质量？
理论上，beta 的价值在于扩大真实使用场景，提前暴露边缘问题。可前提是，反馈必须被有效吸收。如果开发者花时间测试、复现、录屏、写日志、提交报告，最终换来的只是模板化回复、要求重测、或者无声关闭，那么 beta 就会从“共同改进产品”的机制，变成“把 QA 外包给生态参与者”的姿态。久而久之，最直接的结果不是抱怨变多，而是高质量反馈变少。因为人会学会节约自己的热情。
这对苹果并不是小事。AI 时代的软件竞争，已经不只是功能数量的竞争，而是系统复杂度管理的竞争。苹果正试图在终端侧 AI、跨设备协同、隐私计算和系统级智能助手上同时推进，底层接口只会更复杂、模块耦合只会更深。越是在这种时候，开发者反馈越宝贵。你不能一边鼓励生态伙伴参与平台建设，一边又在流程上让他们感到“别添麻烦”。
从更大的行业视角看，这件事还有一个值得思考的问题：平台和开发者，到底是雇佣关系、合作关系，还是一种不对等但必须维持的共生关系？当一家平台足够强势时，它很容易把外部开发者对平台质量的投入视作理所当然。但历史已经反复证明，生态的韧性并不只来自市场份额，也来自信任。开发者不一定会立刻离开苹果，但他们会逐渐降低投入、减少冒险、放弃深入优化。对一个平台来说，这种“慢性失温”比一次公关风波更可怕。
苹果当然仍然会修掉很多问题，也仍然拥有业内最强的一批工程师。但如果它继续让反馈系统表现得像一个以关闭工单为目标的行政机器，那么受损的不只是开发者心情，还有苹果这些年最珍贵的那层东西：大家默认它最终会把事情做对的信任感。科技行业里，Bug 不可怕，可怕的是一个平台开始习惯于让别人证明问题存在，而不是自己证明问题被解决了。