Claude Code十大技能详解：从安装配置到实战应用

最近好几个做后端的朋友跑过来问我同一个问题：Claude Code 现在到底能不能用到生产环境？我的回答一直是——别把它当成“会聊天的终端”，它真正值钱的地方是那一整套能组合起来用的技能。这篇文章我会结合自己这几个月的实际使用体验，把 Claude Code 最推荐的 10 个技能完整拆一遍，从安装配置、模型接入，到日常提效、排错避坑，按一个新手最容易上手的路径写清楚，希望能帮你节省不少摸索时间。

1. 先搞清楚 Claude Code 到底解决什么问题

在我开始数技能之前，有件事必须想明白：Claude Code 不是又一个聊天机器人。它是个跑在终端里的 AI 编程代理，能直接读你的项目文件、执行命令、修改代码、跑测试，像一个坐在你旁边的工程师，而不是一个只能给建议的窗口。

1.1 它不是又一个AI聊天框

很多人第一次用 Claude Code 的时候，会按照 ChatGPT 的习惯去提问：把一段报错贴进去，等它给一段解释。这个用法没错，但远远不是它的全部。Claude Code 真正的核心是“代理”两个字：你给它一个目标，它可以自己决定先看哪个文件、再改哪行代码、最后怎么验证。它会在工作目录里自动调用工具，进行文件搜索、内容读取、命令执行这一整套循环。

我举个最直观的例子。之前我接手一个第三方支付对接模块，代码堆了两年，没人写文档。我让 Claude Code 帮我找出所有调用金额校验函数的位置，它没有先回复我，而是自己执行了 grep，然后逐个打开文件，最终列出一份带上下文的调用清单，还把其中两处疑似忘记校验负数的地方标了出来。这种“先查再说”的交互方式，是普通聊天界面做不到的。

所以结论很简单：如果你把它当作一个会聊天的终端，它只是个“玩具”；如果你把它当作一个能在项目里自主干活的工程师，它就是一套完整的生产力工具，这也是为什么值得专门学它的“技能”。

1.2 为什么值得专门学“技能”

工具能力再强，用的人不会用照样白搭。同样一个 Claude Code，有人让它生成一个带错误处理的完整模块只花了十分钟，有人却折腾一下午还在反复修正几个基础报错。差别不在模型智商，而在使用方式。这里说的“技能”，不是指游戏里那种加成点数，而是一套可以反复组合的工作套路，类似官方文档里提到的 Skills 概念：你通过配置文件或指令模板，告诉模型“在什么场景下，就按什么标准动作执行”。

我自己体会特别深的一点是：Claude Code 属于多轮对话 + 工具调用的形态，上下文窗口再大也有限，怎么让它在正确的轨道上干活，比怎么让它“聪明”更重要。下面这 10 个技能，就是围绕“减少上下文浪费、增加任务闭环、降低人工复核成本”来设计的，全部来自我实际跑过项目的经验，不是纸上谈兵。

2. 安装配置与模型接入：先把地基打牢

在聊技能之前，先把环境搞对。很多新手一上来就卡在安装和模型接入上，后面所有技能都白搭。这一节我会把官方订阅、API、DeepSeek、Ollama 本地模型这几条路都讲清楚，顺带把几个高频报错一次性解决掉。

2.1 安装方式和常见报错

Claude Code 的官方安装方式很简单，只要你的机器上有 Node.js 18 以上版本，直接执行：

npm install -g @anthropic-ai/claude-code

然后运行claude进入交互界面。如果你之前已经装过旧版本，记得用claude --version确认版本号，再执行npm update -g @anthropic-ai/claude-code升级。

Windows 用户最容易踩的是 PowerShell 执行策略的坑，安装时可能出现类似“无法加载文件，因为在此系统上禁止运行脚本”的报错。解决办法是用管理员身份打开 PowerShell，执行：

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

然后重新启动终端。还有更隐性的坑：安装成功后，命令行里输入claude没反应，多半是 npm 全局目录没加到 PATH。运行npm prefix -g查看路径，把对应的 bin 目录加到环境变量里即可。

另外，如果你看到中文乱码，多半是 Windows 控制台代码页的问题。在运行 claude 之前先执行chcp 65001切到 UTF-8，或者直接改用 Windows Terminal，可以省掉很多烦躁。

2.2 模型接入：官方API、DeepSeek、Ollama本地模型

默认情况下，Claude Code 需要登录 Anthropic 账号，用订阅或者是 API Key 方式计费。如果你用的是官网订阅，登录一次即可；如果你是走 API，需要设置环境变量：

export ANTHROPIC_API_KEY=你的key

很多国内开发者会想接 DeepSeek 或者本地 Ollama 模型来跑。这类需求 Claude Code 是支持的，因为它只是通过ANTHROPIC_BASE_URL来切换模型接口。接 DeepSeek 的基本设置是这样的：

export ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic export ANTHROPIC_MODEL=deepseek-chat export ANTHROPIC_API_KEY=你的deepseek key

这里要特别提醒：DeepSeek 的 Anthropic 兼容接口并不保证支持 Claude Code 的全部工具能力，尤其是文件编辑、命令执行这些高频操作，实际体验会有差距。我自己试下来，简单代码解释和测试生成没问题，但复杂重构还是官方 Claude 模型更稳。

如果你只想完全本地跑，可以考虑 Ollama。启动 Ollama 后，设置：

export ANTHROPIC_BASE_URL=http://localhost:11434 export ANTHROPIC_MODEL=qwen2.5-coder:32b export ANTHROPIC_API_KEY=ollama

然后用claude启动。本地模型的好处是数据安全、不计费，但响应速度、代码理解能力都弱不少，只适合做一些低风险的小任务，比如注释补全、单文件脚本编写。别指望本地小模型能完成跨模块重构，那会让你怀疑人生。

2.3 settings.json与省token技巧

Claude Code 启动后会读取项目根目录下的.claude/settings.json，这个文件非常关键。你可以在这里指定默认模型、权限策略、输出格式等。一个典型的配置：

{ "model": "claude-sonnet-4-20250514", "permissions": { "allow": ["Bash(npm run *)", "Read(/*)"], "deny": ["Bash(rm -rf *)", "Bash(git push *)"] }, "outputStyle": "medium" }

outputStyle这个参数很容易被忽略，但它对 token 消耗影响很大。调成compact后，模型回复会更精简，省下不少上下文；反之，如果你希望它一边改代码一边解释，就选verbose。实际项目里，我通常把outputStyle设为compact，只在排错时切回verbose。

关于省 token，我踩过最大的坑是“什么小事都开新会话”。虽然每次开新会话看起来上下文干净，但每次都要重新解释项目背景，基础 token 消耗反而更高。正确做法是把长期不变的信息写进CLAUDE.md，然后在一个会话里持续把任务做完，只在上下文明显膨胀或方向跑偏时再用/clear重置。

3. Claude Code 最推荐的10个技能

接下来是重头戏。这 10 个技能我按“从项目级别到单文件级别、从保守到激进”的顺序排列，每个技能都配套具体操作和我的实操心得。你可以先把它们当清单过一遍，然后在自己的项目里逐项试。

3.1 技能一：用CLAUDE.md建立长期记忆

新手最容易犯的错误，是每开始一个任务都要向 Claude Code 解释一遍项目背景，比如“这是一个 Spring Boot 项目”“测试用 pytest”“构建命令是 npm run build”。这些信息反复出现在多轮对话里，会白白消耗大量 token，还容易让模型在长对话后段忘记关键约束。

正确做法是在项目根目录生成一个CLAUDE.md文件。你可以手动创建，也可以运行/init让 Claude Code 自动扫描项目后生成初稿。一个高质量CLAUDE.md至少应该包含：项目的一句话定位、目录结构说明、常用构建/测试命令、代码风格要求、禁止改动模块。

我通常还会加一段“工作流偏好”，例如“所有前端改动必须在src/pages内进行”“提交信息要求使用 gitmoji 规范”。这样每次新会话启动时，Claude Code 会自动读取这个文件，你不用重复背景，模型也能保持全局认知。实测下来，光这一招就能让长任务的上下文浪费减少 30% 以上。

3.2 技能二：让Claude先搜索再回答

模型会产生幻觉，Claude Code 也一样。尤其在大项目里，如果你直接问“这个订单状态在哪些地方被修改了”，它很可能凭训练记忆写一个模棱两可的答案，而不是真正去看你的代码。所以第二个技能的核心是：不急着回答，先让模型用工具去搜索。

具体操作时，我会在 prompt 里明确要求它先执行搜索，再给结论。比如：

请先 grep 项目里所有的 OrderStatus 赋值位置，打开相关文件确认上下文，然后告诉我哪些地方改了状态，哪些地方可能漏了校验。

Claude Code 会通过工具逐层检索，最后给出的答案通常会附带文件路径和关键行号。对于项目导航，你还可以直接使用内置的/grep、/find命令，按正则或文件名搜索。这个技能熟练之后，一个十万行规模的项目，定位一段逻辑一般不超过两分钟，比我手动翻代码快太多了。

3.3 技能三：把测试覆盖率当成核心KPI

让 Claude Code 写测试可能是它最“惊艳”的场景之一。你不需要把整个文件粘贴给它，只需要告诉它“给src/utils/format.ts补单元测试，函数是formatCurrency，需要考虑负数、千分位、小数精度和非法输入”，它就能自动读取文件、设计用例并生成测试代码。

我常用的做法是在 commit 之前，先让 Claude Code 跑一遍现有测试，然后针对新增模块补测试。比如前面的formatCurrency，我要求它至少覆盖：正常金额、负数、超出精度的浮点数、非数字输入。它生成的 Vitest 测试长这样：

import { describe, it, expect } from 'vitest'; import { formatCurrency } from '../format'; describe('formatCurrency', () => { it('formats normal number with thousands separator', () => { expect(formatCurrency(1234567.89)).toBe('1,234,567.89'); }); it('handles negative values', () => { expect(formatCurrency(-1234.5)).toBe('-1,234.50'); }); it('rounds to 2 decimal places', () => { expect(formatCurrency(0.1 + 0.2)).toBe('0.30'); }); it('throws on invalid input', () => { expect(() => formatCurrency('abc')).toThrow(); }); });

这里要强调一个原则：测试用例仍需要人工 review。AI 生成测试最常见的毛病是“只测快乐路径”，对异常分支覆盖不足。我会在让它写测试时专门加一句“请重点考虑边界条件和异常输入”，测完再自己补两三个反例，防止模型陷入自证循环。

3.4 技能四：用需求描述驱动跨文件改造

第四个技能适合处理跨文件重构，比如把旧的回调式 API 改成 Promise 风格，或者把第三方 SDK 从 V2 升级到 V3。这个场景的难点不是单文件改逻辑，而是多个文件的改动需要保持一致，同时不能影响其他模块。

我的操作模板是：先把改动范围圈出来，再给验收标准。例如：

需求：把 payment 目录下的 request 方法从回调改为 async/await。只允许修改 payment 目录和调用方中显式传入 callback 的文件。改动后必须通过现有测试，不允许改动 order 模块的接口签名。

注意关键词“只允许”和“不允许”，Claude Code 对权限边界比较敏感，你越是明确禁止它动某些文件，它越不会“发挥过头”。如果项目特别大，我还会先让它用技能二搜索所有相关引用，输出一份影响面清单，我确认后再开始改。这套流程下来，跨文件改造的返工率能降低一半以上。

3.5 技能五：让Claude当lint和编译错误的第一道防线

写代码时遇到 import 路径错误、类型不匹配、未定义变量这类低级错误，完全没必要自己一行行看。Claude Code 可以直接帮你跑构建命令，然后把输出结果丢回对话上下文里。

我日常的开发流程是：改完代码后，直接告诉它“运行一下npm run lint和npm run typecheck，如果有错误，列出错误文件并直接修掉，注意不要改动无关代码”。它会执行命令、读取报错、定位文件、修复代码，然后再跑一次命令验证。整个过程不需要我手动复制粘贴错误日志。

这里有个非常重要的权限设置：在settings.json的 permissions 里，我会预先允许Bash(npm run *)、Bash(npx tsc *)这类白名单命令，同时禁用Bash(rm *)等危险操作。这样既能保证自动化，又不会让模型尝试执行风险命令。

3.6 技能六：代码审查不求人

代码审查是个非常适合 Claude Code 的场景，因为它有全局上下文，能串起多个文件的改动，比让模型只看一个 diff 文件更有效。通常我会让 Claude Code 配合 Git 来干活。

做法很简单：先运行git diff HEAD获取本地的全部未提交改动，然后我对它说：

请以资深 reviewer 的视角审查这份 diff。重点关注：并发安全问题、输入校验、资源泄漏、对现有接口的兼容性影响。逐条列出问题并标明严重等级，不要直接改代码。

技能六的关键点是“不要直接改代码”。审查和建议阶段，我会禁止它修改任何文件，避免它“顺手”改掉不该改的东西。等它输出问题清单之后，我再决定哪些要修，然后单独下指令让它修指定条目。这样既能让模型发挥分析能力，又能保持人的决策权。

3.7 技能七：用自然语言操作终端

Claude Code 可以执行终端命令，这就意味着你可以在对话里用自然语言完成很多琐碎操作。比如查找哪个进程占用了 3000 端口、批量重命名一堆日志文件、把某个目录下所有.png压缩成 WebP 格式。

我会这样提问：

帮我找到占用 3000 端口号的进程，杀掉它。

它会先执行lsof -i :3000或netstat -ano查看进程号，再执行kill。这里最忌讳的是模型直接凭猜测执行危险命令，所以我的习惯是给自己留一层保险：涉及删除、强杀、权限变更的命令，我会要求它先“打印命令并等我确认”，确认后再执行。在settings.json里把Bash(pkill *)、Bash(kill -9 *)这类命令加入 deny 名单也是一个好办法。

3.8 技能八：自动生成和维护文档

文档工作枯燥，但却是 Claude Code 的强项。写完一段业务逻辑后，我经常直接说“给src/services/order.ts生成 JSDoc 注释，要求说明每个函数的作用、参数、返回值、异常情况”。它会读取整个文件，为每个顶层函数添加规范注释。

同样，你还可以让它生成README、CHANGELOG甚至 API 文档。提交新功能后，我会执行：

根据最近的 git log，更新 CHANGELOG.md，按 added/fixed/changed 分类，保留现有风格。

它会把 commit 记录汇总成可读的 changelog。不过要注意，模型生成的文档偶尔会“脑补”一些代码里没有的能力。所以文档生成后，最好随机抽两个函数和实际实现比对一下，尤其是行为描述部分，避免把项目文档变成错误文档。

3.9 技能九：写一次性脚本和自动化工具

日常开发经常会遇到临时需求：把一份 CSV 转成 JSON、分析 Nginx 日志里 Top 10 的 IP、把图片批量裁剪成指定尺寸。这类“用完就丢”的脚本自己写要花时间，让 Claude Code 生成又快又不容易出错。

我会这样下指令：

写一个 Python 脚本，读取 logs/access.log，提取状态码为 500 的请求，按 URL 聚合统计次数，输出前 10 个。脚本要能在命令行直接运行，参数为日志文件路径。

它会生成代码，我要求它顺手跑一次，然后把运行结果贴回来。这看起来简单，实际上隐藏着很好的工作模式：不只生成代码，还执行验证。对临时脚本来说，大部分问题不是“能不能写出来”，而是“跑起来有没有坑”，比如编码问题、路径问题。让模型自己跑一遍，能跑通再交给你，体验会好很多。

3.10 技能十：结合VSCode和桌面端提升浏览体验

如果你不习惯纯终端的黑白界面，完全可以把它接入 VSCode 使用。装好 Claude Code 官方扩展之后，可以在编辑器底部面板直接打开 Claude Code 会话，同时还能在侧边栏看到文件改动列表和 diff 预览。这种方式特别适合“代码修改 + 人工复查”的循环：模型改完，我马上在编辑器里检查。

当你需要同时审查多个改动时，桌面端也有帮助，但我个人用得最多的还是 VSCode 集成，因为它把终端、编辑器、diff 工具都放在一个窗口里。至于很多人问“怎么保存对话历史”，Claude Code 默认会保留一定历史，你可以用claude --resume或者claude --session-id <id>回到之前的会话。如果你希望把某段对话导出，可以用命令参数控制输出，方便记录经验或做复盘。

4. 实战：用Claude Code 15分钟完成一个CSV转JSON小工具

光说技能太松散，我把它们串起来跑一个完整实战，你就能看到真实的操作节奏。

4.1 需求描述与上下文初始化

假设我要做一个小工具：读取data.csv，按表头转成 JSON 数组，再按type字段分组写入多个 JSON 文件。需求很常见，但涉及文件读写、分组逻辑、异常处理，正好能把前面几个技能用上。

第一步，我建一个空目录，并在里面创建一个极简CLAUDE.md：

# csv-to-json 一个命令行小工具，使用 Node.js + TypeScript。 - 构建命令：npm run build - 入口文件：src/index.ts - 输出目录：dist/output/

然后启动claude，输入：

请阅读 CLAUDE.md，按需求实现功能。先分析数据结构，再写代码，并补一个基本测试。

它会先读取文件，理解项目结构，再开始设计。

4.2 生成代码、测试和文档的完整过程

Claude Code 的第一步通常会先给出方案，而不是立刻写代码。它可能会询问 JSON 分组字段的处理细节，比如type缺失时是否忽略。这就是技能二“先搜索再回答”的延伸：它先分析，再确认关键决策点，避免做完发现理解偏了。

确认后，它会一次性生成src/index.ts、src/types.ts、测试文件，并尝试运行构建。如果构建报错，它会继续修改直到成功。我这时会给它第二轮指令：

请增加两个测试用例：一个处理空文件，一个处理 type 字段缺失的情况。跑完后用命令生成一个简洁的 README.md，包含说明和示例。

它又会进入“写测试 -> 跑测试 -> 修复 -> 生成文档”的循环。整个过程我基本只是在关键节点做确认和验收，具体代码细节全部交给它。

4.3 本次实战的成本复盘

这个项目从空目录到跑通，大概花了 15 分钟，消耗的 token 大约在 3 万上下，费用不高。如果你用的是本地模型或者 DeepSeek，成本会更低，但代码质量和自动修复能力会相应打折。

这里有个优化技巧：如果不是为了练手，完全不需要让模型从“空目录”开始设计架构。你应该先自己搭一个最小骨架，比如手动写好package.json和入口文件，再让 Claude Code 填逻辑，这样能省掉一半 token，还能避免它生成不必要的封装层级。

5. 常见问题与排查技巧实录

最后这部分，我把最近高频踩坑的问题集中整理一下，作为速查表，遇到类似问题可以按图索骥。

5.1 安装报错、乱码、模型不识别

老生常谈的三类问题：

• Windows 执行策略报错：用Set-ExecutionPolicy RemoteSigned -Scope CurrentUser解决。
• 中文乱码：执行chcp 65001，或切换到 Windows Terminal。
• 模型名不识别：类似"deepseek-v4-flash" is not a model this version of claude code recognizes，通常是因为ANTHROPIC_MODEL变量指向了当前版本不支持的模型。解决办法是查看官方模型列表，或者切换成claude-sonnet-4-20250514、claude-3-5-haiku-20241022这类稳定型号。

还有一个容易忽略的点：环境变量设置后，必须重新启动终端，甚至重启 VSCode 才生效，不要问我是怎么知道的。

5.2 订阅与组织限制

有读者遇到启动后提示your organization has disabled claude subscription access for claude code，这个大概率是当前登录账号的企业管理员关闭了 Claude Code 权限，或者你使用的订阅类型不支持 CLI 接入。解决方式是确认账号类型，使用个人订阅账号或改用 API Key 方式。

如果你是在公司项目里使用，最好先确认一下安全策略，别因为工具太方便就把代码直接推给外部模型，很多公司对这个有硬性要求。

5.3 如何省token和保存会话记录

关于省 token，前面已经提过CLAUDE.md和outputStyle，这里再补充一个思路：尽量让 Claude Code 批量处理同类任务，而不是一小段一小段地发指令。比如要改 10 个文件的注释，一次性告诉它“给以下 10 个文件补文件头注释”，它会在一次上下文里连续处理，比每次单独开一个任务省很多基础消耗。

会话记录方面，claude --resume能回到最近一次会话，claude --session-id <id>能恢复指定会话。需要输出结构化结果时，可以用--output-format json把结果导入其他工具做二次处理。

5.4 和Codex/Cursor的差异

我经常被问到 Claude Code 和 Codex、Coder 类的工具到底怎么选。简单做个对比：

用一句话总结：如果你的工作流高度依赖终端、脚本和持续集成，Claude Code 是最顺手的那把刀；如果你更看重鼠标点选的编辑器体验，Cursor 当然也是一种选择。两者不是替代关系，我目前是配合用的。

最后再分享一个我自己的习惯：每接手一个新项目，第一件事不是写业务代码，而是先花十分钟做一次“Claude Code 体检”——初始化CLAUDE.md、把构建命令跑通、让模型对项目结构输出一份摘要。这十分钟投资，会在后面每次会话里十倍赚回来。技能这种东西，光看不练没有意义，建议你今天就挑一个小工具项目，把这 10 个技能挨个过一遍，踩过一轮坑之后，你才算真正上手。