作者：Cassidy Williams
排版：Alan Wang
AI 正在为“强类型 vs. 弱类型”的长期争论画上句号——当代码并非由你亲手编写时，类型系统正在成为保障代码安全与可靠性的最后一道防线。
这是一个亘古不变的话题：Tab 还是 Space、深色模式还是浅色模式、强类型语言还是弱类型语言。答案永远是——看情况。
但随着开发者越来越多地使用 AI 工具，变化正在发生：大家不仅更倾向于选择更流行、因而在模型中训练得更充分的语言和库，也在主动选择能降低风险的工具。当代码不再只来自开发者本人，还来自 AI 工具时，可靠性就成了更重要的考量。
强类型 vs. 弱类型
像 Python、JavaScript 这样的动态语言，在构建应用时可以让开发者快速前进，支持这些语言的人也正是看中了它们所带来的速度与灵活性。但这种敏捷性，往往缺少强类型语言所提供的那层安全网。
弱类型代码并没有消失，依然有其独特价值。就我个人而言，在一些普通的业余项目中，我很享受可以直接写代码、而不必为每一个细节都做定义的感觉。但当你无法掌控代码的每一行时，一些细微的错误就可能在没有任何检查的情况下悄然溜过。这时，由类型驱动的安全网概念就会显得格外有吸引力，甚至是必不可少的。而 AI 的出现，只是进一步放大了“并非由你亲手编写的代码”的数量，从而提高了风险。
类型系统在揭示模糊逻辑以及预期输入与输出不匹配方面，发挥着不可替代的作用。它们确保来自任何来源的代码，都能符合项目的整体规范。可以说，类型系统已经成为开发者、框架以及 AI 工具之间的共享契约——尤其是在 AI 为开发者生成越来越多脚手架和样板代码的背景下。
随着 AI 工具和智能体以前所未有的规模产出代码和功能，可靠性自然变得更加关键。而这，正是强类型语言在这场争论中胜出的地方。并不是因为弱类型语言“不好”，而是因为强类型语言恰恰能够捕捉到 AI 生成代码有时会带来的那一类意外问题。
类型安全真的有这么重要吗？
是的！
下一个问题。
不过说真的，一项 2025 年的学术研究发现：高达 94% 的 LLM 生成代码中的编译错误，都是类型检查失败导致的。想象一下，如果你项目里 94% 的失败都能消失，会发生什么？你的生活会更美好，皮肤会变好，甚至你可能都会长高一点。至少，你会少掉很多“为什么它现在返回的是一个字符串？”这样的调试时刻。
Octoverse 2025 如何看待强类型语言的崛起
Octoverse 2025 给出了明确答案：TypeScript 已经成为 GitHub 上使用最多的语言，并在 2025 年 8 月超越了 Python 和 JavaScript。
TypeScript 在 2025 年新增了 100 多万名贡献者（同比增长 66%，2025 年 8 月对比 2024 年 8 月），开发者总数约 260 万。这一增长部分来自于一些默认使用 TypeScript 脚手架的框架（如 Astro、Next.js、Angular），但报告同样发现了相关性证据：AI 辅助开发也推动了 TypeScript 的崛起。
这意味着，AI 不仅影响了代码写得有多快，还在影响开发者选择使用哪些语言和工具。而强类型生态也因此受益，因为它们能帮助 AI 将新代码更安全地嵌入现有项目，而不破坏原有假设。
不只是 TypeScript，其他强类型语言的增长同样迅猛
作为一种渐进式类型语言，Roblox 的脚本语言 Luau 实现了 超过 194% 的同比增长；Typst 常被拿来与 LaTeX 相提并论，但采用了函数式设计并具备强类型能力，其同比增长 超过 108%。甚至连 Java、C++、C# 这样的老牌语言，也在今年的报告中迎来了前所未有的增长。
这表明，渐进式类型、可选类型以及强类型都在持续获得动能——它们根据你正在构建的内容，以及你希望 AI 自动化到什么程度，提供了不同层级的安全护栏。
渐进式类型语言
类型系统并不会取代动态语言。但在与 AI 编程工具协作的过程中，它们之所以成为一种普遍的安全特性，是有充分理由的。
随着 AI 辅助开发和智能体开发越来越流行，类型系统很可能会在我们构建和交付可靠软件的方式中，占据更加核心的位置。
静态类型让代码更值得信赖，也更易维护。它们为开发者提供了一种共享且可预测的结构，减少意外，自然也就让你更容易进入 flow（没错，双关 😄）。
想要领先一步？阅读最新的 Octoverse 报告，并试试 Copilot CLI。
