---
title: "Claude 的应用场景"
description: "装好之后先做哪件事：按「改动能落文件、结果能验证」两条标准筛选任务，覆盖开发、排查、重构、测试、文档与自动化六类场景，并给出可直接改用的提示词。"
updated: 2026-11-13
canonical: https://docai.cc/learn/claude-use-cases/
markdown_mirror: https://docai.cc/learn/claude-use-cases.md
---
## 装好之后，先挑一件真活

装好 Claude Code 之后，第一次打开输入框，多数人都会愣住：问点什么好？别把它当搜索引擎。它的长处是把一件有边界的工程活从头做到尾：读、改、验证。

筛选标准只有两条：改动能落到文件吗？做完能用测试或命令判定吗？两条都行，就可以交给它。只能聊出观点、落不了地的任务，网页对话更划算。

## 新功能：把范围、样例和验收写进去

最顺手的场景，是那种要同时动路由、服务层、数据访问和测试的功能。你描述目标，它去找现有写法，按项目风格补齐。

一条可直接改用的提示词：

```text
实现用户头像上传：
- 只收 JPG/PNG，单文件不超过 5 MB
- 存到对象存储，返回可访问的 URL
- 参考 src/services/upload.ts 里现有的上传写法
- 补上失败路径的单元测试，全部通过再交
```

注意三个细节：给了参考文件，它就不会另起一套风格；给了限制，它就不会自行放宽；给了验收方式，你就知道该看什么。缺了这些，它会按自己的理解发挥，改出来的东西未必是你想要的。

## 排查与重构：先给证据，再划边界

报错跨了好几层时，人容易在错误的方向上打转。它的优势是能顺着调用链一路读下去，把前端、服务、数据库配置放在一起看。

```text
/api/orders 在并发请求下偶尔返回 500，日志里是连接池超时。
先读路由、服务层和连接池配置，列出可能的根因和验证方法。
确认原因后再改，改完跑相关测试把结果贴出来。
```

重构同理。最怕改一处漏一处，所以先划边界：

```text
把 utils/helpers.js 里超过 50 行的函数拆成独立模块，
对外导出保持不变，不顺手改逻辑，完成后跑测试。
```

两句都用了同一个套路：先只读分析，你确认后再批准动手。它有能力一口气改完，但方向错了，改得越快损失越大。

## 测试、审查与文档：枯燥但标准清楚

这三类活有个共同点：好不好，有客观标准。

补测试，把要覆盖的路径列全：

```text
为支付服务补单元测试，覆盖成功、余额不足、网络超时三种情况，
沿用项目现有测试框架和命名风格，不要改实现。
```

做审查，先定维度，别只说「看看有没有问题」：

```text
审查 src/auth/ 最近一次改动，重点看：
1. 有没有注入风险
2. 密钥和令牌的处理是否安全
3. 报错信息会不会带出敏感数据
```

写文档，范围越小越好用：「给公开接口补注释，参数、返回值、可能抛出的错误都要写」比「完善文档」有效得多。这些活技术难度不高，却最容易被拖延，正适合交出去。

## 接手陌生项目：先让它画地图

换到一个没有文档的老项目，第一件事不是改代码，而是把结构摸出来。这一步适合只读，别一上来就让它动手：

```text
只读，不要改任何文件。回答四个问题：
1. 一次请求从入口到读写数据库，经过哪些文件
2. 模块之间谁依赖谁，有没有循环依赖
3. 登录和权限在哪一层校验
4. 新增一个接口需要动哪几个地方
每个结论后面附文件路径和关键行号，找不到就写「未找到」。
```

拿到地图再挑第一个任务：改动面小、有测试覆盖、失败不影响线上。地图里标出的扩展点通常就是最安全的入口。这套读法可以配合[代码阅读理解](/learn/basic-code-comprehension/)一起练。

## 场景与验收方式对照

八类场景的输入和验收其实高度相似，可以压成一张表，接活前先对一遍：

| 场景 | 你给的输入 | 怎么判完成 |
|---|---|---|
| 新功能 | 范围、参考文件、边界条件 | 测试通过，主流程手动走一遍 |
| 排查 | 报错原文、复现步骤、相关日志 | 原来能复现的用例不再触发 |
| 重构 | 不许动什么、导出接口不变 | 测试全绿，接口签名一致 |
| 审查 | 关注维度（安全、性能、边界） | 每条发现能指到具体文件和行 |
| 测试 | 要覆盖的路径清单 | 用例清单与覆盖路径对得上 |
| 文档 | 文件范围与读者 | 参数、返回值、异常齐全 |
| 脚本 | 输入输出格式、运行环境 | 同一条命令重复跑结果一致 |
| 读代码 | 想弄清的问题 | 能画出调用链并指出入口 |

表里最右一列是重点：说不清怎么验收的场景，先别交出去，因为你自己也不知道做完该看什么。

## 把一次对话变成脚本

同样的检查跑第二次时，就别再手打了。非交互模式让它可以出现在管道和流水线里：

```bash
# 总结这次提交改了什么、风险在哪
git diff HEAD~1 | claude -p "总结这次提交的改动，标出可能的风险点"

# 输出结构化结果，方便后续处理
claude -p "检查这次改动有没有明显安全问题，按 JSON 输出" --output-format json

# 批量处理多份文档
find docs -name "*.md" | xargs -I{} claude -p "检查 {} 里有没有过期链接，只列出问题"
```

参数名和输出格式会随版本调整，写进脚本前先跑一次 `claude --help` 核对。批量那条注意别让它同时改文件：先只输出问题清单，你抽查几份确认判断靠谱，再放开修改。

这条路径的价值在可重复：同一条命令放进持续集成，每次提交都自动过一遍，不依赖谁记得去点一下。

## 不适合的活，以及第一个任务

有些事别难为它：

- **逐行补全**：编辑器插件响应更快，打断更少；
- **纯视觉调整**：颜色、间距、动效要看效果，回编辑器边看边调更直接；
- **高度敏感的仓库**：它会读项目文件，权限没理清之前不要放进去。

前两条不是能力问题，是交互方式不匹配：补全要的是零延迟，视觉调整要的是所见即所得。第三条是真风险。接上敏感仓库前，先把可访问目录和可执行命令限制在必要范围，能用只读副本练习就别直连线上；具体配置项以当前版本为准。

审查还有个小入口：交互模式里输入 `/help`，能看到当前版本自带哪些命令；有审查命令就用，没有的话把关注维度写进提示词，效果一样。

第一次上手，选一个读多改少的任务，先看它怎么理解项目：

```bash
cd my-project
claude
> 读一遍这个项目：入口在哪、测试怎么跑、最值得改的三个问题是什么。
> 每个问题说明理由和改法。先不要动文件。
```

看完它的回答，你会对它的水平有个底，也知道下一步该给多大的任务。接下来先把环境备齐：[安装前的系统要求与环境配置](/learn/system-requirements-setup/)。