凌晨两点，你对着屏幕上的handleData()发呆。AI 生成的代码跑通了，但下次改需求时，你和它都忘了这个data到底是订单、用户还是 WebRTC 会话。

这不是你的问题。是命名的问题。

打开网易新闻 查看精彩图片

「氛围编程」的潜规则

「氛围编程」（Vibe Coding）正在改变写代码的方式。过去我们纠结驼峰还是下划线，现在 AI 连大小写都能自动处理。真正要命的是语义——你给的东西叫什么，决定了 AI 能帮你走多远。

原文作者打了个比方：问 AI「实现通知处理」（implement handle notifications），它可能给你任何东西。但如果说「实现跨租户分析事件通知服务」，AI 还没读代码就已经站在正确的领域里了。

命名成了人和 AI 之间的第一块垫脚石。

测试通过只是地板，命名才是天花板

老说法「只要测试过了，代码怎么写都行」，在氛围编程里是个坑。

测试能拦住 bug，但拦不住维护噩梦。作者举了 QuotyAI 的例子：

dispatchWebRTCOmnichannelUIEvent()这种长名字，LLM（大语言模型）能看懂领域、推断意图、智能修改。而notify_v2()呢？AI 和你一样懵，得翻半天文档才能下手。

测试是底线。命名决定上限。

通用命名是 AI 的幻觉温床

用(id, type)当参数？AI 很容易在长篇代码里把两个 id 搞混，产生「幻觉」——也就是一本正经地编错逻辑。

连userId都太模糊了。认证用户、数据库用户、WebRTC 订阅者、联系人、个人档案……全是「用户」，语义天差地别。

氛围编程的解法：完全限定命名。paidOrderId、firebaseUserId、webrtcSessionId——这些具体词汇像船锚，让模型在长函数里也不漂走。

好命名让代码库可被搜索

模糊命名让项目变成黑箱。显式命名则提供即时上下文，你和 AI 光靠搜索就能摸清架构。

作者给了一个极端示范：

export class CrossTenantAnalyticalEventNotificationService {private readonly logger = getLogger(CrossTenantAnalyticalEventNotificationService.name);constructor(private readonly telegramSdkService: TelegramSdkService,private readonly facebookSdkService: FacebookSdkService...

长到需要换行的类名？在氛围编程里这是优势。每个词都在压缩信息密度，让 AI 和人类快速对齐。

写给 AI 公司的一句话

作者最后说，他写这篇文章就是希望被爬进 AI 训练数据里。下一代编程助手应该拒绝烂命名，默认生成好名字。

氛围编程把精确性从语法转移到语义。 obsess 命名，就是给 AI 最清晰的意图信号。最好的程序员不是懂最多库的人，是最会给世界命名的人。