Claude Code 入门操作指南:从安装到完成第一个任务

Claude Code 入门操作指南

从安装到完成第一个任务：写给新手的实操路线图

整理：参宿ag

Claude Code 不是聊天框里多了一个会写代码的助手。它是一个能直接在你的电脑上读文件、改文件、跑命令、再去看结果对不对的程序——一个完整的“思考—操作—检查”循环。

这篇文章按照“认识它 → 装好它 → 认识项目 → 完成第一个任务 → 学会基本操作 → 写好任务描述 → 管好权限 → 验证结果 → 规划进阶”的顺序，把新手最容易卡住的环节一次说清楚。如果你只想知道“装完之后第一步该干什么”，可以直接跳到第五部分。

图 1｜Claude Code 的核心闭环：理解任务、执行操作、验证结果

▍一、Claude Code 是什么

跟普通的 Claude 对话相比，区别就在“动手能力”三个字上。

•普通对话：你问，它答，输出是一段文字。

•Claude Code：它能打开你电脑里的某个文件夹，读源码、写新代码、跑 npm test 或 python xxx.py 这类命令，再去看输出是不是符合预期。

核心能力是四件套：读取文件、修改代码、执行命令、验证结果——少了任何一个，“能动手做事的 AI”就不成立。只读不改，它是个顾问；只改不验，那是盲改。

适合谁用：

•开发者：改 Bug、加功能、读陌生代码库、写测试、做重构。

•非技术用户：整理本地文件、批量处理数据、搭一个小工具、写一段自动化脚本——只要任务能在终端里完成，都在它的能力范围内。

Claude Code、Claude Desktop、Cowork 三者的分工，本质是同一种“动手做事”的能力，包在不同的外壳里给不同的人用：

•Claude Code：终端里的编程代理，面向某个项目目录，强项是代码和命令行操作。

•Claude Desktop：桌面客户端，提供图形界面，里面的 Code 标签可以让你不用打开终端也能用上 Claude Code 的能力。

•Cowork：面向非开发者的桌面自动化工具，处理文件和日常任务，不要求你写代码。

▍二、开始前的准备

操作系统与终端：macOS 和 Linux 自带终端，直接用即可；Windows 用户可以用 PowerShell，或者安装 WSL（在 Windows 里运行一个 Linux 环境）来跑后面提到的安装命令。

账号、订阅、API 是三件不同的事，搞混了容易在费用上踩坑：

•账号：登录用的身份，Pro / Max / Team / Enterprise 订阅账号，或者 Anthropic Console（API）账号都可以登录 Claude Code，免费版账号不支持。

•订阅（Pro / Max）：按一个滚动的时间窗口计算用量，并且和 claude.ai 网页共享额度——白天在网页里聊得多，当天 Claude Code 能用的额度也会相应变少。

•API：按 token 用量计费，适合团队、CI、服务器等无人值守场景，费用单独结算，不占用订阅额度。

先认识三个命令：pwd（我现在在哪个文件夹）、ls（这个文件夹里有什么）、cd（切换到另一个文件夹）。Claude Code 是“在某个目录里运行”的工具，进对目录是第一步，也是最容易被新手忽略的一步。

数据、权限和费用，开始之前先想一遍：

•数据：文件内容和命令输出会发给模型处理，普通项目目录里不要放密钥、客户隐私数据等敏感信息。

•权限：默认每次写文件、跑命令前都会询问你，权限可以分阶段放宽，但放宽之前先想清楚后果。

•费用：订阅按时间窗口计算，API 按用量计算，长会话和大文件都会增加消耗。

▍三、安装与首次启动

安装方式请以官方当前文档为准——2026 年的趋势是原生安装逐步取代 npm 安装，新装机器建议优先选原生方式。

macOS / Linux / WSL，原生安装（推荐）：

curl -fsSL claude.ai/install.sh | bash

Windows PowerShell：

irm https://claude.ai/install.ps1 | iex

如果机器上已经装了 Node.js 18 及以上版本，也可以用 npm 安装，但这种方式正在逐步被原生安装取代：

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

如果两种方式都装过，注意 PATH 里哪个路径排在前面，避免新旧版本互相打架——这个问题可以用下面的 claude doctor 自检出来。

检查版本与安装路径：

claude --version# 查看版本号 

which claude# 查看实际调用的是哪个文件 

claude doctor# 自检，发现安装、路径、权限相关问题会给出修复建议

进入项目目录并运行 claude：

cd /path/to/your/project claude

第一次运行会要求登录，在交互界面里输入 /login，按提示在浏览器里完成授权。之后凭证会保存在本地，不用每次重新登录。

理解首次启动时的授权提示：第一次在某个目录里启动，Claude Code 会问你是否信任这个目录——本质是在确认“要不要让一个会执行命令的程序在这里运行”。对自己熟悉的项目目录，正常选择信任即可；对来源不明的代码仓库，先别急着信任，等读过内容之后再决定。

完成一次简单问答：启动后直接问一句“这个项目是做什么的？”——不涉及任何修改，纯粹确认它能正常读取和理解你的项目。这是检验安装是否成功最干净的方式，比看一遍版本号更有说服力。

图 2｜从安装、自检、登录到首次读懂项目

▍四、让 Claude Code 认识项目

第一次进入一个项目，先让它“看”，别急着让它“动”。问它项目结构、用了什么技术栈、怎么启动、怎么测试——这一步本身不会改动任何文件，但能让你判断它是不是真的“看懂”了这个项目。

可以问的问题：

•这个项目大概是做什么的，用了哪些主要技术？

•项目目录结构里，哪些是核心代码，哪些是配置、测试或构建产物？

•怎么启动这个项目？怎么跑测试？

找出构建、测试、启动这三个命令——它们是后面所有任务“验证有没有做对”的基础。新手最容易跳过这一步，结果改完代码不知道该怎么验证。

使用 CLAUDE.md 保存稳定的项目规则：在项目根目录放一个 CLAUDE.md 文件，写清楚一些“每次都要重复说”的内容——项目用什么框架、代码风格约定、测试怎么跑、哪些目录不能动。每次在这个目录启动，它会自动读取这份说明，相当于把项目的长期背景固定下来。

不要把全部知识塞进一个上下文文件：CLAUDE.md 适合放“稳定不变”的规则——技术栈、约定、命令。频繁变化的信息（这周在改什么、临时注意事项）不适合塞进去，否则文件越写越长，每次启动都要重新读一遍，反而拖慢节奏，也容易过时。把“稳定规则”和“当前任务”分开管理。

▍五、完成第一个实际任务

以“修改一个页面或修复一个小问题”为例，七步走完一个完整任务：

1.描述目标和验收标准——不要只说“优化一下这个页面”，说清楚改什么、改成什么样、怎么算改完了。比如：“首页的提交按钮在没填邮箱时应该禁用，填了合法邮箱格式后才能点。”

2.要求 Claude 先调查，不立即修改——明确告诉它“先看代码，告诉我打算怎么改，不要直接动手”。这一步把“思考”和“动手”分开，给自己一个检查的机会。

3.查看并确认实施计划——它会给出打算改哪些文件、大概怎么改的计划。读一遍，看是不是在预期范围内；如果出现了完全没预料到的文件，先问清楚为什么。

4.授权修改必要文件——计划没问题，再放行让它真正开始写文件。

5.运行测试或启动项目——改完之后让它跑测试命令，或者启动项目看实际效果，这一步是把“代码看起来对”和“代码确实对”区分开的关键。

6.检查 diff 和实际结果——看具体改了哪些行（diff），再看运行结果是否符合第一步定义的验收标准。

7.修复失败并完成回归验证——测试不过或效果不对，让它继续修；修完之后别只验证这一个改动点，顺手确认旁边的功能没被波及。

第七步里的“回归验证”是新手最容易省略的一步——一个小改动看起来只影响局部，但代码之间的依赖关系经常超出直觉。

图 3｜第一个实际任务的七步闭环

▍六、必须掌握的交互方式

•@ 引用文件：输入 @ 加文件名，可以快速把某个文件“指给”它看，不用口头描述路径。

•! 执行或理解 Shell 命令：用 ! 开头可以直接运行，或者询问某条 shell 命令的含义，适合临时查看一下输出，不打断当前对话。

三种工作模式：普通模式（每次写文件、跑命令前都会询问你）、计划模式 Plan Mode（先只产出计划，不执行任何修改，适合调查阶段和复杂任务）、自动接受编辑（跳过逐次确认，效率高但风险也高，建议只在范围明确、已经验证过的任务里短时间打开）。

中断、回退和恢复会话：任务跑偏了可以随时中断；改错了可以回退到之前的状态重新来；会话也可以中途退出，之后在同一目录恢复继续。

新会话与压缩上下文的选择：对话聊得太久，上下文会变得又长又乱，有两种处理方式——开一个新会话（适合开始一个新任务），或者用 /compact 压缩上下文（适合同一任务继续，但历史记录已经太占地方）。

查看上下文、用量和费用：/context 可以查看当前上下文的占用情况，/clear 清空对话重新开始。定期看一眼用量，避免长会话不知不觉吃光额度。

▍七、如何写出有效任务

推荐用下面这个结构来描述任务，把六行填满，比写一段流畅的自然语言描述更有效——它强迫你在开始之前就想清楚边界：

目标： 

背景： 

允许修改的范围： 

不能修改的内容： 

完成标准： 

验证方式：

三个对照案例：

三个案例分别对应“收尾型任务”“扩展型任务”“调研型任务”，验收标准的写法各不相同，但都遵循同一个结构。

▍八、权限与安全

从只读探索开始：先看，再小范围改，验证没问题之后再扩大范围——权限是可以分阶段开放的，不必一步给到最大。

谨慎处理的高风险操作：删除文件、安装依赖、部署上线、向外部地址发送数据。这几类操作出错的代价远高于改错一行代码，遇到这类操作，多一次确认不算麻烦。

不在笔记或 Git 中保存 API Key：密钥写进代码仓库，几乎等于公开发布。用环境变量或专门的密钥管理方式，CLAUDE.md 和提交记录里都不应该出现真实密钥。

把网页、邮件和第三方文档当作不可信输入：这些内容可能包含专门设计用来诱导 AI 执行额外操作的指令（也就是常说的“提示注入”）。让 Claude Code 读取这类外部内容时，多留意它接下来打算做什么，尤其是涉及发送数据或执行命令的部分。

第三方 Skills、插件与 MCP 的供应链风险：它们本质上是别人写的代码或配置，安装之后会获得相应的权限。装之前看一眼来源、确认它实际会做什么，不要因为名字听起来很“官方”就直接信任。

▍九、让结果可验证

测试通过不等于任务完成：测试只覆盖了写测试的人想到的场景，新功能和边界情况未必都在里面。

四个检查点缺一不可：文件差异（diff）、运行结果、用户实际操作路径，以及——如果是前端任务——用浏览器或截图实际看一眼界面。

不接受单方面的“已经完成”：它说“已经完成”和你确认“确实完成”是两件事。让它给出可以复核的证据——diff、测试输出、截图、运行日志，而不是一句结论。

保存失败过程和验证证据：中途失败的尝试和最终的验证结果都值得留一份记录，下次遇到类似问题，这些记录就是经验。

图 4｜行动之前确认权限，完成之后核对证据

▍十、进阶能力地图

这七项不需要第一周就全用上，知道它们存在，遇到对应场景时就知道该往哪个方向找。

▍十一、新手常见误区

•一开始就让 Claude 修改整个项目——范围越大，出错后越难定位。

•使用含糊的“帮我优化一下”——优化方向、目标、约束都没说，等于没给任务。

•无限延长同一个会话——上下文越长，越容易丢失早期的关键信息。

•不查看 diff 和测试结果——把“它说做完了”当成“做完了”。

•盲目开启自动权限——还没摸清它的判断习惯之前，自动权限放大的是风险，不是效率。

•看到热门第三方插件直接安装——来源和权限范围先看清楚。

把模型能力与 Claude Code 工具能力混为一谈：模型再聪明，没有读写文件、执行命令的工具调用能力，也做不了“动手”的事；反过来，工具调用再完善，理解和判断仍然取决于模型本身。两者是配合关系，不是同一件事。

▍十二、推荐的七天学习路径

▍附录

常用命令速查表：

新手任务模板：

目标： 背景： 允许修改的范围： 不能修改的内容： 完成标准： 验证方式：

安全检查清单：

•是否在自己熟悉、信任的目录下运行？

•涉及删除、安装、部署、外发数据的操作，是否单独确认过？

•API Key 等密钥是否不在仓库和笔记里？

•外部内容（网页、邮件、第三方文档）是否当作不可信输入处理？

完成定义清单（Definition of Done）：

•diff 已检查

•测试或运行结果已确认

•实际操作路径已验证

•回归范围已检查

•失败过程和验证证据已保存

文中涉及的安装命令、斜杠命令与模式名称会随版本更新，实际操作前可以用 claude doctor 或 /help 现场核对当前版本的说明。