有一阵子我打开代码仓库看到的提交记录长这样连续几十条 commit作者一栏填的都是同一个名字——不是我们团队里的任何人而是我配置的那个 AI 编程助手。隔壁同事路过工位时问了一句“你这是让 AI 把整个项目写完了吧”我没有否认因为从某种角度上说确实如此。这个项目最后的体量是 16 万行代码从零到能跑起来的完整版本前后用了不到四个月。期间我不是没有怀疑过这条路能不能走通尤其是当 AI 产出的代码量越来越大、Review 的速度开始跟不上生成速度的时候。今天想聊的就是这 16 万行代码到底是怎么“跑”出来的。以及更重要的一件事为什么我把这段经历叫做“从 AI Coding 到 AI Engineering”的转变。先说清楚背景。我们当时要做的是一个典型的中后台业务系统用户权限、订单管理、报表统计、审批流一堆 CRUD 密集的业务模块没有什么特别炫酷的算法但胜在量大、规则多、状态流转复杂。这种项目用传统方式做团队至少需要五到六个人干半年。而我们的实际配置是两个后端工程师加一套 AI 辅助开发的完整流程。如果你也想用 AI 大规模产出代码这篇文章应该能帮你少走不少弯路。我会把代码构成、流程设计、质量管控和踩过的坑全部拆开讲。1. 16万行代码的真实构成不是AI自己长出来的先给 16 万行这个数字做个“解剖”。很多人一听到 AI 写代码第一反应是“AI 噼里啪啦自己生成了 16 万行”——不是这样的。至少对我来说把 16 万行全部归功于 AI 是不诚实的也是危险的。1.1 先算一笔账16万行的可信拆解整个项目大约 16 万行包括前端和后端。其中 Java 后端约 9 万行Vue 前端约 4.5 万行测试代码约 2 万行还有一部分 SQL 脚本、配置文件、接口定义文档。这里面真正意义上“AI 全自动生成、我们只做了轻量修改”的代码大概是 6 到 7 万行。还有 5 到 6 万行是 AI 生成后经过人工大幅改造的剩下的 3 万多行属于纯手工编写——大部分是核心业务状态机、审批流引擎、权限模型这些“一旦写错就是事故”的地方。为了让你对 16 万行有感性的认知我列了一个构成表代码类型规模估算AI 参与方式人工介入程度脚手架与基础设施约 1.5 万行自动生成极少CRUD 业务接口约 4 万行自动生成 人工调整中等业务规则与状态流转约 3.5 万行人机协作高前端页面与交互约 4.5 万行自动生成 人工调整中等测试代码约 2 万行自动生成中高核心引擎与权限模型约 1.5 万行以人工为主极高这个划分告诉我一个很重要的道理AI Coding 的产出效率不是平均分布的。越是模式化、重复度高、有章可循的代码AI 的产出效率越高、质量越稳定越是涉及复杂业务判断、技术取舍的代码AI 只能做助手不能做主力。1.2 哪些代码AI写得好哪些必须人来写我后来总结了一个经验法则看一段代码里“确定性的比例”有多高。确定性越高AI 越擅长。什么是确定性高的代码比如一个标准的订单模块无非就是接收请求、校验参数、查表、写表、返回结果。这种代码的技术方案基本是确定的无非是“怎么写”的问题不存在“要不要这么写”的争议。AI 在生成这类代码时几乎不会跑偏。再比如报表统计模块只要把 SQL 写清楚、把聚合规则定义好AI 生成查询层和 DTO 层的代码非常利落。确定性低的代码是什么审批流引擎。一个审批流涉及会签、或签、转办、委派、驳回、撤回光是状态就有十几种状态之间还有各种条件和权限限制。这种代码AI 很容易写出“看起来对、实际上漏了边界条件”的逻辑。因为边界条件本身就是人通过多次业务沟通才能确认的隐性知识AI 看不到那些会议记录和需求文档。所以从一开始就定了一条规矩架构和核心引擎人工写业务 CRUD 交给 AI测试代码 AI 写但人要改断言。这条规矩后来救了整个项目无数次。2. 从AI Coding到AI Engineering思维方式的转折点工具还是那套工具但为什么有的人用 AI 写代码是在“玩”有的人却是在“生产”在我看来区别就在于有没有完成从 AI Coding 到 AI Engineering 的思维转变。这条路我走了不少弯路。2.1 单点用AI和规模化用AI是两套逻辑AI Coding 解决的是一个点的问题比如“帮我写个 Java 的 LRU 缓存”“帮我写个正则表达式”“这个报错是怎么回事”。它面向的是单次的人机对话目标明确、范围极小、上下文可以在一屏内理解。但当你试图让 AI 产出一个完整项目的代码时你面对的根本不是“写代码”问题而是“如何让一个不懂全局的助手持续产出符合全局设计的代码”问题。这两套逻辑天差地别。打个比方AI Coding 像是你请了个很熟练的临时工你告诉他“把这块砖砌好”他能干得不错。但如果你想请他帮你盖一栋楼你就不能只跟他说“砌砖”你得给他看图纸、告诉他用的什么标号的水泥、哪里是承重墙、哪里可以随意砌。更关键的是你得建立一套流程确保每一块砖都砌在图纸规定的位置上否则楼盖到一半必然塌。在建这个 16 万行项目的早期我的思维还停留在 AI Coding 阶段。我花很多精力折腾“怎么提问”写了大量自认为精妙的提示词但效果并不持续。今天我让 AI 生成的订单模块风格是 A明天它生成的用户模块风格是 B后来做权限模块时它甚至把之前已经定好的返回结构都改了。那时候我才意识到一个问题我在用“对话思维”做一件原本需要“工程思维”的事情。2.2 我踩的“伪AI工程化”的坑把提示词当银弹很多人对 AI Engineering 的理解就是“把提示词写得更好”。我当时也这么干过甚至整理了一个几十页的提示词手册。结果是什么手册里的提示词在模板场景下确实好用但只要换一个模块、换一种业务背景效果就大打折扣。我需要在每个新任务里重新调整上下文、补充背景、样例输出提示词的维护成本越来越高产出的稳定性却依然很差。这就是典型的伪 AI 工程化以为把“问问题的技巧”标准化就等于把 AI 生产流程标准化了。但事实是AI 产出的稳定性不取决于你问得多好而取决于你给它搭建的“生产环境”有多稳定。2.3 真正的AI Engineering让不确定性变确定后来我想明白了一件事。AI Engineering 不是提示词工程而是系统设计。它的目标不是“让 AI 每次都能漂亮地回答”而是“设计一套流程让 AI 的产出哪怕不完美也能被及时发现、修正、限制在可接受的范围内”。这意味着你要设计的是这样一套东西一个稳定的架构骨架让 AI 只能在既定的框架内填充内容一套标准化的任务拆解方法让每个 AI 任务足够小、足够明确、足够可验收一套上下文管理机制让 AI 在生成每个模块时都能拿到它真正需要的“图纸”而不是靠猜一套自动化的质量检查体系让 AI 代码的潜在问题在合并前就被暴露而不是上线后爆炸。从这个角度看AI Engineering 其实不是“AI 的工程”而是“人的工程”。AI 只是执行者真正需要设计、维护、兜底的是人。3. 落地这套体系的具体步骤从骨架到血肉道理讲再多不如实操一遍。下面是我在项目里逐步搭建 AI 工程化流程的完整路径每一步都有对比效果。3.1 第一步不是写代码是写“机器可读”的架构文档传统项目里架构文档是给人看的写得模糊一点问题不大大家可以通过会议对齐。但在 AI 辅助开发的项目里架构文档是给“机器”看的因为 AI 不会主动来问你“这里我理解得对吗”——它只会按照自己的理解往下写写错了你最后才知道。所以我们的架构文档必须做到以下三点目录结构即架构项目里每一个目录、子模块在文档里都有明确说明AI 的任务描述里直接引用“看docs/architecture/module-order.md”而不是在提示词里重新描述一遍需求。接口契约先行每个模块对外暴露的 API、请求参数、返回值必须先定义清楚AI 生成的代码必须严格按契约实现。代码风格约束包括命名规范、异常处理方式、返回码设计、日志规范。AI 生成代码后这些规范将通过静态检查自动校验。这一阶段我花了将近一周。这一周让我倍受煎熬因为几乎没有产出业务代码。但事后看这一周是整个项目效率最高的投资。它保证了后面三个月里所有 AI 生成的代码都长在同一个骨架上而不是骨骼清奇地各长各的。3.2 任务拆解的最小单元什么粒度最适合AI让 AI 开发的最大陷阱是给它一个“宏大”的任务。比如“实现整个订单模块”——这种任务扔给 AI它会自己脑补一个自以为合理的订单系统然后你得到一堆看起来完整、实际上和你的设计脱节的代码。我实践的结论是适合 AI 的任务粒度是“一个接口或一个页面”。具体来说一个大任务会被拆成若干个子任务每个子任务只描述清楚一件可以单独验证的事。举个实际例子订单列表这个功能我不会写“帮我实现订单列表”而是拆成订单查询接口支持分页、状态筛选、时间区间筛选订单列表页含筛选表单、表格展示订单详情接口返回订单基本信息 商品明细列表订单详情页含基础信息卡片 商品表格每个子任务AI 生成的核心代码量大约在 30 到 100 行之间。这个范围是我试出来的“甜区”太大AI 容易跑偏且上下文容易混乱太小任务描述和验收的成本会超过自己手写的成本。3.3 上下文工程给AI喂什么比怎么提问更重要在我最早用 AI 写代码时习惯把需求一股脑塞进对话上下文“帮我写一个用户模块跟订单模块差不多。”AI 确实能写出来但写出来的东西总是差点意思。后来我意识到一个问题AI 本身不是“笨”而是它在完成一个任务时能参考的信息太少。我作为一个熟悉项目的人知道用户模块和订单模块在哪些方面“差不多”但 AI 不知道——如果我把订单模块的实现代码提供给 AI 作为参考它生成的效果会完全不同。所以从项目中期开始我建立了一个标准化的任务描述模板每个 AI 任务描述必须包含四部分背景这个模块在整个系统中的位置依赖哪些已有模块目标本次要实现的接口/页面/功能需求卡片说明参考需要参考的已有实现代码的关键路径和文件位置验收标准代码要满足的规范、需要覆盖的测试用例、性能要求。这样做的效果非常明显。AI 的产出从“经常需要返工”变成“偶尔需要微调”。因为它在动手之前已经拿到了一个人类工程师在接手任务时会主动去了解的信息。一句话总结你不是在向 AI 提需求你是在给 AI 补齐它作为新同事的 onboarding 资料。3.4 验收闭环没有自动检查的AI产出都是半成品有人可能会问“任务拆细了、描述写清楚了AI 就一定能写对吗”不一定。AI 毕竟是概率模型它可能在 90% 的情况下表现优秀但在 10% 的情况下犯低级错误。所以验收环节不能省但它也不能靠纯人工。我把验收做成了半个自动化流程代码提交后先触发编译和不同层级的检查校验规范、检查 BUG 模式通过后自动跑单元测试这部分测试大部分也由 AI 生成全部通过后再由人做代码走查——但人只需要关注逻辑设计层面的东西不用去抠缩进和命名。我算过一笔账这套验收流程初期搭建大概花了一周但它在三个月里帮我们拦下了不下 30 个本来会延迟到联调阶段才能发现的“系统性问题”这些问题的修复成本远远高于搭建成本。4. 质量会不会下降四道防线堵住失控“AI Coding 的到来会不会让代码质量下降”是很多人最关心的问题也是项目早期最让我焦虑的问题。现在我可以给一个比较有底气的回答AI 本身不会让质量下降失控的管理会。4.1 代码质量焦虑的真相我刚引入 AI 写代码时最怕的就是“AI 生成了高质量的表面代码”——看起来整洁规范、注释齐全但深挖下去有各种逻辑漏洞。这种代码比烂代码更危险因为烂代码一眼就能看出烂而这种代码容易骗过审查、骗过测试。后来我发现AI 代码的质量问题其实是可以分类的。大部分问题集中在边界条件处理不完整、业务规则理解偏差、异常处理路径缺失。这些问题并不神秘都是传统开发里也会犯的错误只是 AI 犯错的方式更隐蔽。而应对方式也同样是传统开发里那套——靠流程约束而不是靠人盯。4.2 防线一强制Review关键路径代码必须人来写我在项目里有一条被写进规范的高压线架构代码、权限模型、金额计算、审批流状态机不允许 AI 单独产出必须人工主笔、AI 辅助。如果 AI 生成了这些模块的代码必须经过完整 Code Review 重构才能合入。这样做的原因是这些代码的属性不是“可运行的逻辑”而是“不可出错的高风险逻辑”。AI 写这些代码就像让一个刚入职还不熟悉业务的新人直接写支付核心风险太高。对于普通业务代码Review 的重点是“AI 是否照着契约实现”而不是“AI 写得是否优雅”。因为只要契约正确、测试覆盖到位写得好不好看反而不是第一优先级。4.3 防线二测试先行让AI写测试本身这是个很有意思的实践。我发现让 AI 写业务代码不如让它先写测试用例。因为测试用例描述的是“预期行为”这是确定性的东西而业务代码是实现细节是灵活性的东西。AI 对“确定性的描述”往往比对“灵活性的实现”更可靠。具体做法是在设计阶段我先把接口的输入和预期输出定义成一个表格包括正常路径、边界条件、异常路径。AI 根据这个表格生成单元测试然后我再让人 review 一遍测试用例本身确保证明的“预期行为”真的是业务想要的。等测试用例通过审查、合入基线之后再让 AI 去实现业务代码。这时候它有一个明确的目标让这些测试全部通过。这比任何提示词都更不容易跑偏。4.4 防线三CI流水线里的自动化关卡项目跑到一个月的时候我搭了一条专门的 CI 流水线每一次 AI 代码提交都会自动经历四关编译关卡不管代码优不优雅编译不过一票否决。规范关卡用统一的静态检查工具强制命名规范、禁止某些危险 API、检查死代码和明显的逻辑反模式。单测关卡跑所有已合入的单元测试统计覆盖率。覆盖率低于设定阈值的模块不允许合入。接口兼容检查检查本次改动是否破坏了既有接口的签名、返回结构、状态码定义。这套流水线最大的价值不是拦下的 bug 数量而是它把“质量检查”从人的负担变成了系统的负担。人的精力被解放出来去关注真正需要脑子的地方。4.5 防线四技术债登记表每笔债都有主AI 写代码还有个别的问题它会为了完成任务采取“绕路式实现”。比如需要查询一个用户的名称它发现可以直接查用户表但它可能为了减少关联查询把用户名称冗余到一个中间表里。这样的做法不报错、测试也能过但长期维护下去会积累一堆让人抓狂的技术债。我应对的办法是在项目里建了一张“技术债登记表”表格里记录哪个模块、哪段代码、谁发现的、问题类型、建议修法、优先级、截至日期。每发现一个 AI 产生的非最优实现就记录一笔每周统一 review 一次决定是立即修还是排期修。这张表的最大作用是让技术债“可见化”。以前技术债是隐性的大家心里知道有但没人愿意主动说。现在它被摊在桌面上而不是在某次重构时突然爆发。5. 多智能体协作的实战记录分工比人数重要聊到“多智能体 AI Agent 协作”很多人第一反应是“让好几个 AI 同时写代码”。这个理解太初级了。真要让多个 AI 同时参与一个项目你需要解决的核心问题是分工、协议、冲突处理。下面是我的一次完整实战记录。5.1 规划者-执行者-审查者的三角结构我在项目里配置过一套三角色的多智能体协作结构规划者Planner负责拆解任务、定义接口契约、输出任务描述。它相当于 AI 团队里的架构师但它不写业务代码。执行者Coder接收规划者的任务描述按照架构规范产出代码。它相当于搬砖的开发工程师。审查者Reviewer检查执行者的代码是否满足任务描述、是否有明显的 bug 模式、是否通过静态检查。它相当于 Code Review 的第一道关卡。人在这个结构里做的工作是最终裁决规划者拆的任务合不合理审查者的结论准不准确以及那些双方扯皮的问题由人来拍板。这个结构跑起来之后我发现一个有意思的现象把“分解任务”和“编写代码”分开反而比让同一个 AI 既拆任务又写代码效果好得多。因为规划者不会为了实现方便而人为降低任务难度它只从业务视角拆解执行者拿到的是清晰明确的任务不用在“到底想要什么”上做无谓的猜测。5.2 协作协议怎么让多个AI不互相打架多智能体协作最怕的事情是两个 Agent 同时改同一个文件或者 A Agent 生成的代码依赖 B Agent 还没实现的接口导致集成时一塌糊涂。我用了三招来避免这个问题第一招文件级分工。每个任务描述里明确写清“本任务涉及的文件清单”如果一个文件已被其他 Agent 的任务占用这个任务就不会下发给另一个 Agent。第二招契约优先。在多智能体的任务池里先定义好接口契约所有 Coder 只基于契约开发不基于“猜测别人会怎么实现”开发。这样哪怕两个 Agent 并行开发最终集成时只要契约一致代码必然能对上。第三招串行合入。主分支始终只有一个 Agent 的最终产出能合入。其他 Agent 的代码先在分支上跑跑通测试后再排期合入。这保证了主分支永远处于可用状态不会出现“上午是好的、下午一团糟”的情况。5.3 一次失败的协作实验教训是任务边界不清多智能体也不是一帆风顺。项目进行到第二个月时我做了一次实验让规划者把“报表中心”这个大模块拆成 10 个任务分给 5 个执行者并行开发。结果是一星期出了大问题。两张表分别被两个 Agent 改了A Agent 为了加一个字段把表的索引结构调整了B Agent 在生成查询语句时基于的是旧索引结构。两边各自测试都通过但合并到集成环境的瞬间报表查询性能暴跌接口超时一片。这次的根因不在于 Agent 能力而在于我作为任务分配者没有划清任务边界。修改表结构和生成查询语句这两个任务本质上是一件事的两个侧面不应该拆给两个 Agent 独立开发。从那以后我定了一个规矩涉及同一数据模型或同一底层资源的任务必须归到同一个执行者即使要拆也要串行执行而不是并行。多智能体的并行效率只有在任务边界真正独立的情况下才能兑现否则就是给自己挖坑。6. AI写不了的代码人类工程师真正的护城河说了这么多 AI 高效产出的部分我也想聊聊那些 AI 写不了的东西。这些是我在实际项目中反复体会到的也是我觉得 AI 时代工程师最重要的竞争力所在。6.1 需要“取舍”的代码AI只会给出“正确”答案不会给出“合适”答案在项目里我遇到过好几次这样的场景有一个功能用方案 A 实现逻辑优雅、扩展性好但开发成本高用方案 B 实现代码略丑但能快速上线满足当前业务节奏。面对这种选择AI 给出的答案几乎永远是方案 A——因为它只会判断“哪个答案在技术上是正确的”不会判断“哪个选择在业务当下是合适的”。但一个合格的工程师需要理解业务优先级知道哪个功能是核心、哪个功能是锦上添花知道这个系统的生命周期有多长、未来的演化方向是什么。这些东西不会写在任何需求文档里但它们最终决定了架构的选择、代码的走向。我在项目里经常做的只有 AI 做不到的是在两种“技术上正确”的方案之间基于对业务的理解、团队的开发节奏、系统的演进空间做出“更合适”的取舍。这种能力短期看 AI 替代不了。6.2 隐性知识写在代码之外的东西有段代码AI 生成了一版完全可运行、测试也能全部通过的实现但我 review 时还是打回了。代码本身没错但它没有处理一种特殊的业务状况当订单金额超过某个阈值时需要额外走一层风控审批这个状态在订单流转中被跳过了。这个规则为什么 AI 不知道因为它不在需求文档里只在产品经理和运营的口口相传中。是我在跟业务方吃饭时无意间听到的一句话才发现的。这就是隐性知识。它藏在老员工脑子里藏在会议记录里藏在业务方不经意的吐槽里。AI 能从代码库学到显性规则但学不到这种“不在场”的知识。而恰恰是这些隐性知识决定了系统在真正复杂业务场景下能不能站稳。6.3 我的最终体会AI Engineering是人的工程16 万行代码跑起来的那一刻我第一个念头不是“AI 真厉害”而是“我们这一套人机协作的流程终于站住了”。AI 确实写出了大部分代码但真正让这些代码能跑起来的是那个人类定下的架构、那个人类拆解的任务、那个人类设计的验收体系、以及那个人类在关键时刻坚持“这段代码必须我来写”的判断力。所以当你问“16 万行代码是怎么跑出来的”我的回答是AI 提供了速度人提供了方向。如果你也想在这条路上走得更远别把精力耗在“怎么写出完美的提示词”上多花点时间想想怎么设计一套让 AI 稳定发挥的流程。这才是 AI Engineering 的真谛。最后分享一个很小的实操技巧我后来养成了一个习惯每天下班前会把第二天准备交给 AI 的任务全部用文字写下来。不急着发给 AI先自己过一遍——如果这个任务描述我自己都解释不清楚那 AI 更不可能理解。这个习惯遇到几个问题都靠它兜底了。