项目拆开以后，源生成器工程才开始稳定

源生成器最常见的结构性误区，是把生成器代码、示例代码和测试代码全塞进一个项目里。这样一开始看起来省事，后面几乎一定会在引用关系和调试链路上踩坑。

当前仓库把主案例拆成三个核心项目：

• 生成器项目：只负责分析和产出代码
• 示例项目：只负责消费生成器，验证最终用法
• 测试项目：只负责编译级回归验证

为什么不能只有一个项目

因为三件事的目标完全不同。

生成器项目关心的是 Roslyn API、模型提取和输出逻辑；示例项目关心的是“业务方怎么看到生成结果”；测试项目关心的是“这次修改会不会把已有行为打坏”。

一旦把它们混在一起，你会很快遇到这些问题：

• 不知道错误是生成器本身的问题，还是示例代码的问题
• 无法清晰表达“生成前”和“生成后”的边界
• 测试只能做字符串比对，不能做真正的编译验证

两条案例线为什么也要分开

当前仓库除了 ToString 主案例，还有 AdditionalFiles + AnalyzerConfigOptions 的第二案例。把它独立出来，不是为了多做一个 Demo，而是为了证明主线心智模型在更真实的输入场景里仍然成立。

好的教程结构，不是把所有变化都塞进一个例子，而是先稳住一条主线，再用第二案例扩充输入边界。

先把结构立住，后面的复杂度才有地方放

项目拆分不是形式问题，而是后面所有讨论的前提。你只有先接受“生成器、消费方、测试方职责不同”，后面的入口设计、诊断设计和扩展策略才会自然。