VicroCode
让代码创造价值
VicroCode是一个轻量级代码在线发布、交易平台,开箱即用,免部署、免服务器、免备案,支持接入智能体、通用管理系统、游戏等多种项目
稍候片刻,您可先学习AI编程手册
正在加载中...

AI MARKET GUIDE

变量命名对AI编程有多大影响?我用一段全是tmp的代码试出来了

我一开始不信命名会影响AI生成质量,直到把一段变量名全是tmp、res、x的代码丢给它改,它反复猜错、越改越崩。命名不是给人看的洁癖,而是喂给模型的上下文。这篇讲我怎么把好命名和坏命名的同一段逻辑各跑一遍做对比,直观看差异,也顺带聊聊这件小事背后的商业价值。

起因:我本来觉得这是洁癖

上周我在改一段老脚本,逻辑不复杂,就是读一批订单数据、过滤、算个汇总。原作者的命名相当随性,变量全是 `tmp`、`res`、`x`、`d1`、`d2`,函数叫 `do_it`、`handle`。

我懒得自己读,直接把它丢给 AI,让它加一个按日期分组的功能。

结果它改了三版都不对。第一版它把 `res` 当成了结果列表,其实那是个中间变量;第二版它以为 `d1` 是日期,实际上是折扣;第三版干脆开始自作主张重写整个函数,把我原来的逻辑改没了。

我盯着屏幕,第一反应是模型今天犯傻。

但我停下来想了想——V2EX 上正好有个讨论说,代码里的变量、函数、类型名字会被模型做 embed 和 attention,所以“取个给机器看的好名字”到底有没有用。当时我觉得这是个奇思妙想的话题,没往心里去。

现在被 AI 反复猜错折磨了半小时,我突然觉得这事没那么虚。

我的判断:名字就是你喂给模型的上下文

说白了,AI 读你的代码,靠的就是这些符号本身携带的语义。 `tmp` 这个词对模型来说几乎是零信息,它只能从上下文里反推你到底想干嘛,反推错了就往错的方向猜。

而 `filtered_orders`、`daily_revenue` 这种名字,本身就把意图说清楚了,模型一眼就懂,不用猜。

那条讨论里有人回了一句我觉得特别对:语义清晰很重要,代码要自解释,符合一眼看过去的直觉。这句话过去是说给人听的——让同事少骂你几句。

但在 vibe coding 的场景下,这句话的第一读者变成了模型。你名字起得含糊,模型就跟一个不熟悉项目的新人一样,得靠猜;你名字起得准,它一次就懂你要什么。

我的观点很直接:命名不是洁癖,是你在免费给模型补充上下文。这部分上下文不花 token,不占提示词长度,却实打实影响生成质量。

这买卖太划算了。

别空谈,我把两版代码各跑了一遍

光讲道理没意思,我干脆做了个对比实验,你也可以照着复现。

我准备了同一段逻辑的两个版本。坏版本长这样,全是缩写:

def do_it(l):
    r = []
    for x in l:
        if x['s'] == 1:
            t = x['p'] * x['q']
            r.append({'d': x['dt'], 'v': t})
    return r

好版本逻辑一模一样,只改了名字:

def calc_paid_order_amount(orders):
    results = []
    for order in orders:
        if order['status'] == 1:  # 1 表示已支付
            amount = order['price'] * order['quantity']
            results.append({'date': order['order_date'], 'amount': amount})
    return results

然后我给 AI 出了同一个需求:在这个基础上加一个“按日期汇总每天的总金额”的函数。你可以把这两段分别丢进Python在线运行里,先确认两版跑出来的结果完全一致,排除逻辑差异,然后再各自让 AI 续写,看它给出的代码质量差多少。

我自己试下来,坏版本那次,AI 又开始纠结 `x['s']` 到底是啥、`t` 是不是总额;好版本这次它几乎没废话,直接写了个 `summarize_by_date`,字段名也顺着我的风格来。这个差异不是玄学,你自己在线跑这段代码对比一遍就服气了,比看十篇规范文档都直观。

为什么我建议你亲手跑一遍,而不是记结论

因为“命名影响 AI”这句话,你光听是没感觉的,只有当你看到同一个模型、同一个提示词,就因为变量名不同而给出天差地别的结果时,你才会真的改掉随手写 `tmp` 的习惯。

这里我要标一句待核实:命名对不同模型、不同任务的具体影响程度有多大,我没有系统数据,那条讨论里也提到“估计有相关论文”,但我没去查证,所以别把我上面的单次观察当成普适结论。我能确定的只是——在我这几次实验里,好命名确实让 AI 更省心。

你要用,就自己在环境里多跑几组,看你自己项目里的真实差异。

这件小事,其实是个被低估的效率杠杆

我想把话题拉远一点。现在招聘市场对“会用 AI 工具提效”的要求越来越硬——有的岗位直接把熟练使用 Cursor、Claude Code 这类 AI 编码工具写进任职要求,还要求你能沉淀可复用的 prompt 和工作流。

大家都在拼怎么把 AI 用得更快。

但很多人只盯着换更强的模型、买更贵的额度,却忽略了命名这种几乎零成本的输入优化。社区里甚至有人吐槽某些中转站让 AI 在项目里反复瞎翻、死循环读文件,烧钱烧时间。

模型侧的坑当然存在,可你自己代码里的命名混乱,同样会让 AI 多绕路、多猜错、多返工,这部分成本是你自己制造的。

对独立开发者和小团队来说,这里的商业逻辑很清楚:你用 AI 写代码,本质是在为每次生成买单,无论是时间还是额度。让模型少猜一次,就是省一次成本。

好命名不需要你多花钱,只需要你写的时候多想两秒。这是我见过投入产出比最高的习惯之一。

今天就能做的一个小动作

别急着改整个项目。就找你手上最近一段让 AI 反复改不对的代码,把里面所有 `tmp`、`res`、`x` 这类名字换成能说清意图的,然后把改名前后两版分别丢进在线环境,用同一个需求让 AI 各续写一遍,对比结果。

跑完你自己判断,值不值得从今往后认真起名。我打赌你会。