Tabnine 的一个 Java 例子：把“可能为空”写进代码，再修调用与测试

一处空指针，表面上是少写了一个判断，根源却可能是上下游从没约定过“这里能不能返回空”。Tabnine 的官方 Java 样例，恰好把这个问题讲得很具体：先让可空信息出现在代码里，再让代理跟进调用与测试。

这个例子比泛泛介绍“AI 能修 Bug”更值得看，因为输入很短，错误链也清楚。官方 Agents in Action里的关键部分是：

Customer customer = customerService.getCustomerById("999");
String email = customer.getEmail();
notificationService.sendEmail(email, "Welcome!");

官方说明，在这个示例中，查询返回的 customer 是 null，随后调用 getEmail 就会触发空指针。错误发生在调用点，但返回值的约定来自服务层。

让代码表达“可能没有结果”

文档提出的一步是添加 nullness annotations，也就是用 Nullable、NotNull 等注解表达参数、字段或返回值能否为空，让静态检查更容易追踪数据流。随后，代理再调整代码，并修改测试以匹配处理方式。

这条路径与只在当前行补 if 有不同意义。返回值如果确实允许为空，调用方就需要知道这一点；如果业务上保证不为空，则应追查服务契约为什么被破坏。注解让这个选择显式存在，便于其他调用处和工具继续使用，而不是只让当前报错暂时消失。

不过，注解不是对业务的替代判断。查不到客户时应该提示不存在、停止发邮件，还是走其他流程，必须由项目需求决定。官方没有为所有 Java 应用给出同一个处理答案，也不能把演示里的静态分析情况推广成所有 IDE 都找不到这种问题。

使用指南列出了 Agent 的项目读取、搜索、诊断、应用代码和终端等原生工具。对于这类任务，它们分别对应寻找返回定义、查看使用位置、获得检查结果和改动实现。

实际采用时，可以把目标收窄成教学任务：“为客户查询标明可空约定，检查调用方怎样处理查无结果，并补对应测试。”验收材料就不只是新增了几个注解，还包括调用处的行为和查无结果时的测试。这样才能看见一个跨方法问题是否被完整接住。

生成测试之后，断言仍要依据业务，而不能仅照着新实现写一个始终会通过的结果。注解库和静态分析工具也需要在所用项目中正确配置，否则写上符号未必产生预期检查。

Tabnine 当前提供 IDE 和 CLI Agent 等入口，聊天与自动补全也有不同职责。这个案例适合已经有工程、依赖和测试的人，不需要为了认识它先让模型生成一个全新应用。

我会保留这个官方样例作为试用任务的起点：输入足够具体，输出能落到可读的代码约定、调用修改和测试三处。至于模型、部署与账号条件，应按团队实际配置核对，不能从产品的隐私宣传推导出任意安装都完全离线。