面试被问产品命名，怎么判断一个名字好不好？

有观点认为，多智能体不该叫 swarm，而应叫 flocks of agents；还有人补了一句：没人想 invoke 一个 swarm，但显然它就是 swarm。这场争论本身没有结论，但它恰好是产品命名面试题的活素材——面试官想看的不是你喜欢哪个词，而是你怎么拆。

命名评估至少有三个角度。第一是调用场景：用户是在命令行里敲它，还是在汇报里念它？素材里那句“没人想 invoke 一个 swarm”，指向的正是调用时的心理感受，而不是词义对错。第二是认知负担：flock、pride、party 这些替代词更轻松，但用户是否知道它们指同一类东西？第三是传播成本：名字越长越独特，口头传播越容易走样。

面试里可以这样答：先问目标用户是谁、在什么场景下说出这个名字，再判断哪个维度权重最高。不要一上来就说“我觉得 swarm 不好听”。

命名争议背后，产品岗该问哪些用户认知问题？

素材中有人建议，如果要有趣，可以叫 flock of agents、pride of agents 或 party of agents，但别叫 swarm、murder 或 horde。这提醒产品岗：命名分歧往往不是审美分歧，而是对用户认知的假设不同。 延伸阅读：剪映CapCut 27秋招：字节系AI产品岗，值不值得冲？

面对分歧，优先核查三件事。一是用户会不会主动搜索这个词——如果用户搜的是旧词，新名字就要承担教育成本。二是跨团队沟通时，这个词会不会被误听、误写。三是它和现有产品词库是否冲突。

假设一个模拟场景：团队要把一个多智能体功能从内部代号改成对外名称，两个候选词各有支持者。此时不该投票，而应列出“谁在什么场合说这个词”的清单，再判断哪个词在最高频场景里最省力。这是思考方法，不是真实项目结论。

准备命名分析案例时，怎么避免只讲感觉？

素材里还有人调侃，甚至愿意接受一个 OpenAI 式的长名字当官方术语。这恰恰说明：名字的“正式感”和“好用”经常打架。面试中分析命名，要给出可核查的依据，而不是形容词。

可以准备三类依据：调用频率——用户多久说一次；搜索习惯——用户会怎么找它；沟通成本——跨团队转述时会不会变形。每类都对应一个可以向目标岗位核查的问题，比如“这个功能在用户侧最常出现在哪类界面文案里”。

一个实际可做的小建议：下次看到任何产品命名争议，别急着站队，先写下“谁、在什么场景、说出这个词”三栏，再判断。这个习惯比背结论更能帮你在面试里讲清楚。

本文中的命名讨论来自公开观点，不代表任何公司已采纳相关建议。