先说个现象：现在很多人用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 Result<SomeResponse> 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 输出要求：返回boolean，true表示允许展示，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的生成习惯。等流程稳定了，再逐步扩展到模板代码和算法实现。这条路我们走过，稳。
