第 3 章:Claude Code 高效工作流
驾驭 AI 编程工具的核心能力 — 阅读、编辑、执行、搜索
🎯 本章学习目标
- 掌握 Claude Code 四大核心能力:读取、编辑、执行、搜索
- 学会编写高效的 CLAUDE.md 项目引导文件
- 掌握跨文件编辑的原子性与一致性策略
- 建立 AI 辅助的 Git 工作流(commit、PR、review)
- 熟练运用 TDD 循环(测试驱动开发 + AI)
3.1 Claude Code 的核心能力模型
📖 读取(Read)
理解代码库的能力。AI 可以阅读文件、分析项目结构、理解上下文。关键用法:让 AI 先理解现有代码再修改,而不是盲目重写。
✏️ 编辑(Edit)
精确修改代码的能力。支持单文件和多文件的原子性修改。关键用法:分小步修改,每步可验证,避免大范围重写。
▶️ 执行(Execute)
运行命令、测试、构建的能力。AI 可以直接执行 shell 命令并读取输出。关键用法:生成代码 → 运行测试 → 根据结果修复,形成闭环。
🔍 搜索(Search)
在代码库中查找信息的能力。关键用法:重构前先搜索所有引用点,确保修改范围完整。
3.2 CLAUDE.md — 项目的"AI 说明书"
CLAUDE.md 是 Claude Code 的核心配置机制。放在项目根目录的 CLAUDE.md 会在每次会话开始时自动注入 AI 的上下文,让它立即理解你的项目。
CLAUDE.md 最佳实践模板
# 项目名称:[Project Name]
# 一句话描述:[这个项目是做什么的]
## 技术栈
- 后端:Python 3.11 + FastAPI + SQLAlchemy
- 前端:Vue 3 + TypeScript + Vite
- 数据库:PostgreSQL 15
- 测试:pytest + pytest-cov + Playwright
## 项目结构
```
src/
├── api/ # REST API 路由层
├── services/ # 业务逻辑层
├── models/ # 数据模型
├── core/ # 配置、中间件
└── utils/ # 工具函数
tests/ # 测试(结构与 src/ 镜像)
```
## 编码规范
- Python: PEP 8, 类型注解, black 格式化, 行宽 100
- 前端: ESLint + Prettier, 组件使用 Composition API
- 命名: snake_case (Python), camelCase (TS), kebab-case (文件)
- 每个公开函数必须有 docstring (Google style)
## 架构约定
- 遵循分层架构:API → Service → Repository → DB
- 所有数据库操作通过 Repository 模式
- 业务逻辑在 Service 层,不在 API 路由中
- 配置通过环境变量注入,使用 pydantic-settings
## 测试策略
- 单元测试覆盖所有 service 和 utils
- API 测试使用 TestClient
- E2E 测试覆盖核心用户流程
- 目标覆盖率 > 80%
## Git 工作流
- 分支命名: feature/xxx, fix/xxx, refactor/xxx
- Commit: 遵循 conventional commits (feat:, fix:, refactor:)
- PR 前必须通过 CI(lint + test + typecheck)
## 当前状态
- 正在开发:[当前阶段的主要任务]
- 已知问题:[链接到 Issue]
- 下一步计划:[简要说明]
3.3 跨文件编辑的最佳实践
原则:原子性编辑
当一次修改涉及多个文件时——例如重命名一个函数——所有相关文件必须在同一轮对话中完成修改。否则,代码库会进入不一致的状态。
1搜索影响范围:在编辑前搜索所有引用
2规划修改顺序:接口定义 → 实现 → 调用方 → 测试
3逐文件修改:每次修改后验证该文件能通过语法检查
4全局验证:运行完整测试套件
5检查一致性:再次搜索确保没有遗漏
3.4 AI + Git 协作模式
| 场景 | 传统方式 | AI 增强方式 |
|---|---|---|
| 编写 commit | 手动写 summary | 让 AI 分析 diff 生成 conventional commit |
| PR 描述 | 手动写变更说明 | AI 分析变更集生成结构化 PR |
| Code Review | 逐行审查 | AI 预审 → 人工聚焦高风险点 |
| 重构 | 手动批量修改 | AI 搜索+替换,人工确认 |
| 查历史 | git log/blame | AI 总结变更历史和演进趋势 |
📋 本章提示词模板
模板 3.1:项目初始化模板(CLAUDE.md 生成)
📋
请为以下项目生成 CLAUDE.md 文件:
## 项目信息
- 名称:[项目名]
- 目标:[一句话描述]
- 技术栈:[列出所有技术]
- 目录结构:[粘贴 tree 输出]
## 编码规范
- [语言]:[规范名称,如 PEP 8]
- 行宽:[80/100/120]
- 格式化工具:[black/prettier/...]
- 命名约定:[snake_case/camelCase/...]
## 架构约定
- [分层架构 / 六边形架构 / MVC / ...]
- [主要设计模式的约定]
## 输出格式
生成完整的 CLAUDE.md Markdown 文件,包含以上所有信息,并补充合理的默认约定。
模板 3.2:TDD 循环提示词
📋
我们使用 TDD(测试驱动开发)方式实现以下功能:
## 功能描述
[一句话描述功能]
## 当前阶段:[RED / GREEN / REFACTOR]
### 如果是 RED 阶段(先写测试)
请为以下接口生成测试用例:
- 接口签名:[函数签名]
- 测试用例需覆盖:正常输入、边界值、异常输入、并发场景
- 使用 [pytest / unittest / jest] 框架
### 如果是 GREEN 阶段(实现代码)
请根据以下测试实现最小可行的代码,使测试通过:
[粘贴测试代码]
- 不要过度工程化
- 满足当前测试即可
### 如果是 REFACTOR 阶段(重构)
以下代码通过了所有测试,请进行重构优化:
[粘贴代码]
- 保持测试通过
- 改善可读性和架构
- 提取公共逻辑
模板 3.3:AI 辅助 Commit 消息生成
📋
请分析以下 git diff,生成 conventional commit 消息:
## Diff 内容
```
[粘贴 git diff --staged 或 git diff 的输出]
```
## 要求
- 遵循 Conventional Commits 格式:type(scope): description
- Type: feat/fix/refactor/docs/test/chore/perf
- 正文列出主要变更点(每行以 - 开头)
- 如果包含破坏性变更,添加 BREAKING CHANGE 说明
🛠️ 实战演练:AI 辅助的 TDD 全流程
场景:实现一个磁盘空间计算工具
RED 阶段:AI 生成测试
import pytest
from disk_utils import DiskCalculator, DiskInfo
class TestDiskCalculator:
def test_parse_size_bytes(self):
"""解析纯字节数"""
assert DiskCalculator.parse_size("1024") == 1024
def test_parse_size_kb(self):
"""解析 KB 单位"""
assert DiskCalculator.parse_size("1K") == 1024
@pytest.mark.parametrize("size_str,expected", [
("1.5G", int(1.5 * 1024**3)),
("2T", 2 * 1024**4),
("100M", 100 * 1024**2),
])
def test_parse_size_various_units(self, size_str, expected):
assert DiskCalculator.parse_size(size_str) == expected
def test_format_size_bytes(self):
"""小文件使用字节显示"""
assert DiskCalculator.format_size(500) == "500 B"
def test_format_size_auto_unit(self):
"""自动选择合适的单位"""
assert DiskCalculator.format_size(2 * 1024**3) == "2.00 GiB"
def test_parse_invalid_format_raises(self):
"""非法格式抛出 ValueError"""
with pytest.raises(ValueError, match="无法解析"):
DiskCalculator.parse_size("not_a_size")
def test_calculate_usage_percent(self):
"""计算磁盘使用率"""
assert DiskCalculator.usage_percent(used=50, total=100) == 50.0
def test_usage_percent_zero_total(self):
"""总量为 0 时返回 0 避免除零错误"""
assert DiskCalculator.usage_percent(used=0, total=0) == 0.0
GREEN 阶段:AI 实现代码
"""磁盘工具模块 — 磁盘空间计算与格式化。"""
import re
from dataclasses import dataclass
@dataclass
class DiskInfo:
"""磁盘信息数据类。"""
device: str
mount_point: str
total_bytes: int
used_bytes: int
filesystem: str
class DiskCalculator:
"""磁盘空间计算工具。"""
_SIZE_UNITS = {
'B': 1, 'K': 1024, 'M': 1024**2,
'G': 1024**3, 'T': 1024**4, 'P': 1024**5,
}
_SIZE_PATTERN = re.compile(
r'^([\d.]+)\s*([BKMGTP])?$', re.IGNORECASE
)
@classmethod
def parse_size(cls, size_str: str) -> int:
"""解析人类可读的大小字符串为字节数。
Args:
size_str: 如 "1.5G", "100M", "1024"
Returns:
字节数(整数)
Raises:
ValueError: 如果格式无法解析
"""
match = cls._SIZE_PATTERN.match(size_str.strip())
if not match:
raise ValueError(f"无法解析大小字符串: '{size_str}'")
value = float(match.group(1))
unit = (match.group(2) or 'B').upper()
return int(value * cls._SIZE_UNITS.get(unit, 1))
@classmethod
def format_size(cls, bytes_val: int) -> str:
"""将字节数格式化为人类可读的字符串。
Args:
bytes_val: 字节数
Returns:
格式化字符串,如 "2.50 GiB"
"""
if bytes_val < 1024:
return f"{bytes_val} B"
for unit in ['KiB', 'MiB', 'GiB', 'TiB', 'PiB']:
bytes_val /= 1024
if bytes_val < 1024:
return f"{bytes_val:.2f} {unit}"
return f"{bytes_val:.2f} PiB"
@staticmethod
def usage_percent(used: int, total: int) -> float:
"""计算使用百分比,安全处理除零。
Args:
used: 已使用字节数
total: 总字节数
Returns:
使用百分比 (0.0 - 100.0)
"""
if total == 0:
return 0.0
return round((used / total) * 100, 2)
REFACTOR 阶段:优化建议
- ✅ 所有测试通过
- �� 可优化:format_size 可改用 while 循环避免 if-else 链
- ⚠️ 可优化:正则编译为类变量,避免每次调用重新编译
- 💡 扩展建议:添加 df/du 命令输出解析,直接获取真实磁盘信息
⚠️ 常见坑点与避坑指南
🕳️ 坑 1:CLAUDE.md 写成"小说"
CLAUDE.md 太长会消耗宝贵的上下文窗口。控制在 500-1500 词,只记录经常需要 AI 知道的约定和上下文。API 文档和详细设计应放在单独的 docs/ 目录中,需要时再引用。
🕳️ 坑 2:一次性修改太多文件
超过 5 个文件的修改容易出错。每次编辑控制在 1-3 个文件,完成后立即运行相关测试验证,然后再继续。
🕳️ 坑 3:忽略 AI 运行命令的结果
AI 执行测试后,必须阅读输出。测试可能通过了但只是表面上通过(如漏测的边界情况)。关键是让人审查测试输出的含义而非仅仅看通过/失败状态。
📝 本章小结
- Claude Code 的四大能力(读取、编辑、执行、搜索)形成完整开发闭环
- CLAUDE.md 是项目 AI 编程效率的倍增器,值得精心维护
- 跨文件编辑遵循"搜索 → 规划 → 逐文件修改 → 全局验证"流程
- TDD + AI = 测试先写(AI 生成)→ 实现(AI 生成)→ 重构(AI 建议 + 人决策)
- AI 生成的 commit message 和 PR 描述能显著提升团队协作效率
🤔 思考练习
- 为你当前正在做的项目编写一份 CLAUDE.md(控制在 1000 词以内),然后观察 AI 的回答质量变化。
- 选择一个你熟悉的小功能(如字符串工具库),完整走一遍 TDD 三阶段(RED → GREEN → REFACTOR),每个阶段都用 AI 生成。
- 用 git log 找到最近 5 个 commit,让 AI 根据 diff 重新生成 commit message,对比原始版本。