AI编程这两年已经成了开发者的标配从自动补全到整段代码生成大家嘴上说着“AI写代码不靠谱”手上却很诚实地把越来越多逻辑交给模型去生成。但我在实际项目里尤其是维护过几轮迭代的老系统之后越来越明显感觉到一个矛盾AI确实帮我们写完了更多代码但代码的复杂度——那种真正决定项目还能不能维护的复杂度——正在悄悄失控。功能提交变快了可改一个点就要动一串文件注释很规范可没人说得清为什么要有这层抽象代码量暴涨真正能看懂全貌的人却没几个。这篇文章就当是一次复盘AI编程时代的代码复杂性到底是怎么失控的以及我实践中验证过的一些控制手段。1. AI编程时代代码复杂性问题为什么突然浮出水面1.1 AI扩展了产能也放大了复杂度先说一个直观对比。以前一个人一天手写五百行有效代码这个量级下哪怕你的设计再随意第二天自己都能把逻辑捋清楚。现在有了AI辅助一天生成两千行甚至五千行代码变得很轻松但人脑的认知带宽没有同步提升。你不可能在同样时间里理解五千行代码的每一处细节而恰恰是那些你不理解的代码会在未来某个迭代里变成雷。我有个真实的体感去年用AI重构一个订单模块原来手工写大概需要两周AI辅助之下三天就搞定了接口测试也全绿。但上线后第三周运营提了一个“仅修改备注字段时不要触发通知”的需求我顺着调用链找下去发现AI当初生成代码时把这套逻辑分别塞进了三个service方法和两个事件监听器里彼此通过共享的上下文对象传递状态。为了加一个if判断到头来改了五个文件、调整了三处测试用例。手写代码时你会天然倾向于把这种简单需求收敛在同一个地方AI则不然它会生成“看起来结构合理”但实际散布各处的一堆代码。这就是问题所在。AI扩展的是代码生产速度但它不会替你承担结构设计的责任。代码复杂度在快速产出中被稀释、被隐藏直到需求开始变化时才集中爆发。1.2 复杂度失控的三个信号放大效应、隐性依赖、认知承接我总结了自己项目里最常遇到的三个复杂度失控信号大家可以对照检查。第一个信号是“修改放大效应”。原本加一个字段、改一个状态只需动一两个文件现在同样一个改动涉及五六个文件而且每处改动都像是“缺一不可”。这说明AI生成的代码把逻辑重复放在多个位置而不是收敛到单一事实来源。第二个信号是隐性依赖远多于显性依赖。显性依赖是你直接import或者调用的函数看一眼就知道隐性依赖指的是共享的可变状态、事件触发的时序、约定俗成的命名规则、隐藏在配置里的逻辑。AI生成代码特别喜欢制造隐性依赖因为它会基于你提示词里的模糊表述自作主张地设计一些“约定式”交互。一旦你换了上下文或者换了个AI工具这些约定就可能彻底失传。第三个信号是认知负担高度集中在少数人身上。团队里最懂业务的老员工能看懂AI生成的代码其他人在AI生成的复杂代码面前完全是懵的。我以前带过一个项目AI生成的核心调度模块只有两个人敢碰其他人改出问题根本查不了。这不是技术能力问题而是代码复杂度已经把认知门槛抬到普通成员够不着的高度。代码一旦变成“只有少数人敢动”的东西项目的健康度就非常危险了。2. 为什么AI会让代码越来越难维护拆开看几个病根2.1 提示词越模糊AI越喜欢“发挥”很多人让AI写代码时提示词写得很随意比如“帮我写一个订单状态机”“给这个接口加个缓存”。AI接收到模糊指令时最容易做的事就是“发挥”——它会把能想到的边界情况都处理一遍额外封装一个抽象类再顺手加个配置项。你看着代码觉得“哇考虑得真全”但这份“全面”背后是没有经过需求验证的假设。我举个例子。我一个做嵌入式控制的朋友用AI给STC单片机写了一段按键扫描逻辑提示词只写了“用状态机处理按键消抖”。AI生成代码后他直接编译烧录功能确实正常。但后来发现一个问题代码里用了动态内存分配而这款单片机本身只有几百字节RAM频繁分配释放导致内存碎片运行两天后系统偶尔崩溃。AI并没有错它只是执行了提示词里的“状态机”需求但它没有感知到运行环境对内存管理的苛刻限制。所以这里要形成一个意识提示词就是你的设计说明书。提示词里没有明确的约束AI就会用“通用最佳实践”来填坑而这些通用实践在特定项目里可能恰恰是复杂度爆炸的来源。AI编程提示词并不是让AI自由发挥而是你要把自己的约束、边界、限制写清楚让它在一个受控的空间内生成代码。2.2 过度抽象AI把简单问题“工程化”了另一个典型病根是过度抽象。AI训练语料里到处都是设计模式、架构分层、依赖注入这些内容看多了AI生成代码时会倾向于“把简单问题工程化”。我见过一个真实案例同事让AI给一个内部工具写一个SCV文件导出功能结果AI生成了接口定义、策略模式、工厂类、配置化映射四层结构。功能跑起来没问题问题是整个工具一共就三处调用这四层抽象带来的复杂度和收益完全不成正比。后来维护的人为了改一个导出列名需要顺着接口找到策略类再找到具体映射一整套流程下来半小时过去了。很多AI生成的代码都存在这种“架构洁癖”。它不关心你的项目实际情况只是按训练集里的“高质量代码”标准输出。如果你没有在提示词里强调“保持简单”“不要引入额外依赖”“按现有代码风格实现”它就会默认使用一套复杂架构。这里我想说清楚过度抽象本身不是错误架构设计确实需要分层。问题在于抽象发生在错误的位置和错误的粒度上。手写代码时你会凭经验判断“这个逻辑以后会不会复用”AI则没有这个判断能力它倾向于把所有可能复用的情况都准备好。结果是大量“未来可能用到”的抽象占用了当下的维护成本。2.3 上下文断裂模型没有“代际记忆”再往深一层说AI生成的代码还有一个先天缺陷它大多数情况下是“无记忆”的。这里的“无记忆”不是说对话上下文不保留而是AI对你整个项目的演化历史、设计取舍、历史坑点缺乏感知。手写代码的团队里有一个非常重要的隐式知识传递过程当年为什么不用缓存为什么这里不用消息队列为什么这个字段选择放在A表而不是B表这些决策可能早就消散在旧PR的评论里但老员工记住了一部分新人靠着问老员工也能逐渐获得传承。AI没有这个过程。当AI生成了一大段复杂代码后它不会告诉你“这段逻辑里的某个判断是因为生产环境曾出现过一个诡异bug而加的”更不会告诉你“那个抽象类目前只有一个实现类当初纯粹是为了防止过度耦合”。这些原因完全丢失后续任何一个不了解背景的人或者换成另一个AI工具去修改这段代码都会在错误的方向上动刀。我自己的经验是AI生成代码越多项目的“无主代码”就越多——这些代码能跑、有测试覆盖但没有任何人真正理解它为什么这么写。这类代码是复杂度失控的温床因为它是不可维护的哪怕它暂时是“正确的”。3. 实战对策我是怎么在AI开发流程里重新建立复杂度防线的3.1 提示词里写清楚“约束”不是让AI自由发挥前两节说了病根这一节聊解决方案。最前置的一道防线就是你发出去的那段提示词。AI编程提示词写得好不好直接决定生成代码的复杂度走向。我的习惯是提示词必须包含三个部分功能需求、明确禁止项、现有代码上下文。功能需求不用多说禁止项特别重要比如“不要新增依赖”“不要使用动态内存分配”“不要引入设计模式”“保持和现有代码风格一致”。你不要觉得这些话说出来多余实测下来明确写“不要新增依赖”和只写“帮我在现有项目里加个功能”生成结果差异巨大。另外提示词里要提供足够的上下文。别只让AI“写一个配置文件解析器”你要告诉它“现有的配置格式是INI风格解析逻辑放在utils目录不要单独建包错误处理直接return false”。上下文越具体AI的自由发挥空间越小复杂度就越可控。后面我会专门展开提示词模板的写法。3.2 用代码评审和静态检查拦住复杂度代码评审和静态检查是我重建防线时最先补起来的一环。AI生成代码速度快代码评审却必须要慢下来不能因为“AI写的嘛肯定没问题”就把流程省了。评审时我重点关注两件事修改是否放大了调用链、抽象层次是否与项目实际匹配。放大调用链很好判断看PR里改动的文件数量就行如果一个两行的业务改动牵涉到五个文件不管AI生成的代码多漂亮一律打回去重写。抽象层次则稍微主观一点我一般问自己一个问题“这段代码如果以后一个月都不会再碰第二次它需要这么复杂的结构吗”答案是不需要就直接要求简化。静态检查建议接入工具的。选型上我比较推荐SonarQube或ESLint配合复杂度规则。团队里可以约定圈复杂度超过某个阈值的函数必须重构SonarQube可以把这个规则强制卡在CI阶段不通过就不能合入。听起来像是增加流程负担但实际执行下来真正卡住的大多是AI生成代码里的复杂函数手写代码反而很少出问题。3.3 架构约定要前置让AI按你的规则“切菜”光有拦截还不够更有效的是把约束前置到架构层面让AI从一开始就在你的骨架里生成代码。具体来说团队里要有明确的目录结构、分层规范、命名规范、异常处理约定并且这些规范要被AI“看得到”。你可以把项目的README、架构文档、编码规范文件都丢给AI工具做上下文同时在提示词里注明“请严格按照以下开发规范编码不要自行设计新的目录或抽象”。这样AI生成的代码会天然收敛在既有架构框架内复杂度更容易被控制。再进一步很多AI编程工具支持创建项目级的定制规则或自定义指令把这些规范固化到工具里团队每个人用AI生成的代码都会遵循同一套骨架。我自己的团队现在已经把“状态机只允许放在state目录”“外部接口调用必须走gateway层”“禁止自定义异常类”这类约定写进了AI提示词模板里效果非常明显。4. 工具链组合实战用Git worktree和CI搭复杂度预警系统4.1 为什么Git worktree在AI编程时代特别有用聊一个比较偏门但实用的工具Git worktree。为什么它在AI编程时代特别有用因为AI生成的代码经常需要快速验证而多分支并行验证可以极大减少上下文切换带来的认知负担。默认情况下你只有一个工作目录切换分支时要么stash要么commit才能让工作区干净。用AI生成代码的人都知道AI往往在一段上下文里连续工作很久你切出去看另一个bug回来以后之前AI对话的上下文可能就丢了工作区的改动也得整理。Git worktree让你可以同时checkout多个分支到不同目录每个目录独立工作互不干扰。比如我在改一个复杂功能时会开一个worktree放AI正在生成的代码另一个worktree保留着稳定版的代码环境方便随时对比行为差异。这样即使AI生成的代码在验证时出现意外也不会污染当前主线环境排查问题和回滚都干净利落。具体操作很简单git worktree add ../project-feature-branch feature-branch这就创建了一个新目录指向feature分支。需要切换不同AI实验时各开一个worktree各自跑测试互不影响。用完一个就删掉这个worktreegit worktree remove ../project-feature-branch很干净。4.2 把复杂度度量接进CI让失控“发票”在合并前爆出来前面说到的复杂度阈值卡口真正落地要靠CI。我们的做法是把ESLint复杂度规则和SonarQube的质量门禁都接到CI流水线里每次push代码时自动跑跑不过就直接拦截merge request。具体配置上ESLint的max-params可以限制函数参数数量complexity规则可以设置圈复杂度上限SonarQube侧可以配置“圈复杂度高于15的函数必须重构”之类的质量规则。这些数值不是拍脑袋定的需要结合项目实际情况调整。我们一开始把圈复杂度上限设成10结果大量AI生成的函数被卡住明显矫枉过正后来调成15同时要求重构的复杂性函数数量逐渐下降效果不错。这里有一个实操技巧复杂度度量只是信号不是最终审判。不能只靠CI拦截说“你这函数太复杂改”要配合注释和评审流程告诉开发者“为什么被拦截”。我们在CI加了产物阶段的报告链接开发者看到拦截原因后可以直接跳转查看哪一行代码导致复杂度上升到阈值。这样流程从“找茬”变成“辅助”体验好很多团队的接受度也高。4.3 多工具组合后的整体开发节奏把这些工具串起来之后AI编程的开发节奏和以前完全不同了。我的日常流程大致是先开一个Git worktree拉出功能分支把项目规范和必要的上下文信息写进提示词让AI在指定骨架内生成代码本地跑通后push到远程触发CI自动执行静态检查和复杂度度量通过后再走代码评审评审人只需要关注业务逻辑和调用链是否符合预期不需要把每个实现细节都读透。这套流程走顺之后复杂度失控的情况明显减少。不是因为AI变乖了而是因为失控代码在进入主分支之前就被拦下来了。工具链不是用来限制开发效率的它是把“复杂度检查”这件事从人肉记忆变成系统保障让AI的产出被规范在可控范围内。5. 实战中踩过的坑以及一些有效的提醒5.1 AI生成的复杂代码不敢删怎么办这是我在团队里遇到最多的一个问题AI生成了一段复杂的模块代码看起来有测试、有注释就是没人敢改也没人敢删。因为删了之后不知道会不会挂掉隐性的依赖。我的处理办法是分两步走。第一步先让AI自己解释这段代码——把模块丢进AI对话里让AI帮你梳理它的职责和依赖关系相当于做一个“代码考古”的初稿记录。第二步找到真正拥有关键知识的人让他在初稿基础上确认哪些依赖是真依赖、哪些是AI臆想出来的假设。确认完以后把“这段代码为什么存在”写在模块顶部注释里。如果确认结果是“这个模块完全没有存在的必要”那就果断删除。删完如果测试挂了刚好说明哪里有隐藏依赖修复它比留着一坨“没人理解的复杂代码”要好得多。5.2 复杂度突发爆表时的紧急预案有时候复杂度不是缓慢上升的而是一次性爆表。比如某次AI生成的代码合并进去后线上出现性能问题你发现是因为新代码的调用链比原来长很多复杂度已经超出可诊断范围。这时候我建议用“回滚优先复盘在后”的策略先把代码回滚到上一个稳定版本恢复线上服务再把复杂代码放到worktree里慢慢分析。不要顶着线上故障去剖析AI代码那会把人逼疯。复盘时有一个核心问题要问清楚这段代码为什么会这么复杂是因为需求本身就复杂还是AI在生成时用了不必要的抽象如果需求本身就复杂那表示设计阶段就没有拆解清楚下一步要重新做架构设计如果是后者说明提示词约束不够需要把这次失败的教训补进提示词模板的“禁止项”里。5.3 小团队如何让复杂度约定真正落地很多小团队觉得复杂度治理是大团队的事自己三五个开发者没必要搞那些流程。我的观点恰恰相反人越少越是经不起复杂度失控带来的返工成本。大团队有专门的人做架构治理小团队没有所以才更需要靠工具和约定兜底。小团队落地复杂度约定注意别一上来就整很大的体系先从三件事做起约定圈复杂度上限、要求AI生成代码必须走代码评审、提示词模板里必须有“禁止项”。这三件事不需要引入任何额外工具用现有的Git和CI就能执行起来。等团队适应了再把Git worktree、SonarQube这些加到流程里。我个人的体会是AI编程这件事本身是中性的复杂的不是工具而是我们怎么使用工具的态度。你把AI当成一个什么都能干的魔法师它就会给你变出一片复杂的魔法森林你把AI当成一个必须在规则里干活的实习生它就能稳定输出你还hold得住的代码。代码复杂度的控制权始终在开发者自己手里不在AI手里。最后再分享一个小技巧每次跟AI对话结束时顺手让它总结“当前工作目录里新增了哪些文件、改动了哪些函数”并把这份清单附到PR描述里。这个小小的动作能让后期排查复杂问题时节省大量时间。
AI编程这两年已经成了开发者的标配从自动补全到整段代码生成大家嘴上说着“AI写代码不靠谱”手上却很诚实地把越来越多逻辑交给模型去生成。但我在实际项目里尤其是维护过几轮迭代的老系统之后越来越明显感觉到一个矛盾AI确实帮我们写完了更多代码但代码的复杂度——那种真正决定项目还能不能维护的复杂度——正在悄悄失控。功能提交变快了可改一个点就要动一串文件注释很规范可没人说得清为什么要有这层抽象代码量暴涨真正能看懂全貌的人却没几个。这篇文章就当是一次复盘AI编程时代的代码复杂性到底是怎么失控的以及我实践中验证过的一些控制手段。1. AI编程时代代码复杂性问题为什么突然浮出水面1.1 AI扩展了产能也放大了复杂度先说一个直观对比。以前一个人一天手写五百行有效代码这个量级下哪怕你的设计再随意第二天自己都能把逻辑捋清楚。现在有了AI辅助一天生成两千行甚至五千行代码变得很轻松但人脑的认知带宽没有同步提升。你不可能在同样时间里理解五千行代码的每一处细节而恰恰是那些你不理解的代码会在未来某个迭代里变成雷。我有个真实的体感去年用AI重构一个订单模块原来手工写大概需要两周AI辅助之下三天就搞定了接口测试也全绿。但上线后第三周运营提了一个“仅修改备注字段时不要触发通知”的需求我顺着调用链找下去发现AI当初生成代码时把这套逻辑分别塞进了三个service方法和两个事件监听器里彼此通过共享的上下文对象传递状态。为了加一个if判断到头来改了五个文件、调整了三处测试用例。手写代码时你会天然倾向于把这种简单需求收敛在同一个地方AI则不然它会生成“看起来结构合理”但实际散布各处的一堆代码。这就是问题所在。AI扩展的是代码生产速度但它不会替你承担结构设计的责任。代码复杂度在快速产出中被稀释、被隐藏直到需求开始变化时才集中爆发。1.2 复杂度失控的三个信号放大效应、隐性依赖、认知承接我总结了自己项目里最常遇到的三个复杂度失控信号大家可以对照检查。第一个信号是“修改放大效应”。原本加一个字段、改一个状态只需动一两个文件现在同样一个改动涉及五六个文件而且每处改动都像是“缺一不可”。这说明AI生成的代码把逻辑重复放在多个位置而不是收敛到单一事实来源。第二个信号是隐性依赖远多于显性依赖。显性依赖是你直接import或者调用的函数看一眼就知道隐性依赖指的是共享的可变状态、事件触发的时序、约定俗成的命名规则、隐藏在配置里的逻辑。AI生成代码特别喜欢制造隐性依赖因为它会基于你提示词里的模糊表述自作主张地设计一些“约定式”交互。一旦你换了上下文或者换了个AI工具这些约定就可能彻底失传。第三个信号是认知负担高度集中在少数人身上。团队里最懂业务的老员工能看懂AI生成的代码其他人在AI生成的复杂代码面前完全是懵的。我以前带过一个项目AI生成的核心调度模块只有两个人敢碰其他人改出问题根本查不了。这不是技术能力问题而是代码复杂度已经把认知门槛抬到普通成员够不着的高度。代码一旦变成“只有少数人敢动”的东西项目的健康度就非常危险了。2. 为什么AI会让代码越来越难维护拆开看几个病根2.1 提示词越模糊AI越喜欢“发挥”很多人让AI写代码时提示词写得很随意比如“帮我写一个订单状态机”“给这个接口加个缓存”。AI接收到模糊指令时最容易做的事就是“发挥”——它会把能想到的边界情况都处理一遍额外封装一个抽象类再顺手加个配置项。你看着代码觉得“哇考虑得真全”但这份“全面”背后是没有经过需求验证的假设。我举个例子。我一个做嵌入式控制的朋友用AI给STC单片机写了一段按键扫描逻辑提示词只写了“用状态机处理按键消抖”。AI生成代码后他直接编译烧录功能确实正常。但后来发现一个问题代码里用了动态内存分配而这款单片机本身只有几百字节RAM频繁分配释放导致内存碎片运行两天后系统偶尔崩溃。AI并没有错它只是执行了提示词里的“状态机”需求但它没有感知到运行环境对内存管理的苛刻限制。所以这里要形成一个意识提示词就是你的设计说明书。提示词里没有明确的约束AI就会用“通用最佳实践”来填坑而这些通用实践在特定项目里可能恰恰是复杂度爆炸的来源。AI编程提示词并不是让AI自由发挥而是你要把自己的约束、边界、限制写清楚让它在一个受控的空间内生成代码。2.2 过度抽象AI把简单问题“工程化”了另一个典型病根是过度抽象。AI训练语料里到处都是设计模式、架构分层、依赖注入这些内容看多了AI生成代码时会倾向于“把简单问题工程化”。我见过一个真实案例同事让AI给一个内部工具写一个SCV文件导出功能结果AI生成了接口定义、策略模式、工厂类、配置化映射四层结构。功能跑起来没问题问题是整个工具一共就三处调用这四层抽象带来的复杂度和收益完全不成正比。后来维护的人为了改一个导出列名需要顺着接口找到策略类再找到具体映射一整套流程下来半小时过去了。很多AI生成的代码都存在这种“架构洁癖”。它不关心你的项目实际情况只是按训练集里的“高质量代码”标准输出。如果你没有在提示词里强调“保持简单”“不要引入额外依赖”“按现有代码风格实现”它就会默认使用一套复杂架构。这里我想说清楚过度抽象本身不是错误架构设计确实需要分层。问题在于抽象发生在错误的位置和错误的粒度上。手写代码时你会凭经验判断“这个逻辑以后会不会复用”AI则没有这个判断能力它倾向于把所有可能复用的情况都准备好。结果是大量“未来可能用到”的抽象占用了当下的维护成本。2.3 上下文断裂模型没有“代际记忆”再往深一层说AI生成的代码还有一个先天缺陷它大多数情况下是“无记忆”的。这里的“无记忆”不是说对话上下文不保留而是AI对你整个项目的演化历史、设计取舍、历史坑点缺乏感知。手写代码的团队里有一个非常重要的隐式知识传递过程当年为什么不用缓存为什么这里不用消息队列为什么这个字段选择放在A表而不是B表这些决策可能早就消散在旧PR的评论里但老员工记住了一部分新人靠着问老员工也能逐渐获得传承。AI没有这个过程。当AI生成了一大段复杂代码后它不会告诉你“这段逻辑里的某个判断是因为生产环境曾出现过一个诡异bug而加的”更不会告诉你“那个抽象类目前只有一个实现类当初纯粹是为了防止过度耦合”。这些原因完全丢失后续任何一个不了解背景的人或者换成另一个AI工具去修改这段代码都会在错误的方向上动刀。我自己的经验是AI生成代码越多项目的“无主代码”就越多——这些代码能跑、有测试覆盖但没有任何人真正理解它为什么这么写。这类代码是复杂度失控的温床因为它是不可维护的哪怕它暂时是“正确的”。3. 实战对策我是怎么在AI开发流程里重新建立复杂度防线的3.1 提示词里写清楚“约束”不是让AI自由发挥前两节说了病根这一节聊解决方案。最前置的一道防线就是你发出去的那段提示词。AI编程提示词写得好不好直接决定生成代码的复杂度走向。我的习惯是提示词必须包含三个部分功能需求、明确禁止项、现有代码上下文。功能需求不用多说禁止项特别重要比如“不要新增依赖”“不要使用动态内存分配”“不要引入设计模式”“保持和现有代码风格一致”。你不要觉得这些话说出来多余实测下来明确写“不要新增依赖”和只写“帮我在现有项目里加个功能”生成结果差异巨大。另外提示词里要提供足够的上下文。别只让AI“写一个配置文件解析器”你要告诉它“现有的配置格式是INI风格解析逻辑放在utils目录不要单独建包错误处理直接return false”。上下文越具体AI的自由发挥空间越小复杂度就越可控。后面我会专门展开提示词模板的写法。3.2 用代码评审和静态检查拦住复杂度代码评审和静态检查是我重建防线时最先补起来的一环。AI生成代码速度快代码评审却必须要慢下来不能因为“AI写的嘛肯定没问题”就把流程省了。评审时我重点关注两件事修改是否放大了调用链、抽象层次是否与项目实际匹配。放大调用链很好判断看PR里改动的文件数量就行如果一个两行的业务改动牵涉到五个文件不管AI生成的代码多漂亮一律打回去重写。抽象层次则稍微主观一点我一般问自己一个问题“这段代码如果以后一个月都不会再碰第二次它需要这么复杂的结构吗”答案是不需要就直接要求简化。静态检查建议接入工具的。选型上我比较推荐SonarQube或ESLint配合复杂度规则。团队里可以约定圈复杂度超过某个阈值的函数必须重构SonarQube可以把这个规则强制卡在CI阶段不通过就不能合入。听起来像是增加流程负担但实际执行下来真正卡住的大多是AI生成代码里的复杂函数手写代码反而很少出问题。3.3 架构约定要前置让AI按你的规则“切菜”光有拦截还不够更有效的是把约束前置到架构层面让AI从一开始就在你的骨架里生成代码。具体来说团队里要有明确的目录结构、分层规范、命名规范、异常处理约定并且这些规范要被AI“看得到”。你可以把项目的README、架构文档、编码规范文件都丢给AI工具做上下文同时在提示词里注明“请严格按照以下开发规范编码不要自行设计新的目录或抽象”。这样AI生成的代码会天然收敛在既有架构框架内复杂度更容易被控制。再进一步很多AI编程工具支持创建项目级的定制规则或自定义指令把这些规范固化到工具里团队每个人用AI生成的代码都会遵循同一套骨架。我自己的团队现在已经把“状态机只允许放在state目录”“外部接口调用必须走gateway层”“禁止自定义异常类”这类约定写进了AI提示词模板里效果非常明显。4. 工具链组合实战用Git worktree和CI搭复杂度预警系统4.1 为什么Git worktree在AI编程时代特别有用聊一个比较偏门但实用的工具Git worktree。为什么它在AI编程时代特别有用因为AI生成的代码经常需要快速验证而多分支并行验证可以极大减少上下文切换带来的认知负担。默认情况下你只有一个工作目录切换分支时要么stash要么commit才能让工作区干净。用AI生成代码的人都知道AI往往在一段上下文里连续工作很久你切出去看另一个bug回来以后之前AI对话的上下文可能就丢了工作区的改动也得整理。Git worktree让你可以同时checkout多个分支到不同目录每个目录独立工作互不干扰。比如我在改一个复杂功能时会开一个worktree放AI正在生成的代码另一个worktree保留着稳定版的代码环境方便随时对比行为差异。这样即使AI生成的代码在验证时出现意外也不会污染当前主线环境排查问题和回滚都干净利落。具体操作很简单git worktree add ../project-feature-branch feature-branch这就创建了一个新目录指向feature分支。需要切换不同AI实验时各开一个worktree各自跑测试互不影响。用完一个就删掉这个worktreegit worktree remove ../project-feature-branch很干净。4.2 把复杂度度量接进CI让失控“发票”在合并前爆出来前面说到的复杂度阈值卡口真正落地要靠CI。我们的做法是把ESLint复杂度规则和SonarQube的质量门禁都接到CI流水线里每次push代码时自动跑跑不过就直接拦截merge request。具体配置上ESLint的max-params可以限制函数参数数量complexity规则可以设置圈复杂度上限SonarQube侧可以配置“圈复杂度高于15的函数必须重构”之类的质量规则。这些数值不是拍脑袋定的需要结合项目实际情况调整。我们一开始把圈复杂度上限设成10结果大量AI生成的函数被卡住明显矫枉过正后来调成15同时要求重构的复杂性函数数量逐渐下降效果不错。这里有一个实操技巧复杂度度量只是信号不是最终审判。不能只靠CI拦截说“你这函数太复杂改”要配合注释和评审流程告诉开发者“为什么被拦截”。我们在CI加了产物阶段的报告链接开发者看到拦截原因后可以直接跳转查看哪一行代码导致复杂度上升到阈值。这样流程从“找茬”变成“辅助”体验好很多团队的接受度也高。4.3 多工具组合后的整体开发节奏把这些工具串起来之后AI编程的开发节奏和以前完全不同了。我的日常流程大致是先开一个Git worktree拉出功能分支把项目规范和必要的上下文信息写进提示词让AI在指定骨架内生成代码本地跑通后push到远程触发CI自动执行静态检查和复杂度度量通过后再走代码评审评审人只需要关注业务逻辑和调用链是否符合预期不需要把每个实现细节都读透。这套流程走顺之后复杂度失控的情况明显减少。不是因为AI变乖了而是因为失控代码在进入主分支之前就被拦下来了。工具链不是用来限制开发效率的它是把“复杂度检查”这件事从人肉记忆变成系统保障让AI的产出被规范在可控范围内。5. 实战中踩过的坑以及一些有效的提醒5.1 AI生成的复杂代码不敢删怎么办这是我在团队里遇到最多的一个问题AI生成了一段复杂的模块代码看起来有测试、有注释就是没人敢改也没人敢删。因为删了之后不知道会不会挂掉隐性的依赖。我的处理办法是分两步走。第一步先让AI自己解释这段代码——把模块丢进AI对话里让AI帮你梳理它的职责和依赖关系相当于做一个“代码考古”的初稿记录。第二步找到真正拥有关键知识的人让他在初稿基础上确认哪些依赖是真依赖、哪些是AI臆想出来的假设。确认完以后把“这段代码为什么存在”写在模块顶部注释里。如果确认结果是“这个模块完全没有存在的必要”那就果断删除。删完如果测试挂了刚好说明哪里有隐藏依赖修复它比留着一坨“没人理解的复杂代码”要好得多。5.2 复杂度突发爆表时的紧急预案有时候复杂度不是缓慢上升的而是一次性爆表。比如某次AI生成的代码合并进去后线上出现性能问题你发现是因为新代码的调用链比原来长很多复杂度已经超出可诊断范围。这时候我建议用“回滚优先复盘在后”的策略先把代码回滚到上一个稳定版本恢复线上服务再把复杂代码放到worktree里慢慢分析。不要顶着线上故障去剖析AI代码那会把人逼疯。复盘时有一个核心问题要问清楚这段代码为什么会这么复杂是因为需求本身就复杂还是AI在生成时用了不必要的抽象如果需求本身就复杂那表示设计阶段就没有拆解清楚下一步要重新做架构设计如果是后者说明提示词约束不够需要把这次失败的教训补进提示词模板的“禁止项”里。5.3 小团队如何让复杂度约定真正落地很多小团队觉得复杂度治理是大团队的事自己三五个开发者没必要搞那些流程。我的观点恰恰相反人越少越是经不起复杂度失控带来的返工成本。大团队有专门的人做架构治理小团队没有所以才更需要靠工具和约定兜底。小团队落地复杂度约定注意别一上来就整很大的体系先从三件事做起约定圈复杂度上限、要求AI生成代码必须走代码评审、提示词模板里必须有“禁止项”。这三件事不需要引入任何额外工具用现有的Git和CI就能执行起来。等团队适应了再把Git worktree、SonarQube这些加到流程里。我个人的体会是AI编程这件事本身是中性的复杂的不是工具而是我们怎么使用工具的态度。你把AI当成一个什么都能干的魔法师它就会给你变出一片复杂的魔法森林你把AI当成一个必须在规则里干活的实习生它就能稳定输出你还hold得住的代码。代码复杂度的控制权始终在开发者自己手里不在AI手里。最后再分享一个小技巧每次跟AI对话结束时顺手让它总结“当前工作目录里新增了哪些文件、改动了哪些函数”并把这份清单附到PR描述里。这个小小的动作能让后期排查复杂问题时节省大量时间。
