先说结论：AI 生成的代码不是“不能用”，也不是“永远能用”，而是“有些场景特别容易翻车”。我过去一年在项目里大量使用 ChatGPT、Claude、Copilot 这类工具写业务代码、脚本、甚至算法原型，踩过的坑比很多人想象的多得多。最典型的感受就是：AI 交出来的代码，肉眼扫一遍完全没问题，注释齐全、命名规范、逻辑好像也通顺，结果一跑就出错，或者更隐蔽——跑起来不出错，但结果是错的。这篇内容专门聊聊这类“看着对，其实错”的代码到底错在哪，为什么会错，以及我们应该怎么在实操中把这些坑绕过去。
这个话题适合谁看？如果你正在用 AI 辅助写代码，或者打算用 AI 提效，但已经被“代码能跑但结果不对”“代码报错但看不出哪错”这类问题折磨过，那这篇内容基本就是给你写的。我会从原理、典型场景、排查方法论、以及日常工作流中怎么避坑这几个层面展开，尽量不绕弯子。
1. 为什么 AI 生成的代码会“看着对”：先从模型的底层逻辑说起
在讨论具体的坑之前，得先理解一个本质问题：AI 生成代码这件事，本质上是在做什么？很多非技术背景的人会把“让 AI 写代码”想象成“AI 理解了需求，然后像人一样完成了一个软件工程”，但实际机制完全不是这样。
AI 生成代码的本质，是一个基于海量文本语料训练出来的语言模型，在做“概率性的文本续写”。它不是在执行逻辑运算，而是根据你给的上下文，预测下一个最有可能出现的 token 序列。换句话说，模型学到的是“在这类问题下人类通常会怎么写代码”的模式统计，而不是“这段代码运行后会产生什么结果”的逻辑推演。这一点非常关键，它解释了绝大多数“看着对”的根源——模型天然倾向于给出“形态上像正确代码”的输出，而不是“经过逻辑验证的代码”。
1.1 模型的“流畅性优先”机制
你随便翻开一个语言模型的论文或者技术博客，都会看到它们在强调生成质量、流畅度、上下文连贯性。这类指标对自然语言文本是合理的，但对代码来说就埋了一个大坑：代码不只是给人看的，更是给编译器/解释器和 CPU 执行的指令序列。一个流畅、自然、命名优雅的代码片段，和一个能正确计算出目标结果的代码片段，完全是两码事。模型在训练时被优化的是前者——它学会了“长得像正确答案”的能力，但没学过“验证答案是否正确”的方法。
举个例子，你可以让任何主流 AI 模型用 C 语言写一个 strcpy 的安全替代版本，它大概率会给你写一个带长度参数的函数，看起来非常专业，还会贴心加上注释说明“避免缓冲区溢出”。但如果仔细检查，你可能会发现它用了 strlen 来计算源字符串长度，再通过这个长度决定拷贝长度——这等于绕过了安全机制的初衷，攻击者仍然可以利用 TOCTOU 一类的问题。这类问题不深入理解安全攻防细节根本看不出来，但 AI 写起来却“感觉良好”。
再比如在数据分析场景，你让 AI 用 pandas 处理一份销售数据，要求计算“每个品类销售额的月环比增长”。AI 写出来的代码很可能是这样的：先 groupby，再求和，然后用 pct_change()。语法完全正确，运行完全正常，数据也能输出，但如果你仔细推敲，pct_change 默认是按行索引计算的，如果你的 DataFrame 没有按日期排序，那么这个“月环比”算出来就是错的。AI 不会知道的，因为它在生成时根本没“运行”过这份数据。
1.2 训练数据里的“正确性陷阱”
还有一个非常隐蔽的因素：训练数据的质量分布。模型的训练语料来自 GitHub、技术博客、Stack Overflow 等公开来源。这些来源里的代码本身就良莠不齐。有些是质量很高的生产级代码，有些是初学者练习用的玩具代码，还有些是网上流传的片段——比如论坛里的回答，发帖的人自己都没运行过就贴出来了。
大模型在这个大杂烩语料里学习的是“统计上的平均”。如果 100 份代码里 60 份写错了但错误方式相同，模型反而会认为“这就是正确的写法”。这在一些边界条件处理上体现得特别明显，比如并发控制、字符串编码、时间时区处理——这些领域的错误代码在网络上广泛存在，甚至很多就是 Stack Overflow 上高赞但并非最优的答案。模型学到的就是“这种写法是主流”，而主流和正确之间，往往隔着一段距离。
这个问题的严重性在于，AI 生成的错误不是随机错误，而是“系统性的、统计层面的错误”。人写的代码出错，通常是某个变量名拼错、某个边界条件没考虑到，错误位置相对独立。AI 写代码出错，常常在同一个主题上反复以同样的方式出错，因为它们是从同一个概率分布里采样的。这给排查带来了额外的困难——你很难用“换个方式问”来绕过，因为不同问法给出的可能是一样的错误逻辑。
1.3 “看起来对”与“实际对”之间的三层差距
应该说，人对代码的“正确性判断”，和 AI 对代码的“正确性模仿”，之间有非常大的差距。我把这个差距拆成三个层面，方便理解：
第一层是语法正确性。这是最浅层的，AI 生成代码通常能保证这一层没问题——括号匹配、关键词拼写、类型标注齐全。这类似于“句子结构通顺”。
第二层是语义正确性。也就是代码虽然语法正确，但逻辑和需求是否匹配。这一层 AI 经常失守，因为“需求”本身是基于业务上下文理解的，模型并不真正理解你在说什么，它只是在做模式匹配。比如你说“删除文件”，它给你一个os.remove(file_path)，看起来没问题，但你实际想要的可能是“删除成功后还要记录操作日志并做权限校验”，这些隐含需求它抓不住。
第三层是运行时正确性。更麻烦，代码在语义上符合字面需求，但放到真实运行环境里会因为数据格式、性能瓶颈、并发冲突等超出模型认知范围的问题而翻车。这一层靠“读代码”看不出来，必须在真实环境中跑、用真实数据测才能暴露。
理解了这三层差距，就能明白为什么“看着对”是常态，而“真的对”需要额外付出大量验证努力。这不是 AI 能力不够，而是工具本身的设计目标就是这样——它擅长生成符合语料模式的文本，而不是生成经过验证的计算机程序。把这个认知建立起来，你在用 AI 写代码时的预期管理会好很多。
2. 最容易翻车的场景：这些场景就是“看起来对”的重灾区
不同场景下，AI 生成的代码翻车率差别很大。我在实际使用中总结出了一份比较直观的经验清单：纯语法功用的代码、通用算法实现，AI 能处理得很好；但凡是涉及状态管理、边界条件、特定业务语义、或者对性能有隐含要求的地方，AI 的输出就非常不稳定，严格来说属于“每次都要人工仔细审查”的级别。
2.1 边界条件与特殊输入处理
这是 AI 生成代码翻车的头号场景，没有之一。模型在训练语料里学到的往往是“标准的、理想的调用方式”，而真实世界的代码必须处理各种异常输入、空值、越界、网络超时等非理想情况。AI 对这类情况的覆盖能力相当差，因为它们需要的是“对业务的深入理解 + 对输入空间的穷举思维”，而语言模型显然不具备这个能力。
举个特别常见的例子。我在一个项目里要写一个处理用户上传文件的函数，需求是“把 CSV 文件解析成 JSON”，使用 Python 实现。AI 给了一个很标准的答案：直接用csv.DictReader读取，然后遍历每一行输出 JSON。代码非常简洁，注释也很清晰。但问题是，这个答案完全没考虑 CSV 文件可能存在的这些情况：文件是空文件、表头有重复列名、某行数据列数不一致、文件用了非 UTF-8 编码、字段里包含换行符和引号、甚至上传的根本不是 CSV 而是伪装成 CSV 的恶意文件。
在实际生产环境里，以上任何一种情况都会导致程序崩溃或者产生错误数据。人写代码的时候，因为有“我要处理真实世界的数据”这个意识，会主动考虑这些边界条件。AI 生成代码时没有这个“从需求到实现”的链路，它只是在复现“CSV 解析”最常见的写法。很多初学者用过一次 AI 生成的 CSV 解析代码，跑通了一个完美的测试文件，就觉得“AI 真厉害，代码能跑”，那是没经历过生产环境的毒打。
2.2 业务规则与隐式逻辑
如果说边界条件是显性的坑，那业务规则的遗漏就是隐性的坑，危害更大，因为代码从运行角度来看完全正常，但产生的业务结果是错的。
我举一个金融场景的例子。当时我在做一个量化交易策略的回测模块，写一个计算交易信号的函数。需求很简单：当价格突破 20 日均线时买入，跌破 20 日均线时卖出。这个需求听起来足够清晰了吧？我让 AI 直接实现，它生成的代码是：遍历每日价格，如果当日价格大于过去 20 日均价就返回买入信号，否则返回卖出信号。逻辑看着没毛病，代码跑起来也完全正常。
但稍微懂点交易系统的人一眼就能看出问题：第一，这个逻辑没有考虑“已经有持仓”时的状态管理，它会在价格一直高于均线的时候天天给你买入信号，而真实的交易系统只会在空仓时买入；第二，它没有考虑信号生效的时间差异——用当天的收盘价判断，但信号是盘中产生的，这个差异在回测里会造成未来函数，导致回测结果严重失真；第三，没有考虑手续费、滑点这些成交成本。这些不是“代码的语法或算法问题”，而是“业务逻辑的完整性问题”，AI 生成代码时完全没有能力感知到这些隐含的业务约束。
这不是 AI 的错，也不是“提示词没写清楚”的问题——就算你把所有显性需求都写进提示词，还会有大量“行业常识”层面的隐性需求是模型无法理解的。我见过很多开发者在 AI 辅助下写出了一堆“运行时零错误、业务上一塌糊涂”的代码。这类代码对测试人员和 code review 的人来说非常头疼，因为问题不出在代码本身，而出在“代码做了什么”和“需求真正想要什么”之间的错位。
2.3 并发与状态管理
凡是涉及并发、异步、共享状态、分布式系统的代码，AI 生成的可靠性会急剧下降。原因也很直接：并发问题的正确性高度依赖运行时环境的调度行为，这已经超出了语言模型能够基于文本统计来推断的范围。模型可以背诵“加锁用threading.Lock”这种常识性知识，但它无法理解锁的粒度和持有时间对性能的影响，更不能推演两个线程交错执行时的所有可能时序。
我实际测试过让 AI 写一个用于多线程环境下的计数器类。AI 生成的代码用了threading.Lock，看起来和教科书上一模一样，但仔细看细节就能发现问题：它把锁加在了函数入口，然后在整个循环里持锁，导致实际上变成了串行执行——这个计数器在功能上没错，但性能上可能比完全不加锁还差（因为有锁竞争的开销）。如果你把这段代码放在真正的高并发服务里，性能会直接拖垮。
更隐蔽的问题出现在 Python asyncio 场景。AI 生成的异步代码经常混淆“并发”和“并行”，或者在没有加await的地方漏掉 await，这类错误会让协程根本没有执行，程序却在逻辑上“误以为已经执行完了”。这种错误最坑的是，它不会直接报错——程序正常运行，没有异常，但你拿到的结果是空的。我遇到过一次：AI 写了一个批量调用 HTTP API 的异步函数，返回结果列表。代码看起来完全正常，但实际运行时因为遗漏了一个await，结果是[coroutine object]的列表，没有一个真正的 HTTP 请求被发出。这个 bug 在 code review 时很难发现，必须对 asyncio 的运行机制有深刻理解才能看出问题。
2.4 性能与复杂度陷阱
判断一段代码的性能问题，需要理解数据规模、算法复杂度、底层实现的运行机制——这些都是模型在生成时无法“感受”到的东西。
举个例子，AI 在写数据处理逻辑时，特别喜欢用嵌套循环。你让它“找出两个列表中相同的元素”，它会毫不犹豫地写一个双重 for 循环，如果列表长度是 10000，这个算法要跑一亿次比较。稍微有点工程经验的人会直接用 set 去重，或者将列表转成哈希结构进行判断，把复杂度降到 O(n)。AI 不是不会 set，而是它不知道你的数据规模是多少，只能在“通用答案”和“高性能答案”之间选择前者——因为通用答案在任何规模下都不会错，只是慢。但慢这种问题，模型没法通过语料感知到。
还有更隐蔽的性能杀手——不知不觉的复制。AI 在写 Python 代码时频繁使用列表切片、字符串拼接、深拷贝，这些操作在小数据集上毫无感觉，但数据量一上来就是内存和 CPU 的双重灾难。我见过一次 AI 生成的代码，处理 10 万行日志文件，因为反复用字符串+拼接，导致程序跑了 30 多分钟，而优化后只要几秒。这类问题无法通过“看代码”发现，必须在真实数据规模下做性能和内存剖析。
3. 实操方法论：把“看着对”变成“真的是对”
既然 AI 生成的代码天然存在这么多坑，那日常开发中我们应该怎么用 AI 才能既提升效率，又不被它带进沟里？这几年我逐渐形成了自己的一套方法，核心思路可以概括为：把 AI 当成一个“聪明的实习生”，而自己依然是那个“负责的架构师”。具体到实操层面，有几个原则非常重要。
3.1 需求描述必须带“验收标准”，而不是“实现思路”
这是最容易踩的坑，也是可以快速改掉的毛病。很多人在让 AI 写代码时，习惯描述“应该怎么实现”（比如“用 requests 请求这个接口”），而不是描述“应该满足什么标准”（比如“请求成功时返回数据列表，超时时间不超过 2 秒，失败时给出日志”。这两种提问方式的差异非常巨大。你让 AI 按照“实现思路”写，它只是把你的想法翻译成代码，相当于你在告诉一个实习生“按我的方法做”。你让 AI 按照“验收标准”写，它才会去思考如何设计。
具体操作上，我会在提示词里明确包含这几块内容：输入是什么（数据格式、规模范围）、输出应该是什么（结构、类型、值域）、约束是什么（性能要求、安全性要求、兼容性要求）、边界条件是什么（空输入、错误输入、异常输入时怎么办）。把这些信息给全了，AI 生成代码的初始正确率会显著上升。比如同样是写 CSV 解析，如果你告诉它“支持空文件、重复列名、UTF-8 和 GBK 编码，列数不一致时跳过该行并记日志”，它生成的代码质量会比“写一个 CSV 转 JSON 的函数”高出一个层次。
当然，就算提示词写得再好，也还是不能完全信任输出。核心逻辑仍需人工复查。我总结的复盘中有一条：AI 生成的代码里，if/else 分支越多、状态变量越多，越要仔细检查。这是因为条件分支的组合爆炸正是模型最无法充分推理的地方。
3.2 运行验证必须用“脏数据”和“极限数据”
很多人在验证 AI 生成的代码时犯一个错误，就是用最理想的例子来测。请求一个接口，返回 200 就说成功；处理一个数据文件，文件格式规规整整就认为没问题。这是远远不够的，因为 AI 代码最容易翻车的地方恰恰是异常情况。
我的测试习惯是准备好三类数据：第一是脏数据，比如字符串里带非法字符、数字字段里有空值、JSON 里少了必须的 key；第二是边界数据，比如空数组、只有一个元素、达到最大长度限制；第三是超大规模数据，模拟生产环境的数据量级，专门用来测性能和内存问题。把这三类数据喂给 AI 生成的代码，大部分隐藏的问题都能暴露出来。
举个例子，某次我让 AI 写一个从数据库取数并生成报表的函数。测试时用 100 条数据跑得很顺利，放到生产环境跑 1000 万条数据，直接内存溢出。原因就是 AI 写代码时用了全量加载的方式，把所有数据一次性读到内存里，然后才进行聚合。换成一个对性能有感知的工程师写，会想到分批查询或者流式处理。这类问题和“代码是否正确”无关，但和生产可用性直接相关，必须靠数据和环境去验证。
3.3 建立“AI 代码隔离层”：让 AI 代码只负责局部逻辑
我发现一个非常有效的方法，就是不要把 AI 生成的代码直接放到生产架构的关键路径上。更稳妥的做法是，给 AI 划一个明确的“工作边界”，让它只负责某个独立的小函数、类或者模块，而模块与模块之间的数据流、状态管理、异常传播，由人工主导设计和实现。
比如你在写一个数据处理流程，可以让 AI 分别生成“数据清洗函数”“字段映射函数”“结果格式化函数”，但不会让 AI 直接生成整个从 SQL 查询到前端渲染的完整流程——因为越长的链路越需要全局理解。独立函数出了问题，排查范围是可控的；整个系统出了问题，AI 生成的代码也帮不了你排查。
这个设计思路还有个额外的好处——单元测试更容易写。每个 AI 生成的函数都是独立的，你可以针对每个函数设计用例，逐项验证正确性。一旦函数整体通过测试，就可以放心集成到更大的系统中。这个“隔离 + 单项验证”的模式，可以显著提升对 AI 代码的信任度，又不至于完全依赖 AI。
3.4 用代码审查清单强制把关
我这里提供一个自己平时用的代码审查清单，不一定适合所有场景，但很多坑都是靠它拦下来的：
- 边界条件是否处理？空值、非法值、最大值、最小值的表现是否明确？
- 有无隐藏的全局状态或共享变量？并发环境下是否安全？
- 资源是否及时释放？文件、数据库连接、网络请求是否有可能泄漏？
- 时间与时区是否在多线程或跨机器场景下保持一致？
- 错误处理是否合理？日志是否包含足够上下文？
- 数据规模增大时，算法复杂度和内存占用是否可接受？
- 依赖的库版本是否明确？有没有使用已弃用的 API？
- 敏感信息是否可能被泄露到日志或异常消息中？
每个问题在 code review 时逐一核对，能过滤掉很大比例的“看似正确”的代码。我不建议每次审查都严格走一遍，但关键模块和高风险功能建议不省略。
4. 如何把 AI 放进团队工作流：定位、分工与心态
前面聊的更多是“单兵作战”模式下的避坑经验。但在真实项目中，AI 辅助编程往往是团队协作的一部分，这时候问题会上升到另一个层面：一个人被 AI 代码坑了，会拖累整个团队的进度。团队工作流里怎么用 AI 才能尽量避免这种风险，我也有几点实践总结。
4.1 AI 写代码的正确团队定位：加快速度，而不是决定方向
在团队里，最怕的事情是“AI 主导方案设计，工程师负责翻译”。AI 生成一段代码用了什么算法、什么架构、什么依赖库，这些决定不应该由 AI 来做——因为这关系到后续的可维护性、可扩展性、团队技能匹配度。如果让 AI 在 Redis 和 Memcached 之间选，或者干脆让它决定用不用消息队列，你项目的技术债会在几个月后才集中爆发。
正确的定位是：架构师和工程师先做技术决策——数据结构怎么设计、模块怎么划分、依赖怎么管理、接口怎么定义——然后再把这些决策翻译成明确的指令告诉 AI，让它把那些已经确定好的局部功能写出来。AI 负责的是“加速已知正确的方案”，而不是“探索未知的方案”。这个顺序不能倒过来，倒过来就是给自己挖坑。
有个很直观的例子。我见过一个团队用 AI 生成一个微服务模块的整体框架代码，AI 选了一个团队没人用过的第三方库，理由是“它比较简洁优雅”。结果后续出了问题，全团队没人会调试这个库，花了两周才摸清楚它的行为特性。如果当初让 AI 只负责生成路由和控制器层，消息队列和数据库访问层由团队按照既有技术栈人工设计，就完全不会有这个问题。
4.2 强制“AI 代码也必须走 Code Review + 测试”
这条听起来像废话，但在实际团队里很少被严格执行。很多人面对 AI 生成的代码，心理预期会降低，觉得“AI 写的，大概没问题”，顺手就把代码合进主干了。经过前面几节的介绍，你应该已经完全理解，这个想法有多危险。我见过不止一次，AI 生成的代码在 review 时被当成“机器权威”放行，结果上线后暴雷，比人类写的代码事故率还高。
所以我们的团队里有一套铁律：AI 生成的代码和人类写的代码一样，必须走完整的 code review 流程，必须要求单测覆盖核心分支，必须在 staging 环境做集成测试。没有任何豁免。具体执行上，code review 时不会把“这是 AI 写的”当作特殊标签来看待，反而会更警惕，因为 AI 代码的失败模式更隐蔽，值得多花时间看边界条件。
这听起来会削弱 AI 的速度优势，但实际并不是。AI 帮你把初稿写出来，本来就能节省大量“代码输入”的时间，剩下的时间花在 review 和测试上，从整体时间核算仍然是划算的。相反，如果你省掉了 review 和测试，省下 20 分钟，上线后出了 bug，抢救的代价可能是几个小时的排查加半夜的紧急发布。账谁都能算明白。
4.3 建立内部的“典型错误样例库”
随着团队用 AI 写代码的次数越来越多，大家会发现一些反复出现的、典型的 AI 坑点。我特别推荐把这类教训沉淀成团队内部的知识库。比如“AI 生成的多线程代码记得检查锁的粒度”“AI 生成的数据处理代码记得测空输入”“AI 生成的日期处理代码切记验证时区边界”。把失败模式写清楚，附上示例、定位方式、修正方法。
这类样例库的价值会随着时间不断增加，因为新加入团队的人也会使用 AI 编程，他们不可能靠个人摸索把所有的坑踩一遍。有了前人的经验总结，新人在 review AI 代码时就有了一套现成的检查清单。本质上这是把“从失败中学习”的效率最大化——不要求每个人都被坑一次才能学会，而是把坑的教训文档化。
在我们团队里，这个库现在已经收集了大概 40 多条典型错误场景，覆盖多线程、时间处理、网络请求、数据库访问、序列化、性能等不同类别。每周的分享会上，大家会轮流传阅新发现的案例。效果非常好，团队整体的 AI 代码质量上了一个台阶，出事故的频次明显下降。
4.4 把验证“正确性”的思维前置到提问阶段
最后谈一个比较微妙的心态问题。大家在使用 AI 写代码时，最常见的默认心态是“先让 AI 写，写完再看怎么改”，这是一种“验证后置”的工作方式。但大量实践告诉我，把“怎么验证正确性”这个思考提前到提问阶段，效果明显更好。
比如你准备让 AI 帮你写一个排序函数，先别急着敲“帮我写一个排序”，而是先在脑子里想想：这个排序要支持什么类型的数据？数据量大概多大？有没有可能包含重复元素？对稳定性能不能接受？性能要求是什么？把这些想清楚了，你就知道 AI 可能会在哪些地方出岔子，心里自然有底。甚至，你可以直接在提示词里写“请包含对空数组、单一元素、全部相同元素这三种边界情况的处理”，AI 生成的代码就会提前规避这些问题。
这不只是在用 AI 的时候有用，实际上是在培养一种工程思维。我接触的很多开发者，自己在写代码时也会依赖编译器报错和运行时报错来“试探性编程”，而不是先想清楚再动手。AI 本来就容易生成“形态正确但逻辑有缺陷”的代码，如果你的工作流也是“试错驱动”，那双层不确定性叠加起来，翻车的概率就非常高了。
5. 实例复盘：一次细细拆解的“AI 看着对其实错”全过程
理论说了一堆，很多读者肯定想知道具体的 bug 长什么样。这里分享一个经过脱敏的真实案例，是我在做数据清洗脚本时遇到的，整个排查过程非常有代表性。
5.1 需求场景
当时有个需求：从多个 CSV 文件里读出用户订单数据，将数据按用户 ID 分组，提取每个用户的“最早订单日期”和“累计消费金额”，最后输出成一个汇总表。这个需求不算复杂，普通工程师半小时能写完。为了效率，我让 AI 直接写核心逻辑。
AI 给了这么一段（简化版）：
import csv from collections import defaultdict def process_orders(files): user_stats = defaultdict(lambda: {"earliest_date": None, "total_amount": 0.0}) for f in files: with open(f, newline='', encoding='utf-8') as csvfile: reader = csv.DictReader(csvfile) for row in reader: uid = row["user_id"] date = row["order_date"] amount = float(row["amount"]) stats = user_stats[uid] if stats["earliest_date"] is None or date < stats["earliest_date"]: stats["earliest_date"] = date stats["total_amount"] += amount return user_stats这段代码一眼扫过去没有问题：文件遍历正确、字典默认值正确、日期字符串比较看起来很合理、金额累加逻辑正常。编译和运行都不会报错，用几行小规模测试数据跑也能得到看起来合理的结果。
5.2 实际运行时的异常表现
放到真实环境里跑，出现了两个问题。
第一个问题是日期的比较。源数据里的order_date字段有两种格式，大部分是2024-03-15这种标准格式，但有一部分是2024/3/15这种斜杠格式。字符串比较时，2024/3/15和2024-03-15的比较结果完全错误，比如"2024/9/1"用字符串比较会大于"2024-12-31"，导致“最早订单日期”统计错误。第二个问题是金额字段——源数据里某些行是空字符串，某些行带了货币符号$12.99，直接用float()转换会抛异常，脚本直接中断。
人写代码时，因为了解数据是自己对接的外部门提供的，大概率会做规范化处理和防御性校验。AI 生成代码时只会根据常见的“理想数据”来做假设，它没想到“你拿到手里的真实数据根本不会那么乖”。这段代码在开发环境测试通过，不代表在生产环境能通过——因为生产数据比你想象的脏得多。
5.3 修复与改进思路
发现问题后的修复方案并不复杂。日期统一解析：先判断分隔符，再统一转成datetime.date对象；金额数值清洗：去掉货币符号和千分位逗号，空字符串补 0；默认值增强：某些行缺少user_id，需要跳过并记录日志。这几个修复单独拿出来都是很常规的操作，但它们恰恰是 AI 最容易遗漏的部分。
改进后的代码片段：
from datetime import datetime def parse_date(value): for fmt in ("%Y-%m-%d", "%Y/%m/%d", "%Y.%m.%d"): try: return datetime.strptime(value.strip(), fmt).date() except ValueError: continue return None def parse_amount(value): if not value or not value.strip(): return 0.0 cleaned = value.strip().replace(",", "").replace("$", "").replace("￥", "") try: return float(cleaned) except ValueError: return 0.0这个修复过程看起来平淡无奇，但它揭示了一条核心原则：AI 擅长的是“正常路径”的代码，你需要人工补齐的是“异常路径”的代码。每次拿到 AI 的生成结果，你不应该急着去 review “主干逻辑”，而是专门去思考“如果输入不是我预期的那样，这段代码会怎样”。这才是从 AI 代码的“受害者”变成“驾驭者”的关键思维转换。
5.4 更进一步的反思：版本 pin 与可复现性
还有一个额外收获。那次排查过程中，我发现 AI 一开始还"贴心"地在代码里使用了pandas的read_csv和groupby来写替代方案。在本地环境跑没问题，部署到服务器时因为环境没安装 pandas，直接导入失败。这又是一个“看着对”的典型——代码逻辑对，但环境依赖没有说明。AI 不会告诉你它用了哪些第三方库、版本是多少、是不是你生产环境里已有的版本。
后来的做法是：凡是让 AI 生成脚本类代码，我会在提示词里明确要求“只使用 Python 标准库”，或者明确指定依赖版本，并生成requirements.txt一并保存。这样代码才具备可复现性，不至于在环境切换时突然暴雷。这种工程化细节，AI 不会主动替你考虑，必须在使用时约定好边界。
6. 日常使用 AI 辅助编程的几条保命建议
最后一部分，我想把积累的经验压缩成几条可以直接记住并实操的建议。这些建议不针对具体某一类代码，而是适用于任何用 AI 辅助编程的日常场景。
6.1 不要问“怎么写”，要问“要注意什么”
我发现一个有趣的转变：早期我用 AI 编程，问的是“帮我写一个 XX 功能”，现在更多时候会问“写一个 XX 功能，需要注意什么坑”。同样的技术点，后者会激活模型输出更多与边界条件、失败模式相关的内容。这部分内容往往比代码本身更有价值。
比如你让 AI “写一个发送邮件的函数”，它给你的是一段标准实现；但你换成问“写一个发送邮件的函数，并说明可能出现的异常场景和处理方式”，它大概率会提到 SMTP 超时、附件大小限制、收件人格式错误、被反垃圾策略拦截等实际情况。这些提醒正好是你做防御性编程需要的输入。
6.2 每个 AI 生成函数，默认配上最小验证用例
这句话的意思是，让 AI 生成代码的同时，要求它也给你生成对应的测试用例。这个成本很低，但价值很大。你让 AI 写的函数，它最清楚边界条件和特殊逻辑在哪里，让它自己生成测试，反而能覆盖很多你没想到的场景。当然，AI 生成的测试也存在“用自己的错误逻辑验证自己的代码”这种可能性，所以不能全信，但它至少给你提供了一份可以直接运行的参考。
得到测试用例后，用你自己的人脑，往里面加“脏数据”和“极限数据”。比如空字符串、None、超长字符串、负数值、零值、并发调用十次，每一个改动都可能让 AI 代码的隐藏问题暴露出来。这个习惯养成了，你就能把大部分问题拦截在进入 code review 之前。
6.3 遇到诡异问题先别急着找 AI，先“复现”和“定位”
如果真的被 AI 代码坑了、遇到了莫名其妙的 bug，我的建议是别急着把报错信息原样丢回给 AI 问“怎么修”。AI 面对报错信息，给出的修复方案经常是“随机试一个可能的原因”，而不是“定位真正的根因”。这和医生不问诊直接开药没什么区别。
更有效的方式是：先去构造最小复现样例、逐步二分定位问题代码段、用日志把中间变量值打出来。等你大致知道问题出在哪一层，再带着精确定位过的信息去问 AI，这时候它的建议就有针对性多了。我的经验是，直接甩报错给 AI，修复成功率大概 30%；先自己花十几分钟定位到具体函数和具体数据，再给 AI 提供完整上下文，修复成功率能到 70% 以上。这多花的时间非常值得。
6.4 复杂项目里，把 AI 当“结对编程伙伴”，而不是“代写工具”
随着你处理的项目复杂度上升，一条消息把需求说完让 AI 生成完整代码的做法会越来越不靠谱。更成熟的用法是：你在一个聊天窗口里和 AI 展开多轮对话，先讨论设计方案的取舍，再讨论某一块数据结构怎么定，再讨论某段逻辑的边界条件应该怎么处理，最后让 AI 根据讨论结果生成初稿。
这个过程特别像一个工程师在做结对编程，你的大脑负责整体方向和关键判断，AI 负责快速把想法形成可运行的雏形。这个模式下，AI 生成的代码错误率会明显降低，因为你已经在对话中把前面提到的很多隐性需求、边界条件、性能约束传递给了模型，它生成代码时的“上下文空间”是完整的。一个只会接收“一句指令丢一行代码”的开发者，和一个通过多轮对话互相校准的开发者，他们的 AI 代码质量完全不是一个级别。
最后再分享一个我个人实际使用中的小技巧：每次让 AI 生成代码后，我都会在下一条提示词里让它“指出这段代码在什么情况下会出错，并给出修正”。这一步用模型自己来做一次“对抗性审查”，往往能发现不少被我忽略的边界情况。虽然它不一定把所有问题都揪出来，但就像多了一双眼睛帮你 review，成本极低而收益显著——建议大家试一次就能感受到差别。
