"vibe coding 能不能做复杂项目"——这个问题没法抽象地说，因为"复杂"两个字没有刻度。10 张表的 CRUD 有人说复杂，100 万行的单体也有人说复杂。
所以这篇给"复杂"一个具体的刻度：我这个底座项目要对标和承载的，是一套正在工厂里运行的生产管理系统，三个仓库合计约 47 万行代码。它不是随便挑的参照物——它正是这场重构的对象本身：一个大到已经改不动的老系统，和一次"一个人 + AI"的整体重写。
一、标尺的刻度：47 万行是什么概念
先说清楚这套系统有多大。数字是我从代码库里直接统计的（find + wc，口径是源码文件，不含依赖和构建产物）：
后端（Java，单体多模块）
- 1,665 个 Java 文件，约 11.4 万行
- 299 个 Controller、约 350 个 Service、310 个 MyBatis Mapper XML
- 业务层 16 个模块：调度指令、交接班、罐区、工艺、计划、吞吐量、试剂、班组评分、数据对比、绩效奖金、人员管理、基础设置、工厂模型、数据采集、指标……外加框架层（权限、流程引擎、日志、低代码）
- 多数据源（MySQL/Oracle/SQLServer），时序数据走 InfluxDB，配了完整的保留策略和连续查询（1 分钟/30 分钟/1 小时/1 天多档聚合）
- 近 14 个月持续开发，434 次提交，上个月还在加新模块
管理端前端（Vue 2）
- 1,626 个 .vue 文件，约 33.5 万行（vue + js）
- 页面数最多的几个模块：调度 242 页、基础设置 179 页、计划 158 页、工艺 106 页、罐区 93 页
监控组态端（Vue 3 + Vite，独立仓库）
- 约 2.1 万行，一套自研的图形组态设计器（泵、阀门、电气符号等图元库）+ 实时监控大屏 + 历史趋势 + 仪表/环境监测平台，实时数据走 WebSocket
而且它不是代码坟场：这套系统在真实工厂里支撑日常生产——调度指令在线下达，交接班在线签认，生产数据按分钟级采集进时序库，奖金分配从 Excel 手工算搬到线上。每一行都背着真实业务。
二、老系统的硬伤：不是不好，是改不动了
既然在跑、还在持续加功能，为什么要重写？因为它有一个这类系统的典型硬伤：系统过于庞大，底层的一些设计已经不合理，而任何底层改动都牵动全身——改不动了。
具体说三层：
- 技术栈过期。后端 Java 8 + Spring Boot 2.3，前端 Vue 2，都已停止维护。升级不是改个版本号：依赖链、构建链、写法范式全变，相当于换地基。
- 底层设计不合理，但沉没在几十万行代码下面。早期框架层的一些取舍——组织模型、权限模型、主键策略、框架层和业务层的边界——在业务演进到今天之后已经成了束缚。每个都改得起设计，改不起牵连：动一处，几百个 Controller、上千个页面跟着颤。
- 局部修补的账已经算不平了。新需求还在源源不断地来（上个月刚上线一个完整的绩效奖金模块），每加一个功能，都是在不合理的地基上多压一层。继续修，是在给未来的重构持续加价。
这就是大多数企业系统的宿命：不是被写错的，是被写老的。到了这个节点，问题不再是"要不要重构"，而是"谁敢接这个量级的重构"。
三、vibe coding 改变的，是重构这件事的经济学
按传统算法，这个量级的整体重构需要一个不小的团队、以年计的周期，还要叠加一条铁律：沟通成本随人数平方增长，而重构恰恰是最怕信息失真的工作——几十个模块的业务逻辑、几百个隐含的交互约定，经过三四层转述，到新代码里还剩多少是对的，没人敢打包票。所以很多 47 万行的系统不是不想重构，是组织不起一场不失真的重构。
这场实验赌的是 AI 把这个不等式改写了：
- 用更少的人。执行层（编码、测试、文档）全部交给 AI，人只保留决策和验收。人数压到极限，沟通成本这条平方律直接失效。
- 整理更复杂的需求。47 万行老代码本身就是最完整、最不会说谎的需求文档——AI 可以系统地读它，把散落在几百个页面里的业务规则整理成结构化的设计，这比任何访谈和 PRD 都可靠。
- 抽象出更合理的高层逻辑。重写不是照抄：老系统里重复了十几遍的模式、被历史包袱扭曲的模型，正好借重写重新抽象。新底座的框架层（多租户、行级数据权限、统一 ID 策略）就是这么来的——设计水准由决策者把关，AI 负责把抽象贯彻到每一行，不打折扣。
- 统筹更大规模的落地。设计和验收靠人，但"把设计一致地铺到 14 个模块、几百个端点"这种规模化的执行，正是 AI 的主场。上一篇那两个案例已经演示了这个分工怎么运转。
换句话说：47 万行不是这场实验的及格线，而是它要战胜的对手——不是用 AI 复制一个老系统，而是用 AI 完成一次过去组织不起来的重构。
四、为什么这个结论没法注水
有在跑的前身，还是这场实验最严苛的地方：验收标准被提前锁死了。
- 复杂度不能缩水。16 个业务模块、几百个页面、时序采集、公式引擎，一个都绕不开——绕过任何一个，"接住了"就不成立。
- 验收是对数，不是演示。Demo 可以挑顺路的场景演，对数不行：老系统生产出来的结果就是标准答案，新系统算出的指标、排出的班、分下去的奖金，对不上就是错，没有解释空间。
- 终点线画死了。能不能做复杂项目，不看开了多少个好头，看最后能不能完整走到这条线——而且是以更合理的架构走到。
这也是我对"AI 能不能做复杂项目"这类争论的态度：别在定义上打转，把"复杂"换算成模块数、页面数、代码行、要对上的数据，然后跑给他看。
五、接下来的方向
目前底座重构的收尾就在眼前，再往后大方向是把老系统的业务一块块搬上来，先从公用基础、指标管理这类相对独立的模块入手。具体先搬哪块、怎么搬，做到哪算哪，但每搬一块，都会拉老系统出来对数，对得上对不上，尽量会写进这个系列。
最后留个问题：你手里有没有一个"改不动"的老系统？如果有，你会选择继续修，还是赌一次重写？评论区聊聊。
说明：文中项目为企业内部系统，代码与文档暂不公开；所有引用均已脱敏。
本文部分内容包含 AI 辅助创作。
