Claude Code 使用教程：在终端里让 AI 帮你写代码

2026-06-16

Claude Code 是一种和编辑器很不一样的 AI 编程方式：它跑在终端里，更像一个会自己读文件、写文件、跑命令的「编程代理」。你描述任务，它动手干，你负责审阅。这篇教程不讲花活，就讲你上手第一周会用到的东西：怎么装、怎么配、怎么下达任务、踩了坑怎么爬出来。

Claude Code 是什么

和 Cursor 这类「你在编辑器里写、AI 在旁边帮」的工具不同，Claude Code 把主导权更多交给 AI。你在命令行里启动它，用自然语言交代一个任务，它会自己浏览项目、定位相关文件、做出修改、运行测试或命令，遇到问题再继续调整。

它背后是 Claude 系列模型，对长程任务（涉及多个文件、多个步骤的改动）掌控力较强，这也是终端代理派的核心优势。它不是「自动补全的升级版」，而是一个能读懂项目结构、自己规划步骤、自己验证结果的执行者。你把它当成一个刚入职、手脚麻利但需要盯着的初级工程师，用起来心态最准。

安装和第一次启动

装机很简单，前提是本机已经装了 Node.js（18 及以上版本）：

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

装完之后，进到你要处理的项目根目录，直接敲：

claude

第一次启动会引导你登录 Anthropic 账号并完成授权。如果你的公司走的是 AWS Bedrock 或 Google Vertex AI 的企业采购渠道，也可以用对应的环境变量接入，具体看官方文档，这里不展开。

进到交互界面后，先别急着丢任务，花两分钟做两件事：

确认当前目录是不是你要改的项目——它默认以启动目录为工作区，装错目录会浪费一轮对话；
看一眼它能不能正常访问网络（如果你的任务需要它查文档或跑远程命令）。

CLAUDE.md：让它记住项目规矩

新手最容易漏掉的一步，是没有给项目建 CLAUDE.md。这个文件放在项目根目录，Claude Code 每次启动都会自动读取，相当于给它的「入职须知」。建议至少写清楚这几件事：

技术栈和目录约定：用的是什么框架、组件放哪、样式方案是什么，省得它每次都要重新猜；
命令怎么跑：测试命令、构建命令、lint 命令分别是什么，写清楚了它才不会瞎试；
代码风格底线：比如「禁止用 any」「函数式组件优先」「提交信息用什么格式」；
红线：哪些文件绝对不能碰（比如 .env、生产配置），哪些操作要先问你（比如删库、强推）。

这个文件不用一次写全，边用边补，是投入产出比最高的配置动作，比反复在对话里重复同样的话省事得多。

权限模式：管住它的手

Claude Code 默认对「有风险」的操作会停下来问你确认，比如写文件、执行命令、联网请求。这个确认机制是新手期的安全带，别急着关掉。等你摸清脾气了，可以按场景调整：

交互模式下每次操作都问：最保守，适合刚接触、还在建立信任的阶段；
用 --permission-mode plan 启动「计划模式」：它只分析和给方案，不动手改文件，适合你想先看它的思路对不对，再决定要不要放行；
在配置里对「读文件」「跑测试」这类低风险操作加白名单，减少无意义的确认弹窗，但写文件和执行 shell 命令的确认不建议关，这是防止它删错文件、跑错命令的最后一道闸。

如果你要跑一批可重复的自动化任务（比如批量给一堆文件加同一段头注释），可以用无交互的 headless 模式，通过命令行参数一次性传入任务和权限策略，跑完自动退出，适合接入 CI 或脚本里，但一定要先在交互模式里手动跑通一遍，确认它的改法符合预期，再放到自动化流程里跑，不然出错range会很大。

典型工作流

用 Claude Code 的核心节奏是「交代—执行—审阅」三步：

描述任务：用清晰的自然语言说明你要什么，越具体越好。比如别说「优化一下用户模块」，要说「把用户模块的密码校验逻辑抽成独立函数 validatePassword，放到 utils/auth.ts，并补一个覆盖空密码、弱密码、正常密码三种情况的单元测试」。任务描述越像你写给同事的工单，它执行得越准。
它读写文件、跑命令：它会先读相关代码理解现状，再动手改，必要时运行命令验证。整个过程你能看到它在做什么、读了哪些文件、改了哪一行——这个过程别走神，遇到它明显跑偏（比如开始改一个你没提到的文件）要立刻打断。
你审阅：改完后用版本控制（如 git diff）查看它改了哪些地方，确认无误再提交。这一步不能省，AI 会犯错，把关的是你。常见的坑是它「顺手」改动了不在任务范围内的代码，或者为了让测试通过而弱化了断言——这两类问题光看测试是否通过看不出来，必须过一遍 diff。

实践中建议「小步快跑」：一次只交代一个相对独立的任务，做完审阅通过再进行下一步，比一次性丢一个巨大需求更可控。具体到粒度，一次任务改动控制在 3-8 个文件比较好审阅；超过这个量，宁可拆成两轮，也别指望自己能一口气看完几十个文件的 diff 还不漏检。

进阶用法还有几个值得知道：

规划先行：对复杂任务，先让它列出改动计划（不要立刻动手），你看完计划再说「按这个方案做」，能大幅减少走错方向返工的成本；
多轮迭代：一轮任务做完发现方向不对，直接在同一个会话里说明问题、给出新指令，它能带着上下文继续调整，不用重新解释背景；
并行任务用工作树：如果你想让它同时处理两个不相关的分支任务，用 git worktree 开两个独立目录、各起一个 Claude Code 会话，互不干扰，比在同一个工作区来回切分支更省心；
上下文管理：长会话跑久了上下文会变得臃肿，响应变慢或答非所问时，果断开新会话，把关键背景写进 CLAUDE.md 或任务描述里重新交代，别指望它一直记得住几十轮之前的细节。

和编辑器派的差异

简单对比一下两种路线：

维度	编辑器派（Cursor 等）	Claude Code
交互范式	你写为主、AI 辅助补全/改写	AI 干为主，你负责审阅把关
上手门槛	低，边写边看结果	略高，需要习惯命令行和信任模型
擅长场景	日常小步改动、调样式、局部重写	大重构、多文件工程任务、批量自动化
单次任务粒度	几行到一个文件	一个功能到十几个文件
出错代价	小，实时可见、随时改	相对大，一次改动面广，需要认真审阅 diff
成本模式	多为月度订阅	按 API 用量计费，或搭配订阅套餐

从成本角度看，Claude Code 的按量计费意味着任务描述得越精准、返工越少，实际花费越低——这也是为什么前面反复强调任务描述要具体、要先审阅计划再动手，这不只是工程习惯问题，也是真金白银的问题。

想看更完整的对比和选型建议，可以读 Cursor vs Claude Code。结论其实是：两者不冲突，重度开发者常常都用——编辑器管手感，代理管苦力。

新手常踩的三个坑

任务描述太模糊：丢一句「帮我重构一下这个模块」，它只能靠猜，猜错了返工成本比自己写还高。宁可多花两分钟把验收标准写清楚。
不看 diff 就提交：尤其是批量任务，测试通过不代表逻辑对，务必过一遍改动内容，特别关注它有没有动了任务范围之外的文件。
一次塞太多需求：想一次性让它「顺便」把三四件不相关的事都做了，出了问题很难定位是哪一步出的错，拆开来一步步走远比想象中省时间。

想系统学，奇连 AI 的 AI 编程课从 0 带你把 AI 编程真正用进日常工作流。