AI时代，我想把所有人拉进同一个代码仓库

最近公司在项目上全面铺开了AI Coding工具。效果是肉眼可见的。BA基于UX画好的原型图用Claude Code直接生成了HTML页面。前端拿到页面后同样用Claude Code生成了Vue代码。后端也在用AI写接口、写测试。每个人的效率都提升了。但有一天我看到了一个场景让我觉得哪里不对。BA把生成好的HTML页面打了个zip包通过即时通讯发给了前端。前端下载、解压、拷贝到自己的代码库里然后开始让AI基于这些HTML生成Vue组件。等等。2026年了我们都在用AI写代码了但协作方式还是发zip包这不是个别现象。你仔细看整个工作流就会发现AI提升的是每个人手里那一段的效率但人与人之间的衔接——那些交接、传递、等待——还是老样子。甚至因为每个人产出变快了这些衔接点反而成了更明显的瓶颈。AI让每个人都变成了高速公路但连接高速公路的还是乡间小道。然后我遇到了第二个问题。项目在落地SDDSpec-Driven Development。简单说就是先让AI根据需求写spec再根据spec生成代码。在单体代码库里这套流程跑得很顺——AI读完spec看看代码库的上下文就能把任务拆分到具体的文件和模块里。但在微服务架构下不同微服务的代码分散在不同的代码库。那么问题来了AI在拆分spec的时候需要同时理解多个服务之间的关系。比如一个用户下单的spec涉及用户服务、订单服务、库存服务、支付服务。AI需要知道这些服务之间的接口契约、数据模型、调用链路。但它只能看到当前仓库的代码。你可能会说搞一个集中的Spec Hub不就行了把所有服务的API契约放在一个地方AI去那里读上下文。这个思路没错业界也确实有类似实践。但我试了之后发现只集中spec而不集中代码AI的上下文仍然是割裂的。它知道接口长什么样但不知道实现细节、不知道数据库schema、不知道那些没写在契约里的隐含约定。如果SDD只能在单体代码库里好用那对微服务架构来说就是个摆设。这两个问题在我脑子里转了好几天。直到某天晚上我突然把它们放在一起看了一眼。zip包的问题本质上是什么是人和人之间的协作介质太原始。BA的产出和前端的输入之间隔着一个文件传输的鸿沟。SDD在微服务下失灵本质上是什么是AI的上下文被仓库边界切断了。它需要看见全屋但你只给它看了一个房间。这两个问题的根源是同一个上下文是碎片化的。然后我想到了一个词monorepo。不是那个Google和Meta用的超大代码仓库的monorepo。我想到的是一个更激进的版本——一个所有角色都在里面工作的统一仓库。UX的设计稿、BA的页面原型、前端代码、后端各个微服务的代码、数据库变更脚本、QA的测试用例、SDD的spec全部放在一个仓库里。这听起来有点疯狂。但你仔细想想在AI Coding的时代这件事的可行性比以前高了太多。想象一下这个场景。UX在monorepo的/design目录下放好了原型图和设计commit然后push。BA打开同一个仓库用Claude Code读取原型图直接在/frontend/pages下生成HTML页面commit然后push。前端拉取最新代码看到BA生成的页面已经在仓库里了直接让AI基于这些HTML生成Vue组件commit然后push。没有zip包没有即时通讯传文件没有你发我一下最新版。Git就是协作协议。Commit就是交接。类似于开发之间的协作扩大到了整个大团队。再看SDD的场景。所有的spec放在monorepo的/specs目录下。当AI需要拆分一个跨服务的需求时它可以同时看到/services/user-service、/services/order-service、/services/payment-service的代码。它不再是盲人摸象而是站在高处俯瞰全局。spec的拆分结果直接写到对应服务的目录里每个开发人员拉取后就能看到自己要做什么。怎么样很完美是不是你可能会问非开发角色用Git这现实吗说实话在以前确实不太现实。让BA学会处理merge conflict、让UX理解rebase这个门槛太高了。但现在不一样了。Claude Code这样的命令行AI工具本质上是一个自然语言到Git操作的翻译层。BA不需要记住git add . git commit -m xxx git push她只需要对AI说把我刚才的改动提交上去。AI处理剩下的事。这意味着AI不仅提升了每个人的编码效率它还降低了非技术角色使用技术工具的门槛。当这个门槛足够低的时候所有角色在同一个仓库里工作就不再是天方夜谭了。而且这不仅仅是解决zip包和SDD的问题。你再往深想一步——以前团队的工作散落在Figma、Jira、各个代码仓库、测试平台、CI/CD系统里。每个平台都是一个信息孤岛平台之间的同步靠人肉。现在当AI agent可以通过命令行完成越来越多的事情——生成设计、拆分需求、写代码、跑测试——这些原本需要不同平台的能力正在被收敛到一个统一的界面里。Monorepo提供了共享的上下文CLI Agent提供了统一的操作界面。两者结合整个团队就从分散协作走向了共享上下文。AI时代我真的很想把所有人拉进同一个代码仓库。当然我不想把这件事说得太美好。Monorepo不是银弹它有自己的代价。最直觉的担忧是所有代码放一起不会乱套吗前端改了后端的代码怎么办某个开发人员不小心动了别人的服务怎么办这个问题Google和Meta早就回答过了。答案是monorepo的秩序不靠自觉靠机制。第一层是目录结构本身。/services/user-service/、/services/order-service/、/frontend/、/specs/——清晰的目录边界就是最直观的围栏。大多数人不会没事跑到别人的目录里改东西。第二层是CODEOWNERS。这是大多数git工具都支持的机制——你可以声明这个目录的变更必须由谁来review。比如/services/payment-service/的CODEOWNERS是支付团队任何人对这个目录的PR都需要支付团队的人批准。这不是建议是强制的。第三层是CI边界检查。你可以在流水线里加规则service A不能直接import service B的内部模块只能通过公开的API契约交互。如果有人违反了CI直接挂掉。第四层也是AI时代特有的——你可以在CLAUDE.md或项目级的配置文件里告诉AI你只能修改/services/order-service/下的文件其他目录只读。AI agent天然尊重这种约束。把这种约束机制搞全也就向着Harness Engineering更近了一步。所以monorepo的隔离不是靠大家小心点而是靠工具链把边界硬编码进去。另一个常见的担忧是仓库太大。当所有代码都在一起clone、build、CI的时间会不会爆炸这个问题也有成熟的解法sparse checkout只拉取你需要的目录、增量构建Nx和Turborepo都擅长这个、以及合理的CI配置只跑受影响的服务的测试。不展开了这些是工程问题不是架构问题。真正值得警惕的是组织层面的挑战。Monorepo意味着更高的透明度——每个人的代码、每个人的commit都暴露在所有人面前。对于一些习惯了各管各的的团队来说这种透明度可能带来不适。但我倾向于认为这种不适恰恰是好事。透明度是协作的前提。当然也只是前提。康威定律告诉我们如果团队之间本来就不共享目标和责任monorepo只会让冲突更早暴露而不会自动消除。但至少暴露比隐藏好。写到这里我想起了希思兄弟在《瞬变》里提出的一个框架。他们说想要改变人的行为有三条路说服理性指挥骑象人、激发情感激励大象、以及塑造路径Shape the Path。其中最被低估的是第三条——与其说服人改变不如改变环境让正确的行为成为阻力最小的路径。回头看我们在项目上遇到的问题。BA发zip包给前端不是因为她不想用更好的方式而是在polyrepo的环境下发zip包就是阻力最小的路径。SDD在微服务下失灵不是因为SDD本身有问题而是分散的代码仓库让AI看不到全局——环境限制了工具的能力。Monorepo做的事情本质上就是在塑造路径。你不需要写一份流程文档要求BA请把产出物commit到仓库而不是发zip包。你不需要开一个会来强调修改API时请通知下游团队。当所有人都在同一个仓库里工作当AI agent天然能看到全局上下文这些正确的协作方式就自动成为了阻力最小的选择。Monorepo不是在要求团队协作它是在让协作成为唯一自然的选择。我不确定这个方向是不是最终答案。也许半年后回头看会觉得想得太简单了。最近文章里老说这句话来叠甲是因为现在确实是瞬息万变啊。但有一件事我越来越确信AI时代的软件工程瓶颈正在从个人产出效率转向团队协作效率。当每个人都能借助AI高速产出的时候决定整体速度的不再是最快的那个人而是人与人之间衔接的摩擦力。Monorepo也许不是唯一的解法。但它指向了一个正确的问题我们是不是该重新审视一下AI时代的协作基础设施应该长什么样至少在我们的项目上那个zip包已经快消失了。