每个老开发团队都有一座“屎山”——代码杂乱、没有注释、不敢动、一动就崩。最近，我们干了一件疯狂的事：让Kimi K3、Qwen3.8-Max和GLM 5.2三款国产大模型同时接管了一座真实“屎山”，看看它们到底能扛到什么程度。
一、这座“屎山”有多“山”？
项目是一个运行了7年的企业内部订单管理系统。PHP + 原生JS + 混乱的SQL拼接，前后端代码混在一起，10万行+。核心模块包括订单处理、库存扣减、供应商结算，每个都涉及多张表的联表查询和复杂状态流转。
没有文档，没有单元测试，变量命名从$a1到$a99遍地都是。上一个维护它的同事两年前离职了——走之前留下一句“能跑就别动”。
二、三款模型的分工与战术
我们做了分工设计：
Kimi K3：负责代码理解与整体架构拆解。K3以2.8万亿参数规模和100万Token上下文见长，适合把整段代码吞进去，输出模块划分和依赖关系图。
Qwen3.8-Max：负责具体模块的重构与代码生成，将混乱的过程式代码转为清晰的结构。
GLM 5.2：负责边界校验、异常处理和测试用例生成，确保重构后的代码不出新bug。
实际执行中，三个模型的工作流是交叉的——K3拆出模块后，Qwen负责重写，GLM负责校验，发现问题再丢回K3重新分析。
三、实战记录：三个模型怎么拆“山”
第一回合：Kimi K3做“逆向工程”
把整个代码库压缩后丢给K3（约8万Token，在其100万上下文范围内）。K3花了约3分钟输出一份模块划分报告——识别出订单状态机、库存扣减逻辑、供应商结算流程三个核心模块，并画出了它们之间的调用关系。还标注了“疑似死代码”片段——那些从未被调用的函数和从未被使用的变量。
单是这份“屎山地图”，一个资深工程师手动梳理至少需要两周。
第二回合：Qwen3.8-Max做“外科手术”
Qwen3.8-Max负责把K3拆出来的订单模块（约2000行混乱代码）重构为清晰的类结构。输入是K3标注的模块边界和功能说明，输出是重构后的代码。
Qwen的重构策略很聪明：先把所有SQL拼接改为参数化查询（安全第一），再把散落在各处的业务逻辑收敛到OrderService类中，最后把前端JS中混写的业务判断剥离出来，统一由后端API返回状态码。重构后的代码从2000行压缩到1400行，可读性提升明显，编译一次通过。
第三回合：GLM 5.2做“质检员”
GLM 5.2负责两件事：边界测试和异常注入。针对Qwen重构后的订单模块，GLM自动生成了47个测试用例，覆盖正常流程、异常输入、并发冲突、库存不足等场景。还主动发起了几轮“攻击”——模拟数据库连接超时、第三方接口返回异常数据，验证重构后的代码能否优雅降级。
测试结果：47个用例通过43个，4个失败案例全部指向同一个问题——重构时对“已取消订单恢复库存”的逻辑理解有偏差。问题定位后交给K3重新分析原始代码，确认是原代码本身就有的bug（只是从未触发过），Qwen按原样“继承”了。
四、结果：能跑，但需要“AI监理”
三款模型协作两轮迭代后，重构后的代码在功能完整性和代码质量两个维度都通过了验收。整个重构周期从预估的3个月压缩到了5天——其中3天是人工审核和修正AI的输出。
但有几个真实感受值得分享：
第一，AI擅长拆解，但不擅长“决策”。 当遇到“这个历史逻辑到底是feature还是bug”时，三个模型都给出过看似合理但互相矛盾的判断。最终还得靠熟悉业务的人拍板。
第二，上下文窗口是硬约束。 虽然K3有100万Token上下文，但面对10万行代码，一次性全量输入仍然会触发注意力稀释。最终采用的是“分块输入+渐进式理解”策略——先让K3读目录结构，再逐模块深入。
第三，三个模型的“性格”差异明显。 K3擅长宏观分析和文档生成，适合当“架构师”；Qwen在具体代码生成上最稳，适合当“程序员”；GLM在测试和边界校验上最细，适合当“QA”。各有所长，互相配合的效果远超单一模型。
三款国产大模型联手，5天拆完一座7年的“屎山”。AI不会取代程序员，但会用“屎山”的程序员，大概率会被会用AI拆“屎山”的程序员取代。
