你让AI写了一个 Python 爬虫，它刷刷刷给出了完整代码，看起来无懈可击。你信心满满地复制到终端，按下回车——然后屏幕上出现了茫茫多的红色错误信息。
这种感觉，用过AI辅助编程的人应该都不陌生。
2024年的一项研究发现，GitHub Copilot 生成的代码中，大约有 30%-40% 在首次运行时存在至少一个错误。Google Cloud 的研究也得出了类似的结论：AI 生成的代码正确率通常在 60%-70% 之间，剩下的那些，要么语法不对，要么逻辑有坑，要么直接就是"幻觉"出来的虚构函数。
听起来很不靠谱，对吧？但有意思的是，同样的研究还发现，用AI辅助编程的程序员整体产出提高了 55%。一边是帮忙填坑、一边是挖坑，到底哪个是真哪个是假？
今天我们就来拆一拆——AI写代码这件事，到底卡在哪一步？
第一步：AI是怎么"写代码"的？
先说清楚一个基础认知：AI写代码和你写代码，本质上是两回事。
你写代码的时候，脑子里有逻辑闭环——你知道变量 x 存储了什么值，知道 for 循环要遍历什么，知道调用这个函数会触发什么副作用。你在脑子里"运行"了一遍。
AI不是。AI写代码本质上还是在接龙——它看到你输入的"用Python写一个函数，读取CSV文件"，然后根据它的训练数据里的几十亿行代码，预测最可能接下去的token是什么。
这就好比有个学生每次考试都靠背往年真题答案来答题。遇到他背过的，他能把标准答案默写得一字不差；但遇到没见过的新题型，他就只能凭感觉拼凑，东抄一句西抄一段——看起来像那么回事，但一细究就露馅了。
这就是AI写代码的第一个根本局限：它没有"执行"过一行代码。它不知道代码运行起来会是什么样子。
第二步：它到底在哪些地方翻车？
根据Stack Overflow对开发者使用AI编程的调查，常见的翻车场景可以分成三类：
1. API幻想症
这是最典型的翻车。AI会"发明"一些看起来完全合理但实际上不存在的API函数。
比如说，你让AI用 pandas 把一个 DataFrame 保存到多个 Excel 工作簿。它可能写出：
df.save_to_multiple_sheets("output.xlsx")
这个方法光看名字太合理了——“保存到多个工作表”，英文语法也正确。但实际 pandas 根本没有这个方法。正确的做法是 pd.ExcelWriter + df.to_excel()。
为什么会这样？因为在AI的训练数据里，出现过无数次类似的函数签名模式——save_to_xxx、xxx.to_yyy——它只是按照概率拼接了它认为最自然的token序列，根本没去查过有没有这个函数。
2. 版本错配
AI的训练数据是有时间截断的。如果你的技术栈用的是新版库，而AI的训练截止在旧版，它就会给你过时的代码。
比如 2024 年 React 的 API 变了，用惯了的 createRoot 改成了新的方式，但模型可能还在给你生成旧的写法。这不是AI懒，而是它根本"不知道"新版的存在——它脑子里只有截止日期前的版本快照。
3. 逻辑正确但边界爆炸
有时代码语法完全正确，逻辑看起来也通顺，但一跑就崩。最典型的就是没有处理好边界情况。
比如你让AI写一个函数，从一个数组里获取第n个元素的"前一个元素"：
def get_previous(arr, n):
return arr[n-1]
看起来完美。但如果 n=0 呢？arr[-1] 返回的是最后一个元素，不是"不存在"。如果你的业务需求是"n=0时返回None"，这段代码就错了。
AI不是不知道边界情况的概念，它只是缺少一个真实运行的调试器来做校验。它没跑过，所以不知道这个函数会怎么用。
第三步：为什么"看起来对"比"事实上对"更容易？
这才是AI编程的核心矛盾。
人类写代码时，错误往往看起来就不对劲——缩进不对、括号没闭合、变量名拼错了。你一眼就能看出问题。
AI生成的错误是反过来的：语法完美，逻辑有坑。AI在语法层面的准确性接近 95% 以上，因为语法是高度规则化的东西，接龙模型很容易学。但逻辑层面就复杂了——一个程序有 N 种输入组合，可能只有 1 种会导致崩溃，但AI没有能力遍历所有组合。
把AI比作一个能把建筑设计图画得极其漂亮、但从来没考虑过承重和抗震的设计师，是很恰当的比喻。他的图看起来专业到令人窒息，但你按图施工，楼可能塌。
这正是为什么初学者用AI编程最容易踩坑——你没有足够的经验来判断AI生成的代码到底对不对。你以为它写的都对，结果一跑全是错；而当你好不容易把错误修好了，回过头来看——AI确实帮你省了50%的打字时间，但也消耗了你80%的改bug时间。
第四步：那到底该怎么用AI写代码？
别因为上面说的这些就对AI编程绝望了。工具好不好用，关键在于你怎么用。过去两年，一线程序员已经总结出了一套有效的策略：
策略一：分块验证，不要一次性生成大段代码
新手最喜欢做的事：让AI写一个完整的项目。这几乎必然翻车，因为越长的代码越容易出现累积错误——第一行的错误导致第三十行报错，第三十行的坑又蔓延到一百行。
正确的做法：让AI生成一个函数，然后停下来，在你的环境里验证通过后，再写下一个函数。
策略二：让AI当你的"副驾驶"而不是"司机"
最好的AI编程工作流是这样的——你写架构，AI填代码。比如你想写一个 web 爬虫，你手动搭建好框架——主函数、请求模块、解析模块的骨架。然后告诉AI：“帮我实现这个解析函数，输入是HTML字符串，输出是标题列表”。这样AI的上下文是受限的、清晰的，翻车概率大大降低。
Meta 内部的一份报告显示，这种"人类主导、AI辅助"的模式，代码的错误率比"AI主导、人类检查"模式低 3 倍。
策略三：主动提供版本信息
在给AI的指令里加上库的版本号，能大幅减少API幻觉得概率。比如：
“用 Python 3.11 和 pandas 2.0 写一个读取JSON文件的函数”
比
“用Python读取JSON文件”
生成的代码质量高得多。因为一旦限制了版本，AI在token级的概率分布中就更倾向于匹配该版本的API模式。
策略四：把AI当"第一轮草稿机"
接受一个事实：AI生成的代码大概率需要修改。把它当成初稿而不是终稿。
2023年的一项用户研究发现，程序员把AI代码当作"第一遍草稿"来用时，情绪更正面、改动更大胆，最终产品质量也更好；而那些把AI代码当作"差不多就行了"来用的人，更容易在不知不觉中放过bug。
第五步：未来会更好吗？
当然。AI写代码的能力正在飞速进步。2024年末的 Claude 3.5 Sonnet 和 GPT-4o 在 SWE-bench（一个评估AI修bug能力的基准测试）上的得分从一年前的不到15%飙升到了近50%。
一些趋势已经在发生：
- Agent模式：AI不再一次性输出代码，而是可以"思考"——它会先规划步骤、写测试用例、再写实现代码、然后运行测试、看到报错后自动修改。这种"自纠错"循环让错误率大幅下降。
- 代码执行集成：Cursor、GitHub Copilot 等工具已经能把AI的代码直接在你的编辑器里运行，把报错信息自动反馈给AI，形成闭环。
但这终究是个辅助工具。就像计算器没有让数学家失业、反而让数学变得更有创造力一样，AI编程的最终形态不是替代人，而是让人能把注意力从"怎么拼写语法"转移到"应该设计什么架构"上。
写代码最值钱的部分，从来不是打字，而是想清楚要打什么。
📖 本文是MST「30天AI科普专栏」第14篇 / 共25篇 🔖 分类：常见困惑 关注MST，每天一个AI小知识，把大模型讲明白。