代码自动生成框架实战：从大模型到可落地的工程化流水线

去年开始，我就在团队里折腾各种“代码自动生成”的落地方式。最开始的想法很简单，让AI写代码嘛，大家都会，接个大模型API，写几句提示词，让它生成个函数、补个单元测试，demo跑得飞起。但真正推到一个中型项目、多人协作的环境里，问题马上就来了：生成的代码风格不统一、经常用一些莫名其妙的API、没法做自动化校验，更别说接进CI流程里做增量检查了。折腾了几个月，踩了不少坑，最后沉淀出来的经验就是——光有模型远远不够，你需要一个能把“理解需求—检索上下文—生成代码—校验修正—输出产物”串起来的代码自动生成框架。

这篇文章不聊那些PPT层面的概念，直接讲清楚一个能落地的代码自动生成框架到底应该怎么搭。我会把自己在这套框架设计上的思路、每个模块怎么选型、关键代码怎么写、实际运行起来遇到过哪些幺蛾子，全部整理出来。如果你也准备在团队里引入AI辅助编码，或者想把现有的编码流程做成半自动甚至全自动，这篇内容应该能帮你少走不少弯路。

1. 为什么需要一个“框架”，而不是直接调大模型

先说个颠覆很多人直觉的结论：直接用大模型API写代码，在小范围试用的时候很爽，但一旦要稳定地产出可合并的代码，问题就全部暴露了。

1.1 直接调API的痛点

我之前试过几种方式。最简单的是在IDE里装个插件，选中一段代码，让它重写或者补全，这个对单个函数的帮助确实有，但很难保证全局一致性。比如它会自己发明一个错误的方法名，或者为了满足你的注释要求，把函数参数强行改了，连带调用方的代码却不知道要不要同步改，编译过不了。

更麻烦的是上下文问题。比如你让大模型生成一个订单状态流转的工具类，它不了解你们项目里已经存在的状态枚举、底层存储抽象、异常处理规范，它生成的代码可能逻辑上没错，但和你现有的工程体系完全割裂。你给它的上下文太少，它就靠常识猜；给多了，又超过模型上下文窗口，根本塞不进去。

还有个致命问题——不可重复。同一个需求，模型每次生成的代码都不一样，这在有代码评审和规范审查的团队里非常致命。你没法跟评审说“这次生成的代码和上次稍微不一样，但也能跑”，对于一致性要求高的场景（比如对外API、数据模型定义），这不是能商量的空间。

1.2 用“框架思维”解决工程问题

后来我意识到，核心矛盾不是模型不够聪明，而是缺少一层工程化约束。大模型本身是概率输出，但工程上需要的是稳定产物。问题的解法就是：中间加一个框架，让模型在给定的边界内生成内容，并且对输出做自动校验和修正。

这个思路其实跟传统代码生成器一脉相承。以前我们用模板引擎（比如Jinja2、MyBatis Generator）生成代码，预先把结构定死，改变的是数据；现在换成大模型，模板不再只有静态结构，而是变成了“提示词模板+动态上下文+校验规则”的组合，灵活性更高，但同样需要框架来做流程编排。

所以我理解的代码自动生成框架，本质上是一套流程系统：它把需求输入、上下文准备、模型调用、输出校验、错误修正这五个环节固化下来，让每一次代码生成不再是一次“碰运气”，而是一次可控的流水线作业。从这个角度看，这套框架与某个具体的大模型厂商完全解耦，也不绑定某种IDE，它是一个独立于开发流程之外的代码生产工具链。

1.3 什么样的团队适合用框架

如果你的团队有下面任一特征，我比较推荐花时间搭一套自己的框架：

• 项目代码量大，但存在大量样板化代码（比如CRUD接口、数据模型、DTO互换、单元测试）
• 团队对代码规范有硬性要求，需要自动生成的代码跟手写代码风格一致
• 有稳定的大模型API预算，希望把它从“有趣的尝试”变成“每天都要用的生产力工具”
• 项目里已经建立了良好的编译、静态检查、单测机制，可以让框架自动调用这些工具来做校验反馈

如果只是偶尔让AI写个脚本，那确实不需要折腾框架。但如果你指望它在生产环境持续产出代码，框架这层东西迟早要补上。

2. 代码自动生成框架的整体设计

这一节是全文的核心。我把自己在框架设计上的模块划分讲清楚，包含每个模块的作用和设计思路。整个框架我按照流水线的方式组织，一共分五个核心模块：任务解析、上下文采集、生成引擎、校验修正、产物输出。

2.1 模块总览：五段式流水线

我最开始设计的版本没有这么清晰，是随着迭代慢慢拆成这个结构的。

2.2 关键是“任务解析”，不是直接丢需求

很多人做代码生成框架的时候，第一步就把需求原文直接扔给模型，这是很偷懒的做法，效果也不好。真实开发的需求往往是模糊的，比如一句话需求“给用户模块加一个列表接口”，这里面缺了太多信息：是按什么字段筛选？分页怎么做？返回给前端的结构是啥？权限要求是什么？

所以在生成代码之前，必须先有一个任务解析步骤。这一步本质上是在做需求澄清，它可以由人来做，也可以由模型来做。实操中我是两层结合：用户先用一个结构化的表单填写需求要素，框架再调用模型补全缺失的细节。

我之前设计过一套简单的任务描述模板，大致长这样：

json复制{
  "task": "generate_crud_api",
  "target_module": "order",
  "fields": [
    { "name": "id", "type": "string", "primary_key": true },
    { "name": "status", "type": "int", "default": "0" },
    { "name": "amount", "type": "decimal", "note": "订单金额" }
  ],
  "framework": "springboot",
  "api_version": "v1",
  "constraints": [
    "所有对外返回字段必须使用VO对象，不直接返回Entity",
    "分页参数标准为page和size，默认page=1, size=20",
    "状态变更需要写操作日志"
  ]
}

框架拿到这个结构化任务之后，再结合项目上下文生成代码，会比直接往提示词里塞一句话可靠得多。任务解析的本质是把开放问题变成闭合问题，让生成过程有边界。

2.3 上下文采集：决定代码质量的隐形天花板

上下文采集是我在这套框架里花时间最多的模块。它的目的就是解决我前面说的“模型不了解项目现状”的问题。

实操下来，上下文采集要考虑三个层面：

• 工程结构上下文：项目用的框架（Spring