Claude 的应用场景

装好之后，先挑一件真活

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

场景与验收方式对照

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

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

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

把一次对话变成脚本

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

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

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

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

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

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

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

有些事别难为它：

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

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

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

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

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

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