从AI Coding到AI Engineering：16万行代码的稳定运行之道

16 万行代码是怎么“跑”出来的从 AI Coding 到 AI Engineering过去大半年我一直在推进一个偏底层的业务系统重构项目。团队不大核心开发满打满算五个人但项目代码量最终定格在了 16 万行左右。这不是一个“手写 16 万行”的故事——说实话纯靠人肉敲这个周期至少得翻三倍。这 16 万行里有相当一部分是 AI Coding 工具直接生成的但真正让它“跑”起来的却不是生成代码这件事本身。先说一个反直觉的结论AI 写代码从来不是瓶颈让 AI 写的代码能稳定、持续、可控地跑在线上才是真正的瓶颈。前者叫 AI Coding后者我觉得才配叫 AI Engineering。这篇文章不聊那些高大上的理论就聊聊这 16 万行代码是怎么从“生成”到“真正产出”的以及在这个过程中我们对代码质量、团队协作、工程规范的认知发生了哪些变化。如果你正在纠结“AI 写出来的代码到底能不能用”“代码质量会不会越写越烂”“多智能体协作是不是噱头”这篇文章可能会给你一些不一样的参考。1. 16 万行代码的“生成”与“跑起来”是两回事1.1 AI Coding 的真实生产力一天一千行不是梦先交代背景。我们这个项目是一个面向内部业务的资源调度系统涉及权限模型、任务队列、数据看板、消息通知等多个模块。技术栈是 Java Spring Boot 为主前端 Vue数据库 MySQL 加 Redis 缓存。这种项目在技术难度上不算顶尖但胜在业务逻辑复杂、状态流转多、边界情况碎属于典型的“写起来不难、写对很烦”的工程。项目启动初期我们就定了基调AI Coding 工具必须上而且要当成正式生产力工具用不是玩具。团队里五个人的 AI 使用水平参差不齐有人已经用 AI 写了大半年代码有人还停留在“让 AI 解释一下这段代码”的阶段。但即使是这样AI 工具的引入还是立刻带来了肉眼可见的效率变化。具体到数据上我们自己粗算过核心开发人员用 AI 辅助编码后单日有效代码产出从原来的 300 到 500 行提升到了 800 到 1500 行。听起来不算夸张但放在一个持续六个月的迭代周期里这个提升就是决定性的。尤其是那些 CRUD 风格的接口代码、DTO 定义、状态机枚举、常规配置类AI 几乎是“秒出”而且质量相当稳定。但这里有个非常重要的前提AI 生成的代码从来不是“拿来就用”的。我见过不少团队把 AI 当成代码生成器生成完直接往代码库里怼结果就是线上事故频发、返工成本暴涨。这不是 AI 的错是使用姿势的错。1.2 “跑起来”的三个层次编译通过、功能正确、线上稳定我们内部把“跑起来”分成三个层次每个层次对 AI 生成代码的要求完全不同。第一层是编译通过。这个要求很低AI 生成一个类、一个方法语法正确、类型对得上导入的包都存在基本就能过。这一层 AI 的通过率极高大概在 95% 以上。但编译通过距离“能干活”还有十万八千里。第二层是功能正确。也就是这段代码在给定的输入下能返回预期的输出逻辑分支都覆盖到边界条件处理得当。这一层 AI 的通过率就开始明显下降了——特别是涉及复杂业务状态的流转、并发场景下的数据一致性、以及跨模块的接口对接时AI 生成代码的正确性大概只有 70% 到 80%。剩下的 20% 到 30% 需要人工介入调整。第三层是线上稳定。这是最狠的一层。代码功能正确了但放到生产环境要面对高并发、网络抖动、依赖服务超时、数据量爆炸这些现实问题。这一层AI 生成代码的表现就很难用通过率来衡量了——因为很多问题不是代码本身的逻辑错误而是缺乏对运行环境的敬畏。比如 AI 经常生成的代码不设置超时时间、不做降级兜底、不考虑幂等性这些在单测里根本测不出来只有上了线才会爆雷。我们的 16 万行代码真正花时间的地方不是让 AI 生成它们而是让它们跨过第二层和第三层之间的那道鸿沟。这个过程我从里面拆出了三个真正决定成败的关键点架构约束、规范注入和上下文管理。下面分别展开讲。2. 从“能运行”到“稳运行”三个关键桥段2.1 架构先行给 AI 画好“跑道”再让它跑我见过太多团队在引入 AI Coding 的时候犯同一个错误没有架构约束直接让 AI 自由发挥。结果就是每个模块的代码风格完全不同、分层逻辑混乱、调用关系像蜘蛛网一样纠缠。这样的代码前一万行可能还没什么感觉到五万行、十万行的时候维护成本就会呈指数级上升。我们项目从一开始就做了一件非常重要的事先把架构规范固化下来再让 AI 在这个规范框架内生成代码。这不是一句空话而是落地成了具体的约束文件。我们在项目根目录维护了一个ARCHITECTURE.md里面用非常明确的语言定义了分层规则Controller 层只做参数接收和响应封装Service 层只做业务逻辑Repository 层只做数据访问禁止跨层调用。命名规范类名用领域名词 后缀比如OrderQueryService、TaskExecuteRepositoryImpl方法名用动词开头禁止出现doWork、handleData这类毫无信息的命名。依赖方向领域层不依赖基础设施层所有外部接口调用必须走防腐层。异常处理规范业务异常必须抛自定义异常类型禁止裸抛RuntimeException禁止在底层吞异常。数据校验规则所有对外接口入参必须经过参数校验禁止用if (xxx null)这种散弹式判断。这些规范不是什么新鲜东西任何一个有经验的架构师都能列出一堆。关键的区别在于以前这些规范靠 code review 人工盯现在我们把规范写进了 AI 的上下文里让 AI 在生成代码的第一时间就遵守这些规范。具体做法是所有 AI 编码工具的使用者在提交代码生成请求之前必须把ARCHITECTURE.md中与当前任务相关的部分粘贴到对话上下文里或者通过 IDE 工具的规则配置功能加载到系统提示词中。这个动作看起来不起眼但它的价值极其巨大——AI 生成的代码从一开始就在“跑道”内而不是跑偏了再拉回来。2.2 规范注入把那本“团队编码规范”喂给 AI架构约束解决了“大方向”的问题但 16 万行代码的体量光有宏观约束是不够的。真正让代码质量拉开差距的是那些琐碎的、细颗粒度的编码规范。我们团队原来有一份 40 多页的编码规范文档内容包括集合初始化怎么写、字符串拼接用什么方式、日志打印打什么级别、事务注解怎么加最合适、DTO 转换用 MapStruct 还是手动 set……这份文档以前主要是给新员工看的老员工写代码基本靠肌肉记忆。但 AI 没有肌肉记忆它只有上下文里的信息。你要是没告诉它规范它就按训练数据里最通用的方式写——大概率不是你们团队想要的那种风格。所以我们做了一个很“笨”但很有效的事情把编码规范文档拆成一个个场景化的片段按需注入到 AI 的上下文中。举几个实际例子涉及数据库操作的任务我们会把“所有查询必须加LIMIT、所有批量操作必须分批执行、禁止使用SELECT *”这几条规范随任务一起发给 AI。涉及并发编程的任务我们会附上“统一使用ThreadPoolTaskExecutor的包装类禁止直接 new Thread锁必须使用ReentrantLock并配合 try-finally”这类约束。涉及接口对接的任务我们会强调“所有外部调用必须设置连接超时和读取超时必须捕获超时异常并降级处理”。这个动作带来的改变是立竿见影的。以前 review AI 生成的代码经常发现各种“没说就乱来”的情况——比如查询不加分页、日志不打关键上下文、异常吞了就当无事发生。把规范注入到生成阶段之后这类问题减少了大概 60% 以上。有人可能会问为什么不把所有规范一次性全部塞给 AI我也想过这个问题但实际测试下来效果并不好。AI 的上下文窗口虽然是有限的但更重要的是重点不突出。一次性给它 40 页规范它反而不知道该优先遵守哪条。按场景切分注入让它在面对具体任务时只聚焦当前相关的规则正确率反而更高。2.3 上下文管理AI 写错代码的根源往往是你给的信息不够这是我从这次项目里体会最深的一点。AI 生成代码的错误相当大比例不是 AI 能力不行而是我们给的上下文不够完整。我举一个很典型的例子。项目里有段时间需要实现一个“任务超时自动重试”的功能。第一次我让 AI 写这个功能我只给了它一句话“实现一个任务超时自动重试的机制”。AI 给了我一个非常标准的方案用定时任务扫描超时任务然后重新投递到消息队列。逻辑看起来没错但压根跑不通——因为我们系统的任务状态机里根本没有“重试中”这个状态而是复用了“待执行”状态且消息队列里已经有消费者在消费直接重新投递会导致任务被并发执行造成数据错乱。这个问题的根源不在 AI在我。我没有告诉 AI任务状态机的完整定义和流转规则消息队列的消费者机制和幂等策略项目里已有的分布式锁工具类在哪、怎么用。这些信息对团队成员来说是“常识”但 AI 不知道。它只是从海量训练数据里捡了一个“看起来最通用”的方案。后来我们形成了一个工作习惯我管它叫“给 AI 写需求文档”。哪怕是一个很小的功能在让 AI 动手之前至少要提供以下几类信息功能涉及的业务实体和它们之间的关系相关的状态流转规则最好直接把枚举定义贴出来项目里已经存在的类似实现让 AI 照着写而不是凭空创新已知的坑和必须避免的做法。我把这个习惯固化成了团队的执行规范并且做了个简单的模板要求每个 AI 编码任务都必须按模板填信息。包括任务背景这段代码要解决什么问题 涉及模块涉及哪些已有的类/表/接口 关键约束必须遵守的架构/性能/安全规则 参考实现项目里有没有类似的代码可以参考 验收标准怎么算写完有哪些测试用例要过这个模板的效果超出了我的预期。同样的任务用这个模板和不用这个模板AI 生成代码的一次性通过率大概差了 30% 到 40%。很多以前需要反复让 AI 返工修改的场景现在基本上一次就能生成一个像样的初稿人工只需要在旁边捡漏。3. 代码质量会不会越写越烂我们的实测数据与判断3.1 一个敏感问题AI 是在制造技术债吗“AI Coding 的到来会不会让代码质量下降”——这几乎是每个引入 AI 编码的团队都会吵一遍的话题。我们这个团队也不例外。项目做到中期的时候内部还专门开过一次会主题就是讨论要不要继续大规模使用 AI 编码因为有人开始担心代码质量失控。这个担心不是空穴来风。项目进行到第 3 个月的时候我们确实出现了一些质量问题苗头代码重复度开始上升不同模块里出现了大量“看起来不一样但功能几乎相同”的工具方法有些 AI 生成的代码存在轻微的性能隐患——比如在循环里查数据库、N1查询问题、不必要的大对象复制最麻烦的是有些代码“太聪明了”——AI 用了很精妙的写法但可读性极差团队里其他人根本看不懂更谈不上后续维护。坦白讲如果我们对这些问题视而不见16 万行代码写完之后团队大概率会陷入维护泥潭。但我们没有放任不管而是做了一套自己的“质量防御体系”。3.2 我们的质量门禁让 AI 代码也过三道关第一道关是静态检查。我们把 SonarQube 的规则配置调到了比较严格的程度任何代码合入主干之前必须通过静态检查。这一关能拦住大部分明显的坏味道比如未使用的变量、空的 catch 块、明显的 null 风险。第二道关是代码评审。每一段 AI 生成的代码必须经过至少一名有经验的工程师 review 之后才能合入。这个 review 不是走形式而是重点盯几个 AI 特别容易翻车的地方状态流转是否正确、并发场景是否安全、事务边界是否合理、外部依赖是否设置了超时降级。第三道关是测试兜底。我们对 AI 生成的业务逻辑代码强制要求配套单元测试。这不是什么高要求但执行起来需要自觉。我们后来干脆把这个要求做进了任务模板里——AI 生成业务代码的同时要求它一并生成对应的单元测试然后再由人工补充边界用例。这三道关听起来一点都不性感但确实管用。项目结束后我们做过一次质量复盘把代码里的 bug 按来源做了归因分析发现由 AI 生成的代码引入的线上缺陷大约占全部线上缺陷的 35% 左右。这个数字初看有点高但要注意AI 生成的代码量可能占到了全量的 50% 到 60%。按缺陷密度来算AI 代码的质量其实已经和人工代码基本持平了。3.3 技术债的最优解定期重构绝不让 AI 的债利滚利质量问题解决了但技术债的问题还需要单独说。AI 生成代码有一个特点它的代码往往是“局部最优”的但缺乏整体一致性。什么意思呢就是你让它实现一个功能它能干得挺好但你要是让它维护一个已经在演进半年的系统它能给你搞出一堆风格完全不同的代码。我们的应对办法是每一个迭代周期预留一定的重构时间专门用来处理 AI 代码带来的技术债。具体来说每两周的迭代中我们至少会抽出半天到一天的时间做以下几件事找出重复度高的代码片段抽成公共方法或工具类检查 AI 生成的代码是否遵循了最新的架构规范架构规范是会演进的处理那些“能跑但很难读”的代码——要么重写要么加详细注释检查依赖情况把那些不必要的间接层、多余的封装拆掉。这个过程我们没有让 AI 来做因为“整体一致性”恰恰是 AI 目前最不擅长的事情——它没有一个完整的全局视野也没有办法感知团队其他成员在别的模块里做了什么设计决策。这种一致性维护更适合人来做。你可能会问这样是不是反而增加了工作量我的体会是短期内确实增加了一些工作量但长期来看它避免了一笔巨大的“信用贷”。如果放任 AI 代码的技术债利滚利到项目后期你会发现改一个功能需要动三个模块而每个模块的代码风格都不一样调试起来痛不欲生。那种代价比定期重构高出十倍不止。4. 多智能体协作AI Agent 开发规范的落地实验4.1 从一个“天真”的想法说起项目进行到后半段的时候我们做了一个新的尝试引入多智能体协作开发。起因是团队里一个同事看了一些 AI Agent 的宣传材料觉得可以试一试“让 AI 自己开发一个完整的需求”。说实话一开始我是持怀疑态度的。因为前期的经验已经证明了AI 写得再好也需要人工把关。让 AI 自己去“闭环”一个需求听起来很美但不确定性太大了。不过那个同事说得也有道理与其我们五个人挨个把需求拆给 AI 做不如试试看能不能搭建一个 AI 内部的流水线——需求进来经过多个 AI Agent 的协作直接产出可评审的代码。我们花了两周时间搭了一个很简陋的 multi-agent 协作框架核心就是让多个 AI Agent 扮演不同的角色通过消息传递来协作完成一个开发任务。这个实验很有意思。我们的 Agent 角色分四类需求 Agent负责理解原始需求拆解成多个子任务开发 Agent负责根据子任务描述生成具体代码测试 Agent负责为生成的代码编写并执行单元测试审查 Agent负责检查代码规范符合度和上下文一致性。每个 Agent 之间通过一个简单的任务队列来通信上一个 Agent 的输出作为下一个 Agent 的输入。4.2 跑通了但问题比惊喜更多这个实验最后真的跑通了。我们用它完成了几个中等复杂度的需求包括一个带分页查询的列表接口、一个简单的状态流转模块甚至还有一个带 Excel 导入导出的功能。产出的代码质量在可接受范围内但整个过程的“体验”暴露了不少问题。首先Agent 之间的信息损耗比预想的严重。需求 Agent 理解需求后拆解出的子任务描述里经常遗漏一些关键细节导致下游的开发 Agent 生成代码时“凭想象补全”。有时候它补对了有时候补得南辕北辙。测试 Agent 写的测试用例本身的覆盖度也不够而且它倾向于测“代码实现了什么”而不是测“需求要求了什么”。审查 Agent 最鸡肋——它的规则检查能力还行但一旦遇到需要结合业务背景判断的问题就会给出错误结论。其次多智能体协作不等于简单的工作流串联。如果只是把需求文字从一个 Prompt 复制到另一个 Prompt那本质上是把一个完整的开发任务切碎了喂给 AI反而丢失了全局上下文。真正有效的多智能体协作需要解决“共同记忆”的问题——每个 Agent 都应该能访问到项目的全局规范、已有代码结构、领域模型定义而不是只看到任务队列里传给它的那一段话。4.3 用好 Agent 的关键把它当成“实习生团队”而不是“自动化流水线”经历了这个实验之后我的判断是多智能体协作目前还不足以替代人类的工程组织但它作为人类的“辅助团队”已经非常好用了。关键是别把它当成一个全自动流水线而是当成一个可以并行的实习生团队来管理。在我们后续的项目推进中把多智能体的使用方式调整成了“人在环上”的模式。具体来说需求拆解和任务分配仍然由人来决定AI Agent 只是执行者一个复杂需求会被拆成多个可以并行的子任务每个子任务对应一个工作上下文AI Agent 完成代码后仍然要经过统一的静态检查、代码评审和测试兜底环节对于跨模块的修改默认不让 AI Agent 独立完成必须有经验的工程师先给出修改方案再做拆分。调整之后这个 multi-agent 框架的价值就体现出来了。它最大的优势是并行性——以前一个需求从拆解到开发到测试流程串行跑现在可以同时开三四个 Agent 并行开发不同模块整体周期缩短了 30% 以上。如果你想在自己的团队里尝试多智能体协作开发我的建议是从最小的框架开始先跑通一个需求再逐步增加 Agent 角色。网上那些宣传多智能体框架多强大的文章看看就行别照着抄。真正的落地一定是结合自己团队的开发规范和项目特点一点点磨出来的。5. 回看这 16 万行AI 重构了我们的工程方式项目收尾之后我花了很长时间复盘整个过程。以前聊 AI Coding大家谈的是“AI 怎么帮我写代码”好像它就是一个更聪明的自动补全工具。但这 16 万行代码跑下来我的感受完全不同——AI 改变的不仅仅是写代码这个动作而是我们做工程的方式。5.1 代码产出的瓶颈变了以前我们做项目瓶颈几乎都在“写代码”这个环节。需求拆解完了开发时间是大头一个功能写到一半发现漏了状态处理又得返工。有了 AI 之后代码生成的效率飙升瓶颈悄悄转移到了别处——需求定义和上下文传递。这意味着什么意味着团队里最值钱的能力从“代码写得快”变成了“能把一个需求讲清楚让 AI 一次听明白”。这个转变的影响是深远的。以前我们招人看重算法底子和代码功底现在我们更看重业务理解能力和结构化表达能力。这个趋势在后面还会加剧。我甚至觉得未来两三年内会出现一个新的岗位方向——专门负责把业务需求翻译成 AI 能理解的形式并管理 AI 的产出质量。这和传统的架构师有点像但关注的重心完全不同。5.2 代码评审也变了过去 code review 主要是挑毛病——找逻辑错误、发现性能隐患、指出规范问题。但 AI 加入之后大部分低级错误在生成阶段就被规避了代码评审的焦点变成了更“高级”的问题这个方案的整体设计是否合理这个模块的边界划分是否清晰这段代码是否考虑了未来的演进这其实是件好事。AI 把评审者从繁琐的“找茬”中解放了出来让他们把精力集中在真正需要人类判断力的事情上。但也带来一个新挑战评审者的水平要求更高了。以前是“谁都能看出来这段代码不好”现在是“你得理解业务背景才能看出来 AI 的优雅方案里藏着哪些坑”。5.3 最后说一点个人的体会如果你问我16 万行代码里AI 到底贡献了多少我会说代码量上它贡献了超过一半但工程质量上的贡献来自于我们围绕 AI 建立的那套工程体系。AI Coding 解决的是“怎么写”AI Engineering 解决的才是“怎么用好”。前者是效率工具后者是组织能力。跑完这个项目之后我对 AI 写代码的态度是大胆用但永远保留“人”的判断力。AI 可以帮你把代码写出来但它不会告诉你这段代码在什么业务场景下会出问题它可以把整个模块搭起来但它感受不到这个模块的代码风格和团队其他模块之间的细微差异。这些东西永远需要人来把关。如果你所在的团队正在考虑引入 AI Coding 或者已经在用但效果一般我的建议是别先急着换更强的模型、买更贵的工具先把工程规范梳理清楚把需求模板建起来把上下文的传递机制跑通。AI 的能力摆在那里能不能把它变成生产力取决于你周围那套工程系统是否接得住它。这件事越早想明白越早受益。