用途：这是一套与语言无关的命名原则，用于在编码时给变量、函数、类和集合取名，让名称体现代码意图与领域含义，而非底层实现。
主要能力： 一、禁止含糊命名。明确禁止 Manager、Helper、Util、Misc、Common 等笼统词，也避免 step1、phase1 这类时间性命名、单字母名（循环计数器 i、j、k 除外）以及 usr、msg、ctx 这类模糊缩写（id、url、api、http 等广为人知的例外）。Service、Handler、Processor、Controller 需谨慎使用，仅当带有明确领域或框架语境时才可接受；Base、Abstract 前缀在框架、库代码中可用，在应用代码中通常应避免。 二、变量用描述性名词并使用领域语言，例如 activeUsers、totalRevenue、selectedItems，避免 userArray、data 这类暴露数据结构或过于笼统的名字，注意 activeUserCount 比 count 更清楚。 三、函数用动词加名词。纯函数描述转换（format、parse、convert），有副作用的函数用 save、send、fetch、update、delete 等动词；返回布尔值时用 is、has、can、should 作前缀。避免 get、do、handle、manage、process 等没有上下文的含糊动词。 四、类与类型用单数名词并体现领域概念，如 User、Order、PaymentProcessor、OrderRepository；Repository、Factory、Builder、Strategy 等模式后缀在能增加含义时可用。 五、布尔值使用疑问前缀：is 表示状态（isActive、isLoading），has 表示拥有（hasPermission、hasChildren），can 表示能力（canEdit、canDelete），should 表示条件（shouldRefetch），will 表示未来（willExpire）。 六、集合用复数表示多项，如 users、selectedItems、errorMessages，避免 userList、userArray 这类冗余类型后缀；键值集合用 userById、configByEnv、productsByCategory 表达键含义。
使用方式：这是一份命名约定参考，可在命名时对照其模式模板执行，例如变量用描述性名词、函数用动词加名词、布尔用疑问前缀、类用单数名词、集合用复数。资料未提供安装命令、配置文件或自动检查工具，具体如何集成到项目暂未提供。
适用场景：适用于 TypeScript、Go、Rust、Python 等多种语言的日常命名与代码评审，尤其适合需要统一命名风格、提升可读性的团队。
限制：文档中的规则带有主观取舍，部分通用命名（如框架中的 RequestHandler、UserRepository）被列为在特定语境下可接受；未提供强制校验手段、性能影响或收费信息。