最近大半年我一直在一线写代码也一直在折腾 AI 代码生成。从最开始拿它补全几个函数到后来直接让它写完整的模块、生成单元测试再到把 AI 拉进工控项目里写 PLC 程序这一路下来最大的感受就八个字真能干活但得管着用。今天这篇文章我不打算讲什么高深理论而是把我自己从体验到落地全过程里踩过的坑、试对的路、总结出来的规范原原本本分享出来。不管你是刚听说 AI 代码生成、想试试水的开发新人还是已经用了几个月但总觉得生成代码“不听话”的老手这篇文章都值得你花十分钟看完。先给没接触过的朋友一句话解释AI 代码生成就是让大语言模型根据你给的描述、上下文和约束条件直接产出可用代码。它不像传统 IDE 的自动补全那样只能猜你下一个单词而是能理解一整段需求再“组织语言”把它变成代码。这个能力一旦用顺了写重复代码、写胶水代码、写测试用例的效率提升是肉眼可见的。但反过来说如果完全放手让它自由发挥你收获的可能是表面漂亮、跑起来就翻车的“幻觉代码”。所以这篇的主线很明确AI 代码生成能做什么怎么把它纳入规范流程以及我在嵌入式、Web、PLC 三类项目里的实战记录与避坑经验。1. AI代码生成到底在生成什么先拆掉那层神秘感很多人以为 AI 代码生成就是个“加强版 Tab 补全”其实完全不是一回事。它的底层是语言模型也就是说它不是在“查代码”而是在“预测代码”。你给它一句注释、一段上下文它会根据海量开源代码里学到的模式一个 token 一个 token 地把最可能出现的代码“续写”出来。理解这一点特别重要因为它决定了你该怎么和它协作你得把它当成一个“读过很多代码但偶尔会编瞎话的实习生”而不是一个“绝对可靠的老专家”。1.1 代码补全与续写最常用的基础能力代码补全是所有人最先接触到的能力。我在 IDE 里用 AI 插件写 Python 和 JavaScript 时体验最顺的场景有三个重复性的样板代码、机械的 CRUD 接口、数据结构转换。比如你刚写了一个字典的键AI 已经把你想要的所有逻辑列出来了你写完函数签名它能把函数体给你补完。这种场景下模型的上下文越长补全质量越高。但它也有明显的边界。补全只适合“局部的、模式明确的”代码生成。如果你在一个超长文件里、函数嵌套很深的地方让它补全它很容易被前面的无关代码带偏生成出来的函数逻辑写着写着就和主流程断开了。所以我现在的习惯是补全功能只在函数级以下使用一旦要生成完整模块就单独开一个新的对话给它干净的上下文。1.2 注释转代码把需求“翻译”成实现注释转代码是我现在最依赖的能力。你可以先写一句人话比如“读取配置文件返回字典缺省值设为空”AI 就能把读文件、处理异常、返回默认值这一整套逻辑写出来。这个能力适合做两类事一是你不熟悉的语言或框架让 AI 先给你一个“能跑的骨架”二是你不愿意碰的胶水代码比如格式转换、参数校验、日志封装。不过这里有个很容易被忽视的前提注释本身必须写清楚边界。如果你只说“处理一下数据”AI 大概率会想当然地假设输入输出格式等你拿去一跑才发现完全对不上。正确的做法是给注释补上“输入是什么、输出是什么、边界条件怎么处理”。比如“将列表中的数字字符串转换为整数忽略空值和非法字符返回新列表”这么写出来的代码基本不用改。1.3 单测生成、重构建议与代码解释被低估的三驾马车很多人把注意力全放在“让 AI 帮我写业务代码”上却忽略了另外三个实用性极高的能力单测生成、重构建议、代码解释。单测生成我是强烈推荐的。你写好一个函数直接把函数贴给 AI让它生成 pytest 或 JUnit 测试用例它会自动补上正常场景、边界场景、异常场景。虽然它生成的测试偶尔会“自我验证”就是用例写得和实现一样测不出 bug但只要你在 prompt 里强调“覆盖空值、超限、异常输入”质量就有保障。重构建议则适合拿来当“第二双眼睛”。写完一段有点乱的代码让 AI 从可读性、性能、命名三个维度提意见它给的很多建议确实有参考价值。代码解释更不用说接手别人留下的老项目时把一段看不懂的逻辑扔给 AI它能用人话讲清楚这段代码在干什么、大概的数据流向是什么。这三项能力的共同特点是它们天生就是“低风险”的因为代码已经在你的掌控中AI 只是辅助不会替你拍板。2. 一次完整的AI代码生成实操从Prompt到可用代码光说不练假把式。下面我带大家完整走一遍我现在最常用的实操流程拿一个真实的例子来讲让 AI 生成一个批量任务进度计算工具。这个例子不复杂但足够覆盖“需求拆解—Prompt 编写—生成—评审—修正”全流程。2.1 明确需求写一个什么样的程序我的需求是给一个生产管理工具写个函数输入是一批任务的总数和已完成数输出是剩余数量以及完成百分比。听起来很简单但如果直接这么跟 AI 说它写出来的代码多半会漏掉边界判断——比如总数为 0 怎么办、已完成数大于总数怎么办、百分比要不要保留小数。所以我在动手前会先花两分钟把需求彻底说清楚。自己心里先回答这几个问题函数入参是什么类型出参是什么结构异常和边界怎么处理外部依赖要不要这一步做扎实了后面生成的代码几乎不会跑偏。2.2 编写高质量Prompt上下文、约束、示例一个都不能少我自己总结出一套 Prompt 公式虽然不那么花哨但实操中特别稳定角色 任务 输入输出 约束条件 示例。我实际使用的 Prompt 是这样的你是一个经验丰富的Python开发工程师。 请实现一个函数 calculate_task_progress。 输入completedint已完成任务数、totalint任务总数。 输出返回一个字典包含 remainingint剩余任务数和 percentfloat完成百分比保留2位小数。 约束当total小于等于0时抛出ValueError当completed大于total时按completed等于total处理。 补充说明不要引入第三方库函数体尽量简洁并写好中文注释。这个 Prompt 看起来没什么特别但每个部分都有用。角色限制让模型默认采用经验丰富工程师的风格输入输出约束消灭了最常见的“参数猜错”问题边界条件说明则大幅降低幻觉代码出现的概率。等生成完代码我把函数复制进来附上几组调用示例再让它补一组 pytest 用例。整个过程五分钟不到得到的东西是干净、可测试、几乎不用改的。2.3 生成后的代码评审与修正真正的分水岭AI 生成的代码从来不该直接进主干。我每次拿到生成结果会先做一轮“人工 code review”重点看三处第一输入输出类型是否和调用方一致第二边界条件是否覆盖第三异常路径会不会吞掉关键错误。举个例子有一次我让 AI 写一个读配置文件的功能它生成得非常完整但我在评审时发现它把文件不存在的异常直接 except 掉并返回空字典。这样一来配置写错了系统也不会报警以后排查问题会非常痛苦。发现这个问题后我只需要再补一句“文件不存在时抛 FileNotFoundError而不是静默处理”它就能立刻改对。这里想强调一个非常重要的心得AI 生成代码的迭代成本极低所以不要指望一次生成就完美更不要自己默默手工修补。你发现任何不满意的地方都可以回到对话里继续提要求让它改。把“AI 初稿 人工评审 多轮对话修正”当成标准闭环远比“AI 初稿 人工大改”效率高。3. 当AI去写PLC代码工控领域的真实体验说完常规软件聊点更有挑战性的我最近把 AI 代码生成用到了 PLC 编程上这也是“ai plc代码生成”这个热词背后很多人关心的场景。说实话第一次看到 AI 写结构化文本ST代码时我是有点怀疑的毕竟工控讲究的是稳定可靠代码必须在 PLC 上跑几十年不出毛病。但实际体验下来它确实有一些出人意料的亮点。3.1 PLC编程的痛点和AI介入的价值传统 PLC 编程最大的痛点不是“写不出来”而是“重复劳动太多”。一个稍微大点的项目模拟量处理、设备联锁、批次计数、报警汇总这些功能块每个项目都得写一遍逻辑大同小异却要逐行敲。以前老工程师的做法是复制上一个项目的代码再改参数但这样效率低不说还容易复制漏。AI 代码生成恰好能切进这个空白地带你给它一个功能描述它能迅速给你生成一个符合主流编程习惯的 ST 功能块。另外很多一线电气工程师熟悉梯形图却不熟悉 ST这时候 AI 还能当一个“翻译官”。你用大白话描述清楚逻辑它给你写出 ST 代码你再拿到软件里转成功能块学习成本直接降了一大截。这个价值做过工控的人应该都能懂。3.2 用AI生成ST结构化文本的实操示例我拿一个最常见的需求来演示批量计数功能块。要求是每次触发信号加一达到设定批量值后输出一个完成的脉冲并自动清零。我给 AI 的 Prompt 是这样请用IEC 61131-3结构化文本语言编写一个功能块FB_BatchCounter。 输入bTriggerBOOL上升沿触发、iSetValueINT批量设定值。 输出bCompleteBOOL计数达到设定值时输出一个扫描周期的高电平、iCurrentCountINT当前计数值。 变量使用功能块内部静态变量不使用外部全局变量。 行为触发信号每产生一次上升沿当前值加1当前值达到设定值时完成输出置位如果设定值小于等于0则完成输出立即置位。它生成出来的代码大致是下面这样逻辑清晰还配好了注释FUNCTION_BLOCK FB_BatchCounter VAR_INPUT bTrigger : BOOL : FALSE; iSetValue : INT : 0; END_VAR VAR_OUTPUT bComplete : BOOL : FALSE; iCurrentCount : INT : 0; END_VAR VAR bLastTrigger : BOOL : FALSE; END_VAR (* 上升沿检测 *) IF bTrigger AND NOT bLastTrigger THEN IF iSetValue 0 THEN bComplete : TRUE; ELSE iCurrentCount : iCurrentCount 1; IF iCurrentCount iSetValue THEN bComplete : TRUE; iCurrentCount : 0; END_IF; END_IF; END_IF; bLastTrigger : bTrigger; (* 完成信号保持一个扫描周期 *) IF NOT bTrigger THEN bComplete : FALSE; END_IF;说实话这段代码的完成度已经超过了我见过的一部分外包代码。我把它导入编程软件后只做了两处调整一是把内部静态变量统一加上了默认值声明二是把完成信号的复位逻辑改成了由外部指令控制。整体下来原本要写二十分钟的功能块现在五分钟就能搞定而且格式比手工敲的还规整。3.3 AI生成的PLC代码为什么必须人工审核但是重点来了。我在用 AI 写 PLC 代码时踩过最大的一个坑是它会把“看起来像 ST 语言的伪代码”和“真正的 IEC 61131-3 代码”混在一起。有一次它给我生成一段数组遍历的逻辑直接用了 Python 风格的for i in range(len(arr))这种写法在 PLC 软件里根本编译不过必须改成 ST 的 FOR 循环。还有一次它在功能块里用了类似return的语法这在 ST 里也是不支持的。所以我的结论非常明确AI 在 PLC 领域只能定位为“提效助手”不能是“代码作者”。尤其是在安全联锁、急停、报警回路这类关键逻辑里我会明确要求 AI 只做代码解释和结构建议实际代码全部自己手写。不是不信任它而是 PLC 代码一旦出问题轻则停机重则出安全事故这个责任没有任何 AI 能替你承担。4. AI Coding的规范与示例别让模型自由发挥用 AI 写代码这件事本质上和带新人写代码一样你不立规矩他就会按自己的习惯乱来。AI 模型训练出来的“平均风格”未必符合你项目的编码规范所以从第一天起就该把规范前置。这也是“ai coding 代码生成规范示例”这个热词背后真正的需求。4.1 从“能跑”到“规范”代码生成规范的必要性我见过不少团队引入 AI 工具后代码审查反而更痛苦了。原因很简单AI 生成的代码“太有个性”。同一个功能你这次生成的代码用for循环下次生成的代码用列表推导式这次变量名是count下次是cnt。如果每个人都按自己的习惯去用 AI代码库的风格就会迅速失控。但规范并不是要扼杀效率。我建议团队建立一份“AI 代码生成使用规范”里面至少包含四块内容语言与框架版本、命名与格式要求、禁止生成的高风险代码清单、提交前的自检动作。特别是高风险代码清单我会把“涉及加解密、现金支付、设备安全、权限校验的代码”全部列入这类代码默认禁止用 AI 出初稿只能让 AI 做检查和建议。4.2 一套可直接照抄的Prompt模板分享一个我们团队内部在用的通用 Prompt 模板你可以直接复制调整。这套模板的核心是让 AI 在生成代码前先“复述需求”避免它一上来就闷头写。我现在要开发一个功能请先不要写代码按下列格式向我确认需求 1. 语言和框架版本 2. 函数/模块的输入输出 3. 异常和边界处理 4. 对性能的要求 5. 不允许使用的第三方库。 确认后再按项目现有代码风格输出实现要求包含完整注释并附上至少三组调用示例。这个模板的巧妙之处在于它把“需求对齐”前置了。大部分 AI 代码生成翻车都不是模型不够聪明而是需求没对齐。你先让它复述一遍需求如果你发现它理解偏了现在纠正的成本几乎为零等它写完整段代码再纠偏那成本就高了。4.3 团队落地AI Coding时的几点铁律最后分享几条我们落地的硬性规则都是实践里用代价换来的。第一AI 生成的代码必须经过真人审查才能提交这条没有任何例外。第二关键业务模块的代码生成不要用在线网页版尽量在 IDE 插件或公司内部部署的服务里完成防止源码外泄。第三生成代码中不要包含任何真实密码、密钥、IP 地址提示词里也不能出现。第四每次生成后至少让 AI 再输出一组测试用例不管最后用不用这个过程能逼着模型把边界条件想清楚。第五不建议让 AI 同时修改多个文件的大型重构任务它容易改到一半“忘掉”你最初的约束。这几条看起来不起眼但执行和不执行团队的差别会非常大。我见过一个同事严格执行这些规矩三个月后他不但没有沦为“AI 的操作员”反而因为能更快地评审和修正 AI 代码实际编码能力肉眼可见地涨了一个台阶。AI 代码生成用得好是杠杆用不好是拐杖。5. 常见问题与排查技巧实录我踩过的坑你尽量避开最后这部分我把这一年多来自己踩过、也帮别人排过的高频问题整理出来做成一份速查表。这些问题普遍到什么程度呢可以说只要你开始认真用 AI 写代码早晚会遇见。5.1 幻觉代码看着合理跑不通这是所有 AI 代码生成使用者遇到的第一座大山。所谓幻觉代码就是 AI 一本正经地“编造”了一些看起来合理、但实际不存在的 API 或函数。我之前让它写一个操作 Redis 的脚本它给我推荐了一个根本不存在的第三方库还把连接参数写错了。遇到这种情况我一般的排查顺序是这样的先看报错信息里的函数名是否真实存在再看导入的库是否已安装、版本号是否匹配最后看有没有类型不匹配。如果代码逻辑没问题但就是跑不出预期结果我会把输出结果原样甩给 AI让它解释哪一步和预期不一致。多数情况下它都能自己发现问题并修正。记住一句话AI 写代码是“按概率生成”不是“按真相生成”所以任何不确定的 API 都要回到官方文档核实。5.2 上下文丢失聊着聊着就忘了最初的约束用过 AI 编程的人都有这种经历前十分钟它还在老老实实按你的要求写聊着聊着它开始“自由发挥”把你开头强调的约束全忘了。这不是模型故意使坏而是它的注意力会随着输入变长而分散。我的解决办法是项目开始时就把所有硬性约束写在一个固定的文本块里每次开启新话题时重新贴上如果对话超过二十轮果断开新会话把这个约束块再贴一遍。另外把任务拆得足够小也很重要。一个会话只让 AI 干一件事比让它在一个会话里连续完成五个任务可靠得多。5.3 安全与合规谁为生成的代码负责这点我必须放在最后压轴说。AI 生成的代码可能存在你根本发现不了的漏洞这可能比你手写代码的风险更高。因为模型训练数据里的代码良莠不齐它学到的高频写法未必是安全的写法。比如写 SQL 时它可能天然使用了字符串拼接写鉴权时它可能忽略越权检查。这些风险AI 不会主动告诉你。所以我的个人体会是AI 代码生成是放大器它放大的不只是你的生产力还有你的代码隐患。你自己越懂安全、懂规范AI 生成的代码就越安全你自己一知半解AI 只会让问题更快地扩散。真正为代码负责的永远是人而不是模型。最后再分享一个小技巧我每次拿到 AI 生成的代码都会特意跑到官方文档里把涉及的关键 API 逐条过一遍。这个动作看着费时间实际上能避开百分之八十的隐性坑。AI 代码生成这条路走得越稳就越能走远。你把它当成一个快速出初稿、帮你拓宽思路的搭档而不是替你拍板的决策者它会成为这个时代最好用的编程工具。