codebase-onboarding

代码库入门

系统性地分析不熟悉的代码库，生成结构化的入门指南。专为加入新项目或首次在现有仓库中设置 Claude Code 的开发者设计。

何时使用

• 首次使用 Claude Code 打开项目
• 加入新团队或仓库
• 用户要求“帮我理解这个代码库”
• 用户要求为项目生成 CLAUDE.md
• 用户说“带我入门”或“带我了解这个仓库”

工作原理

阶段 1：侦察

在不读取每个文件的情况下收集项目的基本信号。并行执行以下检查：

1. 包清单检测
   → package.json, go.mod, Cargo.toml, pyproject.toml, pom.xml, build.gradle,
     Gemfile, composer.json, mix.exs, pubspec.yaml

2. 框架识别
   → next.config.*, nuxt.config.*, angular.json, vite.config.*,
     django settings, flask app factory, fastapi main, rails config

3. 入口点识别
   → main.*, index.*, app.*, server.*, cmd/, src/main/

4. 目录结构快照
   → 目录树的前 2 层，忽略 node_modules, vendor,
     .git, dist, build, __pycache__, .next

5. 配置和工具检测
   → .eslintrc*, .prettierrc*, tsconfig.json, Makefile, Dockerfile,
     docker-compose*, .github/workflows/, .env.example, CI 配置

6. 测试结构检测
   → tests/, test/, __tests__/, *_test.go, *.spec.ts, *.test.js,
     pytest.ini, jest.config.*, vitest.config.*

阶段 2：架构映射

根据侦察数据，识别：

技术栈

• 语言和版本约束
• 框架和主要库
• 数据库和 ORM
• 构建工具和打包器
• CI/CD 平台

架构模式

• 单体、单仓库、微服务或无服务器
• 前后端分离或全栈
• API 风格：REST、GraphQL、gRPC、tRPC

关键目录
将顶级目录映射到其用途：

<!-- 示例：React 项目 — 替换为检测到的目录 -->

src/components/  → React UI 组件
src/api/         → API 路由处理器
src/lib/         → 共享工具
src/db/          → 数据库模型和迁移
tests/           → 测试套件
scripts/         → 构建和部署脚本

数据流
追踪一个请求从入口到响应的过程：

• 请求从哪里进入？（路由器、处理器、控制器）
• 如何验证？（中间件、模式、守卫）
• 业务逻辑在哪里？（服务、模型、用例）
• 如何到达数据库？（ORM、原始查询、仓库）

阶段 3：约定检测

识别代码库已遵循的模式：

命名约定

• 文件命名：kebab-case、camelCase、PascalCase、snake_case
• 组件/类命名模式
• 测试文件命名：*.test.ts、*.spec.ts、*_test.go

代码模式

• 错误处理风格：try/catch、Result 类型、错误码
• 依赖注入或直接导入
• 状态管理方法
• 异步模式：回调、Promise、async/await、channel

Git 约定

• 从最近分支看分支命名
• 从最近提交看提交消息风格
• PR 工作流（squash、merge、rebase）
• 如果仓库没有提交或只有浅层历史（例如 git clone --depth 1），跳过此部分并注明“Git 历史不可用或太浅，无法检测约定”

阶段 4：生成入门产物

生成两个输出：

输出 1：入门指南

# 入门指南：[项目名称]

## 概述
[2-3 句话：项目功能和服务对象]

## 技术栈
<!-- 示例：Next.js 项目 — 替换为检测到的栈 -->
| 层 | 技术 | 版本 |
|-------|-----------|---------|
| 语言 | TypeScript | 5.x |
| 框架 | Next.js | 14.x |
| 数据库 | PostgreSQL | 16 |
| ORM | Prisma | 5.x |
| 测试 | Jest + Playwright | - |

## 架构
[组件连接方式的图表或描述]

## 关键入口点
<!-- 示例：Next.js 项目 — 替换为检测到的路径 -->
- **API 路由**：`src/app/api/` — Next.js 路由处理器
- **UI 页面**：`src/app/(dashboard)/` — 认证页面
- **数据库**：`prisma/schema.prisma` — 数据模型权威来源
- **配置**：`next.config.ts` — 构建和运行时配置

## 目录映射
[顶级目录 → 用途映射]

## 请求生命周期
[追踪一个 API 请求从入口到响应的过程]

## 约定
- [文件命名模式]
- [错误处理方法]
- [测试模式]
- [Git 工作流]

## 常见任务
<!-- 示例：Node.js 项目 — 替换为检测到的命令 -->
- **运行开发服务器**：`npm run dev`
- **运行测试**：`npm test`
- **运行 linter**：`npm run lint`
- **数据库迁移**：`npx prisma migrate dev`
- **构建生产版本**：`npm run build`

## 查找位置
<!-- 示例：Next.js 项目 — 替换为检测到的路径 -->
| 我想... | 查看... |
|--------------|-----------|
| 添加 API 端点 | `src/app/api/` |
| 添加 UI 页面 | `src/app/(dashboard)/` |
| 添加数据库表 | `prisma/schema.prisma` |
| 添加测试 | `tests/` 匹配源路径 |
| 更改构建配置 | `next.config.ts` |

输出 2：初始 CLAUDE.md

根据检测到的约定生成或更新项目特定的 CLAUDE.md。如果 CLAUDE.md 已存在，先读取并增强它 — 保留现有的项目特定指令，并明确标注新增或更改的内容。

# 项目指令

## 技术栈
[检测到的栈摘要]

## 代码风格
- [检测到的命名约定]
- [检测到的要遵循的模式]

## 测试
- 运行测试：`[detected test command]`
- 测试模式：[检测到的测试文件约定]
- 覆盖率：[如果配置了，覆盖率命令]

## 构建与运行
- 开发：`[detected dev command]`
- 构建：`[detected build command]`
- Lint：`[detected lint command]`

## 项目结构
[关键目录 → 用途映射]

## 约定
- [如果可检测，提交风格]
- [如果可检测，PR 工作流]
- [错误处理模式]

最佳实践

1. 不要读取所有内容 — 侦察应使用 Glob 和 Grep，而不是读取每个文件。仅在信号不明确时有选择地读取。
2. 验证，不要猜测 — 如果从配置检测到某个框架，但实际代码使用了不同的框架，请相信代码。
3. 尊重现有的 CLAUDE.md — 如果已存在，增强它而不是替换它。标注新增与现有内容。
4. 保持简洁 — 入门指南应在 2 分钟内可浏览。细节属于代码，而不是指南。
5. 标记未知项 — 如果无法自信地检测到某个约定，请说明而不是猜测。“无法确定测试运行器”比错误答案更好。

应避免的反模式

• 生成超过 100 行的 CLAUDE.md — 保持专注
• 列出所有依赖项 — 仅突出影响代码编写的依赖项
• 描述显而易见的目录名称 — src/ 不需要解释
• 复制 README — 入门指南提供了 README 所缺乏的结构性洞察

示例

示例 1：首次进入新仓库

用户：“带我了解这个代码库”
操作：运行完整的 4 阶段工作流 → 生成入门指南 + 初始 CLAUDE.md
输出：入门指南直接打印到对话中，并将 CLAUDE.md 写入项目根目录

示例 2：为现有项目生成 CLAUDE.md

用户：“为这个项目生成 CLAUDE.md”
操作：运行阶段 1-3，跳过入门指南，仅生成 CLAUDE.md
输出：包含检测到的约定的项目特定 CLAUDE.md

示例 3：增强现有 CLAUDE.md

用户：“用当前项目约定更新 CLAUDE.md”
操作：读取现有 CLAUDE.md，运行阶段 1-3，合并新发现
输出：更新后的 CLAUDE.md，新增内容清晰标注