企业官网建设流程全解析

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 生成的代码存在轻微的性能隐患——比如在循环里查数据库、N+1查询问题、不必要的大对象复制；
• 最麻烦的是，有些代码“太聪明了”——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 代码带来的技术债。

具体来说，每两周的迭代中，我们至少会抽出半天到一天的时间，做以下几件事：

1. 找出重复度高的代码片段，抽成公共方法或工具类；
2. 检查 AI 生成的代码是否遵循了最新的架构规范（架构规范是会演进的）；
3. 处理那些“能跑但很难读”的代码——要么重写，要么加详细注释；
4. 检查依赖情况，把那些不必要的间接层、多余的封装拆掉。

这个过程我们没有让 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 的能力摆在那里，能不能把它变成生产力，取决于你周围那套工程系统是否接得住它。这件事，越早想明白，越早受益。