AI 应用为啥适合 monorepo
要点
- 不是因为 AI 这个词有什么魔法，而是这类项目发展起来以后，各层内容会越来越紧地黏在一起
- 普通项目也有共享代码，但 AI 应用有一类东西特别容易联动：上下游约定
- AI 应用里最容易被低估的一点：共享层不会只停在 types
- 一个典型 AI 应用按现在常见的形态摆出来
- 多仓库表面上边界清楚、权限好分
内容
1. AI 应用比普通项目更早碰到 monorepo
不是因为 AI 这个词有什么魔法，而是这类项目发展起来以后，各层内容会越来越紧地黏在一起。
一个很典型的过程：最开始只有一个 Web 页面，后来加 API，再加异步 worker，然后共享 schema、共享提示词、共享组件、共享实验脚本。继续往前走，还会冒出文档站、后台管理、playground、评测脚本和模型调用层。
这些东西不只是数量多，而是关系紧——改一个地方，往往不只影响一个 app。
2. 最容易一起变的，是上下游约定
普通项目也有共享代码，但 AI 应用有一类东西特别容易联动：上下游约定。
典型场景：前端发起一次 AI 任务，API 接住写入数据库，worker 消费执行，结果回到前端展示。这条链路上，以下内容一改全改：
- 请求参数
- 响应结构
- 任务状态枚举
- 工具调用结果格式
- 评测输出格式
这些定义分散在多个仓库时，每次改动都要反复同步确认。感受不是"结构更清晰"，而是每次都在跨仓库追改。
3. 共享的不只是类型
AI 应用里最容易被低估的一点：共享层不会只停在 types。
写到后面你会发现，跨应用复用的东西越来越多：
- 提示词模板
- 工具定义（function calling）
- schema 校验
- 默认配置
- 模型调用封装
- 评测脚本
- 公共 UI
也就是说，你不是只需要一个 shared-types 包，而是会长出一整层共享能力。
Canvas actions64%Exit zen mode
Drawing canvas 走到这里，多仓库暴露的问题就不是"仓库太多"，而是共享层越来越碎，改动越来越散。
4. 放回一个典型项目里看
一个典型 AI 应用按现在常见的形态摆出来：
apps 独立对外运行的应用
web 用户前端
admin 管理后台
api 接口层
worker 异步任务和编排执行
docs 文档和示例站点
packages 共享能力层
ui 共享组件
shared 共享类型和工具函数
prompts 提示词模板和默认文案
schemas 输入输出 schema
ai-core 模型调用、工具和运行时封装
config
统一配置
apps/web 和 apps/admin 共用 UI，apps/api 和 apps/worker 共用 schema，提示词模板和模型调用封装也不只属于一个应用。这些内容本来就在一起工作，硬拆开维护代价很高。
5. 继续拆成多仓库，最累的是同步
多仓库表面上边界清楚、权限好分。但 AI 应用一旦开始长，真正变累的是同步：
- API 字段改了，前端和 worker 都要跟
- 提示词模板改了，评测脚本也要更新
- 共享 schema 改了，后台和主站都要发版
- 一次模型调用策略调整，影响接口层、任务层和日志层
这些改动本来是一件事。拆成多仓库以后，变成多次提交、多次发版、多次联调。
6. 但不是所有 AI 项目都该一开始就上 monorepo
如果你现在只有一个前端和一个很轻的 API，几乎没有共享层，那继续保持简单反而更好。
monorepo 开始有价值，是在这些信号出现以后：
- 共享包变多了
- 多个应用要一起演进
- 一次改动经常跨多个项目
- 本地联调越来越频繁
适合 monorepo 的不是"项目听起来很大"，而是关系已经开始变紧。
7. 总结
AI 应用之所以更容易走到 monorepo，是因为它很容易同时长出多个强相关的部分——前端、后端、worker、共享 schema、提示词、UI、评测脚本。这些东西一旦同时演进，仓库结构迟早会变成一个工程问题。
一句话：AI 应用不是天然必须 monorepo，但它比普通项目更早走到这一步。
下一篇开始动手，搭一个最小 monorepo。