最近我在团队里做了一件“很复古”的事把一批高频重复的代码全部收编到一个模板代码生成工具里。同事问我说现在都有AI代码生成了你还折腾这个干嘛但实际上真的把两者放在生产环境下对比过一轮之后我发现模板代码生成工具有一个朴实又难替代的优势它简单、高效、而且完全不烧token。所谓“token”如果你用过基于大模型的代码工具应该不陌生Prompt一长、对话一多费用和响应时间都上来了而模板生成是本地跑一个渲染引擎毫秒级出结果规则写死之后生成的代码和你预想的永远一字不差。这篇文章想把从原理到落地、再到踩坑的完整经验整理出来。内容覆盖模板字符串的基本结构、自定义规则引擎的处理链路、一份可以直接抄走的Python实现以及PLC代码生成、Simulink模型自动生成C代码、前端页面骨架、WPF自定义模板、Word批量填充这些真实场景里的用法。适合经常写重复CRUD、接口、配置、点位程序的开发者也适合想给团队统一代码风格的人参考。1. 为什么在AI代码生成时代我还要回头啃模板代码生成工具1.1 被Token账单和不确定输出“逼”回老路先说个真实经历。年初我做项目的时候需要给几十个业务接口批量生成DTO、VO、Mapper和Service骨架。当时图省事直接用大模型对话生成。前几个接口效果确实惊艳语言风格、命名习惯都很像样。但用到第20个接口的时候问题来了每次对话都要把接口描述、字段清单、项目代码规范重新粘贴一遍这几千字的Prompt每次都严格计入token消耗一轮下来成本肉眼可见地在涨更要命的是同一个接口需求我上午下午各问一次输出的字段顺序和注释风格可能都不一样。后来我索性把历史上所有“AI写得不错”的片段收集起来抽掉具体业务数据发现剩下的结构大致相同类名占位、字段占位、注释占位、一组固定的注解和继承关系。那一刻我意识到这类代码其实早就有更合适的生产工具就是模板代码生成工具。它不依赖模型推理也就没有token成本规则一旦定义清楚输出结果就是确定性的。对于这类“结构固定、只是数据不同”的工作AI属于杀鸡用牛刀而且是一把偶尔会抖的牛刀。1.2 模板代码生成与AI生成的本质差异确定性、成本、可维护性我把两种方案放在一起做了个对比专业一点的维度如下对比维度基于大模型的代码生成模板代码生成工具单次生成成本按token计费Prompt越长越贵本地渲染几乎为零输出确定性同需求多次结果可能不一致同一版本规则输出永远一致可审查性需要人工确认逻辑是否正确生成逻辑写在模板里可以逐行Review维护方式靠微调或改Prompt行为不可控改模板和规则文件改完即生效离线可用多数需要联网调用API完全本地运行无网络依赖对使用者要求会用自然语言描述需求看得懂模板语法和数据结构即可这个表很清楚模板生成不是替代AI而是在“结构已知、变化有限”的战场里用最小的成本拿到最大的确定性。很多刚入行的朋友容易陷入一个误区——什么代码都想让AI写。实际做工程讲究的是投入产出比。类似的代码结构如果用模板10秒能出10个文件何必花几毛钱和一个小时的来回核对去等AI输出1.3 边界感很重要模板生成工具擅长什么、不该碰什么用了大半年之后我总结出一个边界清单。模板代码生成工具最擅长的是CRUD接口层代码、DTO/VO/Entity数据类、配置文件YAML、JSON、XML、建表SQL、PLC点位映射、重复度极高的页面表格与表单、测试用例骨架。这些工作有共同特征结构稳定变化的是业务参数产出结果需要和团队规范完全一致批量生成价值远大于单次手写。不适合模板生成的是复杂算法、需求本身不清晰的功能、高度依赖上下文语义的UI细节调整、以及需要跨模块推理的代码。这些地方AI或者人肉介入反而更快。意识到这个边界之后我的工作流变成了90%的重复骨架用模板工具批量产出剩下10%的差异化逻辑再交给AI或手写。这个比例带来的效率提升非常明显。2. 模板代码生成工具的运行原理模板字符串、占位符与自定义规则引擎2.1 最小可见的“模板字符串”长什么样要说清楚模板代码生成工具得从模板字符串说起。所谓模板字符串就是一个带有占位符的文本骨架。比如我想生成一个Java的DTO类最简单的模板可以长这样public class {{ className }}DTO { private {{ fieldType }} {{ fieldName }}; public {{ fieldType }} get{{ FieldName }}() { return {{ fieldName }}; } }其中{{ className }}、{{ fieldType }}、{{ fieldName }}这些就是占位符。渲染引擎拿到一个数据字典比如{className: User, fieldType: String, fieldName: name, FieldName: Name}逐项替换进去最终就会得到一段完整的Java代码。这个逻辑具体到代码里可以拆成三步把模板当普通文本读取用正则或解析器找到所有占位符再到数据字典里取对应的值填回去。听起来简单但就是这最简单的占位符替换构成了所有代码生成工具的地基。那些看起来高级的代码生成器本质上就是在占位符之上又叠加了循环、条件、文件输出、规则映射这些零件。2.2 一条代码从模板到成品的流水线我理解模板代码生成工具喜欢把它拆成一条流水线来看输入数据通常是一份JSON或YAML文件描述“要生成什么”。比如要生成用户模块的代码数据文件里就会写清楚类名、字段列表、类型映射。模板文件定义输出长什么样。模板里包含静态文本如固定注释、注解、框架调用和动态占位符如类名、字段名。规则配置负责做数据到模板之间的“翻译”。比如数据库里的varchar类型在Java里对应String在Python里对应str这条映射关系就存在规则配置里。渲染引擎把数据按规则填进模板输出最终文件内容。文件落盘把渲染结果写入指定路径批量循环时就生成多个文件。打个生活化的比方模板是一张空白的简历表数据是你自己的具体经历规则配置是填表说明——比如“工作年限按周年计算不足一年填1”。简历表决定了最终版本布局填表说明决定了数据的口径而你的经历只是内容。模板、规则和数据各司其职谁改起来都互不干扰。2.3 自定义规则为什么是灵魂很多代码生成工具“不好用”一个核心原因是把规则写死在程序代码里了。比如我在早期项目里见过一个生成器类型映射全部硬编码在Java类里数据库里加了一个新的字段类型要改动就得改源码重新编译。这还能叫工具吗这是给自己挖坑。自定义规则的意义在于把“怎么做”从程序里抽离出来变成一份可以随时修改的配置文件。举个例子同一个模板可以搭配不同的规则文件在A项目里把varchar映射成String在B项目里映射成string在A项目里主键用自增注解在B项目里主键用雪花算法注解。模板和数据都不用动只换规则文件产出就完全适配另一套技术栈。这才是“可自定义规则的代码生成工具”真正值钱的地方。团队里任何人哪怕不会写Java、不会写Python只要懂业务、看得懂YAML也能维护这套生成规则。模板引擎本身只是大力士自定义规则才是大脑决定了这个大力士怎么发力。3. 手搓一个不烧token的可自定义规则生成器含可直接抄走的代码3.1 先定需求边界再写代码我要的工具只有四个能力动手之前我先明确这个工具要解决什么问题不烧token、本地运行、可自定义规则、能批量生成。我刻意没有追求做一个通用的模板引擎因为市面上成熟的Jinja2、Handlebars都已经把渲染能力做得很好了再造一个轮子没有必要。我要做的是在这层引擎之上封装出适合“代码生成”这个场景的工作流。最终这个工具的核心能力收敛成四条读取一份数据文件JSON格式里面描述要生成的所有模型/字段信息。读取一份模板文件Jinja2语法支持变量、循环、条件。加载一份规则文件YAML格式做类型映射和命名处理。按配置批量渲染并把结果写到目标目录。功能不多但正好卡在团队最痛的那个点上。如果你也想自己搞一个建议同样从“下个月要给多少个重复代码”这个角度倒推需求不要一开始就想着全功能。3.2 用Jinja2当渲染内核自己写规则层附核心代码我选Python Jinja2做渲染内核因为它成熟、干净、跨平台不需要引入Node或Java环境。直接在命令行里跑一条pip install jinja2 pyyaml就能开工。整个工具的核心代码很短但骨架很清晰# gen.py import argparse import json from pathlib import Path import yaml from jinja2 import Environment, FileSystemLoader, StrictUndefined def load_json(path: Path) - dict: return json.loads(path.read_text(encodingutf-8)) def load_rules(path: Path) - dict: return yaml.safe_load(path.read_text(encodingutf-8)) def build_env(template_dir: Path) - Environment: env Environment( loaderFileSystemLoader(str(template_dir)), keep_trailing_newlineTrue, undefinedStrictUndefined, # 模板引用到不存在的变量时直接报错而不是静默变空串 ) # 注入自定义过滤器例如把 user_name 转成 UserName def upper_first(value: str) - str: return value[:1].upper() value[1:] if value else value def pascal_case(value: str) - str: return .join(part.capitalize() for part in value.replace(-, _).split(_)) env.filters[upper_first] upper_first env.filters[pascal_case] pascal_case return env def render_one(env: Environment, template_name: str, data: dict, rules: dict) - str: payload {**data, rule: rules} template env.get_template(template_name) return template.render(**payload) def main() - None: parser argparse.ArgumentParser(descriptionTemplate Code Generator) parser.add_argument(--data, requiredTrue, helppath to data JSON) parser.add_argument(--rules, requiredTrue, helppath to rules YAML) parser.add_argument(--template, requiredTrue, helptemplate file name) parser.add_argument(--out, requiredTrue, helpoutput file path) parser.add_argument(--template-dir, default./templates, helptemplate folder) args parser.parse_args() env build_env(Path(args.template_dir)) data load_json(Path(args.data)) rules load_rules(Path(args.rules)) content render_one(env, args.template, data, rules) out_path Path(args.out) out_path.parent.mkdir(parentsTrue, exist_okTrue) out_path.write_text(content, encodingutf-8) print(f[OK] {out_path}) if __name__ __main__: main()有几个细节我在代码里已经备注了但值得再多说两句。StrictUndefined是我强烈建议加上的很多模板工具把“找不到变量”静默处理成空字符串这在代码生成场景里是灾难级的隐患。字段名拼错了你不看输出根本发现不了等代码提交到仓库、CI编译到一半才开始怀疑人生。宁可生成的时候直接抛异常也不要埋一个静默的bug。3.3 通过数据文件驱动批量生成单个文件生成跑通之后批量生成就是加一层循环。我用一个构建清单文件来定义“本次要生成哪些文件”这个清单本身也是一份JSON{ tasks: [ { template: dto.j2, data: data/user.json, output: output/com/example/dto/UserDTO.java }, { template: dto.j2, data: data/order.json, output: output/com/example/dto/OrderDTO.java } ] }然后在原有命令之外再加一个--batch参数读取清单后循环调用render_one。不要小看这个批处理能力实际项目里最爽的瞬间就是你改了字段定义然后一条命令重新生成全部模块代码几十个文件在几毫秒内刷新完毕。这种“一键重建”的感觉会明显提高你改业务模型的勇气因为改动成本变低了重构不再是一件需要鼓起勇气才干的事。3.4 把规则独立成YAML配置让模板“活”起来规则文件的设计我建议按团队技术栈来组织。比如一个后端项目规则配置长这样type_map: int: Integer varchar: String datetime: Date text: String decimal: BigDecimal common_imports: - java.time.LocalDateTime - java.math.BigDecimal annotation_rules: id: TableId(type IdType.AUTO) create_time: TableField(fill FieldFill.INSERT)模板里引用规则的方式很直白。比如处理Java DTO时我可以在模板里写{% for field in fields %} private {{ rule.type_map.get(field.dbType, String) }} {{ field.name }}; {% endfor %}这样业务表里字段的数据库类型是datetime最终生成的就是LocalDateTime数据库类型是decimal最终生成的就是BigDecimal。如果哪天团队决定数据库类型datetime要统一映射成LocalDateTime还是改成Instant只需要改YAML里一行映射模板完全不用动。这就是“规则与模板分离”的威力。模板关心的是代码结构规则关心的是类型口径。结构变化频率低类型口径变化频率高把高低频拆开维护整体变更成本就降下来了。4. PLC、Simulink、前端页面到WPF模板生成在真实场景里的落地方式4.1 PLC代码生成点位表直接变成SCL程序段先说说PLC代码生成。做工业自动化的朋友应该深有体会PLC程序里最重复的一类工作就是I/O映射和功能块实例化。假设现场有200个模拟量点位每个点位都要写一段量程转换、报警判断和HMI地址绑定这些代码结构几乎一样区别只在点位名称、硬件地址、量程上下限。我的做法是把点位表整理成CSV或Excel用Python脚本转成JSON然后套用SCL语言模板生成程序段。模板大概长这样{% for point in analog_points %} {{ point.name }}_RAW : INT; {{ point.name }}_VAL : REAL; {{ point.name }}_VAL : INT_TO_REAL({{ point.name }}_RAW) * {{ point.scale }} {{ point.offset }}; {% endfor %}规则配置里则可以定义模拟量通道类型和设备前缀。这样一来每次新项目来了我只要替换点位表的CSV生成出来的PLC程序段风格和命名完全统一连注释格式都是一致的。以前需要两个工程师忙三天的工作现在半小时搞定剩下时间用来核对量程参数比手写代码有价值得多。4.2 Simulink模型自动生成C代码模板化配置脚本Simulink做模型开发的时候也有类似痛点。模型里的自定义存储类、信号命名规则、生成代码的配置脚本每次新建模型都要重新设置一遍。我通常把模型代码生成相关的配置项抽成模板用脚本灌入新的模型。具体来说我会先生成一份config.m配置脚本模板里写好set_param调用比如目标系统、语言标准、代码风格、注释开关等配置项。占位符就是模型名称、头文件前缀、函数命名后缀。新模型建立后往模板传入模型名自动生成整套配置脚本再在MATLAB里执行Simulink就会按统一规范生成C代码。模板生成在这里解决的问题是配置一致性。团队有四五个人都在做模型开发如果每个人在Simulink里手动点选配置几乎不可能保证完全一致。而用一套模板产出的配置脚本生成大家生成的C代码风格就是同一套标准Review的时候不会因为代码格式吵起来。4.3 前端后台管理页面骨架从接口定义到列表和表单前端后台管理系统是最典型的模板化战场。一个后台页面无非就是搜索区、表格区、分页、新增弹窗、编辑弹窗再加几个操作按钮。这些骨架代码的重复程度高得惊人。我现在的做法是后端把接口定义写成一份JSON描述路径、方法、请求参数和响应字段前端模板根据这份JSON生成API调用函数和页面骨架。比如接口定义里有一个POST接口/api/user/list响应字段是id, name, status, createdAt模板会自动生成一个包含这些列的表格配置和对应的搜索表单项。Vue项目里模板的一小段结构类似这样el-table :datatableData {% for field in listFields %} el-table-column prop{{ field }} label{{ field | pascal_case }} / {% endfor %} /el-table更复杂的交互逻辑当然要人工处理但页面80%的骨架代码是先由模板生成的。搜索区、分页器、弹窗开合这些“肌肉记忆代码”不需要再一行一行敲。规则层里可以定义不同字段类型的默认控件比如enum字段默认生成下拉框datetime字段默认生成日期选择器。这套东西搭好之后后端接口一确定前端十分钟内就能出现一个可运行的页面雏形剩下的时间全部花在真正有业务逻辑的地方。4.4 WPF自定义模板与Word批量填充桌面端与办公文档WPF里的模板分两类一类是DataTemplate决定数据怎么展示另一类是ControlTemplate决定控件长什么样。自己写一套统一风格的WPF模板其实也很适合用模板生成工具来维护。比如你有几十个业务实体每个实体都要一个列表页的总览卡片模板字段不同但结构类似完全可以写一个.j2模板生成XAML资源字典再用数据驱动批量产出。Word批量填充是另一个人人都用得上的场景。WPS和Office都支持通过脚本向Word模板填充数据但很多人还在手动一个文档一个文档地复制粘贴。我用这套思路处理过批量生成合同、批量生成验收报告这类任务先把正文里需要变化的部分用占位符标记好再用Python或者VBA逐条读取Excel里的合同信息填进Word同名占位符另存为新文件。这个场景就是典型的模板字符串替换只不过占位符长在.docx里不在代码文件里。跑一遍下来几十份格式统一、内容准确的文档几秒钟生成完毕。5. 生成工具翻车实录五个你早晚会踩的坑及对策5.1 定界符冲突模板里的CSS/JS花括号误伤第一个坑来自前端项目。我在写Vue代码模板时模板本身用的定界符是{{ }}正好和Vue插值表达式的语法长得一模一样。结果模板里写Vue模板渲染引擎把Vue的{{ item.name }}当成自己的占位符去解析立刻报错。解决办法有两个方向。一个是换掉模板引擎的定界符比如Jinja2可以自定义variable_start_string和variable_end_string改成[[ ]]或者# #这样就和Vue的插值语法错开了。另一个是在模板里用原始块语法把Vue代码包起来告诉渲染引擎这片区域不要解析。我的建议是只要你的生成目标本身包含花括号类语法第一件事就是改定界符别等到报错再处理。像FastReport、WPF的XAML这类本身就带{}绑定的文件也是一样的问题。5.2 缩进与换行崩坏生成代码没法看第二个坑更隐蔽。模板引擎在处理循环时如果缩进写在模板里渲染结果通常没问题但如果某个占位符出现在行首或行尾取出来的值带换行或者空格生成出来的代码缩进立刻乱掉。Python代码对缩进零容忍Java/C代码缩进乱了虽然能编译但Review体验极差。我踩过一次很深的坑模板里写了{% for %}之后忘记控制循环内部的空白行结果生成的Java文件里每个字段之间多了一堆空行整个文件看起来就像谁在床上蹦过一遍。对策主要有三点第一模板里每一行的静态部分和缩进必须完整写在模板文件里第二启用trim_blocks和lstrip_blocks选项自动处理控制语句后面残留的换行和缩进第三生成后接一个格式校验脚本比如Java项目用Checkstyle前端项目跑ESLint代码格式不对直接拦截。5.3 循环嵌套里的变量作用域数据字段同名覆盖第三个坑在实际生成任务里非常容易触发。一次生成的数据文件往往是一个大JSON里面既有根级字段也有嵌套对象。如果模板里第一层循环用了变量item进了第二层循环又用item作为循环变量那么内层循环会覆盖外层循环的item后面再想访问外层字段就全错了。这个问题在Jinja2里表现为变量覆盖更难排查的是它不报错只是结果静默错误。比如内层循环之后模板里写{{ item.id }}本意想取外层用户的ID实际取到的是内层某个子项的ID。我的习惯是所有循环变量都用有业务含义的名字比如for user in users、for field in fields绝不写泛指语义的item并且尽量让嵌套循环里的变量名完全不重叠。5.4 文件编码与换行符Windows和Linux生成结果不一致这个坑主要在跨平台协作时暴露。同一个模板文件在Windows上以GBK编码保存在Linux上以UTF-8保存渲染出来中文注释直接乱码Windows上的换行符是\r\nLinux上是\n同一套模板在两个平台上生成的代码Git提交时会显示整个文件都被修改。解决办法其实很简单但需要从一开始就立规矩模板文件、数据文件、规则文件统一使用UTF-8编码.gitattributes里强制文本文件归一化换行。Python代码里像我前面写的读写文件时显式指定encodingutf-8不要用系统默认编码。这个习惯在Windows上尤其重要因为你永远不知道同事的机器默认编码是什么。5.5 错误定位难模板报错看不出是哪个数据导致的最后一个坑是体验层面的。模板文件一旦变大渲染报错时Jinja2会给出模板行号和错误描述但如果数据文件里有几百条记录其中某一条字段类型写错了渲染时可能要到很深的地方才炸出来。更烦的是报错信息只提示模板第几行不会告诉你具体是数据里的哪条记录。我在工具里加了一个宽松但有效的处理拿到每条渲染结果后先做一次基础校验比如输出文件里不能留有没有被替换掉的占位符不能出现None字样然后再批量写盘。一旦校验失败就把对应的数据文件名和内容片段一起输出到日志这样就能直接定位到是哪个模型文件的问题。生成过程宁可慢几毫秒也要把排查成本降下来。我自己在实际使用中的一个体会是模板代码生成工具看起来“土”但它解决的是工程里最不性感却最消耗精力的一类问题。它不会替你写算法也不会替你想业务逻辑但能把所有重复劳动压缩到一条命令里。如果你也想搞一个属于自己的工具别一开始就追求大而全找一个下周就要交付的高频场景把模板和规则跑通你就能感受到那种“所有文件一键刷新”的踏实感。后面再遇到新的重复代码顺手往工具里补一个模板就行这个习惯会越用越顺手。