如果你是一名程序员，最近一两年肯定被各种 AI 编程工具刷屏了。从 GitHub Copilot 到 Cursor，到今年国内出的 Trae，以及最近发布的为提升 AI 编程效率而生的 Claude Code，还有国内的通义灵码等等，简直让人眼花缭乱。
身边不少同事和朋友都已经用上了，有人说效率翻倍，有人说就是个高级的代码补全。在网上也看到许多争论，如程序员会不会被 AI 取代等等话题。
作为一个在一线写了十多年代码的人，我想聊聊自己的观察和思考。这篇文章不是要唱衰 AI，也不是要贩卖焦虑，而是想分析一下当前 AI 编程的真实情况。
今天主要聊两块：LLM 的固有局限、这些局限在编程领域的具体表现，应对策略我们下一篇文章再聊。
1. LLM 的天生缺陷
要理解 AI 编程的问题，得先搞清楚底层的大语言模型（LLM）有哪些局限。这些局限不是某个产品的 bug，而是当前技术架构的固有特性。
1.1 概率预测的本质
LLM 说到底是个概率模型。它的工作原理是根据上下文，预测下一个最可能出现的词。注意，是「最可能」，不是「最正确」。
这就像一个特别会察言观色的人，能根据前面的对话猜出你想听什么，但他并不真正理解你们在聊什么。大部分时候猜得挺准，偶尔也会离谱到家。
在写作、聊天这种场景下，这种「猜测」问题不大，甚至还能带来一些创意。但在编程这种需要 100% 精确的领域，问题就来了，这就是我们所说的 LLM 的幻觉。
以编程为例，AI 可能会「发明」一个当前环境中并不存在的库函数，或者一本正经地告诉你某个框架有某种你从未听说过的特性。例如，你让它用一个小型库 mini-lib 写个功能，它可能会自信地写下 mini-lib.complex_function()，而这个函数实际上只存在于它通过模式匹配「幻想」出的世界里。这种随机性在创意写作中是火花，但在编程中就是地雷。一个分号、一个等号、一个大于号的随机错误，都可能导致程序编译失败、运行崩溃或产生灾难性的计算错误。
LLM 的本质是一个概率预测引擎 ，而不是一个事实检索数据库。它的核心任务是基于海量训练数据，「猜」下一个 token 是什么最合理，而不是「下一个 token 是什么最真实」。它的训练数据中包含了海量的代码和文档，当它发现很多库都有 .complex_function() 这种模式时，它就会推断 mini-lib 可能也有，从而生成一个语法通顺但功能无效的代码。它追求的是「看起来对」，而不是「真的对」。
1.2 知识的时间窗口
训练一个大模型需要几个月时间和巨额成本，所以模型的知识总是滞后的。比如 Claude 的知识截止到 2025 年 1 月，那么 2 月份发布的新框架、新 API，它就完全不知道。
对于技术更新速度极快的编程领域，这是个大问题。React 19 出了新特性，Node.js 又发布了新版本，某个常用库爆出了安全漏洞......这些信息，AI 都无法及时获取。
虽然可以通过 RAG/Agent 等技术缓解，但这更像是在给一个旧大脑外挂一个「实时信息提示器」，而非大脑本身的更新。
对于技术迭代比翻书还快的软件开发领域，依赖一个「活在过去」的工具，无异于拿着旧地图在新世界航行。更危险的是，它可能会自信地推荐一个已经停止维护、或者已知存在 CVE 的第三方依赖库，从而出现安全隐患。
1.3 上下文窗口限制
这个问题就像人的短期记忆一样。当我们和 AI 聊天聊久了，它会忘记开头说了什么。目前最好的模型，上下文窗口能达到百万级 token，能解决部分问题，但是也不够用。
对于动辄几十万、上百万行代码的现代开发项目，AI 就像一个只能通过门缝看房间的访客。它能看到门缝里的景象，但对整个房间的布局、风格和功能一无所知。开发者们常常抱怨 AI 编程工具「用着用着就变笨了」，根本原因就在于此。
1.4 缺乏真正的理解
这是最根本的问题。LLM 不理解代码的含义，它只是在模式匹配。
举个例子，当我们让 AI 写一个排序算法，它能写出完美的快排代码。但这不是因为它理解了「分治」的思想，而是因为训练数据里有大量类似的代码，它学会了这个模式。
一旦遇到需要真正理解业务逻辑、需要创新思维的场景，AI 就可能搞不定了。
2. 编程领域的具体挑战
上面这些通用局限，在编程领域会被急剧放大，产生一些特有的问题。
2.1 错误的放大效应
我们知道人是有容错能力的，如这张图，汉字顺序错了，我们也能读懂。
写文章错个字，读者能看懂。但代码里少个分号、多个逗号，程序直接跑不起来。更要命的是逻辑错误，比如边界条件判断错了，可能测试都能通过，上线后才爆雷。
我见过 AI 生成的代码，把 < 写成 <=，导致数组越界。还有在金融计算中使用浮点数，精度问题累积后造成账目对不上。这些都是看起来微小，实际后果严重的错误。
2.2 安全漏洞
这个问题相当严重。研究显示，AI 生成的代码中，包含安全漏洞的比例明显高于人工编写的代码。
原因很简单：
- 训练数据本身就包含大量有漏洞的代码
- AI 不理解什么是「安全」，只知道完成功能
- 很多老旧的、不安全的编码模式被 AI 学习并复现
最常见的问题包括 SQL 注入、XSS、路径遍历等。AI 可能会直接把用户输入拼接到 SQL 语句里，或者在处理文件上传时不做任何验证。除非特别要求。
我们在实际写代码过程中，正向逻辑往往并不是花时间最多的，最复杂的就是边界，异常和特殊情况。
2.3 项目上下文的缺失
真实的项目开发不是写独立的函数，而是在一个复杂的系统中工作。每个项目都有自己的：
- 代码规范和风格
- 架构设计和模式
- 业务领域知识
- 自定义的工具类和框架
AI 看不到这些全貌，经常会：
- 重复造轮子（明明有现成的工具类不用）
- 违背架构原则（在该用依赖注入的地方直接 new 对象）
- 误用内部 API（不理解接口的设计意图）
2.4 代码质量和可维护性
AI 生成的代码往往追求「能跑就行」，但忽略了可读性和可维护性。常见问题包括：
- 过度复杂的嵌套和链式调用
- 缺乏有意义的变量名和注释
- 不符合团队的编码规范
- 没有考虑扩展性和重用性
当我们习惯了 AI 写代码，可能会不想去看代码（自信点，就是不想看），如果这样过度依赖 AI，可能会失去对代码的深度理解。当需要调试或优化时，面对一堆自己没真正理解的代码，问题就会比较大，甚至出了问题还需要现场看代码来定位问题。
小结
写了这么多，核心观点其实很简单 ：AI 编程工具是很强大，但也有明显的局限性。我们需要清醒地认识这些局限，合理地使用工具，同时不断提升自己的核心能力。
代码是我们与机器对话的语言，但写代码的意义，永远是为了解决人的问题。无论工具如何进化，这一点不会变。
所以，继续写代码吧，带着思考去写，带着责任去写。让 AI 成为你的助手，而不是你的拐杖。
毕竟，最好的代码，永远是有灵魂的代码，在写代码中注入心流。
以上。