各位做后端、做云原生、做平台工程的朋友大家好。最近在团队里跟进一个使用了大量 AI 辅助编码的微服务项目时遇到了一种很奇特的现象功能确实交付得很快但系统却像一个不断膨胀的雪球依赖项越来越多启动越来越慢线上问题越来越难查。团队成员形容这种感觉就像“被一个看不见的漩涡吸住越陷越深”。这不是个别团队的困境。当我们越来越依赖 AI 生成代码、自动补全依赖、自动修复报错时一个名为「螺旋」的赛博陷阱正在浮现。它不是某个具体的工具或框架而是一种由 AI 辅助开发引发的系统性失控你越是依赖 AI 解决眼前的局部问题就越会为系统埋下更深层的全局隐患最终整个项目进入一条难以回头的螺旋下降通道。本文将用工程视角拆解这个“螺旋”的本质结合一个真实可复现的 Spring Boot 项目案例给出排查依赖膨胀、建立 AI 辅助开发质量门禁的完整方案。1. 什么是「螺旋」AI 工程失控的技术隐喻1.1 从三个开发切面重新看“螺旋”如果我们把“螺旋”理解成一个技术现象而不是一个营销词它其实描述的是三种非常具体的失控循环第一个切面是依赖螺旋。AI 在生成业务代码时为了“确保功能可用”往往会倾向于引入尽可能多的第三方库。你让 AI 实现一个简单的 Excel 导出功能它可能顺手引入了 POI、EasyExcel、common-io、commons-lang3 等多个依赖。一开始只是几十兆的 jar 包但经过数十次 AI 生成和自动补全后项目的依赖树会膨胀得完全不可控。第二个切面是配置螺旋。AI 修复一个问题时往往会在配置文件里追加新的参数。这些参数之间可能存在隐藏的相互覆盖关系。当配置项数量超过团队成员的认知负荷后没有人能说清楚某个配置变更会影响哪些模块于是只能再让 AI 去分析配置依赖这又进一步增加了配置的复杂度。第三个切面是认知螺旋。这是最隐蔽的。当开发者习惯了“AI 生成 → 复制 → 运行通过”的开发模式后对底层原理的理解会逐渐退化。项目一旦出现 AI 无法解决的深层问题如并发冲突、分布式事务不一致团队就完全失去了排查能力只能继续用 AI 做各种尝试。这种“能力退化”与“工具依赖”互相强化形成一个几乎无法自主挣脱的闭环。这三个切面叠加在一起就是我今天想讲的“赛博邪教”一个由效率幻觉驱动、以技术债为代价、让人越陷越深的工程陷阱。1.2 为什么 AI 会加速螺旋的形成人类开发者引入依赖时通常会经过一个“必要性评估”的思考过程这个功能我能不能自己写这个库的维护状态如何引入后会不会和其他版本冲突但 AI 生成代码时这些评估过程几乎不存在。AI 的目标是“生成一个看起来正确且能通过的代码”它不会考虑三个月后这个依赖是否会被废弃也不会考虑这个 jar 包是否会和其他模块的版本产生冲突。这种“局部最优、全局无序”的生成逻辑正是螺旋得以形成的基础。理解了这个本质我们就能用工程手段去对抗它而不是简单地“禁止使用 AI”。2. 一个快进到失控的案例复盘为了让大家有更直观的认识我用一个模拟项目来完整复盘“螺旋”的形成过程。假设我们有一个订单查询微服务技术栈是 Spring Boot 3 Maven初期只有 5 个核心依赖。2.1 项目背景该服务最初由人工开发依赖清单非常清晰!-- pom.xml 初始版本 -- dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-jpa/artifactId /dependency dependency groupIdcom.mysql/groupId artifactIdmysql-connector-j/artifactId scoperuntime/scope /dependency dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency /dependencies此时项目构建时间约 20 秒启动时间约 5 秒任何人打开 pom.xml 都能在 30 秒内看懂项目依赖了哪些东西。2.2 第一阶段AI 生成让开发变快了很快团队开始使用 AI 辅助开发。第一个需求是增加订单导出功能。开发者向 AI 描述了需求AI 给出了一个完整的实现方案并且自动在 pom.xml 中加入了 EasyExcel、commons-csv、commons-io 三个依赖。代码能跑通功能也正常团队没有对新增依赖做过多审查。2.3 第二阶段依赖膨胀第二个需求是增加订单状态推送。AI 又引入了 spring-boot-starter-amqp 和 jackson-datatype-jsr310。第三个需求是做一个简单的缓存AI 推荐了 spring-boot-starter-data-redis但又额外带了一个 commons-pool2。到第四个月这个原本只有 5 个依赖的项目已经膨胀到了 43 个直接依赖、120 多个间接依赖。构建时间从 20 秒涨到 2 分 40 秒启动时间逼近 20 秒。最关键的是团队成员已经没有一个人能准确说出这些依赖中哪些是真正必要的哪些是 AI 在某个中间版本引入、后续重构后已经不再使用的“僵尸依赖”。2.4 第三阶段无人看清全局一次线上故障成了压垮骆驼的最后一根稻草。某个依赖的传递版本升级不是团队主动升级的而是另一个依赖的传递依赖版本漂移导致 Jackson 的序列化行为发生了变化线上订单数据导出出现乱码。问题是由于依赖树太庞大团队根本无法快速定位是哪个依赖引起的版本漂移。大家只能反复让 AI 分析日志AI 给出了各种可能的猜测团队试了整整一个下午才通过mvn dependency:tree找到问题根源。这次事故后团队决定对整个项目的依赖体系进行一次彻底清理并建立一套可持续的 AI 辅助开发质量门禁。2.5 第四阶段重构与告别螺旋清理工作分为三步第一步删除所有“没有任何代码 import”的依赖。 第二步用 Maven 的 dependency:analyze 插件找出声明了但未使用的依赖以及使用了但未声明的依赖。 第三步固定所有直接依赖的版本号并引入 Maven BOMBill of Materials统一管理版本。清理完成后依赖数量从 43 个降回 11 个构建时间恢复到 30 秒以内。这个案例并不是个例而是大量 AI 辅助开发团队的缩影。接下来我将把清理和防御的手段做成一套可持续运行的工程方案。3. 实战为项目装上依赖体检系统既然 AI 会源源不断地引入依赖我们就要有一个自动化的机制来“监控”和“约束”它的行为。下面这套实战方案可以帮你在项目里搭建一个依赖健康度体检系统。3.1 环境准备本文示例环境如下需要根据你的实际项目调整操作系统macOS / Linux / Windows 均可构建工具Maven 3.8JDK 版本17项目类型Spring Boot 3.x 多模块或单模块项目版本管理Gitmvn -v如果输入类似下面的信息说明 Maven 环境可用Apache Maven 3.9.6 Java version: 17.0.103.2 编写依赖健康度扫描脚本我们先写一个 Python 脚本用来扫描 pom.xml 中声明的依赖并检查每个依赖是否真的被代码引用了。这个脚本不是要替代 Maven 插件而是为了定期生成一份依赖审计报告方便团队评审。#!/usr/bin/env python3 # -*- coding: utf-8 -*- 项目路径tools/dependency_audit.py 功能扫描 Maven 项目依赖标记原始依赖与僵尸依赖 用法python tools/dependency_audit.py /path/to/project import os import re import sys from collections import defaultdict from pathlib import Path def parse_pom(pom_path): 从 pom.xml 中提取 groupId:artifactId:version 三元组 with open(pom_path, r, encodingutf-8) as f: content f.read() deps re.findall(rdependency(.*?)/dependency, content, re.S) result [] for dep in deps: gid re.search(rgroupId(.*?)/groupId, dep) aid re.search(rartifactId(.*?)/artifactId, dep) ver re.search(rversion(.*?)/version, dep) if gid and aid: result.append({ groupId: gid.group(1).strip(), artifactId: aid.group(1).strip(), version: ver.group(1).strip() if ver else managed }) return result def scan_java_imports(src_path): 扫描所有 Java 文件中的 import 语句 imports set() for root, _, files in os.walk(src_path): for f in files: if f.endswith(.java): file_path Path(root) / f with open(file_path, r, encodingutf-8) as fp: for line in fp: line line.strip() if line.startswith(import ): imports.add(line) return imports def main(project_path): project_root Path(project_path) pom_path project_root / pom.xml if not pom_path.exists(): print(f[ERROR] 未找到 pom.xml: {pom_path}) sys.exit(1) print(f[INFO] 解析 pom.xml: {pom_path}) all_deps parse_pom(pom_path) src_path project_root / src if not src_path.exists(): print(f[WARN] 未找到 src 目录跳过 import 检查) imports set() else: imports scan_java_imports(src_path) print(f[INFO] 总共声明依赖: {len(all_deps)} 个) print(f[INFO] 扫描到 import 语句: {len(imports)} 条\n) suspicious [] for dep in all_deps: gid dep[groupId] aid dep[artifactId] # 以 artifactId 的最后一段做粗略匹配 # 实际使用时建议结合 groupId 做更精确的映射 keyword aid.replace(spring-boot-starter-, ) if dep.get(version) managed: managed_info f (version 由父 pom 管理) else: managed_info f (version: {dep[version]}) # 检查是否有对应的 import matched False for imp in imports: if keyword in imp or gid in imp: matched True break if not matched: suspicious.append({ groupId: gid, artifactId: aid, info: managed_info }) if suspicious: print([WARN] 以下依赖疑似未在代码中直接使用可能为僵尸依赖:) for s in suspicious: print(f - {s[groupId]}:{s[artifactId]}{s[info]}) else: print([OK] 未发现明显的僵尸依赖) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python tools/dependency_audit.py /path/to/project) sys.exit(1) main(sys.argv[1])这个脚本的核心逻辑是解析 pom.xml 中所有显式声明的依赖然后扫描 src 目录下所有 Java 文件的 import 语句用 artifactId 的片段去匹配 import。如果某个依赖在代码中没有任何对应的 import就会被标记为“疑似僵尸依赖”。运行方式python tools/dependency_audit.py .需要说明的是这个脚本是一个简化版本只适合做粗筛。实际项目中spring-boot-starter-*这种依赖即使代码里没有直接 import 它的类也可能因为自动装配而成为必要依赖。因此脚本的输出只能作为评审参考不能直接自动删除。3.3 接入 CI 质检流程比“事后扫描”更好的方案是把依赖健康度检查前置到 CI 中让每一个新引入的依赖都必须经过自动化检查和人工确认。我建议在你的 CI 流程中加入两个 Maven 插件第一个是maven-dependency-plugin用于分析依赖使用情况plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version3.6.1/version executions execution idanalyze-dependencies/id goals goalanalyze/goal /goals phaseverify/phase /execution /executions /plugin在项目根目录执行mvn verify如果存在“使用了但未声明”或“声明了但未使用”的依赖Maven 会输出类似下面的警告[WARNING] Used undeclared dependencies found: [WARNING] org.springframework:spring-core:jar:6.1.4:compile [WARNING] Unused declared dependencies found: [WARNING] org.apache.commons:commons-lang3:jar:3.14.0:compile这里需要注意的是analyze目标基于字节码分析对于通过反射或配置文件加载的类可能会出现误报。因此 CI 中建议把该插件的输出作为“检查报告”而不是“硬性失败条件”可以结合后面介绍的 BOM 管理来一起判断。第二个插件是versions-maven-plugin用于定期检查依赖版本更新情况mvn versions:display-dependency-updates这个命令会列出项目所有依赖的最新可用版本。建议每两周跑一次由专人评估是否有必要升级。3.4 添加 AI 生成代码的依赖审查清单前面说过AI 生成代码时不会做依赖必要性评估。为了把这道关补上建议在项目仓库中放置一份《AI 生成代码依赖引入检查单》内容如下# AI 生成代码依赖引入检查单 提交代码前请逐项确认 1. 新引入的依赖是否在 pom.xml 中显式声明 2. 该依赖是否被代码直接 import 并使用而非仅为间接依赖 3. 是否已排除传递依赖中的重复项 4. 新依赖是否会与项目现有依赖产生版本冲突建议运行 mvn dependency:tree 检查 5. 是否已确认该依赖的 Maven 坐标在公共仓库中存在 6. 如果该依赖只在某个模块中使用是否放在了对应模块的 pom.xml 中 7. 是否有纯 JDK 实现可以替代该依赖 8. 是否已将该依赖添加到 BOM 统一管理团队在 Code Review 时凡是涉及 pom.xml 变更的 MR都需要对照这个清单进行逐项确认并在 MR 描述中粘贴检查结果。这样一来即使 AI 生成了冗余依赖也会在人工审核环节被拦截。4. 工程化防旋AI 辅助开发流程规范依赖扫描和 CI 检查只是“止血”的手段。要从根源上阻断螺旋还需要在开发流程层面建立几项硬性规范。4.1 最小依赖原则团队内部必须达成一个共识AI 生成的代码中如果某个功能可以用 JDK 原生 API 或者项目已有的依赖实现就不允许引入新的依赖。为了执行这个原则可以在 Code Review 阶段增设一个专门的检查项“本次变更是否新增了依赖如果新增了请说明为什么不能使用已有依赖。”这个看似简单的提问可以倒逼开发者去思考依赖的必要性而不是无脑接受 AI 的建议。4.2 依赖版本“双锁”策略很多依赖冲突问题来自版本漂移。即使你自己的 pom.xml 写死了版本传递依赖的版本也可能被其他依赖覆盖。推荐的“双锁”策略是第一层锁在项目根 pom.xml 中使用dependencyManagement统一管理所有直接依赖的版本。第二层锁针对核心依赖如 Jackson、Spring Framework、Netty 等在 dependencyManagement 中显式排除传递依赖的版本漂移。例如dependencyManagement dependencies !-- 统一管理 Jackson 版本 -- dependency groupIdcom.fasterxml.jackson/groupId artifactIdjackson-bom/artifactId version2.17.0/version typepom/type scopeimport/scope /dependency !-- 统一管理 Spring Boot BOM -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-dependencies/artifactId version3.2.5/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement这样做的目的是把版本的“最终决定权”收拢到项目自身而不是让传递依赖的版本漂移来决定线上行为。4.3 AI 代码的强制 Code Review这里要特别强调一个心态转变AI 生成的代码应当被视为“第三方贡献”而不是“自己写的代码”。这两者的根本区别在于自己写的代码你清楚每一行的意图。第三方贡献的代码你必须在合并前做完整审查。因此在使用 AI 辅助编码时必须至少有一名不参与该功能开发的资深工程师进行 Code Review。这名工程师不需要审查 AI 生成的每一行代码但必须重点关注以下内容pom.xml 变更是否合理。新增的配置项是否必要。是否有隐藏的全局副作用如改变了全局序列化行为、增加了全局过滤器、修改了线程池配置等。生成代码是否存在明显的性能隐患和安全隐患。4.4 定期“依赖清理日”推荐的节奏是每两周或每个迭代周期安排一次“依赖清理日”专门用来处理依赖膨胀问题。具体操作步骤# 1. 列出所有依赖树 mvn dependency:tree dependency-tree.txt # 2. 找出重复版本 mvn dependency:analyze-duplicate # 3. 检查依赖更新 mvn versions:display-dependency-updates # 4. 移除无用的依赖确认后手动编辑 pom.xml清理日结束后需要提交一份《依赖清理日志》记录本次清理了哪些依赖、清理后的构建时间变化、以及是否有风险点需要持续观察。5. 高频问题与排查指南为了便于大家在实际项目中快速排查问题我将 AI 辅助开发中常见的问题汇总成了一张速查表问题现象常见原因解决思路构建时间从几十秒膨胀到几分钟依赖数量过多Maven 需要解析大量 jar 包运行mvn dependency:tree分析依赖树清理僵尸依赖启动时出现 NoClassDefFoundErrorAI 生成的代码引用了未显式声明的依赖使用mvn dependency:analyze找出使用了但未声明的依赖多个依赖中存在同一个类的不同版本传递依赖版本漂移使用dependencyManagement和 BOM 统一管理版本升级某个依赖后线上行为异常依赖升级带来了序列化、线程模型或日志行为的隐性变更升级后先跑全量回归重点检查日志格式、JSON 序列化、线程池行为AI 推荐的依赖版本与项目不兼容AI 的版本知识可能滞后或过于激进以 Maven 中央仓库中实际存在的稳定版本为准不要直接使用 AI 推荐的版本号pom.xml 中出现大量“看起来多余”的配置AI 修复某个局部问题时添加了全局性的配置Code Review 时留意配置作用域能局部配置就不要全局配置团队离开 AI 后无法排查问题认知依赖螺旋形成定期组织无 AI 环境下的代码走读和故障演练这张表是实战中最高频的问题。遇到类似情况时建议按照“定位范围 → 生成依赖树 → 对比变更记录 → 小范围验证”的顺序来排查而不是盲目让 AI 试错。6. 团队能力建设与 AI 工具边界最后谈一个容易被忽视的层面团队能力建设。防旋的根本不是禁用 AI而是确保团队的核心成员对系统有足够的掌控力。这就引申出一个重要原则AI 可以帮你写代码但它不能替你做架构决策也不能替你理解业务上下文。我建议团队至少保持以下三个方面的“人工能力”第一核心链路代码必须人工编写和审查。指的是涉及资金、数据一致性、用户权限等关键路径的代码不允许直接由 AI 生成后未经深度审查就合入。这里的深度审查不是看一眼有没有明显 bug而是要求审查人理解每一行代码的边界条件。第二保持“无 AI 排障”演练。每季度可以安排一次故障演练要求工程师在不使用 AI 辅助工具的情况下通过分析日志、查看依赖树、阅读源码来定位一个预设故障。这个训练能有效阻止认知依赖螺旋的深化。第三建立 AI 工具使用规范文档。文档中明确“哪些场景可以使用 AI”“哪些场景不建议使用 AI”“AI 生成代码合入前需要经过什么流程”。规范不需要写得很死板但必须明确边界和责任。7. 结语打破螺旋做 AI 的主人回到标题中那个「螺旋」。它并不是一个抽象的概念而是技术债、认知退化和自动化失控三者互相喂养的结果。今天我通过一个真实的依赖膨胀案例和大家一起完整地走了一遍依赖体检系统的搭建过程并梳理了一套可持续的工程规范用mvn dependency:tree和dependency:analyze量化依赖健康度。用 BOM 和 dependencyManagement 收拢版本控制权。用依赖清理日和 Code Review 清单阻断新的膨胀源。用人工能力建设保持团队对系统的掌控力。这些手段并不复杂也不需要引入额外的重量级平台但它们能为你建立一道护栏让 AI 真正成为提升效率的助手而不是将项目拖入失控循环的推手。技术浪潮不会倒退AI 辅助开发是未来的方向。但越是在高效工具面前越要保持工程师的清醒和掌控力。希望这篇文章能对你和你的团队有所启发在享受 AI 红利的同时守住系统的稳定与可控。如果这篇内容对你有帮助可以收藏备用欢迎在评论区分享你在 AI 辅助开发中遇到过的“螺旋”案例。