鄂奎阿先说我自己的一个判断：代码生成这个事，听起来好像是大厂才有的基建能力，但实际上只要你写过三五个重复度极高的CRUD接口，或者手工敲过上百行格式固定的配置文件，大概率都动过“自己搞一个生成器”的念头。行业里聊代码自动生成框架，其实分了两条完全不同的路线：一条是规则模板驱动，靠元数据和模板引擎机械地产出代码，典型代表就是若依这类后台管理框架里的代码生成器；另一条是AI大模型驱动，靠自然语言描述直接生成代码，或者用Agent框架做自动补全和重构。这几年聊生成式AI的人多，但真正在公司里落地跑得稳的，反而是第一类——它简单、高效、不烧token，产出的代码完全可控。这篇博客我打算把自己从零搭建代码生成框架的完整过程讲清楚，包括框架分层、自定义规则的实现、嵌入式场景下Simulink模型到C代码的生成链路，以及当前最热的AI辅助生成方向选型，给正在调研或者准备动手的读者一个可以借鉴的样本。
代码生成框架能解决什么问题，说白了就是一句话：把“重复且有规律”的脑力劳动，变成“配置加渲染”的机械劳动。比如后端接口的Controller、Service、Mapper三件套，本质上就是表结构到代码的一次映射；再比如嵌入式开发里根据Simulink模型生成C代码，核心也是把模型表达的逻辑翻译成目标语言。这些话听起来简单，但真正动手之后才会发现，难点不在“生成”这两个字，而在“框架”这两个字——怎么把变化的部分隔离出来、怎么让规则可自定义、怎么保证生成的代码能直接进CI而不是当一次性废料，这些才是决定一个生成工具是玩具还是生产力的分水岭。
1. 先把“代码生成框架”拆开看：两种路线与适用边界
1.1 规则模板型与AI生成型：各自解决什么问题
很多人搜“代码生成框架”这个词，其实想找的东西并不一样。我把市面上能见到的工具粗略分成三类，方便大家对照：
| 类型 | 代表思路 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 规则模板型 | 若依代码生成器、自研模板引擎 | 结果确定、可测试、离线运行、不烧token | 灵活度低，只能生成固定模式 | CRUD、DTO、Mapper、配置文件、测试骨架 |
| AI生成型 | 大模型代码补全、Copilot、AI代码生成工具 | 理解自然语言，通用性强 | 结果不确定、上下文受限、token成本 | 复杂逻辑编写、算法原型、SQL/正则表达式生成 |
| 混合型 | 规则定骨架 + AI填业务 + 人工审核 | 可控性和灵活性兼顾 | 架构复杂度高，需要工作流编排 | 中大型项目的代码生成平台 |
规则模板型之所以在工程界活得很好，核心原因是产出确定。你给它一张表结构信息，它出来的Controller是什么样就是什么样，版本之间的差异可以用diff工具看得清清楚楚。这对团队协作、代码Review、质量回溯都有巨大的好处。AI生成型更多被当成“结对编程助手”，适合在思路不清楚、写法不常见的时候救场，但真要把它当成框架的底层引擎，是需要很强的工程兜底能力的。
1.2 什么样的代码适合自动生成
这是我踩过坑之后才总结出来的一句话：代码生成框架适合解决“重复且有规律”的产出，不适合解决“研发逻辑本身”。适合的典型场景我列一下：
- 后端接口的CRUD层：实体类、Mapper接口、Mapper XML、Service接口、ServiceImpl、Controller。字段基本由数据表结构决定，几乎没有业务分支。
- 配置类代码：Spring的Bean配置、K8s的YAML、数据库初始化脚本、DTO/VO/Pojo转换代码。
- 客户端与服务端的数据模型：根据接口定义文档生成Swift/Kotlin/TypeScript模型类。
- 测试骨架：pytest的测试类、Java接口自动化测试框架里的用例模板。
- 嵌入式模型代码：Simulink模型生成的C代码、状态机生成的C代码。
不适合自动生成的部分，主要是业务流程状态机、算法核心逻辑、涉及多表事务的复杂操作。这些代码的表象并不由结构决定，而是由业务规则决定，规则变了代码就变，硬套模板只会让代码变成一坨没法维护的“生成物”——比手写的还难改。我见过一个团队试图用模板生成多表联查的复杂Service方法，结果模板里写了一堆条件判断和循环，比手写代码复杂三倍，最后那个模板改一次要半天，没人愿意碰。
1.3 框架分层的通用思路
不管用哪种路线，一个正经的代码生成框架，我都会按四层去设计：
- 数据接入层：负责读取元数据。后端场景直接连数据库读表结构，嵌入式场景读Simulink模型或接口描述文件，前端场景读OpenAPI/Swagger文档。
- 规则配置层：定义生成行为的全部开关和参数。哪个表生成哪几层代码、包名叫什么、类型映射规则是什么、要不要生成分页接口等，全部收敛到配置里。
- 模板渲染层：真正的“代码工厂”。用Freemarker、Jinja2或Velocity这类模板引擎，把元数据和规则配置渲染成目标代码文本。
- 输出与后处理层：负责文件落盘、目录结构创建、格式化、版权头补齐，再理想一点，直接跑一下编译或者lint检查，保证产出是能进CI的。
这四层各管各的事，互不掺和。最关键的是第二层和第三层之间的边界——规则配置文件里只写字面参数，模板里只写渲染逻辑，两者通过一个统一的上下文对象交互。我之前见过有人把业务逻辑直接写在模板里，那个模板后来没人能改得动，等于废了。实际上很多自研的代码生成器最终变成“一次性工具”，就是因为没守住这个边界，把变化和不变的东西揉在一起，后面想扩展就只能推翻重来。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。