背景
在后端微服务开发中，一个产品需求经常会同时涉及多个服务。如果每个服务都单独打开一个 Claude Code session，会出现几个问题：
text
1. 需要重复描述同一个需求
2. 每个 session 只理解当前服务，缺少跨服务上下文
3. 字段、DTO、接口契约容易不一致
4. 多个终端来回切换，协作成本高
5. 最后还需要人工重新串联整体方案因此，可以使用一种 monorepo-like workspace 的方式，把多个相关微服务放到同一个工作区中，并在工作区根目录启动 Claude Code，用一个主 session 负责跨服务理解和协同。
解决什么问题
这个方案主要解决：
text
1. 跨服务需求上下文割裂
2. 多个 Claude Code session 重复沟通
3. 微服务之间字段/API/DTO 契约不一致
4. 跨服务改动缺少统一影响分析核心目标是：
让 Claude Code 像理解 monorepo 一样理解多个微服务，但仍然按照 multi-repo 的方式修改、测试和交付。
1. 什么是 monorepo-like workspace
monorepo-like workspace 可以理解为：类 monorepo 工作区或者 monorepo 风格的多仓库工作区它不是真正的 monorepo。
真正的 monorepo 是：
text
一个 Git 仓库
里面包含多个服务 / 模块 / 包
一次 commit 可以同时修改多个模块而我们的微服务通常是 multi-repo：
text
root-workspace/
CLAUDE.md
roadshow-service/
.git/
CLAUDE.md
user-service/
.git/
CLAUDE.md
admin-service/
.git/
CLAUDE.md
order-service/
.git/
CLAUDE.md这里每个服务都有自己的 .git，所以它们仍然是独立仓库。
但是，我们把多个服务放在同一个父目录下，并在父目录启动 Claude Code：
bash
cd root-workspace
claude这样，从 Claude Code 的视角看，它拥有一个类似 monorepo 的工作空间：
text
一个根目录
一个根 CLAUDE.md
下面有多个服务目录
可以跨服务搜索、分析、对比字段、维护接口契约所以这个模式可以叫：
text
monorepo-like workspace也就是：
Git 不是 monorepo，但 AI 使用体验接近 monorepo。
2. Monorepo：上下文就是一切（这一部分剪辑于网络）
Claude需要上下文。
你想啊，如果前端一个repo、后端一个repo、微服务又是一堆repo，Claude每次切换都要重新理解架构。这就像让一个人在三个房间之间跑来跑去找东西------效率低到爆炸。
但Monorepo不一样。
把同一个应用的所有代码放一起，Claude能一眼看到全局。前端调了什么API？后端返回什么数据？数据库Schema长啥样？全都在视野里。
这不是什么新鲜概念（Meta就是Monorepo），但应用到AI编程上，意义完全不同------上下文管理变成了头等大事。
当然，作者也提醒了：Monorepo是指"同一个应用的不同部分"。如果你有5个毫不相关的项目，该分还是得分
3. --add-dir 的使用场景
--add-dir 用于给 Claude Code 添加额外工作目录。
它的作用是：
text
让 Claude Code 可以读取和编辑当前工作目录之外的目录适合"主服务很明确，只是临时参考其他服务"的场景。
例如，主要修改 roadshow-service，只是需要参考 user-service 的用户 DTO：
bash
cd roadshow-service
claude --add-dir ../user-service然后明确限制：
text
当前任务以 roadshow-service 为主。
user-service 只作为参考目录。
除非我明确允许，不要修改 user-service。总结
monorepo-like workspace 是一种适合 AI 编程的后端微服务工作区组织方式。
它的核心不是把 multi-repo 强行变成 monorepo，而是：
text
通过统一工作区，让 Claude Code 获得跨服务理解能力；
通过服务范围限制，避免无边界探索和 token 浪费；
通过 Git 边界规则，保持每个服务独立交付。最终原则：
像 monorepo 一样理解全局，像 multi-repo 一样修改、测试和发布。