AI代码生成，上下文示例怎样写最有效？港科大最新

长久以来我们都知道在Prompt里塞几个好例子能让LLM表现得更好，这就像教小孩学东西前先给他做个示范。在Vibe coding爆火后，和各种代码生成模型打交道的人变得更多了，大家也一定用过上下文学习（In-Context Learning, ICL）或者检索增强生成（RAG）这类技术来提升它的表现。但您有没有遇到过这样的困惑：有时候给AI一个例子，它瞬间开窍，表现得像个天才；可换个例子，它又蠢得让人想砸键盘。这到底是为什么？来自香港科技大学的研究者们，通过一篇硬核论文，总算把这个“玄学”问题给整明白了。

AI代码生成的三大灵魂拷问

这些问题可能也正是您在使用AI生成代码时偶尔想过，但没有深究的问题。研究者们没有满足于“反正它就是能行”的模糊答案，而是像侦探一样，提出了三个直击要害的问题，试图彻底搞明白AI的学习机制：

• 问题一（RQ1）：在一份代码里，到底是什么特征（比如变量名、代码缩进、还是算法本身）对AI的帮助最大？

• 问题二（RQ2）：如果说命名很重要，那AI到底喜欢什么样的命名风格？是短小精悍的，还是详细冗长的？

• 问题三（RQ3）：AI能做到“举一反三”吗？给它一个相似问题的答案，它能从中受到启发，解决当前的问题吗？

一场精心设计的“代码破坏”实验

为了回答这些问题，研究者们设计了一个非常巧妙的实验，叫做“受控消融研究”（controlled ablation study）。这个很像中学物理的“控制变量法”，一次只改变一个条件，然后观察结果的变化。在这里，他们是拿一份“完美代码”作为基准，然后系统性地一次只“搞坏”它一个地方。

他们用来“搞坏”代码的工具，叫做“突变算子”（mutation operators），具体手法五花八门，但都很有针对性：

• 破坏命名特征：这是最狠的一招，把所有有意义的变量名，比如 user_name、total_price，全都换成 var0、var1、func0 这种毫无意义的符号。

• 破坏格式特征：把整齐的缩进和换行全部删掉，将代码压成一行天书；或者反过来，把代码打散成一个个独立的词元（Token）列表。

• 破坏实现细节：比如把 for 循环换成功能完全等价的 while 循环，或者干脆釜底抽薪，把整个代码逻辑用自然语言重新描述一遍，变成伪代码。

他们就是用这种方式，像做化学实验一样，精准地测试每一种代码特征对AI学习效果的影响，最终得出了相当有冲击力的结论。

值得一提的是，为了保证结论的普适性，研究者们还在 Python 和 Java 这两种主流编程语言上分别进行了测试，确保这些发现不是某种语言的“特例”。

发现一：命名就是王道

实验结果表明，在所有被“破坏”的特征里，有意义的标识符命名（尤其是变量名）简直是拥有碾压性的重要地位。当研究者把代码里那些清晰的变量名换成无意义的符号后，AI代码生成的正确率直接崩盘，性能最多时下降了足足30个百分点！相比之下，那些破坏代码格式（比如删除缩进）或者改变实现细节（比如循环方式）的操作，对AI性能的影响就小得多了。这说明，对于AI来说，代码里那些变量名、函数名所承载的语义信息，是它理解代码意图的最主要线索，远比代码长得好不好看、用的是哪种循环要重要得多。

发现二：AI喜欢什么样的命名？

既然命名这么重要，那AI到底喜欢什么样的命名呢？研究者发现对ICL（上下文学习）性能贡献最大的代码特征是有意义且语义准确的标识符命名（Meaningful and Semantically Precise Identifier Naming），尤其是变量名。

简单来说，就是变量、函数等的名字是否能清晰地表达出它们的用途。下面我们通过一个具体的例子来感受一下“好”的命名和“坏”的命名对LLM理解代码的巨大影响。

场景设定： 假设我们需要让LLM学习如何“计算购物车中所有商品加税后的总价”。

示例 A：好的ICL代码示例（使用有意义的命名）

def calculate_final_price(shopping_cart, tax_rate):
    """
    Calculates the total price of items in a shopping cart, including tax.
    """
    subtotal = 0
    # Calculate subtotal before tax
    for item in shopping_cart:
        item_price = item['price']
        quantity = item['quantity']
        subtotal += item_price * quantity

    # Calculate final price with tax
    total_price = subtotal * (1 + tax_rate)
    return total_price

# 示例数据
cart_data = [{'price': 10.0, 'quantity': 2}, {'price': 5.5, 'quantity': 3}]
sales_tax = 0.08

# 调用函数
final_cost = calculate_final_price(cart_data, sales_tax)

为什么这个例子对LLM“好”？

• 1.自解释性 (Self-Explanatory)：当LLM看到 subtotal, tax_rate, total_price 这些变量名时，它可以直接将这些词汇与其在海量训练数据中已经学到的概念（“小计”、“税率”、“总价”）联系起来。代码几乎是在用自然语言描述自己的逻辑。

• 2.提供强大上下文：shopping_cart 这个名字清晰地告诉LLM，我们正在处理一个与购物相关的场景。item_price 和 quantity 的组合也完全符合常识。LLM不需要去“猜”这些变量是干什么的。

• 3.易于学习和迁移：当LLM学习了这个高质量示例后，如果它接到一个新任务，比如“计算订单的总运费”，它就能从这个示例中学会处理价格、数量等模式，并能更好地在新任务中生成类似 shipping_fee 或 total_weight 这样有意义的变量。

示例 B：坏的ICL代码示例（使用模糊/无意义的命名）

这是论文中提到的“变量有序侵蚀 (Variable Ordered Erosion, VOE)”方法的体现，也是导致性能下降最多的罪魁祸首。

def do_calculation(data_list, rate_val):
    """
    Performs a calculation on a list of data.
    """
    temp_val = 0
    # Loop through data
    for entry in data_list:
        p = entry['p_val']
        q = entry['q_val']
        temp_val += p * q

    # Final calculation
    result = temp_val * (1 + rate_val)
    return result

# 示例数据
d = [{'p_val': 10.0, 'q_val': 2}, {'p_val': 5.5, 'q_val': 3}]
r = 0.08

# 调用函数
final_res = do_calculation(d, r)

为什么这个例子对LLM“坏”？

• 1.语义缺失 (Semantic Void)：变量名 temp_val, p, q, result 几乎没有提供任何有用的信息。p 和 q 可能是什么？价格？重量？坐标？LLM只能靠猜。

• 2.认知负担重 (High Cognitive Load)：为了理解 temp_val += p * q 这行代码，LLM必须纯粹依赖其数学和结构分析能力，而无法借助任何语义线索。它需要推断出这是一个累加求和的过程，但这个“和”代表什么，它并不清楚。

• 3.极易产生误解：当看到 result = temp_val * (1 + rate_val) 时，LLM可能会推断出 rate_val 是某种比率，但由于缺乏上下文，它可能会误解为“增长率”、“错误率”或“折扣率”，而不是“税率”。这种不确定性极大地增加了生成错误代码的风险。

也就是说LLM在学习代码时，很大程度上依赖于代码中的文本语义信息，就像人类阅读一样。一个好的变量名就像一个清晰的路标，直接告诉LLM代码的意图。而一个坏的变量名就像一块模糊不清的指示牌，迫使LLM在一个充满迷雾的逻辑迷宫中艰难探索，自然就很容易迷路和犯错了。

发现三：“反思”和“推理”能力有限

这个发现，可能对所有正在做RAG系统的工程师来说，是一个挺大的警醒。研究结果表明，如果您给AI一个问题的标准答案，它能很好地利用这些“直接信息”来解决问题，这就像一个会完美“抄作业”的学霸。但是…但是！如果您给它的是另一个“相似问题”的答案，哪怕解题思路几乎一样，希望能让它“举一反三”，结果是它不仅学不会，甚至还会被这些不完全匹配的信息严重干扰，表现得比不给任何示例（Zero-Shot）还要糟糕。

发现四：不同AI模型，“口味”也大不相同

您可能会好奇，这些结论是在哪些模型上验证的呢？研究者们选取了市面上几款主流的模型进行了测试，包括 GPT-4o-mini、Qwen系列（7B和32B），以及 DeepSeek-Coder。一个特别有价值的发现是，不同的模型在面对这些“被破坏”的代码时，表现出了非常不同的“性格”：

• 大力出奇迹型（Qwen-32B）：像Qwen-32B这样的大参数模型，展现出了极强的鲁棒性。不管研究者怎么折腾代码，它的性能都非常稳定，似乎在说：“这点小场面，影响不大。

• ”敏感依赖型（GPT-4o-mini, Qwen-7B）：这些相对小一些的模型，就显得比较“敏感”。当代码中的语义信息（尤其是命名）被拿走后，它们的性能下降非常明显，说明它们更依赖高质量、信息丰富的示例。

• 特立独行型（DeepSeek-Coder）：作为专门为代码优化的模型，DeepSeek-Coder的表现最出人意料。它在处理完美、格式规范的代码时，表现平平，甚至不如其他通用模型。但当代码的格式被破坏、信息被简化后（比如压成一行），它的性能反而相对更好了！这可能说明，这类专业模型在训练时接触了大量非标准、多样化的代码表示，导致了它独特的“口味”。

如何与AI更高效地协作？

基于这些发现，当您在开发和优化自己的AI产品时，有几件事真的可以立刻做起来：

• 重新审视您的RAG知识库：在您构建用于检索的代码库时，可以更关心代码的“命名质量”，不仅是代码多不多。一份充斥着 a,b,c 变量的代码库，对AI来说可能比没有还要糟糕，当ICL示例是目标问题的直接答案时，LLM能很好地利用它。但如果示例是另一个相关问题的答案（即使解题思路相似），LLM不仅无法受益，甚至可能被这些“噪音”信息干扰，导致性能比不提供任何示例（Zero Shot）还要差。

• 合理管理对AI的期望：目前的LLM在逻辑推理和知识迁移上还有很大的局限性。指望它能从一些蛛丝马迹中领悟您的复杂意图，目前可能还有点难，给它的上下文示例，一定要尽可能地直接、清晰、高质量。

写在最后

我们总想着去追寻更复杂的模型、更花哨的Prompt技巧，但也许提升AI代码能力最有效的方法，恰恰是回归到我们学习编程的第一课：写干净、可读的代码，起有意义的名字。编写人类和AI都能轻松理解的代码即拥有极高语义清晰度的代码已不再仅仅是提升团队协作效率的“软技能”，而是决定AI辅助开发工具能否发挥其最大潜力的“硬性技术要求” 。在所有代码特征中，清晰的变量和函数命名拥有绝对的优先权。总结就是，语义！语义！还是语义！

文章来自于微信公众号“AI修猫Prompt”。