1. 为什么需要一套模板代码生成工具
干这行久了，你迟早会碰到一个让人抓狂的场景：新项目开荒，先建目录结构、配编译脚本、写日志组件、接数据库连接池、再补一堆重复的 CRUD 接口。这一套流程走下来，熟练工也要小半天，而且每个项目之间差异不大，纯粹是体力活。还有更头疼的，团队里每个人建出来的目录习惯不一样，有人叫util，有人叫utils，有人把配置放在根目录，有人塞进config子目录。等到人员流动、项目交接时，光熟悉这些"个性十足"的代码结构就够喝一壶的。
模板代码生成工具要解决的就是这类问题。它会根据你预先定义好的模板和配置参数，自动生成一整套符合规范的项目骨架、业务模块、数据访问层代码。说白了，就是把"复制粘贴然后改名字"这种手工活自动化，并且让它稳定、可重复、不依赖某个人的个人习惯。
这个工具适合谁来用？如果你是一个需要经常起新项目的后端工程师，或者你在带一个多人的研发团队，又或者你维护着多条业务线、需要频繁创建相似的服务和接口，那这套东西几乎是刚需。前端同学同样适用，组件库脚手架的生成、页面模板的初始化，思路完全通用。
我最初动手写这套工具，是因为某段时间公司内部要批量搭建十几个业务子系统，每个系统的基础代码一模一样，但手工创建总会出各种幺蛾子——漏了统一的异常处理，配置文件里写错了数据库地址，还有人把依赖版本升得乱七八糟。后来我把整个初始化流程固化到生成器里，新系统五分钟出一个能跑的骨架，稳定性明显上来了。
需要先说明一点，现在市面上有不少现成的脚手架工具，比如各大框架自带的 CLI，用起来也很方便。但通用脚手架的问题是它们只能生成"标准"结构，很难内化你自己团队的工程规范、代码风格和内部公共库依赖。这就是自定义模板代码生成工具的价值所在，它把"团队规范"直接写进了生成逻辑里，从源头上保证一致性。
2. 整体架构拆解：生成器的三个核心部件
任何模板代码生成工具，无论实现语言是哪一种，本质上都由三个核心部件组成：模板库、配置模型、渲染引擎。理解这三者的分工，你就能明白这类工具的设计精髓。
2.1 模板库：代码的"母版"
模板库是所有要生成文件的母版。它不是普通的源码文件，而是在普通源码里嵌入了占位符变量、循环块和条件判断的特殊文件。举个例子，一个标准的 Java 类模板大概长这样：
package ${packageName}.entity; import lombok.Data; /** * ${classComment} */ @Data public class ${entityName} { #foreach ($field in $fields) private ${field.type} ${field.name}; #end }这里面的${packageName}、${entityName}是变量占位符，会在渲染时替换成真实值；#foreach是循环控制块，用来根据字段列表批量生成成员变量。模板库的设计重点在于覆盖率和抽象层级：覆盖率是指你的模板能覆盖多少常见代码形态，抽象层级是指你控制"变与不变"的边界在哪里。
我习惯把模板分成三类：一类是固定模板，整个项目完全一样，比如主启动类、统一异常处理器，这类模板里几乎不需要变量；一类是半固定模板，大框架是定的，但包名、类名、依赖项会变化；还有一类是动态模板，根据配置输入生成不同内容和数量的文件，比如每个实体对应一套 Controller、Service、Mapper。
2.2 配置模型：参数从哪里来
配置模型解决的是"每次生成时，哪些信息因人而异"的问题。这些差异信息可以来自用户在命令行输入的方式，也可以来自一个配置文件，甚至可以来自界面表单。
我第一次实现时用的是简单的方式：读取一个config.yaml，里面写清楚这次要生成的项目基本信息：
project: name: user-service package: com.example.user port: 8080 features: orm: mybatis-plus cache: redis logging: log4j2 entities: - name: User comment: 用户实体 fields: - name: id type: Long comment: 主键 - name: userName type: String comment: 登录名 - name: email type: String comment: 邮箱配置模型的设计要把握好两个度：一是别太复杂，配置文件本身变成一门晦涩的方言，学习成本远高于手写代码，那就本末倒置了；二是别太简单，如果只能传项目名和包名，生成出来的东西没多大用。合理的做法是把"团队里每开一个项目必填的信息"定义为配置项，其余全部走模板默认值。
2.3 渲染引擎：把模板变成真实代码
渲染引擎是生成器的发动机。它会读取模板文件，解析其中的语法标记，将配置模型里的数据填充进去，最终输出真实的源码文件。
渲染引擎有两个关键选择要做：一是选一个成熟的模板引擎库，还是自己写解析器；二是输出过程怎么组织，比如目录结构怎么映射、已存在文件如何处理。
我强烈建议直接使用成熟的模板引擎，比如 Java 生态里有 FreeMarker、Velocity，Python 生态里有 Jinja2，JavaScript 生态里有 Handlebars、EJS。自己写解析器纯粹是找罪受，除非你有极其特殊的语法需求，否则模板引擎成熟的功能——变量插值、循环、条件判断、宏定义、模板继承——已经覆盖了绝大部分场景。
渲染引擎另一个容易被忽略的职责是文件系统操作。模板源文件在templates/目录下，目标项目输出到output/目录，中间需要一个映射机制：模板文件的相对路径经过变量替换，变成目标文件的相对路径和文件名。比如模板里有一个文件叫[[entityName]]Controller.java，配置里实体名叫User，那渲染时就会生成UserController.java。路径里的变量替换是新手最常踩坑的地方，后面我会详细讲。
有了这三个部件的骨架，你再去审视任何一套代码生成工具，都能一眼看穿它的设计思路，也能更容易定位问题出在哪里。
3. 实操：用 Python + Jinja2 从零构建生成器
理论说完，直接上代码。我选了 Python 和 Jinja2 作为实现组合，原因是 Python 语法简洁、跨平台部署方便，Jinja2 的功能对代码生成场景支持得非常充分——模板继承、宏定义、过滤器一应俱全。这套组合我之前在团队内部用了两三年，稳定可靠，你完全可以照着搭。
3.1 项目结构规划
codegen/ ├── main.py # 入口，读取配置，调用生成流程 ├── config/ │ ├── project.yaml # 项目级配置 │ └── templates.yaml # 模板清单控制文件 ├── templates/ # 模板目录 │ ├── common/ # 固定内容模板 │ │ ├── Application.java.j2 │ │ ├── ErrorHandler.java.j2 │ │ └── logback.xml.j2 │ ├── entity/ # 实体相关模板 │ │ ├── Entity.java.j2 │ │ ├── Controller.java.j2 │ │ ├── Service.java.j2 │ │ ├── ServiceImpl.java.j2 │ │ └── Mapper.java.j2 │ └── resource/ # 资源文件模板 │ └── application.yml.j2 └── generator/ ├── __init__.py ├── loader.py # 加载模板清单 ├── renderer.py # 渲染核心逻辑 └── writer.py # 文件输出模块注意到模板文件的命名。我故意给所有模板文件名加了.j2后缀，这是一个很实用的小习惯：它能让你一眼区分"模板文件"和"正常源码文件"，因为在开发工具时你经常需要同时打开模板目录和输出目录，没有后缀区分很容易搞混。另外，编辑器也会根据.j2后缀启用 Jinja2 语法高亮。
3.2 核心渲染逻辑的实现
先来看renderer.py，这是整个工具的心脏：
import os from pathlib import Path from jinja2 import Environment, FileSystemLoader, StrictUndefined class Renderer: def __init__(self, templates_dir: str): self.env = Environment( loader=FileSystemLoader(templates_dir), undefined=StrictUndefined, keep_trailing_newline=True, trim_blocks=True, lstrip_blocks=True, ) # 注册自定义过滤器 self.env.filters['lower_first'] = lambda s: s[:1].lower() + s[1:] if s else s self.env.filters['upper_first'] = lambda s: s[:1].upper() + s[1:] if s else s self.env.filters['camel_case'] = self.to_camel_case @staticmethod def to_camel_case(value: str) -> str: parts = value.replace('-', '_').split('_') return parts[0] + ''.join(p.title() for p in parts[1:]) def render_file(self, template_rel_path: str, target_rel_path: str, context: dict) -> str: template = self.env.get_template(template_rel_path) content = template.render(**context) return content这段代码里有几个细节值得展开说。
StrictUndefined是 Jinja2 的一种严格模式，它会在模板中引用了未定义的变量时直接抛出异常，而不是默默渲染成空字符串。这个特性对代码生成工具太重要了。我在早期的工具里没开严格模式，结果配置里少写了一个字段时，生成的代码里莫名出现一片空白，排查老半天才发现是一个拼错的占位符。开启严格模式后，问题会在第一次渲染时就暴露，直接告诉你哪个变量没有定义，省心太多。
keep_trailing_newline保持文件末尾的换行符，这样生成的源码文件符合常规规范，不会因为模板渲染而丢失最后的换行，避免某些检查工具报警。trim_blocks和lstrip_blocks则是为了让模板写入时能自由控制缩进，控制块标签本身不会残留多余的空行和缩进。
自定义过滤器解决了命名风格转换的痛点。数据库字段是下划线风格user_name，Java 属性要驼峰userName，类名要首字母大写UserName，控制器变量反而要首字母小写userService。这些转换如果每次都在模板里一个个写，既啰嗦又容易出错，做成过滤器之后在模板里一行搞定：``。
3.3 模板清单与输出路径映射
模板文件怎么映射到目标路径？我建议不要直接在代码里硬编码映射表，而是用单独的templates.yaml来维护。这个文件的本质是"生成规则"，里面定义了哪个模板生成到哪个路径：
templates: - source: common/Application.java.j2 target: '{{ project.package_path }}/{{ project.name }}Application.java' - source: common/ErrorHandler.java.j2 target: '{{ project.package_path }}/exception/GlobalExceptionHandler.java' - source: resource/application.yml.j2 target: 'src/main/resources/application.yml' - source: entity/Entity.java.j2 target: '{{ project.package_path }}/entity/{{ entity.name }}.java' loop: entities - source: entity/Controller.java.j2 target: '{{ project.package_path }}/controller/{{ entity.name }}Controller.java' loop: entities - source: entity/Service.java.j2 target: '{{ project.package_path }}/service/{{ entity.name }}Service.java' loop: entities注意loop: entities这个字段，它标识了这个模板要为配置里的每个实体各生成一份。渲染引擎在读取到loop字段时，会遍历配置里的实体列表，为每个实体渲染一份代码，并且渲染时的上下文自动切到"当前实体 + 项目全局信息"。
target里出现了{{ project.package_path }}，在 Java 项目里包路径就是包名转目录形式，比如com.example.user变成com/example/user。这个路径本身也是一个变量，在入口程序里先解析一次：
def build_target(template_spec, context): target = render_template_string(template_spec['target'], context) # 二次处理：路径变量替换，确保目录名规范 target = target.replace('{{ project.package }}', context['project']['package'].replace('.', '/')) return target实际实现中，我更倾向把package_path预先计算好放进上下文，而不是在模板字符串里用嵌套表达式去处理。这样目标路径模板的写法更简洁，可读性更高。还有一点，templates.yaml里所有target都是相对路径，最终输出时会自动拼上输出根目录。这样你可以随时改输出目录，而不需要动任何映射配置。
3.4 入口程序串联整体流程
main.py是整个工具的调度中心：
import argparse import sys from pathlib import Path import yaml from generator.renderer import Renderer from generator.writer import Writer def load_config(config_path: str): with open(config_path, 'r', encoding='utf-8') as f: return yaml.safe_load(f) def build_context(project_config: dict) -> dict: ctx = dict(project_config) ctx['project'] = project_config['project'] ctx['package_path'] = ctx['project']['package'].replace('.', '/') return ctx def main(): parser = argparse.ArgumentParser(description='模板代码生成工具') parser.add_argument('--config', '-c', default='config/project.yaml', help='项目配置文件路径') parser.add_argument('--output', '-o', default='output', help='输出目录') parser.add_argument('--overwrite', '-f', action='store_true', help='覆盖已存在文件') args = parser.parse_args() project_config = load_config(args.config) context = build_context(project_config) templates_spec = load_config('config/templates.yaml') renderer = Renderer('templates') writer = Writer(output_dir=args.output, overwrite=args.overwrite) for template_spec in templates_spec['templates']: if 'loop' in template_spec: loop_list = context.get(template_spec['loop'], []) for item in loop_list: item_context = dict(context) item_context['entity'] = item target = renderer.render_template_string(template_spec['target'], item_context) content = renderer.render_file(template_spec['source'], target, item_context) writer.write_file(target, content) else: target = renderer.render_template_string(template_spec['target'], context) content = renderer.render_file(template_spec['source'], target, context) writer.write_file(target, content) print(f"代码生成完成，输出目录: {args.output}") if __name__ == '__main__': main()这里有个设计决策值得说说。为什么我把"上下文"设计成每个文件渲染时临时构建，而不是全局共享同一个巨型 dict？因为代码生成过程中，不同文件的上下文差异很大。实体类需要字段列表，项目启动类只需要包名和项目名，如果全局共用一个 dict，模板里的变量引用会变得很混乱，无法保证"每个模板只拿自己需要的变量"。临时构建的方式保证了模板变量的可见性和职责边界，生成结果的稳定性和可预测性就好很多。
Writer模块要处理的事情比较杂，核心是目录创建、文件写入、冲突处理三个功能：
import os from pathlib import Path class Writer: def __init__(self, output_dir: str, overwrite: bool = False): self.output_dir = Path(output_dir) self.overwrite = overwrite self.generated_files = [] def write_file(self, relative_path: str, content: str): target_path = self.output_dir / relative_path target_path.parent.mkdir(parents=True, exist_ok=True) if target_path.exists() and not self.overwrite: raise FileExistsError(f"文件已存在，跳过写入: {target_path}") target_path.write_text(content, encoding='utf-8') self.generated_files.append(str(target_path))写文件时用utf-8编码而不是默认编码，这在 Windows 环境下尤其重要，否则生成的源码文件打开就是乱码。文件写入后我会记录一个列表，方便后续脚本统计本次生成了多少文件、覆盖了多少文件，这也为后期接 CI 流程做代码生成校验打了基础。
4. 模板设计的进阶技巧：一次写好，长久复用
模板是生成工具的核心资产，模板写得好不好，直接决定工具能复用多久、团队买不买账。这里分享几条我积攒下来的经验。
4.1 用模板继承消除重复片段
代码生成场景里的大量重复不是出现在"文件之间"，而是出现在"文件内部"。每个 Controller 几乎都有同样的接口响应包装逻辑、同样的参数校验方式，每个 Service 接口都有同样的注解声明。如果这些内容在每一个模板文件里都复制一份，后续想调整响应格式时就得改几十个模板，痛苦程度不亚于手工改代码。
Jinja2 的模板继承机制可以很好地解决这个问题。你可以把公共结构抽到基础模板里，再让具体模板填空。比如定义一个PageResult.java.j2作为所有分页返回结构的基类，各业务模块的分页类都继承它：
{% extends 'common/BasePageResult.java.j2' %} {% block class_annotation %} @ApiModel(description = "{{ entity.comment }}分页查询结果") {% endblock %}更轻量的做法是使用宏（macro）。宏类似于函数，把可复用的代码片段定义一次，然后在任意模板里调用。我常把序列化注解、日志打印语句、接口响应包装这些片段写成宏：
{% macro response_wrapper(method, return_type, body) %} @Override public Result<{{ return_type }}> {{ method.name }}() { {{ method.log_statement }} return Result.success({{ body }}); } {% endmacro %}模板继承和宏的选择标准：如果一个"公共部分"横跨多个文件，用继承；如果一个"公共片段"出现在单个文件内部多处，用宏。两者配合使用，模板的维护成本能大幅下降。
4.2 命名约定与大小写转换
代码生成工具最容易翻车的地方就是命名规范。业务上有下划线风格、驼峰风格、短横线风格、大写下划线风格，模板引擎通常只能做简单的字符串替换，但真实需求往往是"同一个名字的不同变体"。
我的做法是在上下文中为每个核心命名对象预先计算全部变体，而不是依赖模板里的过滤器链。比如配置里定义了一个实体叫order_detail，我会在加载上下文时把它展开成：
entity: name: order_detail camel: orderDetail pascal: OrderDetail constant: ORDER_DETAIL这样一来，模板里直接写{{ entity.pascal }}而不是{{ entity.name | title | replace("_", "") }}这种长串表达式。可读性大幅提升，也避免了因为过滤器使用不当导致的边界问题，比如order_detail变成Order_Detail而不是OrderDetail。
这个"变体预计算"的思路不仅适用于实体名，也适用于项目名、服务名、数据库表名。统一约定"配置源名称统一用小写下划线"，剩下的变体在上下文中自动计算好，每个模板都从上下文取，不会出现两个人各写一套转换逻辑、产出不同代码的场面。
4.3 模板调试技巧：白盒输出
模板渲染出错时，最大的痛苦是根本不知道渲染出来的中间态长什么样。Jinja2 的报错信息虽然会指向模板文件和行号，但如果你嵌套了好几层模板继承，报错位置和真实问题往往隔着十万八千里。
我用的一个有效手段是"白盒输出"调试模式。在 Renderer 里加一个环境变量开关，开启后会在输出每个文件的同时，导出一份"渲染上下文快照"，也就是这个文件渲染时用到的所有变量以及它们的值，格式可以是 JSON。这样如果生成的代码结果不对，你可以直接看快照，判断是上下文里值不对，还是模板逻辑有问题。
比如某个 Controller 生成的@RequestMapping路径少了前缀，如果快照里entity.uri_prefix是空字符串，说明配置数据没传对；如果快照里是有值的，那就是模板里没引用对变量。一步就定位问题，不用反复改配置再重新生成来猜测。
4.4 为模板写测试用例
代码生成工具的模板也是代码，也需要测试。我见过不少团队花大力气搭了生成器，但模板从没做过自动化测试，结果某天公共依赖升级，生成出来的全部代码编译不过，才被迫加班排查。
一个现实的方案是维护一组"黄金样例"：在仓库里放几个典型的项目配置（比如带三个实体的完整项目、以及一个最小只生成基础骨架的项目），在 CI 里跑生成器，把输出与预期目录结构做对比。不必逐个字节比对，核心是检查关键文件是否存在、关键类名是否匹配、能否通过编译。这一步守住，模板的回归风险就基本可控了。
5. 实战案例：生成一套完整的微服务工程骨架
理论环节到这里，我拿一个实际案例完整走一遍，让你看看整套工具在真实项目里是什么效果。
假设现在团队要接一个用户管理服务，实体包括用户、角色两个，需要基础的 REST 接口、数据库访问层、缓存配置、日志配置。我在项目配置文件里这样写：
project: name: user-service package: com.example.user description: 用户管理微服务 port: 8080 entities: - name: user comment: 用户 uri: /api/v1/users fields: - name: id type: Long comment: 主键 - name: username type: String comment: 用户名 - name: email type: String comment: 邮箱 - name: status type: Integer comment: 状态 - name: role comment: 角色 uri: /api/v1/roles fields: - name: id type: Long comment: 主键 - name: role_code type: String comment: 角色编码 - name: role_name type: String comment: 角色名称 - name: description type: String comment: 角色描述执行生成命令：
python main.py --config config/project.yaml --output ./generated生成的目录结构大致如下：
generated/ ├── pom.xml └── src/main/ ├── java/com/example/user/ │ ├── UserServiceApplication.java │ ├── config/MybatisPlusConfig.java │ ├── controller/UserController.java │ ├── controller/RoleController.java │ ├── entity/UserEntity.java │ ├── entity/RoleEntity.java │ ├── mapper/UserMapper.java │ ├── mapper/RoleMapper.java │ ├── service/UserService.java │ ├── service/Impl/UserServiceImpl.java │ └── exception/GlobalExceptionHandler.java └── resources/ ├── application.yml ├── logback.xml └── mapper/UserMapper.xml整个生成过程在本地实测大概是几秒钟。同一个配置再生成一次，得到的结果完全一致，这就能保证团队成员之间的环境是平等的，不会因为某人的手工初始化遗漏个别文件而出问题。
如果你在一个项目里要创建多个结构一致的子系统，这种方式的效率优势更明显。原来每个子系统从前到后初始化要一整天，现在十分钟跑完配置加生成，剩下的时间集中精力做业务逻辑，投入产出比肉眼可见地好。
6. 常见问题排查与经验总结
工具用久了，各种坑也踩了个遍，挑几个最典型的说说，希望你能少走弯路。
6.1 模板文件编码问题
有一个很隐蔽的坑：模板文件如果用不同编码保存，在不同操作系统上生成的代码会出现乱码。尤其是中文注释和中文实体描述，在 Windows 上如果不注意，生成的 Java 文件注释全变问号。解决办法有两个：一是模板文件保存时统一用 UTF-8，二是写文件时强制指定 UTF-8 编码。我两个措施都做了，彻底绝了这个隐患。
6.2 路径分隔符的跨平台差异
模板里的路径，比如target: '{{ project.package_path }}/{{ entity.name }}Controller.java'，在 Windows 和 Linux 下的语义是有区别的。Python 的Path类会帮你自动处理分隔符，但如果你用了字符串拼接就很容易踩坑。我曾经因为在一个路径映射里手动拼接了\\，导致工具在 Linux 上生成了一堆带反斜杠的目录名，代码全部编译不过。现在所有路径操作都经过Path类，不再使用字符串拼接。
6.3 已存在文件的覆盖策略
生成工具跑第二次时，如果目标目录里已经存在同名文件，是覆盖还是跳过？不同场景需求不同：新项目初始化，希望无脑覆盖；在已有项目里局部生成某个模块，就不能动别人正在改的文件。我的做法是默认冲突时报错并退出，由调用方显式添加--overwrite参数才允许覆盖。这样避免了误操作，也保留了灵活性。
6.4 模板本身的可读性维护
模板文件写多了以后，最容易出现的问题是模板的可读性迅速劣化：长条件嵌套、复杂宏调用、多层继承，看模板的人已经很难判断最终生成的代码长什么样。我的应对策略是把"模板直接能生成的可运行代码"与"模板本身"放在一起，在仓库里保留一个examples/目录，里面放着某个典型配置生成出来的完整目标工程。新成员借鉴模板时，先看examples里的输出结果，再反过来理解模板的写法，上手速度会快很多。
这个做法也带来一个额外好处：当你修改了模板想确认没有破坏现有逻辑时，直接跑一次生成，对比examples目录的差异，就能清楚地看到模板修改前后对生成结果的影响，比盯着模板本身的 diff 要直观得多。
6.5 变量的作用域与命名冲突
上下文里的变量越多，越容易互相覆盖。比如实体列表里有一个字段叫name，而项目配置里也有一个project.name，如果上下文中把name暴露成了顶层变量，模板里写{{ name }}就不知道引用的是谁了。我的习惯是上下文严格分层：项目级变量都在project下，实体级变量都在entity下，公共配置在config下，禁止出现无命名空间的顶层碎片变量。不要为了省几个字符而放弃命名空间，后期排查问题的成本远超这点键盘输入。
6.6 生成结果的可编译性校验
模板写了再久，也难免出现生成的代码编译不过的情况。我在 CI 里加了一个步骤：跑完代码生成后自动用 Maven 或 Gradle 编译生成的项目，编译失败就直接把构建标红。这个步骤看起来笨重，但实际效果非常好，能拦截掉绝大多数模板回归问题，比如依赖项配置错误、类引用缺失、包名拼写不一致等。刚引入时每周都要修两三个模板问题，后来模板稳定了，这个校验就很少触发，但依然留着作为最后一道防线。
7. 工具能力的进一步扩展
基础版本能干活了，如果时间允许，你可以顺着下面几个方向继续扩展，让工具变得更顺手。
一是接入交互式引导。现在的版本是手工编辑 YAML 配置，对不熟悉配置格式的同事来说有门槛。可以加一个交互式提示，逐个询问项目名、包名、需要的功能模块，自动生成配置再执行渲染。这个改造前排产物体验的提升非常明显，新人不用看文档也能跑通第一个生成流程。
二是插件化模板市场。在团队内部，不同业务线有自己特有的代码模板。可以把模板按业务线组织成插件包，生成器在加载模板时合并多个来源。这样公共模板统一维护，业务线模板各自演进，互不影响。
三是增量生成能力。现在工具面向的是"从零创建"，但实际开发中经常需要在已有项目里新增一个实体，只生成这个实体对应的那一组文件，而不碰其他文件。这个能力需要生成器记录上次生成的文件清单，并在新一次生成时做差异计算。我目前就是在项目里维护一个.codegen-manifest文件来记录文件映射关系，实现增量更新已有二十多个实体的大项目，运行一次新增实体只花不到半秒，非常实用。
四是对接团队规范校验。生成出来的代码只是第一步，更理想的状态是生成时就把代码规范内嵌进去，比如模板里直接带上统一的注释头、统一的 import 顺序、统一的异常处理。这样新项目从一开始就站在团队规范的高起点上，而不是生成完之后还要靠 Code Review 挨个挑毛病。
模板代码生成工具的本质，不是为代码而代码，而是把团队的经验、规范和最佳实践沉淀成可复制、可演进的结构化资产。我自己从一个项目一个项目地手工复制粘贴，到后来维护一套覆盖几万人使用的公共模板库，最大的感受是：工具投入的时间，最终都会以十倍以上的效率回报在工作流的每一处。如果你也在被重复初始化折腾，不妨从最小的模板开始，逐步积累成自己团队的发电机。
