那天的代码评审我差点被一支命名为model_final_v2_really的分支劝退。旁边的同事把投影仪切到 deploy 配置界面里面躺着ai_platform_test2、ai_platform_test3、ai_platform_new_new谁也不知道哪个才是生产环境真正在用的。不是大家不懂命名而是当团队被 AI 项目的快节奏推着走时命名这件事总是被排在“到最后再说”的那一栏。但 AI 项目恰恰是最不能忽视命名的地方模型会迭代、服务会拆分、数据集会扩展代码里任何一个模糊的名字都会在一周后变成团队之间互相确认的成本。我后来想了一件反直觉的事与其在model_best和model_best_v2里反复挣扎不如把目光放回半个多世纪前的科幻小说。60 年代的科幻名今天拿来给 AI 项目命名仍然够用而且往往比我们自己现场造的词更准确、更有辨识度。这不是情怀而是一种工程策略。1. 为什么AI项目的命名问题比普通项目更严重1.1 从变量名到模型名命名的层级被低估了很多团队在还没有正式命名规范的情况下就先跑通了第一版 AI 服务。这可以理解毕竟从训练到部署中间有太多比命名更紧急的事。我自己也做过这种事先用test.py跑通 PyTorch 推理再复制成test2.py调整参数最后等到需要给这个模型写网关接口的时候才发现根目录下已经躺了五个不重样但意思差不多的文件。AI 项目里的命名不是只有变量名和函数名。它是一个从底层到上层的完整链条数据集名称训练集、验证集、测试集以及经过清洗、增强后的不同版本。模型结构名称网络结构、预训练权重、微调版本对应的标识。特征名称不同特征工程步骤产出的字段。服务接口名称API 路径、模型服务名、推理服务版本号。环境名称dev、staging、prod以及每个环境的模型映射关系。配置键名称超参、路径、开关、模型列表等配置项。只要这一层里的任何一级命名是随手的后面排查问题时就会被反复击中。尤其当模型从实验状态进入产品状态后model_final_v2这种名字几乎必然导致误用。它不是风格问题是生产事故的隐患。1.2 AI原生团队为什么最容易出现命名混乱按理说AI 从业者普遍对抽象概念敏感应该更容易理解命名的价值。但实际观察到的现象恰恰相反。原因是 AI 项目的开发节奏太像“研究”而不是“研发”一开始没有人知道哪个方向能跑通于是每个人都在自己的临时目录里做实验。实验本身就是试错名字自然也会随意很多。另一个推手是模型迭代速度。一个模型今天还是v1.0明天因为加了数据增强变成v1.1后天又换了一个 backbone可能就要叫v1.2或v2.0。如果命名规则没有事先定好大家就会凭感觉加_new、_plus、_refactor、_final这样的后缀。这些后缀在写代码的那一秒钟有意义但过两周再看没人能回忆起当时的“感觉”。这些问题在普通 Web 项目里也存在但在 AI 项目里会更难清理。原因是模型产物的体积大、路径依赖强很多运行结果都绑定在特定的实验目录下一旦名字乱掉重跑的代价很高。你没法简单复制一个model_final_v2的文件夹然后重新训练一遍。1.3 命名不是风格洁癖是沟通成本很多团队把代码命名当成“风格问题”觉得只要功能正常大小写和下划线都无所谓。但实际上命名是注释之外最重要的沟通载体。代码首先是给人读的其次才是给机器执行的。一个变量叫user_age和一个变量叫a1对于读代码的人认知负担完全不同。AI 项目里这种差距会被放大因为代码里到处都是张量、矩阵、损失函数和评估指标本身就足够抽象如果再叠加模糊命名可读性会迅速崩掉。从这个角度看命名是一种降低沟通成本的投资。好的命名让新成员入职时能快速定位代码坏的命名让所有人都在群里反复追问“这个参数是干什么的”。算下来一个命名检查清单可以省下大量“看起来不重要但实际上很磨人”的沟通。2. 60年代科幻留给AI时代的命名宝库2.1 那些跨越半个世纪的词汇和意象为什么我会说 60 年代科幻名仍可用因为那一代科幻作品集中讨论了一个核心主题人与智能机器的边界。阿西莫夫的机器人系列、海因莱因的《严厉的月亮》、克拉克的《2001太空漫游》这些作品里出现了大量后来成为技术世界通用词的名字和概念。无论是 “Robot” 这个基本词还是 “Hal” 这样的人工智能角色名都自带一种“智能体”的文化线索。如果从 AI 项目命名的角度看这些名字有一个共同特点它们不是无意义的音节而是自带一段可以被解释的故事。给一个语义检索服务起名Foundation团队里读过《基地》的人会立刻知道这是一个提供基础能力的平台服务给一个超大规模模型起名Ansible懂科幻的人能联想到“瞬时通信”的意象很适合用于需要快速同步的分布式推理场景。即便团队里没人读过原著只要命名文档里解释一句“这个词来自经典科幻代表跨距离实时协同”名字就有了记忆点。这些名字比随手造的aiprocessor更有生命力。因为它们不是行业黑话而是公共文化的一部分。任何人都可以借助这个文化背景快速理解一个产品或者一个模块在解决什么问题。2.2 为什么科幻名比新造词更适合AI产品新造的复合词有一种天然缺陷第一次看到它时你不知道它是组合词、简称还是误拼。比如smartbrain这种名字看似直观但它既没有提供新的理解框架也没有让读者联想到任何已有的知识背景。它只是一种“描述性标签”相当于把“智能大脑”翻译成英文并拼在一起信息量很低。相反一个成熟的科幻名往往具有三个特性可联想它关联着一个已有的概念或故事用户能通过类比快速理解产品定位。可拼读大部分经典科幻名都遵循字母语言的自然读音规则不容易读错。可扩展同一个词根可以衍生出系列名例如用Foundation作为平台名子服务可以叫Foundation-Index、Foundation-Query形成一套干净的名字树。这里要注意不是所有科幻名都适合直接使用。太长或太生僻的词会造成输入负担。比如某个角色的全名可能很有史诗感但每次部署时都要在命令行里敲一遍就会变成纯粹的负担。所以一个基本建议是优先选择两个音节的短词、可作名词的专有名词以及不会和现有技术栈冲突的词汇。2.3 使用科幻名的边界商标、语义错位与版本归属把科幻名当作命名灵感不等于闭着眼直接抄。需要先做三件事。第一件事是排查商标风险。很多经典科幻名已经被注册成了产品商标或技术项目名称。比如Gort在多个领域都有使用Trantor也有对应的软件组织名。不能因为名字好听就直接用尤其是商业产品必须先做基础检索。第二件事是检查语义错位。一个词在原作里可能代表“无所不知的超级智能”但你的项目只是一个轻量级 API 网关。名字太重反而会增加团队心理负担也会让外部用户产生错误预期。命名要和项目的实际复杂度匹配。第三件事是版本归属。如果同名项目已经存在开源版本而你只是使用别人代码库里的部分思想再用同一个名字会引发混淆。这时候可以在名字后面加-like或使用变体例如在内部项目里叫FoundationX并明确记录“从某开源项目获得灵感但内部实现已独立重构”。命名建议不是让你执着于原作忠实度而是让名字在真实工程里能稳定使用五年。如果名字好看但下个月就得换那么这个灵感本身就没有转化价值。3. 一套可以落地的AI命名方法3.1 先给命名对象分层如果想把命名从“碰运气”变成“流程化”第一步不是找名字而是先分清楚这次的命名对象到底是哪一个层级。不同层级的命名约束完全不同。常见的 AI 项目命名层级可以分成五层产品层对外展示的产品名例如智能助手、推荐系统、视觉分析平台。项目层代码仓库名、项目代号、内部服务名。模块层核心算法模块、数据模块、评估模块、部署模块。模型层模型结构名、预训练权重名、微调版本名。资源层数据集名、特征名、配置键名、环境名。越靠近产品层越需要顾及用户记忆、品牌辨识度越靠近资源层越需要遵循技术一致性减少特殊字符和长度限制。很多命名混乱的根源在于把产品层的取名思路用到了资源层或者反过来。比如在配置键里使用大小写混合、带空格的长标题结果导致脚本解析出错。一个稳妥的流程是先明确“现在给哪一层命名”再决定风格。产品层可以大胆使用科幻意象模块层应该优先考虑语义清晰模型层则必须包含版本信息和时间锚点资源层要尽量全部使用小写字母、数字和下划线。3.2 从科幻意象到合规标识符的转换规则选好了想用的科幻词还得把它转成符合当前技术栈的标识符。不同语言和平台有不同的风格习惯。比如 Java 类名常用帕斯卡命名法FoundationIndex变量名和函数名用驼峰命名法foundationIndexPython 变量和函数名用下划线命名法foundation_indexC 命名空间和类名在不同团队里也有不同约定。并不是所有科幻名都能原样放进代码里需要进行标准化处理。转换时可以按下面这套规则处理去掉特殊字符空格、连字符、撇号一律去掉或转成下划线。统一大小写风格根据所在语言和项目规范使用 camelCase、PascalCase 或 snake_case。缩写检查如果名字本身很长可以压缩到 2-3 个音节但必须在代码注释里标注全名。语言约束检查避免使用保留字、避免数字开头、避免连续下划线。跨模块查重在代码库中搜索同名确认没有冲突。例如FoundationIndex在 Python 模块里可以变成foundation_index在 API 路径里可以变成foundation/index在环境变量里可以变成FOUNDATION_INDEX_ENDPOINT。只要在文档里建立一张“科幻名 → 各层标识符”的映射表团队就能始终清楚地知道同一个概念在不同位置用了什么名字。3.3 命名质量检查清单每完成一个命名可以跑一遍下面的清单。不需要很长时间但能拦截大多数后续问题。检查项说明通过标准可读性其他人是否能只看名称就大致理解用意不用解释也能猜出五成以上可拼读口头讨论时是否能顺畅读出来不会出现长停顿或拼字母无歧义在当前项目里是否有多个完全不同的含义一个名称只对应一个核心概念一致性是否与同级其他命名风格一致同一层级使用同一套大小写和分隔符规则长度控制是否在可接受的长度范围内资源层尽量不超过 32 个字符版本辨识是否包含可追踪版本信息模型名中至少有主干版本号商标/冲突是否与已有开源项目或商业产品明显冲突搜索后无高相似同名风险文档映射是否有文档记录该命名的来源和含义README 或命名规范表中有条目这张清单不需要每次都打印出来。可以把它做成 code review 的勾选项或者写进命名规范文档的第一页。真正有用的不是清单本身而是它强制团队在命名这件事上做一次慢思考。如果你现在没有一个可以长期使用的命名规范我建议先做一张最简单的命名映射表一列写目标词汇一列写产品名一列写项目名一列写代码标识符。之后所有新模块都先查表再决定是否新增名字。4. 从命名灵感到团队共识工程化落地建议4.1 用规范文档和代码评审守住一致性仅有一个人觉得“60 年代科幻名挺好用”是不够的。命名要成为团队资产必须沉淀成文档并在代码评审时被实际执行。否则每个人都会按自己的口味来有人喜欢《沙丘》有人喜欢《海伯利安》很快就会形成另一层混乱。具体做法可以在项目根目录放一份NAMING.md内容不用很长但要包含命名对象层级、风格约定、允许使用的词根、禁止使用的后缀、以及一张“已使用名称登记表”。登记表很关键。它避免两个模块分别用了同名科幻词而互相覆盖也避免后人不知道trantor其实是一个未上线模块的代号。代码评审里命名应该是一票否决项。不是为了让评审人扮演语文老师而是因为命名问题一旦合并后续改动成本会指数级上升。在评审时问三个问题这个命名是否准确表达了模块功能是否符合NAMING.md中的层级规范是否有同级别的其他命名风格可以参考三个问题都过关再谈逻辑实现。4.2 模型名、API名和环境名的统一策略在 AI 项目里最容易出现命名不一致的是模型、API 和环境这三组名称之间的对应关系。比如模型叫bert_base_uncased对应的 API 路径却叫/v1/semantic环境变量里叫MODEL_A。一旦三者不能对应排查问题时会耗费大量时间。一个较稳的策略是让三者共享同一个核心标识符。假设我们选择了一个 60 年代科幻词trantor作为某个文本分类服务的内核名那么模型目录名tranto_bert_base_v1服务名trantor-classifierAPI 前缀/v1/trantor/classify环境变量TRANTOR_MODEL_PATH、TRANTOR_SERVICE_URL部署环境标签trantor-dev、trantor-staging、trantor-prod这样从日志、监控指标到部署配置都能通过trantor这根主线快速串起来。如果服务内部有多个模型再用trantor-entity、trantor-sentiment作为子标识保持家族感的同时也保证唯一性。这套做法的本质不是追求名字好看而是让一个词成为跨层级的“外键”。只要核心标识稳定其他数据都容易被追踪。4.3 命名混乱时的排查与重构路径如果项目里已经出现了大量的model_new、test_final也不要急着立刻全部重命名因为盲目重构可能破坏代码。建议按下面的链路排查先确认最危险的部分哪些命名直接关联生产环境配置、模型路径、数据库表名和 API 路由。这部分风险最高优先处理。再做依赖分析使用代码搜索工具查一下目标名称在哪些文件、脚本、文档、K8s 配置、CI 流程中出现过。不要只看.py文件还要看yaml、json、Dockerfile和.env样例。然后建立映射表把旧名和新名一一对应先在文档里列出不要直接在代码里全局替换。按模块分批重构每次只改一个子模块并且立即跑测试和部署验证。避免在周五下午一次性替换所有文件。最后更新文档和配置模板很多项目只改代码忘了更新 README 里的示例命令和配置模板。结果新成员照着旧文档启动服务又生成了一次旧名字的实例。这套路径的核心不是“赶紧把名字改漂亮”而是先识别哪些名字是真实正在被依赖的哪些只是陈旧的残留物。把依赖理顺了命名重构才不会改出一堆新的_v2。5. 最后的建议先从一个变量名开始改变5.1 适合用60年代科幻名的场景不是所有 AI 项目都适合使用科幻名但有几种场景非常合适。如果你的团队正在做内部平台或工具链使用科幻名可以降低沟通成本。比如把数据管道服务命名为psychohistory团队里自然会有好奇的人去查这个词的出处从而在讨论“数据预测”这个话题时多一层共同语言。如果团队本来就有阅读科幻的习惯这种做法会显著增强项目本身的辨识度。如果你的项目需要一个可扩展的命名族谱科幻名也比功能性口号更耐用。比如用ansible作为分布式部署平台的核心代号子功能可以叫ansible-discovery、ansible-sync比sync-service-v1、deploy-worker-2更容易记忆。如果你的产品想要传达“智能体”“自主系统”“机器与人类协同”等理念60 年代科幻名提供的隐喻能量会很有帮助。一个叫Golem的自动化工作流引擎和一个叫auto_workflow的工具给人的心理感受完全不同。5.2 不适合用科幻名的情况但也有几类场景不建议套用。如果产品面向的是对技术术语陌生的大众用户使用生僻科幻词会增加理解门槛。这时候更稳妥的选择是直白易懂的通用词或产品名而不是让用户去查典故。如果你所在的行业对命名有严格合规要求比如金融、医疗、政务那就要优先确保命名不会产生歧义、不会触犯监管规定不要为了风格引入复杂词汇。合规性永远高于文艺性。更重要的一点命名不能掩盖架构问题。如果一个服务里面乱七八糟哪怕起名Foundation也不能让它更有韧性。命名只是让问题更容易被看见不能替代设计。一个团队如果连模块边界都没想清楚先花一整周想名字那是在本末倒置。我自己的建议是从最小的一步开始。为今天新增的变量、模型文件路由或者环境变量配置文件挑一个有意思且有解释潜力的名字在旁边用一行注释说明它来自哪个经典科幻意象。然后观察这种方式是否能让协作更顺畅。如果有效再逐步把命名规范、检查清单和映射表引进团队。不要想一次性把五年间形成的命名债全部还清先让新代码成为好例子比大规模重构更容易执行。说到底60 年代的科幻名仍然可用不是因为旧东西更好而是因为它提示我们好的命名是一种跨越时间的隐喻。它把新技术放回人类已有的经验框架里让人不需要重新学习一套生硬的黑话。AI 领域已经足够难懂了我们能做的是至少给它一个让人能记住的名字。