2026-03-22
第 1 篇模板不是多余脚手架，而是长期成本控制器
真正有价值的模板，不是在第一天帮你少敲几行代码，而是在后面每次扩字段、补诊断、接配置和交付时持续压低成本。
系列
模板、工程化与落地
第三季主线：从 simple、standard、enterprise 模板到改名、测试、打包和 PackageReference 消费，把教程推进到可复制的交付骨架。
这一季开始讨论“怎么把教程能力变成可复制的工程骨架”：
- 为什么模板不是多余脚手架，而是长期成本控制器
- simple、standard、enterprise 三套模板分别适合什么阶段
- 模板复制到新仓库后，为什么改名、测试和打包才是真正难点
- 为什么
ProjectReference跑通还不够，必须继续验证PackageReference消费链路 - 为什么分层配置、测试基座和发布检查应该在模板阶段就提前收口
- 为什么 sample、tests 和交付脚本不能互相替代
第三季阅读路线
从模板选型一路读到改名、测试、交付脚本和发布清单
01
先做模板选型
先把 simple、standard、enterprise 的边界读清楚，不要一开始就默认越重越好。
02
再看复制落地
重点理解为什么模板真正容易失败的地方是改名、包面和 PackageReference 消费。
03
补工程化基础设施
把分层配置、测试基座、sample 和交付脚本当成模板契约，而不是发布前临时拼装件。
04
最后收发布闭环
把发布检查清单、验证顺序和交付动作一起收口，模板才能稳定复制到团队仓库里。
如果前两季解决的是“怎么把生成器做出来”，这一季解决的就是“怎么把它稳定带进团队和仓库里”。
2026-03-22
第 2 篇simple 模板适合验证，不适合长期还债
simple 模板最有价值的地方是快速确认 Roslyn 接线和生成闭环，而不是承载你后面所有工程复杂度。
2026-03-22
第 3 篇standard 模板真正值钱的地方，是改动落点清晰
standard 模板不是 simple 的加厚版，而是大多数正式项目最该使用的默认骨架，因为每类改动都有明确落点。
2026-03-22
第 4 篇enterprise 模板不是“文件最多”，而是“交付闭环最完整”
enterprise 模板真正贵的不是复杂度本身，而是它把声明诊断、配置契约、测试和 NuGet 消费链路一起闭环了。
2026-03-22
第 5 篇从模板复制到新仓库时，最容易失败的是改名与包消费链路
模板真正落地时，最常见的失败点不是结构设计，而是改名不完整、包元数据遗漏，以及 PackageReference 消费链路没有被认真验证。
2026-03-22
第 6 篇ProjectReference 跑通，不等于 PackageReference 可交付
本地 sample 的 ProjectReference 只能证明生成器在开发链路里活着，不能证明最终 nupkg、分析器收拢和外部消费者恢复链路都正确。
2026-03-22
第 7 篇分层配置不该等到第二个仓库才设计
模板第一次落地时如果不先想清楚默认值、仓库级覆盖和文件级覆盖的边界，第二次接入时通常就会开始出现配置债。
2026-03-22
第 8 篇测试基座应该早于复杂功能扩展
对源生成器模板来说，先补测试基座再扩 AdditionalFiles、诊断和配置合并，通常比反过来便宜得多。
2026-03-22
第 9 篇sample 负责证明模板活着，tests 才负责证明它没撒谎
sample 和 tests 在源生成器模板里不是重复建设：前者证明链路活着，后者证明复杂边界没有被悄悄改坏。
2026-03-22
第 10 篇交付脚本应该是模板契约的一部分，而不是口头流程
模板如果要真正被团队复制和发布，改名、打包、恢复和消费验证这些动作就应该进入脚本层，而不是留在记忆和聊天记录里。
2026-03-22
第 11 篇发布检查清单应该写进模板，而不是留在人的记忆里
模板真正进入首发阶段时，最容易遗漏的往往不是生成逻辑，而是包元数据、诊断前缀、示例配置和消费链路这些发布面。