LLM不生成正确代码而是生成看似合理的代码

基本信息

作者: dnw
评分: 37
评论数: 27
链接: https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code
HN 讨论: https://news.ycombinator.com/item?id=47283337

导语

大型语言模型在编程领域的表现令人印象深刻，但开发者常误以为其生成的代码可以直接用于生产环境。本文指出，模型本质上是基于概率预测下一个 token，因此它生成的是“看似合理”而非逻辑正确的代码。理解这一局限性对于构建稳健的工作流至关重要，阅读本文将帮助你重新审视 AI 辅助编程的边界，并学会如何更安全地评估与使用模型生成的代码。

以下是对文章《An LLM doesn’t write correct code, it writes plausible code》（大模型不编写正确的代码，它编写看似合理的代码）的深入评价。

一、核心观点与逻辑架构

中心观点： 大语言模型（LLM）本质上是基于概率的“合理续写”机器，而非逻辑推理引擎，因此其生成的代码在语法上可能完美且逻辑上看似通顺，但并不保证在语义层面是正确或安全的。

支撑理由：

概率生成的本质：LLM 的核心机制是预测下一个 Token，它追求的是训练数据分布中的“最大似然”，即“这段代码看起来像什么”，而不是“这段代码运行结果是什么”。
表象与语义的割裂：模型对代码的理解停留在句法和统计相关性上（变量名、常见模式匹配），缺乏对底层执行环境的真实反馈机制，容易产生“幻觉”。
上下文窗口的局限：LLM 难以处理超长依赖或跨越多个文件的复杂系统架构，导致它在处理大型项目时，虽然局部代码看起来很合理，但全局逻辑可能断裂。

反例/边界条件：

形式化验证辅助：当 LLM 被集成到带有形式化验证工具（如 Lean、Coq）的闭环中时，其生成的“合理代码”可以被快速证伪或修正，此时它逼近了“正确代码”。
低复杂度与高重复度场景：对于标准化的 CRUD 操作或高度重复的脚手架代码，训练数据中的“正确模式”占绝对主导地位，此时“合理”往往等同于“正确”。

标注：

事实陈述：LLM 基于 Transformer 架构，通过最大化概率预测下一个词元。
作者观点：LLM 生成的代码应被视为“看似合理”而非“正确”，需要人工严格审查。
你的推断：随着模型规模增大和推理技术的引入（如 o1 的思维链），模型在逻辑推理上的“正确率”会提升，但只要是基于概率生成，其根本的“幻觉”属性就无法根除。

二、多维度深入评价

1. 内容深度：从表象到本质的洞察

文章切中了当前 AI 编程助手最核心的痛点——“置信度陷阱”。许多开发者被代码的流畅性和语法的正确性所迷惑，误以为逻辑也是正确的。

论证严谨性：文章将代码生成定义为“ plausible completion”（合理续写），这在认知心理学层面解释了为什么人类容易被 AI 误导——我们习惯于补全认知，而 AI 的输出恰好迎合了这种直觉。
深度分析：真正的深度在于指出了**“编译通过”与“逻辑正确”之间的巨大鸿沟**。LLM 擅长模仿人类专家的“语气”和“结构”，但这并不等同于具备了专家的“模型思维”。

2. 实用价值：重塑开发者的工作流

这篇文章对实际工作具有极高的指导意义，它是一剂清醒剂，防止团队盲目依赖 AI。

指导意义：它要求开发者转变角色，从“代码编写者”变为“代码审计者”。
风险控制：在金融、医疗等高风险领域，明确“Plausible ≠ Correct” 是避免灾难性后果的关键。它提醒我们，AI 生成的单元测试可能本身也是错误的，因为它同样是在“合理地模仿测试代码”，而不是在验证逻辑。

3. 创新性：概念的重构

新观点：文章没有停留在“AI 会犯错”这种陈词滥调上，而是引入了软件工程中 “Spaghetti Code”（意大利面代码/乱麻代码） 的概念，指出 AI 倾向于生成看似整洁实则难以维护的代码，甚至可能引入微妙的 “Hallucinated Imports”（幻觉导入），即引用不存在的库或方法，这是极具破坏力的创新性观察。

4. 可读性与逻辑性

文章逻辑清晰，术语使用准确。它成功地将复杂的机器学习原理（概率分布）与具体的软件开发实践（Debug、Code Review）联系起来。这种跨学科的表达方式非常适合技术读者理解 AI 的局限性。

5. 行业影响：推动“AI 原生开发”范式的变革

这篇文章可能会成为推动开发工具革新的催化剂：

测试驱动开发（TDD）的回归：为了验证 AI 的“合理代码”是否“正确”，开发者必须先编写严格的测试用例。
静态分析工具的崛起：行业将更加依赖 AST（抽象语法树）分析和符号执行工具来捕获 AI 引入的逻辑错误，而不仅仅是 Lint 语法错误。

6. 争议点与不同观点

争议点：文章可能过于悲观地低估了 LLM 的逻辑推理能力。随着 OpenAI o1 等模型的发布，模型在生成代码前会进行“慢思考”和自我反思，这在一定程度上弥补了单纯概率预测的缺陷，使得代码的“正确率”显著提升。
反方观点：部分学者认为，只要 RLHF（人类反馈强化学习）做得足够好，模型最终会收敛到逻辑正确性上，因为“正确”本身就是训练数据中的一种高概率特征。

7. 实际应用建议

基于文章观点，建议在实际工作中采取以下策略：

零信任策略：将 Copilot/Cursor 等工具视为“初级实习生”，其输出必须经过

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# 示例1：处理文件读取异常
def safe_file_reader(file_path):
    """
    安全读取文件内容，处理常见异常
    参数:
        file_path: 文件路径
    返回:
        文件内容或错误信息
    """
    try:
        with open(file_path, 'r', encoding='utf-8') as f:
            return f.read()
    except FileNotFoundError:
        return "错误：文件不存在"
    except PermissionError:
        return "错误：没有读取权限"
    except UnicodeDecodeError:
        return "错误：文件编码问题"
    except Exception as e:
        return f"未知错误: {str(e)}"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 示例2：安全的API请求函数
def safe_api_request(url, params=None, timeout=10):
    """
    发起安全的HTTP请求，处理各种异常情况
    参数:
        url: 请求URL
        params: 请求参数
        timeout: 超时时间(秒)
    返回:
        响应数据或错误信息
    """
    import requests
    
    try:
        response = requests.get(url, params=params, timeout=timeout)
        response.raise_for_status()  # 检查HTTP错误
        return response.json()
    except requests.exceptions.Timeout:
        return "错误：请求超时"
    except requests.exceptions.ConnectionError:
        return "错误：连接失败"
    except requests.exceptions.HTTPError as e:
        return f"HTTP错误: {str(e)}"
    except ValueError:
        return "错误：响应不是有效的JSON"
    except Exception as e:
        return f"未知错误: {str(e)}"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
# 示例3：安全的数值计算函数
def safe_division(a, b):
    """
    安全的除法运算，处理各种异常情况
    参数:
        a: 被除数
        b: 除数
    返回:
        计算结果或错误信息
    """
    try:
        result = a / b
        return round(result, 2)  # 保留两位小数
    except ZeroDivisionError:
        return "错误：除数不能为零"
    except TypeError:
        return "错误：参数必须是数字"
    except OverflowError:
        return "错误：数值过大"
    except Exception as e:
        return f"未知错误: {str(e)}"

案例研究

1：某大型金融科技公司的风控系统重构

背景: 该公司正在重构其核心信贷风控系统，需要将旧的遗留逻辑迁移至新的微服务架构。由于业务逻辑极其复杂且涉及大量特殊的历史遗留规则，部分原始开发者已离职，文档缺失。

问题: 团队使用 LLM（如 GPT-4）根据遗留代码和简短的注释生成新系统的 Python 数据处理脚本。LLM 生成的代码语法完美，逻辑通顺，能够处理常规的信贷申请数据。然而，在上线前的灰度测试中，风控团队发现该代码在处理“部分还款且含逾期罚息”的极端边缘案例时，逻辑与旧系统不一致。LLM 编写的是“看似合理”的代码——它按照常见的金融逻辑进行了推断，但并未遵循该公司特有的、非标准的十年前定下的业务规则。

解决方案: 团队不再将 LLM 视为最终代码的生成者，而是将其视为“翻译助手”。开发流程调整为：由 LLM 生成框架代码，随后必须由资深开发人员对涉及资金计算的核心逻辑进行逐行人工审查。同时，引入了基于旧系统历史数据的对比测试用例，强制要求新代码在所有边缘案例上的计算结果与旧系统完全一致，否则无法通过 CI/CD 流程。

效果: 通过这种“人机协同”的模式，代码迁移效率提升了 40%，但避免了因逻辑偏差可能导致的数千万美元的资金风险敞口。项目成功上线，且未发生一起因代码逻辑错误导致的坏账。

2：某医疗科技初创公司的辅助诊断算法

背景: 该公司致力于开发辅助医生进行皮肤癌筛查的 AI 应用。为了加快研发进度，工程团队尝试使用 LLM 来编写图像预处理和特征提取的底层代码。

问题: 开发人员要求 LLM 编写一段用于对皮肤病变图像进行归一化处理的代码。LLM 生成了一段使用了常见医学图像处理库的代码，代码运行流畅，没有任何报错，且在公开的数据集上表现良好。然而，在一次内部审计中，首席科学家发现，LLM 在代码中默认使用了一个特定的颜色空间转换常数。这个常数对于普通照片是“合理”的，但对于医疗级的高光谱皮肤图像，它会引入微小的像素偏差。这种偏差在肉眼看时是“合理”的图像，但在后续的病理分析中会导致误诊率的上升。

解决方案: 公司规定，所有涉及医疗数据处理的算法逻辑，严禁直接使用 LLM 生成的实现。LLM 仅被允许用于编写单元测试框架、数据管道的胶水代码以及文档生成。核心算法必须由专业算法工程师手写，并经过双重验证。

效果: 虽然放弃使用 LLM 编写核心逻辑略微延长了开发周期，但确保了算法的临床准确度。该产品最终通过了医疗器械监管机构的认证，因为其代码逻辑是完全可解释且经得起推敲的，而非仅仅是“看起来能跑”的黑盒。

3：某电商平台的促销活动配置引擎

背景: 在“双十一”大促前夕，该电商平台急需为一个新上线的营销活动开发一个复杂的优惠券计算引擎。时间紧迫，开发压力巨大。

问题: 后端工程师利用 LLM 快速生成了折扣计算的代码逻辑。代码结构清晰，变量命名规范，涵盖了满减、折扣叠加等逻辑。然而，当活动上线并在流量高峰期运行时，系统突然抛出异常。经排查，LLM 生成的代码在处理高并发下的浮点数精度问题时，使用了简单的四舍五入方式。这在单机测试时是“合理”的，但在分布式环境下，由于订单分片计算，导致部分用户的总金额出现了 0.01 元的误差，进而触发了底层的财务对账报警。

解决方案: 运维团队紧急回滚，并重新编写了该模块。事后，团队建立了严格的代码规范：所有涉及金额计算的代码，禁止直接由 LLM 生成，必须使用公司内部封装的、经过验证的金融类库。LLLM 只能用于生成非核心业务的 CRUD（增删改查）接口或前端展示组件。

效果: 虽然修复过程导致了短暂的系统抖动，但及时止损避免了更大的财务混乱。该案例成为了公司内部培训的经典教材，用以警示工程师：LLM 写的代码在语法上是正确的，但在业务严谨性上是不可信的。

最佳实践

最佳实践指南

实践 1：建立严格的验证与测试机制

说明: LLM 生成的代码看起来逻辑通顺且符合语法，但可能包含隐藏的逻辑错误、边界条件漏洞或使用了不存在的库函数。必须假设代码在首次生成时是不可靠的，通过自动化测试来验证其正确性。

实施步骤:

在提示词中明确要求生成配套的单元测试用例。
将生成的代码集成到 CI/CD 流程中，运行现有的测试套件。
对于关键业务逻辑，必须进行人工代码审查。
利用沙箱环境运行代码，检测是否存在安全风险或性能问题。

注意事项: 即使 LLM 声称代码已通过测试，也不要轻信，必须在本地环境中重新执行测试。

实践 2：实施渐进式提示策略

说明: 一次性要求 LLM 生成复杂的系统或长函数往往会导致错误累积。通过将任务拆解为小的、具体的步骤，可以逐步引导 LLM 生成更准确的代码，并在每一步进行纠偏。

实施步骤:

将复杂的编码任务分解为多个子任务（如：先写数据结构，再写核心逻辑，最后写接口）。
每次只针对一个子任务向 LLM 提问。
检查每一步生成的代码，确认无误后，再将上下文传递给 LLM 进行下一步开发。
如果发现错误，立即在对话中指出，不要等到最后。

注意事项: 保持上下文的连贯性，确保 LLM 理解前序步骤的意图和变量定义。

实践 3：明确上下文与约束条件

说明: LLM 倾向于基于常见的训练数据（通常是通用的、过时的）编写代码。如果不提供具体的上下文（如技术栈、版本号、依赖库），生成的代码可能无法在现有环境中运行。

实施步骤:

在提示词中明确指定编程语言版本（例如：Python 3.10 vs 3.8）。
列出必须使用的库及其版本限制，或者禁止使用的库。
提供相关的代码片段或项目结构图，让 LLM 理解其代码需要嵌入的位置。
明确代码的运行环境（如：浏览器端、服务器端、嵌入式设备）。

注意事项: 避免模糊的指令，例如“写一个高效的排序函数”，而应说“在内存受限的情况下，对整数数组进行排序”。

实践 4：优先生成伪代码或架构设计

说明: 直接生成可执行代码容易陷入细节错误的泥潭。先让 LLM 输出伪代码、流程图或架构设计，有助于在逻辑层面验证思路的正确性，避免在错误的实现上浪费时间。

实施步骤:

第一步要求 LLM 仅输出算法逻辑或伪代码。
人工审查逻辑流程，确认其符合业务需求。
第二步要求 LLM 基于确认的伪代码生成特定语言的具体实现。
对比生成的代码与伪代码，确保实现没有偏离设计。

注意事项: 伪代码应包含关键步骤和变量声明，而不仅仅是自然语言描述。

实践 5：保持对幻觉的警惕与事实核查

说明: LLM 经常会“发明”不存在的函数、属性或 API。这种现象被称为幻觉。开发者必须熟悉常用的标准库，或者具备查阅文档的能力，以识别这些虚构的代码。

实施步骤:

对生成的代码中不熟悉的 API 或函数调用保持怀疑。
复制关键函数名到官方文档或搜索引擎中进行验证。
要求 LLM 提供 API 文档的来源或链接（虽然它可能编造链接，但这是排查线索）。
使用 Linter 或静态分析工具检查代码，标记出未定义的符号。

注意事项: 特别注意那些看起来“完美契合”你需求但极其冷门的函数，这通常是幻觉的高发区。

实践 6：建立人机协作的编码工作流

说明: LLM 是副驾驶，人类是机长。最佳实践是将 LLM 作为辅助工具来处理重复性、模板化或探索性的代码编写，而由人类负责把控整体架构、安全性和最终决策。

实施步骤:

使用 LLM 生成样板代码、正则表达式或复杂的 SQL 查询语句。
使用 LLM 解释晦涩的旧代码或报错信息。
人类开发者编写核心业务逻辑和关键的安全模块。
定期对 LLM 生成的代码进行重构，以符合团队特定的代码规范。

注意事项: 不要盲目复制粘贴代码，必须理解每一行代码的作用，即使它是生成的。

学习要点

基于对“LLM 编写的是看似合理的代码而非正确代码”这一核心观点的深度分析，总结如下：
LLM 的核心机制是概率预测，它生成的是基于训练数据统计规律的“看起来像”代码，而非经过逻辑验证的代码。
“看似合理”与“正确”之间存在本质区别，代码可能通过编译、逻辑通顺，但包含隐蔽的边界错误或安全漏洞。
人类开发者必须从“代码编写者”转变为“代码审查者”，具备阅读和验证 AI 生成代码的能力比直接编写代码更重要。
仅依赖 LLM 无法保证软件工程的可靠性，必须引入严格的单元测试、集成测试以及静态分析工具作为质量兜底。
LLM 擅长处理样板代码和重复性语法，但在处理复杂业务逻辑、算法优化或冷门领域知识时容易出现“一本正经胡说八道”的幻觉。
在使用 LLM 辅助编程时，应优先关注其提供的思路和框架，而非直接复制粘贴未经审查的实现细节。

常见问题

1: 为什么说大语言模型（LLM）生成的代码只是“看似合理”，而不是“绝对正确”？

A: 这是由大语言模型的基本工作原理决定的。LLM 本质上是一个概率预测引擎，而非逻辑推理机或编译器。它是根据训练数据中数以亿计的代码片段，预测下一个最可能出现的字符或 Token。

当模型编写代码时，它是在模仿人类程序员在类似上下文中通常会写出的代码结构、语法和命名模式。因此，生成的代码在语法上通常是完美的，变量命名也很专业，逻辑流程看起来也非常顺畅（这就是“看似合理”）。然而，模型并不真正“理解”代码的执行逻辑，也没有在内部运行过这段代码。它只是基于统计规律拼凑出答案，因此无法保证代码在逻辑上是无误的，或者在所有边界条件下都能正确运行。

2: 既然代码看起来没问题，直接运行通常也能通过，为什么还需要警惕这种“看似合理”的特性？

A: 这种特性最大的危险在于它会产生“隐蔽的错误”。与代码完全跑不通（语法错误）不同，“看似合理”的代码可以成功通过编译并运行，但可能会输出错误的结果、引入安全漏洞或导致系统在特定的高负载或边缘情况下崩溃。

这种代码极具欺骗性，因为它看起来非常专业，甚至可能包含详细的注释。开发者（尤其是初级开发者或对该领域不熟悉的专家）很容易产生虚假的安全感，跳过严格的 Code Review（代码审查）或测试环节，直接将其部署到生产环境中。这种“隐性 Bug” 往往比显性 Bug 更难调试，也更危险。

3: 在使用 LLM 辅助编程时，如何识别并防范这种“看似合理”的错误代码？

A: 防范这种风险需要建立严格的验证流程，不能盲目信任模型生成的输出：

编写单元测试：这是最有效的手段。在生成代码后，必须编写覆盖正常路径、边界条件和异常情况的测试用例。
严格的 Code Review：不要将 AI 视为资深架构师，而应将其视为实习生。必须逐行检查其逻辑，确保它不仅仅是“看起来像代码”，而是真正实现了业务逻辑。
理解代码逻辑：如果你无法读懂生成的代码，就不要使用它。你需要有能力判断代码在做什么，而不是仅仅复制粘贴。
使用小模型验证：对于关键逻辑，可以使用代码解释器或让模型自我解释代码的执行路径，以发现逻辑漏洞。

4: LLM 生成“看似合理”但错误的代码，通常有哪些具体的典型表现？

A: 常见的错误模式包括：

幻觉产生的 API：模型自信地调用了一个不存在的库函数或方法，或者使用了错误的参数，仅仅因为这在训练数据的统计上是常见的组合。
微妙的逻辑错误：例如在循环中使用了错误的终止条件（差一错误），或者在处理并发、异步操作时遗漏了锁机制。
缺乏上下文感知：模型可能生成了在当前文件或项目中无法运行的代码，因为它假设存在某些并未定义的变量或辅助函数。
安全漏洞：代码可能功能正常，但包含了 SQL 注入风险或硬编码的密钥，因为模型并不具备安全审计的意识。

5: 这种“看似合理”的特性是否意味着 LLM 在编程领域没有实用价值？

A: 绝对不是。虽然它不保证正确性，但 LLM 仍然是极其强大的生产力工具。它极大地降低了编程的门槛，能够快速生成样板代码、提供 API 使用建议、帮助重构代码以及解释复杂的逻辑。

关键在于**“人机协作”的模式转变**：开发者的角色从“代码编写者”转变为“代码审查者和架构师”。LLM 负责快速产出“看似合理”的草稿，而人类负责验证其正确性、修补逻辑漏洞并确保系统安全。只要保持怀疑态度并进行严格测试，LLM 能显著提升开发效率。

6: 为什么 LLM 在解决简单的编程问题时表现很好，但在复杂系统中容易写出“看似合理”的错误代码？

A: 简单的编程问题（如反转字符串、二分查找）在训练数据中出现的频率极高，且逻辑模式非常固定。模型已经对这些模式进行了过拟合，因此能生成高度准确的代码。

然而，复杂系统涉及深层的上下文依赖、跨文件的模块交互以及特定的业务约束。LLM 受限于上下文窗口大小，无法完全理解整个项目的全貌，且训练数据中完全匹配当前复杂特定场景的样本较少。在这种情况下，模型更多是依靠概率去“拼凑”解决方案，这种拼凑出来的代码虽然语法通顺，但往往无法精确契合复杂的业务逻辑或系统架构，从而导致错误。

7: 随着 LLM 技术的发展，未来能否解决“只写看似合理代码”的问题，直接生成“正确代码”？

A: 这是一个正在快速发展的领域。目前的改进方向包括：

引入编译器反馈：让模型在生成代码后自动编译，如果报错则利用

思考题

## 挑战与思考题

### 挑战 1: 代码逻辑的“直觉陷阱”

问题**: 请尝试使用大语言模型生成一个简单的 Python 函数，用于判断一个整数是否为素数。要求生成的代码包含明显的逻辑错误（例如错误的边界条件或算法逻辑），然后手动修正这段代码，并记录下 LLM 生成的原始代码与你修正后的代码之间的具体差异。

提示**: 重点关注 LLM 在处理循环范围（如 `range` 函数）或取模运算时的常见失误，思考为什么 LLM 会认为这些错误的代码在语法上是“看起来正确”的。

引用

原文链接: https://blog.katanaquant.com/p/your-llm-doesnt-write-correct-code
HN 讨论: https://news.ycombinator.com/item?id=47283337

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：大模型 / AI 工程
标签： LLM / 代码生成 / 幻觉 / 调试 / AI 编程 / 软件工程 / 代码质量 / Copilot
场景：大语言模型 / AI/ML项目

大语言模型成为新型高级编程语言
LLM成为新型高级编程语言
大语言模型成为新一代高级编程语言
超越智能体编码：AI 编程助手的演进方向
超越智能体编码：AI 编程助手的演进方向 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

LLM不生成正确代码而是生成看似合理的代码