sample 负责证明模板活着，tests 才负责证明它没撒谎

模板里同时放 sample 和 tests，经常会被问一句：

这两套不是重复了吗？

其实一点都不重复。

sample 真正负责什么

sample 最重要的价值，是让你在最短路径上确认：

• 引用方式是对的
• 特性发现是活的
• 生成成员能被真实业务代码调用

它更像一个活体演示。

只要 sample 跑通，你就知道这套模板至少没有死。

tests 真正负责什么

tests 负责的不是“看起来能跑”，而是：

• 边界有没有守住
• 诊断有没有漂移
• 配置优先级有没有被改坏
• analyzer 和 generator 的协作有没有退化

这类问题，sample 基本不适合承担。

因为 sample 的目标是让人快速理解，不是把所有反例都塞进去。

为什么这两者不能互相替代

只保留 sample，你会缺少系统化回归拦截。

只保留 tests，你又会失去最直接的接入演示和活体验证。

模板一旦要复制给别人，这两种能力都很关键：

• sample 负责降低第一次接入门槛
• tests 负责降低后续演进风险

少任何一个，模板都会偏科。

enterprise 模板为什么两者都保留

因为它既要被人看懂，也要被机器稳定验证。

前者靠 sample，后者靠 tests。

这不是冗余，而是模板从“示例项目”升级成“团队骨架”后必须具备的双面能力。

一句话结论

sample 的职责是证明模板活着，tests 的职责是证明模板在扩展和重构之后仍然诚实地守住原有边界。