10个老仓库合并为Monorepo：AI编程助手实战复盘

在AI Engineer大会上，来自医疗科技公司WiseDocs的工程师分享了一个真实且具争议的工程决策：用六个月时间，把10个存在了六年多的老仓库重构成一个Monorepo（单一代码仓库），并全程借助AI编程助手。这场重构值不值得？AI编程工具在真实的大型重构中到底靠不靠谱？这篇复盘给出了相当务实的答案。

为什么要做这场Monorepo重构

讲者所在的公司主要处理复杂的医疗理赔文件——一些PDF体积超过1万页，甚至比视频文件还大。整个处理流程包含多个机器学习模型，扩展其中任何一部分都非易事。

业务扩张遇到了三个核心瓶颈：第一，交付速度跟不上客户需求；第二，AI流水线过于复杂，难以更新；第三，超过10个仓库的遗留代码库让没人愿意碰代码，开发体验极差。

讲者把技术债类比为金融债务：它会以神秘甚至难以解释的方式复利累积。技术债（Technical Debt）这一隐喻由Ward Cunningham在1992年提出，将软件开发中为了短期速度而采取的权宜之计类比为金融债务。但与金融债务不同的是，技术债的"利率"往往是隐性且非线性的：一个临时的hack可能在初始阶段毫无影响，但随着系统复杂度增长，它会与其他债务相互纠缠，形成指数级的维护成本。Martin Fowler将技术债细分为四个象限：鲁莽/谨慎 × 有意/无意。有意且谨慎的技术债（如明确记录的临时方案）是合理的工程权衡；而无意且鲁莽的债务（如不了解设计模式导致的混乱代码）则是纯粹的负担。WiseDocs六年积累的多仓库遗留代码，显然已经从可控的债务演变为抑制业务增长的系统性风险。

企业通过承担技术债来换取业务ROI（比如上新功能、拿新客户）本无可厚非，但一旦引入的复杂度增速超过ROI增速，整个系统就会失控。他引用了Anthropic关于Spotify和Stripe的案例，指出这些公司在交付速度和重构能力上都取得了巨大进步。

但他也抛出了一个尖锐的观察：过去20年技术产品确实更强了，可在"更快交付"的同时，我们丢失了一些东西——以客户为中心的产品打磨、代码的可维护性和可靠性都在退化。 他展示了两家头部公司低于99.9%甚至99.999%的可用性数据，说明交付变快并不等于质量提升。

Monorepo vs 多仓库：两种架构范式

理解这场重构的意义，需要先理解Monorepo和多仓库（Polyrepo）这两种代码组织范式。Monorepo是指将一个组织的所有项目、服务、库的代码存放在同一个版本控制仓库中的工程实践。Google、Meta、微软等科技巨头长期采用这种模式。与之相对的是多仓库模式，每个服务或模块各自独立一个仓库。Monorepo的优势在于代码共享更容易、跨项目重构可以原子化提交、依赖管理更统一；劣势则包括仓库体积膨胀、CI/CD复杂度上升、权限管理粒度变粗等。近年来Nx、Turborepo、Bazel等构建工具的成熟，大幅降低了Monorepo的管理成本，使得中小型团队也能享受到这种架构的红利。对WiseDocs而言，10个独立仓库带来的跨仓库协调成本已经严重拖慢了团队的迭代速度。

AI模型一年半的能力进化有多快

重构从4月正式动手，前期还做了准备工作。团队花了大约两个月评估AI流水线的编排器（orchestrator），对比了5个开源项目，围绕17项标准逐一打分——当时Google和OpenAI的Deep Research还没发布，缺乏系统性网络检索能力，所有调研只能手工整理进Confluence文档。

讲者坦言：如果放到现在，同样的调研工作能快90%。 用今天的agentic工作流，从Deep Research起步，为每一项评估标准和候选产品创建子代理（subagent），再自动构建POC并评测，效率完全不可同日而语。Agentic工作流是2024年以来AI工程领域最重要的范式转变之一——与传统的单次问答不同，agentic工作流中的AI代理能够自主规划任务、调用工具（如搜索引擎、代码执行器、文件系统）、生成子代理处理子任务，并通过多轮迭代验证结果。这种模式的技术基础包括函数调用（function calling）能力、长上下文窗口、以及ReAct等推理-行动框架。Deep Research本质上就是这样一种agentic搜索系统，它能自动分解研究问题、并行检索多个信息源、交叉验证后生成综合报告。

但讲者也提醒警惕"AI精神错乱"（AI psychosis）——看到一份20页的Deep Research报告就轻信，结果发现报告里描述的产品功能根本不存在，反而拖累项目。这种风险在agentic系统中尤为突出：代理的自信程度往往与其准确度不成正比，它们善于生成流畅且结构完整的报告，却可能在关键细节上"幻觉"出不存在的API接口或功能特性。

最有说服力的是模型能力的对比实验。当初用O3做Temporal相关的重构，来回聊了三个小时，还犯了10个重大错误，全程需要人工介入引导、手动删改代码。这里提到的Temporal是一个开源的分布式工作流编排引擎，脱胎于Uber内部的Cadence项目，核心理念是让开发者用普通代码编写复杂的长时间运行工作流，而无需手动处理状态持久化、重试、补偿等分布式系统的经典难题。在医疗AI流水线这类场景中，一份超大PDF的处理可能涉及多个ML模型的串联调用、异步等待和失败重试，Temporal能将这些步骤编排为可靠的工作流，确保任何节点故障后都能从断点恢复。这也解释了为什么Temporal相关的重构代码对模型来说有一定难度——它涉及对分布式状态机语义的深刻理解。

而重新用现代模型跑同一任务：Sonnet 4.6只需一次额外迭代就解决了问题，Opus基本一次成型（one-shot）。

更关键的是交互方式的变化。O3时代很少调用工具，而现代harness（模型执行框架）会自动派生子代理、生成计划、执行shell命令、进行多轮验证。虽然单次执行成本略高，但人工介入大幅减少。讲者估算：同样的重构任务，现在只需当初五分之一的时间。

建立正确的AI编程能力心智模型

模型变强，深刻改变了软件开发生命周期的思考方式。此前大家还在给模型喂具体代码片段、做小改动；如今只要提供一份结构良好的spec（规格说明），模型通常就能高质量地执行完成。

讲者特别强调了对METR那张著名的"任务时长"曲线的正确解读。METR（Model Evaluation and Threat Research）是一家专注于AI能力评估的研究机构，其发布的"任务时长"基准测试已成为衡量AI编程代理能力的重要参考。该测试收集了大量真实的软件工程任务，按人类完成所需的时间进行分级（从几分钟到数十小时不等），然后让AI代理独立完成这些任务并统计成功率。这种评估方式比传统的代码补全准确率更贴近真实工程场景。

业界常引用50%成功率的版本，宣称模型能完成人类需要18小时以上的任务；但他认为更该关注80%甚至90%、99%成功率下的数据——此时才是最高效的心智模型。关键的区分在于：50%成功率意味着模型"有可能"完成，而99%成功率才意味着工程师可以"信赖"并"委托"给模型。这个差距正是当前AI编程工具从"辅助"迈向"自主"的核心瓶颈。

他的逻辑很实在：如果你在晚上11点启动一个要跑一小时的agent，而它只有50%的成功率，那你很可能白白浪费了这一小时的算力和注意力。你希望的是构建好plan和spec、交给agent后，能相当有把握它会做完。以Mythos Preview为例，成功率在4小时任务节点开始显著下滑，甚至在15分钟以内的短任务中，也有某些类别是模型无法稳定完成的。

结论是：AI进步飞快，但还远没到"启动一个agent就能可靠交付"的程度。 对工程团队和每一位IC（个人贡献者）来说，理解自己在这套体系中如何贡献，至关重要。这也需要一整套框架和原语（primitives）来支撑高质量的agentic开发，避免陷入与模型无休止的"doom loop"——即开发者不断提交修改请求、模型反复生成有缺陷的代码、双方在纠错循环中消耗大量时间却无实质进展的恶性循环。

Monorepo重构的真实生产力收益

核心动作很简单：把10个仓库合并成一个Monorepo，并在其上构建新功能。结果相当亮眼。

此前的仓库存在了六年多，进展缓慢，一方面是技术债累积，另一方面是当时还没有AI编程工具。而重建后的头六个月，仅仅是追平原有功能，代码增长曲线的陡峭程度就已经非常惊人，而且在达到功能对等之后仍未减速——团队持续加入新功能，无论是代码量还是提交频率都远超从前。

更重要的是参与人数的变化：越来越多开发者加入贡献，如今公司几乎每个开发者都在向这个新Monorepo提交代码，即便某些改动不在他们的专长领域——比如需要改schema、API调用或技术栈的其他部分。这一现象印证了Monorepo的一个核心优势：当所有代码都在同一个仓库中，开发者跨越模块边界的心理和技术门槛都会大幅降低，不再需要克隆另一个仓库、搞懂另一套构建配置、提交跨仓库的协调PR。

讲者提到一个容易被忽视的软性收益：开发者主动想在这个更干净的代码库里工作。 大家会主动问"我能不能在这个仓库里干活"，而且这套重构中沉淀下来的模式已经扩散到公司其他仓库。这种"开发者体验"（Developer Experience, DX）的提升虽然难以量化，但对团队士气和人才留存有着深远影响——当代码库结构清晰、工具链顺畅时，工程师能把更多精力放在解决业务问题上，而不是与构建系统和代码腐化搏斗。

现代LLM能一键搞定大型重构吗

讲者做了一个大胆的实验：直接让GPT-5.5（extra high）零样本（zero-shot）重构整个代码库，只给出仓库名称和底层模型、组件信息。

模型在10分22秒内声称"完成目标"，但只写了2000行代码——数据有些可疑。深挖后发现，它只搭建了一堆脚手架，并没有真正实现模型部分，甚至自己在注释里承认"尚未添加Ray Serve部署或bootstrap命令"。Ray Serve是基于Ray分布式计算框架的模型服务组件，由UC Berkeley的RISELab团队开发，允许开发者将机器学习模型以HTTP端点的形式部署为可伸缩的在线服务，支持模型组合、动态批处理和自动扩缩容。在WiseDocs这类需要串联多个ML模型处理超大文件的场景中，Ray Serve提供了统一的部署和资源调度框架。GPT-5.5跳过了这部分实现，恰恰说明AI模型在基础设施集成层——涉及分布式系统配置、环境变量、进程管理等"胶水代码"——仍然力不从心。

这说明：当前模型还无法自我验证并一次性完成这类大型重构，但已经很接近了。 讲者预测，大约六个月后，模型就能像Stripe案例那样稳定地完成相当规模的重构。

这场Monorepo重构到底值不值

面对"是不是该再等一年、等模型和harness更成熟再重构"的质疑，讲者给出了辩证的回答。

反方观点确实成立：模型越来越强、工具调用越来越好、沙箱和监控框架越来越完善，承担技术债、日后再重构的成本正在以指数级下降。

但风险同样存在：在AI原生的开发方式下，如果放任生成，很容易堆出大量低性能、低质量、且没人真正理解的代码——这和过去的遗留代码没有本质区别。一旦出现问题或需要根据客户需求调整，反而更难下手。因此无论是全量还是部分重构，都必须设置合理的护栏（guardrails）。所谓护栏，在AI编程语境下既包括技术层面的措施（如类型检查、自动化测试套件、lint规则、CI门禁），也包括流程层面的约束（如强制人工代码评审、spec评审前置、agent输出的diff审查）。没有这些护栏，AI生成的代码可能通过了表面的功能测试，却埋下了性能隐患、安全漏洞或架构腐化的种子。

讲者的最终答案是值得。团队先用多仓库的模式快速满足了客户需求、达成了业务目标，随后回头重构、显著加速。重构带来的实打实收益包括：流水线耗时缩短、成本下降、能支持更大的文件，过去需要数月的功能现在一周内就能交付。

在问答环节，他还补充了几个务实的细节：

• 多仓库 vs Monorepo：现代模型已经很擅长在多仓库间导航（只要放进同一上层目录），但端到端测试、验证、部署以及在沙箱里跑完整"AI工厂"时，多仓库依然更麻烦、克隆和环境搭建更耗时。
• 需求准确率：重构时17项需求中命中了15项，验证流程也在演进——比如plan模式当时刚进入Claude Code、Cursor还没有，团队后来把它纳入了开发生命周期。这里的plan模式指的是让AI代理在动手写代码之前，先输出一份结构化的执行计划供人类审阅，确认方向正确后再进入实现阶段，从而避免代理在错误方向上大量生成无用代码。
• 代码评审：重构期间全部是人工PR评审，配合本地skill做代码检查。PR是当时为数不多的开发者建立仓库上下文、理解重构细节的好方式。

核心启示是：模型会持续变强，但有时停下来、建好Monorepo、清理技术债、再大步向前，仍然是正确的工程决策。关键在于严肃评估大型重构的业务价值，以及"现在做"与"未来做"之间的权衡。