Polyrepo

机器可校验的规格（如JSON Schema、OpenAPI、Protocol Buffers或数据库DDL）能被自动化工具解析和验证，可嵌入CI流水线，在Polyrepo场景下弥补跨仓缺乏共享视图的短板。

许多组织混合使用Monorepo和Polyrepo，例如按业务域各建一个Monorepo，同时把共享库放在独立仓库中。

在Monorepo中修改共享模块可以同步更新所有使用方；在Polyrepo中需要先修改共享模块、发布新版本，再逐个更新调用方。

工具质量与仓库结构选择同等重要，工具支持到位的Polyrepo可以胜过缺乏维护的Monorepo。

Polyrepo的典型失败模式是修复只到达部分项目、团队间习惯逐渐漂移；预警信号包括同一个修复在多个地方重复、团队互相等待发布。

为每个模块（包括共享模块）明确归属，能预防Monorepo和Polyrepo两种模式下的大部分问题。

原文给出的经验法则是观察一次变更需要跨越仓库边界的频率：如果两个项目经常一起改动，放在同一空间能减少协调成本；如果很少联动或因权限、归属原因必须分离，独立仓库更合适。

Polyrepo为每个项目或团队保留独立的仓库，拥有各自的提交历史和访问规则。

对字段进行一次性全量改名都有风险，更安全的路径是先加新字段、逐个迁移使用方、再删除旧字段，这个顺序比仓库布局更重要。

AI编程助手一次能容纳的文本量受上下文窗口限制，大型代码库永远无法完整装入；Monorepo并非全部可见，Polyrepo也并非完全隐藏，真正的问题是助手能否找到正确的文件。

在Polyrepo中，AI助手如果只能看到一个仓库，它无法判断还有谁在使用共享字段，可能在完成第一步修改后就停下，导致某个项目被遗漏或停留在旧版本。