先说个现象现在很多人用AI写代码确实能跑通Demo但一提到“生产级”三个字就露馅了。尤其是效果广告引擎这种对延迟、并发、稳定性极度敏感的系统AI生成的结构性代码往往只是“看起来像那么回事”真要上线各种隐性问题全冒出来。我在一个效果广告引擎项目里完整趟了一遍AI Coding的流程从需求拆解到代码生成、自动化验证、CI/CD集成最后确实让AI承担了不少模块的开发但踩过的坑比想象中多得多。这篇就是我自己的实践记录适合正在把AI编程往正式项目里推的团队也适合想搞清楚“AI写代码到底能写到什么程度”的开发同学。1. 项目背景与目标拆解1.1 广告引擎代码的特殊性效果广告引擎有一套自己的脾气。它不是普通的CRUD应用核心链路里全是高并发请求、实时竞价、预算控制、频次过滤、算法打分排序每一环都在毫秒级响应。代码层面要同时兼顾性能、可扩展性和可运维性很多模块看起来逻辑简单但隐含的边界条件多得离谱。比如一个广告投放相关的计数服务表面上就是“累计消耗金额超过预算就停止投放”但实际要考虑不同币种、不同扣费模式、异步对账、双写一致性、缓存穿透等问题。像这种代码如果直接让AI看一句话需求就写写出来的东西肯定骨架完整但细节全错。更麻烦的是广告引擎的代码往往运行在深度定制的Java框架上内部有自己的一套RPC、序列化、配置中心、监控上报规范。外部大模型训练数据里根本没有这些内部框架的用法所以AI生成代码时经常出现“拿着Spring的思维写内部RPC”的错位现象。这就决定了我们不能把AI当成一个“自动编程员”只能把它当成一个“擅长写局部代码的工程师”。1.2 我们想让AI承担什么项目启动前我先和团队定了目标不是让AI独立完成一个完整模块而是把工作拆分成更细的“编码单元”。每个单元都有一个非常明确的输入输出、依赖环境、边界条件AI在这种约束下生成的代码质量会高很多。我们实际选定了三类最适合AI承担的任务第一类是模板化代码比如标准的数据传输对象DTO、枚举定义、简单的增删改查接口。这类代码写起来重复、没技术含量但数量巨大正好是AI的舒适区。第二类是算法实现比如广告召回中的向量相似度计算、频控里的滑动窗口计数、预算池的分配逻辑。算法本身的伪代码或公式是公开知识AI生成后我们只做边界校验和性能优化。第三类是单元测试这个后来成为整个实践里收益最高的部分。让AI根据业务代码和分支覆盖要求生成测试用例比让AI写生产代码稳定得多。我们没有让AI碰的是涉及资金安全、分布式事务、跨团队接口协议的核心代码。这不是不信任AI而是这类代码出问题的代价太高人工评审成本也会抵消AI带来的效率收益。把边界划清楚后面推进才顺利。1.3 生产级代码的定义团队内部对“生产级”有一个共识清单不是“能跑”就行。这份清单后来也成了AI生成代码的验收标准第一正确性必须通过全部单测、集成测试并且覆盖关键分支和异常分支。第二性能核心接口的TP99不能比原有代码差内存分配、对象创建、锁粒度都要符合性能要求。第三可读性命名清晰逻辑直白注释说明“为什么”而不是“是什么”。第四可维护性代码风格与团队规范一致可以被人轻松review和修改。第五可观测性必须包含日志、指标上报、异常链路信息方便线上排障。第五点很容易被忽略。AI生成的代码通常没有日志意识出问题后完全看不到链路信息这在广告引擎这种需要快速定位的系统里是致命的。所以后来我在提示词里专门加了“必须打印关键路径日志”的要求。2. 整体方案设计从“单次生成”到“编码流水线”2.1 为什么不直接用大模型写整个模块最早做过一个实验把整个广告创意的过滤模块需求扔给大模型让它一次生成完整代码结果非常“惊艳”——接口齐全、层级清楚、注释完整。但一进代码评审就发现问题了。首先是抽象过度。AI为一个两万行不到的模块生成了六个设计模式服务层、工厂层、策略层、模板层全堆上代码量膨胀了一倍。其次是错误处理思路有问题大量catch了所有异常然后打日志导致调用方完全感知不到业务失败。再加上内部框架的规范几乎没有一条是对的整个模块基本不能用只能当参考。这个实验让我明白大模型擅长的“全局设计”其实建立在它见过的通用模式上而每个项目的内部规范、历史债、性能约束都是非标准的。与其让它做架构不如把架构定死只让它做实现。所以我们把AI定位成“流水线上的高级码农”而不是“架构师”。2.2 三层流水线需求拆解、代码生成、验证加固实践过程中我们逐渐固定了一套“三步走”的流水线每一步都有明确的人机分工。第一步是需求结构化。由我或者模块负责人把业务需求写成结构化的规格说明包括功能描述、输入输出、边界条件、性能要求、依赖的服务、异常场景。这一步绝对不能交给AI。需求结构化是整个人机协作的地基写得越清楚AI发挥越稳定。第二步是代码生成。把规格说明喂给大模型配合特定的提示词模板让它生成指定模块的代码。这一步可以多次迭代我们通常会让AI先给出实现思路人工确认思路后再生成代码减少大方向的返工。第三步是自动验证。AI生成的代码必须立刻进入静态检查、单测、代码扫描的流程。我们专门写了一个脚本把生成代码自动接入编译、测试、覆盖率统计形成“生成即验证”的闭环。不满足条件的代码直接打回重新生成不打回的话后面的人工review成本会爆炸。这套流水线跑通后单模块的平均交付周期从人工编码的三天缩短到半天。最关键的改进是把“让AI一次性写对”变成了“让AI快速试错”因为AI生成代码的成本极低反复迭代几次完全可接受。2.3 提示词工程与上下文管理提示词工程不是玄学它就是在约束AI的想象空间。我们实践出来的核心原则就一句话给AI尽可能多的“确定信息”让它做填空题而不是问答题。一个合格的生成提示词至少包含五类信息第一类角色与任务比如“你是某广告引擎团队的Java开发工程师现在需要实现一个预算消耗服务的方法”。第二类输入与输出明确入参类型、出参类型、异常类型。第三类编码规范包名、类名、方法名、日志规范、禁止使用的API。第四类业务上下文相关的业务规则、边界条件、依赖服务名称。这些信息虽然没有实际代码但决定了代码的走向。第五类痛点提醒比如“注意高并发场景下的原子性”“不要把整个对象放在锁里”“上报耗时指标”。另外上下文管理也很关键。现在的模型窗口虽然变大了但塞入大量无关代码反而会让生成质量下降。我们把项目相关的规范、示例代码、团队文档整理成几个固定的上下文片段每次生成时按需拼接。比如涉及RPC调用时就拼入标准RPC示例涉及数据库操作时就拼入DAO层规范。这套“上下文模板库”维护了三个多月已经成为团队的重要资产。3. 核心实践让AI写出可上线的代码3.1 需求规格的编写我要强调一点AI Coding最大的瓶颈不是模型而是需求表达。你给AI一个模糊的需求它只能给你一段模糊的代码。所谓“生产级代码”的起点其实是一份结构化的需求规格。我们定义的需求规格模板长这样功能名称比如“按日预算的平滑消耗控制”功能描述一段话讲清业务逻辑明确什么条件下触发什么行为输入参数参数名、类型、约束例如“预算剩余金额Long类型必须大于等于0”输出要求返回值、成功场景、失败场景业务规则逐条列出例如“如果剩余预算小于单次出价则返回竞价失败”异常处理明确哪些异常要抛出哪些要吞掉并记录日志性能要求如“单次调用不能创建超过3个对象”“锁粒度不能超过100毫秒”依赖项需要调用的下游RPC、DAO方法、配置项有了这个模板AI生成的代码基本不会漏业务分支。有一次我们让AI生成一个“频次控制”模块需求规格里只写了“用户在一天内最多看到3次同类广告”AI生成的代码就漏了跨天时间戳的处理。后来我们把时间边界条件写进规格AI立刻就补上了。每次踩坑都说明规格还得再精细。3.2 代码生成的约束与模板提示词是约束的第一层代码模板是第二层。我们在项目里维护了一个“代码骨架库”把广告引擎常见的代码结构固化成模板。AI生成代码时不是从零开始写而是在模板上填充。举个例子一个标准的RPC服务方法模板长这样public ResultSomeResponse handle(SomeRequest request) { long start System.currentTimeMillis(); try { // 参数校验 // 业务逻辑 // 成功日志与指标上报 return Result.success(response); } catch (BizException e) { log.warn(biz exception, requestId{}, errorCode{}, request.getRequestId(), e.getErrorCode()); return Result.failure(e.getErrorCode(), e.getMessage()); } finally { long cost System.currentTimeMillis() - start; metrics.record(module.method.cost, cost); } }这个模板里已经写好了日志、异常处理、耗时上报AI需要填写的只有参数校验和核心业务逻辑。这种情况下AI生成代码的生产级程度大幅提高因为它踩不到可观测性和异常处理的大坑。为了让模板真正生效提示词里我会明确写“请严格按照给定模板填充不要修改模板结构不要添加额外设计模式不要新增不必要的方法。”实践证明给AI的约束越硬代码越可控。相反如果只说“请按照团队规范”AI就会放飞自我。3.3 代码评审与静态检查的自动接入这里有一个很痛的教训AI代码刚接入CI时我们只跑了编译和单测结果上线后出了一次生产事故。原因是AI生成的代码里有一段字符串拼接逻辑单测覆盖不到极端长文本导致内存分配过大拖垮了接口性能。问题的本质是单测通过只能说明逻辑对不能说明代码对。后来我们把静态检查工具和代码扫描规则全部接入AI生成代码的验证流程。团队有统一的Java编码规范包括禁止大对象分配、禁止循环内调RPC、禁止未捕获的InterruptedException等。AI生成的代码必须过完这一整套检查才能进入人工review。我强烈建议给AI代码单独设置一条CI流水线和人工代码区分开。AI生成代码的“异味”模式很稳定大量使用Optional嵌套、过度拆分子类、忽略资源关闭、魔法数不提取等。把静态检查规则加上后这些问题会以报表形式暴露出来我们也可以反哺到提示词里告诉AI下次不要犯同样的错误。3.4 测试生成与覆盖率AI写测试代码这件事我愿称之为整个实践里回报率最高的环节。广告引擎里最难写的不是业务代码而是覆盖各种边界条件的单元测试。人工写测试用例费时费力但AI生成测试用例的速度非常快而且覆盖路径记录得清清楚楚。我们的做法是先让AI阅读目标业务代码然后依据代码逻辑生成单元测试要求它覆盖正常路径、边界值、异常路径和并发场景。AI生成的测试用例我们不会直接全收而是先跑一遍看哪些用例能过哪些会挂挂掉的用例往往能反哺出业务代码里的隐藏bug。有一个具体案例AI给一个“预算扣减”方法生成的测试用例里用并发线程同时发起扣减结果暴露了原有的“先查后写”逻辑存在并发覆盖问题。这个测试用例放人工评审时大概率不会写因为人力成本太高但对AI来说就是一秒生成的事。所以我现在特别推荐所有做AI Coding的团队优先让AI写测试它比写生产代码更可靠收益也更直接。覆盖率方面我们用行覆盖率和分支覆盖率两个指标卡点。新生成模块的分支覆盖率要求不低于80%核心模块要求达到90%以上。达不到就继续让AI补充测试用例。跑了几轮以后发现AI在补测试这块很擅长只要告诉它没覆盖到的分支它就能补出有意义的用例而不是那种“为了覆盖而覆盖”的空测试。4. 踩坑记录与排查技巧4.1 AI生成代码的“看似正确”AI生成的代码有一种非常迷惑人的特质读起来完全合理但就是会在某个隐蔽点上出问题。比如它特别喜欢用if (list ! null)这类防御性判断表面没毛病可一旦上游传入的是null真正的业务逻辑反而被吞掉了。广告引擎里很多“不应该为空的字段”被AI的防御性代码默默保护起来最后问题暴露在数据异常上排查起来极其痛苦。我们后来立了一条规矩AI生成代码里凡是涉及业务流程中断、异常分支吞掉的都必须有明确的日志和指标。但这个要求不一定能靠提示词完全约束住关键还是靠review的人。给AI代码做评审时我会特别留意“这个分支如果走到这里线上会发生什么”这个问题。大多数AI代码的隐患都藏在防御性逻辑和宽泛异常捕获里。4.2 性能问题AI不会自动考虑广告引擎的高并发广告引擎的性能要求和大模型训练数据里的“普通Java项目”完全不是一个量级。AI生成的代码最常见的性能问题有三个。第一个是循环内调用RPC或查询。AI天然喜欢把逻辑写得直观比如在遍历一批广告创意时逐个查询创意详情。这在数据量小时没问题但广告引擎一个请求往往涉及上百创意循环内调用RPC直接能把TP99拖到秒级。我们的提示词里后来固定加了一条“所有下游调用必须批量处理禁止循环内调用”。第二个是不必要的对象创建。AI经常会new ArrayList()、new HashMap()一写一大片在高频调用路径上这些对象的创建和GC开销会非常明显。一次性创建三五个对象和创建一个对象对单次请求来说差异不大但在每秒几万次请求下就是天壤之别。第三个是锁粒度过大。AI处理并发问题时容易直接用synchronized锁住整个方法。这在广告扣费、预算更新这类高频写路径上会造成严重的锁竞争。我们会要求AI优先使用原子类、CAS、分布式锁并且锁范围必须收敛到最小临界区。这三个性能问题静态检查不一定能发现更多要靠压测和性能测试来暴露。我们的做法是所有AI生成代码合并前必须过一个固定链路的性能回归测试。跑不过就直接打回人工优化的时间成本很高不如让AI重写一遍。4.3 依赖与版本管理陷阱AI生成代码时不会主动遵循项目现有依赖约束。有一次AI在一个工具类里直接引入了某个第三方JSON库而我们整个项目统一用的是内部JSON工具。AI生成代码后没有报错因为第三方库也能跑通但引入了一个多余依赖还可能导致序列化行为不一致。这个问题的根源是上下文缺失。AI不知道项目里已经有什么依赖所以它只能凭经验选择“最常用”的库。要解决这个问题我们在提示词里的“编码规范”部分专门维护了一个“允许使用的依赖清单”明确列出所有常见场景应该使用的工具类、JSON库、HTTP客户端等。如果AI生成了清单之外的依赖静态依赖检查会直接拦截。版本管理方面也要注意。AI给出的代码片段里可能会带版本注释比如“需要xx版本以上”这些信息可能来自过时的训练数据。我们的策略是AI生成代码一律不自动引入新依赖所有依赖变更必须走人工评审。从源头上堵住这个问题后续能少很多版本冲突的麻烦。5. 工具链选型与配置参考5.1 模型选择的考虑我们实践时对比过好几款主流的代码生成模型包括通义、GPT系、Claude系以及一些开源模型。最终选择的标准不完全是代码准确率而是三个维度。第一个是上下文遵循度。很多模型生成的小段代码很漂亮但无法严格遵循长上下文里的约束经常会把需求规格里的某条规则漏掉。我们做了一个小测试集包含20条常见业务规则让模型生成一段代码看它能遵守几条。上下文遵循度高的模型在复杂需求下优势特别明显。第二个是代码风格一致性。有的模型生成代码倾向于“优雅但复杂”喜欢泛型、Optional、Stream流式操作。团队代码风格是“直白、易读、偏命令式”这种情况下如果模型不听话生成代码的返工率会特别高。第三个是模型在私有框架上的表现。外部大模型对内部框架一无所知但具备良好代码补全能力的模型可以根据示例代码做模仿。我们筛选时给模型输入了内部RPC框架的标准示例然后让它模仿示例风格写一个新的接口最后选出了模仿能力最强的模型作为主力。没有普适的最佳模型只有最适合你团队的模型。我建议每个团队都自己建一个“代码验收测试集”包含业务代码、测试代码、注释风格三类任务用同样的提示词跑不同模型量化打分再决定用哪款。5.2 提示词模板示例这里放一个我们实际在用的提示词模板覆盖了日常“AI生成工具类方法”的场景。大家可以按自己的项目做调整你是一位经验丰富的Java开发工程师就职于一个高并发的效果广告引擎团队。 请根据以下需求实现代码严格遵循编码规范。 【需求规格】 功能名称按时间窗口统计用户广告曝光次数 功能描述对给定的用户ID和广告位ID在指定时间窗口内统计曝光次数超过阈值则返回拒绝展示。 输入参数 - userId: String, 不能为空 - adSlotId: String, 不能为空 - windowStart: long, 时间窗口起始时间戳毫秒 - windowEnd: long, 时间窗口结束时间戳毫秒 - threshold: int, 曝光次数阈值必须大于0 输出要求返回booleantrue表示允许展示false表示超过频控 业务规则 1. 如果窗口跨度小于等于0抛出IllegalArgumentException 2. 如果统计失败返回true兜底放行 3. 统计时必须使用缓存计数服务禁止自己维护本地内存 【编码规范】 - 使用项目标准Logger记录日志日志必须包含userId和adSlotId - 禁止使用System.out.println - 禁止在循环内调用任何RPC方法 - 禁止捕获Throwable只允许捕获业务异常 - 所有方法必须返回Result对象或基本类型不允许返回null - 类名和文件名必须一致包名按照com.company.adengine.frequencycontrol 【实现思路】 请先简要说明你的实现思路再输出完整代码。 输出内容仅包含实现思路和代码不要额外解释。这个模板看起来很长但每次实际生成时只需要复制粘贴成本很低。模板里最关键的是“业务规则”和“编码规范”两块它们直接决定了代码的质量。如果你把提示词写得太短AI就会用默认模式发挥生成你不需要的复杂度。5.3 集成到CI/CD的配置参考AI生成代码不是终点它必须和现有开发流程融合。我们最终把AI生成代码的流程做成了半自动化的流水线整个流程包含四个阶段。第一阶段是代码生成。开发者在本地通过内部工具或脚本发起生成请求传入需求规格和提示词模板得到候选代码。第二阶段是编译与静态检查。生成的代码直接进入Maven编译、Checkstyle检查、SpotBugs扫描。这个阶段不通过的话工具会自动把错误信息反馈给大模型让大模型修复形成一个“生成-检查-修复”的自动循环。第三阶段是自动化测试。编译通过后自动执行该模块的单测和集成测试并统计覆盖率。核心模块覆盖率低于阈值时工具会要求AI补充测试用例同样自动循环。第四阶段是人工评审。通过自动化验证的代码会生成一份包含“生成记录、检查报告、测试报告”的合并请求交给团队里的工程师做最后的业务逻辑评审。人工只需要关注业务正确性不用再花时间查风格、查规范。这样设计的好处是AI生成的代码几乎不会把低级问题带到review阶段人工review的压力大幅下降。我把这套流水线的核心配置代码整理成了一份内部文档核心思路就是“把AI当作已有信息源接入流程而不是当作一个独立工具用”。6. 效果与心得6.1 数据表现实践三个月后我们统计了几个关键指标。模板类和工具类代码的生成通过率达到了80%以上也就是生成后经过自动修复能直接进入人工评审的比例。算法实现类的通过率在60%左右主要难点在于边界条件和性能要求。单元测试代码的生成通过率最高超过了90%。整体交付效率上简单模块的编码时间从原先的一到两天缩短到半天以内中等复杂度的模块缩短了约40%的时间。代码评审阶段的“返工改逻辑”情况明显变少因为大部分基础问题都被静态检查和自动测试挡在前面。最让我意外的一点是AI生成代码带来的Bug率比人工代码低。这背后的逻辑不难理解AI生成的代码经过了非常充分的静态检查和测试覆盖而人工代码在时间紧张时往往会跳过这些步骤。当然这里的Bug率只统计了基本的逻辑错误和规范错误不统计业务理解上的偏差业务偏差还是需要人工兜底。6.2 团队协作模式的改变AI Coding带来的最大改变不是“写代码更快”而是开发者的角色变了。以前我们是“从零实现需求”现在更像是“审稿人”和“架构师”的结合。基础代码由AI生成我们负责把需求描述清楚给AI划边界做代码评审处理AI搞不定的难题。团队里原本比较抗拒AI的同事在看到AI生成的测试用例帮自己发现隐藏Bug后态度也发生了转变。后来我们形成了一个内部共识AI不是替代开发而是把我们从重复劳动中解放出来把精力放在真正的设计、评审和复杂系统思考上。不过也要诚实地说AI Coding初期会带来一段“混乱期”。代码量猛增、review工作量变大、工具链维护成本增加团队可能会觉得更累。但只要把流程理顺把自动验证机制搭好后面就会进入正循环。我们大概花了一个月的时间才尝到甜头所以别指望一上来就有效率提升。6.3 个人实操体会最后分享一点我自己的感受。AI Coding这件事最大的风险不是模型不够强而是人太懒。如果需求描述随便写AI生成代码不review直接上那生产事故一定在等着你。AI可以承担大量编码工作但“清晰思考”这件事最终还是人的责任。我把需求规格模板、提示词模板、代码骨架库这三样东西视为AI Coding的三大支柱。缺了任何一样生成代码的质量都会明显下滑。特别是需求规格模板它逼迫我们在让AI动手之前把业务想得更清楚这个收益远超AI本身。如果你所在的项目也是高并发、强约束、依赖复杂我建议你先从“让AI写测试”开始不要急着让AI写核心业务代码。测试代码失败成本低又能立刻带来收益还能让你熟悉AI的生成习惯。等流程稳定了再逐步扩展到模板代码和算法实现。这条路我们走过稳。