最近常有朋友问我同一个问题AI 生成代码到底能不能用到生产环境他们有的被网上铺天盖地的宣传搞得跃跃欲试有的试了几天发现生成的代码根本跑不通转头又开始怀疑 AI 编程是不是纯噱头。我的看法是这两种极端都不可取。AI 生成代码这件事既不是万能神器也不是空中楼阁它更像一个需要重新学习使用方式的强力工具——用对了能把重复劳动压缩到原来的十分之一用错了它会用非常自信的语气给你产出一堆看似合理但完全没法用的东西。这篇文章我把过去一段时间在 AI 辅助编程上的实践、踩坑和思考整理了一遍包括工具选型、提示词设计、bat 脚本优化 Windows 游戏性能的完整实战、STM32CubeIDE 生成代码失败的复盘以及我把 AI 生成的代码迁移到生产环境前必经的验证流程。内容偏工程实践适合已经在用或准备用 AI 编程的开发者也适合对 AI 应用落地感兴趣的产品和技术管理者。1. 先想清楚AI 生成代码到底改变了什么1.1 从写代码到审代码的角色转换AI 生成代码最根本的改变不是帮你把键盘敲得更快而是把工作重心从生产代码转移到了定义需求和审查代码。以前写一个功能模块我大部分时间花在思考怎么实现、怎么组织数据结构、怎么处理边界条件然后一个字一个字敲出来。现在有了 AI我只需要把需求描述清楚它就能给我一版结构完整的代码。听起来省事了对吧但实际上我的时间并没有减少太多只是从写变成了审——审它的逻辑是否正确、是否有隐藏 bug、是否有安全漏洞、是否符合项目规范。这个转换对很多人来说是个坎。我看到不少同事拿到 AI 生成的代码简单扫两眼觉得能用直接合进主干结果出了问题排查起来比手写还痛苦。因为手写代码你脑子里有完整的上下文AI 生成的代码你得先花时间理解它的思路才能判断它对不对。这其实是个隐性成本很多人忽略掉了。所以说AI 生成代码真正考验的不是写代码的能力而是需求拆解和代码审查的能力。你可以不懂某个 API 的具体实现但你必须能判断它被调用的上下文是否正确你可以不记得某个框架的配置文件怎么写但你必须能认出 AI 写出来的配置哪里会导致启动失败。这种能力恰恰是很多初阶开发者最薄弱的地方。1.2 AI 最擅长与最不擅长的代码场景用了一段时间下来我整理了 AI 生成代码的强弱项清单基本都是经过实测验证的不是拍脑袋总结的。场景AI 的表现我的使用建议脚本类bat、shell、Python 小工具非常擅长可以放开了用但必须逐行审查CRUD 接口、常规业务逻辑比较擅长配合详细的接口文档和数据结构定义单元测试、Mock 数据生成很擅长能节省大量时间但要注意断言是否真的有效复杂算法、性能敏感代码表现一般需要人工验证复杂度AI 容易选型错误嵌入式初始化、寄存器配置表现较差只能当参考必须结合芯片手册核对跨多文件的大型重构容易翻车拆成小任务逐步执行不要一次到位安全相关、权限控制不推荐绕过安全机制是常态必须人工审计这套清单并不是绝对的AI 的能力也在快速变化但基本框架可以参考。我的核心建议是脚本和胶水代码可以大胆用 AI核心业务和底层敏感代码必须至少做一轮严格的人工审查这个原则到现在依然成立。2. 工具选型的现实问题从 Codex 到 Spring AI2.1 我实际用过的几款 AI 编程工具AI 编程工具这两年爆发式增长每款都声称自己是最强编程助手但实际用下来差距还是挺明显的。我前后试过几款主流的包括 GitHub Copilot、Cursor、OpenAI Codex、通义灵码还有用 Spring AI 搭过的内部助手简单聊聊真实感受。先说 Cursor。它最大的优势是代码库理解——你给它指定一个目录它能读取整个项目的结构和关键文件然后在生成代码时引用你项目里已有的函数、类型和风格。这点在大型项目里特别有用因为它不会凭空造一个不存在的工具函数而是会先看看你的项目里有什么、再用什么。我同事在 Cursor 上做过一个实验让它给一个已有 5 万行代码的 Java 项目加一个导出功能它居然能自动找到项目里现成的 Excel 工具类并调用。这个体验比单纯复制粘贴聊天窗口强太多。再说 Copilot。它在编辑器里的补全体验依然是最顺滑的尤其适合写那些模式化明显的业务代码比如定义一个接口写一个实现类加几个增删改查方法这种。但它的问题是对上下文的理解比较短浅经常在你写了一行注释后补全出一段看起来合理、实则用了旧 API 的代码需要我频繁修改。Codex 更适合那种一次性生成完整脚本的场景。比如你要一个处理日志的 Python 脚本或者一个清理系统临时文件的 bat 批处理给它一个清晰的需求描述它能直接产出一份可以直接运行的版本比 Copilot 在编辑器里一步步补全效率高得多。我下面的 bat 实战就是用 Codex 类工具生成的。通义灵码是国产工具里做得不错的中文理解有天然优势某些中文技术文档场景下表现比国外工具好。不过它的代码库理解能力相对弱一些适合个人项目或中小型项目的辅助编码。Spring AI 则完全是另一条路线。它不是编辑器插件而是让你在自己的应用里集成 AI 能力——比如做一个内部代码生成服务让团队通过网页或接口提交需求它调用大模型生成代码后走你们自己的 CI 流程。适合对数据安全要求比较高的公司代码不会出内网。2.2 多工具分工别把鸡蛋放一个篮子里我现在的习惯是多个工具配合使用而不是只依赖某一个。在编辑器里写业务代码用 Copilot 补全要生成独立脚本或 Demo 用 Codex 类工具需要在已有项目里做跨文件修改时用 Cursor涉及数据敏感的需求走 Spring AI 搭的内部平台。这样做的原因是每个工具的训练数据、上下文机制和交互方式都不一样同一段需求在不同工具里的表现差异非常大拿我那个 bat 脚本优化 Windows 游戏性能的需求来说几个工具给出的脚本质量差别很大有的甚至混入了危险命令。所以选工具不是选最好的而是选最适合当前任务类型的。另外提醒一句工具版本更新非常快别只看网上测评就下结论一定要在自己的真实代码库上试至少一个迭代周期。我见过有人因为某个博主说某工具神器结果装了发现对自家技术栈支持很差白白折腾一天。3. 提示词是 AI 生成代码的第一道质量关卡3.1 一个不清晰的提示词会浪费你半小时很多人觉得提示词就是跟 AI 说人话随意写几句就开始生成代码。这也是我早期最大的误区。后来我统计过一个模糊的提示词往往要浪费至少二十分钟——第一次生成的东西不符合预期你得追问、修正甚至来回拉扯好几轮。如果一开始把需求讲清楚五分钟就能拿到相对满意的结果。举一个我踩过的真实例子。有一次我让 AI 帮我写一个 Python 脚本需求是批量重命名文件夹下的图片文件就这么一句话AI 给了我一个用os.rename的简单脚本。问题是我的文件名里有特殊字符和中文Windows 路径下还涉及编码问题而且我需要按拍摄日期重命名而不是按原文件名排序。结果那版代码根本不能用我又花了好几轮告诉它这些约束条件来回改了七八次才勉强可运行。后来我把同样需求重新描述了一遍明确说明了文件格式、命名规则、目标平台和异常处理方式AI 第一轮就给出了几乎能直接跑的版本。3.2 我常用的提示词模板现在我在让 AI 生成代码时基本会按照一个固定结构来组织提示词大家可以直接拿去用稍微调整一下里面的字段就行。【角色】你是一名有 X 年经验的 XXX 工程师熟悉 XXX 技术栈。 【开发环境】操作系统是 Windows 11开发语言是 Python 3.11依赖管理工具是 pip。 【项目背景】这是一个内部日志分析工具的一部分数据来自 xxx 格式的日志文件。 【需求描述】 1. 读取指定目录下的所有 .log 文件 2. 提取每行中以 ERROR 开头的日志信息 3. 按时间戳排序后输出到 result.txt同时把相同错误信息的出现次数统计出来 4. 输出格式是 CSV包含时间、错误等级、错误信息、出现次数。 【输入输出示例】 输入/logs/2024-05-01.log 输出result.csv 【约束】 1. 不能用第三方库只用标准库 2. 需要处理文件不存在、文件编码为 GBK 的情况 3. 脚本要有清晰的注释函数要有类型注解 4. 内存占用要控制在 200MB 以内因为是跑在低配服务器上。 【验收标准】 1. 单测覆盖核心函数 2. 给出命令行运行示例和参数说明。这个模板的实质就是把平时产品经理跟你说需求时最让人崩溃的背景信息缺失问题给前置解决掉。角色定义让你的回答风格更贴近特定领域的资深工程师而不是一个泛泛的通才开发环境和项目背景让它可以参考具体的语言特性和代码风格输入输出示例约束了它生成的数据结构和函数签名约束和验收标准则堵住了它偷懒或者自由发挥的空间。3.3 追问轮次比一次性提示更重要一次提示很难把所有细节都考虑周全但可以通过多轮对话来弥补。这里有一个技巧拿到第一版代码后不要直接复制粘贴先问它几个问题——这里为什么用 A 方案而不是 B 方案这个函数在输入为空时会怎样这段代码的最小依赖是什么AI 的回答会暴露出它生成代码时的假设你就能快速判断它有没有理解对的你的需求。有一回我问它为什么选择了subprocess.run而不是os.system来执行外部命令它告诉我os.system是旧 API在错误处理和返回值获取上都有局限性而且不安全。这个回答让我确定它是理解了我的意图的——我确实需要获取命令返回值做后续判断。如果它答不上来或者含糊其辞那这版代码的可靠性就要打个问号了。这种追问式验收比单纯看代码有没有报错要靠谱得多。4. 实战拆解用 AI 生成 bat 脚本优化 Windows 游戏性能4.1 需求拆解把优化游戏性能翻译成可执行操作前面说过用 AI 生成 bat 批处理代码用于优化 Windows 系统的游戏性能这种需求很有代表性因为它是典型的听起来简单、做起来全是坑的脚本任务。拆开分析优化游戏性能其实包含了好几类动作关闭不必要的后台服务、把电源模式改成高性能或卓越性能、优化网络延迟、清理系统临时文件。如果你直接把这个需求甩给 AI它大概率会给你一个七拼八凑的脚本里面可能包含禁用系统关键服务、强制关闭某些进程这种危险操作。所以我的做法是先做需求拆解。在提示词里我会把每类动作再细化一层关闭后台服务我会明确列出哪些服务是game 运行时可选的比如打印服务Spooler、Windows SearchWSearch同时强调不能禁用网络相关的 DHCP、DNS 服务否则断网了游戏更卡调整电源模式直接指定用powercfg.exe的命令和对应的 GUID优化网络延迟指定通过netsh调整 TCP 全局参数而不是胡乱改注册表清理临时文件指定清理目录列表和排除规则。经过这种拆解后AI 生成的脚本就靠谱多了至少每一行命令都能让人看懂它在干什么你也能在审查时快速定位问题。如果你自己都不知道 AI 生成的那些命令是干嘛的那建议不要用这个脚本。4.2 生成、审查、修正的三轮迭代我跑了一次完整的 AI 生成 bat 脚本流程大家感受一下实际迭代过程。第一轮提示词我给的是拆解后的需求AI 给了我一个约 80 行的脚本。整体结构不错有echo off有管理员权限检测有分区的回声提示也有每个操作的注释。但它犯了一个低级错误——把powercfg.exe的高性能 GUID 写错了导致执行后电源计划根本没有被正确设置。这种错误很典型大模型对具体的 GUID 字符串记忆并不可靠经常混用新旧不同版本的标识符。所以遇到这种硬编码参数一定要以官方文档和本机实测为准不要轻信 AI 给出的常量。第二轮我把错误指出来要求它重新核对并加上如果设置失败要回滚到默认方案的逻辑。它这次聪明了不少用powercfg /getactivescheme先读取当前电源方案再执行修改失败时还能用powercfg /setactive恢复这比第一版稳妥多了。第三轮我重点审查的是禁服务的部分。第一版里 AI 用了sc config XXX start disabled这种写法一旦执行服务的启动类型会被永久改成禁用就算你重启系统也不会恢复。这个风险非常大我要求它改成临时停止服务的方式也就是只执行net stop XXX不修改启动类型再配合一个恢复脚本来重新启动这些服务。另外我还让它补充了对是否以管理员身份运行的判断因为sc和powercfg这类命令在非管理员权限下要么报错要么静默失败。三轮迭代之后我得到了一份可以拿去测试的脚本但注意这里说的可以拿去测试不是可以直接在主力机上跑。我把它放在测试虚拟机里先跑了一次确认没有禁用关键服务、没有误删文件之后才在真机上执行。4.3 跑完脚本后必做的三件事即使脚本经过多轮审查也在虚拟机上验证过了真机上跑完后我依然会做三件事算是长期养成的习惯。第一件事是检查电源计划是否真的生效。执行powercfg /getactivescheme看返回的是不是我们设定的高性能或卓越性能方案。注意有些笔记本即使在控制面板里看到了高性能实际运行中也会被厂商的电源管理软件覆盖这个只能通过 CPU 频率和散热表现来侧面验证。第二件事是确认网络参数没有改坏。AI 优化 TCP 参数时经常用netsh int tcp set global autotuninglevelnormal这类命令如果参数设置不合适反而会导致网络吞吐下降。安装完脚本后我会用下载工具跑一个测速对比优化前后的数值正常应该略有提升或持平如果明显变差立刻执行恢复命令。第三件事是重启系统验证服务状态。因为这次优化里我用的是临时停止服务的方式重启后这些服务会恢复自动启动所以需要确认它们没有在优化期间被改坏。另外我还要检查 Windows 事件查看器里有没有因为停止服务而产生的报错记录特别是打印、更新相关的服务报错是正常的但如果出现了与系统核心功能相关的错误就得考虑是不是禁用范围太大。这里有个实用的经验任何涉及系统配置修改的脚本都必须在脚本末尾打印一行当前修改项 对应的恢复命令方便出问题时快速回滚。AI 第一次生成时通常不会自动加这种恢复机制你需要主动要求或者自己手动加上。没做回滚方案的优化脚本本质上是拿系统稳定性换那一点点性能提升不值当。5. 实战复盘STM32CubeIDE 生成代码失败引发的排查5.1 失败现场AI 生成的初始化代码为何编译不过AI 生成代码不是万能的尤其在嵌入式开发这种要跟硬件打交道的领域翻车几乎是大概率事件。以前我在调试一个基于 STM32F407 的项目需要快速搭一个外设初始化函数——涉及 GPIO、UART、定时器 PWM 输出。我图省事让 AI 生成了一段 STM32CubeIDE 里的初始化代码结果一编译就报了几十个错误基本都是undefined reference和implicit declaration of function。最初我以为是简单遗漏了头文件但#include加到怀疑人生也没解决问题。后来耐下心去看报错的符号发现 AI 生成的代码里调用了好几个在 STM32F4 系列 HAL 库中根本不存在的新版本函数而它给出的类型定义也和我本地的 HAL 库版本对不上。说白了它大概是拿 STM32F7 或更新的示例代码来填空了。5.2 逐层排查从 HAL 库版本到 .ioc 配置什么时候能高枕无忧ST 官方提供 STM32CubeMX 生成初始化代码AI 想在嵌入式领域做到同样的可靠性还有很长的路要走。我这个问题的排查过程比较有代表性列出来给大家参考。第一步我先确认了编译报错的根源把所有报错信息放进一个文本文件统计出出现频率最高的几个符号。结果发现报错集中在 GPIO 初始化和定时器配置相关的函数。于是我用本地 HAL 库源码去搜索这些符号发现函数名存在但签名不匹配比如 AI 生成代码里传了 5 个参数本地库的函数只需要 3 个。这基本可以断定是 HAL 库版本不匹配导致的。第二步我对比了自己项目里.ioc文件CubeMX 的配置文件的内容。.ioc里配置的引脚、外设、中断优先级都会影响代码生成结果。AI 生成的代码没有经过 CubeMX 配置所以它压根不知道你的引脚具体接到了哪个 GPIO Port 的哪一位它只是凭空生成了一个看起来像样的初始化函数自然跟硬件对不上。第三步我看了一下编译器的报错日志里面有一些#error指令的输出比如某个配置宏没有定义。这些宏通常由编译器根据芯片型号自动带入AI 生成的代码不会主动定义它们也说明它对 STM32 这个生态的构建流程理解不够深——它以为写代码就是写给编译器看但嵌入式里的代码还要被启动文件、链接脚本、芯片头文件共同约束。最终我放弃了让 AI 直接生成嵌入式初始化代码的路径改为让 AI 生成代码片段作为参考实际工程代码仍然用 STM32CubeMX 生成AI 只负责帮我补充业务逻辑和数据处理部分。这样分工之后效率反而更高了。5.3 嵌入式场景用 AI 的三个教训这个问题解决后我总结了一套嵌入式领域使用 AI 生成代码的约束条件分享给大家。第一个教训是AI 生成代码的语言能力不能代表它对芯片生态的熟悉程度。它能写出语法完全正确的 C 语言但未必了解 STM32F407 的 UART 外设挂在 APB1 还是 APB2 总线上也不知道这个型号的定时器是否支持互补输出。这些信息散落在芯片参考手册的几百页里大模型训练数据并没有完全覆盖。第二个教训是需要为 AI 提供足够的硬件上下文。同样是配置一个 UART你至少要告诉它芯片具体型号、使用的 HAL 库版本、目标波特率、引脚复用关系、是否开启中断、DMA 是否需要等。这些信息缺失的话AI 就只能用最常见、最通用的配置来猜猜错的概率自然很高。第三个教训是验证成本必须前置计算。如果你打算让 AI 直接生成嵌入式代码先想想编译一次需要多长时间、烧录一次需要多长时间、出现问题后排查需要多长时间。这些成本如果很高那就老老实实让 AI 做辅助角色别指望一步到位。6. 从运行到合入AI 生成代码迁移到生产环境的必经步骤6.1 构建门禁与静态检查一个都不能少AI 生成的代码看起来能跑和可以进生产库之间隔着好几道检查关卡。我在实际工作中总结了一条黄金流程基本能拦截掉百分之九十的 AI 生成代码问题。第一步是构建门禁。必须确保项目在启用全量编译的前提下没有警告报错不能因为 AI 代码引入了-Wno-XXX之类的东西来掩盖问题。我看到过有同学为了让 AI 代码编译通过悄悄给 CMakeLists.txt 加了忽略警告的参数这种做法必须禁止。第二步是引入静态检查。以 Python 和 JavaScript 生态为例AI 生成的代码经常有未使用变量、危险函数调用比如eval、空异常处理这类问题。用 Ruff、ESLint、Bandit 这类工具扫描一遍能自动拦截大部分低质量问题省去人工审查大量无意义细节的时间。第三步是单元测试覆盖率。我这里强调的不是覆盖率数字本身而是断言质量——AI 生成的测试经常是断言结果不等于空这种毫无意义的用例。你必须要用一些 boundary value 去测比如空列表、0 值、超大数值、并发请求等。我遇到过一个 AI 生成的排序函数测试所有测试用例都是正序数组它当然能过但这种测试对代码质量的保护能力为零。6.2 代码审查要点AI 生成的代码审查简历给 AI 生成的代码做 Code Review 的时候我会重点盯着几个 AI 最容易翻车的点。一是资源泄漏。AI 生成的代码里文件句柄、数据库连接、网络请求经常开而不关尤其当它采用提前return的错误处理时非常容易漏掉close或finally逻辑。静态检查工具能发现一部分但最稳的还是人工过一遍。二是并发问题。AI 生成的代码在单线程场景下表现很好但一旦涉及多线程很容易出现共享变量没有加锁、使用了非线程安全的数据结构、或者在应该用CopyOnWriteArrayList的地方用了普通ArrayList这类问题。这种问题在压测或高并发场景下才会暴露排查成本极高。三是异常处理的粒度。AI 喜欢在最外层包一个巨大的try...catch把不同类型的异常一锅端。如果后面还要做监控告警你就会发现所有错误都被吞掉了线上日志全是Exception一条根本分辨不出是数据库挂了还是参数错了。审查时我一般要求它对不同异常分别处理或者至少让异常信息带上足够的上下文。6.3 生成代码也要写清为什么AI 生成的代码通常注释很少即使有注释也基本是解释这段代码做了什么而不是为什么要这样做。进入生产环境的代码读代码的人关心的往往是后者——毕竟做什么看代码本身就能理解但为什么如果不在注释里写清楚后人改代码时就是一场灾难。我要求团队在合入 AI 生成的代码时必须补齐两条注释一是这段代码解决什么问题二是有没有替代方案以及为什么选了这个方案。如果是 AI 生成的代码里有一些看起来不太合理的硬编码我会要求发起人写清楚这个数值的来源。这一条执行起来有难度因为写注释比写代码还费脑。但长远来看它省掉的是后来者反复考古的时间。7. AI 代码生成替不掉人的部分判断力与责任感用 AI 生成代码的时间越长我越觉得它更像是一个能力放大镜——基础扎实的人用它如虎添翼基础薄弱的人用它会在不知不觉中积累大量技术债。前面聊了这么多流程和技巧最后想聊聊那些 AI 没法替你决定的事。AI 可以帮你生成一个函数但它不能告诉你这个函数该不该存在它可以把一段代码从一个文件挪到另一个文件但它不知道这个模块是不是已经该拆分了它可以帮你写出一套完整的错误码映射表但它没办法帮你判断某个错误在业务上到底算警告还是致命。这些东西需要对业务的理解、对系统架构的把握、以及对技术选型的判断力短期内 AI 都不会真正具备。我的一个感受是AI 生成代码的下限很高因为它至少能给你一个语法正确的起点但它的上限完全取决于使用者的水平。只有当你清楚地知道自己想要什么、能识别出 AI 给出的答案哪里不对、并且有足够的风险意识去验证它你才有资格享受它带来的效率红利。否则它只是给你提供了一个更快的挖坑工具。从 bat 脚本到 STM32 初始化每一次实践都在提醒我一件事人不是被 AI 替代的而是被那些懂得用 AI 卷自己效率的人替代的。但反过来不懂工程严谨性、不懂需求本质、不懂验证和审查用上再强的 AI 也只会把错误以更高的速度放大。AI 是一个值得长期投入的方向但决定它价值的永远是你自己手里那关判断力。