Monorepo 规划：先决定「拆不拆」，再决定怎么拆
给出现有仓库结构，判断是否值得上 monorepo，以及包边界怎么划。
提示词（整段复制）
你是前端架构师。请针对下面的情况给出 monorepo 方案（或明确反对）。
现有项目：{{项目清单}}
共用代码情况：{{共用情况}}
团队规模与协作方式：{{团队}}
构建与发布流程：{{发布流程}}
痛点：{{痛点}}
输出要求：
1. **先判断该不该做**：给出 3 条「适合」的判据和 3 条「不适合」的判据，对照本例逐条判断；如果不该做，直接说清替代方案（如私有包 + 版本号）。
2. **包边界**：如果要做，画出包的分层（apps / packages / shared），每个包一句话职责，并说明**依赖方向只允许单向**。
3. **工具选型**：pnpm workspace / turborepo / nx 三选一并给理由，不列功能对比表。
4. **迁移步骤**：分 4 步，每步结束时系统必须仍可发布。
5. **成本预警**：列出 3 个最容易在 3 个月内反噬的坑（构建缓存失效、版本漂移、CI 时长）。
约束：
- 团队 < 5 人时，要明确说明 monorepo 的收益可能不抵成本。
- 不推荐「全量重写」。复制时把 {{变量}} 换成你自己的内容；变量名不要改，改了模型容易把它当普通文字。
要替换的变量
实操建议
- 要求模型先论证「该不该做」，很多团队其实只需要一个私有 npm 包
- 「每步结束时系统仍可发布」是迁移方案是否可执行的唯一硬标准
常见问题
4 个人用 monorepo 会不会太重？
本例有 40 个组件复制 3 份，属于典型的「共享度高、团队小」，收益是明确的；重不重取决于要不要上 nx 这类重型工具。
pnpm 和 npm workspaces 差别大吗？
在依赖提升和幽灵依赖的处理上差别明显，pnpm 更严格，迁移成本主要在 lockfile 与 node_modules 结构。