命名生成器

解决什么问题

当代码库中混用 User、Account、Member，或出现 DataProcessor2、HandleStuff 这类名字时，阅读成本会迅速上升。这个技能解决的问题不是“取一个好听的名字”，而是让新名称与周围系统保持一致：先理解相邻模块、文件、接口和数据结构的命名方式，再为待命名概念生成能融入现有约定的候选。

核心能力

它不会凭空抛出一个英文名，而是按以下方式工作：

• 先检查 nearby naming conventions：包名、类名、函数名、变量名、接口字段和测试目录中的模式。
• 再明确 concept 的 responsibility、scope 和 audience：它是对外 API，还是内部实现细节？调用者是谁？生命周期多长？
• 优先选择 boring, specific 的名称，避免 broad 或 metaphorical 名称。
• 避免把 implementation details 写进名字，尤其是这些细节可能随重构变化时。
• 当选择主观性较强时，输出 3-7 个候选，并说明每个名称的 tradeoffs。

好名字的标准

Good names make misuse harder. 名称应回答“这个对象代表什么”，而不是“当前代码如何产出它”。因此，OrderReceipt 通常比 OrderPrinter 更稳定；RefundPolicy 比 RefundLogic 更贴合领域；InvoiceSnapshot 也比 InvoiceDataFromDb 更容易长期使用。

适用边界

它适合在已有代码库或正在形成的约定中做命名评审，不适合替代领域建模；如果上下文非常模糊，它给出的候选也需要人来验证。不要把它当作命名数据库，也不要期待它为所有缩写、遗留接口和跨团队冲突提供唯一正确答案。