模板不是多余脚手架，而是长期成本控制器

很多人第一次看见源生成器模板，会先问一句：

这不就是脚手架吗？

这个判断只对了一半。

如果模板只能帮你在第一天少建几个目录、少写几个 csproj，那它确实只是脚手架。可一旦模板把职责边界、诊断编号、测试路径和交付链路一起固定下来，它控制的就不是“初始化动作”，而是后面几个月的维护成本。

真正被复用的，不是文件，而是决策

一个成熟模板真正替你重复利用的，通常是这些决策：

• 入口类只做装配，不继续堆业务逻辑
• 发现、校验、渲染和诊断分别落在哪些位置
• 配置输入通过什么契约进入生成器
• 测试和 sample 各自负责哪一段验证
• 最终包怎么被外部项目消费

这些东西一旦没有模板，每开一个新生成器项目，团队都会重新争一遍。

为什么没有模板时，成本会在后面爆出来

没有模板时，第一天通常看不出问题。

因为你只需要让第一份 .g.cs 生成出来。

真正的代价会在后面集中出现：

• 第二个需求进来时，不知道新字段该改哪一层
• 第三个诊断进来时，编号和分类开始失控
• 第一次接 AdditionalFiles 时，读取逻辑直接塞进主 pipeline
• 第一次准备交付时，才发现只有 ProjectReference 跑通过

这些都不是“代码能力不够”，而是缺少一套预先收口好的结构。

模板最值钱的地方，是把改动面固定住

高质量模板的价值，通常不是“功能最多”，而是“改动落点稳定”。

你今天要扩一个字段，知道去改 Models + Pipeline + Rendering。

你明天要补一个错误，知道先去看 Diagnostics。

你后天要支持配置文件，知道不能直接往渲染器里塞解析逻辑。

一旦这些改动面稳定下来，生成器项目的维护成本就会明显下降。

所以第三季为什么必须讲模板

前两季解决的是：

• 生成器为什么成立
• 输入怎么进入
• 配置怎么合并

但真正进入团队后，还会有另一个问题：

这套能力以后怎么被复制、升级和交付。

模板讨论的，正是这个问题。

一句话结论

模板真正控制的不是初始化速度，而是生成器项目在后续扩展、测试和交付阶段会不会持续失控。