把文档和代码塞进同一个仓库,AI就能变聪明?我试了试,发现事情没那么简单

大家好，我是码哥！

上篇Monorepo：一个古老思想的“文艺复兴”聊完Monorepo的前世今生，码哥其实留了个尾巴——在AI编程的语境下，这东西突然变得有点不一样了。

码哥当时正在做一个调研，想把产品文档、技术方案、前后端代码统统塞进一个仓库里。直觉告诉码哥，这样AI就能一次性看懂全部上下文，不用码哥翻来覆去地解释“这个需求对应哪个接口”、“那个类型定义在哪个包里”。但冷静下来之后，脑子里冒出了好几个问号。这些问题不搞清楚，码哥不敢往下走。

第一个问题：Git到底该放哪儿？

码哥最朴素的想法是：把几个独立的Git仓库，放在同一个文件夹里，开发时一起打开，不就行了吗？这样每个子目录还保留着自己的.git，互不干扰。

试了一下，很快发现问题。AI确实能看到所有文件，但当它想同时修改前端代码和产品文档时，它面对的是两个独立的Git仓库。它没法在一个提交里把两边的改动一起搞定。提交前端的改动，文档那边还是旧的；提交文档的改动，代码又没跟上。AI自己都乱了，一会儿问我“要不要我帮你分别提交”，一会儿又说“抱歉，我无法同时操作两个仓库”。

真正的Monorepo不是这么玩的。它只放一个.git 在根目录，所有子目录（前端、后端、文档）都是这个大仓库的一部分。AI改前端、改文档、改类型定义，全都在同一个版本快照里。一次提交，全部搞定。这对人类来说只是少几次操作，但对AI来说，这是它能否自主完成一个完整任务的前提条件。AI不怕复杂，怕的是“拆开”。

第二个问题：这和“前后端不分离”有什么区别？

把前后端代码放在一起，甚至把文档也放进去——这听起来像是倒退回了PHP + MySQL混写的年代。那时候改个按钮样式都得动后端模板，上线一个功能恨不得重启整个服务。

区别在于：传统不分离是运行时耦合，而Monorepo只是开发时聚合。

运行时耦合的意思是，前端和后端在同一个进程里，你中有我，我中有你，想拆都拆不掉。而Monorepo里的前端代码依然编译成静态文件部署到CDN，后端代码跑在云函数或者容器里，文档生成静态站点。上线之后，它们谁都不认识谁。只是在开发的时候，它们安静地躺在同一个仓库里，让AI能一眼看全。

这个区别很关键。传统不分离是为了让人少写几个接口，少配几次跨域，牺牲的是长期的可维护性。而我们现在把东西放一起，不是为了让人方便，是为了让AI方便。AI需要在一个“房间”里同时看到产品文档、技术方案和代码实现，才能做出一致性的修改。这个“房间”只在开发时存在，上线后就拆掉了。

第三个问题：Token消耗会不会剧增？

这是我最担心的问题，也是最现实的问题。一个中型项目的代码库加上文档，少说几十万个Token。如果每次对话AI都要把整个仓库读一遍，一次就能花掉几块钱，一天下来不敢想。

但实际跑起来发现，根本不会这么干。AI不是傻子，工具也不是这么设计的。

我在根目录放了一个很小的文件，就叫 AGENTS.md，内容只有几百个Token。它不写具体代码，只写一张地图：

• • 产品需求在 /docs/product/ 下，按模块拆分
• • 技术方案在 /docs/tech/ 下，每个方案一个文件
• • 前端代码在 /apps/frontend/
• • 要改订单状态机，先读 /docs/tech/order-state-machine.md

AI在第一轮对话时只读这个地图。然后根据我的问题（比如“帮我改一下支付流程的回调逻辑”），它会自己去查地图，找到对应的产品文档、技术方案、相关代码文件，只读那几个。

这叫按需加载。我观察了一次典型任务的Token消耗：

• • 地图文件：~500
• • 用户问题：~200
• • 两个产品文档片段：~3000
• • 一个技术方案：~5000
• • 三个关键代码文件：~15000
• • 对话历史：~5000

加起来两三万Token。对于Cursor或Codex来说，这是正常水平。如果我不做任何优化，让AI自己漫无目的地扫仓库，那确实可能冲到几十万。但问题在于：你会让一个刚入职的实习生把整个公司的文档全部读一遍才开始干活吗？不会。你会给他一张地图，告诉他“先看这个，再找那个”。对AI也是一样。

还有个技巧：把文档拆碎。不要写一个几百KB的PRD大包，而是按模块拆成十几个小文件。AI读目录索引，只拉取相关的两三个。这不仅是省Token，更重要的是让AI不会在一个长文档里迷失重点。

走了这一趟之后，我的看法变了

一开始我只是觉得Monorepo是个“可以试试”的方案。把文档和代码放一起，听起来挺酷的。但经过了这几个问号的折腾，我发现它不是一个锦上添花的东西，而是AI编程能否真正落地的基础条件。

AI需要一个完整的、可导航的、边界清晰的知识库。文档告诉它“要做什么”，技术方案告诉它“怎么做”，代码告诉它“已经做成了什么样”。这三样东西如果散落在不同的Git仓库、不同的文件系统、不同的工具里，AI的连接成本太高了，高到还不如人自己做。

Monorepo提供了一个容器。它不解决AI的智能问题，但它解决了AI的上下文问题。一个能同时看到产品文档、技术方案和代码的AI，和一个只能看到当前文件的AI，是两种完全不同的物种。

当然，这不意味着你要把所有东西无脑塞进去。你需要一张地图（AGENTS.md），需要把文档拆碎，需要接受按需加载而不是全量投喂。但这些工作量是一次性的，而收益是每一次对话都会享受到。

下一篇文章，我打算聊聊实际操作——我是怎么搭这个仓库的，用了哪个工具，以及AI在实际跑起来之后，遇到了哪些新的麻烦。

如果你也在走这条路，欢迎一起讨论。