做了两年多 AI 生成代码的深度用户我最大的感受是它把写代码的门槛降下来了但把判断代码好坏的门槛抬上去了。第一次真正被 AI 惊艳到是在一次重构任务里项目里有一段 500 多行的 if-else 分支业务规则叠着历史包袱我刚接手根本不敢乱动。抱着试试看的心态我把代码贴给 AI让它给一份重构思路结果它不光把策略模式拆得明明白白还直接生成了完整实现。那一刻确实有种效率暴涨的快感。可没过多久我就吃了大亏AI 生成的脚本在测试环境跑得一切正常部署到生产后却把数据库索引全删了因为它的重建索引优化方案在真实权限环境下只执行了删除、没有执行重建。代码看起来完全正确运行结果却把整个系统拖垮了。从那天起AI 生成代码在我这里不再是聊天工具而是一项需要专业管理的工程活动。这篇内容就是我自己实践路径的完整复盘AI 擅长写什么、不擅长写什么怎么描述需求才能让 AI 交出可靠代码生成之后的审查、测试、落地又要怎么把关。1. 从帮我写个函数到代码流水线合伙人我的实践路径1.1 第一阶段把 AI 当记忆增强器最早用 AI 生成代码我的心态很朴素把它当成一个永不疲惫的 Stack Overflow。遇到 API 用法记不清、某个正则表达式写不出来、某个 SQL 联查想偷懒就丢一句话让它给我答案。这一阶段的体验确实爽尤其是一些孤立的小片段比如把时间戳转成指定格式、解析一个 JSON 字段、写个简易爬虫AI 基本一两轮就能给出能跑的代码。但这个阶段的失败率也很高高到让我一度怀疑自己是不是不会提问。最典型的场景是框架版本差异我让 AI 写一个老项目的 Spring Boot 接口它默认按新版本语法生成结果依赖注入的写法完全不同编译直接挂掉。后来我才意识到AI 对当前项目里正在用的框架版本没有感知能力我把它当成搜索引擎用却不给它搜索引擎该有的限定条件它自然会按照训练数据里最主流的写法输出而主流版本不一定就是我的项目版本。1.2 第二阶段学会把验收标准前置吃了版本差异的亏以后我开始强迫自己改变提问方式不再说帮我写个XX而是说请写一个满足以下输入输出规则的函数使用 Java 11 的语法项目里已经引入了 Lombok不要新增依赖处理 null 输入的期望是抛出 IllegalArgumentException。这样描述之后代码的可用率显著提升。这个阶段我开始意识到一个关键现象AI 生成代码的水平很大程度上取决于我把需求描述得多清楚。它不是读心术更不是按个按钮就自动完成的魔法。凡是让 AI自由发挥的任务它就会真的自由发挥交出的代码从结构化角度来看挑不出大毛病但落地时处处需要修补。相反当我像写需求文档一样把输入、输出、异常、边界、依赖约束、验收标准列清楚AI 一次生成就能通过测试的概率高得惊人。1.3 第三阶段定位从写手变成结对同事现在我的工作方式已经稳定下来AI 负责生成初稿、解释陌生代码、编写测试用例、做机械性重构我负责定义问题、划定边界、审查逻辑、补业务规则、决定最终是否合并。说白了它像一个能力很强但没有项目记忆的结对同事我可以把重复劳动丢给它但业务正确性这项责任永远在我身上。这个转变背后有一个很现实的理由。AI 生成代码的最大风险不是代码质量差而是看起来质量很高但实际上是错的而且它错得很自信不会在任何阶段提示你我不确定这里的业务规则。如果你把 AI 当成可以交付责任的员工早晚会在生产环境里付出代价。把它当工具把责任机制捏在自己手里才是可持续的使用姿势。2. 给任务分个类AI 擅长什么不擅长什么2.1 一张粗粒度的能力地图经过大量真实项目的测试我整理出这样一张经验地图任务类型适合程度注意事项CRUD 样板代码高直接生成后仍需检查权限和事务边界单点算法排序/解析/格式转换高用测试向量验证尤其是边界值胶水代码API 对接、类型转换高依赖协议文档需核对字段映射单元测试初稿高AI 容易漏边界生成后自己再补框架配置 / 依赖声明中版本兼容性要人工确认性能优化中让它给思路很安全直接合并要警惕含复杂业务规则的逻辑低规则隐含在需求里AI 不可见安全敏感代码低严禁不经人工深度审查直接采用硬件相关 / 时序相关代码低实时性、寄存器、信号量很难验证对比出来就能发现AI 生成代码的价值高低几乎和任务是否能快速验证成正比。一个函数能不能处理空字符串、负数、超大数跑几个测试用例立刻见分晓这类任务交给 AI 非常划算。反过来一套计费规则对不对、一个权限判定是否漏了角色边界、一条数据库迁移会不会破坏历史数据这些事短时间内很难验证AI 生成得再快你也只能把它当草稿看。2.2 可验证性决定 AI 代码可靠性的核心指标我有个很朴素的原则让 AI 写能快速跑测试的代码不要让它写不能验证的代码。这一点在工程上非常关键。为什么 AI 写算法题特别靠谱因为它见过海量类似题而且这类题有明确输入输出模型在训练中见过大量配对示例。为什么 AI 写某些业务代码不靠谱因为业务规则是项目私有的训练数据里不可能有完整上下文模型只能在语言概率上给你凑一段看起来符合业务描述的代码它无法验证这段代码在真实业务里是否成立。如果不能把验证成本降下来AI 的效率优势就会被人工查业务规则的时间吃掉。所以我现在接任务时的第一反应不是这个能不能让 AI 写而是这个能不能在半小时内写出自动化验证方案。能就可以大胆让 AI 生成再交给测试把关不能就把它拆成更小的可验证单元或者干脆自己写核心逻辑让 AI 只负责外围代码。2.3 自信错误是 AI 生成代码最大的坑AI 生成代码有一类非常危险的输出行业里通常叫一本正经地胡说八道。比如你问它某个 API 的用法它可能把参数名、返回值、异常类型都编得有理有据但这个 API 根本不存在或者在新版本里早已废弃。这种错误你乍一眼看不出来因为代码风格太正常了。我处理这个问题的办法很简单对不熟悉的库让 AI 先给出你确定这个 API 存在吗的解释和官方文档链接再决定是否相信。如果它给不出来或者含糊其辞那就按纯概率输出处理宁可自己查一遍文档也不要直接复制。忠实训练数据的模型没有核实事实的能力它只是在预测最可能的 token 序列你可以把它当成一个记忆力极强但会脑补的同事绝不能当成一个可以追溯准确性的权威知识库。3. 提示词是需求规格说明不是聊天3.1 一个经典的反面案例很多人在让 AI 生成代码时只给一句话帮我写一个用户登录接口。这个提示词从聊天角度看没问题但从工程角度看约等于什么都没说用户信息存在哪里密码怎么存登录之后要返回什么失败多少次要锁定接口是给 web 端还是 app 端超时时间多少这些需求细节全部缺失AI 只能按最常见的假设补全出来的代码自然和你的项目场景错位。我就见过同事用这种提示词让 AI 写用户登录接口AI 生成的代码用的是明文密码比对注释里还写着示例代码生产环境请使用 BCrypt——它已经好心提醒了但仍然交了一版不可用于生产的实现。问题不在 AI而在提问者没有把密码必须加密存储这条硬性约束放进需求里。3.2 用结构化提示词把需求说清楚我现在写提示词时基本会遵循一个固定结构不一定要每项都无脑填满但关键信息必须齐全目标写一个 Python 函数输入字符串列表输出去重后保持原顺序的列表。 约束 - Python 3.10不引入第三方依赖 - 输入包含 None 时跳过 None - 保留第一次出现的元素 示例 输入 [a, b, a, c] - 输出 [a, b, c] 输入 [None, x, None] - 输出 [x] 验收写一个 pytest 测试函数覆盖上面两个示例以及空列表。这种提示词没有多余废话但把 AI 从猜变成了按规格实现。它会知道边界情况如何处理也知道要在测试里验证这些边界。实际体验下来一次通过的几率远高于帮我写个去重函数这种模糊指令。3.3 迭代修正的正确姿势给出失败样例和期望输出没有人能保证第一次提示就完美AI 也一样。但很多人的第二轮追问很不讲章法只会说不对再改改。AI 根本不知道哪里不对只能瞎猜这样来回几次双方都会崩溃。我比较推荐的做法是明确提供失败样例和期望输出。比如当输入是数字字符串 123 时你的代码返回了 123但我期望保留字符串类型 123因为调用方后续要做字符串拼接。这样 AI 能精准定位问题原因而不是凭空推理。把这套方法固定下来你会发现 AI 的听话程度提升一个量级因为你不是在让它猜需求而是在和它一起对一个明确目标做迭代。3.4 上下文要给但不要无限堆另一个常见误区是给 AI 塞过多无关上下文。有人为了保险把整个项目的 README、数据库表结构、十几段关联代码全部粘贴过去结果模型被大量信息淹没反而抓不住你真正要它改的那一小块。正确做法是只提供当前任务直接相关的上下文一个函数定义、一个接口契约、一段报错堆栈、一个最小可复现的输入样例。如果你想让它修改一个已有函数那就把那个函数完整贴出来并指出第几行需要改如果你想让它对接一个新 API那就提供 API 的字段说明文档或 JSON 示例。上下文数量不是越多越好而是越精越好。4. 生成之后的落地关卡审查、测试、重构4.1 我的代码审查清单如果是人工写的代码我们会走 code reviewAI 生成的代码也一样而且审查标准只能更严。我自己的团队现在规定凡是 AI 生成的代码合并前必须过一遍统一的审查清单重点看下面前六项依赖与许可证AI 有没有为了省事引入一个你不知道的第三方库这个库的许可证允许商业使用吗安全面有没有拼接 SQL、直接操作文件路径、打印敏感信息、硬编码密钥副作用AI 生成的函数内部有没有发起网络请求、写数据库、改环境变量这些隐性副作用调用方根本看不见。错误处理异常路径是否覆盖了所有失败情况还是只写了 try 块、catch 里什么都没有边界条件空输入、超长输入、并发场景下会不会炸命名和风格AI 有时候会自己发明一些不合理的命名比如把用户名称命名为 ue把订单状态命名为 os。性能有没有在循环里执行 SQL、有没有 N1 查询、有没有算法复杂度爆炸。我之所以把安全面和副作用放得这么靠前是因为 AI 本身对什么操作会有严重后果缺乏真实感知。它知道删除表是一个 word但它不知道这个 word 落在生产环境意味着什么。代码能不能跑通是它要负责的代码跑起来之后会不会造成破坏这是审查者必须把关的。4.2 让测试用例当验收裁判有一种极其好用的工作流推荐给大家先让 AI 写测试用例再让它写实现。听起来反直觉却非常符合工程逻辑。AI 生成的测试用例通常比实现更接近需求因为测试描述的是输入输出关系不涉及复杂内部逻辑。实际执行路径是这样的我先写几个关键测试用例覆盖正常路径和几个边界值然后把测试文件交给 AI让它实现函数直到测试全部通过。如果 AI 第一次实现的代码被测试打回它会根据测试失败信息自己调整逻辑往往一两轮就能给出正确实现。这个方法把生成代码是否可靠从主观判断变成了测试是否通过的客观事实特别适合没有积累足够代码审查经验的新手。当然测试用例本身也可能是错的尤其是 AI 生成的测试。所以关键测试的断言仍然需要你人工看一遍。但它已经把花时间写测试的成本压下来了剩余的人工校验量小很多。4.3 重构别把 AI 代码当黑盒AI 生成的代码很多时候是逻辑正确但结构冗余的。它可能写出一堆不必要的中间变量也可能为了一个简单场景生成一个过度设计的类。这些代码如果直接被合入主干后续维护成本会一直累积。我的习惯是测试通过之后先通读一遍代码把明显冗余的部分手动精简把命名统一成项目风格把机器味很重的注释删掉换成能解释为什么的注释。这一步一定要在测试通过之后再做确认重构不改变行为也不要边生成边改那样出了问题很难定位是生成问题还是修改问题。保持AI 生成 → 测试验收 → 人工重构 → 再测一遍的节奏代码质量会稳定很多。5. 从单次生成到多步骤 Agent 协作5.1 自动补全和 Agent 到底有什么区别现在市面上的 AI 编程工具大致分两类。一类是自动补全型你写一个函数名它帮你补完剩下部分典型如 GitHub Copilot 的补全模式另一类是 Agent 型它不止补全代码还能读取仓库文件、搜索符号定义、运行测试、根据报错自己修代码典型如 Codex 模式下的自动修复流程。两者适用范围完全不同。自动补全适合你心里已经有方案只想减少打字量的场景它像输入法灵感来自你的上下文但也只限于局部。Agent 型适合你只有目标还要探索路径的场景它像实习生你把一个 issue 丢给它它自己去翻代码、写改动、跑测试最后提交一个 pull request 给你审查。但越往 Agent 方向走权限和责任边界就越要划清楚否则一个实习生把测试库清了最终负责的还是你。5.2 本地部署模型的账要算清楚受数据合规要求影响不少团队会考虑本地部署大模型来生成代码。这个方向确实有意义尤其当代码仓库涉及不可外发数据时本地模型是最稳妥的方案。但我想特别提醒的是本地部署不是装个 Ollama 跑一下 Qwen 或者 DeepSeek 就完事。本地模型的能力上限受显存和量化影响很大7B 级别的模型在日常补全里表现尚可但面对复杂业务逻辑的改写任务质量和云端大模型有明显差距。很多团队部署完之后发现生成结果没法直接使用反而增加了人工校验成本。我个人建议算清楚两笔账一是硬件成本二是人工返工成本。如果本地模型生成的代码需要你花三倍时间修复那它省下的那点数据外泄风险未必划算。反之如果你的需求大多是样板代码生成本地模型完全够用那就用。5.3 一个最小可用的 AI 代码工作流在真实团队里我把 AI 生成代码落成了一个最小工作流这里分享给大家编码前先写好需求说明和验收条件哪怕只是几行注释也要让 AI 有据可依。用 AI 生成初稿或重构方案只负责解决怎么实现不负责定义该不该做。单元测试先行AI 生成测试用例或实现代码两边相互校验。人工 code review按上面提到的审查清单逐项过。通过后合入并在提交说明里标注部分代码由 AI 生成已人工审查。这套流程看起来朴素但底层逻辑是让 AI 承担产生候选和执行验证的角色把人留在做决定的位置。团队里真正产生分歧的从来不是这段代码是不是 AI 写的而是这段代码背后的业务规则到底谁说了算。规则这东西AI 永远不能替你做主。6. 四个真实场景复盘批处理、嵌入式、C 工具库、工控逻辑6.1 Windows 批处理优化脚本AI 能写你敢不敢跑网上经常看到类似的提问帮我生成一段 bat 批处理代码用于优化 Windows 系统的游戏性能包括关闭不必要的后台服务、调整电源模式为高性能、优化网络延迟、清理系统临时文件。这种请求 AI 确实能响应得很快但我要泼一盆冷水AI 生成的批处理代码可能是所有代码类型里最危险的之一。因为它不是运行在隔离环境里的应用代码而是直接在操作系统上执行的命令。它可以把服务设置为禁用、修改电源计划、调整网络参数、删除临时目录内容任何一条命令的失误都可能导致系统异常甚至需要重装。我自己不是不做这类优化而是会在 AI 生成之后逐条审查把每一条命令的意思查清楚再看它改的是什么注册表键、什么服务名称。之后在虚拟机里跑一遍确认系统无恙后再在真机上操作并且提前创建还原点。对关闭后台服务这类高风险项我的原则是宁缺毋滥不确定用途的服务就不关收益再大也不拿系统稳定性冒险。6.2 STM32CubeIDE 无法生成代码嵌入式环境的边界问题嵌入式方向有另一个常见求助主题STM32CubeIDE 无法生成代码配置界面点了生成但工程里没有出现对应的初始化代码。这类问题表面上和 AI 生成代码没关系但它恰好说明了自动生成代码这件事在嵌入式领域的历史和边界。STM32CubeMX / STM32CubeIDE 本质上就是一种代码生成工具它根据引脚配置和时钟树自动生成 HAL 初始化代码。很多开发者对它生成的代码习以为常甚至觉得自动生成的代码不用看。但实际工程里真正难的不是初始化代码而是初始化之后的业务代码怎么和这些自动生成代码协同。AI 能很好地帮你写 HAL 库的调用、外设驱动的封装但它对寄存器时序、中断优先级、DMA 通道冲突等硬件约束缺乏感知。我见过 AI 生成的 ADC DMA 读取代码看起来完全符合 HAL 文档但实际采样值一直是 0最后排查下来是 DMA 时钟没开启。硬件世界的信息不会出现在训练数据里AI 看不到你的电路板。所以嵌入式场景我用 AI 生成代码时边界守得特别死算法层、协议解析层可以交给 AI寄存器配置、时序关键路径必须自己看数据手册。6.3 轻量二维码 C 代码别让 AI 从零重写标准另一个非常有代表性的场景是生成轻量二维码 C 语言代码。很多人以为 AI 可以像写排序算法一样把二维码编码算法完整生成出来。这里必须说句实话二维码编码涉及 ISO/IEC 18004 标准包括模式选择、纠错码计算、掩码规则、版本信息等多个环节任何一个细节出错生成出来的图案都无法被扫码器识别。AI 对这种标准实现类任务最合理的输出不是从零造轮子而是推荐现有成熟库并写出封装代码。比如用 qrencode 库完成核心编码由 AI 生成调用接口、内存管理和文件输出逻辑这样既轻量又可靠。我的建议是遇到标准算法类需求让 AI 做集成者而不是发明者。你可以请它解释标准、对比库的许可证、生成调用示例但别指望它能精准默写一整个标准实现测试向量稍微多几条它就会露出马脚。6.4 工控 PLC 代码生成验证成本高到不可承受工控领域现在也有人尝试用 AI 生成 PLC 代码这同样属于高风险低收益的方向。PLC 代码运行在生产设备上可能控制电机、阀门、温度回路一旦逻辑错误轻则停机重则安全事故。AI 能做的辅助是有限的生成注释文档、生成仿真环境里的 HMI 通讯代码、生成报表逻辑等这些不影响实际控制逻辑的部分可以放心尝试。但涉及安全回路、急停逻辑、联锁保护的部分绝对不能直接让 AI 生成然后合入。工控行业最重视的东西叫可追溯性代码背后的每个逻辑都要求能回溯到安全规范和技术标准AI 生成代码天然缺少这种追溯链条。7. 效率与责任AI 生成代码时代程序员在守什么7.1 技术判断力是无法外包的部分AI 生成代码让打字变得极其廉价但这不代表开发者失去价值。恰恰相反开发者的核心价值变得更加聚焦判断力。你要能判断这段需求是否合理、这个技术方案是否适合当前架构、这段 AI 代码是否真正满足业务约束。判断力的来源是项目经验、行业知识、对系统运行机制的理解这些东西不是模型参数量能替代的。举个最简单的例子AI 生成了一个订单超时关闭的定时任务代码写得很漂亮分布式锁也加了测试也通过了。但如果你不知道业务上还存在超时前最后一秒用户已完成支付这种竞态条件你就会直接合入生产上就会漏单。这种行业常识不在代码上下文里也不在测试用例里只在你的脑子里。7.2 团队应该建立自己的 AI 代码准入规范我在自己带的小团队里给AI 生成代码立过几条规矩现在分享给有需要的人不允许让 AI 直接生成涉及支付、权限、数据删除、密钥管理的代码除非经过两个人以上的独立审查。所有 AI 生成的代码合并前必须有对应测试用例通过禁止裸提交。提交信息里注明哪些文件有 AI 参与方便后续出问题回溯。每周抽时间做一次AI 代码复盘把本周 AI 生成的代码里踩过的坑汇总成文档当作团队知识沉淀。这几条规矩不复杂但能把使用 AI这件事从个人英雄主义变成团队工程实践。AI 的能力是实实在在的前提是你给它设置的护栏足够稳。7.3 最后的一点个人体会用 AI 生成代码到今天是第三年我越来越觉得它像一把非常锋利的刀。刀刃越锋利越要求握刀的人知道自己要切什么、下刀的位置在哪、哪些地方必须避开。AI 生成的每一行代码都是对你想让它做什么的回应它无法对你没说的部分负责。所以我会在每次合并 AI 代码时清楚地记得将来生产环境出了 bug可以甩锅给工具但没人会替你的团队修。真正该担责的始终是那个点击合并按钮的人。想清楚这一点AI 生成代码对你的价值会远远大于风险。