背景与问题定义
2026年3月6日，一篇标题为”LLM Doesn’t Write Correct Code. It Writes Plausible Code”的博客文章在 Hacker News 引发热烈讨论，截至目前已获得超过 200 个赞同。文章的核心观点并不复杂但极具冲击力：大型语言模型生成的不是”正确的代码”，而是”看似合理的代码”——这两者的区别可能在简单任务中不明显，但在复杂系统中足以造成严重故障。
这不是学术界第一次提出类似的观点。但这篇文章的特殊之处在于它来自一线开发者的实践经验分享，而非理论推导。文章作者是一个长期使用 LLM 进行编程的开发者，他详细记录了多次”代码看似正确但运行崩溃”的案例，并试图分析背后的原因。
理解 LLM 的这一本质局限，对于正确使用 AI 编程辅助工具至关重要。
核心机制拆解
语言模型的本质：下一个 token 预测
要理解为什么 LLM”写不出正确的代码”，需要回到大语言模型的本质训练目标。
所有现代 LLM 都是基于”下一个 token 预测”（Next Token Prediction）目标进行训练的。模型被喂入海量文本数据，任务是预测给定前文后下一个最可能出现的词元。这个目标函数本身不关心”正确性”，只关心”统计意义上的合理性”。
这意味着什么？模型学到的是”在给定上下文中，什么样的文本最可能出现”，而不是”什么是真正正确的”。这两个目标在大多数情况下是重叠的，但在某些场景下会产生显著差异。
“合理”与”正确”的区别
文章作者用了一个生动的比喻：这就像一个学生学习数学，他的练习册答案是”抄写”而非”计算”。在考试中，如果题目与练习册类似，他能写出完美答案；但一旦题目形式变化，他的”理解”就失效了。
具体到代码生成场景，这种差异表现为几种模式：
模式一：边界条件错误
def find_element(arr, target):
for i in range(len(arr)): # 正确：range(len(arr))
if arr[i] == target:
return i
return -1
# LLM 可能写成：
def find_element(arr, target):
for i in range(len(arr) + 1): # 错误：多遍历一位
if arr[i] == target:
return i
return -1
这段代码在大多数情况下能工作（当目标不在数组中时），但当目标存在于数组最后位置时会崩溃。
模式二：隐藏假设
LLM 常常做出未被明确说明的假设。比如假设输入总是有效的、假设不会有并发问题、假设文件总是存在。这些假设在训练数据中常见，但在特定业务场景中可能不成立。
模式三：表面正确的错误逻辑
# 用户要求：返回所有偶数
def get_evens(numbers):
result = []
for n in numbers:
if n % 2 == 0:
result.append(n)
else: # 不必要的 else 分支
continue
return result
这段代码功能上正确，但结构冗余。如果代码更复杂，这类”看似合理但多余”的逻辑可能悄然引入性能问题或难以调试的 bug。
为什么测试通过不等于代码正确
文章指出了一个更令人担忧的现象：LLM 生成的代码往往能通过测试，但测试本身可能不够全面。
在测试驱动开发（TDD）中，开发者会主动设计边界 case。但当开发者”信任 AI”时，他们更可能只运行基本的功能测试。LLM 生成的代码可能在 happy path 上表现完美，但在边界情况下失败。
更深层的问题是：即便测试失败了，开发者可能也难以理解失败原因——因为代码不是他们自己写的，逻辑链条不在他们的心智模型中。
实践价值与适用边界
LLM 编程适合什么场景
尽管存在上述局限，LLM 在以下场景中仍然非常有效：
样板代码生成 当需要生成标准化的代码模式（如 API 端点、CRUD 操作、常见数据结构）时，LLM 的表现通常很好。这些代码的模式在训练数据中出现频繁，模型”见过”大量正确实现。
代码翻译 将代码从一种语言翻译到另一种是 LLM 的强项。这不是”创造”，而是”转换”，LLM 在这类任务上表现稳定。
学习辅助 当开发者需要理解不熟悉的代码库时，让 LLM 添加注释、解释逻辑是有效的。它不会”创造错误理解”，因为它是在已有代码基础上进行解释。
LLM 编程不适合什么场景
关键基础设施 涉及安全、金融、医疗等高风险领域的代码，应该极度谨慎地使用 AI 生成。文章作者特别强调：绝不应该让 LLM 独立编写生产环境的核心逻辑。
新领域代码 当任务涉及开发者不熟悉的领域时，AI 生成的代码尤其危险。开发者无法有效验证代码的正确性，因为判断需要专业知识。
复杂系统设计 LLM 擅长生成”看起来对”的代码，但架构设计需要系统性的思考。AI 无法理解业务的完整上下文和约束条件。
实用的”人机协作”模式
基于以上分析，可以总结出更安全的 AI 编程工作流：
- AI 负责初稿，人负责验证：将 AI 生成的代码视为”第一稿”而非”最终稿”
- 测试先行：在让 AI 写代码之前，先明确测试 case——这迫使你思考边界条件
- 小步迭代：不要让 AI 生成大段代码，而是分步骤生成，每步验证
- 知识保留：即使使用 AI 辅助，最终也要确保自己理解代码逻辑
行业意义与启示
对 AI 编程工具开发者的启示
这篇文章在 Hacker News 上的热度表明，开发者社区对 AI 编程工具的认识正在从”崇拜”转向”务实”。
此前行业叙事过度强调”AI 将取代程序员”。但一线开发者的经验显示，这个论断至少在目前是过时的。AI 更像是”一个超级实习生”——可以快速产出，但需要资深工程师的指导和审核。
对于 AI 编程工具的开发者而言，这意味着单纯追求”生成更多代码”不是最优方向。更重要的是：
- 增强代码可解释性（让开发者理解 AI 为什么这样写）
- 集成更严格的测试和验证
- 明确告知用户代码的置信度
对教育体系的启示
如果 LLM 写不出”真正正确”的代码，那它还能用于编程教育吗？
一个可能的回答是：工具的价值不只在”产出”，也在”学习过程”。即便 AI 生成的代码有局限，让学习者分析”AI 为什么这样写”、”这样写有什么问题”本身也是一种学习。
对评估标准的启示
当前对 LLM 编程能力的评估主要看”通过率”——在 HumanEval、MBPP 等基准上答对多少题。但这些基准无法衡量”代码在实际部署中的可靠性”。
行业可能需要新的评估范式：不是看”能否跑通测试”，而是看”在复杂场景下是否仍然正确”。
参考来源
- Katanaquant Blog, “LLM Doesn’t Write Correct Code. It Writes Plausible Code”, 2026年3月6日
- Hacker News, “Discussion: LLM Code Quality”, 2026年3月7日
- Microsoft, “Code Generation with LLMs: Challenges and Best Practices”, 2026年