你可能知道我热爱 Rust 和 TypeScript，并且非常推崇优秀的类型系统。我发现它们很有用的原因之一是它们支持自动完成，这通常是一个很好的功能。拥有一个集成良好、合理且具有内存布局优化潜力的类型系统通常是一个好主意。
由此，你自然会认为这对于代理编码工具来说也很棒。它显然有一些好处。如果你让一个代理编写 TypeScript，然后代理添加类型，它的性能会很好。我不知道它是否比原始 JavaScript 性能更好，但至少看起来不会造成任何损害。
但大多数代理工具无法访问 LSP（语言服务器协议）。我曾尝试过一些能够访问 LSP（且提供类型信息）的代理编码工具，但并未从中获得任何实际好处。LSP 协议会降低速度并严重污染上下文。此外，这些模型尚未经过充分的训练，无法理解如何使用这些信息。如果仅从编译器以文本形式获取类型检查失败信息，就能获得更好的结果。
最终，你会得到一个代理编码循环，如果不启用类型检查，代理就会通过编写代码并在某处添加类型来向前推进。只要这段代码编译成某个版本的 JavaScript（如果你使用 Bun，其中大部分代码最终都会被类型擦除），它就会创建可运行的代码。然后它继续执行下去。但这种进展很糟糕——这种进展需要它之后回来清理类型。
这很奇怪，因为类型显然已经写好了，但却在很大程度上被忽略了。如果你把类型检查放到循环里，我的测试结果反而更差。这是因为代理设法让代码运行起来，但只有在运行完成后才会运行类型检查。直到那时，可能要等到很晚的时候，它才会意识到自己犯了类型错误。然后它就开始修复错误，可能会陷入循环，浪费大量的上下文。如果你让它在每次编辑后都进行类型检查，最终会消耗更多的上下文。
当类型本身极其复杂且难以理解时，情况会变得非常糟糕。TypeScript 的表达式功能晦涩难懂，而一些库则过度使用了复杂的结构（例如，条件类型）。LLM 几乎无法理解这些内容。例如，如果你授予它访问 TanStack Router 的 .d.ts 文件以及它用于使路由器系统正常工作的前向声明内容的权限，它根本无法理解其中的任何内容。它只能猜测，有时猜得很糟糕。它完全糊涂了。当它遇到类型错误时，它会执行各种操作，但这些操作都无济于事。
Python 类型检查的问题更加严重，因为我们必须面对一个非常复杂的生态系统，不同的类型检查器甚至无法就类型检查的工作方式达成一致。这意味着，至少从我的测试来看，LLM 甚至无法完全理解如何解决来自非 mypy 工具的类型检查错误。这种情况并非普遍存在，但如果你最终遇到一个复杂的类型检查错误而你无法自行解决，令人震惊的是，LLM 通常也无法完全弄清楚到底发生了什么，或者至少需要多次尝试。
Go 是一个类型赋能的杰出例子。Go 的类型表达力较弱，结构性很强。对象仅通过拥有某些方法即可符合接口。LLM 无需理解太多就能理解这一点。此外，Go 的类型强制执行得相当严格。如果类型错误，就无法编译。由于 Go 拥有一个更简单的类型系统，不支持复杂的结构，因此效果更好——既能让 LLM 理解他们编写的代码，也能让 LLM 理解你可能交给 LLM 的实际库。
我真的不知道该如何处理这种情况，但这些行为表明，尽力而为的类型系统或像 JSDoc 这样的类型提示更有价值。因为至少就 LLM 而言，它不需要完全理解类型，只需要大致了解某个对象可能是什么类型。对于 LLM 来说，更重要的是错误消息中的类型名称与源代码中的类型名称保持一致。
我认为，如今 LLM 的这种行为是否会影响未来的语言设计是一个有趣的问题。我不确定是否会，但我认为这在很大程度上证实了 Go 和 Java 等语言诞生的一些决策。尽管我过去曾批评它们处理问题的方法过于简单，而且设计可能不太重视开发人员，但现在我认为它们实际上处于一个相当不错的位置。它们的设计比我想象的要优雅得多。