AI辅助单体仓库规划：Claude Code在工程架构重构中的实战指南

如果你正在管理一个包含多个模块、服务或应用的中大型项目，是否经常面临这样的困境：代码分散在不同仓库，依赖管理混乱，跨模块修改需要频繁切换上下文，CI/CD 配置重复且难以维护？当团队规模扩大，这种“多仓库”模式带来的协作成本和工程效率问题会愈发凸显。

最近，一个名为Claude Code的 AI 编程助手工具，因其在单体仓库架构规划与重构方面的出色能力，在开发者社区引发了广泛讨论。它并非一个全新的构建工具，而是一个能深度理解代码上下文、辅助进行复杂工程决策的智能体。本文的核心判断是：Claude Code 在单体仓库规划这类高复杂度、强上下文依赖的任务上，展现出了超越传统代码补全工具的“工程洞察力”，它能成为架构师和 Tech Lead 进行系统设计与重构的“副驾驶”，而不仅仅是写代码的“助手”。

对于面临工程化挑战的团队，本文将带你深入探讨：如何利用 Claude Code 这样的 AI 工具，系统性地规划、评估和落地一个单体仓库。我们将从概念辨析、环境搭建、实战规划流程、代码示例到最佳实践，提供一个完整的、可落地的操作指南。读完本文，你将能清晰地判断单体仓库是否适合你的项目，并掌握一套借助 AI 进行高效架构规划的具体方法。

1. 这篇文章真正要解决的问题：工程效率的“熵减”之战

在深入技术细节之前，我们必须先回答一个根本问题：为什么我们要关注单体仓库，以及为什么 Claude Code 在这件事上值得一试？

传统多仓库模式的典型痛点：

1. 依赖地狱：基础库版本升级需要同步修改所有依赖它的仓库，沟通和协调成本极高，容易导致版本碎片化。
2. 重构恐惧：一个公共 API 的改动，需要跨多个仓库搜索、修改、提交、测试，极易遗漏，风险巨大。
3. 工具链重复：每个仓库都需要一套独立的构建、测试、打包、部署配置，维护成本成倍增加。
4. 全局视角缺失：新人难以快速理解项目全貌，代码复用率低，容易重复造轮子。
5. CI/CD 流水线复杂：需要管理大量仓库的触发规则和依赖构建顺序，复杂度飙升。

单体仓库的核心价值主张：将所有相关项目的代码放在一个版本库中统一管理，通过目录结构、构建工具和依赖管理策略来组织代码。它追求的是降低协作成本、统一工具链、简化依赖管理和提升代码复用。

然而，从多仓库迁移到单体仓库，或者为一个新项目规划一个健康的单体仓库结构，本身就是一个高风险的架构决策过程。它涉及：

• 边界划分：如何划分子项目、包、模块的边界？
• 依赖管理：是使用工作区、符号链接还是单体构建？
• 构建优化：如何确保只构建和测试受影响的部分，避免全量构建？
• 权限与部署：如何控制不同团队的代码权限？如何实现独立部署？

Claude Code 的切入点：传统的 IDE 插件或代码助手，擅长在单个文件或模块内提供补全和建议。但 Claude Code 被设计为能理解整个 Workspace（工作区）的上下文。这意味着，当你向它提出“为我们的微服务项目规划一个单体仓库结构”时，它可以分析你现有的代码布局，理解模块间的调用关系，并基于最佳实践，给出包含目录结构、构建配置、依赖关系甚至迁移路径的具体建议。它解决的不是“写一行代码”的问题，而是“如何组织千万行代码”的工程问题。

2. 基础概念与核心原理：单体仓库与 AI 工程洞察

2.1 什么是单体仓库？

单体仓库是一种将多个项目或包的代码存储在一个单一版本控制仓库中的软件开发策略。它与“多仓库”相对。

关键特征：

• 单一源码库：所有代码共享同一个根目录和版本历史。
• 标准化工具链：统一的构建系统、代码规范、测试框架和 CI/CD 配置。
• 原子提交：一次提交可以跨多个项目或模块，便于保持一致性。
• 模块化设计：内部通过清晰的目录结构划分独立的、可复用的模块或包。

常见技术栈支持：

• JavaScript/TypeScript:pnpm/npm/yarnWorkspaces, Turborepo, Nx
• Rust: Cargo Workspace
• Java: Maven Multi-module, Gradle Composite Builds
• Go: Go Modules (通过目录组织)
• Bazel: 语言无关的构建系统，天生支持单体仓库

2.2 Claude Code 是什么？它如何“理解”工程？

Claude Code 是 Anthropic 公司推出的 AI 编程助手，它以插件形式深度集成在 VS Code 等 IDE 中。与普通补全工具的核心区别在于其Workspace 级别的上下文感知能力。

工作原理简述：

1. 索引整个工作区：当你打开一个项目文件夹，Claude Code 会尝试分析其结构，读取关键配置文件（如package.json,Cargo.toml,pom.xml,build.gradle），建立对项目模块、依赖和技术的初步认知。
2. 理解用户意图：当你提出“规划单体仓库”这类高层级问题时，它会将问题与已索引的工程上下文结合。
3. 生成结构化建议：基于训练数据中的海量开源项目模式和最佳实践，它能够生成不仅仅是代码片段，而是包含文档说明、目录树、配置差异的综合性方案。
4. 迭代与澄清：你可以针对它的建议提出追问，它会基于之前的对话历史进行调整，模拟一个资深架构师的评审过程。

它的优势领域：

• 架构设计：提供初始的项目结构模板。
• 代码重构：建议如何安全地拆分或合并模块。
• 依赖分析：识别循环依赖、版本冲突。
• 工具链选型：对比不同构建工具在单体仓库场景下的优劣。

3. 环境准备与前置条件

要跟随本文进行实战，你需要准备好以下环境。请注意，Claude Code 的可用性可能因地区和服务条款而异，请以其官方信息为准。

3.1 基础开发环境

• 操作系统：Windows 10/11, macOS 10.15+, 或主流 Linux 发行版（如 Ubuntu 20.04+）。
• Node.js：建议安装 LTS 版本（如 v18.x, v20.x），这是运行许多现代前端构建工具和包管理器的基础。
• 包管理器：根据你的技术栈选择其一安装：
  • npm(随 Node.js 安装)
  • yarn(npm install -g yarn)
  • pnpm(npm install -g pnpm，对单体仓库支持更友好)
• 版本控制：Git，并配置好全局用户信息。
• IDE：Visual Studio Code (VS Code)，这是 Claude Code 插件的主要运行平台。

3.2 Claude Code 的安装与配置

由于网络和服务可用性问题，安装过程可能是最大的挑战。以下是基于公开信息的通用步骤和问题排查思路。

步骤一：在 VS Code 中安装 Claude Code 插件

1. 打开 VS Code。
2. 进入扩展市场 (Ctrl+Shift+X 或 Cmd+Shift+X)。
3. 搜索 “Claude Code” 或 “Claude”。
4. 找到由 Anthropic 官方发布的插件，点击“安装”。

步骤二：认证与启用

1. 安装后，VS Code 侧边栏会出现 Claude 的图标。
2. 点击图标，通常会引导你进行登录或注册。
3. 重要：你需要一个可用的 Claude 账户（可能涉及地区限制）。请自行查阅 Anthropic 官方的最新注册指南。
4. 完成认证后，插件即可使用。

常见安装问题与排查：

关键提醒：AI 辅助工具是“增强”而非“替代”。即使暂时无法使用 Claude Code，本文后续的规划方法论、技术选型和实践步骤依然具有独立的参考价值。你可以用其他具备一定上下文理解能力的工具（如 Cursor、GitHub Copilot Chat）进行类似尝试，或纯粹依靠本文的指南进行手动规划。

4. 核心流程拆解：用 Claude Code 规划单体仓库的六步法

假设我们有一个名为“电商平台”的虚构项目，目前包含：用户服务、商品服务、订单服务三个独立的 Spring Boot 后端仓库，以及一个 React 管理后台前端仓库。我们的目标是将它们整合到一个单体仓库中。

4.1 第一步：现状分析与目标定义

目标：让 Claude Code 理解我们当前的混乱状态和未来期望。操作：在 VS Code 中打开一个临时目录，创建一个context.md文件，描述现状。提示词示例：

我现在有四个独立的Git仓库： 1. `user-service`: Spring Boot 项目，提供用户注册、登录、管理功能。 2. `product-service`: Spring Boot 项目，提供商品CRUD、分类、搜索功能。 3. `order-service`: Spring Boot 项目，处理下单、支付、库存扣减。 4. `admin-frontend`: React + TypeScript + Vite 项目，是内部管理后台。 它们之间存在依赖：`order-service` 需要调用 `user-service` 和 `product-service` 的Feign客户端。前端通过API网关调用所有后端服务。 目前的问题：公共DTO定义重复，Feign客户端接口维护困难，版本升级不同步，CI/CD配置四套。 我的目标：将它们迁移到一个单体仓库中，使用合适的工具管理。希望达到：代码共享方便、构建测试高效、能够独立部署每个服务。请帮我规划一个合理的单体仓库结构，并说明理由。

将这段描述提供给 Claude Code，让它先消化背景。

4.2 第二步：技术栈与工具选型建议

目标：确定实现单体仓库的底层技术栈。操作：基于上一步的上下文，向 Claude Code 提问。提示词示例：

基于上述电商平台项目，后端是Java Spring Boot，前端是React。请为这个单体仓库推荐具体的构建/依赖管理工具链，并对比不同方案的优缺点。我需要考虑：Java多模块管理、前端项目管理、统一的代码风格和提交检查、高效的增量构建。

Claude Code 可能给出的建议摘要：

• 后端（Java）：推荐使用Gradle作为构建工具，因其对多项目构建的支持比 Maven 更灵活、脚本能力更强。使用Gradle Composite Builds或标准的多项目构建。
• 前端（TypeScript）：推荐使用pnpm Workspaces或Turborepo。pnpm 磁盘效率高，Workspaces 能很好地处理本地包链接；Turborepo 则提供强大的增量构建和任务编排缓存。
• 混合管理：可以考虑使用Nx作为更上层的构建系统，它提供强大的代码生成、依赖图可视化、受影响项目测试等功能，对全栈单体仓库支持很好。
• 统一工具：推荐Husky+lint-staged管理 Git hooks，Prettier+ESLint（前端）/Checkstyle+SpotBugs（后端）统一代码风格。

4.3 第三步：生成顶层目录结构

目标：获得一个具体的、可执行的仓库根目录布局。操作：要求 Claude Code 输出详细的目录树。提示词示例：

非常好。请根据你的推荐（假设我们选择 Gradle + pnpm Workspaces 的组合），为这个电商平台单体仓库生成一个完整的、具体的目录结构树。请包含所有必要的配置文件（如 .gitignore, README.md, 根构建脚本等），并简要说明每个目录或文件的用途。

Claude Code 可能生成的目录结构示例：

ecommerce-monorepo/ # 仓库根目录 ├── .gitignore # Git忽略规则 ├── README.md # 项目总览文档 ├── LICENSE ├── package.json # 根 package.json，用于 pnpm workspaces 和根脚本 ├── pnpm-workspace.yaml # 定义 pnpm 工作区 ├── build.gradle.kts # 根 Gradle 构建脚本（Kotlin DSL） ├── settings.gradle.kts # Gradle 项目设置，包含子模块 ├── gradle/ │ └── wrapper/ # Gradle Wrapper ├── libs/ # 共享库目录 │ ├── common-utils/ # 通用工具类（Java） │ │ ├── build.gradle.kts │ │ └── src/ │ ├── api-client/ # Feign 客户端接口和DTO定义（Java） │ │ ├── build.gradle.kts │ │ └── src/ │ └── ui-components/ # 共享的React组件库（TypeScript） │ ├── package.json │ ├── vite.config.ts │ └── src/ ├── services/ # 后端微服务目录 │ ├── user-service/ │ │ ├── build.gradle.kts │ │ ├── src/ │ │ └── Dockerfile │ ├── product-service/ │ │ ├── build.gradle.kts │ │ ├── src/ │ │ └── Dockerfile │ └── order-service/ │ ├── build.gradle.kts │ ├── src/ │ └── Dockerfile ├── apps/ # 前端应用目录 │ └── admin-frontend/ │ ├── package.json │ ├── vite.config.ts │ ├── index.html │ └── src/ ├── config/ # 统一配置文件 │ ├── checkstyle/ # Java代码检查规则 │ ├── spotbugs/ # Java Bug检测规则 │ └── eslint/ # JavaScript/TS代码检查规则 ├── scripts/ # 项目级脚本 │ ├── bootstrap.sh # 环境初始化脚本 │ └── ci/ # CI相关脚本 └── docs/ # 项目文档 ├── adr/ # 架构决策记录 └── dev-setup.md # 开发环境设置指南

4.4 第四步：深入关键配置文件

目标：获得核心配置文件的详细内容，避免手动编写的低级错误。操作：针对关键文件，要求 Claude Code 生成具体内容。提示词示例：

请为根目录的 `pnpm-workspace.yaml` 和 `settings.gradle.kts` 生成具体内容。同时，为 `libs/api-client` 和 `services/order-service` 生成它们的 `build.gradle.kts` 文件，要体现出它们对 `libs/api-client` 和 `libs/common-utils` 的依赖关系。

Claude Code 生成的配置示例：

1. 根目录pnpm-workspace.yaml

packages: - 'apps/*' - 'libs/ui-components'

说明：此文件告诉 pnpm，在apps/目录下的所有文件夹和libs/ui-components都是独立的工作区包。

2. 根目录settings.gradle.kts

rootProject.name = "ecommerce-monorepo" // 包含所有子项目 include( ":libs:common-utils", ":libs:api-client", ":services:user-service", ":services:product-service", ":services:order-service" ) // 如果需要为子项目自定义项目目录，可以使用 project(...).projectDir

说明：此文件定义了 Gradle 构建中包含哪些子模块。

3.libs/api-client/build.gradle.kts

plugins { `java-library` `maven-publish` } group = "com.ecommerce" version = "1.0.0-SNAPSHOT" dependencies { // 内部依赖：依赖于另一个共享库 api(project(":libs:common-utils")) // 外部依赖 implementation("org.springframework.boot:spring-boot-starter-web") implementation("org.springframework.cloud:spring-cloud-starter-openfeign") implementation("com.fasterxml.jackson.core:jackson-databind") // 编译期注解处理器等 annotationProcessor("org.projectlombok:lombok") compileOnly("org.projectlombok:lombok") } java { withSourcesJar() withJavadocJar() } publishing { publications { create<MavenPublication>("mavenJava") { from(components["java"]) } } // 可以配置发布到内部仓库 }

说明：这是一个java-library，被其他服务依赖。它本身依赖common-utils。

4.services/order-service/build.gradle.kts

plugins { id("org.springframework.boot") id("io.spring.dependency-management") } group = "com.ecommerce" version = "0.0.1-SNAPSHOT" dependencies { // 内部依赖：Feign客户端和通用工具 implementation(project(":libs:api-client")) implementation(project(":libs:common-utils")) // Spring Boot 启动器 implementation("org.springframework.boot:spring-boot-starter-web") implementation("org.springframework.boot:spring-boot-starter-data-jpa") implementation("org.springframework.cloud:spring-cloud-starter-openfeign") // 数据库驱动 runtimeOnly("com.mysql:mysql-connector-j") // 测试依赖 testImplementation("org.springframework.boot:spring-boot-starter-test") } tasks.getByName<org.springframework.boot.gradle.tasks.bundling.BootJar>("bootJar") { archiveFileName.set("order-service.jar") }

说明：订单服务依赖两个内部库api-client和common-utils。Gradle 会自动处理这些项目依赖，无需发布到仓库。

4.5 第五步：规划迁移策略与任务清单

目标：获得一个从当前多仓库状态迁移到目标单体仓库的可操作步骤。操作：要求 Claude Code 制定迁移计划。提示词示例：

现在我们有目标结构了。请为我制定一个从四个独立仓库迁移到这个单体仓库的详细步骤清单。需要考虑：历史提交记录的保留、渐进式迁移的可能性、团队协作的过渡期、以及如何验证每一步的正确性。

Claude Code 可能给出的迁移步骤摘要：

1. 准备阶段：在单体仓库中建立初始结构（使用上述生成的模板），配置好根部的构建和代码检查工具。
2. 迁移共享库：先将重复的 DTO、工具类等提取到libs/common-utils，并将 Feign 客户端接口提取到libs/api-client。确保它们能独立编译。
3. 迁移后端服务（逐个进行）：
   • 例如，先迁移user-service。将其代码移动到services/user-service/src，调整其build.gradle.kts以依赖新的共享库。
   • 运行该服务的测试，确保功能正常。
   • 重复此过程迁移product-service和order-service。
4. 迁移前端应用：将admin-frontend代码移动到apps/admin-frontend，更新其package.json中可能指向本地共享组件库（ui-components）的依赖。
5. 整合 CI/CD：在单体仓库根目录创建统一的 CI 配置文件（如.github/workflows/ci.yml），配置针对变更路径的智能构建和测试。
6. 并行运行与验证：在迁移过渡期，可以暂时保持旧仓库的只读状态，新开发都在单体仓库进行，并行运行一段时间以确保稳定性。
7. 最终切换：更新所有文档、部署脚本，将 Git 远程仓库指向新的单体仓库，完成切换。

4.6 第六步：生成辅助脚本与文档

目标：获得提升开发效率的自动化脚本和关键文档模板。操作：向 Claude Code 索要实用脚本。提示词示例：

请为我生成几个实用的脚本： 1. 一个根目录的 `Makefile` 或 `package.json` 脚本，用于启动所有后端服务和前端应用。 2. 一个用于在 `services` 目录下快速创建新 Spring Boot 服务模版的脚本（使用 Gradle init）。 3. 一份 `docs/dev-setup.md` 的初版内容，指导新成员如何搭建开发环境。

Claude Code 生成的脚本示例：

根目录package.json中的脚本部分：

{ "name": "ecommerce-monorepo-root", "private": true, "scripts": { "install:all": "pnpm install -r", "dev:frontend": "pnpm --filter admin-frontend dev", "build:frontend": "pnpm --filter admin-frontend build", "build:services": "./gradlew :services:build", "build:libs": "./gradlew :libs:build", "build:all": "pnpm run build:libs && pnpm run build:services && pnpm run build:frontend", "test:services": "./gradlew :services:test", "test:all": "./gradlew test && pnpm -r test", "start:services": "concurrently \"./gradlew :services:user-service:bootRun\" \"./gradlew :services:product-service:bootRun\" \"./gradlew :services:order-service:bootRun\"", "start:all": "concurrently \"pnpm run start:services\" \"pnpm run dev:frontend\"" }, "devDependencies": { "concurrently": "^8.0.0" } }

说明：使用pnpm -r在所有工作区运行命令，使用./gradlew :子项目路径:任务执行特定 Gradle 任务。concurrently用于并行启动多个服务。

5. 运行结果与效果验证

规划完成后，关键在于验证这个结构是否真的能工作。以下是验证步骤：

5.1 初始化与依赖安装

# 1. 克隆或创建仓库 git clone <your-monorepo-url> ecommerce-monorepo cd ecommerce-monorepo # 2. 安装前端依赖 (使用 pnpm) pnpm install # 3. 构建 Java 共享库，确保它们能被发布到本地 Maven 仓库或作为项目引用 ./gradlew :libs:common-utils:build ./gradlew :libs:api-client:build

预期结果：所有依赖下载成功，共享库编译通过，生成jar文件。

5.2 验证服务间依赖

# 尝试构建 order-service，它依赖 api-client 和 common-utils ./gradlew :services:order-service:build

预期结果：构建成功，控制台输出BUILD SUCCESSFUL。这证明 Gradle 正确解析了项目间的依赖关系。

5.3 运行测试

# 运行所有 Java 项目的测试 ./gradlew test # 运行前端项目的测试 pnpm -r test

预期结果：所有单元测试和集成测试通过。这是代码功能正确性的基础保障。

5.4 启动应用（开发环境）

# 使用根目录的脚本启动所有服务（需要先安装 concurrently） pnpm run start:all

预期结果：

1. 三个 Spring Boot 服务分别在各自的端口（如 8080, 8081, 8082）成功启动，日志显示无异常。
2. React 前端开发服务器启动（如localhost:5173），并且能通过代理或直接调用后端 API。
3. 打开浏览器访问http://localhost:5173，前端应用能正常加载，并且能调用后端接口获取数据。

5.5 验证增量构建

这是单体仓库的核心优势之一。

# 1. 先进行一次全量构建 ./gradlew clean build # 2. 只修改 libs/common-utils 中的某个工具类文件 echo "// 测试修改" >> libs/common-utils/src/main/java/com/ecommerce/utils/DateUtil.java # 3. 再次构建 order-service ./gradlew :services:order-service:build

预期结果：Gradle 能够智能地识别到order-service依赖的common-utils发生了改变，因此会重新编译common-utils和order-service，但不会重新编译user-service和product-service。构建日志会显示被处理的任务，验证增量构建生效。

6. 常见问题与排查思路

在实践单体仓库和与 Claude Code 协作的过程中，你可能会遇到以下问题：

7. 最佳实践与工程建议

基于 Claude Code 的建议和社区经验，实施单体仓库时请牢记以下原则：

7.1 明确边界与所有权

• 定义清晰的目录规范：如apps/(可独立部署的应用)，libs/(内部共享库)，services/(微服务)，tools/(脚本工具)，docs/。并写入README.md。
• 建立代码所有权：即使代码在一起，也要明确每个模块的主要负责团队或个人。可以使用CODEOWNERS文件。
• API 契约先行：对于共享库（尤其是api-client），要像对待外部 SDK 一样严格管理其公共 API。考虑使用版本号或严格的变更审查。

7.2 投资工具与自动化

• 统一的开发环境：使用Dockerfile或devcontainer.json确保所有开发者环境一致。
• 高效的本地开发：利用 Turborepo、Nx 或 Gradle 的并行和缓存功能，加速本地构建和测试。
• 智能的 CI/CD：CI 流水线必须能识别变更集，只运行受影响部分的测试和构建。这是单体仓库成败的关键。
• 代码质量门禁：在根目录配置统一的 pre-commit hooks 和 CI 检查，确保代码风格、安全扫描和测试覆盖率达标。

7.3 管理依赖与版本

• 内部依赖使用项目引用：在 Gradle 中使用project(‘:path’)，在 pnpm 中使用 workspace 协议 (workspace:*)。避免早期发布到私有仓库的复杂度。
• 外部依赖统一版本：在根目录的gradle.properties或pnpm的overrides字段中，统一管理第三方库的版本，避免冲突。
• 谨慎升级：升级共享库时，要评估对所有依赖方的影响。考虑使用自动化测试和渐进式发布。

7.4 与 Claude Code 协作的策略

• 提供高质量上下文：将项目的主要架构图、关键决策文档（ADR）保存在docs/下，并引导 Claude Code 阅读，它能利用这些信息给出更精准的建议。
• 迭代式提问：不要期望一次得到完美方案。先问结构，再问配置，最后问迁移细节。根据它的回答不断追问和修正。
• 验证生成物：Claude Code 生成的代码和配置是“建议”，不是“圣旨”。务必理解每一行配置的含义，并在测试环境中验证其正确性。
• 结合人类经验：AI 擅长提供模式和最佳实践，但对你业务特有的约束（如合规要求、遗留系统接口）可能不了解。最终的架构决策需要你来做。

8. 总结与后续学习方向

通过本文的梳理，我们可以看到，将 Claude Code 应用于单体仓库规划，实质上是将 AI 的“模式识别”和“知识整合”能力，与开发者的“业务理解”和“工程判断”相结合的过程。它极大地降低了启动一个结构良好的单体仓库的初始认知负担，提供了可立即参考的实践模板。

本文的核心价值在于提供了一个系统性的“AI辅助架构设计”工作流：

1. 从痛点出发，明确为什么要用单体仓库。
2. 利用 AI快速生成符合主流最佳实践的技术选型和项目骨架。
3. 深入关键细节，获取可运行的配置和代码示例。
4. 制定迁移路径，获得可操作的任务清单。
5. 注重验证与排错，确保规划能落地。

后续你可以深入探索的方向：

• 深入构建工具：学习 Gradle 多项目构建的高级特性（如复合构建、变体感知），或深入研究 Turborepo/Nx 的任务流水线和远程缓存，这将极大提升大型单体仓库的构建性能。
• 探索模块化架构：在单体仓库内，如何进一步实践领域驱动设计（DDD），划分清晰的限界上下文（Bounded Context），使得代码结构不仅能被工具管理，更能体现业务逻辑。
• CI/CD 高级实践：实现基于变更图的动态流水线，研究如何将单体仓库与云原生部署（如 Kubernetes）更好地结合，实现每个服务的独立部署和回滚。
• AI 工程化：将类似 Claude Code 的 AI 助手更深度地集成到你的开发流程中，例如自动生成变更影响分析报告、辅助代码审查、维护架构决策记录等。

记住，工具和技术始终服务于业务和团队。单体仓库不是银弹，Claude Code 也不是。它们的价值在于，当你明确面临多仓库带来的协作与效率瓶颈时，能提供一条经过验证的、且有智能工具辅助的破局路径。建议你从一个小型项目或团队开始试点，积累经验后再逐步推广。