1. 从"能跑"到"能交付"：AI写代码到底卡在哪一环
先说个真实场景。上个月我接了个小需求，给内部工具加一个批量导入功能，Excel上传、字段校验、错误行回显、进度提示。老套路了，我懒得手写，直接把需求扔给AI助手，让它生成一版 Django 后端的导入接口。
第一版代码出来得很快，接口能跑，文件能解析，数据能入库。看起来挺美。但我往深处一看，问题全出来了：校验逻辑是拿if not row.get("name")这种写法判断空值，遇到0或者False直接误判；错误信息只返回了"第3行有问题"，完全没有定位到具体字段；事务只包了一半，中间抛异常会造成脏数据。连跑带改，我花了比手写多一倍的时间才把它修到能交付的状态。
这就是当前 AI 生成代码最真实的处境——"能用"和"好用"之间，隔着一整条生产环境的经验鸿沟。
如果你问"AI生成的代码真的有用吗"，我的回答是：有用，但它的用处在特定场景下，而且使用方式决定了一半的成败。这篇文章不打算给你一个非黑即白的结论，我会从自己过去一年高频使用AI辅助编程的实际经历出发，拆一拆哪些环节 AI 是真帮忙，哪些环节它在给你挖坑，以及怎么把它变成顺手工具而不是麻烦制造机。
适合谁来读？正在用 ChatGPT、Copilot、通义灵码这类工具写代码的开发者，尤其是那些发现"AI写的东西一跑就报错"或者"跑通了但不敢上线"的人。这篇文章会告诉你问题出在哪，以及怎么调整你的使用姿势。
2. 为什么大家对AI生成代码的评价两极分化
2.1 同一个AI，有人当宝，有人骂废
我在几个技术社区里观察到一个很有意思的现象。聊到AI写代码，评论区基本分两派。一派说"效率翻倍，写CRUD再也不用手敲了"，另一派说"生成的代码全是表面功夫，稍微复杂一点就崩"。
两边说的都属实，只是他们让AI干的活完全不是一回事。
用AI写一个独立的纯函数，比如把时间戳转成指定格式的日期字符串，或者写一段正则提取URL里的参数——这种任务边界清晰、输入输出明确、逻辑不依赖外部上下文，AI通常能一把过，给你一份能直接用的代码。
但如果你让AI"帮我写一个订单系统的退款接口"，情况就完全不一样了。这个任务背后隐藏着大量上下文：数据库表结构长什么样、订单状态机怎么定义的、支付网关回调接口是什么格式、退款要不要走人工审核、并发情况下怎么防超退……这些信息在你的脑子里，不在AI的上下文窗口里。你不主动提供，它就基于"一般情况"脑补一套，出来的代码自然没法直接落进你的项目。
所以"AI到底有没有用"这个问题的正确答案是：它对"任务边界清晰"的活极有用，对"隐含上下文丰富"的活，用不好就是灾难。
2.2 "看起来对"和"真的对"之间差多少
再往深一层说，AI生成的代码有一个非常迷惑人的特点——它"看起来非常对"。变量命名规范、函数拆得合理、注释写得比你自己写得还勤快，代码风格标准得像是从教科书里抄出来的。这很容易让你放下戒心，觉得"AI都写成这样了，应该没问题吧"。
但代码的正确性从来不体现在"表面整洁"，而是体现在边界条件的处理上。
我随手举一个例子。让AI写一个函数，从一个列表里找出所有用户 ID 大于100的元素。它会给你写：
def filter_users(users, threshold=100): return [u for u in users if u["id"] > threshold]看着对不对？对。但如果你给它传users=None呢？直接TypeError。如果列表里有元素缺少"id"键呢？KeyError。如果用户的 ID 是字符串"150"而你用整数100去比较呢？同样崩。
人写代码的时候，因为了解业务、知道数据从哪来、经历过线上事故，会下意识地加这些防御。AI没有这些"潜意识"，它在训练数据里学到的"平均人写法"就是最直接的那种——不考虑异常、不处理边界、乐观假设一切正常。
这就是为什么很多人初用AI写代码时感觉"惊为天人"，用了一周后开始觉得"全是坑"。不是AI变笨了，而是你从简单任务切换到了复杂任务，AI生成代码的"乐观假设"开始频繁与现实碰撞了。
3. 实战复盘：我用AI写了三个真实模块
光说理论没意思，我把上个月真实做过的三个模块拿出来拆一遍，你们感受一下AI输出质量的巨大波动。
3.1 配置转换脚本：AI的高光时刻
第一个任务是把一份内部用的 YAML 格式配置批量转换成新的 JSON Schema 格式，字段要重命名，嵌套层级要拍平，某些默认值要统一替换。这个任务很简单，约束清楚，输入输出完全可预期。
我把新旧格式的样例各一份贴给AI，描述转换规则，让AI生成脚本。它给了我一份 Python 脚本，用的yaml.safe_load和json.dump，转换逻辑和我的预期一致。我跑了三组测试数据，第一组直接通过，后面两组在嵌套处理上有两个小偏差，我描述了偏差位置，AI修正后再次运行，全部通过。
全程耗时15分钟，手动写大概需要40分钟到1小时。这次体验非常顺滑。
这类任务之所以适合AI，是因为它本质上是"有明确规则的文本变换"。规则清楚、逻辑简单、测试容易，AI生成的内容可以直接用。
3.2 内部数据看板接口：AI的及格线
第二个任务是给一个运营数据看板写后端接口，数据源是现有的 PostgreSQL 库，表结构如下：orders（订单表，含金额、创建时间）、users（用户表，含注册时间、渠道来源）、order_items（订单明细表）。需要按天聚合订单数、GMV、新用户数，返回 JSON 给前端。
第一版AI代码，建立查询的逻辑是对的，GROUP BY用法没毛病，日期处理也用了date_trunc。但问题出在两处：
第一，AI不知道我们项目里有个公共的base_repo基类，所有数据库操作都要走它；结果AI直接用了裸psycopg2连接，跟项目架构完全不搭。第二，报表接口需要对零数据日期补 0（比如某天没有订单，也要返回一条 0 记录），AI没有处理这个。
第一处是我没给它足够的上下文——它不知道我项目里有什么基础设施。第二处是需求没写清楚——我没明确说"缺失日期要补零"。这两处都需要我补充信息后再让AI调整，第二版就基本贴合需求了。
这次体验算是"及格偏上"。AI帮我完成了核心的SQL组装和序列化代码，但集成工作得我自己把控。
3.3 异步任务队列改造：AI的翻车现场
第三个任务是个大改造。一个老模块原本是同步处理文件上传后的转码逻辑，我要把它改成异步架构：上传接口接收文件后立刻返回，后台任务去转码，转码完成后回调更新状态。
这个任务的复杂点在于：它涉及任务队列的选型（我们用 Celery 还是 RQ？）、老代码里有一堆全局变量依赖（数据库连接池、存储客户端的引用）、还有分布式锁的需求（同一个文件不能触发两个转码任务）。
AI完全翻车了。它生成的代码用的是它训练数据里最常见的写法——"给你一个崭新的异步处理示例"，里面假设了所有依赖都可以从配置文件里读取，然后用标准库模拟了个队列。它完全没意识到（也没法意识到）这个模块的历史包袱：那个老模块里有个模块级初始化过程，加载了一堆从环境变量读出来的服务配置，还依赖一个调用链追踪装饰器——这些AI一概不知。
结果是我花了一个下午，自己把老模块的结构重新梳理了一遍，把异步化的改造方案画出来，再分步骤用AI辅助实现每个子步骤的代码（队列任务抛上来的参数解析、状态回调的存储逻辑等）。最后AI帮我写的代码加起来占最终改动量的四成，但架构设计、接口拆分、异常链路设计全是我自己做的。
这三个案例摆在一起，你大概能感受到规律了：AI的能力上限不在模型参数量，而在于任务的"上下文密度"。上下文密度越低——就是"信息都在你的输入里"，AI发挥越好；上下文密度越高——需要你脑中的项目知识、架构约束、历史包袱才能写对，AI就快速掉链子。
4. 我审视AI生成代码时必查的六个危险点
踩了无数坑之后，我现在把AI生成的代码当成"一个能力不错但刚入职三天的初级工程师"写的代码——表面光鲜，实际上对项目的潜规则一无所知。我建立了一张固定的审查清单，每一块AI生成的代码都必须过这六道关。
4.1 接口与依赖是否虚构
第一关查"幻觉API"。AI训练数据里有大量库的用法，但很多库的接口在演进过程中变了。AI很可能给你写一个"记忆里存在、实际上不存在"的函数调用。
我遇到过最典型的一次：AI生成了一段用某个第三方SDK上传文件的代码，调用了一个upload_to_bucket_with_metadata(file_path, metadata, timeout=30)方法。我保持警觉去查了SDK文档，发现根本没有这个方法，正确写法是先初始化BucketClient，再调put_object()。还有一个更隐蔽的情况，AI会把两个库的接口混合使用——比如把requests库的Session概念套到httpx上面，写出来的调用方式两边都不对。
4.2 错误处理是否敷衍
第二关看异常处理是不是"假把式"。AI生成代码时最常见的风格是：函数开头写一个笼统的try/except，里面全部log.error然后return None，看起来好像有了错误处理，实际上把异常吞了个干干净净。
这种代码放到线上最要命。错误被吞了，排查全靠猜；返回None之后上层代码还按正常结果处理，大概率第二处AttributeError或者空指针。我现在的标准是：一个函数里凡是有IO操作（网络请求、数据库访问、文件读写），AI写的try/except必须逐条审，必要时全删掉重写。
4.3 边界条件是否覆盖
第三关检查边界。我给AI提问题时，如果我没主动说"参数可能为None""列表可能是空的""并发下会同时操作同一份数据"，它默认不处理。这也正常——因为训练数据里那些"高票答案"就是针对理想输入写的。
所以收到AI代码后，我习惯性会脑补一遍"恶意输入"测试：传空值、传超长值、传格式错误的值、传并发冲突的值。这块不能省，翻车率极高的地方就在这。
4.4 事务与并发是否安全
第四关是事务边界和并发安全。这一块AI的错误率最高。让AI写一段"从账户A转账到账户B"的逻辑，十有八九它会给你写成"先扣A的钱，再加B的钱"，中间没有任何事务包裹，更不用说考虑两个账户同时操作时的锁问题。
倒不能说AI不懂事务——你让它"用事务包裹这段逻辑"，它能给出正确写法。但它默认输出的时候不会主动加，因为大部分训练样本都不是在"生产环境多用户高并发"的假设下写的。
4.5 性能是否"只对不优"
第五关看性能。AI生成的代码在正确性上说得过去，但性能经常存在隐性缺陷。典型情况：循环里重复查询数据库（本来一条IN查询就能搞定，AI给写成for循环里逐条SELECT）、频繁拼接字符串不优化、大数据集上能用set却用了列表推导再in查询。
小数据量时完全没感知，等我把数据量翻个百倍，接口响应时间从 50ms 涨到 3s 的事我真没少遇到过。
4.6 安全问题是否缺失
第六关查安全底线。AI默认生成的代码基本不考虑安全问题：SQL拼接可能注入、用户输入不做白名单校验、密码直接明文存储、文件上传路径不做防穿越处理。
其中SQL注入是最常见的。我甚至碰到过AI生成代码里有个eval()调用，它的注释还写着"根据条件动态计算表达式"——这种代码放到生产环境，约等于邀请别人进你家参观。
我现在对AI代码的安全策略很简单：凡是涉及用户输入、SQL、文件路径、权限判断的代码，不管AI怎么写，一律按重写对待。AI在这块能提供的价值顶多是帮你把逻辑骨架搭好，安全加固必须自己做。
5. 怎么把AI用成"得力干将而不是甩手掌柜"
聊了这么多AI代码的缺陷，不是劝你别用——完全相反。AI辅助编程确实实打实地帮我节省了时间，关键是要调整使用姿势。下面这几条是我摸索下来收益最大、踩坑最少的实战原则。
5.1 拆任务：AI擅长的是"原子任务"，不是"系统工程"
我最深刻的体会是：你丢给AI的任务范围越大，它给你的代码越水。反过来，你把大任务切成一段一段边界清晰、上下文完整的小任务，一个个喂给它，质量会有质的提升。
同样是"写一个订单导出功能"，不要直接扔这个完整需求。拆成这样喂更靠谱：
- 先让它写"根据查询条件从订单表查数据，支持分页，按创建时间倒序"的函数。
- 再让它写"把一个订单对象转换成导出Excel行数据的函数"。
- 然后让它写"把多个Excel行数据写入一个workbook并保存到指定路径"的函数。
每个函数单独给它完整的输入样例和输出要求，它相当于在已知领域里做翻译，质量自然高。
5.2 给约束：AI不是读心机，上下文全靠你喂
前面讲了AI不知道你项目的架构、依赖、潜规则，那这种上下文能不能靠提示词补？能。而且补得越详细，出来的代码越贴地。
我现在写提示词有个固定模板，里面对项目背景的描述必占一半：
项目背景：Python 3.11，使用 FastAPI，数据库访问走 SQLAlchemy 2.0 异步方式， 统一异常处理在 app/exceptions.py 里定义了 ApiException，返回格式是 {code, message, data}。 请实现一个查询用户订单列表的接口，按 create_time 降序分页，支持按状态筛选。 表结构如下：...注意里面每一句都不是废话。告诉它用 SQLAlchemy 2.0，它就不会给你写 1.0 时代的Session.query；告诉它异常处理已统一，它就不会自己发明一个try/except返回字典当错误响应。
5.3 分阶段审查：按我清单逐步过滤
上一章节那六个审查点对应六个阶段，你不需要一次性检查完。实际操作时我按"能不能跑→跑得对不对→跑得稳不稳→跑得快不快→跑得安不安全"这个顺序层层过滤。
- 第一步代码能不能跑：直接跑测试
- 第二步逻辑对不对：写几个边界用例验证
- 第三步稳不稳：错误处理和事务有没有漏洞
- 第四步快不快：看有没有明显性能瓶颈
- 第五步安不安全：过一遍SQL注入、权限校验、敏感信息
越靠前的问题越容易发现，越靠后越致命。我大部分时间都花在第三和第五步，这两步是AI最容易翻车也是线上事故高发区。
5.4 让AI先出方案，再写代码
这条是我最近才悟出来的。原本我都是"需求→代码"一步到位，后来发现如果中间加一步"方案确认"，效率反而更高。
具体做法：拿到任务后，先让AI用自然语言描述它的实现方案，比如"第一，解析Excel并逐行校验；第二，将有效数据批量插入数据库；第三，异步生成错误行报告；总体采用事务包裹"。然后我看一遍这个方案，哪里不符合预期当场纠正，等方案对齐了再让它写代码。
这个"先方案后代码"的模式能大幅减少返工，因为很多问题在方案阶段就能暴露——比如它打算用for循环逐行插入而我想要bulk_create，这种事等代码写完了再改，代价高得多。
5.5 建立AI代码的"回归测试"习惯
最后一条建议，也是让AI代码能安全上线的最后一道防线：给AI生成的代码配上足够的回归测试，尤其是你让它重构别人写的旧代码时。
AI做重构，最常见的问题不是"新代码写歪了"，而是"隐式的旧行为没保住"。旧代码里有某些细节逻辑——某个字段为空时的默认赋值、某个错误码的语义、某个时间字段是使用本地时区而非UTC——这些都没写进需求文档，但线上一直靠这些细节运行。AI重构后很可能把这些"隐性契约"弄丢。
解决办法就是：重构前后，把旧代码的参数组合全部整理成测试用例，跑一遍旧实现记下结果，再跑一遍新实现对拍。对不上的地方逐一排查。这个过程比让AI直接生成测试用例更能发现真问题。
6. 到底哪些代码敢放心交给AI，哪些必须人自己来
把 AI 生成代码的优缺点放一起看，我心里其实有一张比较清晰的分配表。分享出来供大家参考。
6.1 放心交给AI的六类活
我个人实践中，以下六类任务交给AI，性价比最高，翻车概率最低：
- 样板代码：新建一个接口的 CRUD 壳子、写一个标准的 RESTful handler、生成项目初始结构。
- 配置与转换逻辑：YAML 转 JSON、字段名映射、格式对齐、新老配置变更。
- 正则表达式：描述完匹配规则，让AI直接出正则可视化断言的代码，效率远超手调。
- 测试用例生成：给AI函数源码和边界值清单，让它生成单元测试。这一步要注意审查它造的断言是否真能执行。
- 简单的数据处理脚本：日志解析、Excel 合并、统计报表。这类任务通常是一次性脚本，多修几次成本也不高。
- SQL 查询编写：给AI完整的表结构和查询需求，简单的多表关联它能写出对的 SQL。复杂的联表或者带窗口函数的，我还会人工复核执行计划。
6.2 必须人来主导的五类活
下面这些场景我坚决不会让AI全权代劳：
- 架构设计：模块怎么拆、依赖方向怎么定、扩展点留哪里，这种全局视野是AI上下文中永远缺的。
- 核心业务逻辑：比如订单状态流转、计费规则、库存扣减，这些出错了是要担责的，必须逐行人肉审查。
- 安全敏感代码：认证、授权、支付回调验签、加密解密，任何一行不能马虎。
- 事务与并发控制：涉及锁、事务边界、幂等控制的地方，AI的理解基本停留在概念层面，实战细节差得远。
- 维护性要求高的长期代码：代码要活五年十年的，AI生成的写法和项目既有风格往往有冲突，这类代码我更愿意按团队的约定手写。
6.3 一个通用的取舍原则
如果你不知道某个任务该不该交给AI，我送你一个判断公式：
任务的"可验证性"越高，越适合AI。
什么叫可验证性高？输入输出可以快速写断言来验证，边界条件可以枚举出来测试，环境和数据接近纯函数。这种任务AI哪怕偶尔出错，你也能低成本发现并修正。
反过来，可验证性低的任务——需要上线观察、需要业务方确认、需要人来看体验——就别省那个劲了，自己来。
我见过不少开发者的痛苦根源是把 AI 用反了：简单但要求"不出错"的活（比如 POS 机重试逻辑、退款回调处理）图省事丢给AI，复杂但"差不多能跑就行"的活（比如数据分析脚本）反而小心翼翼地手写。这么一颠倒，不翻车才怪。
7. 真实收益：算一笔AI辅助开发的效率账
说了这么多，有人可能觉得我立场偏保守。我最后拿自己的实际数据说明：我用AI辅助编程半年，整体效率确实提升了，但提升的方式可能和你想的不一样。
我在一个小型团队里做后端开发。过去六个月，我统计了一下自己写代码时间的分布变化。
手写全部代码的时候，我的时间大概是这样花的：想清楚需求和方案占三成，写代码占四成，调试占两成，自测和走查占一成。
用AI辅助之后，变成了：想清楚需求和方案占四成，给AI描述上下文加审查代码占三成，调试占两成，自测和走查占一成。
看时间比例：写代码的核心劳动从四成降到了三成，效率确实提升了，但没有想象中"AI自动写、我啥事不干"那种颠覆感。而且注意，"想清楚需求"的时间占比从我原来已经很高的三成涨到了四成——因为你要给AI讲清楚它该干什么，这个过程倒逼我把需求梳理得更完整，反而减少了后期返工。
这算下来，我整体开发效率提高了大约20%到30%。主要集中在大量样板代码的加速生成和简单脚本的快速落地。复杂的核心模块，AI帮我省的时间大约一到两成，大头还得自己扛。
这个数字不算惊艳，但已经足以让我把AI留在日常工具链里了。它带来的最大价值不是"替代我写代码"，而是"省下那些写了十年、闭着眼都会写的重复劳动时间，让我把这些时间拿去思考更重要的设计问题"。
8. 写在最后：AI是副驾驶，方向盘别松
每次跟朋友聊AI写代码，我都会重复一个比喻：AI不是自动驾驶，它是副驾驶。副驾驶能帮你导航、帮你看着点盲区、帮你递水，但方向盘焊在你手里，油门刹车也得你自己踩。你把方向盘交给副驾驶，那不是效率，是赌命。
现在AI编程工具每天都在进步，上下文窗口越来越大、能记住的项目约束越来越多。一年后的AI可能比今天的AI强不少，但"它不懂你的业务并且会自信地装懂"这个底层逻辑不会变，因为它本质上还是一个"基于模式预测的生成器"，而不是一个"理解系统运行的人"。
我的实践结论是：AI生成的代码确实有用，但它的价值天花板由你的审查能力决定。你越是能清晰地定义任务、越是能严格地验收输出，AI就越能成为你的得力干将。相反，你越是把它当成万能填空机，它坑你的花样就越多。
最后分享一个我个人的实操习惯：每段AI生成的代码合入前，我都会在代码审查里加上一个# ai-generated注释，让团队里每个人都知道这段代码需要额外关注。这个微小的习惯，已经帮我们拦下了好几次潜在的线上问题。它的价值不在于标记本身，而在于它时刻提醒所有人——这里的东西，别只看表面。
