Claude Code 真实任务案例集：从入门到高阶实战
Claude Code 已经从”体验玩具”变成了不少开发者每天打开的第一个工具。但网上大多数教程停留在”帮我写个 Hello World”，真正复杂的项目场景很少有人系统整理。
本文汇集 10 类在实际开发中高频出现的任务案例，每类给出具体 prompt 模板和注意事项，帮你把 Claude Code 的能力用到极限。
一、遗留代码快速摸底
场景：接手一个没有文档的老项目，几万行代码，不知道从哪下手。
适合 Claude Code 的原因：它可以读取整个仓库上下文，而不是一次只处理一个文件。
Prompt 模板：
请分析这个项目的整体架构：
1. 入口文件在哪里？主要数据流如何？
2. 有哪些核心模块？各自的职责是什么？
3. 依赖关系中有没有循环依赖或潜在风险？
4. 用 Mermaid 画一张模块依赖图
仓库根目录：<路径>注意事项：
- 对超大仓库（> 50 万行），先限定
--include范围，否则上下文会被稀释 - 生成的 Mermaid 图优先验证核心路径，边缘模块可以后续补充
二、复杂 Bug 定位与修复
场景：线上出现偶发性错误，栈信息不完整，难以复现。
Prompt 模板：
以下是错误日志：
<粘贴错误信息>
相关代码路径：src/services/payment.ts
请：
1. 推断最可能的根本原因（列出 3 个假设，按可能性排序）
2. 针对最高概率的假设，给出验证步骤
3. 如果假设成立，提供修复代码（不要修改无关部分）
4. 说明这个修复会不会引入新的边界条件问题实战技巧：
- 把相关的测试文件一起提供，让 Claude Code 看到历史上测了什么、没测什么
- “按可能性排序”这个约束能让它给出更有判断力的答案，而非罗列所有可能
- 明确说”不要修改无关部分”，避免它顺手重构其他代码
三、单元测试生成
场景：一个核心函数缺乏测试覆盖，需要快速补全。
Prompt 模板：
为 src/utils/price-calculator.ts 中的 calculateDiscountedPrice 函数生成完整单测：
要求：
- 使用项目现有的测试框架（见 package.json）
- 覆盖正常路径、边界值（0、负数、极大值）、异常路径
- 每个测试用 describe + it 结构，注释说明测试意图
- 不要 mock 没必要 mock 的东西
- 生成的测试文件放到 src/utils/__tests__/price-calculator.test.ts容易踩的坑：
- 如果函数有外部依赖（数据库、HTTP），要额外告诉它哪些需要 mock、用什么 mock 库
- 生成后用
npm test -- --coverage跑一次，看覆盖率是否达标，不达标让它补充
四、API 文档自动生成
场景：REST API 或 SDK 缺少文档，需要产出给外部调用方的接口说明。
Prompt 模板：
读取 src/routes/api/ 下所有路由文件，生成 OpenAPI 3.0 规格文档：
- 提取每个路由的 HTTP 方法、路径、请求参数、响应结构
- 错误码从 src/middleware/error-handler.ts 提取
- 认证方式从 src/middleware/auth.ts 提取
- 输出格式：YAML，保存到 docs/openapi.yaml
- 对于有歧义的字段类型，标注 TODO 而非自行推断进阶用法：生成后配合 Swagger UI 或 Redoc 渲染，快速给团队共享一个可交互的文档页面。
五、依赖升级风险评估
场景：npm outdated 显示几十个包有更新，不知道哪些升级安全、哪些有 breaking change。
Prompt 模板：
以下是我的 package.json 依赖列表（当前版本）：
<粘贴列表>
请分析以下几点：
1. 哪些是补丁/安全更新，可以直接升级？
2. 哪些有已知 breaking change，需要检查代码？
3. 重点检查这些包与我们的代码的集成点：express、prisma、zod
4. 给出一个建议的分批升级顺序（按风险从低到高）注意：这类任务 Claude Code 的判断基于其训练数据截止时间，对非常新的包版本可能不准确——用它做初筛，重要包还是要查官方 changelog。
六、代码重构：模块解耦
场景：一个 God Class 或者超长函数需要拆分，但改动面很大，不敢轻易动。
Prompt 模板：
src/services/OrderService.ts 目前有 1200 行，职责混杂。请：
1. 分析当前类承担了哪些不同职责（列出来）
2. 提出一个解耦方案：拆成哪几个类/模块，各自职责是什么
3. 给出第一步的重构代码（只拆出最独立的那部分，不要一次全改）
4. 列出重构后需要更新的调用方（grep 相关引用）
5. 说明如何保证重构不改变现有行为（测试策略）重要原则：让它”只拆出最独立的那部分”——一次性大重构容易翻车，分批来更安全。每次重构后跑完整测试，再继续下一步。
七、性能瓶颈分析
场景：接口响应慢，有 profiling 数据但看不懂哪里是热点。
Prompt 模板：
以下是 Node.js 的 flame graph 数据（或 profiling 输出）：
<粘贴数据>
相关代码：src/services/ReportService.ts
请：
1. 指出最明显的性能瓶颈在哪里
2. 分析是 CPU 密集、I/O 阻塞还是内存问题
3. 给出 2-3 个优化方向，从投入产出比排序
4. 对优化方向 1，给出具体的代码改动建议补充技巧：如果没有 profiling 数据，可以直接提供”慢接口的代码路径”让它推断潜在瓶颈。它对 N+1 查询、同步阻塞 I/O 等常见模式识别效果很好。
八、安全审查
场景：上线前快速过一遍代码，查是否有明显安全漏洞。
Prompt 模板：
对以下文件做安全审查，重点检查：
- SQL 注入 / NoSQL 注入
- XSS（特别是用户输入直接渲染的地方）
- 不安全的反序列化
- 敏感信息硬编码（密钥、密码、token）
- 权限检查缺失
- CORS 配置过宽
文件列表：
- src/routes/user.ts
- src/routes/payment.ts
- src/middleware/auth.ts
对每个发现点，说明：风险等级（高/中/低）、触发条件、修复建议。注意边界：Claude Code 做的是静态分析，不能替代真正的渗透测试。高风险问题发现后应交给专业团队复核。
九、跨语言代码迁移
场景：把一个 Python 脚本迁移成 TypeScript，或把旧版 jQuery 代码迁移成 React。
Prompt 模板：
把以下 Python 脚本迁移为 TypeScript（Node.js 运行时）：
<粘贴原始代码>
要求：
- 保持原有逻辑不变，不要优化算法
- 使用 TypeScript 的类型系统标注所有变量
- 第三方库用 npm 上的等价包（注明包名和版本）
- 对 Python 惯用法无法直接翻译的地方，加注释说明
- 迁移完成后列出需要人工验证的部分常见问题：Python 的生成器、上下文管理器、某些标准库在 JS 生态中没有直接对应，遇到这类情况让它”加注释说明”而非静默替换。
十、CI/CD 流水线配置
场景：从零配置 GitHub Actions，或者优化现有流水线跑得太慢的问题。
Prompt 模板：
为这个 monorepo 项目配置 GitHub Actions CI：
项目结构：
- packages/api（Node.js + TypeScript）
- packages/web（Next.js）
- packages/shared（共享类型）
要求：
- 只有变更的包才跑对应的测试（使用 paths filter）
- 并行跑 api 和 web 的测试
- 构建缓存 node_modules（按 lockfile hash 缓存）
- 主分支 push 后自动部署 api 到 Railway，web 到 Vercel
- 失败时发 Slack 通知（webhook 用 secrets.SLACK_WEBHOOK）关于 Claude Code CI 集成的更多细节，可以参考 Claude Code CI 集成实践。
提升效果的通用原则
经过上面 10 类案例，可以提炼出几条通用的”让 Claude Code 发挥更好”的原则：
| 原则 | 说明 |
|---|---|
| 给约束，不给选项 | ”修改 X” 比 “你觉得应该改 X 还是 Y” 得到更聚焦的答案 |
| 分批次，不一次性 | 大重构/大迁移先做最小切片，验证后再扩大范围 |
| 提供上下文文件 | 告诉它相关的测试文件、依赖文件，不只是目标文件 |
| 要求说明副作用 | ”这个改动会不会影响 X” 可以暴露它没想到的风险 |
| 让它标注不确定性 | ”对有歧义的地方加 TODO”，防止它静默猜测错误 |
关于 API 访问的注意事项
Claude Code 在国内使用需要解决网络和 API 访问问题。如果你在自己的工作流或 IDE 中调用 Claude API，可以参考 Claude Code 国内网络配置指南 和 Claude Code 镜像站配置 了解中转方案的搭建方式。
相关阅读
如果你在使用 Claude Code 过程中遇到 API 访问限制，YoTradeApi 提供稳定的 Claude API 中转服务，支持所有主流 AI 工具的直接接入。