AI生成代码的工程化落地：提示词、审查与验证

做了两年多 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 一张粗粒度的能力地图

经过大量真实项目的测试，我整理出这样一张经验地图：

对比出来就能发现，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 review；AI 生成的代码也一样，而且审查标准只能更严。我自己的团队现在规定：凡是 AI 生成的代码，合并前必须过一遍统一的审查清单，重点看下面前六项：

1. 依赖与许可证：AI 有没有为了省事引入一个你不知道的第三方库？这个库的许可证允许商业使用吗？
2. 安全面：有没有拼接 SQL、直接操作文件路径、打印敏感信息、硬编码密钥？
3. 副作用：AI 生成的函数内部有没有发起网络请求、写数据库、改环境变量？这些隐性副作用，调用方根本看不见。
4. 错误处理：异常路径是否覆盖了所有失败情况？还是只写了 try 块、catch 里什么都没有？
5. 边界条件：空输入、超长输入、并发场景下会不会炸？
6. 命名和风格：AI 有时候会自己发明一些不合理的命名，比如把用户名称命名为 ue，把订单状态命名为 os。
7. 性能：有没有在循环里执行 SQL、有没有 N+1 查询、有没有算法复杂度爆炸。

我之所以把安全面和副作用放得这么靠前，是因为 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 生成代码落成了一个最小工作流，这里分享给大家：

1. 编码前，先写好需求说明和验收条件，哪怕只是几行注释，也要让 AI 有据可依。
2. 用 AI 生成初稿或重构方案，只负责解决"怎么实现"，不负责定义"该不该做"。
3. 单元测试先行：AI 生成测试用例或实现代码，两边相互校验。
4. 人工 code review，按上面提到的审查清单逐项过。
5. 通过后合入，并在提交说明里标注"部分代码由 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 生成代码对你的价值，会远远大于风险。