代码生成不是终点：飞算JavaAI + Kimi 的“生成-验证”闭环实践

代码生成不是终点：飞算JavaAI + Kimi 的“生成-验证”闭环实践

AI 生成代码最常见的翻车姿势，不是编译报错，而是“编译干净、自测全绿、一上预发就崩”。我用飞算JavaAI（飞算科技面向 Java 开发者的 IDE 插件）搭配 Kimi 系模型跑了几个月，被坑过也验证过，结论收敛成一句话：生成质量取决于模型，交付质量取决于验证机制。

人的角色随之改变：从“写代码”，变成“定验收标准、跑验证、把失败结果喂回去”。

下文按踩坑顺序展开：一次全表扫描的翻车复盘、单次生成不可验收的原因、一键工程构建与版本快照的用法、按等价类生成单测的实践，文末附一张可直接抄的速查表。

一次翻车复盘：编译通过，EXPLAIN 不过

上月接手订单中心改造，要给订单列表页加“按订单号模糊搜索”。需求丢给飞算JavaAI 的 Javachat 模式（智能会话有智能问答、Javachat、智能体三种模式，带工程上下文的改码活我基本用 Javachat），Kimi-K3 几十秒返回完整实现：Controller、Service、Mapper XML 一条龙，注释齐全，编译零警告。我扫了两眼没看出毛病，合入。

三天后运营找上门：列表页翻到靠后的页码，一次要卡七八秒。慢日志里的 SQL 长这样：

SELECT * FROM t_order
WHERE tenant_id = 1001
  AND order_no LIKE CONCAT('%', 'SO202611', '%')
ORDER BY create_time DESC
LIMIT 20 OFFSET 980000;

EXPLAIN 结果 type=ALL，扫描行数一百四十多万。两个问题叠在一起，每一个单看代码都发现不了：LIKE 的前置通配符让 B+ 树索引直接失效，只能全表扫；深分页用 OFFSET，数据库要老老实实走过前 98 万行再丢弃，页码越深越慢。

生成代码为什么会这样？因为它是从“这个需求最常见的写法”里采样出来的——绝大多数教程里的分页就是 LIKE 加 ORDER BY 加 LIMIT OFFSET，模型给出的是“最像标准答案”的答案，而不是“你这张表最正确”的答案。编译器不报错，小数据量自测也正常，只有 EXPLAIN 和慢日志会说话。

修复方案我定的，两条：模糊搜索改成按单号前缀匹配——跟运营确认过，他们习惯就是输前缀，LIKE 从 ‘%xxx%’ 变成 ‘xxx%’ 就能吃索引；分页从 OFFSET 换成游标式，记住上一页最后一条记录的主键 id。代码让模型按方案重写：

/** 游标分页：lastId 为上一页末条主键，首页传 null */
public List<OrderVO> listOrdersAfter(Long tenantId, Long lastId, int size) {
    return orderMapper.selectList(
            Wrappers.<Order>lambdaQuery()
                    .eq(Order::getTenantId, tenantId)
                    .lt(lastId != null, Order::getId, lastId)
                    .orderByDesc(Order::getId)
                    .last("LIMIT " + size));
}

索引只留 tenant_id 一列就够——InnoDB 的二级索引天然挂着主键，id 倒序扫描直接命中。同一页数据从 6.8 秒降到 20 毫秒以内。从那以后我固定了一个习惯：方案我来定，代码它来写，顺序反了坑就在前面等着。

同一周还有第二次翻车，性质不同。让模型写订单服务与库存服务的联动逻辑，它规规矩矩让两个 Service 用字段注入互相 @Autowired，项目直接起不来：

***************************
APPLICATION FAILED TO START
***************************

Description:
The dependencies of some of the beans in the application context form a cycle:

┌─────┐
|  orderService
↑     ↓
|  inventoryService
└─────┘

Spring Boot 2.6 起默认禁止循环引用，这种环会抛 BeanCurrentlyInCreationException。讽刺的地方在于：模型完全具备这个知识，也完全可能忘——训练语料里互相注入的老教程遍地都是，采样时“最常见写法”就赢了。

为什么“单次生成”天然不可验收

两次翻车指向同一个本质：大模型的代码生成是概率采样，不是确定性推导。同一个 prompt 跑两次，输出可以不同；它命中的是语料里的高频写法，不是你生产环境里的正确写法。

所以验收要建立一条清醒的链条：编译通过 ≠ 逻辑正确 ≠ 生产可用。编译通过只证明语法合法；逻辑正确要靠用例，尤其是边界用例；生产可用还要看执行计划、并发行为和资源占用。这三层里没有一层是模型能替你完成的——它不知道你的数据量、你的索引、你们团队禁止循环依赖的规约。

有人会说，把需求写得更全不就行了。我的体会是写不全：很多验收标准是被失败逼出来的，开工时你自己也说不清“分页翻到第 98 万行还扛不扛得住”。单次生成的正确率再高，摊到几十个接口的工程上，期望错误数也不是零。验收不是对 AI 的不信任，而是把概率问题变成工程问题的唯一手段。

一键工程构建：把“确认”拆到最小单元

单次生成不可验收，正解是把“确认”这个动作切得足够细。飞算JavaAI 的一键工程构建，流程设计基本就是照这个思路来的：

按接口模块顺序逐一生成，边生成边预览，逐级确认后才继续下一级，确认完一键输出完整项目工程。体感和“一次性吐全部代码”完全不同：接口设计 Agent 先出接口定义，我确认一遍；数据库架构 Agent 出表结构，我再确认一遍；然后每个模块的代码逐个生成、逐个预览。

细粒度确认的价值在订单模块那次直接兑现：预览窗口里我一眼看到 Mapper 用的是 OFFSET 深分页，当场退回重生成，没有让它带着问题流到后面二十个文件里。多维度上下文关联在这里也起了作用——插件读得到工程里已有的实体和 Service，生成的字段名和 import 不是凭空捏造的，确认成本因此低很多。

这个机制解决的是反馈粒度问题：一次确认二十个文件，人只能粗扫；一次确认一个模块，人才能真看。问题暴露得越早，修复成本越低，这是“逐级确认”比“事后全量 review”强的根本原因。

版本快照：给“再优化”留退路

逐级确认拦得住大部分问题，拦不住全部。改到第四个模块才发现第二个模块的表设计有隐患，这种事仍然会发生。版本快照回溯就是干这个的：每个生成节点都有快照，发现走错直接回到上一个正确节点，不用手动 revert 一堆半成品文件。

我的用法是把快照当“已知良好状态”的锚点：每确认一个模块、跑通一次编译和冒烟，就定格一次。后续任何再优化改崩了，回溯锚点重来，损失只有一轮尝试的时间。没有这个兜底，人在多轮修改里容易陷入“改坏了又回不去”的赌徒心态，反而更不敢让模型动手。

单测生成：按等价类和边界值，不按覆盖率凑数

飞算JavaAI 能直接生成单元测试，但这里有个隐蔽的坑：不给验收标准，模型会交出一堆“断言恒真”的用例，行覆盖率漂亮，缺陷捕获能力约等于零。

我的做法是在指令里直接给定测试设计框架——黑盒测试的老两样：等价类划分和边界值分析。以优惠券金额校验为例，规则是金额大于 0、不超过 10000、最多两位小数。我让模型先列有效等价类和无效等价类，再按边界取值：

@ParameterizedTest
@CsvSource({
        "0,        false",   // 下边界外：无效
        "0.01,     true",    // 下边界：最小有效值
        "5000.00,  true",    // 有效等价类的中间样本
        "10000,    true",    // 上边界：本身有效
        "10000.01, false",   // 上边界外：无效
        "-1,       false",   // 无效等价类：负数
        "1.999,    false"    // 无效等价类：小数位超限
})
void validateAmount(BigDecimal amount, boolean expected) {
    assertEquals(expected, couponService.validateAmount(amount));
}

0.01、10000、10000.01 这几个点，“凑覆盖率”式生成永远不会主动给。这批用例第一轮就抓出模型自己写的校验漏掉了三位小数——生成器和验证器用同一套理论时，缺陷在两边的夹缝里最藏不住。

闭环为什么成立：把验收结果喂回采样条件

上面这些动作串起来，就是飞算JavaAI 在产品层面引导的“生成-反馈-再优化”闭环：

它为什么比“开工前把需求写全”有效？从采样角度解释很直白：模型每次输出，都是从“prompt 加上下文”共同决定的概率分布里抽出来的。第一轮的条件只有需求描述，你的隐含约束——数据量、索引、团队规约——只能靠语言命中概率去碰。

而每一次验证失败，都是高信息量的新约束。“EXPLAIN 显示全表扫描”这一行字，对采样分布的修正力度，远大于你预先写一百字“注意性能”。把报错栈、慢日志、失败用例喂回对话，等于把采样条件从“我猜你要什么”修正为“你已经证明了什么不行”。几轮下来，分布被约束得越来越窄，命中概率自然上去。

换个说法：闭环不指望模型变聪明，它让人的验收结果有了回流通道。这也是它被做成“智能引导”而不是可选技巧的原因——多数人不会自发地把失败证据组织好喂回去，产品流程替你补了这一步。

耗时对比：省掉的是打字，省不掉的是验收

拿上周一个真实模块粗算：订单列表、详情加三个管理端接口，Spring Boot 加 MyBatis-Plus。

不用 AI，我的历史均值六到七个小时：表设计和实体半小时到一小时，四层样板代码三小时上下，联调自测两小时，再摊上查文档的时间。

用飞算JavaAI 加 Kimi-K3：接口和表设计确认二十分钟，逐级生成加预览四十分钟，修两个问题（一处深分页、一处漏了租户条件）一小时，补等价类单测并跑通四十分钟。合计两个半到三小时，大约省一半。收尾时顺手让优化建议功能扫了一遍模块，又提了两处空指针防护，属于白捡。

省一半是诚实的数字。AI 吃掉的是打字和查资料的机械时间，吃不掉验收时间——验收是工作量的迁移，不是消失。真正变化的是这几小时的内容构成：从“写代码”变成“定标准、跑验证、喂反馈”。

模型档位直接影响流程的成本和上限。K3 本身是 2.8 万亿参数的 MoE，激活约 104B，百万 token 上下文配 KDA 混合线性注意力，工程上最直观的收益是整个模块的代码加完整报错栈能一次塞进对话。同一个分页需求，Kimi-K3-低配给的直接是 OFFSET 深分页，K3 没被提醒就主动用了游标写法，还附了一句索引建议。我的分界线：低配跑 CRUD 样板和日常问答，配额省、响应快；复杂查询和性能敏感的活给 K3；架构讨论切 K3.1-Pro——旗舰思考模型，始终开启推理，reasoning_effort 能按任务调。各档位配额倍率不同，具体数值以官方为准。

场景速查表

场景	选哪个模型/参数	为什么	坑在哪
单表 CRUD、四层样板代码	Kimi-K3-低配	写法固定，低配质量够用，配额省、响应快	偶漏空值判断，确认时盯参数校验
复杂查询、分页、导出	Kimi-K3	对性能约束的“语感”更好，会主动考虑执行计划	默认 LIMIT OFFSET 深分页，必须点名游标分页
架构设计、跨模块联动	Kimi-K3.1-Pro，reasoning_effort 调高	始终开启推理，长链路推导稳	思考耗时长，简单任务用它浪费配额
单元测试生成	Kimi-K3，指令写明等价类/边界值	理论框架给足，用例才打在边界上	不给标准就按覆盖率凑数，断言恒真
线上异常修复	智能会话贴完整报错栈，配控制台异常辅助修复	报错栈是信息量最高的反馈	只贴现象不贴栈，修复建议会漂移
多轮重构与再优化	任意档位，每步留版本快照	快照是已知良好状态的锚点	别等改崩才找锚点，每确认一个模块就定格