李弯湾我一直觉得，程序员日常里最磨人的不是那些需要绞尽脑汁的算法设计，也不是复杂的业务逻辑梳理，而是没完没了的模板代码。结构体定义、读写接口、状态管理、算法竞赛里那些固定套路的线段树、平衡树，每次写到它们的时候，脑子完全是放空的，手却停不下来，效率低不说，还特别容易在复制粘贴里混入几个低级 bug。
所以当我看到"模板代码生成工具"这个项目标题，加上"自定义规则""不烧 token"这几个关键字时，一下就来了兴趣。这些年市面上的代码生成方案我基本都试过：重量级的用起来要配一堆插件和配置文件，轻量级的又往往规则固定，想生成线段树套线段树这种特定数据结构就得自己动手写脚本。这个工具主打"简单、高效、不烧 token"，还能自定义规则，说实话正好打在痛点上。
这篇东西我打算把它从设计思路、核心功能、实操过程到踩坑记录完整拆一遍，尤其是怎么用它生成算法竞赛里那种复杂的线段树套线段树模板，给有同样需求的朋友一个可以直接上手的参考。
1. 内容整体设计与思路拆解
1.1 为什么"可自定义规则"比"开箱即用"更重要
市面上的代码生成工具大概分两类。第一类是全家桶式的脚手架工具，你告诉它"我要一个 Spring Boot 项目"，它哗啦一下给你吐出一堆文件。第二类是代码片段管理工具，本质上是增强版的复制粘贴板。这两类工具的问题其实是一样的：规则是别人定好的，你想在生成的结构体后面自动加上一组特定命名的 getter/setter，或者想统一给每个类文件头加上一段包含团队信息的注释，就得在生成之后二次手工加工。
这个项目选择把"自定义规则"作为核心卖点，我认为是抓准了真实需求。以算法竞赛选手为例，线段树套线段树的模板看着千篇一律，但每个人习惯的写法不一样。我习惯用数组模拟节点而不是指针，我喜欢把 update 和 query 封装成带默认参数的形式，我还会在模板里预留下离散化的接口。这些个性化的东西，通用的工具根本给不了，只能自己写生成规则。
再往深一层看，自定义规则的意义不只是"按我的喜好生成代码"，它其实是在把程序员脑子里的隐性经验显性化。你写一条"创建结构体时自动补全比较函数"的规则，本质上就是把"我每次写结构体都要记得加 cmp"这个思维习惯固化成规范。时间一长，这套规则就变成了你自己专属的工程规范检查器。
1.2 "不烧 token"背后的技术选型逻辑
最近几个月 AI 辅助编程热度一直很高，很多人第一反应是：生成模板代码？直接丢给大模型不就行了？我也试过这种方案，结论是：能跑，但很别扭。
一方面，大模型生成代码存在随机性。同一个需求，你让它生成十次线段树套线段树，它每次给的变量命名风格、代码排版、边界处理方式都可能不一样。这在算法竞赛场景下尤其致命，因为你需要的是完全可控、每一个变量的下标含义都了然于胸的代码，而不是一个"看起来应该没错"的版本。
另一方面，token 消耗是真实成本。把一段冗长的算法模板输入给大模型，让它"按我的风格改一改"，一次可能就要消耗几百上千 token，反复调试几次，成本蹭蹭往上涨。而"自定义规则"本质上是把生成逻辑变成确定性匹配，本地跑完瞬间出结果，完全不走网络请求。
这就好比你既可以请一个大厨来你家做菜，也可以准备一套模具直接压出形状统一的点心。前者灵活但每次都要沟通成本，后者只要你提前把模具刻好，之后每次使用都是零额外成本。模板代码生成工具走的就是"模具"这条路，把生成规则一次性定义好，以后每次使用都是秒出结果。
1.3 这个项目适合谁，解决什么场景
往细了说，这个工具至少适合了三类人。
第一类是算法竞赛选手。比赛里经常需要大量重复书写数据结构的模板代码，而线段树套线段树这类复杂度较高的模板，手打一遍怎么也要二十多分钟，还容易出错。用工具提前定义好规则，比赛前一键生成，省下来的时间可以多推演两道题的边界条件。
第二类是业务开发中的 CRUD 工程师。每天写新增业务的接口、DTO、Mapper，结构几乎一模一样，区别只