OpenAI 向美政府状告 DeepSeek：他不讲武德！| 肘子的 Swift 周报 #075

几天前，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 竞争可能带来的安全风险。然而，对于那些自身尚未在知识产权问题上建立足够可信背书的年轻企业来说，积极寻求政策保护，反而可能削弱自身的创新动力，限制长期发展。

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

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

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

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

与许多常见的图表框架不同，Swift Charts 采用了声明式 API，这让某些开发者在实现交互时感到不太直观。在本文中，Itsuki[15]深入解析了 Swift Charts 的内置交互方式，并探讨了如何使用chartGesture(_:)来自定义手势，从而实现更灵活的用户交互体验。

SwiftUI 让用户界面开发变得更加直观，但由于其黑盒特性，开发者往往难以洞悉其底层运作机制。在这篇文章中，Mihai Popa[17]通过一种访谈式的叙述方式，清晰而简洁地阐释了 SwiftUI 的诸多核心原理，包括声明式渲染架构、状态驱动的界面更新机制、视图差异化比较（diffing）算法，以及与 UIKit 的桥接技术等关键内容。

曾几何时，我们在互联网上的浏览充满了探索的乐趣，随意点击、偶然发现，让每次搜索都可能成为一场意想不到的冒险。然而，如今 AI 答案引擎（如 ChatGPT、Perplexity、Grok、Gemini 等）正在重塑我们的信息获取方式——它们提供即时、精准的回答，却在无形中削弱了我们的自主性，让互联网的多样性逐渐消失。我们不再主动探索，而是被 AI 精选的答案所引导，错过了许多原本可能发现的独立创作者、小众社区和新鲜视角。在这篇文章中，Paul Stamatiou[19]深入探讨了这种变化对互联网生态的影响，并提出 AI 未来可能的个性化发展方向，以帮助我们找回探索的自由。

如果你觉得这份周报或者我的文章对你有所帮助，欢迎点赞、赞赏，并将其转发给更多的朋友。

参考资料

[1]

weekly.fatbobman.com:https://weekly.fatbobman.com

[2]

肘子的 Swift 记事本:https://fatbobman.com

[3]

Discord:https://t.ly/gzxeh

[4]

人工智能行动计划:https://www.whitehouse.gov/briefings-statements/2025/02/public-comment-invited-on-artificial-intelligence-action-plan/

[5]

68 期周报:https://fatbobman.com/zh/weekly/issue-068/

[6]

SwiftData 使用前必须了解的关键问题:https://fatbobman.com/zh/posts/key-considerations-before-using-swiftdata/?utm_source=fatbobman%20weekly%20issue%2075&utm_medium=web

[7]

Async 函数的幕后机制 (Behind the Scenes of Async Functions):https://l.fatbobman.com/w075-01

[8]

Vitaly Batrakov:https://www.linkedin.com/in/vitaly-batrakov/

[9]

当 Swift 编译器在标准库中删除代码时 (When the Swift Compiler Deleted Code in Stdlib):https://l.fatbobman.com/w075-02

[10]

WeZZard:https://x.com/realWeZZard

[11]

Pull Request:https://github.com/swiftlang/swift/pull/79872

[12]

Swift Testing 中的 Completion Handler 处理 (Swift Testing Completion Handlers):https://l.fatbobman.com/w075-03

[13]

Keith Harrison:https://x.com/kharrison

[14]

? SwiftUI：交互式图表 (SwiftUI: Interactive Charts):https://l.fatbobman.com/w075-04

[15]

Itsuki:https://x.com/itsuki68391179

[16]

? SwiftUI 的底层原理 (Under the Hood: SwiftUI):https://l.fatbobman.com/w075-05

[17]

Mihai Popa:https://x.com/ios_gems

[18]

互联网的探索感正在消失 (Browse No More):https://l.fatbobman.com/w075-06

[19]

Paul Stamatiou:https://x.com/Stammy