显式文件发现，真正打破的是文件名约定的锁定

只靠文件名约定做发现，入门很顺。

因为规则简单：

• 文件名长得像 tutorial*.strings.json
• 那就进生成器

但这条路走到真实项目里，很快就会遇到一个硬限制：

旧项目里已经存在很多不符合约定的文件。

为什么命名约定会变成迁移阻力

如果生成器只认一种文件名模式，那你接入旧项目时通常只剩两种选择：

• 批量改名
• 放弃接入

这两种都不理想。

批量改名会带来大量非业务改动，放弃接入则等于把生成器能力锁死在“新项目、干净命名”这一类场景里。

所以第二季真正需要补上的，不是另一个命名模式，而是：

显式文件发现。

显式发现真正改变了什么

很多人以为 TutorialSettingsEnabled=true 只是“多开了一个开关”。

但它真正打破的是：

文件名约定对输入资格的独占。

也就是说，从这一刻开始：

• 约定命名仍然可以继续工作
• 但它不再是唯一入口

这一步非常关键，因为它让第二案例从“围绕样例约定组织输入”走向了“能接历史系统”。

为什么这件事应该放在入口层处理

显式发现解决的是：

这个文件到底有没有资格进入后续管道。

这不是 JSON 解析问题，不是元数据合并问题，也不是渲染问题。

所以它就应该在入口层完成决议：

• 文件名符合约定，默认可进
• 显式设为 true，无论名字如何都可进
• 显式设为 false，即使本来符合约定也要排除

这种分层很重要，因为它能把“发现错误”和“内容错误”彻底拆开。

为什么非法值必须直接失败

像下面这些写法：

• yes
• 1
• enabled

如果被模糊容错，你很快就会遇到最难排查的结果：

• 你以为某个文件已经启用，其实没进来
• 你以为某个文件已经禁用，其实还在继续参与生成

所以第二季这里必须坚持一个更硬的原则：

非法值不要猜，直接报错。

这样边界反而最清楚。

为什么这一步会直接影响博客第二季的价值

因为它说明第二季已经不再只是“如何设计一个干净样例”，而是在讨论：

怎么把生成器接进现实里那些不够干净的项目。

这才是 AdditionalFiles 场景真正值得讲的地方。

一句话结论

显式文件发现真正打破的不是某个文件名模式，而是生成器对“只有新项目才能优雅接入”的默认假设。