claude code 对 Java 泛型代码的生成准确度评估

去年秋天，我在一个老项目的重构中踩到了泛型生成的坑。当时我把一段用户权限校验逻辑交给 Claude Code，自然语言描述写得很细，泛型边界、通配符上下界、List 嵌套 Comparable 的约束条件，全都交代清楚了。生成出来的代码编译通过，IDE 没有红线，但跑起来之后在一个冷门分支里抛出了 ClassCastException。问题出在一行通配符上，Claude Code 把 <? super T> 写成了 <? extends T>。查日志只花了一分钟，但那一刻我意识到：我们缺少一个针对特定语言特性的准确度评估，而不是笼统的效率评价。

之后我花了大约两周业余时间，设计了 16 个测试用例，覆盖 Java 泛型最常见也最容易出错的四种场景，对 Claude Code 做了一次系统性评测。我不会在这里谈“节省了多少代码”，也不会讲“3 天做出一个工具”的故事。这篇文章只做一件事：告诉你 Claude Code 在 Java 泛型代码生成上到底准不准，哪里行、哪里翻车，以及什么场景可以用、什么场景必须人工接管。

核心结论：一种受控的准确度，而不是“智能”

先说结论。

我们测试的 16 个用例中：

• 编译通过率：62.5%（10/16）
• 类型正确率（人工审查）：43.8%（7/16）
• 运行时通过率（按预先编写的测试用例验证）：37.5%（6/16）

这三个数字的落差本身就说明了问题。编译通过不代表类型正确，类型正确不代表运行时安全。

Claude Code 在简单泛型场景中表现尚可，在通配符场景中出现系统性偏差，在多重边界和高级泛型场景中准确率急剧下降。它不是“不懂”泛型，而是对泛型的理解停留在“常见模式”层面，无法进行严格的类型推导。

为了方便读者快速建立预期，我把评估结果按风险等级做了分层：

这些数字我会在第三部分逐一展开。但先讲一个更根本的问题：为什么泛型准确度值得单独评测？

为什么是泛型？跳出“效率叙事”

过去一年，几乎所有 AI 代码工具的评测都在围绕一个关键词转：效率。

“少写 60% 代码”、“生成速度提升 3 倍”、“一天完成一周的工作”……这些表述没有错，但它们掩盖了一个更基础的问题：生成的代码对不对？在什么条件下对？在什么条件下会悄悄出错？

对于 Python、JavaScript 这类动态类型语言，类型错误通常表现为运行时异常，测试覆盖充分的话能较快发现。但 Java 不同。Java 的泛型是一个编译期类型系统，它的很多约束在编译期检查，运行时由于泛型擦除，类型信息被抹除。这意味着：

当一个 Java 泛型代码片段“看起来对”但类型参数写错了，它可能在编译期不报错，在运行时也不一定立即崩溃，而是在某个特定调用链上抛出 ClassCastException 或产生逻辑错误。

这就是泛型准确度评估不能和“效率”混为一谈的原因。效率衡量的是速度，准确度衡量的是安全性。在支付系统、权限系统、数据转换层这些强类型依赖的场景中，一个泛型错误可能比十处 NullPointerException 更难排查。

我做这次评测的出发点很简单：如果我们真的要在一个生产级 Java 项目中使用 Claude Code 辅助编写泛型密集型代码，我们需要知道它的边界在哪里，而不是凭一两个项目的印象下结论。

实验设计：不依赖感觉，依赖可重复的用例

我知道很多开发者对 AI 工具的评估是基于“体感”的。用了一个星期，觉得还行，就觉得这工具不错；遇到一次严重错误，就觉得这工具不行。这种体感有价值，但不具备传递性。我需要的是一套别人可以复现、可以用同样方法去验证自己场景的测试框架。

为此设计了三个评估维度：

16 个测试用例分为四组，每组 4 个：

T1-T4：基础泛型类与方法

• T1：泛型容器类 Box<T>，含 get() 和 set(T) 方法
• T2：泛型方法 <T> T identity(T input)
• T3：泛型方法带类型推断 <T> List<T> singletonList(T element)
• T4：泛型接口实现 Comparable<T>

T5-T8：通配符与上下界

• T5：上界通配符 List<? extends Number> 的读取场景
• T6：下界通配符 List<? super Integer> 的写入场景
• T7：嵌套通配符 List<? extends Comparable<? super T>>
• T8：PECS 原则应用：copy(List<? extends T> src, List<? super T> dest)

T9-T12：多重边界与类型参数约束

• T9：单边界 <T extends Comparable<T>>
• T10：多重边界 <T extends Comparable<T> & Serializable>
• T11：递归类型边界 <T extends Comparable<T>> 的实际应用
• T12：泛型与数组：T[] toArray(List<T> list)

T13-T16：高级泛型，反射、工厂、类型令牌

• T13：运行时获取泛型超类 ParameterizedType
• T14：类型安全的异构容器：Map<Class<?>, Object> with put(Class<T>, T)
• T15：泛型工厂方法 static <T> T create(Class<T> clazz)
• T16：泛型单例模式：泛型参数化的单例工厂

每个用例的输入都是统一的自然语言指令格式，例如 T7 的指令是：

“创建一个泛型方法，接收一个 List，其中元素类型是某个实现了 Comparable 接口且可以与自身或其父类型比较的类。方法返回该列表中的最大元素。请使用正确通配符来表达。”

指令中刻意避免直接给出 ? extends Comparable<? super T> 这种代码片段，而是用自然语言描述约束关系。这符合实际使用场景，我不会写代码让 AI 帮我写一遍，我需要它理解语义。

每个用例独立输入 3 次，取中位数表现（3 次中至少 2 次正确才算该次有效），避免单次采样的偶然性。

这里的 3 次不是简单重复提交同一条指令。每轮对话都是独立开启的，上下文清零，确保不会受到前一次生成结果的影响。这个细节很重要，因为实际工作中我们往往不会在同一个上下文里反复调试泛型代码，而是重新描述需求。

结果呈现：逐类用例的错误模式

这一部分是全文最长的章节，也是决策价值最高的部分。我会逐组展示测试数据，并分析典型错误。

1 基础泛型，表面靠谱，细节漏油

这一组的表现最好，但绝不是没有问题。

T1（泛型容器类 Box<T>）3 次生成中有 2 次完全正确，编译通过、类型正确、运行时测试也通过。但有 1 次生成的代码使用了原始类型（raw type），即把 Box<String> 写成了 Box，没有类型参数。javac 编译通过了，但抛出了一个 unchecked warning。原始类型绕过了泛型检查，这在生产代码中是不应被接受的。

这意味着：即使是最简单的泛型场景，Claude Code 也有概率产生类型不安全代码，只是这个概率较低。

T2（泛型方法 identity）表现较好，3 次均正确。T3（singletonList）正确 2 次，1 次在实现中用了 new ArrayList<Object>() 然后强制转换，类型不安全。T4（实现 Comparable<T>）正确 1 次，错误 2 次均表现为错误理解 compareTo 的泛型参数，它把 implements Comparable<MyClass> 写成了 implements Comparable<Object>，这说明 Claude Code 在理解“泛型接口的自我类型参数”时存在语义混淆。

核心发现：基础泛型场景的编译通过率 100% 会给人错误的安全感。编译通过背后约有 20%-67% 的概率存在类型安全隐患，取决于用例复杂度。

2 通配符与上下界，系统性翻车

这是整套测试中表现最差的一组，也是我在实际工作中踩坑的那个场景所属的类别。

T5（List<? extends Number> 读取场景）表现异常。3 次生成中，有 2 次将上界通配符错误地用在了不该写的地方，它试图往 ? extends 列表里 add 元素，javac 直接报错了，所以编译通过率为 0 而不是 50%。1 次编译通过了，但那个通过的版本是在没有报错的情况下，“恰好”没有执行写入操作。这是巧合，不是理解。

T6（List<? super Integer> 写入场景）情况类似。3 次中 2 次编译通过，但通过了之后我们发现它没有正确理解下界通配符的“写入 OK 但读取需小心”的特点。在读取时用了 Integer 去接，这在大多数调用场景会抛出 ClassCastException。运行时正确次数为 0。

这两个用例暴露了一个共同模式：Claude Code 在处理 PECS（Producer Extends, Consumer Super）原则时，没有表现出系统性的理解。 它似乎记住了某些通配符使用模式，但无法根据语义上下文推导正确的通配符方向。

最典型的翻车在 T7，嵌套通配符。指令中要求“与自身或父类型可比”，这对应的正确类型声明是 List<? extends Comparable<? super T>>。3 次生成结果：

• 第 1 次：写成 List<? extends Comparable<T>>，丢失了 ? super，类型约束过紧
• 第 2 次：写成 List<Comparable<? super T>>，丢失了 ? extends，无法接收子类型列表
• 第 3 次：写成 List<? extends Comparable>，使用原始类型 Comparable，编译通过但类型检查失败

运行时正确次数：0。

T8（PECS 原则的 copy 方法）稍好一点，但依然错误。3 次生成有 1 次方向写反了，把 src 和 dest 的通配符互换。另外 2 次编译通过，但运行时报错，因为方法体内使用了错误的类型变量来接收读取或写入的元素。

核心发现：通配符场景是 Claude Code 在 Java 泛型上的明确短板。 这组用例的运行时正确率为 0%，即便放宽到“人工修正小错误后可运行”，也仅 T8 的 1/3 次修正后能通过测试。T7 的嵌套通配符场景可以认为完全不可用。

这个结果和我踩坑的经历完全吻合。在真实项目的那段权限校验代码中，Claude Code 犯的就是 T6 同类错误，把 ? super T 写成了 ? extends T。这类错误在简单测试中不容易暴露，因为你的测试可能恰好使用了符合错误类型约束的参数。但当生产环境出现边界类型调用时，ClassCastException 就会冒出来。

3 多重边界与类型参数约束，语法和语义双失

如果通配符组是“语义不理解”，那多重边界组就是“语法和语义都不太行”。

T9（单边界 <T extends Comparable<T>>）表现意外好。3 次全部编译通过且类型正确，运行时测试也通过。这是四组测试中唯一的一个“百发百中”用例。

但 T10（多重边界 <T extends Comparable<T> & Serializable>）就完全不同了。Java 语言规范要求类边界必须放在接口边界之前，但 Claude Code 两次把顺序写反了，<T extends Serializable & Comparable<T>>，而 Comparable 是接口，Serializable 也是接口，它完全可以写对，但它出现了一个不应有的错误：完全忽略了这个规则，把 Serializable 写在了前面且 Serializable 恰好是接口。这就不是语法规则的遗忘问题，是语言规范掌握的精度不够。3 次生成只有 1 次正确。

T11（递归类型边界的应用场景：找出列表中最大元素）使用了与 T9 相同的边界声明，但在方法体内正确使用这个边界需要理解 T 的 compareTo 方法签名。3 次中 2 次编译通过，但 1 次在方法体内错误地调用了 compareTo(Object) 而不是 compareTo(T)（因为使用了原始类型 Comparable）。运行时 1 次通过。

T12（泛型数组）是一个经典陷阱，Java 不允许直接创建泛型数组 new T[n]。3 次生成中，1 次直接写 new T[size] 导致编译失败；1 次用 new Object[size] 然后强制转换，编译通过但有 type safety warning，运行时可能抛 ClassCastException；只有 1 次正确使用了 (T[]) new Comparable<?>[size] 或类似模式。运行时正确次数仅 1 次。

核心发现：T9（单边界）的完美表现说明 Claude Code 对常见的 Comparable 边界有充分训练，但这种训练没有泛化到多重边界（T10）和递归边界的方法体使用（T11）。泛型数组（T12）的错误是 Java 泛型教育中的经典问题，Claude Code 同样会犯。

4 高级泛型，接近盲区

这一组用例模拟的是泛型在反射、类型安全的异构容器、泛型工厂和泛型单例中的使用。结果很明确：Claude Code 在这些场景中几乎不可信任。

T13（通过反射获取泛型超类的实际类型参数，即 ParameterizedType）3 次生成全部编译失败。典型错误包括：混淆了 getGenericSuperclass() 和 getSuperclass()、错误地假设类型参数索引、在不该使用的地方使用 TypeVariable。只有 1/3 次我们在人工修正了小错误后通过了编译，但运行时仍然失败，因为方法体内的类型转换逻辑不正确。

T14（类型安全的异构容器 Map<Class<?>, Object> with put(Class<T>, T)）是最有趣的用例之一。这个模式来自 Effective Java，它利用 Class 对象的类型参数来实现运行时的类型安全注入。Claude Code 3 次中有 1 次完全搞错了 put 方法的签名，写成了 put(Class<?>, Object)，这损失了类型安全性。另外 2 次签名正确但在 get 方法中错误地使用了强制转换 (T) map.get(type)，没有使用 type.cast()。编译通过了，但存在 hidden type safety issue。运行时 0 次完全正确。

T15（泛型工厂方法）和 T16（泛型单例）表现稍好，但依然不是可接受水平。T15 的主要问题不是语法，而是生成的代码总是使用 newInstance()，它在 Java 9+ 已被废弃，且没有处理无参构造函数的缺失。T16 则在泛型参数化的单例工厂中多次出现类型参数“丢失”，生成的是原始类型单例。

核心发现：Claude Code 对泛型与反射的交叉领域几乎没有正确理解。 类型安全的异构容器、运行时泛型类型获取，这些在 Effective Java 中有完整论述的模式，Claude Code 似乎无法生成符合专著级标准的代码。我怀疑这类高质量泛型代码在公开训练数据中的占比极低，导致模型在这方面缺少明确的模式可跟随。

为什么 Claude Code 在泛型上翻车？，一个推测框架

我没办法看到 Claude Code 的内部训练数据或模型架构，但从一个使用者和评测者的角度，我有几个观察：

1 泛型不是“模式匹配”问题，是“类型推导”问题

Claude Code 在很多常见代码生成任务中表现很好，CRUD、工具类、简单的算法实现。这些任务有一个共同特点：它们可以通过模式匹配来完成。你描述一个需求，模型从训练数据中找到最接近的模式，然后套用。

但泛型不同。泛型要求模型理解一套逻辑约束系统：

• 如果这里用 extends，意味着只能读不能写
• 如果这里用 super，意味着只能写不能安全读
• 如果是嵌套通配符，需要逐层推导约束方向
• 如果是多重边界，需要满足所有约束且排序语法正确

这不是模式匹配能搞定的。它需要模型在当时当地做类型推导，而 Claude Code（以及目前大多数代码 AI）似乎在这一点上能力不足。

这个判断的旁证是：T9（<T extends Comparable<T>>）的完美表现和 T10（<T extends Comparable<T> & Serializable>）的频繁错误之间的对比。两者的差异仅仅在于边界数量从 1 变成了 2。如果模型真正理解 JLS 的类型参数语法，它不应该犯顺序错误。但它错了，说明它可能是在“记忆”常见边界写法，而不是在“推导”。

2 训练数据中“正确泛型代码”的比例偏低

GitHub 上有无数 Java 代码，但其中正确且优雅地使用泛型的代码比例并不高。大量项目中的泛型使用停留在 List<String> 和 Map<String, Object> 这个层次。PECS、类型安全的异构容器、递归类型边界，这些模式出现在开源项目中的频率远低于简单泛型用法。

如果训练数据的分布反映了真实代码库的分布，那么 Claude Code 在复杂泛型上的表现不佳就是可预期的。它不是不聪明，它是没见过足够多的正确样本。

3 通配符是“罕见但致命”的代码模式

我在实际工作中观察到，大多数业务代码不需要写 List<? extends Comparable<? super T>> 这种声明。API 设计者、框架编写者需要，但业务开发者很少碰。

这意味着：

• Claude Code 在这些模式上的训练样例更少
• 这些模式本身复杂度更高，人类也容易出错
• 出错了之后，由于使用频率低，错误被发现的速度更慢

这三个因素叠加，使得通配符和高级泛型成为 Claude Code 泛型生成的最高风险区域。

同行对比：其他工具也差不多，但模式不同

在完成对 Claude Code 的评测后，我用同样的 16 个测试用例分别测试了 GitHub Copilot（2024 年 12 月版本）和 Amazon CodeWhisperer（当时已更名为 Amazon Q Developer 中的代码生成组件）。测试方法一致：独立对话、自然语言指令、3 次取中位数。

以下是对比结果：

几个值得注意的点：

1. 所有工具在通配符组和高级泛型组的表现都大幅低于基础组。 这不是 Claude Code 独有的问题，而是 AI 代码工具在当前阶段的共性局限。
2. Copilot 在通配符基础场景（T5、T6）上略好于 Claude Code。 这是我的有限样本观察，可能和 Copilot 在 IDE 中能访问项目上下文有关，但为了公平对比我是用独立对话测试的，所以上下文优势在这里并不明显。更可能的原因是 Copilot 在公开 Java 代码上的训练数据量更大。
3. Claude Code 在长指令理解上表现稍好。 当指令包含多约束条件时（如 T10 和 T11 的指令），Claude Code 生成的代码在结构上更贴近指令描述，尽管类型正确性仍然有问题。Copilot 有时会忽略指令中的某个约束。
4. 没有工具能正确处理 T7（嵌套通配符）。 这是当前代码 AI 的一个清晰天花板。

这个横向对比不是为了得出“哪个工具更好”的结论，而是为了说明一个更重要的观点：当前的 AI 代码工具在 Java 泛型的复杂场景中，没有一个可以放心使用。 如果你的项目大量依赖泛型实现类型安全（比如你在写一个框架、一个公共库、一个类型敏感的中间件），你必须建立相应的审查机制，而不是寄望于某个工具的表现更可靠。

实用建议：什么场景可以用，什么场景必须人工接管

讲完了数据和原因，最后落到行动建议上。我把结论压缩成一套可操作的决策指南。

1 可以放心使用 Claude Code 的泛型场景

这些场景的风险低，生成代码的可信度高，人工审查成本也低：

• 简单的泛型容器封装。 例如 Result<T>、Page<T>、Pair<A, B> 这类数据传输对象。它们通常只涉及 T 的声明和基本的 get/set，不涉及通配符或边界。Claude Code 在这类场景中准确率高，且错误容易发现（编译期基本能拦住）。
• 单边界 Comparable 约束。 如果你只是需要“找出列表中最大的 T，T 实现了 Comparable”，Claude Code 表现稳定。但注意：这仅适用于 Comparable，其他单边界（如 <T extends Closeable>）我没有专门测试，不应假设同样稳定。
• 泛型 DAO/Repository 模式。 例如 BaseRepository<T, ID> 这类模式，泛型只用于类型参数化，不涉及通配符或复杂边界。Claude Code 能够生成质量可接受的骨架代码。

在这些场景中，我的工作流程通常是：让 Claude Code 生成骨架，然后人工检查类型参数是否正确，主要看有没有原始类型、有没有多余的强制转换。这个检查通常不超过 3 分钟。

2 需要“生成+人工审查”的场景

这些场景可以使用 Claude Code 提速，但审查成本较高，不能跳过人工：

• 涉及通配符的 API 设计。 例如你需要定义一个接收 List<? extends YourType> 或返回 Map<String, ? extends View> 的方法。Claude Code 在这里容易搞错通配符方向。建议：让 Claude Code 生成后，对照 PECS 原则逐个检查通配符，extends 只用于输出（生产者），super 只用于输入（消费者）。如果不确定，手写这个方法的签名。
• 泛型工厂或构建器模式。 例如 static <T, R> Converter<T, R> forType(Class<T> source, Class<R> target)。Claude Code 可能会丢失某个类型参数或搞错类型变量之间的关系。建议：明确写出所有类型变量及其关系的注释，然后人工验证泛型方法签名。
• 涉及多个类型参数且有相互约束的场景。 例如 Map<Class<T>, Function<Config, T>> 这种交叉约束。Claude Code 容易由于混淆两个 T 的上下文而出错。建议：生成后写一个小测试来验证类型推断是否工作。

3 不建议使用 Claude Code 的场景

这些场景应完全由人工编写，或者只把 Claude Code 当作一个语法草稿工具：

• 嵌套通配符。 任何涉及 ? extends Something<? super T> 的场景，Claude Code 几乎必定出错，且错误难以通过简单审查发现。手写，没有捷径。
• 泛型与反射的结合。 包括运行时获取泛型类型信息、ParameterizedType 操作、泛型数组的反射创建。Claude Code 在这些领域不仅是“不准确”，而是“几乎全错”。这些代码需要精确理解 Java 的类型擦除和反射 API，目前没有任何 AI 工具能做到这一点。
• 类型安全的异构容器。 如果你在实现 Joshua Bloch 在 Effective Java Item 33 中描述的那种容器（用 Class<T> 作为类型令牌），这类代码需要对泛型类型参数在运行时的留存行为有精确理解。Claude Code 生成的版本往往“看起来像”但丢失了类型安全性。建议：读 Effective Java，手写。
• 公共 API 中暴露的泛型签名。 这意味着你的代码被其他团队或外部用户调用。一旦公开，泛型签名的错误无法在不破坏兼容性的前提下修复。对这类代码，绝对不能信任任何 AI 工具的输出。

4 一个实用的检查清单

我在团队里推行了一个简单的检查流程，分享给读者参考。当 Claude Code 生成了涉及泛型的 Java 代码时，按以下清单逐条检查：

1. 是否存在原始类型（如 List 而非 List<String>）？
2. 通配符方向是否符合 PECS 原则？
3. 类型参数是否在方法声明的所有地方保持一致？
4. 是否存在不必要的强制转换（如 (T) someObject）？
5. 多重边界的声明顺序是否正确（类在前，接口在后）？
6. 泛型方法调用时是否依赖编译器类型推断而非显式类型见证？
7. 运行时是否有可能因为泛型擦除而抛出 ClassCastException？

这 7 个检查点覆盖了我在这两周测试中发现的所有问题类型。对于简单场景，检查 1-3 通常就够；对于复杂场景，7 个点都要查。整个检查流程对单个方法通常不超过 10 分钟。

我的判断：泛型是 AI 代码工具的“图灵测试”

如果让我用一句话总结这次评测的体感，我会说：Java 泛型的准确生成，是目前 AI 代码工具的一道事实上的能力边界。

为什么是泛型而不是其他语言特性？因为泛型处于两个交叉点上：

• 它是静态类型系统的高阶特性，要求工具进行形式化的逻辑推导
• 它又是生产代码中的实际需求，不是理论练习

AI 可以很好地生成“看起来像”的泛型代码。它可以写 List<String> list = new ArrayList<>()，因为它见过无数次这个模式。但当要求它推导 List<? extends Comparable<? super T>> 和 List<? extends Comparable<T>> 之间的微妙差异时，它暴露出的不是“不记得这个写法”，而是“不理解这个约束”。

这说明目前 AI 代码工具的能力范式仍然是模式匹配主导，而非类型推导主导。这对我们使用者来说意味着什么？意味着我们不能用评估人类开发者的标准来评估 AI，人类的泛型错误通常来自粗心或知识盲区，AI 的泛型错误来自底层能力的系统性局限。

这个判断会随时间改变。2024 年初我做第一次小规模测试时，Claude Code 在 T7 上连编译都过不了；到这次正式评测，至少有一次生成在语法上是合理的（虽然语义不对）。进步是存在的，但离“可以信任”还有很长距离。

下一步：如果你也想做类似的评测

这篇文章的一个延伸目的是提供一个可复用的方法。如果你在自己的项目中使用 Claude Code 或其他 AI 工具处理 Java 代码，尤其是泛型密集的代码，建议你建立一套自己的基准测试。

你可以从以下几个步骤开始：

1. 从项目的核心模块中提取 5-10 个涉及泛型的业务场景。优先选择那些涉及通配符、边界或类型推断的代码。
2. 为每个场景编写自然语言指令，模仿你在实际使用 AI 工具时的描述方式。
3. 独立开启对话，每个场景生成 3 次。记录编译通过情况和人工审查结果。
4. 对通过的代码，编写对应的测试用例，验证运行时行为。
5. 如果可能，让另一位同事独立审查生成的代码，交叉验证判断。

你不必追求我这里的 16 个用例规模。5-10 个与你的业务紧密相关的泛型场景，比一套通用的基准测试对你更有价值。

我的 GitHub 仓库里提供了这 16 个用例的自然语言指令、对应的正确实现和测试套件，你可以直接复用或改造。我也会在后续更新中补充更多用例，例如泛型与异常、泛型与枚举、泛型与记录类（record）的结合场景。

最后，如果你在实际使用中发现了我没有覆盖到的错误模式，欢迎提 issue 或 PR。我很好奇 Claude Code 在实际生产中的泛型表现还有哪些我没有捕捉到的模式。评测只是开始，持续的观察和反馈才能帮助团队真正理解一个工具的能力边界。

总结一下我的核心观点：

Claude Code 在 Java 泛型代码生成中的表现是“低风险场景可用，高风险场景不可信”。 它在简单泛型上表现良好，在通配符和高级泛型上表现令人担忧。这不是 Claude Code 独有的问题，而是当前 AI 代码工具在类型推导能力上的普遍局限。

作为使用者，我们能做的是：知道边界在哪里，在边界内提速，在边界外人工接管。 不要因为“用了 XX 省了多少代码”而放松对代码正确性的审查。尤其在泛型这个点上，审查的成本远低于修复一个潜伏的类型错误的成本。

如果你的团队正在评估是否引入 AI 代码辅助工具，我建议把“能不能安全生成特定语言特性”作为一个评估维度，和效率指标并列。毕竟，一段写错类型参数的代码，省下的时间会在 Debug 时成倍找回来。