1. 项目概述：为什么你需要一份 CLAUDE.md

如果你最近开始用 Claude Code 写代码，感觉它时灵时不灵，或者总在重复一些基础问题，那你大概率缺了一份 CLAUDE.md。这玩意儿不是什么官方文档，而是我们这些天天跟 AI 编程助手打交道的老鸟，自己摸索出来的一套“驯化”指南。你可以把它理解成你和 Claude Code 之间的“合作章程”或者“岗位说明书”。

简单来说，Claude Code 很强大，但它默认是个“通才”。你让它写 Python 数据分析，它可能给你套上 Django 的架子；你让它调前端 CSS，它可能顺手把 Bootstrap 的类名都改了。这种“过度发挥”在初期很让人头疼。CLAUDE.md 的核心作用，就是通过一个纯文本的配置文件，明确地告诉 Claude Code：“在我这个项目里，请按这套规矩来。” 它能极大地提升 AI 生成代码的准确性、一致性，并减少大量无效的上下文澄清对话。

从热词里你能看到，大家已经在热烈讨论 .cursorrules、AGENTS.md 这些类似的概念了。这正说明，为 AI 助手制定规则，已经成为高效 AI 编程的标配技能。掌握 CLAUDE.md，你就不再是 Claude Code 的“用户”，而是它的“指挥官”。

2. CLAUDE.md 的核心设计哲学与结构拆解

一份好的 CLAUDE.md，不是命令的堆砌，而是意图的传达。它的设计遵循几个核心原则：

2.1 明确性高于一切 AI 无法理解模糊的意图。“代码要写好”是废话，“函数命名采用小写蛇形，并添加详细的 Google 风格 Docstring”才是明确的指令。你的每一条规则，都应该像给一个严谨的新同事写工作手册一样，没有歧义。

2.2 上下文即王道 CLAUDE.md 的力量在于它被放置在项目根目录，Claude Code 在分析你的项目时，会优先读取并理解这份文件。这意味着，你无需在每个对话中重复项目规范、技术栈偏好或代码风格。它提供了持续、稳定的上下文背景。

2.3 结构化便于维护 一个杂乱无章的 CLAUDE.md 文件会迅速变得难以使用和更新。我们需要一个清晰的结构，让不同类别的信息各归其位。

基于这些原则，一个典型的 CLAUDE.md 文件结构如下：

2.1 项目全局设定

这部分定义了项目的“宪法”。它通常包括：

  • 项目简介与目标 ：用一两句话说明这个项目是做什么的，核心业务逻辑是什么。这能帮助 AI 理解代码的最终目的，做出更合理的架构选择。
  • 技术栈与版本 ：明确列出主要使用的语言、框架、库及其版本号。例如： Python 3.9+, FastAPI 0.104+, SQLAlchemy 2.0, Pydantic V2 。这能有效防止 AI 推荐过时或冲突的语法。
  • 核心架构与模式 ：说明项目采用的主要设计模式（如 MVC、DDD）、代码组织结构（如 src/ 分层）和关键约定。例如：“本项目采用领域驱动设计，领域模型位于 src/core/domain/ ，应用服务位于 src/core/application/ 。”

2.2 代码规范与风格约束

这是使用最频繁的部分，直接决定了生成代码的“颜值”和“气质”。

  • 命名规范 ：规定变量、函数、类、文件等的命名规则。例如：“Python 模块和包名使用小写蛇形，类名使用大驼峰，常量使用大写蛇形。”
  • 代码风格 ：可以引用或直接指定风格指南，如 PEP 8 for Python, Airbnb Style Guide for JavaScript。甚至可以细化到“每行不超过 88 字符”、“使用双引号定义字符串”。
  • 导入与依赖管理 ：规定导入语句的顺序（标准库、第三方库、本地模块），是否使用绝对导入等。

2.3 开发流程与质量要求

这部分指导 AI 如何“思考”和“工作”。

  • 测试驱动开发要求 ：明确要求 AI 在实现功能前先编写测试用例。例如：“任何新功能必须优先编写 pytest 测试用例，确保覆盖核心路径和边界条件。”
  • 代码审查要点 ：告诉 AI 你关注哪些代码质量维度。例如：“生成的代码必须考虑异常处理，避免裸的 except: 。循环中避免复杂的逻辑，优先考虑列表推导式或 map/filter 。”
  • 提交信息规范 ：如果你希望 AI 协助生成 Git 提交信息，可以在这里给出格式模板，如 Conventional Commits。

2.4 特定任务与场景指令

针对项目中常见的、特定的任务，给出精确的指令模板。这是提升效率的“快捷键”。

  • API 端点生成 ：“当需要创建新的 REST API 端点时，请遵循以下模板：使用 FastAPI 的 @app.post/put/get/delete 装饰器；请求/响应模型使用 Pydantic V2；路径参数和查询参数需明确类型和验证；业务逻辑封装在 service 层函数中。”
  • 数据库模型定义 ：“定义 SQLAlchemy ORM 模型时，需从 Base 类继承；字段需明确类型和约束（如 nullable , unique ）；关系使用 relationship 和 back_populates 正确定义。”
  • 前端组件创建 ：“创建 React 函数组件时，使用 TypeScript 并导出 FC 类型；Props 需定义接口；优先使用 useState , useEffect 等钩子；样式使用 CSS Modules，类名格式为 .componentName__element 。”

3. 8个让 Claude Code 起飞的实战技巧

理解了结构，我们来看如何填充内容。下面这8个技巧，是我从大量项目实践中总结出的“黄金法则”，能让你和 Claude Code 的协作效率产生质变。

3.1 技巧一：用“角色扮演”设定清晰的 AI 人设

不要将 Claude Code 视为工具，而是视为一个具有特定专长和性格的“资深开发者”。在 CLAUDE.md 的开头，直接为其赋予一个角色。

实操示例： 

# CLAUDE.md

## 角色与职责
你是一位资深后端架构师，专注于构建高可用、可维护的 Python 微服务。你性格严谨，注重细节，对代码性能和安全性有极高的要求。在本项目中，你将协助我进行所有后端开发工作。

## 项目上下文
项目名称：订单处理中心
核心目标：为电商平台提供稳定、高效的订单创建、查询和状态管理接口。
技术栈：Python 3.10, FastAPI, SQLAlchemy 2.0, Pydantic V2, PostgreSQL, Redis（缓存）

为什么有效？ 这个设定为 AI 的“思考”提供了初始方向。当它接到一个模糊的请求时，会基于“资深后端架构师”的视角去优先考虑架构合理性、异常边界、性能影响，而不是仅仅完成语法正确的代码。

3.2 技巧二：固化技术栈与版本，避免“版本漂移”

AI 的知识库可能包含同一个库的多个版本。如果不加约束，它可能混用新旧语法，导致项目依赖冲突或运行时错误。

实操示例： 

## 技术栈与版本锁
*   **语言与运行时**: Python == 3.10.12 (使用 pyenv 管理)
*   **Web框架**: FastAPI == 0.104.1
*   **ORM**: SQLAlchemy == 2.0.23
*   **数据验证**: Pydantic == 2.5.0 (必须使用 V2 语法，如 `Field` 替代 `schema_extra`)
*   **异步驱动**: asyncpg == 0.29.0
*   **缓存**: redis == 5.0.1
*   **测试**: pytest == 7.4.3, pytest-asyncio == 0.21.1

注意事项： 版本号最好精确到小版本。同时，可以补充关键语法提示，比如明确要求使用 Pydantic V2 语法，这能直接避免 AI 生成已被废弃的 V1 代码。

3.3 技巧三：制定原子级的代码风格规则

不要只说“遵循 PEP 8”，要把你最在意、最容易出错的细节写清楚。AI 对具体规则的执行能力远超对抽象原则的理解。

实操示例： 

## 代码风格规范
### 通用规则
1.  **最大行宽**: 88 字符（使用 Black 格式化器默认值）。
2.  **引号**: 所有字符串使用双引号 `"`，除非字符串内包含双引号。
3.  **导入排序**: 分三组，每组空一行：1) 标准库；2) 第三方库；3) 本地模块。每组内按字母排序。
4.  **类型注解**: 所有函数、方法必须包含返回类型和参数类型注解。使用 `from typing import ...`。

### Python 特定规则
1.  **异常处理**: 禁止使用裸 `except:`。必须捕获具体异常，如 `except ValueError as e:`。记录日志后，根据情况重新抛出或转换为业务异常。
2.  **字典与列表**: 优先使用字典推导式和列表推导式，除非逻辑过于复杂。
3.  **路径处理**: 使用 `pathlib.Path` 替代 `os.path`。

实操心得： 一开始可以只写几条你最在意的规则，比如“禁止裸 except”。在后续协作中，每当发现 AI 在某个风格点上反复“犯错”，就把这条规则补充进 CLAUDE.md。这个文件是动态成长的。

3.4 技巧四：为高频操作编写“代码模板”

这是提升效率最显著的一招。将项目中重复出现的代码模式抽象成模板，让 AI 直接套用。

实操示例： 

## 代码模板
### FastAPI 路由处理器模板
```python
from fastapi import APIRouter, Depends, HTTPException, status
from app.schemas import SomeRequest, SomeResponse
from app.services import some_service
from app.dependencies import get_current_user

router = APIRouter(prefix="/api/v1/some-resource", tags=["SomeResource"])

@router.post("/", response_model=SomeResponse, status_code=status.HTTP_201_CREATED)
async def create_something(
    request: SomeRequest,
    current_user = Depends(get_current_user)
) -> SomeResponse:
    """
    创建某个资源。
    - **request**: 创建请求体。
    - **current_user**: 通过依赖注入获取的当前用户。
    """
    try:
        # 参数验证和业务逻辑已由 Pydantic 和 Service 层处理
        result = await some_service.create(request, user_id=current_user.id)
        return SomeResponse.from_orm(result)
    except ValueError as e:
        # 业务逻辑错误，返回 400
        raise HTTPException(status_code=status.HTTP_400_BAD_REQUEST, detail=str(e))
    except Exception as e:
        # 其他未预期错误，记录日志并返回 500
        logger.error(f"Failed to create something: {e}")
        raise HTTPException(status_code=status.HTTP_500_INTERNAL_SERVER_ERROR, detail="Internal server error")

**为什么有效？** 这个模板不仅规定了代码结构，还嵌入了最佳实践：正确的导入、依赖注入、异常处理分层（业务异常转 400，系统异常转 500）、日志记录。AI 根据这个模板生成的代码，质量立刻就能达到生产级要求，你几乎不需要再做大的调整。

### 3.5 技巧五：强制实施测试驱动开发流程
在 CLAUDE.md 中明确要求 TDD，可以改变 AI 的代码生成顺序，从而从源头提升代码质量。

**实操示例：**
```markdown
## 开发流程
### 测试驱动开发
1.  当接到实现新功能 `X` 的需求时，**必须首先**在 `tests/` 目录下创建或找到对应的测试文件。
2.  编写描述 `X` 功能的测试用例。测试用例应使用 `pytest`，并遵循 `test_<功能>_<场景>` 的命名规则。
3.  运行测试，确认它们因功能未实现而失败（红）。
4.  再请求生成实现功能 `X` 的代码。
5.  运行测试，确保所有用例通过（绿）。
6.  最后，可以请求 AI 审查并重构代码。

### 测试规范
*   使用 `pytest.fixture` 管理测试依赖。
*   对于异步代码，使用 `pytest.mark.asyncio`。
*   断言使用 `assert` 语句，复杂断言可配合 `pytest.assume`。

注意事项： 这个技巧需要你稍微改变一下与 AI 的对话方式。你的提示词应该从“写一个函数来计算用户折扣”变成“我们需要一个计算用户折扣的功能。请先为这个功能编写 pytest 测试用例，覆盖正常情况、边界情况和异常情况。” AI 会根据 CLAUDE.md 的指引，优先产出测试代码。

3.6 技巧六：定义清晰的“禁区”与“推荐区”

明确告诉 AI 什么不该做，和告诉它该做什么同样重要。

实操示例： 

## 禁止与警告
### 绝对禁止
*   **安全**：禁止在任何代码中硬编码密码、API密钥、令牌。必须使用环境变量或配置中心。
*   **数据库**：禁止在路由处理器中直接编写原始 SQL 字符串进行查询。所有数据库操作必须通过 SQLAlchemy ORM 或封装好的 Repository 模式进行。
*   **性能**：禁止在循环内进行数据库查询或发起网络请求。必须使用批量操作或预加载。

### 强烈不推荐
*   **模式**：避免使用单例模式，除非有绝对必要。优先使用依赖注入。
*   **工具**：避免引入新的、未经团队评估的第三方库。如需引入，请在 CLAUDE.md 中先讨论。

实操心得： “禁区”规则能帮你守住项目的底线，尤其是安全和性能的底线。当 AI 生成一个包含 f"SELECT * FROM users WHERE api_key = '{key}'" 的代码片段时，它会因为触犯“禁区”而自我纠正或给出警告。

3.7 技巧七：利用 AGENTS.md 进行复杂任务分解

当项目非常庞大或任务极其复杂时，单一的 CLAUDE.md 可能不够。这时可以引入 AGENTS.md 的概念。你可以认为 CLAUDE.md 是“宪法”，而 AGENTS.md 是针对特定复杂任务的“专项法律”或“作战手册”。

实操示例： 假设你需要实现一个“用户积分系统”，涉及积分计算、过期、兑换、排行榜等多个子域。

  1. 你可以在项目根目录创建一个 agents/ 文件夹。
  2. 在 agents/integration_system.md 文件中，详细描述这个任务： 
    # 积分系统实施手册
## 目标
构建一个完整、可扩展的用户积分系统。
## 子任务分解
1.  **积分账户模型**：设计 `CreditAccount` 表，包含用户ID、余额、过期时间等。
2.  **积分流水模型**：设计 `CreditTransaction` 表，记录每一笔积分的变动（获取、消费、过期），类型、数量、关联业务ID等。
3.  **核心服务层**：
    - `CreditService.earn(user_id, amount, reason)`: 赚取积分。
    - `CreditService.consume(user_id, amount, reason)`: 消费积分（需检查余额）。
    - `CreditService.expire()`: 定时任务，处理过期积分。
4.  **API层**：提供查询余额、流水明细的只读接口。
5.  **定时任务**：使用 Celery 或 APScheduler 实现每日积分过期任务。
## 与主项目集成点
*   用户注册成功后，自动调用 `CreditService.earn()` 赠送新手积分。
*   订单完成后，调用 `CreditService.earn()` 根据订单金额赠送积分。
  3. 在与 Claude Code 对话时，你可以直接说：“请参考 agents/integration_system.md 文件，开始实现子任务1：积分账户模型。”

为什么有效？ 这相当于把一个大需求拆解成了 AI 可以逐步消化、执行的工单。AI 每次只需要关注一个相对独立的子模块，同时又能通过 AGENTS.md 理解该模块在整个系统中的位置和职责，保证了代码的连贯性和系统整体架构的一致性。

3.8 技巧八：持续迭代与“对话式”更新

CLAUDE.md 不是一份写完后就被束之高阁的文档。它应该是一个活的、随着项目和你对 AI 使用熟练度而不断进化的知识库。

更新策略：

  1. 问题驱动更新 ：每当你在 review AI 生成的代码时，发现一个重复出现的风格问题、一个可以优化的模式、或者一个错误的依赖使用，不要只是口头纠正。立刻停下来，将这条经验总结成一条清晰的规则，补充到 CLAUDE.md 的对应章节。
  2. 版本化 ：像对待代码一样，用 Git 管理你的 CLAUDE.md 文件。重大的规则变更可以提交一个 commit，例如 “feat(claude-md): 增加异步上下文管理器使用规范”。
  3. 定期回顾 ：每隔一段时间（比如完成一个项目里程碑），从头到尾阅读一遍 CLAUDE.md。你可能会发现一些早期制定的规则已经过时，或者不同规则之间存在矛盾。进行梳理和精简，保持文件的清晰和有效。

一个迭代的示例： 最初，你的 CLAUDE.md 里可能只有“使用日志记录”。经过几次合作，你发现 AI 生成的日志级别混乱，有的地方用 debug ，有的地方用 info 。于是你更新为：

## 日志规范
*   **记录器**：通过 `logging.getLogger(__name__)` 获取模块级记录器。
*   **级别使用**：
    - `DEBUG`: 详细的调试信息，如函数入参、中间结果。
    - `INFO`: 重要的业务流程节点，如“开始处理订单XXX”、“用户XXX登录成功”。
    - `WARNING`: 不影响程序运行但需要关注的情况，如“缓存键XXX不存在，使用默认值”。
    - `ERROR`: 业务逻辑失败，如“用户余额不足”、“数据库唯一约束冲突”。
    - `CRITICAL`: 系统级错误，如“数据库连接池耗尽”、“磁盘空间不足”。
*   **格式**：日志消息应包含上下文，如 `f”Failed to process order {order_id} for user {user_id}: {error}”`。

这个迭代过程，本质上是你将自己的开发经验和最佳实践，系统地“灌输”给 AI 的过程。

4. 从配置到实战：一个完整的工作流示例

让我们通过一个模拟场景，看看如何将上述技巧融入一个完整的开发工作流中。

场景： 你正在开发一个简单的待办事项 API 后端，使用 FastAPI 和 SQLAlchemy。

第一步：初始化 CLAUDE.md 在项目根目录创建 CLAUDE.md ，填入以下核心内容（融合了技巧一、二、三）：

# CLAUDE.md
## 角色
你是我的 Python 后端开发伙伴，专注于构建简洁、健壮的 RESTful API。

## 项目：Todo API
一个提供待办事项管理的后端服务。

## 技术栈
*   Python 3.11
*   FastAPI 0.104+
*   SQLAlchemy 2.0+
*   Pydantic V2
*   SQLite (开发)/PostgreSQL (生产)

## 代码风格
*   使用 Black 和 isort 格式化。
*   所有端点必须包含响应模型和状态码。
*   数据库操作必须放在 `crud.py` 文件中，使用异步会话。
*   错误处理：业务错误返回 400+描述，系统错误记录日志并返回 500。

第二步：实现第一个端点（应用技巧四、五） 你打开 Claude Code 聊天窗口，输入：“我们需要一个创建待办事项的 POST 端点。请先为这个功能编写 pytest 测试用例。”

Claude Code 会读取 CLAUDE.md ，理解项目上下文。它可能会生成类似下面的测试代码到 tests/test_todos.py ：

import pytest
from httpx import AsyncClient
from app.main import app

@pytest.mark.asyncio
async def test_create_todo_success():
    """测试成功创建待办事项"""
    async with AsyncClient(app=app, base_url="http://test") as ac:
        payload = {"title": "Buy milk", "description": "Get 2 liters"}
        response = await ac.post("/todos/", json=payload)
    assert response.status_code == 201
    data = response.json()
    assert data["title"] == payload["title"]
    assert "id" in data
    assert data["completed"] is False

@pytest.mark.asyncio
async def test_create_todo_missing_title():
    """测试缺少标题时返回400错误"""
    async with AsyncClient(app=app, base_url="http://test") as ac:
        payload = {"description": "No title"}
        response = await ac.post("/todos/", json=payload)
    assert response.status_code == 400

你运行测试，它们会失败（因为端点还没实现）。然后你继续对 AI 说：“很好。现在请实现这个端点，包括必要的 Pydantic 模型、数据库模型和 CRUD 函数。”

AI 会基于 CLAUDE.md 的约束（如代码组织、异步、错误处理）和已有的测试用例，生成结构清晰的代码。它可能会将代码分别放在 app/schemas/todo.py , app/models/todo.py , app/crud/todo.py 和 app/api/todos.py 中，并且生成的端点代码会自然地包含 response_model 和 status_code=201 。

第三步：处理边界情况（应用技巧六） 你 Review 代码，发现 AI 生成的 CRUD 函数直接使用了传进来的 db 会话，但没有处理回滚。你意识到这需要成为一条规则。于是你更新 CLAUDE.md ，在“代码风格”或新增的“数据库规范”章节加入：

## 数据库事务
*   在 CRUD 函数中，如果执行了写操作（INSERT, UPDATE, DELETE），必须使用 `await db.commit()`。
*   必须在 `try...except` 块中执行，发生异常时执行 `await db.rollback()` 并重新抛出异常。

之后，当你再请求 AI 编写更新或删除的 CRUD 函数时，它就会自动包含事务处理逻辑。

第四步：扩展功能与迭代 当需要添加“待办事项分类”功能时，你的对话可以非常高效：“参考现有的 Todo 模块结构，为‘分类’（Category）创建完整的 CRUD 端点。分类有 name 和 color 字段。一个分类下可以有多个待办事项。”

由于 CLAUDE.md 已经定义了项目结构、代码风格和数据库模式，AI 能够快速、准确地生成风格一致、质量可控的整套代码。

5. 避坑指南与常见问题排查

即使有了详尽的 CLAUDE.md，在实际使用中还是会遇到一些问题。这里记录了一些常见坑点和解决方法。

5.1 AI 似乎“忽略”了 CLAUDE.md 中的某些规则

现象： 你明确规定了函数命名用蛇形，但 AI 还是生成了驼峰命名的函数。 排查与解决：

  1. 检查文件位置和名称 ：确保文件名为 CLAUDE.md （全大写），并且位于项目的 根目录 。Claude Code 通常只认这个位置的这个文件名。
  2. 检查规则表述 ：规则是否足够具体、无歧义？将“使用蛇形命名”改为“函数和变量名使用小写蛇形命名法，单词间用下划线连接，例如： calculate_total_amount ”。
  3. 重启或重载会话 ：有时 AI 的上下文窗口需要刷新。尝试关闭当前聊天窗口，重新打开一个新对话，或者使用编辑器插件提供的“重载上下文”功能。
  4. 在对话中明确引用 ：在提示词中直接强调：“请严格遵守 CLAUDE.md 中第 3.2 节的命名规范。”

5.2 生成的代码存在隐藏的安全或性能问题

现象： AI 生成了看似能用的 SQL 查询，但可能存在 SQL 注入风险；或者在循环内进行了网络请求。 解决方案：

  1. 强化“禁区”规则 ：在 CLAUDE.md 的“禁止与警告”章节，将这些问题列为“绝对禁止”项，并给出正确做法的示例。例如：“禁止使用字符串拼接生成 SQL。必须使用 SQLAlchemy 的查询表达式或参数化查询。”
  2. 进行针对性代码审查 ：不要完全信任 AI 的输出。对于涉及安全（认证、授权、数据验证）、资金、性能核心路径的代码，必须进行人工仔细审查。将 AI 视为一个强大的初级或中级开发者，你仍然是最终的责任人（Tech Lead）。

5.3 CLAUDE.md 文件变得过于冗长和难以维护

现象： 文件长度超过 500 行，查找和更新规则变得困难。 解决方案：

  1. 模块化拆分 ：对于大型项目，可以考虑将 CLAUDE.md 拆分成多个文件。例如：
    • CLAUDE.md (主文件，包含角色、项目概述、核心原则和索引)
    • CODING_STANDARDS.md (详细的代码风格规范)
    • ARCHITECTURE_GUIDE.md (架构与设计模式)
    • TASK_TEMPLATES.md (各种代码模板) 在主 CLAUDE.md 中通过链接引用这些子文件。
  2. 定期重构 ：每个季度或每个大版本，花时间整理 CLAUDE.md。合并重复的规则，删除过时的约束，优化表达方式。保持它的简洁和有效。
  3. 使用注释分区 ：在文件内使用清晰的注释标题（如 ## --- 数据库规范 --- ## ）来划分区域，提高可读性。

5.4 如何处理第三方库或框架的特定版本差异

现象： 项目升级了 FastAPI 版本，一些旧语法被废弃，但 AI 仍可能生成旧语法。 解决方案：

  1. 及时更新技术栈声明 ：升级依赖后，第一时间更新 CLAUDE.md 中的版本号。
  2. 提供迁移指南片段 ：如果新旧版本语法差异大，可以在 CLAUDE.md 中添加一个“版本迁移提示”章节，简要说明关键变化。例如：“本项目已升级至 Pydantic V2。禁止使用 schema_extra ，请使用 Field(json_schema_extra=...) 。”
  3. 在提示词中强调版本 ：在涉及该库的对话中，开头可以加上：“注意，我们使用的是 FastAPI 0.104+，请使用该版本对应的语法。”

5.5 团队协作时，如何统一 CLAUDE.md

现象： 团队中多人使用 Claude Code，但每个人的 CLAUDE.md 习惯不同，导致代码风格不一致。 解决方案：

  1. 将 CLAUDE.md 纳入版本控制 ：将 CLAUDE.md 文件提交到团队的 Git 仓库中，使其成为项目的一部分，像 README.md 或 docker-compose.yml 一样。
  2. 建立评审流程 ：对 CLAUDE.md 的修改，也需要像代码一样发起 Merge Request，经过其他团队成员评审后再合并。
  3. 作为新人 onboarding 材料 ：新成员加入项目时，除了看代码，也必须阅读并理解 CLAUDE.md 。这能极大缩短他们上手使用 AI 辅助开发的时间，并保证产出代码与团队标准一致。

掌握 CLAUDE.md 的编写和使用，是一个从“被动使用 AI”到“主动塑造 AI 工作流”的转变。它需要你前期投入一些时间总结和梳理自己的开发规范，但带来的长期收益是巨大的：更少的上下文切换、更一致的代码质量、更快的开发速度，以及一个真正与你项目深度契合的智能编程伙伴。

# 代码规范
Logo
亚马逊云科技技术品牌专区

更多推荐

cover

大 硬 仗14小时：用2009年的上古亮机卡跑完深度学习，CPU满载但代码没崩

avatar 亚马逊云科技技术品牌专区
cover

害虫检测和识别3：基于深度学习YOLO26神经网络实现害虫检测和识别(含训练代码、数据集和GUI交互界面）

avatar 亚马逊云科技技术品牌专区
cover

原来AI、画图、导航都在用向量！

avatar 亚马逊云科技技术品牌专区