OpenAI 向美政府状告 DeepSeek：他不讲武德！

在 weekly.fatbobman[1]订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本[2]查看更多的文章。加入 Discord[3]社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

OpenAI 向美政府状告 DeepSeek：他不讲武德！

几天前，OpenAI 向美国政府提交了一封长达十五页的进言，将 DeepSeek 带来的竞争威胁上升至国家安全层面，并试图将其框定为意识形态竞争。这是 OpenAI 对美国白宫科技政策办公室（Office of Science and Technology, OSTP）就人工智能行动计划[4]（AI Action Plan）公开征求意见的反馈。坦率而言，当看到这则新闻时，我不禁哑然失笑——难以想象行业巨头 OpenAI 会如此沉不住气，展现出这般脆弱的一面。

这两年来，OpenAI 等企业一直向全球灌输一种观念：打造领先的大模型必须依靠海量资金与超级算力，这是一个门槛极高的领域，普通玩家根本无缘参与。凭借这一论调和先发优势，OpenAI 创造了惊人的估值，并源源不断地吸引资本涌入。然而，DeepSeek 的出世打破了这一既定认知，促使越来越多的国家、企业乃至个人开始重新审视进入大模型领域的可能性。

OpenAI 显然察觉到了投资者对其“高门槛论”的迟疑与动摇。为了稳固自身地位，他们选择采取更为强硬的手段，急于重申资金的决定性作用，并巧妙地为自身对资本的渴求披上了一层“意识形态对抗”的外衣。

AI 行业，尤其是大模型领域今天取得的成就，源自众多科研人员和企业的共同努力与无私分享。作为一家受益于开源社区，并积极公开自身研究成果和技术细节的企业，DeepSeek 推动了社区的发展，也为降低 AI 训练和推理成本作出了贡献。这些开放成果本应惠及整个社会，当然也包括那些已处领先地位的 AI 公司。但正如我在第68 期周报[5]中所指出的：“那些习惯于高投入、大规模资源配置的头部 AI 企业，在短期内转变思维模式无疑是困难的。即使 DeepSeek 的方法能够提供一些启发，但如果没有彻底的理念变革，这些企业在降低训练成本上将难以取得持续的显著进展。”

显而易见，OpenAI 正陷入这种思维转型的困境。当意识到自身难以快速改善成本结构时，它选择了更为激进的竞争手段，即向美国政府寻求外部干预，以此减缓竞争对手发展的步伐。这种幼稚的做法像极了小孩子在向家长告状，或许能在短期内缓解资本市场的压力，但从长远来看，并不能解决企业自身的发展瓶颈。

AI 的崛起不仅是人类科技史上的一次重大变革，也是一场充满商业机遇的挑战。作为拥有广阔市场前景的朝阳产业，激烈的竞争在所难免，各国与企业纷纷加紧布局抢占先机。在大模型技术逐渐接近性能天花板，各类模型性能日益趋同的当下，能够提供特色应用场景和具备更高性价比的产品，才是真正决定市场胜负的关键。OpenAI 此番或许并未采用合适的竞争策略——如果不能坦诚面对并有效解决自身存在的结构性问题，那么未来真正能取而代之的，很可能并非它所指控的 DeepSeek，而是在性价比与特色场景方面更具优势的那些曾被其甩在身后的国内竞争者。

值得一提的是，与 OpenAI 相比，Anthropic 向白宫提交的反馈甚至更为极端。DeepSeek 不过是众多挑战现有格局的新锐之一，它只是让更多人看到了进入这个所谓“高门槛”行业的可能性。相信很快我们会看到来自全球各地更多类似 DeepSeek 式的成果展现。

我从不否认知识产权的重要性，也不否认国家级 AI 竞争可能带来的安全风险。然而，对于那些自身尚未在知识产权问题上建立足够可信背书的年轻企业来说，积极寻求政策保护，反而可能削弱自身的创新动力，限制长期发展。

原创

SwiftData 使用前必须了解的关键问题[6]

在刚刚结束的 Let’s Vision 2025 大会上，我收到了许多关于 SwiftData 的提问：“SwiftData 是否已经足够成熟，可以用于实际项目？”、“作为初学者，如何高效地使用 SwiftData？”。这些问题反映了开发者对苹果最新数据持久化框架的浓厚兴趣，但也透露出技术选型时的犹豫。本文旨在为对 SwiftData 感兴趣的开发者提供一份指南，帮助你了解 SwiftData 的优势与局限，并根据项目需求做出明智的技术选择。

近期推荐

Async 函数的幕后机制 (Behind the Scenes of Async Functions)[7]

Swift Concurrency 带来了更安全、更高效的异步编程模型，但你真的理解它的内部运作吗？在这篇文章中，Vitaly Batrakov[8]深入解析了async/await、Tasks、Jobs、Executors、Actors 以及 Cooperative Thread Pool 的核心概念，帮助开发者建立更清晰的 mental model。本文适合已有并发基础的开发者，能帮助你更全面地掌握 Swift Concurrency 的工作原理。

当 Swift 编译器在标准库中删除代码时 (When the Swift Compiler Deleted Code in Stdlib)[9]

Swift 编译器的优化机制本意是提升性能，但有时候却可能“优化过头”，引发意想不到的 Bug。WeZZard[10]在这篇文章中分享了一起use-after-free崩溃案例，该问题发生在-Osize优化级别下，根本原因是 Swift 编译器误删了关键代码，导致程序访问已释放的内存。幸运的是，WeZZard 经过深入分析后，在 Swift 社区提交的Pull Request[11]已成功合并，修复了这个问题。这篇文章或许读起来有些硬核，但如果你对 Swift 编译器优化、SIL 以及 LLVM 感兴趣，它绝对值得一读！

Swift Testing 中的 Completion Handler 处理 (Swift Testing Completion Handlers)[12]

在XCTest中，我们通常使用XCTestExpectation来等待异步操作完成，但Swift Testing并没有提供直接等效的expectation机制。官方推荐的做法是使用continuations来将基于 completion handler 的异步代码转换为async/await。如果你是从零编写测试，这种方式非常自然，但当你需要迁移大量XCTest代码时，工作量可能会大幅增加。Keith Harrison[13]在本文中分享了一种高效的迁移策略，利用withCheckedContinuation简化 completion handler 代码的转换，让你在迁移过程中减少不必要的重复工作，大幅提升效率。