Claude Code 场景最佳实践：不同开发场景的最优使用方法（第六篇）

发表于 分类于 ， ， ， 阅读次数： 本文字数： 6.7k 阅读时长 ≈ 25 分钟
深度解析Claude Code在前端开发、后端API、数据科学、Bug调试、代码重构、全栈项目等10大开发场景中的最佳实践。提供可直接复用的提示词模板、工作流配置和CLAUDE.md示例，覆盖从需求分析到上线部署的完整开发周期。

Claude Code 场景最佳实践：不同开发场景的最优使用方法（第六篇）

系列文章导航

引言：场景决定方法，方法决定效率

同样一把锤子，木匠和雕塑家用起来差异巨大。Claude Code 也一样——知道”能用”只是起点，知道”在什么场景下怎么用”才是真正提效的关键。

本文聚焦 10 大常见开发场景，每个场景都包含：

  • 该场景的 专属 CLAUDE.md 配置
  • 推荐的工作流步骤
  • 可直接复用的提示词模板
  • 常见踩坑和规避方法

场景一：前端组件开发（Vue/React）

工作流：需求 → 组件 → 测试 → 文档

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 第一步：初始化前端项目记忆
/init

# 第二步：描述组件需求（Plan 模式审批计划）
Shift+Tab → Plan 模式
> 创建一个用户头像上传组件：
  - 支持拖拽和点击两种上传方式
  - 上传前预览，支持裁剪（圆形/方形切换）
  - 文件大小限制 5MB，仅支持 jpg/png/webp
  - 上传进度条
  - 使用 Vue 3 + TypeScript + Vant 组件库

# 第三步：审批计划，切换 Auto 模式执行
Shift+Tab → Auto 模式

# 第四步：实现完成后，审查修改
/diff

前端开发 CLAUDE.md 模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# 前端项目配置

## 技术栈
- Vue 3.5 + TypeScript 5 + Vite 5
- Pinia（状态管理）+ Vue Router 4
- Vant 4（移动端）/ Element Plus（PC端）
- TailwindCSS 4

## 组件规范
- 文件命名：PascalCase（如 UserAvatar.vue）
- Props 必须定义类型（TypeScript interface）
- 事件命名：camelCase（如 onUploadSuccess）
- 样式：优先使用 TailwindCSS，复杂样式用 scoped CSS

## 目录约定
components/
├── common/    # 全局通用组件
├── business/  # 业务组件（与特定业务强相关）
└── layout/    # 布局组件

## API 调用
- 统一使用 src/api/ 目录下的封装函数
- 不要直接调用 axios，通过 src/utils/request.ts
- 接口返回格式：{ code: number, data: T, message: string }

## 禁止
- 禁止使用 any 类型
- 禁止在 template 中写复杂逻辑
- 禁止 v-html（XSS 风险）

高效提示词模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 创建新组件
创建 [组件名] 组件：
功能：[功能描述]
Props：[prop名]: [类型] - [说明]
Emits：[事件名] - [触发时机]
特殊要求：[特殊约束]
参考组件：[类似组件路径，让AI参考代码风格]

# 修复样式问题
[组件名] 在 [设备/浏览器] 上出现 [问题描述]。
当前代码：[代码片段]
期望效果：[描述或截图]
请修复这个样式问题。

# 组件重构
将 [组件路径] 从 Options API 重构为 Composition API：
- 保持所有功能完全一致
- 提取可复用逻辑到 composables
- 改进 TypeScript 类型定义

常见踩坑

1
2
3
4
5
6
7
8
❌ 踩坑：AI 生成的组件没有遵循项目样式规范
✅ 规避：在 CLAUDE.md 中明确样式规范，或在提示词中附加 "参考 src/components/UserCard.vue 的代码风格"

❌ 踩坑：生成了不需要的依赖包
✅ 规避：在 CLAUDE.md 中列出允许使用的依赖，并注明"不引入新依赖"

❌ 踩坑：TypeScript 类型不够严格
✅ 规避：在提示词中明确要求 "严格的 TypeScript 类型，不使用 any"

场景二：后端 API 开发

工作流：接口设计 → 实现 → 测试 → 文档

后端 API 开发最怕的是”先实现后设计”——等接口写好了才发现数据模型有问题，返工成本极高。Claude Code 在这里最大的价值是驱动 API 优先设计：在写任何代码之前，先让 AI 生成接口规范和数据库模型，人工确认无误后再动手实现。这种方式不仅减少返工，还能在早期发现潜在的设计缺陷。

推荐使用 Plan 模式：后端 API 往往涉及数据库操作，先确认方案再执行，避免误操作。

1
2
3
4
5
6
7
8
9
10
11
12
13
# 第一步：用 Plan 模式设计接口方案
> think：设计用户管理模块的 REST API：
  - 用户的 CRUD 操作
  - 分页查询（支持按名称/邮箱搜索）
  - 角色权限控制（管理员/普通用户）
  - 技术栈：Node.js + Express + PostgreSQL + Prisma ORM
  先给出数据库模型设计和接口规范，我确认后再开始实现。

# 第二步：审批设计方案
# 第三步：切换到 Auto 模式完成实现

# 第四步：生成接口文档
> 根据已实现的接口，生成 OpenAPI 3.0 格式的接口文档

后端开发 CLAUDE.md 模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
# 后端项目配置

## 技术栈
- Node.js 20 + TypeScript 5
- Express 4 + Zod（参数验证）
- Prisma ORM + PostgreSQL 15
- Redis（缓存/会话）
- Jest（单元测试）

## 项目结构
src/
├── routes/      # 路由定义（RESTful 风格）
├── controllers/ # 控制器（只处理 HTTP 逻辑）
├── services/    # 业务逻辑层
├── models/      # Prisma 模型（在 schema.prisma）
├── middleware/  # 中间件
└── utils/       # 工具函数

## 开发规范
- 严格分层：route → controller → service → model
- 所有参数用 Zod 验证，不信任任何用户输入
- 错误统一通过 middleware/errorHandler.ts 处理
- 敏感操作必须记录审计日志

## 响应格式
{
  "code": 0,        // 0=成功，非0=失败
  "data": {},       // 业务数据
  "message": ""     // 描述信息
}

## 安全要求
- SQL 查询必须通过 Prisma（防 SQL 注入）
- 密码必须用 bcrypt 哈希（rounds=12）
- 接口必须验证 JWT token（除白名单路由）
- 文件上传限制类型和大小

高效提示词模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 实现 CRUD 接口
实现 [资源名] 的完整 CRUD 接口：
- GET /api/[资源名]s：分页列表（支持 page, limit, [搜索字段] 参数）
- GET /api/[资源名]s/:id：详情
- POST /api/[资源名]s：创建
- PUT /api/[资源名]s/:id：更新
- DELETE /api/[资源名]s/:id：删除

字段：[字段名]: [类型] - [约束条件]
特殊逻辑：[业务规则]
包含：参数验证、错误处理、单元测试

# 数据库迁移
为 [模型名] 添加/修改字段：
变更：[字段名] [类型] [约束]
生成 Prisma migration，不要破坏现有数据。

# 性能优化
[接口路径] 在高并发下响应慢（平均 [X]ms），
数据量：[量级]，查询条件：[条件]
请分析原因并给出优化方案（包括索引优化、缓存策略等）

常见踩坑

1
2
3
4
5
6
7
8
❌ 踩坑：AI 写的 SQL 没有考虑 SQL 注入
✅ 规避：在 CLAUDE.md 强制要求使用 ORM，或在提示词中声明

❌ 踩坑：密码/密钥被硬编码到代码中
✅ 规避：在 CLAUDE.md 中明确 "所有敏感配置从环境变量读取"

❌ 踩坑：缺少输入验证，直接使用 req.body
✅ 规避：指定使用 Zod/Joi 等验证库

场景三：Bug 调试与修复

Bug 调试是 Claude Code 表现最出色的场景之一，但也是最容易陷入”AI 幻觉漩涡”的场景。很多人在遇到 Bug 时习惯只把错误信息贴给 AI，期望得到一个”复制粘贴即可解决”的答案。但实际上，上下文越完整，AI 的诊断就越准确。提供触发条件、已排查的方向、相关代码片段，能把调试效率提升数倍，也能有效避免 AI 给出似是而非的错误建议。

正确的调试工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# 第一步：提供完整的问题上下文（不要只粘贴错误信息）
> 遇到了以下问题：

错误信息：
TypeError: Cannot read properties of undefined (reading 'map')
  at UserList.vue:45

触发条件：
- 用户列表页面首次加载时必现
- 刷新页面偶现
- 操作步骤：进入 /users 路由

相关代码：[粘贴 UserList.vue 第 40-60 行]
相关状态：[粘贴 store/user.ts]

我已经尝试过：
- 检查了 API 返回格式，看起来正常
- 添加了空值判断 if (users.value)，但还是报错

# 第二步：AI 给出分析后，如果不确定，让它"think"
> think harder：你的分析有道理，但能不能再深入分析一下
  为什么只在首次加载时必现，刷新偶现？

# 第三步：修复后立即测试，不要连续修改多个问题
# 第四步：修复确认后，让 AI 补充防御性代码和测试
> 问题已修复。请：
  1. 为这个修复添加单元测试
  2. 检查项目中是否有类似的风险点

AI 幻觉识别与处理

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 识别幻觉的信号
- AI 建议修改的代码越来越多，但问题还是没解决
- 开始建议修改与报错位置无关的代码
- 给出的解释前后矛盾
- 建议"先临时这样处理"的 hack 方案

# 正确处理方式
/clear                  # 清除当前对话，重新开始
git reset --hard        # 回滚所有修改

# 重新开始时，提供负面清单
> 遇到以下问题：[错误信息]
  注意：以下方案我已经验证过是无效的，请勿再次建议：
  1. 修改 UserList.vue 第 45 行的空值判断
  2. 调整 API 请求时序
  请从其他角度分析根本原因。

调试提示词模板

1
2
3
4
# 标准 Bug 报告格式
问题描述：[一句话描述]

错误信息：

[完整的错误堆栈]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

复现步骤：
1. [步骤1]
2. [步骤2]
3. [触发条件]

期望行为：[应该发生什么]
实际行为：[实际发生什么]

相关代码：[文件路径或代码片段]

已排除的可能性：
- [原因1]
- [原因2]

# 性能 Bug
[功能]在[条件]下性能异常：
- 当前耗时：[X]ms/s
- 期望耗时：[Y]ms/s
- 数据规模：[描述]
- Profiler 输出：[如有]
请分析瓶颈并给出优化方案。

场景四：代码重构

重构是 Claude Code 最能发挥”大上下文”优势的场景——它能同时理解多个文件的关系并保持一致性。很多开发者害怕重构，因为在复杂的代码库中，一个改动可能牵一发而动全身。Claude Code 的做法是：先分析、再计划、再分步执行，每一步都有测试验证，把这个高风险操作变得可控、可预期。记住：重构前一定要先 commit，给自己留好退路。

重构工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 重构前：建立安全网
git add . && git commit -m "chore: before refactor checkpoint"

# 第一步：让 AI 分析现状（不要立即开始修改）
> 分析 src/utils/auth.js 的代码质量，列出主要问题和重构建议，
  暂时不要修改代码。

# 第二步：审查分析结果，明确重构范围
# 第三步：分步执行重构（不要一次重构太多）
> 按照你的建议，先重构第一个问题：[具体问题]
  要求：
  - 保持功能完全一致，所有现有测试必须通过
  - 每次只重构一个关注点
  - 完成后说明改动了什么

# 第四步：验证重构结果
> 运行测试：npm test
# 如果测试通过，继续下一个重构点

常见重构场景与提示词

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
# 消除重复代码
以下几个文件有重复的 [功能] 逻辑：
- src/[file1] 第 [X] 行
- src/[file2] 第 [Y] 行
- src/[file3] 第 [Z] 行

提取为公共函数/Hook，放到 src/utils/[name].ts，
所有引用处同步更新。

# 改善函数过长
[文件路径] 中的 [函数名] 函数有 [X] 行，
需要拆分为更小的函数，每个函数只做一件事。
拆分原则：按业务步骤划分，而非技术层次。

# 添加 TypeScript 类型
将 [文件路径] 从 JavaScript 迁移到 TypeScript：
- 为所有函数参数和返回值添加类型
- 为所有对象定义 interface
- 避免使用 any，尽量使用精确类型

# 改善错误处理
[文件路径] 中缺乏错误处理，请：
1. 在所有可能失败的操作添加 try/catch
2. 定义明确的错误类型（继承 Error 类）
3. 确保错误信息对调试有帮助
4. 不要吞掉错误（catch 里不能为空）

大规模重构策略

1
2
3
4
5
6
7
8
9
# 处理大型项目重构（如整个目录的 API 版本升级）
> think：我需要将 src/api/ 目录下所有接口调用从
  旧版 API（/api/v1/）迁移到新版（/api/v2/），
  主要变更是：
  1. 认证方式从 cookie 改为 Bearer token
  2. 响应格式从 { status, result } 改为 { code, data }
  
  请先列出所有需要修改的文件和修改点，
  再按模块逐一执行迁移，每个模块完成后暂停等我确认。

场景五：数据科学与机器学习

数据科学项目的特殊挑战在于可复现性和实验追踪。相同的代码在不同环境、不同时间运行，结果可能完全不同。Claude Code 在这里的价值不仅是帮你写分析代码，更重要的是帮你建立规范的项目结构，确保每个实验步骤都有记录，每个结果都可以溯源。对于数据工程师来说，把 CLAUDE.md 配置成要求 random_state=42 和 MLflow 记录，可以从源头上杜绝”在我电脑上能复现”的尴尬。

数据处理工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 数据分析阶段
> 分析 data/user_behavior.csv：
  1. 基本统计信息（行数、列数、数据类型）
  2. 缺失值分布
  3. 异常值检测
  4. 关键特征的分布可视化
  生成 Python 脚本，使用 pandas + matplotlib

# 特征工程
> 基于探索性分析的结果，设计特征工程流程：
  目标变量：[列名]
  候选特征：[列名列表]
  已知领域知识：[业务规则]
  
  要求：
  - 处理类别型变量（Label Encoding / One-Hot）
  - 数值特征标准化
  - 生成交叉特征
  - 可复现的 sklearn Pipeline

数据科学 CLAUDE.md 模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 数据科学项目配置

## 环境
- Python 3.11 + Jupyter Lab
- pandas 2.x + numpy + scikit-learn
- matplotlib + seaborn（可视化）
- MLflow（实验追踪）

## 项目结构
data/
├── raw/         # 原始数据（只读，不要修改）
├── processed/   # 处理后数据
└── output/      # 模型输出

notebooks/       # 探索性分析
src/
├── data/        # 数据处理脚本
├── features/    # 特征工程
├── models/      # 模型定义和训练
└── evaluation/  # 评估脚本

## 代码规范
- 所有随机操作设置 random_state=42
- 数据处理必须可复现（不做原地修改）
- 模型实验用 MLflow 记录超参数和指标
- Notebook 按目的命名：01_eda.ipynb, 02_feature.ipynb

## 数据规范
- 原始数据不可修改，只读
- 所有中间数据保存到 data/processed/
- 日志必须记录数据处理的每一步变更

常用 ML 提示词模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
# 模型选型
任务类型：[分类/回归/聚类]
数据规模：[样本数] x [特征数]
已知特点：[类别不平衡/高维稀疏/时序数据]

请推荐 3 个候选模型，说明各自的适用理由和预期性能，
并给出基线实现代码（使用 sklearn Pipeline）。

# 超参数调优
已有基线模型：[模型代码]
当前 CV 得分：[指标]: [值]
计算资源：[CPU核数/时间限制]

使用 Optuna 设计超参数搜索空间和目标函数，
目标提升 [指标] 到 [目标值]。

# 特征重要性分析
训练好的模型：[模型路径/代码]
请：
1. 输出 Top 20 重要特征（含可视化）
2. 分析特征间的相关性
3. 提出可以移除的冗余特征（减少过拟合风险）

场景六：全栈新项目搭建

从零搭建一个新项目，是 Claude Code 效率最显著的场景。没有历史包袱，没有存量代码的约束，你可以用最理想的方式描述需求，让 AI 生成一个完整的项目骨架。关键技巧是：先充分对话再动手写代码。许多人上来就让 AI 写代码，结果写到一半发现架构选型有问题，大量返工。正确的做法是花 10-15 分钟与 AI 讨论技术方案，确认 ER 图、目录结构、关键接口设计，然后再逐模块实施。

脚手架工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
# 第一步：充分描述需求
> think harder：我要开发一个团队任务管理应用，类似 Trello：
  功能：
  - 项目/看板/卡片三级结构
  - 成员邀请和权限管理（Owner/Editor/Viewer）
  - 实时协作（WebSocket）
  - 文件附件上传（最大 50MB）
  
  技术约束：
  - 前端：Vue 3 + TypeScript
  - 后端：Node.js + Fastify
  - 数据库：PostgreSQL + Prisma
  - 实时：Socket.io
  - 部署：Docker
  
  请给出完整的技术架构方案，包括：
  1. 数据库 ER 图
  2. 前后端目录结构
  3. 关键接口设计
  4. 实时数据同步策略
  
  方案确认后我会开始实施。

# 第二步：确认方案后，分模块实施
> 开始实施。先完成项目骨架搭建：
  - 初始化前后端项目结构
  - 配置 TypeScript、ESLint、Prettier
  - 设置 Docker Compose（前端+后端+PostgreSQL+Redis）
  - 完成用户认证模块（注册/登录/JWT）

# 第三步：按模块迭代，每个模块完成后验证

新项目 CLAUDE.md 初始模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# [项目名] - 项目配置

## 项目概述
[一句话描述：做什么、给谁用]

## 技术栈
前端：[框架 + 版本]
后端：[框架 + 版本]
数据库：[DB + ORM]
部署：[方式]

## 核心业务规则
1. [最重要的业务规则]
2. [权限/安全要求]
3. [特殊约束]

## 开发状态
- [x] 项目骨架
- [x] 用户认证
- [ ] 核心功能模块
- [ ] 测试
- [ ] 部署配置

## 参考资料
- 产品文档：[链接]
- 设计稿：[链接]
- API 文档：[链接]

场景七：代码审查与质量提升

代码审查是工程质量的最后一道防线，但人工 review 有两个明显的局限：精力有限（容易漏掉细节）和主观偏见（习惯于自己的风格）。将 Claude Code 引入代码审查流程，可以弥补这两个缺陷。AI 不会因为疲劳而降低标准，也不会因为人际关系而对问题视而不见。特别是安全漏洞的排查，AI 能系统性地检查 OWASP Top 10 中的每一个类别，比人工审查更全面、更稳定。

自动化代码审查工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 审查 PR 改动
git diff origin/main...HEAD | claude -p "
对以下代码变更进行审查：
1. 潜在的 Bug 和安全问题（高优先级）
2. 性能问题
3. 代码可读性和规范
4. 是否有遗漏的边界情况
5. 测试覆盖是否充分

请按优先级排列问题，高优先级必须修改，其他建议性修改。
"

# 批量审查目录
claude -p "
对 src/api/ 目录进行安全审查，重点检查：
1. SQL 注入风险
2. 未经验证的用户输入
3. 权限绕过可能
4. 敏感数据泄露（日志、响应体）
给出每个风险点的文件位置、风险等级和修复建议。
" --include "src/api/**/*.ts"

代码质量审查提示词

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# 安全审查
对 [文件/目录] 进行 OWASP Top 10 安全审查：
- 注入攻击（SQL/XSS/CSRF）
- 认证和授权问题
- 敏感数据暴露
- 安全配置错误

对每个问题给出：风险等级、触发条件、修复代码示例

# 性能审查
分析 [文件/目录] 的性能问题：
- N+1 查询问题
- 不必要的重新渲染
- 内存泄漏风险
- 可以缓存的重复计算

给出优化前后的对比代码

# 可维护性审查
评估 [文件] 的可维护性（1-10分），从以下维度：
1. 函数长度和复杂度（圈复杂度）
2. 代码重复程度
3. 注释质量
4. 命名清晰度
5. 单一职责原则遵守情况

给出评分依据和具体改进建议

场景八：文档生成与维护

文档是技术债的重灾区——代码更新了但文档忘记更新，是团队中最常见的痛点之一。Claude Code 的打印模式（-p）非常适合接入文档生成工作流：只要代码变了，就可以通过一行命令重新生成对应文档。将这个命令放进 git hook 或 CI 流程，就实现了”代码即文档”的理想状态，彻底告别手动维护文档的烦恼。

自动化文档工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 生成 API 文档
claude -p "
根据 src/routes/ 目录下的路由定义和控制器代码，
生成 OpenAPI 3.0 格式的 API 文档（YAML格式）。
包含：接口描述、请求参数、响应示例、错误码说明。
" > docs/api/openapi.yaml

# 生成 README
claude -p "
根据项目代码结构、package.json 和现有注释，
生成专业的 README.md，包含：
1. 项目简介和特性亮点
2. 技术栈说明
3. 快速开始（安装、配置、运行）
4. 核心功能文档
5. 贡献指南
6. License 信息
" > README.md

# 更新变更日志
git log v1.0.0..HEAD --pretty=format:"%s" | claude -p "
根据以下 commit messages，生成规范的 CHANGELOG.md 条目。
格式遵循 Keep a Changelog 规范，按类型分组：Added/Changed/Deprecated/Removed/Fixed/Security
" >> CHANGELOG.md

场景九：遗留系统理解与维护

接手别人的代码库是很多开发者的痛苦经历，Claude Code 可以大幅降低理解成本。遗留系统最难处理的不是技术问题，而是”知识的缺失”——为什么当初要这么设计？这个奇怪的逻辑是在应对什么场景？关键决策背后的业务背景是什么？Claude Code 能通过分析代码本身，推断出很多隐藏的业务规则，帮助你更快地建立全局认知，而不是在黑暗中摸索。

代码库快速理解工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 第一步：让 AI 生成项目地图
> 分析整个项目结构，生成一份"新人入职指南"，包括：
  1. 项目架构图（文字版）
  2. 核心业务流程说明（3-5个最重要的流程）
  3. 关键文件和模块说明
  4. 常见操作指南（如何添加新功能、如何调试等）
  5. 代码中的坑和注意事项（如果能发现的话）
  
  输出到 docs/ARCHITECTURE.md

# 第二步：理解特定功能
> 帮我梳理用户下单的完整调用链，从前端点击"立即购买"按钮
  到订单落库的全过程，列出每一步涉及的文件和函数。

# 第三步：定位需要修改的位置
> 我需要在用户下单时增加一个库存检查，
  应该在哪个文件的哪个位置添加这个逻辑？
  请给出修改建议，不要直接修改。

遗留代码改造提示词

1
2
3
4
5
6
7
8
9
10
# 理解复杂函数
解释 [文件路径] 第 [X-Y] 行的代码做了什么，
特别是这段逻辑：[代码片段]
用业务语言而非技术语言描述，并指出任何可疑的地方。

# 安全添加功能到遗留代码
在不破坏现有功能的前提下，在 [文件路径] 中添加 [功能]：
1. 先分析当前代码，确认影响范围
2. 给出最小侵入式的改动方案
3. 实施前告知哪些测试需要更新

场景十：自动化脚本与工具开发

运维脚本和自动化工具往往是”积累的智慧”——每个团队都有一堆各自为政的脚本，功能重叠、文档缺失、只有原作者知道怎么用。Claude Code 在编写脚本方面表现出色，特别是涉及复杂的错误处理、日志记录、幂等性设计这些”脚本写好比写难”的地方。告诉 AI 你的目标环境和约束条件，它会生成考虑周全、可以直接投入生产的脚本。

DevOps 脚本开发

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# 生成部署脚本
> 编写一个 Docker 部署脚本（deploy.sh），功能：
  - 从 git 拉取最新代码
  - 构建 Docker 镜像（附加 commit SHA 作为 tag）
  - 健康检查通过后才切换流量
  - 失败时自动回滚
  - 部署日志记录到 /var/log/deploy.log
  - 支持 --dry-run 参数（只打印不执行）
  
  目标环境：Ubuntu 22.04 + Docker Compose

# 生成数据迁移脚本
> 编写数据迁移脚本，将 MongoDB 的 users 集合
  迁移到 PostgreSQL 的 users 表：
  字段映射：[MongoDB字段] → [PostgreSQL字段]
  特殊处理：[嵌套字段展开规则]
  要求：
  - 支持断点续传（记录迁移进度）
  - 迁移前备份数据
  - 提供验证步骤（确认数据一致性）
  - 错误时记录失败记录，不中断整体迁移

测试自动化

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
# 生成测试数据工厂
> 为 src/models/ 目录下的所有模型创建测试数据工厂（factory）：
  使用 Faker.js 生成真实感数据
  每个工厂支持：
  - create()：创建单条记录
  - createMany(n)：批量创建
  - build()：只生成对象不入库
  - createWithRelations()：附带关联数据
  符合项目中 Prisma 的数据约束

# 端到端测试
> 使用 Playwright 为用户注册/登录流程编写 E2E 测试：
  覆盖场景：
  - 正常注册并登录
  - 邮箱格式错误
  - 密码强度不足
  - 邮箱已注册
  - 密码错误（连续3次后锁定）
  使用 Page Object 模式，方便维护

通用最佳实践总结

不同场景的模型选择建议

场景 推荐模型 工作模式 理由
架构设计/技术选型 Opus Plan 需要深度推理
日常功能开发 Sonnet Auto 性价比最优
Bug 修复 Sonnet + think Default 需要审慎确认
大规模重构 Opus Plan 影响面广需谨慎
批量文档生成 Haiku Auto 简单重复任务
遗留代码理解 Sonnet - 上下文理解为主
数据分析脚本 Sonnet Auto 中等复杂度

五个能让效率翻倍的习惯

  1. 先计划再执行：复杂任务用 Plan 模式，确认方案后再 Auto 执行
  2. 善用 /diff 审查：每次 AI 完成一批修改后，先 /diff 再接受
  3. 勤 commit 保存进度：每完成一个小功能点就 commit，方便回滚
  4. 上下文及时清理：切换任务前用 /clear，保持 AI 的聚焦度
  5. 负面清单备忘：遇到 AI 走弯路时，将错误方向写入 CLAUDE.md 的”禁止”区

结语：AI 是放大器，不是替代者

Claude Code 在不同场景中表现出的差异，本质上是对”如何向 AI 提问”这一命题的检验。同样的工具，在一个能清晰描述需求、善用上下文管理、及时审查结果的开发者手中，生产力可以提升 5-10 倍；而在另一个只会”帮我写代码”的开发者手中，可能只提升 20%。

本系列六篇文章到此就完整了。如果你是从这篇开始读的，建议按照第一篇到第六篇的顺序系统学习，能获得最佳的学习效果。

📚 完整系列文章