交付脚本应该是模板契约的一部分，而不是口头流程

模板成熟到一定阶段后，最容易被忽略的一块不是代码，而是动作。

也就是：

• 怎么批量改名
• 怎么打包
• 怎么恢复 package consumer
• 怎么按固定顺序验证整条链路

如果这些动作只存在于 README 一小段说明里，或者只存在于某个维护者脑子里，这套模板其实还没有真正工程化。

为什么脚本层很重要

因为交付失败往往不是“不会写生成器”，而是：

• 少改了一个命名空间
• 忘了同步包名
• 本地能 run，换台机器 restore 就断
• 验证顺序每个人都不一样

这些问题最适合用脚本固化，而不是靠人记。

什么动作最值得脚本化

模板里最值得脚本化的，通常是这几类：

• dry-run 改名
• 正式改名
• 打包输出到固定目录
• package consumer 恢复与 smoke run
• 发布前的统一检查命令

一旦这些脚本存在，模板复制出去后的失败概率会明显下降。

为什么这也是模板契约的一部分

很多人把模板理解成“源代码模板”。

这个理解不够完整。

更准确地说，模板应该同时包含：

• 代码骨架
• 配置骨架
• 测试骨架
• 交付动作骨架

少最后一层，模板还是会在真正 rollout 时暴露大量人为差异。

一句话结论

当一套源生成器模板准备给团队复用时，交付脚本就不再是附属品，而应该和代码、配置、测试一起成为模板契约的一部分。